[fdo-internals] SpatiaLite; spatial extension for SQLite

[Alessandro Furieri]

I've finally released SpatiaLite and VirtualShape,
two extensions enabling spatial processing on
SQLite and direct SQL processing for shapefiles
please see: http://www.gaia-gis.it/spatialite/

I notice that you've already included a link in
http://trac.osgeo.org/fdo/wiki/FDORfc16
... thanks ...

- SpatiaLite actually stores geometries in BLOB
  columns, using an internal format very closely
  related to WKB [but not identical]:
- there are "magic numbers" [markers] at strategic
 positions ensuring the BLOB really is a geometry
 as expected
- there is an explicit SRID assignement
- there is an header containing the MBR aka BBOX,
 in order to allow quick entities selection for
 a given spatial context.

You'll find a complete reference for "BLOB internal
format" at
http://www.gaia-gis.it/spatialite/SpatiaLite-manual.html#t3 
Converting to/from "BLOB internal format" from/to
WKB and WKT [... any other format at your choice ...]
is a quite simple task, and does not requires any
"extension" [dll, so] at all.
A couple of simple C functions included in your planned
FDO provider can easily accomplish such kind of conversions
with a very limited complexity and little overhead;
you can eventually derive your own functions starting from
the SpatiaLite's ones in the sple_geometry.c and sple_wkt.c
sources.

IMHO, the optimal solution will be as follows:
----------------------------------------------
- the FDO provider will support the various WKT, WKB, FGF
 and metadata tables as originally planned
- adding support for the new "SpatiaLite internal BLOB"
 format as well
- SpatiaLite on its own can implement some extra SQL
 function such as: AsFGF(geom), GeomFromFGF(fgf)
 in order to ensure an easy way to support FGF
 encoded geometries
 (it seems to me FGF is very similar to WKB, at least
  for XY Point, LineString, Polygon, MultiPoint,
  MultiLinestring, MultiPolygon, and MultiGeometry;
  supporting Z or M and CurveString, CurvePolygon seems
  harder ... at least for now)

Arranging things in such a way will ensure an easy
integration:
- users who simply want to use SQLite as a generic
 GIS data repository, with no SQL frills,
 can do this by using the FDO provider alone, with
 no need for "extensions" at all.
- users who needs a simple but quite complete
 spatial DBMS can use SQLite+SpatiaLite
- the two environments can fully interoperate,
 because they both share a common binary representation
 for geometries, i.e. the "SpatiaLite BLOB internal".

Best regards,
Sandro Furieri