Ticket #4269 (closed task: fixed)
Spatialite write support improvements
|Reported by:||rouault||Owned by:||spatialite|
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. ============================================
Note: See TracTickets for help on using tickets.