Spurred on by some great talks at FOSS4G, and also by a bit of cynicism elsewhere in the geospatial blogosphere, I finally got around to having a play with Spatialite at the weekend. There have been posts elsewhere about it working really well, so all I’ll say here is “it works for me as well”. I’m not really trying to tout it as a shapefile replacement, but a useful tool in a particular use case as an alternative to the ESRI personal geodatabase.

The use case I’m thinking of is the rather prosaic issue of file management. We are moving over to the KnowledgeTree Content Management System for file management, which works well for single files, like Documents, Spreadsheets, etc, but is pretty useless for multi-part files (for want of a better term) like CAD or GIS data. I can’t speak for CAD, but the average GIS scenario is going to need at least one project file, plus shapefiles with at least three parts to them, and usually rasters with at least two parts to them. Logically, file-based geodatabases work well in this scenario, providing you with a single file to hold your geospatial data. With Rasterlite support becoming more common, perhaps with Spatialite we can have our rasters nicely packaged up as well as our vectors. Getting data in and out is easy, and can be automated using scripts so easily that even I can do it.

So- why are we not doing using PostgreSQL for all of this? Well, in an ideal world we’d have big and powerful enough servers and network bandwidth to cope with the myriad GIS work we do.  Some of the GIS work is quite ephemeral, so we don’t want to go to the trouble of setting up new databases/virtual machines every time someone needs to use GIS for a project. Spatialite seems ideal for this, and I look forward to exploring it further over the coming weeks.