[Gvsig_english] New Student for GVSIG within Google Summer OfCode2010: quick introduction

[Cèsar Ordiñana]

Hi Ben,

Yes, I think so. The simple model will let Luca learn about gvSIG 
development and have something to be able to play with in less time.

Regards,

-- 
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)



Benjamin Ducke escribió:
> Cesar,
>
> excellent point. SpatiaLite's indexing is maybe it's most important
> advantage for our use.
>
> But I think we all agree that it would make sense for Luca to first
> do the simple WKB/WKT storage model and then start working on the
> SpatiaLite support? Depending on time, as you say, he may or may not
> be able to finish it within this year's GSoC.
>
> Cheers,
>
> Ben
>
> ----- Original Message -----
> From: "Cèsar Ordiñana" <cordinyana at gvsig.com>
> To: "Users and Developers mailing list" <gvsig_internacional at listserv.gva.es>
> Sent: Monday, May 17, 2010 1:51:56 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> Subject: Re: [Gvsig_english] New Student for GVSIG within Google Summer OfCode2010: quick introduction
>
>
> Hi Ben, 
>
> Benjamin Ducke escribió: 
>
> 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). 
> 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. 
>
> 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. 
>
> 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. 
>
> 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. 
>
> Regards, 
>