Difference between revisions of "GvSIG GSoC 2014 Ideas"

From OSGeo
Jump to navigation Jump to search
m
 
(9 intermediate revisions by 7 users not shown)
Line 16: Line 16:
 
The objective would be to integrate the Aparapi library in gvSIG, so it might be used in the development of new parallel geoprocessing algorithms which take advantage of current GPUs. Also some geoprocesses would have to be developed or converted to use the Aparapi library to check the benefits and the proper operation of the idea.
 
The objective would be to integrate the Aparapi library in gvSIG, so it might be used in the development of new parallel geoprocessing algorithms which take advantage of current GPUs. Also some geoprocesses would have to be developed or converted to use the Aparapi library to check the benefits and the proper operation of the idea.
  
== Extend Raster Support in Scripting Framework in gvSIG ==
+
== Port Network Analysis Extension to gvSIG 2.x branch ==
  
 
* '''Product''': gvSIG Desktop
 
* '''Product''': gvSIG Desktop
* '''Possible mentor''':  
+
* '''Possible mentor''': [[User:Fpenarru| Francisco José Peñarrubia]]
* '''Possible student''': Sandeep Kumar
+
* '''Possible students''': David Pinheiro, Vicente Caballero, Dragos Dragomir
 +
 
 +
Port gvSIG Network Analysis Extension from 1.12 release to the new 2.x branch.
 +
 
 +
Network Analysis extension allows to calculate routes, service areas, origin - destination matrices, connectivity analysis... It supports speeds for several vehicles, barriers, turn costs, etc.
 +
 
 +
Improvement: Use GraphHopper [http://graphhopper.com/] library to use new algorithm Contraction Hierarchies (much faster) when calculating routes.
 +
 
 +
Skills needed: Java, Eclipse development. Some notions about Maven would be interesting.
 +
 
 +
== OGR library support for gvSIG Mini ==
 +
 
 +
* '''Product''': gvSIG Mini
 +
* '''Possible mentor''': Daniel Gastón, Carlos Sánchez
 +
* '''Possible student''': Vanessa Maria Martínez
  
 
'''1. Introduction'''
 
'''1. Introduction'''
  
gvSIG Scripting Framework is a small environment for development and execution of scripts that interact with the application.These scripts allow us to automate small tasks or add some functionality that we need and that we can implement. This feature helps the developers to test their implementations locally with much less effort.  
+
By integrating the OGR library into gvSIG Mini we could get access several vector formats including the widespread SHP, GML, KML format so much demanded by the gvSIG Mini users. OGR offers us the perfect platform to implement demanding format transformations and the corresponding file format outputs as many desktop GIS application already do.
  
 
'''2. Background'''
 
'''2. Background'''
  
At this moment, using Scripting Framework one can load raster layer and perform some filtering operations. This was implemented as part of GSoC 2013 idea [https://google-melange.appspot.com/gsoc/project/google/gsoc2013/kumarsandeep2357/6526151266664448 Add Raster Format to Scripting in gvSIG]
+
At this moment, gvSIG gets access to a reduced list of file formats and transformations.  
  
'''3. Idea'''
+
'''3. The idea'''
  
This idea concentrates on extending the capabilities of Jython Scripting in gvSIG Desktop. A lot of Raster functions like histogram analysis, flow direction analysis, geoprocessing etc., which stand as a major advantage of using Raster data should be implemented in Scripting Framework.
+
The main idea behind this project is about integrating the OGR library into gvSIG Mini. The OGR library provides several capabilities for simple features vector data; however it should be mentioned that OGR is also part of the GDAL source tree, so that by integrating OGR we do integrate GDAL as well, getting access to GDAL raster capabilities(for future developments). This proposal improves the application interoperability, and in general terms, the supported range of geoprocesses and transformations.  
  
Filtering of raster images is one of the key feature of image analysis. As of now, the filtering operations consume lots of time even on small images. This can be optimized by making use of the already implemented gvSIG kernels from Java.
+
Once the solution is adapted and compiled, we would proceed to adapt and connect the full OGR data model with the data model gvSIG works with and provide full support to the SHP format. The implementation is intended to be done in a way future formats supports are easily developed.
  
As of now, one can load .tiff files using Scripting Framework. This should be extended such that one can load .ecw, .jp2 files. Loading a layer in a tiled way, loading WMS and WCS layers, getting the ROI of a layer as a vector layer etc.,  should be implemented.
+
== Add XLS file format support to gvSIG Desktop 2.x ==
  
== Port Network Analysis Extension to gvSIG 2.x branch ==
+
* '''Product''': gvSIG Desktop
 +
* '''Possible mentor''': Joaquín del Cerro
 +
* '''Possible student''': Manuel Madrid
 +
 
 +
The management of alphanumeric information contained in tables is a critical question of spatial analysis, but often the desktop GIS applications are not as powerful as a spreadsheet application for this kind of tasks, so having the possibility of transfering data between both types of applications would be very useful.
 +
 
 +
Microsoft Excel is a poweful and widely used spreadsheet application tradicionaly used by many GIS users for managing alphanumeric data. Unfortunately from the version 2007 on, this application stopped supporting dBase file format (.DBF), which is the most common table file format used by GIS applications.
 +
 
 +
The idea is about adding to gvSIG Desktop support of XLS file format (Microsoft Excel Spreadsheet) by implementing a new data provider in order to facilitate the data transfer between Microsoft Excel and gvSIG.
 +
 
 +
The provider will support multiple spreadsheets files reading and mono-spreadsheet files writing.
 +
 
 +
== Geoprocesses Access from the Scripting Framework in gvSIG Desktop 2.x ==
  
 
* '''Product''': gvSIG Desktop
 
* '''Product''': gvSIG Desktop
* '''Possible mentor''': [[User:Fpenarru| Francisco José Peñarrubia]]
+
* '''Possible mentor''': Joaquín del Cerro
* '''Possible student''':  
+
* '''Possible student''': Óscar Martínez Olmos
  
Port gvSIG Network Analysis Extension from 1.12 release to the new 2.x branch.
+
Since the last version, you can write your own Python scripts inside gvSIG 2.x using the new Scripting Framework. Now, when you create your script, you have a lot of functions available, but you don't have access to the Geoprocesses that already exist in gvSIG.
  
Network Analysis extension allows to calculate routes, service areas, origin - destination matrices, connectivity analysis... It supports speeds for several vehicles, barriers, turn costs, etc.
+
The idea is extend the capabilities of this module and create the link between Scripting and Geoprocesses for have access to powerfool tools, who can be even more usefull when you use it inside your own script. ArcPy (ArcGIS) have a similar funcion, with gvsig, you will call one geoprocess in your script with a code similar like this:
  
Improvement: Use GraphHopper [http://graphhopper.com/] library to use new algorithm Contraction Hierarchies (much faster) when calculating routes.
+
Gvsig_Disolve("layer1.shp","AREA",0,0,fields, "C:/gvsig/disolve.shp")
  
Skills needed: Java, Eclipse development. Some notions about Maven would be interesting.
+
Also, if a have time, i would like to incorporate the option to insert scripts inside the gvSIG Model Builder, you could create greater tasks.
  
 +
 
== Idea template ==
 
== Idea template ==
  
Line 59: Line 86:
  
 
Write your idea here... Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi imperdiet condimentum leo sit amet scelerisque. Aliquam placerat, dolor non egestas gravida, tellus felis viverra dui, a scelerisque dolor leo in nulla. Suspendisse pharetra lacus vitae lacus mollis dapibus dignissim metus varius. Nullam scelerisque, elit sit amet ornare commodo, tortor enim consectetur est, eget imperdiet leo augue eget felis. Vivamus nec justo tellus, nec semper ante. Etiam et dolor urna. Nullam non augue in lacus auctor laoreet eget non erat. Integer id justo id magna commodo malesuada. Maecenas tincidunt ipsum nec erat fringilla posuere. Sed ante sapien, posuere non euismod tincidunt, fermentum sollicitudin quam. Aenean metus lacus, viverra ut hendrerit eu, interdum vitae turpis.
 
Write your idea here... Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi imperdiet condimentum leo sit amet scelerisque. Aliquam placerat, dolor non egestas gravida, tellus felis viverra dui, a scelerisque dolor leo in nulla. Suspendisse pharetra lacus vitae lacus mollis dapibus dignissim metus varius. Nullam scelerisque, elit sit amet ornare commodo, tortor enim consectetur est, eget imperdiet leo augue eget felis. Vivamus nec justo tellus, nec semper ante. Etiam et dolor urna. Nullam non augue in lacus auctor laoreet eget non erat. Integer id justo id magna commodo malesuada. Maecenas tincidunt ipsum nec erat fringilla posuere. Sed ante sapien, posuere non euismod tincidunt, fermentum sollicitudin quam. Aenean metus lacus, viverra ut hendrerit eu, interdum vitae turpis.
 
 
 
[[Category:Google Summer of Code]][[Category:gvSIG]]
 
[[Category:Google Summer of Code]][[Category:gvSIG]]

Latest revision as of 07:40, 23 March 2014

Use this page to jot down and develop any good idea for the Google Summer of Code 2014 program with gvSIG project. Please, use the gvSIG mailing lists for discussion and check 2013, 2012, 2011, 2010, 2009 ideas pages for examples or reference.


Add OpenCL support with Aparapi for Geoprocessing in gvSIG desktop

  • Product: gvSIG Desktop
  • Possible mentor: Cèsar Ordiñana
  • Possible student: Paula Navarro

Aparapi is a library which allows Java developers to take advantage of the compute power of GPU and APU devices by executing data parallel code fragments on the GPU rather than being confined to the local CPU. It does this by converting Java bytecode to OpenCL at runtime and executing on the GPU, if for any reason Aparapi can't execute on the GPU it will execute in a Java thread pool.

Large amounts of geographic data-processing might be involved in the execution of a geoprocess. And many geoprocessing algorithms are suitable to be converted to parallel code, allowing for much better execution performance and capacity.

The objective would be to integrate the Aparapi library in gvSIG, so it might be used in the development of new parallel geoprocessing algorithms which take advantage of current GPUs. Also some geoprocesses would have to be developed or converted to use the Aparapi library to check the benefits and the proper operation of the idea.

Port Network Analysis Extension to gvSIG 2.x branch

Port gvSIG Network Analysis Extension from 1.12 release to the new 2.x branch.

Network Analysis extension allows to calculate routes, service areas, origin - destination matrices, connectivity analysis... It supports speeds for several vehicles, barriers, turn costs, etc.

Improvement: Use GraphHopper [1] library to use new algorithm Contraction Hierarchies (much faster) when calculating routes.

Skills needed: Java, Eclipse development. Some notions about Maven would be interesting.

OGR library support for gvSIG Mini

  • Product: gvSIG Mini
  • Possible mentor: Daniel Gastón, Carlos Sánchez
  • Possible student: Vanessa Maria Martínez

1. Introduction

By integrating the OGR library into gvSIG Mini we could get access several vector formats including the widespread SHP, GML, KML format so much demanded by the gvSIG Mini users. OGR offers us the perfect platform to implement demanding format transformations and the corresponding file format outputs as many desktop GIS application already do.

2. Background

At this moment, gvSIG gets access to a reduced list of file formats and transformations.

3. The idea

The main idea behind this project is about integrating the OGR library into gvSIG Mini. The OGR library provides several capabilities for simple features vector data; however it should be mentioned that OGR is also part of the GDAL source tree, so that by integrating OGR we do integrate GDAL as well, getting access to GDAL raster capabilities(for future developments). This proposal improves the application interoperability, and in general terms, the supported range of geoprocesses and transformations.

Once the solution is adapted and compiled, we would proceed to adapt and connect the full OGR data model with the data model gvSIG works with and provide full support to the SHP format. The implementation is intended to be done in a way future formats supports are easily developed.

Add XLS file format support to gvSIG Desktop 2.x

  • Product: gvSIG Desktop
  • Possible mentor: Joaquín del Cerro
  • Possible student: Manuel Madrid

The management of alphanumeric information contained in tables is a critical question of spatial analysis, but often the desktop GIS applications are not as powerful as a spreadsheet application for this kind of tasks, so having the possibility of transfering data between both types of applications would be very useful.

Microsoft Excel is a poweful and widely used spreadsheet application tradicionaly used by many GIS users for managing alphanumeric data. Unfortunately from the version 2007 on, this application stopped supporting dBase file format (.DBF), which is the most common table file format used by GIS applications.

The idea is about adding to gvSIG Desktop support of XLS file format (Microsoft Excel Spreadsheet) by implementing a new data provider in order to facilitate the data transfer between Microsoft Excel and gvSIG.

The provider will support multiple spreadsheets files reading and mono-spreadsheet files writing.

Geoprocesses Access from the Scripting Framework in gvSIG Desktop 2.x

  • Product: gvSIG Desktop
  • Possible mentor: Joaquín del Cerro
  • Possible student: Óscar Martínez Olmos

Since the last version, you can write your own Python scripts inside gvSIG 2.x using the new Scripting Framework. Now, when you create your script, you have a lot of functions available, but you don't have access to the Geoprocesses that already exist in gvSIG.

The idea is extend the capabilities of this module and create the link between Scripting and Geoprocesses for have access to powerfool tools, who can be even more usefull when you use it inside your own script. ArcPy (ArcGIS) have a similar funcion, with gvsig, you will call one geoprocess in your script with a code similar like this:

Gvsig_Disolve("layer1.shp","AREA",0,0,fields, "C:/gvsig/disolve.shp")

Also, if a have time, i would like to incorporate the option to insert scripts inside the gvSIG Model Builder, you could create greater tasks.


Idea template

  • Product: gvSIG Desktop/gvSIG Mini
  • Possible mentor: if applicable
  • Possible student: if applicable

Write your idea here... Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi imperdiet condimentum leo sit amet scelerisque. Aliquam placerat, dolor non egestas gravida, tellus felis viverra dui, a scelerisque dolor leo in nulla. Suspendisse pharetra lacus vitae lacus mollis dapibus dignissim metus varius. Nullam scelerisque, elit sit amet ornare commodo, tortor enim consectetur est, eget imperdiet leo augue eget felis. Vivamus nec justo tellus, nec semper ante. Etiam et dolor urna. Nullam non augue in lacus auctor laoreet eget non erat. Integer id justo id magna commodo malesuada. Maecenas tincidunt ipsum nec erat fringilla posuere. Sed ante sapien, posuere non euismod tincidunt, fermentum sollicitudin quam. Aenean metus lacus, viverra ut hendrerit eu, interdum vitae turpis.