[Gvsig_english] New Student for GVSIG within Google Summer OfCode2010: quick introduction
Benjamin Ducke
benjamin.ducke at oxfordarch.co.uk
Mon May 17 11:25:16 CEST 2010
Hi Juan Lucas
>
> 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:
>
> https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite
>
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).
Cheers,
Ben
> 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
> http://www.prodevelop.es
> ---
>
>
> De: gvsig_internacional-bounces at listserv.gva.es 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
>
>
>
>
> >
> > Ben,
> >
> > you know for sure much better than me what would mean having
> problems
> > 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
> >
>
> 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
>
> > [1] http://www.iosa.it/blogs/luca
> > 2010/5/14 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>
> > 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:
> >
> > http://www.gdal.org/ogr/drv_sqlite.html
> >
> > 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" <jldominguez at prodevelop.es>
> > To: "Users and Developers mailing list"
> > <gvsig_internacional at listserv.gva.es>, "Gvsig internacional"
> > <Gvsig_internacional at listserv.gva.es>
> > Sent: Friday, May 14, 2010 2:38:44 PM GMT +01:00 Amsterdam / Berlin
> /
> > 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
> (Android
> > supports SQlite too).
> >
> > I was wondering: what is the simplest Sqlite database that can be
> read
> > and processed from Spatialite? Let's suppose I have a Sqlite
> database
> > 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)?
> This
> > 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
> > http://www.prodevelop.es
> > ---
> >
> >
> > De: gvsig_internacional-bounces at listserv.gva.es en nombre de luca
> > bianconi
> > Enviado el: jue 06/05/2010 15:17
> > Para: Gvsig_internacional at listserv.gva.es
> > Asunto: [Gvsig_english] New Student for GVSIG within Google Summer
> Of
> > 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
> gvSig
> > 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
> > _______________________________________________
> > 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.
>
> _______________________________________________
> 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.
More information about the Gvsig_internacional
mailing list