<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Ben,<br>
<br>
Benjamin Ducke escribió:
<blockquote
 cite="mid:127351146.323371274088316143.JavaMail.root@mail.thehumanjourney.net"
 type="cite">
  <pre wrap="">Hi Juan Lucas

  </pre>
  <blockquote type="cite">
    <pre wrap="">As for Luca's project, I think JNI (on top of OGR or
SQLite/Spatialite) is unavoidable, no? OpenJUMP's plugin might be a
reference, as somebody said. They are using a JAR that includes a
native library (.dll, .so) in it:

<a class="moz-txt-link-freetext" href="https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite">https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Thanks for the link. There will certainly be interesting information
in there.

If we go for the simple WKB/WKT storage model, then Luca could model
his work on the existing code for the PostGIS driver and avoid having
to use JNI, at least until support for the native SpatiaLite format
is required (but then that can still be done via the existing 
GDAL/OGR driver bindings).
  </pre>
</blockquote>
<br>
I agree the simple model may be interesting, as a way to be able to
work with existing sqlite databases or even as a first phase of
development. <br>
<br>
That work should be quite quick and easy, as there is a base
implementation for JDBC based DAL providers, and our current Postgis
and Mysql providers are already reading and writing geometries in WKB
format by themselves, so they are good examples to start from.<br>
<br>
But I think we shall go to the full spatialite support. gvSIG needs
support for a local personal database, for many uses (cache, temporal
storage, etc.), and we still haven't one because the java based ones
(HSQLDB, etc.) doesn't have proper spatial support. With spatial
support I mean, above all, spatial indexes support, or I fear
performance will suffer badly. <br>
<br>
I don't know if that work is too much to be done in the period
available for Luca in the GsC, and should be continued in the next
year's GsC, or by some other volunteer/s, but I would like to stress
the importance of having spatialite support, at least at spatial
indexes level.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">-- 
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (<a class="moz-txt-link-freetext" href="http://www.disid.com">http://www.disid.com</a>)</pre>
<br>
<br>
<blockquote
 cite="mid:127351146.323371274088316143.JavaMail.root@mail.thehumanjourney.net"
 type="cite">
  <pre wrap="">
Cheers,

Ben

  </pre>
  <blockquote type="cite">
    <pre wrap="">Nacho's work sounds very interesting too.

Regards,


Juan Lucas Domínguez Rubio
---
Prodevelop SL, Valencia (España)

Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
<a class="moz-txt-link-freetext" href="http://www.prodevelop.es">http://www.prodevelop.es</a>
---


De: <a class="moz-txt-link-abbreviated" href="mailto:gvsig_internacional-bounces@listserv.gva.es">gvsig_internacional-bounces@listserv.gva.es</a> en nombre de Benjamin
Ducke
Enviado el: lun 17/05/2010 9:28
Para: Users and Developers mailing list
Asunto: Re: [Gvsig_english] New Student for GVSIG within Google Summer
OfCode2010: quick introduction




    </pre>
    <blockquote type="cite">
      <pre wrap="">Ben,

you know for sure much better than me what would mean having
      </pre>
    </blockquote>
    <pre wrap="">problems
    </pre>
    <blockquote type="cite">
      <pre wrap="">with wrapping of C API so if we will have too much pain with
SpatiaLite it could be perfect use the plain WKT/WKB. I've given a
glance to the link you've suggested but I should read it better for
understanding what it means on the development point of view.

Ciao,
Luca

      </pre>
    </blockquote>
    <pre wrap="">I think for a first stage implementation, the simple WKB/WKT
storage model is probably best. Others can always be added later
using the new GDAL 1.7 java bindings. That way, you shouldn't
have to worry about maintaining your own JNI stuff (which can
be a real pain).

Give users the choice to use WKB (more compact) or WKT (more
easy to parse) when storing geometries. When reading, the
format should be auto-detected.

Let me know if you have any problems understanding anything.
I can send you a little sample SQLite3 database with some WKB/WKT
tables for illustration. I produced them in GRASS GIS using the
GDAL/OGR drivers.

But maybe start by adding plain SQLite3 non-spatial tables as
a new project document type first. And then work towards spatial
tables from there -- to keep things a little more simple for you
at the start!

Best,

Ben

    </pre>
    <blockquote type="cite">
      <pre wrap="">[1] <a class="moz-txt-link-freetext" href="http://www.iosa.it/blogs/luca">http://www.iosa.it/blogs/luca</a>
2010/5/14 Benjamin Ducke <a class="moz-txt-link-rfc2396E" href="mailto:benjamin.ducke@oxfordarch.co.uk">&lt;benjamin.ducke@oxfordarch.co.uk&gt;</a>
Hi Juan, Luca

That question is not so rhetorical, actually!
There are several ways of storing spatial data in an SQLite3
database, that are all in use by some software:

<a class="moz-txt-link-freetext" href="http://www.gdal.org/ogr/drv_sqlite.html">http://www.gdal.org/ogr/drv_sqlite.html</a>

One of them is a simple WKT/WKB storage model that is also nicely
documented (see link above).

So if SpatiaLite is too much pain, because of the need to wrap the
C API, then we can just use the plain WKT/WKB storage for our
purposes.
It's supported by GDAL/OGR, so we lose only the special SpatiaLite
functionality.

Cheers,

Ben

----- Original Message -----
From: "Juan Lucas Dominguez Rubio" <a class="moz-txt-link-rfc2396E" href="mailto:jldominguez@prodevelop.es">&lt;jldominguez@prodevelop.es&gt;</a>
To: "Users and Developers mailing list"
<a class="moz-txt-link-rfc2396E" href="mailto:gvsig_internacional@listserv.gva.es">&lt;gvsig_internacional@listserv.gva.es&gt;</a>, "Gvsig internacional"
<a class="moz-txt-link-rfc2396E" href="mailto:Gvsig_internacional@listserv.gva.es">&lt;Gvsig_internacional@listserv.gva.es&gt;</a>
Sent: Friday, May 14, 2010 2:38:44 PM GMT +01:00 Amsterdam / Berlin
      </pre>
    </blockquote>
    <pre wrap="">/
    </pre>
    <blockquote type="cite">
      <pre wrap="">Bern / Rome / Stockholm / Vienna
Subject: Re: [Gvsig_english] New Student for GVSIG within Google
Summer Of Code2010: quick introduction




Ciao, Luca.

I too think Spatialite is a very interesting way to store and share
GIS data, especially because its simplicity fits mobile devices very
well.

I know a pure-Java version of SQLite (not Spatialite) which will
probably work on a wide range of Java-enabled mobile devices
      </pre>
    </blockquote>
    <pre wrap="">(Android
    </pre>
    <blockquote type="cite">
      <pre wrap="">supports SQlite too).

I was wondering: what is the simplest Sqlite database that can be
      </pre>
    </blockquote>
    <pre wrap="">read
    </pre>
    <blockquote type="cite">
      <pre wrap="">and processed from Spatialite? Let's suppose I have a Sqlite
      </pre>
    </blockquote>
    <pre wrap="">database
    </pre>
    <blockquote type="cite">
      <pre wrap="">file with only one table and one of the columns of that table is of
binary type (BLOB or similar), and that column contains some WKB
describing a geometry. Would this be enough to open it from a
Spatialite-enabled application (for example gvSIG in the future)?
      </pre>
    </blockquote>
    <pre wrap="">This
    </pre>
    <blockquote type="cite">
      <pre wrap="">is rather a rhetorical question... I need to look into it myself :)

Can we see your progresses online? blog? SVN?

Regards,


Juan Lucas Domínguez Rubio
---
Prodevelop SL, Valencia (España)

Tlf.: 96.351.06.12 -- Fax: 96.351.09.68
<a class="moz-txt-link-freetext" href="http://www.prodevelop.es">http://www.prodevelop.es</a>
---


De: <a class="moz-txt-link-abbreviated" href="mailto:gvsig_internacional-bounces@listserv.gva.es">gvsig_internacional-bounces@listserv.gva.es</a> en nombre de luca
bianconi
Enviado el: jue 06/05/2010 15:17
Para: <a class="moz-txt-link-abbreviated" href="mailto:Gvsig_internacional@listserv.gva.es">Gvsig_internacional@listserv.gva.es</a>
Asunto: [Gvsig_english] New Student for GVSIG within Google Summer
      </pre>
    </blockquote>
    <pre wrap="">Of
    </pre>
    <blockquote type="cite">
      <pre wrap="">Code2010: quick introduction


Hello gvsig-international mailing list,

sorry for sending this email as a kind of spamming, I'd like just to
introduce myself quickly to the whole list.

My name is Luca Bianconi and I'm the "student" working with the
      </pre>
    </blockquote>
    <pre wrap="">gvSig
    </pre>
    <blockquote type="cite">
      <pre wrap="">team for the Google Summer of Code 2010.
Our task is implementing the gvSig support for SQlite and SpatiaLite
and I'll do my best for doing it.

I'd like to say my "Hello" to everybody and I thank you all for the
help you will be able to provide when we will be up to the
implementation phase both in comments and suggestions!

Nice to meet you all,
Cheers,
Luca
_______________________________________________
      </pre>
    </blockquote>
  </blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>