[gdal-dev] SpatiaLite patch-set

[a.furieri at lqt.it]

Hi all,

just a quick social introduction: I'm the main developer
and maintainer of the SpatiaLite DBMS.

I'm glad to submit to your attention the attached
patch-set, intended to add full and robust support 
for SpatiaLite [OGR/SQLite driver].

some months ago I've already contributed a patch-set
for OGR effectively supporting 2.5D geometries [recent 
versions of SpatiaLite]: and thanks to Even Rouault's 
kind cooperation that patch-set was duly accepted and 
committed to SVN-trunk.

Anyway, my previous patch-set was simply focused on 
"read" modes: the present patch-set is focused instead 
on effectively supporting "write" modes as well, thus 
allowing ogr2ogr to create fully valid SpatiaLite own 
DB-files.

just a short technical reminder: supporting "read" ops
doesn't strictly require OGR to be linked against libspatialite.
But any attempt to perform "write" ops skipping at all the 
expected libspatialite support will simply create a corrupted 
(i.e. broken, useless) DB-file, not a genuine SpatiaLite own.


ogr2ogr options:
================
the current implementation already supported several SpatiaLite 
specific options:

-dsco SPATIALITE=YES (enabling SpatiaLite DB creation)
-lco SPATIAL_INDEX=YES/NO (creating or not a Spatial Index)
I left both options completely unaffected.

-INIT_WITH_EPSG=YES/NO (populating or not the "spatial_ref_sys" 
 table)
I've changed the behaviour of this option:
* if libspatialite 2.3.1 (or any previous) is linked to ogr2ogr, 
  then the option behaviour is unaffected
* if libspatialite 2.4.0 (or any subsequent) is linked to ogr2ogr, this 
  option will be always ignored because any recent version automatically 
  loads the whole EPSG dataset into "spatial_ref_sys" while creating a 
  new DB.

I've introduced a further SpatiaLite specific option:
-lco FORCE_2D=YES/NO
interpretations is the following one:
* if libspatialite 2.3.1 is linked to ogr2ogr, then this option is 
  completely ignored, because v.2.3.1 simply supports 2D. 
  so, forcing any geometry to 2D is silently implied anyway.
* if libspatialite 2.4.0 (or any subsequent) is linked to ogr2ogr, 
  this option will be honoured as specified by the user.


about technical implementation:
===============================

ogr_sqlite.h
------------
I've introduced (several classes and methods affected) a new boolean 
variable: bSpatialite2D
this is intended to implement the FORCE_2D option

ogrsqlitetablelayer.cpp
-----------------------
I've simply added support to bSpatialite2D 

ogrsqlitedatasource.cpp
-----------------------
OGRSQLiteDataSource::CreateLayer()
I've completely replaced the code implementing creation of any 
SpatiaLite table and geometry.
Now the appropriate SpatiaLite's own SQL method AddGeometryColumn() 
is correctly invoked, avoiding at all any direct access to 
"geometry_columns".
(any such attempt will easily produce an inconsistent DB)

ogrsqlitedriver.cpp
-------------------
OGRSQLiteDriver::CreateDataSource()
I've completely changed the implementation of DB creation: 
now the appropriate SpatiaLite's own SQL method InitSpatialMetadata() 
is correctly invoked. 
(this too avoids generating broken and inconsistent DB-files).
And I've consistently handled INIT_WITH_EPSG as explained before.

ogrsqlitelayer.cpp
------------------
OGRSQLiteLayer::ComputeSpatiaLiteGeometrySize()
OGRSQLiteLayer::ExportSpatiaLiteGeometryInternal()
OGRSQLiteLayer::ExportSpatiaLiteGeometry()
Code arranged as appropriate, so to consistently honour the FORCE_2D
option accordingly to the library version linked to OGR.

drv_sqlite.html
---------------
updated documentation.

misc
----
I've added some 'contributing' disclaimer here and there,
acknowledging the financial support offered by Tuscany Region Govt.

other infos
-----------
the proposed patch-set doesn't impacts at all with the existing 
sqlite/FDO implementation.
any libspatialite version (from the nowadays obsolete 2.3.1 to 
the latest 3.0.0) is fully supported.
and finally OGR could be used to create fully valid SpatiaLite's
own DB-files without any inconsistency: surely a big improvement
for interoperability.
============================================

Glad to hear any comment from you about all this.

Sincerly your,
Sandro Furieri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spatialite_patch.zip
Type: application/zip
Size: 6801 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110929/7db0915f/spatialite_patch-0001.zip