GRASS SoC Ideas 2012: Difference between revisions
(→Vector: your idea here..) |
⚠️Wenzeslaus (talk | contribs) |
||
(63 intermediate revisions by 14 users not shown) | |||
Line 9: | Line 9: | ||
* Visit the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 main OSGeo Google Summer of Code 2012 @ OSGeo wiki page]. | * Visit the [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012 main OSGeo Google Summer of Code 2012 @ OSGeo wiki page]. | ||
__TOC__ | __TOC__ | ||
Line 21: | Line 19: | ||
Promotion: | Promotion: | ||
<!-- | |||
* OSGeo Flyer at <s>http://svn.osgeo.org/osgeo/marketing/flyer/google_summer_of_code/OSGeo_GSoC_2012.pdf </s>(todo) | * OSGeo Flyer at <s>http://svn.osgeo.org/osgeo/marketing/flyer/google_summer_of_code/OSGeo_GSoC_2012.pdf </s>(todo) | ||
--> | |||
* Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos | * Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos | ||
* More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers | * More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers | ||
== Timeline == | == Timeline == | ||
* '''[http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#timeline The official timeline]''' | * '''[http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#timeline The official timeline]''' | ||
== Required Steps == | == Required Steps == | ||
* List ideas | * '''List ideas''' | ||
* Assign Mentors to Ideas | * Assign Mentors to Ideas | ||
Line 57: | Line 55: | ||
== Ideas == | == Ideas == | ||
* | * Also review ideas from [[GRASS SoC Ideas 2009#Ideas|2009]], [[GRASS SoC Ideas 2010#Ideas|2010]], and [[GRASS SoC Ideas 2011#Ideas|2011]] which are still open. | ||
* Project ideas of '''your own''' are also most welcome and often the best. | |||
=== wxGUI === | === [[wxGUI]] === | ||
# Develop GUI support in wxPython for visualy analyzing series of raster map layers. The module should provide users with capabilities to browse and animate raster (and potentially also vector) data series in a 2D display and save outputs to animated GIF, MOV, or MPEG files. A related module that displays the series as small images and support re-ordering, deleting and adding raster maps (frames) to the series would also be helpful. To compare visually two images a slider functionality could be added to the 2D display, for example, to compare before and after images, or two consequent images in series. The series of data layers can be handled as multiple standard raster or vector layers or using the new time series support. See existing modules {{cmd|xganim}}, {{cmd|r.out.mpeg}}, [[NVIZ]]'s animation tools, and the [[Movies]] creation wiki page. There is also a related capability in the TclTk GUI. (co-mentor Helena Mitasova). ''This was implemented outside GSoC as {{Cmd|g.gui.animation|ver=70}} (GRASS Animation Tool) and {{Cmd|g.gui.mapswipe|ver=70}} (GRASS Mapswipe).'' | |||
# Develop an interactive vector geometry selection and export tool for [[wxGUI]] as described in the trac ticket [http://trac.osgeo.org/grass/ticket/1471 #1471] | |||
# Offer also (optional) "conventional" '''GUI layout''': For some users, the current approach of separate windows (SDI) leads to a '''windows flooding'''. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the [[wxGUI]] windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-03.png example 1] and [http://grass.osgeo.org/grass63/screenshots/images/wxgrass_digit-01.png example 2]. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see [[wxGUI#Layout| wxGUI layout]]. | |||
<center> | <center> | ||
<gallery widths=400 heights=250> | |||
Image:Wxgui_current.png|Current wxGUI layout with detached window components | |||
Image:Wxgui_proposal.png|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus) | |||
</gallery> | |||
</center> | </center> | ||
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:MarisN|Maris Nartiss]], [[User:Mmetz|Markus Metz]], (''your name here'') | '''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:MarisN|Maris Nartiss]], [[User:Mmetz|Markus Metz]], (''your name here'') | ||
=== Raster === | === Raster === | ||
#Add '''[[OpenMP]] parallelization''' where appropriate, for example {{cmd|r.cost}}, {{cmd|r.surf.contour}}, {{cmd|r.watershed}}. It is important to understand which modules are processor bound, and concentrate on them. i.e. do not needlessly complicate the code of non-long running processor bound modules. A good working knowledge of ANSI C and {{wikipedia|OpenMP}} is required. ({{wikipedia|OpenCL}} and {{wikipedia|pthreads}} are fine too!) | |||
#Create a new GRASS module to find the {{wikipedia|topographic_prominence}} of peaks from a raster elevation map within the region. (probably this would only make up 1/4 to 1/2 of a multi-part GSoC project) | |||
'''Willing to Mentor:''' Hamish (co-mentor parallelization and prominence projects), (''your name here'') | '''Willing to Mentor:''' Hamish (co-mentor parallelization and prominence projects), Wolf Bergenheim(''your name here'') | ||
=== Vector === | === Vector === | ||
# Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)''. (OpenCL and pthreads are fine too!) See above idea in the [[GRASS SoC Ideas | # Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)''. (OpenCL and pthreads are fine too!) See above idea in the [[GRASS SoC Ideas 2012#Raster|Raster section]]. | ||
# Better '''support for wrap-around at 180 longitude''': Currently the raster engine is pretty good at wrapping data over 180 longitude. The vector data isn't, but it should be. This is a great task if by the end of the summer you'd like to be familiar with the implementation method of an entire vector stack of a fully featured modern GIS. | # Better '''support for wrap-around at 180 longitude''': Currently the raster engine is pretty good at wrapping data over 180 longitude. The vector data isn't, but it should be. This is a great task if by the end of the summer you'd like to be familiar with the implementation method of an entire vector stack of a fully featured modern GIS. | ||
# Add '''break lines support to interpolation modules''' ({{cmd|v.surf.rst}}, {{cmd|v.surf.idw}}, {{cmd|v.surf.bspline}}). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See [http://www.spatialanalysisonline.com/output/html/Breaklinesandnaturalboundaries.html Geospatial Analysis - a comprehensive guide. 3rd edition] for description. [*] well, some support exists, see {{AddonCmd|v.surf.icw}}. | # Add '''break lines support to interpolation modules''' ({{cmd|v.surf.rst}}, {{cmd|v.surf.idw}}, {{cmd|v.surf.bspline}}). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See [http://www.spatialanalysisonline.com/output/html/Breaklinesandnaturalboundaries.html Geospatial Analysis - a comprehensive guide. 3rd edition] for description. [*] well, some support exists, see {{AddonCmd|v.surf.icw}}. | ||
# Speed up wxGUI handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd). | # Speed up [[wxGUI]] handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd). | ||
# | # Create graphical vector attribute data merging tool and provide necessary functionality in v.patch to allow merging of two vector datasets with different attribute data tables. Tool should provide a GUI way to map attribute table columns, create new ones and, where possible, change data type during merging. | ||
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:Mmetz|Markus Metz]], Hamish (co-mentor for parallelization), (''your name here'') | |||
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:Mmetz|Markus Metz]], Hamish (co-mentor for parallelization), Wolf Bergenheim, (''your name here'') | |||
=== Imagery === | === Imagery === | ||
Line 103: | Line 100: | ||
#* In addition, there are a number of '''improved/automated georectification tools''' which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code. | #* In addition, there are a number of '''improved/automated georectification tools''' which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code. | ||
# Implement '''[[OpenMP]] (multithreading)''' as much as possible (where appropriate; OpenCL and pthreads are fine too) | # Implement '''[[OpenMP]] (multithreading)''' as much as possible (where appropriate; OpenCL and pthreads are fine too) | ||
# In addition to the porting of the georectification tools mentioned above, it would be interesting to implement an orthorectification tool for satellite imagery. Currently, GRASS only has {{cmd|i.ortho.photo}} for aerial photographs. | |||
# Implement image segmentation algorithms and tools | # Implement image segmentation algorithms and tools | ||
# Implement region-based classification | # Implement region-based classification | ||
# Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests) | # Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests) | ||
See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|ideas for imagery improvement]] and [http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib GRASS 7 ideas] wiki pages for more details. | See the [[Image_processing#Ideas_collection_for_improving_GRASS.27_Image_processing_capabilities|ideas for imagery improvement]] and [http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib GRASS 7 ideas] wiki pages for more details. | ||
'''Willing to Mentor:''' (''your name here'') | '''Willing to Mentor:''' Hamish (co-mentor for parallelization), Markus Metz (orthorectification), (''your name here'') | ||
=== Cartography and display === | |||
# Add SVG (and perhaps EPS) support to the display library, for use via {{cmd|d.graph}} and/or {{cmd|d.vect}}, and add SVG support to {{cmd|ps.map}} via a SVG to EPS converter tool (probably by adapting an existing GPL-compatible library). Code to be written in ANSI C. Step 1 is adding a Bézier curve rendering library function. | |||
# Integrate Quantum/GRASS SVG output plugin with Inkscape. Python can serve as a common glue between these tools. The project would facilitate easy cartographic workflow while utilizing the advanced design functionality of Inkscape. This would be a two way bridge: | |||
## QGIS/GRASS plugins to invoke an Inkscape process and send a data set. | |||
## Inkscape plugin to query various OSGeo projects and display various data sets as layers. | |||
'''Willing to Mentor:''' Hamish (as a co-mentor) | |||
=== 3D visualization === | === 3D visualization === | ||
Line 118: | Line 126: | ||
# Design and implement user-provided '''symbol support in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should support GRASS symbols, SVG, and/or simple EPS symbols. | # Design and implement user-provided '''symbol support in OGSF library''' and it's front-ends (NVIZ, [[wxNVIZ]]). Solution should support GRASS symbols, SVG, and/or simple EPS symbols. | ||
<!-- # Add/fix missing features to [[wxNVIZ]] (lighting, robust handling of z-exageration and viewing position including latlong data, cutting planes, multiattribute 3D points, decorations: scale, north, legend, text, isosurfaces and slicing) --> | <!-- # Add/fix missing features to [[wxNVIZ]] (lighting, robust handling of z-exageration and viewing position including latlong data, cutting planes, multiattribute 3D points, decorations: scale, north, legend, text, isosurfaces and slicing) --> | ||
# Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency). | # Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency). | ||
'''Willing to Mentor:''' [[User:Landa|Martin Landa]] (for 2), co-mentor for 1 and | # Improve handling of z-exageration so that z-exag=1 is a realistic representation of landscape in terms of vertical scaling. Other default settings could also be improved to support wider range of data and improve robustness. | ||
'''Willing to Mentor:''' [[User:Landa|Martin Landa]] (for 2), co-mentor for 1 and 5: Helena Mitasova, (''your name here'') | |||
=== Volume modeling === | === Volume modeling === | ||
# | # Develop '''r3.flow''' for computing 3D flow lines and 3D flow accumulation from 3D rasters (implemented in [https://trac.osgeo.org/grass/wiki/GSoC/2014/ImplementationOf3DRasterFlowLine GSoC 2014]) | ||
# Enhance volume interpolation module '''{{cmd|v.vol.rst}}''' for handling of data in space-time cube, including computation of gradients and hypercurvatures | |||
# | |||
'''Willing to Mentor:''' co-mentor Helena Mitasova, [[User:Huhabla|Sören Gebbert]] | |||
=== Improved Python interface === | |||
Design '''sophisticated Python scripting interface''' for GRASS based on [http://grass.osgeo.org/programming7/pythonlib.html GRASS Python Scripting Library]. This API should become more intuitive and more integrative | |||
GRASS GIS would gain even more attractiveness! | |||
'''Willing to Mentor:''' [[User:Huhabla|Sören Gebbert]] | |||
'' | ''Accepted as Python high level map interaction for GRASS GIS (PyGRASS).'' | ||
=== Other === | === Other === | ||
* See also the [https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&type=enhancement GRASS wish list] | |||
# Implement selected modules (in C/C++) for geospatial analysis (kriging, etc.) based on [http://hpgl.aoizora.org/ HPGL] library (see also [http://hub.qgis.org/projects/quantum-gis/wiki/Python_Plugin_Ideas#Add-and-R-Free-geostatistic-toolbox-using-HPGL QGIS plugin wish]). | |||
# Design and implement modern '''metadata management system''' for GRASS to support [http://www.opengeospatial.org/standards/cat OGC CSW] and INSPIRE discovery a view services | # Design and implement modern '''metadata management system''' for GRASS to support [http://www.opengeospatial.org/standards/cat OGC CSW] and INSPIRE discovery a view services | ||
# Design '''GRASS toolboxes environment''', see [[GRASS repository layout proposal]] for detailed information. This would also include general clean up and organization of existing GRASS modules in trunk and add-ons. ''[http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes Toolboxes for wxGUI] implemented outside GSoC.'' | |||
# Design '''GRASS toolboxes environment''', see [[GRASS repository layout proposal]] for detailed information. This would also include general clean up and organization of existing GRASS modules in trunk and add-ons. | |||
'''Willing to Mentor:''' (''your name here'') | '''Willing to Mentor:''' Wolf Bergenheim (Python API, metadata management), [[User:Landa|Martin Landa]] (for HPGL) (''your name here'') | ||
== Guidelines for Students == | == Guidelines for Students == | ||
Line 158: | Line 178: | ||
* Please review the submitting files for our coding standards | * Please review the submitting files for our coding standards | ||
** {{ | ** {{twiki|Submitting|SUBMITTING}} | ||
* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki] | * There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki] | ||
Line 172: | Line 190: | ||
== Accepted Ideas == | == Accepted Ideas == | ||
# '' | # ''Python high level map interaction for GRASS GIS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2012/zarch/11001 abstract]) | ||
#: Student: | #: Student: Pietro Zambelli | ||
#: Mentor: | #: Mentor: Sören Gebbert | ||
#: Backup mentor: | #: Backup mentors: Luca Delucchi, Martin Landa | ||
#: Wiki page: | #: Wiki page: [[GRASS GSoC 2012 High level map interaction]] | ||
# ''GRASS GIS WxGui front end for vector analysis modules'' ([http://www.google-melange.com/gsoc/project/google/gsoc2012/turek/38001 abstract]) | |||
#: Student: Stepan Turek | |||
#: Mentor: Martin Landa | |||
#: Backup mentor: Markus Metz | |||
#: Wiki page: [[GRASS GSoC 2012 WxGUI front end for vector analysis modules]] | |||
# ''Image Segmentation in GRASS GIS'' ([http://www.google-melange.com/gsoc/project/google/gsoc2012/emomsen/20001 abstract]) | |||
#: Student: Eric Momsen | |||
#: Mentor: Markus Metz | |||
#: Backup mentors: Moritz Lennert, Pierre Roudier | |||
#: Wiki page: [[GRASS GSoC 2012 Image Segmentation]] | |||
<!-- | |||
# ''Project name'' | # ''Project name'' | ||
#: Student: Someone else's name here | #: Student: Someone else's name here | ||
Line 182: | Line 213: | ||
#: Backup mentor: Their backup mentor's name here | #: Backup mentor: Their backup mentor's name here | ||
#: Wiki page: wiki page maintained by them (typically in this GRASS wiki, or the trac development wiki) | #: Wiki page: wiki page maintained by them (typically in this GRASS wiki, or the trac development wiki) | ||
--> | |||
{{GSoC}} | |||
Latest revision as of 03:49, 19 December 2015
- See also previous Google Summer of Code ideas from 2011.
About
This is the GRASS page for Google Summer of Code 2012. Here we will list project ideas and and other information related to the GRASS GSoC projects.
Promotion:
- Videos at http://code.google.com/p/google-summer-of-code/wiki/Videos
- More Flyers at http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers
Timeline
Required Steps
- List ideas
- Assign Mentors to Ideas
- Notify OSGeo
- Mentors evaluate student applications
- Accepted students announced
- Students subscribe to the grass-dev mailing list and introduce themselves
- Mentor will create directory structure in the GRASS add-ons SVN for projects and setup access for students
- Students must read and post agreement to RFC2 to the grass-psc mailing list to gain SVN access
- Create a Wiki page for each accepted project, to be used as a progress reporting tool
- Coding begins...
- Students and mentors: Complete the Mid-term survey
- Final commit and packaging for Google
Ideas
- Project ideas of your own are also most welcome and often the best.
wxGUI
- Develop GUI support in wxPython for visualy analyzing series of raster map layers. The module should provide users with capabilities to browse and animate raster (and potentially also vector) data series in a 2D display and save outputs to animated GIF, MOV, or MPEG files. A related module that displays the series as small images and support re-ordering, deleting and adding raster maps (frames) to the series would also be helpful. To compare visually two images a slider functionality could be added to the 2D display, for example, to compare before and after images, or two consequent images in series. The series of data layers can be handled as multiple standard raster or vector layers or using the new time series support. See existing modules xganim, r.out.mpeg, NVIZ's animation tools, and the Movies creation wiki page. There is also a related capability in the TclTk GUI. (co-mentor Helena Mitasova). This was implemented outside GSoC as g.gui.animation (GRASS Animation Tool) and g.gui.mapswipe (GRASS Mapswipe).
- Develop an interactive vector geometry selection and export tool for wxGUI as described in the trac ticket #1471
- Offer also (optional) "conventional" GUI layout: For some users, the current approach of separate windows (SDI) leads to a windows flooding. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: example 1 and example 2. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see wxGUI layout.
-
Current wxGUI layout with detached window components
-
Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)
Willing to Mentor: Martin Landa, Maris Nartiss, Markus Metz, (your name here)
Raster
- Add OpenMP parallelization where appropriate, for example r.cost, r.surf.contour, r.watershed. It is important to understand which modules are processor bound, and concentrate on them. i.e. do not needlessly complicate the code of non-long running processor bound modules. A good working knowledge of ANSI C and OpenMP is required. (OpenCL and pthreads are fine too!)
- Create a new GRASS module to find the topographic_prominence of peaks from a raster elevation map within the region. (probably this would only make up 1/4 to 1/2 of a multi-part GSoC project)
Willing to Mentor: Hamish (co-mentor parallelization and prominence projects), Wolf Bergenheim(your name here)
Vector
- Add OpenMP parallelization where appropriate, for example, v.surf.rst and v.vol.rst (co-mentor Helena Mitasova). (OpenCL and pthreads are fine too!) See above idea in the Raster section.
- Better support for wrap-around at 180 longitude: Currently the raster engine is pretty good at wrapping data over 180 longitude. The vector data isn't, but it should be. This is a great task if by the end of the summer you'd like to be familiar with the implementation method of an entire vector stack of a fully featured modern GIS.
- Add break lines support to interpolation modules (v.surf.rst, v.surf.idw, v.surf.bspline). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See Geospatial Analysis - a comprehensive guide. 3rd edition for description. [*] well, some support exists, see v.surf.icw.
- Speed up wxGUI handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd).
- Create graphical vector attribute data merging tool and provide necessary functionality in v.patch to allow merging of two vector datasets with different attribute data tables. Tool should provide a GUI way to map attribute table columns, create new ones and, where possible, change data type during merging.
Willing to Mentor: Martin Landa, Markus Metz, Hamish (co-mentor for parallelization), Wolf Bergenheim, (your name here)
Imagery
- GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implemented using interactive X-monitors which are not available in MS Windows and so are removed in the new cross-platform code of GRASS 7.
- We need someone willing to port the old modules to work with GRASS 7, including writing new wxPython GUI frontends to a number of existing tools and updating the imagery libraries to current raster library standards.
- In addition, there are a number of improved/automated georectification tools which have not been merged into GRASS 5/6 which it would be nice to have updated and merged into the main code.
- Implement OpenMP (multithreading) as much as possible (where appropriate; OpenCL and pthreads are fine too)
- In addition to the porting of the georectification tools mentioned above, it would be interesting to implement an orthorectification tool for satellite imagery. Currently, GRASS only has i.ortho.photo for aerial photographs.
- Implement image segmentation algorithms and tools
- Implement region-based classification
- Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)
See the ideas for imagery improvement and GRASS 7 ideas wiki pages for more details.
Willing to Mentor: Hamish (co-mentor for parallelization), Markus Metz (orthorectification), (your name here)
Cartography and display
- Add SVG (and perhaps EPS) support to the display library, for use via d.graph and/or d.vect, and add SVG support to ps.map via a SVG to EPS converter tool (probably by adapting an existing GPL-compatible library). Code to be written in ANSI C. Step 1 is adding a Bézier curve rendering library function.
- Integrate Quantum/GRASS SVG output plugin with Inkscape. Python can serve as a common glue between these tools. The project would facilitate easy cartographic workflow while utilizing the advanced design functionality of Inkscape. This would be a two way bridge:
- QGIS/GRASS plugins to invoke an Inkscape process and send a data set.
- Inkscape plugin to query various OSGeo projects and display various data sets as layers.
Willing to Mentor: Hamish (as a co-mentor)
3D visualization
- Optimize OGSF (and NVIZ/wxNVIZ) to display large 3D point clouds with uninterupted tought speed. OGSF + (wx)NVIZ should be able to rotate point cloud (i.e. LiDAR dataset) with 4 millions of points on medium hardware (i.e. 2GHz CPU with 2Gb RAM and GPU with hardware transform and lighting support and dedicated video RAM) with response time not greater than 1.0 second.
- Design and implement text displaying and styling in OGSF library and it's front-ends (NVIZ, wxNVIZ). Solution should be user configurable (fonts, colors, effects etc.) and multilanguage friendly.
- Design and implement user-provided symbol support in OGSF library and it's front-ends (NVIZ, wxNVIZ). Solution should support GRASS symbols, SVG, and/or simple EPS symbols.
- Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency).
- Improve handling of z-exageration so that z-exag=1 is a realistic representation of landscape in terms of vertical scaling. Other default settings could also be improved to support wider range of data and improve robustness.
Willing to Mentor: Martin Landa (for 2), co-mentor for 1 and 5: Helena Mitasova, (your name here)
Volume modeling
- Develop r3.flow for computing 3D flow lines and 3D flow accumulation from 3D rasters (implemented in GSoC 2014)
- Enhance volume interpolation module v.vol.rst for handling of data in space-time cube, including computation of gradients and hypercurvatures
Willing to Mentor: co-mentor Helena Mitasova, Sören Gebbert
Improved Python interface
Design sophisticated Python scripting interface for GRASS based on GRASS Python Scripting Library. This API should become more intuitive and more integrative
GRASS GIS would gain even more attractiveness!
Willing to Mentor: Sören Gebbert
Accepted as Python high level map interaction for GRASS GIS (PyGRASS).
Other
- See also the GRASS wish list
- Implement selected modules (in C/C++) for geospatial analysis (kriging, etc.) based on HPGL library (see also QGIS plugin wish).
- Design and implement modern metadata management system for GRASS to support OGC CSW and INSPIRE discovery a view services
- Design GRASS toolboxes environment, see GRASS repository layout proposal for detailed information. This would also include general clean up and organization of existing GRASS modules in trunk and add-ons. Toolboxes for wxGUI implemented outside GSoC.
Willing to Mentor: Wolf Bergenheim (Python API, metadata management), Martin Landa (for HPGL) (your name here)
Guidelines for Students
How do you maximize your chances of getting picked? First read the Google SoC FAQ. Then talk to us about your idea. Try emailing our dev-mailing list, or come and talk to us in IRC (#grass). You can also reach the mentors directly by emailing:
- If you are thinking about applying, do make a point of reading the "Flip bits not Burgers: The Student's Guide to the Summer of Code" eBook
Getting started with GRASS coding
- The source code is maintained in a SVN server which is easy to browse
- Please review the submitting files for our coding standards
- There is lots of good info at the GRASS Developer's wiki
- See also the development section of the GRASS user's wiki
Guidelines for Mentors
- Un(?)official book: http://www.booki.cc/gsoc-mentoring/
- Some more hints on the OSGeo wiki
Accepted Ideas
- Python high level map interaction for GRASS GIS (abstract)
- Student: Pietro Zambelli
- Mentor: Sören Gebbert
- Backup mentors: Luca Delucchi, Martin Landa
- Wiki page: GRASS GSoC 2012 High level map interaction
- GRASS GIS WxGui front end for vector analysis modules (abstract)
- Student: Stepan Turek
- Mentor: Martin Landa
- Backup mentor: Markus Metz
- Wiki page: GRASS GSoC 2012 WxGUI front end for vector analysis modules
- Image Segmentation in GRASS GIS (abstract)
- Student: Eric Momsen
- Mentor: Markus Metz
- Backup mentors: Moritz Lennert, Pierre Roudier
- Wiki page: GRASS GSoC 2012 Image Segmentation