Difference between revisions of "GvSIG GSoC 2010 Ideas"

From OSGeo
Jump to navigation Jump to search
 
(30 intermediate revisions by 7 users not shown)
Line 4: Line 4:
  
 
== gvSIG Desktop ==
 
== gvSIG Desktop ==
 +
 +
=== Import / Export data from Epanet ===
  
 
Proposed mentor: [[User:fpenarru | Francisco José Peñarrubia]]
 
Proposed mentor: [[User:fpenarru | 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 ''.
+
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: [[User:csancehz | Carlos Sánchez Periñán]]
 
Proposed mentor: [[User:csancehz | 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.  
+
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:  
 
Summary:  
 
-''Add new KML 2.2 tags specification to the reader into org.gvsig.gpe.kml''
 
-''Add new KML 2.2 tags specification to the reader into org.gvsig.gpe.kml''
Line 17: Line 22:
 
-''Add new events to store other KML information or lauch it to the user''
 
-''Add new events to store other KML information or lauch it to the user''
 
OSOR gvsig-gpe repository [https://www.osor.eu/projects/gvsig-gpe]
 
OSOR gvsig-gpe repository [https://www.osor.eu/projects/gvsig-gpe]
 +
 +
 +
=== Support for SQLite3/SpatiaLite ===
 +
 +
Proposed mentor: [[User:benducke | Benjamin Ducke]]
 +
 +
SQlite3 [http://www.sqlite.org] 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 [http://www.gaia-gis.it/spatialite/] 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: [[User:nachouve | 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: [[User:psanxiao | Pablo Sanxiao]]
 +
 +
Implement new features for [http://navtable.forge.osor.eu 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:
 +
 +
#. official API (actually on version [http://wiki.openstreetmap.org/wiki/API_v0.6 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.
 +
#. [http://wiki.openstreetmap.org/wiki/OSM_Binary_Format OSM Binary Format]. It's the API binary version. Being binary, it's perfect for optimizing the access to great data volume.
 +
#. [http://wiki.openstreetmap.org/wiki/OSM_Mobile_Binary_Protocol 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.
 +
 +
 +
=== Add support for WFS-T ===
 +
 +
Proposed mentor: [[User:jpiera | Jorge Piera]]
 +
 +
Add support for remote edition using WFS-T. WFS-T is a subset of requests/replies in the OCG WFS specification that allows remote edition of both alphanumerical and geometric attributes of a feature collection.
 +
 +
 +
=== Create a Title block Library in the gvSIG layout ===
 +
 +
Proposed mentor: [[Vicente Caballero]] (melange id: vcaballero)
 +
 +
The aim of the project is to extend the functionality of gvSIG Desktop layout, in order to add a library of configurable title blocks (this functionality has been demanded through the user mailing list of gvSIG).
 +
 +
The purpose is to reduce the repetitive and tedious work of creating title blocks on the layouts, which is so limited in the current version of gvSIG. It will be possible to configure text, images, divisions, size, font... and save them with an own format (gvb) for storaging and using them is future gvSIG works.
 +
 +
=== gvSIG as GDAL/OGR front-end ===
 +
 +
Proposed mentor: [[User:jvhigon | José Vicente Higón]]
 +
 +
One way to increase the functionallity of gvSIG is linking with other applications or libraries like GDAL/OGR.
 +
The main goal of this project would be the development of one front-end for GDAL/OGR command tools like gdal_translate, gdalwrap,
 +
gdaldem, ogr2ogr and so on. The development would consist in two parts. The first one would be a library for executing system processes in background, actually GDAL/OGR processes. The second one would consist of user interface development for wrapping the commands mentioned before.
 +
  
 
== gvSIG Mobile ==
 
== gvSIG Mobile ==
 +
 +
=== Add support of WMS-C and other tile services like OSM ===
 +
 +
Proposed mentor: ???
 +
 +
Accessing remote tiled map services allows the user to get updated maps from any part of the world inmediately. You can use those maps to locate yourself on an unknown city or to validate the features you are digitizing.
 +
 +
The project should include:
 +
 +
* Acessing tilecache, WMS-C and OSM
 +
* Cache of tiles
 +
* Drawing tiles as they come instead of drawing the map when all tiles are downloaded
 +
* Download of tiles while the user is panning (dragging) the map instead of downloading when the user releases
 +
* Concretize zoom levels of the application when a tiled layer is used
 +
 +
=== Add support of Versioned WFS===
 +
 +
Proposed mentor: ???
 +
 +
Editing in situ has a lot of advantages and some problems. One of the problems is the sinchronization of edits. Supose user A and user B are editing data from the same WFS-T. If both users download the same feature at the same time and both edit and store it back then some data will be lost.
 +
 +
With WFS versioning you can handle those situations and have the opportunity of have a look or even restore the state of every feature in any moment in the past.
 +
 +
Geoserver has done a test implementation of WFS versioning http://geoserver.org/display/GEOS/Versioning+WFS+-+Extensions
 +
 +
The project should include:
 +
 +
* Installing and testing Geoserver WFS versioning
 +
* Handling conflicts when uploading changes
 +
 +
Desirable:
 +
 +
* See log
 +
* Support of update to head
 +
* Support of rollback
 +
* Go to a specific version
 +
 +
=== Fill shapes with holes efficiently ===
 +
 +
Proposed mentor: ???
 +
 +
To draw a filled shape, gvSIG uses the Graphics2D.fill(Shape s) method. This paints the shape correctly even if it has holes or several disconnected areas.
 +
In CDC Personal Profile there is no Graphics2D so gvSIG Mobile is not able to draw shapes with holes.
 +
 +
The project should include:
 +
 +
* Study of different filling algorithms (floodfill and others)
 +
* Implement one software filling algorithm
 +
* Implement tringulation algorithm to split the area into polygons without holes and compare the performance
 +
 +
Desirable:
 +
 +
* Search for free implementations of JSR 184 or JSR 239 (3D) and reimplement drawing using any of those APIs
  
 
== gvSIG Mini ==
 
== gvSIG Mini ==
−
 
−
Proposed mentor: [[Alberto Romeu]]
 
  
 
[http://www.gvsigmini.com gvSIG Mini] is a free mobile map viewer of several layers sources (OSM, WMS, WMS-c) which at the moment is able to consume [http://wiki.openstreetmap.org/wiki/YOURS YOURS routing service] and [http://wiki.openstreetmap.org/wiki/Name_finder NameFinder service] (also weather, twitter services, etc.).  
 
[http://www.gvsigmini.com gvSIG Mini] is a free mobile map viewer of several layers sources (OSM, WMS, WMS-c) which at the moment is able to consume [http://wiki.openstreetmap.org/wiki/YOURS YOURS routing service] and [http://wiki.openstreetmap.org/wiki/Name_finder NameFinder service] (also weather, twitter services, etc.).  
Line 28: Line 145:
 
gvSIG Mini is currently being developed by [http://www.prodevelop.es 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.
 
gvSIG Mini is currently being developed by [http://www.prodevelop.es 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.
+
'''We are open to new ideas!'''
  
−
* '''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.
+
=== Add support to read and write GPX files (POIs, tracklogs, routes) ===
  
−
* '''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.
+
Proposed mentor: [[Alberto Romeu]] (melange id: alrocar)
  
−
* '''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.
+
The application should be able to read/parse files in [http://www.topografix.com/gpx.asp GPX format], convert the data into the gvSIG Mini geometries model (points and lines) and draw the information on a new layer.
  
−
'''We are open to new ideas!'''
+
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 ===
 +
 
 +
Proposed mentor: [[Alberto Romeu]] (melange id: alrocar)
 +
 
 +
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 ===
 +
 
 +
Proposed mentor: [[Alberto Romeu]] (melange id: alrocar)
 +
 
 +
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.
 +
 
 +
There are several libraries which implement the Twitter API (jTwitter, twitter4Java...) so the task to connect to a Twitter account and retrieve the information needed should be transparent to the student who selects this project.
 +
 
 +
 
 +
=== Build a POI editor using the OSM API ===
 +
 
 +
Proposed mentor: [[Alberto Romeu]] (melange id: alrocar)
 +
 
 +
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.

Latest revision as of 11:24, 11 April 2010

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.


Add support for WFS-T

Proposed mentor: Jorge Piera

Add support for remote edition using WFS-T. WFS-T is a subset of requests/replies in the OCG WFS specification that allows remote edition of both alphanumerical and geometric attributes of a feature collection.


Create a Title block Library in the gvSIG layout

Proposed mentor: Vicente Caballero (melange id: vcaballero)

The aim of the project is to extend the functionality of gvSIG Desktop layout, in order to add a library of configurable title blocks (this functionality has been demanded through the user mailing list of gvSIG).

The purpose is to reduce the repetitive and tedious work of creating title blocks on the layouts, which is so limited in the current version of gvSIG. It will be possible to configure text, images, divisions, size, font... and save them with an own format (gvb) for storaging and using them is future gvSIG works.

gvSIG as GDAL/OGR front-end

Proposed mentor: José Vicente Higón

One way to increase the functionallity of gvSIG is linking with other applications or libraries like GDAL/OGR. The main goal of this project would be the development of one front-end for GDAL/OGR command tools like gdal_translate, gdalwrap, gdaldem, ogr2ogr and so on. The development would consist in two parts. The first one would be a library for executing system processes in background, actually GDAL/OGR processes. The second one would consist of user interface development for wrapping the commands mentioned before.


gvSIG Mobile

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

Proposed mentor: ???

Accessing remote tiled map services allows the user to get updated maps from any part of the world inmediately. You can use those maps to locate yourself on an unknown city or to validate the features you are digitizing.

The project should include:

  • Acessing tilecache, WMS-C and OSM
  • Cache of tiles
  • Drawing tiles as they come instead of drawing the map when all tiles are downloaded
  • Download of tiles while the user is panning (dragging) the map instead of downloading when the user releases
  • Concretize zoom levels of the application when a tiled layer is used

Add support of Versioned WFS

Proposed mentor: ???

Editing in situ has a lot of advantages and some problems. One of the problems is the sinchronization of edits. Supose user A and user B are editing data from the same WFS-T. If both users download the same feature at the same time and both edit and store it back then some data will be lost.

With WFS versioning you can handle those situations and have the opportunity of have a look or even restore the state of every feature in any moment in the past.

Geoserver has done a test implementation of WFS versioning http://geoserver.org/display/GEOS/Versioning+WFS+-+Extensions

The project should include:

  • Installing and testing Geoserver WFS versioning
  • Handling conflicts when uploading changes

Desirable:

  • See log
  • Support of update to head
  • Support of rollback
  • Go to a specific version

Fill shapes with holes efficiently

Proposed mentor: ???

To draw a filled shape, gvSIG uses the Graphics2D.fill(Shape s) method. This paints the shape correctly even if it has holes or several disconnected areas. In CDC Personal Profile there is no Graphics2D so gvSIG Mobile is not able to draw shapes with holes.

The project should include:

  • Study of different filling algorithms (floodfill and others)
  • Implement one software filling algorithm
  • Implement tringulation algorithm to split the area into polygons without holes and compare the performance

Desirable:

  • Search for free implementations of JSR 184 or JSR 239 (3D) and reimplement drawing using any of those APIs

gvSIG Mini

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.

We are open to new ideas!


Add support to read and write GPX files (POIs, tracklogs, routes)

Proposed mentor: Alberto Romeu (melange id: alrocar)

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.

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

Proposed mentor: Alberto Romeu (melange id: alrocar)

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

Proposed mentor: Alberto Romeu (melange id: alrocar)

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.

There are several libraries which implement the Twitter API (jTwitter, twitter4Java...) so the task to connect to a Twitter account and retrieve the information needed should be transparent to the student who selects this project.


Build a POI editor using the OSM API

Proposed mentor: Alberto Romeu (melange id: alrocar)

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.

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