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

[Benjamin Ducke]

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.