[Gvsig_english] [GSOC 2010] Spatialite Support: some things need to be discussed

[Benjamin Ducke]

Hi Luca,

I think you should not worry too much about write support for the 
SpatiaLite format at this time. Better first implement the 
specification for loading and saving WKT/WKB geometries in an
SQLite3 DB, as detailed here: http://trac.osgeo.org/fdo/wiki/FDORfc16

If we have support for this format in gvSIG, then we are interoparable
with all GIS that use the OGR driver for vector data access (and that's
the majority).

The SpatiaLite format as such has no particular advantage in a gvSIG
context. SpatiaLite implements things such as topology queries and
spatial indices. But gvSIG already has all of that, so no need to
reinvent those things!

Of course, it would be very nice to have direct writing of SpatiaLite
format geometries in addition to reading them. But for that it should
be enough to implement the basic geometry BLOB structures. Start with
reading from SpatiaLite BLOBS, then if there is still time, implement
writing. I agree that direct processing of the BLOBs is much better
than wrapping the SpatiaLite C API using JNI, because that will just
break with the next major SpatiaLite release!

Cheers,

Ben




----- Original Message -----
> Hi all,
> 
> I'd like discussing a couple of things with you after all the tests
> I've done during this first time past for finding out which was the
> most reasonable approach to get SQLite and SpatiaLite support into
> gvSIG.
> 
> Brief introduction:
> 
> I've tested all the approaches and resources we've discussed [1] and
> all those I could find asking around and scanning the web.
> 
> Results:
> 
> SQLITE SUPPORT
> 
> - The Xerial SQLite driver[2], derived from the Zentus'one [3],
> developed and mantained by Taro L. Saito of the University of Tokyo
> looks to be the most suitable for accomplishing our tasks.
> 
> The reasons are mainly:
> - it's kept updated and recompiled with every new version of SQLite
> - it has some improvements and some fixing
> - you need to include in your project just one file (sqlite-jdbc.jar)
> in order to use it
> - as far as it's a java jar it's multiplatform
> 
> SPATIALITE
> - you can import the libspatialite.* file (according to your system)
> with Xerial sqlite-JDBC driver(see above)[2] and reading data from a
> SpatiaLite database
> - I've found many bugs in doing Spatialite's operations (due probably
> to bugs in memory handling of SpatiaLite functions into java-driver):
> that means I can do any SELECT with SpatiaLite's functions (I've
> tested many of them) retrieving the data I want BUT with a silly
> workaround that avoids the crash of the JVM (usually in connection
> closing / statment reset)
> - I can't write data at the moment (I've found no workarounds/fixing
> yet) because of other errors in memory handling.
> I've got in touch with Taro L. Saito but I guess he has not found any
> fixing for that segmentation fault.
> I will try to write him again hoping he has time to fix this problem.
> 
> CONCLUSIONS
> 
> I guess that thanks to SQLite-JDBC driver [2] including SQLite support
> into gvSIG should be quite quick (Cèsar has suggested me to see the
> libFMap_daldb for understanding how MySQL, etc are already supported
> in our application).
> 
> SpatiaLite support needs to be discussed a little bit because the
> reading it's quite straightforward (keeping in mind we can make it
> work with a workaround. That's not proper but as a temporary solution
> could be partially acceptable), including the proper library
> (according to OS and architecture) thanks to the SQLite-JDBC driver as
> well.
> 
> SOLUTION I PROPOSE ABOUT SPATIALITE
> 
> Well, I'd need hearing your ideas about this matter anyway and discuss
> together about which whould be the better way to get spatialite
> support.
> 
> However I've a proposal to get finally a much better work in my
> opinion: I've almost finished the code for decoding the SPATIALITE
> BLOB[5] (that's the particular structure that stores every Spatialite
> infos) and I guess the better thing would be implementing a Java
> version of SpatiaLite or at least of its most common functionalities.
> For many of them we could have help from JTS[4] (as partially
> suggested by Juan Lucas [1]).
> 
> 
> Firstly it would let us having just one file (a common java jar) for
> every OS and architecture, instead of having a lib file for each most
> common machine.
> It would avoid the necessity of trying to wrap a C lib into a JAVA
> interface with all the problems we have already with the memory
> handling in importing libspatialite.* into the already fully working
> driver [2].
> It would take some time BUT finally we will have a much cleaner and
> multiplatform solution.
> 
> Sorry for the maybe too long paper,
> 
> Cheers,
> 
> Luca
> 
> [1]
> http://osgeo-org.1803224.n2.nabble.com/New-Student-for-GVSIG-within-Google-Summer-Of-Code-2010-quick-introduction-td5014112.html#a5014112
> [2] http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC
> [3] http://www.zentus.com/sqlitejdbc/
> [4] http://www.vividsolutions.com/jts/jtshome.htm
> [5]
> http://www.gaia-gis.it/spatialite/spatialite-manual-2.3.1.html#t3.3
> _______________________________________________ Gvsig_internacional
> mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.