GRASS SoC Ideas 2011: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(→‎Volume modeling: mark implemened things)
 
(58 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{ToModify}}
[[Image:gsoc_2011_logo.png|350px|right]]
[[Image:gsoc_2011_logo.png|350px|right]]
__TOC__
__TOC__
Line 22: Line 21:
* {{Done}} Accepted mentoring organizations announced (March 18)
* {{Done}} Accepted mentoring organizations announced (March 18)


* '''Interested students should initiate preliminary discussions with projects (March 18-27)'''
* {{Done}} Interested students should initiate preliminary discussions with projects (March 18-27)


* Student applications open (March 28)
* {{Done}} Student applications open (March 28)


* Deadline for student's applications (April 8)
* {{Done}} Deadline for student's applications (April 8)
: Registering your application early (before the deadline) allows us to give you feedback for revisions before the final deadline, enhancing your proposal and thus giving you a better chance of success.
: Registering your application early (before the deadline) allows us to give you feedback for revisions before the final deadline, enhancing your proposal and thus giving you a better chance of success.


* Mentor assignments and application reviews deadline (April 22)
* {{Done}} Mentor assignments and application reviews deadline (April 22)


* Accepted proposals announced (April 25)
* {{Done}} Accepted proposals announced (April 25)


* Community bonding time (getting to know the students)
* {{Done}} Community bonding time (getting to know the students)


* Work Begins (May 23)
* {{Done}} Work Begins (May 23)


* Midterm evaluation (July 11-15)
* {{Done}} Midterm evaluation (July 11-15)


* Pencils down! (August 15)
* {{Done}} Pencils down! (August 15)


* Final evaluations submitted to Google (August 22)
* {{Done}} '''Final evaluations submitted to Google (August 22)'''


* Final results of GSoC 2011 announced (August 29)
* {{Done}} Final results of GSoC 2011 announced (August 29)


* Students can begin submitting required code samples to Google (August 30)
* {{Done}} Students can begin submitting required code samples to Google (August 30)


== Required Steps ==
== Required Steps ==
Line 61: Line 60:
* Students subscribe to the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev mailing list] and introduce themselves
* Students subscribe to the [http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev mailing list] and introduce themselves


* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
* Mentor will create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** Students must read and post agreement to [http://grass.osgeo.org/programming7/rfc2_psc.html RFC2] to the [http://lists.osgeo.org/mailman/listinfo/grass-psc grass-psc mailing list] to gain SVN access
** Students must read and post agreement to [http://grass.osgeo.org/programming7/rfc2_psc.html RFC2] to the [http://lists.osgeo.org/mailman/listinfo/grass-psc grass-psc mailing list] to gain SVN access
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
Line 78: Line 77:
=== wxGUI ===
=== wxGUI ===


# 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]].
<ol>
#:<center>
<li> 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]].
#:[[Image:Wxgui_current.png|480px|thumb|center|Current wxGUI layout with detached window components]]  
<center>
#:[[Image:Wxgui_proposal.png|480px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
[[Image:Wxgui_current.png|300px|thumb|left|Current wxGUI layout with detached window components]]  
#:</center>
[[Image:Wxgui_proposal.png|300px|thumb|center|Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)]]
# Add '''WMS and/or TiledMapService layer support''' for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response.
</center>
# ''Your idea here''
<li> Add '''WMS and/or TiledMapService and/or WMS-T layer support''' for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response. ''Accepted as [[WXGUI WMS service rendering GSoC 2011]].''
 
<li> Develop a GUI module in wxPython for '''creating animations''' from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files. See existing modules {{cmd|xganim}}, {{cmd|r.out.mpeg}}, [[NVIZ]]'s animation tools, and the [[Movies]] creation wiki page. (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).''
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], (''your name here'')
<li> Develop a sophisticated '''GUI for r.stream modules'''. The advantage of such GUI is to allow the user to have a simple approach to a sophisticated thing like hydrology.
</ol>
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:MarisN|Maris Nartiss]], [[User:Mmetz|Markus Metz]], (''your name here'')


=== Raster ===
=== Raster ===


# ''Your idea here''
# 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 OpenMP is required.
 
# r.in.modis a module to import MODIS products. It will be able to download tile/s and import it/them. It will create also the mosaic from original MODIS tiles and import it. (Proposed by [[User:lucadelu|lucadelu]] with [[User:Neteler|MarkusN]] like mentor) ''Accepted as [[R.modis GSoC 2011]], see also {{AddonSrc|raster|r.modis|version=7}} addon.''
'''Willing to Mentor:''' (''your name here'')


=== Vector ===
=== Vector ===
Line 98: Line 98:
# Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)'' . See above idea in the [[GRASS SoC Ideas 2011#Raster|Raster section]].
# Add '''[[OpenMP]] parallelization''' where appropriate, for example, {{cmd|v.surf.rst}} and {{cmd|v.vol.rst}} ''(co-mentor Helena Mitasova)'' . See above idea in the [[GRASS SoC Ideas 2011#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.
# ''Your idea here''
# 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).


'''Willing to Mentor:''' [[User:Landa|Martin Landa]], (''your name here'')
'''Willing to Mentor:''' [[User:Landa|Martin Landa]], [[User:Mmetz|Markus Metz]], (''your name here'')


=== Imagery ===
=== 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.
# 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.
#* 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.
#* 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
# Implement '''[[OpenMP]] (multithreading)''' as much as possible (where appropriate)
# ''Your idea here''
# ''Your idea here''


Line 113: Line 115:


'''Willing to Mentor:''' (''your name here'')
'''Willing to Mentor:''' (''your name here'')
=== 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.
# 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).
'''Willing to Mentor:''' [[User:Landa|Martin Landa]] (for 2), co-mentor for 1 and 4: Helena Mitasova, (''your name here'')
=== Volume modeling ===
# implement color management for 3D rasters : '''r3.colors''' (implemented in 2011)
# develop '''r3.flow''' for computing 3D flow lines and 3D flow accumulation from 3D rasters (implemented in 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, (''your name here'')


=== Other ===
=== Other ===


# 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 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.
# 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.
-->
# Design '''sophisticated Python scripting interface''' for GRASS based on [http://grass.osgeo.org/programming7/pythonlib.html GRASS Python Scripting Library]
# ''Your idea here''
# ''Your idea here''


Line 132: Line 153:


* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the [http://svn.osgeo.org/grass/grass/trunk/SUBMITTING SUBMITTING] files there for our coding standards.
 
* Please review the submitting files for our coding standards
** {{src|SUBMITTING|branch=trunk}} for C coding rules
** {{src|SUBMITTING_PYTHON|branch=trunk}} for Python coding rules
** {{src|SUBMITTING_DOCS|branch=trunk}} for Documentantion coding rules


* 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]
: See also the [[Development|development section]] of the GRASS user's wiki
: See also the [[Development|development section]] of the GRASS user's wiki
== Guidelines for Mentors ==
* Unofficial book: http://www.booki.cc/gsoc-mentoring/


== Accepted Ideas ==
== Accepted Ideas ==
# [http://www.google-melange.com/gsoc/project/google/gsoc2011/eil8iath/5001 Completion of wxGUI Nviz extension for 3D data visualization in GRASS GIS]
#: Student: Anna Kratochvilova
#: Mentor: [[User:Landa|Martin Landa]]
#: Wiki page: [[WxNviz GSoC 2011]]
# [http://www.google-melange.com/gsoc/project/google/gsoc2011/madi468/9001 Graphical User Interface for the hydrological tools r.stream* in GRASS GIS]
#: Student: [[User:Madi|Margherita Di Leo]]
#: Mentor: Jarek Jasiewicz
#: Wiki page: [[Wx.stream GSoC 2011]]
# [http://www.google-melange.com/gsoc/project/google/gsoc2011/sudeep495/10001 GRASS WXGUI WMS service rendering]
#: Student: sudeep495
#: Mentor: [[User:MarisN|Maris Nartiss]]
#: Wiki page: [[WxGUI WMS service rendering GSoC 2011]]
# [http://www.google-melange.com/gsoc/project/google/gsoc2011/lucadelu/13001 r.in.modis for GRASS GIS]
#: Student: [[User:Lucadelu|Luca Delucchi]]
#: Mentor: [[User:Neteler|Markus Neteler]]
#: Wiki page: [[R.modis GSoC 2011]]


[[Category:Development]]
[[Category:Development]]
[[Category:Community]]
[[Category:Community]]
[[Category:GSoC]]
[[Category:GSoC]]

Latest revision as of 17:06, 11 February 2015

About

This is the GRASS page for Google Summer of Code 2011. Here we will list project ideas and and other information related to the GRASS GSoC projects.

Promotion:

Timeline

See GSoC timeline

  • √ Mentoring organization applications open (March 11)
  • √ Accepted mentoring organizations announced (March 18)
  • √ Interested students should initiate preliminary discussions with projects (March 18-27)
  • √ Student applications open (March 28)
  • √ Deadline for student's applications (April 8)
Registering your application early (before the deadline) allows us to give you feedback for revisions before the final deadline, enhancing your proposal and thus giving you a better chance of success.
  • √ Mentor assignments and application reviews deadline (April 22)
  • √ Accepted proposals announced (April 25)
  • √ Community bonding time (getting to know the students)
  • √ Work Begins (May 23)
  • √ Midterm evaluation (July 11-15)
  • √ Pencils down! (August 15)
  • √ Final evaluations submitted to Google (August 22)
  • √ Final results of GSoC 2011 announced (August 29)
  • √ Students can begin submitting required code samples to Google (August 30)

Required Steps

  • List ideas
  • Assign Mentors to Ideas
  • Notify OSGeo
  • Mentors evaluate student applications
  • Accepted students announced
  • 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

  • Also review ideas from 2007, 2008, 2009, and 2010 which are still open.
  • Project ideas of your own are also most welcome.

wxGUI

  1. 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)
  2. Add WMS and/or TiledMapService and/or WMS-T layer support for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response. Accepted as WXGUI WMS service rendering GSoC 2011.
  3. Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files. See existing modules xganim, r.out.mpeg, NVIZ's animation tools, and the Movies creation wiki page. (co-mentor Helena Mitasova). This was implemented outside GSoC as g.gui.animation (GRASS Animation Tool) and g.gui.mapswipe (GRASS Mapswipe).
  4. Develop a sophisticated GUI for r.stream modules. The advantage of such GUI is to allow the user to have a simple approach to a sophisticated thing like hydrology.

Willing to Mentor: Martin Landa, Maris Nartiss, Markus Metz, (your name here)

Raster

  1. 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.
  2. r.in.modis a module to import MODIS products. It will be able to download tile/s and import it/them. It will create also the mosaic from original MODIS tiles and import it. (Proposed by lucadelu with MarkusN like mentor) Accepted as R.modis GSoC 2011, see also r.modis (src) addon.

Vector

  1. Add OpenMP parallelization where appropriate, for example, v.surf.rst and v.vol.rst (co-mentor Helena Mitasova) . See above idea in the Raster section.
  2. 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.
  3. 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.
  4. 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).

Willing to Mentor: Martin Landa, Markus Metz, (your name here)

Imagery

  1. 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.
  2. Implement OpenMP (multithreading) as much as possible (where appropriate)
  3. Your idea here

See the ideas for imagery improvement and GRASS 7 ideas wiki pages for more details.

Willing to Mentor: (your name here)

3D visualization

  1. 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.
  2. 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.
  3. 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.
  4. 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)
  5. 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: Martin Landa (for 2), co-mentor for 1 and 4: Helena Mitasova, (your name here)

Volume modeling

  1. implement color management for 3D rasters : r3.colors (implemented in 2011)
  2. develop r3.flow for computing 3D flow lines and 3D flow accumulation from 3D rasters (implemented in GSoC 2014)
  3. 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, (your name here)

Other

  1. Design and implement modern metadata management system for GRASS to support OGC CSW and INSPIRE discovery a view services
  2. Design sophisticated Python scripting interface for GRASS based on GRASS Python Scripting Library
  3. Your idea here

Willing to Mentor: (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:

Getting started with GRASS coding

  • The source code is maintained in a SVN server which is easy to browse
See also the development section of the GRASS user's wiki

Guidelines for Mentors

Accepted Ideas

  1. Completion of wxGUI Nviz extension for 3D data visualization in GRASS GIS
    Student: Anna Kratochvilova
    Mentor: Martin Landa
    Wiki page: WxNviz GSoC 2011
  2. Graphical User Interface for the hydrological tools r.stream* in GRASS GIS
    Student: Margherita Di Leo
    Mentor: Jarek Jasiewicz
    Wiki page: Wx.stream GSoC 2011
  3. GRASS WXGUI WMS service rendering
    Student: sudeep495
    Mentor: Maris Nartiss
    Wiki page: WxGUI WMS service rendering GSoC 2011
  4. r.in.modis for GRASS GIS
    Student: Luca Delucchi
    Mentor: Markus Neteler
    Wiki page: R.modis GSoC 2011
Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=GRASS_SoC_Ideas_2011&oldid=21263"