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

Tue Jun 15 10:21:38 CEST 2010

Ok,

during the weekend I've started the implementation of a "sqlite spatial"
class according to FDO specifications (
http://trac.osgeo.org/fdo/wiki/FDORfc16).

Thanks for the suggestions,
Luca

2010/6/11 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>

> Good point.
>
> When the features are read in from BLOBs, their coordinates
> can be checked and filtered. So the spatial index is not absolutely
> necessary -- but it would certainly speed up the operation a lot!
>
> So it would be good to be make use of spatial indices for SpatiaLite
> format geometries.
>
> The "raw" WKB/WKT format (http://trac.osgeo.org/fdo/wiki/FDORfc16)
> does not include a proposal for a stored spatial index. Instead,
> it suggests to build the index in memory the first time a spatial
> filter is run on the data.
>
> Ben
>
> ----- Original Message -----
> > > 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!
> >
> > Being able to use the spatial indexes provided by the DB is important!
> > For example, how do you select only the features needed by a certain
> > viewport? For example, the OracleSpatial driver select statement asks
> > for features through a spatial filter (sdo_filter and sdo_relate)
> > which uses the oracle internal spatial index...
> >
> > Giovanni
> >
> >
> > >
> > >
> > >
> > > ----- 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.
> > >
> > > _______________________________________________ Gvsig_internacional
> > > mailing list
> > > Gvsig_internacional at listserv.gva.es
> > > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> > >
> > _______________________________________________ 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.
>
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100615/fa0c9dc4/attachment.htm 