Hi Ben, <br><br>I like your idea frankly.<br>Starting with a simpler but working solution and only after looking for something more complex.<br><br>I agree the idea of avoiding "JNI pains".<br><br>Ciao and thanks a lot,<br>
Luca<br><br><br><div class="gmail_quote">2010/5/17 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;">
<div class="im">><br>
> 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>
</div>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>
<div><div></div><div class="h5"><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>
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>