[Gvsig_english] [GSoC] Mentoring a gvSIG GSoC idea

[Benjamin Ducke]

Thanks for all the pointers, people. It seems that at this
stage, Java support for SQlite3/SpatiaLite is growing in
many projects. There is another option that I find very
attractive. As of version 1.7, GDAL/OGR has newly
maintained Java bindings:

http://gdal.org/java/

If these turn out to be working (have not tested them
yet) I would actually think they are the best option
for geometry handling, because:

1) They support multiple ways of geometry storage in
an SQLite3 DBMS, not only the SpatiaLite format
(see here: http://www.gdal.org/ogr/drv_sqlite.html)

2) OGR has layer write support.

2) Once we have an implementation for SQlite3, we
can easily recycle the same classes to add more
OGR-supported data sources, such as MapInfo, etc.

For plain SQlite3 tables (no geometries), I would use
one of the two suggested JDBC drivers.

Cheers,

Ben

On 04/07/2010 01:18 PM, Rahkonen Jukka wrote:
>
> Hi,
>
> I have used two available spatialite plugins for OpenJUMP both with the zentus jdbc driver and this one from xerial:
>
> http://www.xerial.org/maven/repository/artifact/org/xerial/sqlite-jdbc/3.6.20.1/sqlite-jdbc-3.6.20.1.jar
>
> They both advertise to have a native Java option (slow) and native libraries for Windows, Linux and Mac, all included in the same jar.
>
> -Jukka Rahkonen-
>
>
> Cèsar Ordiñana wrote:
>  
>> Hi Fran and Ben,
>
>> If you need some help with the Data Access Layer in gvSIG 2.0, I can 
> offer myself too.
>
>> If there exists a working JDBC driver for sqlite/spatialite, it should 
> not take too much effort to develop the new provider. In gvSIG 2.0 there 
> is a generic JDBC provider, which is extended by the postgreSQL/Postgis 
> provider (and the other jdbc based providers) which can be used as a 
> base to develop the sqlite/spatialite provider.
>
>> I have found a JDBC driver project for sqlite 
> (http://www.zentus.com/sqlitejdbc/), but don't know if it works with 
> spatialite.
>
>> But if the JDBC option is not available, we should revert to JNI, in 
> which case the project will require a lot more effort, may be too much 
> for the 3 months period.
>
> Regards,
>
> Francisco José Peñarrubia escribió:
>> Hi Ben and Jukka.
>>
>> I don't know much about Data Access Layer in gvSIG 2.0, but I think for 
>> this summer I will .... or at least, I can ask other people here about 
>> it ;-).
>>
>> I can offer myself to co-mentor this project.
>>
>> Best regards.
>>
>> Fran Peñarrubia
>> www.scolab.es
>>
>> Rahkonen Jukka escribió:
>>   
>>> Hi,
>>>
>>> There is something about Spatialite and OpenJUMP at
>>> http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUM
>>> P_with_SpatialLite
>>>
>>> It might be worth having a look.
>>>
>>> -Jukka Rahkonen-
>>>
>>> Benjamin Ducke wrote:
>>>
>>>   
>>>     
>>>> Yes, it would be good if someone could co-mentor
>>>>     
>>>>       
>>> this with me. I know SQLite3 quite well, but do
>>> not have any experience with the gvSIG 2.0 data
>>> access layer yet.
>>>
>>> Cheers
>>>
>>> ----- Original Message -----
>>> From: "Miguel Montesinos" <mmontesinos at prodevelop.es>
>>> To: "Users and Developers mailing list"
>>> <gvsig_internacional at listserv.gva.es>
>>> Sent: Monday, April 5, 2010 8:47:08 PM GMT +01:00 Amsterdam / Berlin /
>>> Bern / Rome / Stockholm / Vienna
>>> Subject: Re: [Gvsig_english] [GSoC] Mentoring a gvSIG GSoC idea
>>>
>>> Hi,
>>>
>>> Some tests have been done in the past with H2, but SQLite3 would be
>>> great. We have to coordinate GSoC proposals ASAP.
>>>
>>> Cheers,
>>>
>>> Miguel Montesinos
>>>
>>>
>>> -----Mensaje original-----
>>> De: gvsig_internacional-bounces at listserv.gva.es en nombre de silvio
>>> grosso
>>> Enviado el: vie 02/04/2010 9:23
>>> Para: Users and Developers mailing list
>>> Asunto: Re: [Gvsig_english] [GSoC] Mentoring a gvSIG GSoC idea
>>>  
>>> Hi Ben,
>>>
>>>   
>>>     
>>>> Benjamin Ducke wrote:
>>>>     
>>>>       
>>>   
>>>     
>>>> I'd like to mentor a student (and I probably have a 
>>>> candidate,already) to implement support for SQlite3 tables (both 
>>>> simple tables and spatial tables) in gvSIG.
>>>>     
>>>>       
>>> WOW!!! 
>>> I am sure SpatiaLite support would be really a Must for gvSIG 2. 
>>> Not to mention that other Open Source GIS already support it ;-)
>>>
>>> Best regards,
>>>
>>> Silvio
>>>
>>>
>>>
>>>       
>>> _______________________________________________
>>> 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
>>>   
>>>     
>>
>> _______________________________________________
>> 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.