Is SpatiaLite or SQLite Spatial an Accepted Standard?

Question

The reason why I ask this is because I have been undertaking some testing and have found that there seems to be many implementation and not all of them are interchangeable. For example:

1. FME can read and write SQLite Spatial (FDO) and SpatiaLite
2. MapInfo can read and write SQLite Spatial (FDO, I think)
3. QGIS can read and write SpatiaLite

But,

• MapInfo wont read QGIS' SpatiaLite
• FME will read and write anything (as usual)
• QGIS will read output from FME in either the FDO or SpatiaLite writer, but can't edit (silent fail) and the same for MapInfo written tables.

There are probably other bits of software that read/write some variation of the above but implement it differently.

So, to ask a simple question. Is it fair to expect to work in some variation of SQLite and be interoperable?

Edit: It turns out that you can read/write spatialite from MapInfo and FME in QGIS via the 'open vector' dialog. I was trying using the 'add spatialite table' dialog. It just remains that MapInfo wont read SpatiaLite from QGIS, but this isn't all that surprising...

Edit 2: I am thinking that QGIS wont edit mapinfo and qgis SQLite Spatial layers, despite being able to view them, due to the use of the generic 'geometry' spatial type, rather than 'point' or 'polygon' etc.

Answer 1

For sake of posterity, the short answer is that MapInfo and FDO (AutoDesk technology) are far removed from any development with SQLite, compared to the members of the SQLite Consortium. MapInfo and FDO (AutoDesk) would be contributing binary to their downstream users, via their products and services.

Spatialite is specked under a triumvirate of licenses--Mozilla Public License, GPL, and LGPL. QGIS (via the Qspatialite plugin) is the most significant user of Spatialite, seeing its preeminent usage compared to other applications, they contribute code upstream AND binary for users downstream..

Upstream of Qspatialite is Spatialite itself, controlled at http://www.gaia-gis.it/ This is where the development occurs of the deFacto standard. Spatialite_GUI, a simple executable that requires no installation, is the recommended executable to target design usage with. IF the Spatialite database isn't designed to work with this product, Spatialite_GUI, then its a "non-standard" version of Spatialite.

It's worth noting that SQLITE is the overriding database executable, which is public domain and therefore without any license at all. Spatialite extends SQLite. The chief developer of SQLite is Dwayne Richard Hipp. SQLITE has established the high reputability, trust and usage from major corporations.

A portion of the development is sponsered by the SQLite Consortium, which currently includes Bloomberg, Mozilla, Bently, Nokia, Adobe and Oracle. The SQLite Consortium is the deFacto Standardization of the SQLite database executable, located at http://sqlite.org If an sqlite database isn't designed to work with their executables, then it's a "non-standard" version, or fork, or SQLite.

Of note, I'm not seeing that commercial GIS leaders such as MapInfo, Autodesk, Safe Software or Esri are part of this SQLITE Consortium.

SQLite can easily store spatial geometries without being extended by Spatialite. But, Spatialite adds the ability to query the SQLite database based on spatial relationships, rather than just standard data value queries. If you don't need to query based on spatialite relationships, then SQLite (by itself) may be all that you need to store an archive of GIS data.

(Edit 2021): As of 2018 - SQLite can do many spatial relationships by itself using the GEOPOLY extension: https://www.sqlite.org/geopoly.html. If you wanted to limit dependencies, it may be worth investigating. I can't speak to its performance yet, or a feature comparison, but it seems to provide SQLite with a fairly decent spatial capability.