Hi Francisco,<br><br>thanks for your help!<br>It would be great taking in account all the possibilities we have to solve the problem before chosing the best solution to be developed!<br><br>If you could get further explanations from Nacho it would very interesting anyway!<br>
<br>Cheers,<br>Luca<br><br><br><div class="gmail_quote">2010/5/17 Francisco José Peñarrubia <span dir="ltr"><<a href="mailto:fpenarru@gmail.com">fpenarru@gmail.com</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;">
Hi Ben and Luca.<br>
<br>
Not many people is aware of this, but.... Nacho Brodin, one of the main<br>
developers of raster support in gvSIG told me some time ago that he did<br>
some work related to support OGR bindings from GDAL<br>
(<a href="http://www.gdal.org/ogr/" target="_blank">http://www.gdal.org/ogr/</a>).<br>
The idea is great, gvSIG will be able to support a lot of formats with<br>
only one library....among them, you can find SQLite Spatial format:<br>
<a href="http://www.gdal.org/ogr/ogr_formats.html" target="_blank">http://www.gdal.org/ogr/ogr_formats.html</a><br>
<br>
As far as I know, Nacho was able to do it, but the results were poor in<br>
order of speed.<br>
<br>
Maybe Nacho can explain better than me his results. If this is true, I<br>
think it would be interesting to have some tests in order to decide if<br>
you go JNI way or pure Java way.<br>
<br>
Best regards.<br>
<br>
Fran.<br>
<br>
Benjamin Ducke escribió:<br>
<div><div></div><div class="h5">>> Ben,<br>
>><br>
>> you know for sure much better than me what would mean having problems<br>
>> with wrapping of C API so if we will have too much pain with<br>
>> SpatiaLite it could be perfect use the plain WKT/WKB. I've given a<br>
>> glance to the link you've suggested but I should read it better for<br>
>> understanding what it means on the development point of view.<br>
>><br>
>> Ciao,<br>
>> Luca<br>
>><br>
>><br>
><br>
> I think for a first stage implementation, the simple WKB/WKT<br>
> storage model is probably best. Others can always be added later<br>
> using the new GDAL 1.7 java bindings. That way, you shouldn't<br>
> have to worry about maintaining your own JNI stuff (which can<br>
> be a real pain).<br>
><br>
> Give users the choice to use WKB (more compact) or WKT (more<br>
> easy to parse) when storing geometries. When reading, the<br>
> format should be auto-detected.<br>
><br>
> Let me know if you have any problems understanding anything.<br>
> I can send you a little sample SQLite3 database with some WKB/WKT<br>
> tables for illustration. I produced them in GRASS GIS using the<br>
> GDAL/OGR drivers.<br>
><br>
> But maybe start by adding plain SQLite3 non-spatial tables as<br>
> a new project document type first. And then work towards spatial<br>
> tables from there -- to keep things a little more simple for you<br>
> at the start!<br>
><br>
> Best,<br>
><br>
> Ben<br>
><br>
><br>
>> [1]<a href="http://www.iosa.it/blogs/luca" target="_blank">http://www.iosa.it/blogs/luca</a><br>
>> 2010/5/14 Benjamin Ducke <<a href="mailto:benjamin.ducke@oxfordarch.co.uk">benjamin.ducke@oxfordarch.co.uk</a>><br>
>> Hi Juan, Luca<br>
>><br>
>> That question is not so rhetorical, actually!<br>
>> There are several ways of storing spatial data in an SQLite3<br>
>> database, that are all in use by some software:<br>
>><br>
>> <a href="http://www.gdal.org/ogr/drv_sqlite.html" target="_blank">http://www.gdal.org/ogr/drv_sqlite.html</a><br>
>><br>
>> One of them is a simple WKT/WKB storage model that is also nicely<br>
>> documented (see link above).<br>
>><br>
>> So if SpatiaLite is too much pain, because of the need to wrap the<br>
>> C API, then we can just use the plain WKT/WKB storage for our<br>
>> purposes.<br>
>> It's supported by GDAL/OGR, so we lose only the special SpatiaLite<br>
>> functionality.<br>
>><br>
>> Cheers,<br>
>><br>
>> Ben<br>
>><br>
>> ----- Original Message -----<br>
>> From: "Juan Lucas Dominguez Rubio" <<a href="mailto:jldominguez@prodevelop.es">jldominguez@prodevelop.es</a>><br>
>> To: "Users and Developers mailing list"<br>
>> <<a href="mailto:gvsig_internacional@listserv.gva.es">gvsig_internacional@listserv.gva.es</a>>, "Gvsig internacional"<br>
>> <<a href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a>><br>
>> Sent: Friday, May 14, 2010 2:38:44 PM GMT +01:00 Amsterdam / Berlin /<br>
>> Bern / Rome / Stockholm / Vienna<br>
>> Subject: Re: [Gvsig_english] New Student for GVSIG within Google<br>
>> Summer Of Code2010: quick introduction<br>
>><br>
>><br>
>><br>
>><br>
>> Ciao, Luca.<br>
>><br>
>> I too think Spatialite is a very interesting way to store and share<br>
>> GIS data, especially because its simplicity fits mobile devices very<br>
>> well.<br>
>><br>
>> I know a pure-Java version of SQLite (not Spatialite) which will<br>
>> probably work on a wide range of Java-enabled mobile devices (Android<br>
>> supports SQlite too).<br>
>><br>
>> I was wondering: what is the simplest Sqlite database that can be read<br>
>> and processed from Spatialite? Let's suppose I have a Sqlite database<br>
>> file with only one table and one of the columns of that table is of<br>
>> binary type (BLOB or similar), and that column contains some WKB<br>
>> describing a geometry. Would this be enough to open it from a<br>
>> Spatialite-enabled application (for example gvSIG in the future)? This<br>
>> is rather a rhetorical question... I need to look into it myself :)<br>
>><br>
>> Can we see your progresses online? blog? SVN?<br>
>><br>
>> Regards,<br>
>><br>
>><br>
>> Juan Lucas Domínguez Rubio<br>
>> ---<br>
>> Prodevelop SL, Valencia (España)<br>
>><br>
>> Tlf.: 96.351.06.12 -- Fax: 96.351.09.68<br>
>> <a href="http://www.prodevelop.es" target="_blank">http://www.prodevelop.es</a><br>
>> ---<br>
>><br>
>><br>
>> De: <a href="mailto:gvsig_internacional-bounces@listserv.gva.es">gvsig_internacional-bounces@listserv.gva.es</a> en nombre de luca<br>
>> bianconi<br>
>> Enviado el: jue 06/05/2010 15:17<br>
>> Para: <a href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a><br>
>> Asunto: [Gvsig_english] New Student for GVSIG within Google Summer Of<br>
>> Code2010: quick introduction<br>
>><br>
>><br>
>> Hello gvsig-international mailing list,<br>
>><br>
>> sorry for sending this email as a kind of spamming, I'd like just to<br>
>> introduce myself quickly to the whole list.<br>
>><br>
>> My name is Luca Bianconi and I'm the "student" working with the gvSig<br>
>> team for the Google Summer of Code 2010.<br>
>> Our task is implementing the gvSig support for SQlite and SpatiaLite<br>
>> and I'll do my best for doing it.<br>
>><br>
>> I'd like to say my "Hello" to everybody and I thank you all for the<br>
>> help you will be able to provide when we will be up to the<br>
>> implementation phase both in comments and suggestions!<br>
>><br>
>> Nice to meet you all,<br>
>> Cheers,<br>
>> Luca<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>
>><br>
>> ------<br>
>> Files attached to this email may be in ISO 26300 format (OASIS Open<br>
>> Document Format). If you have difficulty opening them, please visit<br>
>> <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>
>><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>
>><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>
><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>