GvSIG GSoC 2010 Ideas

There's been a general call for ideas, mentors and students a gvSIG mailing list. If you have an idea, please feel free to add it here, as much detailed as possible. If you have any doubt, please refer to the general Google Summer of Code 2010 main wiki page or Jorge Sanz.

gvSIG Desktop

Import / Export data from Epanet

Proposed mentor: Francisco José Peñarrubia

The idea is to define a layer model suitable to be exported to Epanet's .inp file, and a geoprocess to export this model to Epanet. So, we will need to define pipes, wells, valves, depots and so on in gvSIG, analize connectivity and then export to Epanet. From Epanet, to analyze and modify the network and then export the network again to gvSIG. So, the main tasks are: Define layer model , Create a geoprocess exporter to .INP , Create a geoprocess importer back to gvSIG .

KML 2.2 support for gvsig-gpe

Proposed mentor: Carlos Sánchez Periñán

gvsig-gpe is a library for reading and writing data based on the GML format, through the use of events. It does not depend on any geometry data model, providing the raw data to the application. Initially developed for the GML format, it supports readers and writers for KML 2.1 formats. The project consist on develop a new plugin org.gvsig.gpe.kml2 for gvsig-gpe or complete the existing one adding the new KML 2.2 specification. The event's handled by the API also can be extended to support the Google KML file symbology referenced. Summary: -Add new KML 2.2 tags specification to the reader into org.gvsig.gpe.kml -Add the new updated KML 2.2 writer too -Add new events to store other KML information or lauch it to the user OSOR gvsig-gpe repository [1]

Support for SQLite3/SpatiaLite

Proposed mentor: Benjamin Ducke

SQlite3 [2] is a cross-plattform, fast and simple file-based DBMS. Currently, gvSIG has nothing to offer for those users that want to have a fully functional and fast desktop DBMS backend, without having to install (and manage) a full client/server system. SQlite3 could ideally fill that gap, being a far superior alternative to DBF and ODBC. SQlite3 can also store geometries (WKB and WKT) in an OGC-conformant manner. The GDAL/OGR driver page for SQLite3 details how this should be done. In addition, the SpatiaLite [3] project provides optimized geometry storage plus topological SQL query functions. This looks very much like the emerging open source standard to replace those awful Shapefiles. Quantum GIS and OpenJUMP already have direct support for it and this makes having it in gvSIG all the more important. Much code could be borrowed from OpenJUMP, which is also Java based and already has working SQlite/SpatiaLite support. This should be implemented for gvSIG 2.0, as the data storage model has changed fundamentally in this code branch.

Work plan: -Add an SQLite3 driver for plain tables -Add support for SpatiaLite vector layers (read and write)

Sync gvSIG view with gmaps/osm...

Proposed mentor: Nacho Varela

Create a gvSIG extension that allows to open an integrated web browser and show geographic info from google maps, openstreetmap, etc.. synchronized with the current view (zoom, pan, etc).

New fetaures for NavTable

Proposed mentor: Pablo Sanxiao

Implement new features for NavTable: modify the table schema to make possible add, erase and modify attributes and also choose which ones will be shown in NavTable and which won't, order records by attributes, creating a system to separate the GUI of the personalized forms based in Xml (maybe using thinlet, abeille...)

Give support to OSM formats on gvSIG

Proposed mentor: ???

The idea is to give support any OSM formats on gvSIG:

1. . official API (actually on version 0.6). It's the official API to access to the vector information of the project in XML format. For this reason, it's not valid for great data volume. JOSM restricts the big downloads. Therefore it's the official format and the most widely used.
2. . OSM Binary Format. It's the API binary version. Being binary, it's perfect for optimizing the access to great data volume.
3. . OSM Mobile Binary Protocol. The equivalent of the previous one, but optimized for mobile devices. In this case, it would be interesting to add this format support to gvSIG Mobile.

gvSIG Mobile

• Add support of WMS-C and other tile services like OSM

• Add support of Versioned WFS: http://geoserver.org/display/GEOS/Versioning+WFS+-+Extensions

• Fill shapes with holes efficiently

gvSIG Mini

Proposed mentor: Alberto Romeu

gvSIG Mini is a free mobile map viewer of several layers sources (OSM, WMS, WMS-c) which at the moment is able to consume YOURS routing service and NameFinder service (also weather, twitter services, etc.).

gvSIG Mini is currently being developed by Prodevelop. There are two versions: for Android and J2ME (CLDC/MIDP 2.0). Students are free to select which version of gvSIG Mini want to develop for or use a subset of the Java API compatible between Android and J2ME to build a library and then make the connectors needed for both versions.

• Add support to read GPX files (POIs, tracklogs, routes): The application should be able to read/parse files in GPX format, convert the data into the gvSIG Mini geometries model (points and lines) and draw the information on a new layer.

• Add support to write GPX files (POIs, tracklogs, routes): The application should be able to write files in GPX format to store POIs, tracklogs and routes with the information provided by the GPS.

• Design an API to make easy integrate gvSIG Mini in other applications: For the Android version gvSIG Mini should be able to react to some Intent actions sent by other applications. For the J2ME version this project consists in decouple the mapping library from the UI.

• Integrate gvSIG Mini with social services: Currently gvSIG Mini is able to send the GPS location of the device to the user twitter account. We'd like to improve the social skills of gvSIG Mini, so the application should be able to look for location information into the user's followers tweets and draw picture symbols on the proper locations over the map. This symbols should be contextable so, pressing on them the user should be able to send a message to the account of the user represented by the symbol.

• Build a POI editor using the OSM API: Design a friendly interface to point locations on the map and edit the properties needed to store the location as a POI on the OSM database using its API.

We are open to new ideas!