Introduction

Generalities

SpatiaLite is an open source library intended to extend basic SQLite core in order to support full fledged Spatial SQL capabilities.

SQLite is intrinsically simple and lighweight:

• a single ligthweight library implementing the full SQL engine.
• standard SQL implementation: almost complete SQL-92.
• no complex client/server architecture.
• a whole database simply corresponds to a single monolithic file [no size limits].
• any DB-file can be safely exchanged across different platforms, because the internal architecture is universally portable.
• no installation, no configuration.

SpatiaLite is smoothly integrated into SQLite so to deploy a complete and powerfull Spatial DBMS [mostly OGC-SFS compliant].
All this fully preserving the lightness and simplicity typical of SQLite itself.
That's not all: SpatiaLite supports direct SQL access to several commonly used external datasources, this including:

• ESRI Shapefiles.
• DBF Archive Files.
• TXT/CSV structured text files.
• Spreadsheets [.xls format].

And SpatiaLite actively supports many alternative standard Geometry notations:

• WKT [Well Known Text] and WKB [Well Known Binary].
• PostGIS own EWKT and EWKB [Extended WKT / WKB].
• GML [Geography Markup Language, both v2 and v3].
• KML [Keyhole Markup Language, used by Google Maps and Google Earth].
• GeoJSON [Geometry Java Script Object Notation].
• SVG [Scalable Vector Graphics].

Conclusion: using SQLite + SpatiaLite you can deploy an alternative Spatial DBMS roughly equivalent to PostgreSQL + PostGIS.
The main difference between them isn't in powerness, but mainly relies on architecture:

• PostgrSQL + PostGIS fully supports a client/server architecture.
  This is well fit for complex and sophisticated Spatial Data infrastructures, but surely implies a certain degree of complexity.
• SQLite + SpatiaLite supports a much more simplest personal architecture.
  This is most appropriate for desktop, stand-alone, personal activities.

Choosing the one or the other simply depends on your very specific requirements:

• no one is better than the other one: they are simply optimized for different envoronments.
• both them can roughly support the same Spatial Data processing capabilities.
• feel free to choose the best fit one accordingly to your effective goals.

Building

Building and installing the SpatiaLite library is straightforward:

./configure
make
make install

Please note: SpatiaLite depends on the following open source libraries:

• GNU ICONV
  locale charset encodings support
• GEOS
  Geometry engine
• PROJ.4
  Spatial Reference System handling [coordinate re-projection]
• FreeXL
  Spreadsheet input support [.xls format]

The library comes in two different flavors:

• libspatialite
  standard, canonical library: the best and safest way to deploy SpatiaLite.
  this obviously depends on external libsqlite: thus ensuring full coherence between libraries.
  warmly reccomended, mostly on Unix-like systems.
  
• libspatialite-amalgamation
  The whole library is amalgamated into a single monolithic file and includes an internal private copy of libsqlite.
  Using the amalgamated library may strongly simplify any following installation process, and nicely supports static linkage.
  Anyway, you can safely apply the amalgamated approch only to self-standing apps.
  Attempting to use the amalgated library on complex frameworks or on data connectors / language bindings
  may easily cause serious conflicts.

Deployment

You can deploy SpatiaLite in two alternative ways:

• you can load the SpatiaLite library as a dynamic extension to SQLite.
  This allows SQLite to support SQL Spatial Data [Geometry] and SQL Spatial Functions.
  Theorically, any generic tool or language connector supporting SQLite can support this extension mechanism;
  sadly enough, sometimes this feature is intentionally disabled: I'm sorry for you if this is your specific case.
  
  How to load SpatiaLite as a dynamic extension to SQLite:

  SELECT load_extension('spatialite_dynamic_library_name');
  

  
  
• you can directly link the SpatiaLite library to any application of your own.
  This allows you to ship a complete, powerfull, self-contained Spatial SQL engine directly supporting your app.
  And such Spatial SQL engine doesn't requires any installation or configuration at all.
  That's not all: linking the SpatiaLite to your own C/C++ code you aren't simply constrained to use SQL:
  adopting this approach you can directly access the complete C API.
  
  Linking SpatiaLite to your own code is usually simple:

  gcc my_program.c -o my_program -lspatialite
  

  
  On some systems you may have to provide a slightly more complex arrangement:

  gcc -I/usr/local/include my_program.c -o my_program \
    -L/usr/local/lib -lpsatialite -lsqlite -lgeos_c -lgeos \
    -lproj -lfreexl -liconv -lm -lstdc++
  

  
  SpatiaLite also provides pkg-config support, so you can also do

  gcc -I/usr/local/include my_program.c -o my_program \
    `pkg-config --libs spatialite`
  

License

SpatiaLite is licensed under the MPL tri-license terms: you are free to choose the best-fit license between:

• the MPL 1.1
• the GPL v2.0 or any subsequent version
• the LGPL v2.1 or any subsequent version

Enjoy, and happy coding