GvSIG GSoC 2010 Ideas

From OSGeo
Jump to navigation Jump to search

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

Proposed mentor: Francisco José Peñarrubia

  • Import / Export data from Epanet: 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 .

Proposed mentor: Carlos Sánchez Periñán

  • KML 2.2 support for gvsig-gpe: 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]

Proposed mentor: Benjamin Ducke

  • Support for SQLite3/SpatiaLite: 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)

gvSIG Mobile

  • Add support of WMS-C and other tile services like OSM
  • Fill shapes with holes

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!

Retrieved from "http://wiki.osgeo.org/w/index.php?title=GvSIG_GSoC_2010_Ideas&oldid=46604"