The Future Looks Bright for SpatialLite
This blog has covered the wonderful SpatiaLite database several times. To quickly review, SpatiaLite is a full-blown spatial database, complete with not only with spatial data types, but also with spatial predicates, and an OGC Simple Features for SQL implementation (think PostGIS). It also includes support for raster data and routing support, all implemented in an SQLite database so the whole database can be emailed to a colleague, or embedded into applications.
This format had me very excited since I first heard about it 2 and a half years ago, as a potential replacement for the Shapefile, but I was personally holding back a bit since FME had no way of reading or writing spatial data in it. I was very pleased to see that there is now an FDO provider for SpatiaLite (Massive hat tip to Jason Birch for alerting me to this and to Haris Kurtagic of SL-King for creating the FDO provider).
This means that while there is no official SpatiaLite reader or writer for FME (yet) you can still read and write any of over 255 data formats to SpatialLite by using FME’s FDO Providers Reader/Writer. The setup is a manual process for now, but a wrapper to make this a standard FME format is on the way. If this process sounds familiar, you may have used this method to use SQLite Spatial (an alternative spatial extension of SQLite). For those playing along at home, we quickly wrapped Jason’s steps into a first class FME format.
So why am I so excited about SpatiaLite? Imagine a mobile application that accesses data from a traditional spatial database like PostGIS, but can also operate offline through an embedded SpatiaLite database with no loss of functionality. In an email today to Haris about using his FDO provider through FME, I attached a sample SpatiaLite database created with FME. This file contains both data as well as database logic. What a great interchange format!
With SQLite making such great progress as a non-spatial data format, it is great to see SpatiaLite getting traction for the same reasons.