Ok,<br><br>during the weekend I've started the implementation of a "sqlite spatial" class according to FDO specifications (<a href="http://trac.osgeo.org/fdo/wiki/FDORfc16" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc16</a>).<br>
<br>Thanks for the suggestions,<br>Luca<br><br><div class="gmail_quote">2010/6/11 Benjamin Ducke <span dir="ltr"><<a href="mailto:benjamin.ducke@oxfordarch.co.uk">benjamin.ducke@oxfordarch.co.uk</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Good point.<br>
<br>
When the features are read in from BLOBs, their coordinates<br>
can be checked and filtered. So the spatial index is not absolutely<br>
necessary -- but it would certainly speed up the operation a lot!<br>
<br>
So it would be good to be make use of spatial indices for SpatiaLite<br>
format geometries.<br>
<br>
The "raw" WKB/WKT format (<a href="http://trac.osgeo.org/fdo/wiki/FDORfc16" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc16</a>)<br>
does not include a proposal for a stored spatial index. Instead,<br>
it suggests to build the index in memory the first time a spatial<br>
filter is run on the data.<br>
<br>
Ben<br>
<div><div></div><div class="h5"><br>
----- Original Message -----<br>
> > The SpatiaLite format as such has no particular advantage in a gvSIG<br>
> > context. SpatiaLite implements things such as topology queries and<br>
> > spatial indices. But gvSIG already has all of that, so no need to<br>
> > reinvent those things!<br>
><br>
> Being able to use the spatial indexes provided by the DB is important!<br>
> For example, how do you select only the features needed by a certain<br>
> viewport? For example, the OracleSpatial driver select statement asks<br>
> for features through a spatial filter (sdo_filter and sdo_relate)<br>
> which uses the oracle internal spatial index...<br>
><br>
> Giovanni<br>
><br>
><br>
> ><br>
> ><br>
> ><br>
> > ----- Original Message -----<br>
> >> Hi all,<br>
> >><br>
> >> I'd like discussing a couple of things with you after all the tests<br>
> >> I've done during this first time past for finding out which was the<br>
> >> most reasonable approach to get SQLite and SpatiaLite support into<br>
> >> gvSIG.<br>
> >><br>
> >> Brief introduction:<br>
> >><br>
> >> I've tested all the approaches and resources we've discussed [1]<br>
> >> and all those I could find asking around and scanning the web.<br>
> >><br>
> >> Results:<br>
> >><br>
> >> SQLITE SUPPORT<br>
> >><br>
> >> - The Xerial SQLite driver[2], derived from the Zentus'one [3],<br>
> >> developed and mantained by Taro L. Saito of the University of Tokyo<br>
> >> looks to be the most suitable for accomplishing our tasks.<br>
> >><br>
> >> The reasons are mainly:<br>
> >> - it's kept updated and recompiled with every new version of SQLite<br>
> >> - it has some improvements and some fixing<br>
> >> - you need to include in your project just one file<br>
> >> (sqlite-jdbc.jar) in order to use it<br>
> >> - as far as it's a java jar it's multiplatform<br>
> >><br>
> >> SPATIALITE<br>
> >> - you can import the libspatialite.* file (according to your<br>
> >> system) with Xerial sqlite-JDBC driver(see above)[2] and reading<br>
> >> data from a<br>
> >> SpatiaLite database<br>
> >> - I've found many bugs in doing Spatialite's operations (due<br>
> >> probably<br>
> >> to bugs in memory handling of SpatiaLite functions into<br>
> >> java-driver): that means I can do any SELECT with SpatiaLite's<br>
> >> functions (I've<br>
> >> tested many of them) retrieving the data I want BUT with a silly<br>
> >> workaround that avoids the crash of the JVM (usually in connection<br>
> >> closing / statment reset)<br>
> >> - I can't write data at the moment (I've found no<br>
> >> workarounds/fixing yet) because of other errors in memory handling.<br>
> >> I've got in touch with Taro L. Saito but I guess he has not found<br>
> >> any fixing for that segmentation fault.<br>
> >> I will try to write him again hoping he has time to fix this<br>
> >> problem.<br>
> >><br>
> >> CONCLUSIONS<br>
> >><br>
> >> I guess that thanks to SQLite-JDBC driver [2] including SQLite<br>
> >> support into gvSIG should be quite quick (Cèsar has suggested me to<br>
> >> see the<br>
> >> libFMap_daldb for understanding how MySQL, etc are already<br>
> >> supported in our application).<br>
> >><br>
> >> SpatiaLite support needs to be discussed a little bit because the<br>
> >> reading it's quite straightforward (keeping in mind we can make it<br>
> >> work with a workaround. That's not proper but as a temporary<br>
> >> solution could be partially acceptable), including the proper<br>
> >> library (according to OS and architecture) thanks to the<br>
> >> SQLite-JDBC driver as<br>
> >> well.<br>
> >><br>
> >> SOLUTION I PROPOSE ABOUT SPATIALITE<br>
> >><br>
> >> Well, I'd need hearing your ideas about this matter anyway and<br>
> >> discuss together about which whould be the better way to get<br>
> >> spatialite support.<br>
> >><br>
> >> However I've a proposal to get finally a much better work in my<br>
> >> opinion: I've almost finished the code for decoding the SPATIALITE<br>
> >> BLOB[5] (that's the particular structure that stores every<br>
> >> Spatialite infos) and I guess the better thing would be<br>
> >> implementing a Java<br>
> >> version of SpatiaLite or at least of its most common<br>
> >> functionalities. For many of them we could have help from JTS[4]<br>
> >> (as partially<br>
> >> suggested by Juan Lucas [1]).<br>
> >><br>
> >><br>
> >> Firstly it would let us having just one file (a common java jar)<br>
> >> for every OS and architecture, instead of having a lib file for<br>
> >> each most<br>
> >> common machine.<br>
> >> It would avoid the necessity of trying to wrap a C lib into a JAVA<br>
> >> interface with all the problems we have already with the memory<br>
> >> handling in importing libspatialite.* into the already fully<br>
> >> working driver [2].<br>
> >> It would take some time BUT finally we will have a much cleaner and<br>
> >> multiplatform solution.<br>
> >><br>
> >> Sorry for the maybe too long paper,<br>
> >><br>
> >> Cheers,<br>
> >><br>
> >> Luca<br>
> >><br>
> >> [1]<br>
> >> <a href="http://osgeo-org.1803224.n2.nabble.com/New-Student-for-GVSIG-within-Google-Summer-Of-Code-2010-quick-introduction-td5014112.html#a5014112" target="_blank">http://osgeo-org.1803224.n2.nabble.com/New-Student-for-GVSIG-within-Google-Summer-Of-Code-2010-quick-introduction-td5014112.html#a5014112</a><br>
> >> [2] <a href="http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC" target="_blank">http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC</a><br>
> >> [3] <a href="http://www.zentus.com/sqlitejdbc/" target="_blank">http://www.zentus.com/sqlitejdbc/</a><br>
> >> [4] <a href="http://www.vividsolutions.com/jts/jtshome.htm" target="_blank">http://www.vividsolutions.com/jts/jtshome.htm</a><br>
> >> [5]<br>
> >> <a href="http://www.gaia-gis.it/spatialite/spatialite-manual-2.3.1.html#t3.3" target="_blank">http://www.gaia-gis.it/spatialite/spatialite-manual-2.3.1.html#t3.3</a><br>
> >> _______________________________________________ Gvsig_internacional<br>
> >> mailing list<br>
> >> <a href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a><br>
> >> <a href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional" target="_blank">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</a><br>
> ><br>
> ><br>
> > ------ Files attached to this email may be in ISO 26300 format<br>
> > (OASIS Open Document Format). If you have difficulty opening them,<br>
> > please visit <a href="http://iso26300.info" target="_blank">http://iso26300.info</a> for more information.<br>
> ><br>
> > _______________________________________________ Gvsig_internacional<br>
> > mailing list<br>
> > <a href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a><br>
> > <a href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional" target="_blank">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</a><br>
> ><br>
> _______________________________________________ Gvsig_internacional<br>
> mailing list<br>
> <a href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a><br>
> <a href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional" target="_blank">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</a><br>
<br>
<br>
------<br>
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit <a href="http://iso26300.info" target="_blank">http://iso26300.info</a> for more information.<br>
<br>
_______________________________________________<br>
Gvsig_internacional mailing list<br>
<a href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a><br>
<a href="http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional" target="_blank">http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional</a><br>
</div></div></blockquote></div><br>