Difference between revisions of "GRASS SoC Ideas 2009"

From GRASS-Wiki
Jump to: navigation, search
Line 110: Line 110:
=== Other ===
=== Other ===
* Continue the development of [[WinGRASS_Current_Status|GRASS for Windows]].
* Continue the development of [[WinGRASS_Current_Status|GRASS for Windows]]. We are especially interested in having GRASS work on Windows Vista.
== Guidelines for Students ==
== Guidelines for Students ==

Revision as of 13:52, 26 March 2009

2009 summer of code logo final r3-01.png


March 2009: This page is open to contributions - please edit!

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


  OSGeo Flyer at http://svn.osgeo.org/osgeo/marketing/flyer/
  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


(GSoC timeline)

  • Community bonding time (getting to know the students)
  • Deadline for student's applications (April 3rd)
  • Accepted proposals announced (April 20th)
  • Work Begins (May 23th)
  • Midterm evaluation (July 6th-13th)
  • Pencils down! (August 10th-17th)

Required Steps

  • List ideas
  • Assign Mentors to Ideas
  • Notify OSGeo
  • Mentors evaluate student applications (Deadline April 3rd)
  • April 20st: Accepted students announced
  • Students subscribe to the grass-dev mailing list and introduce themselves
  • 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


  • Also review ideas from 2008 which are still open.
  • Project ideas of your own are also most welcome.


  • While the GUI is becoming very powerful, there is potential for improvement of the layout. It is suggested to reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figure below). Essentially follow the Human interface guidelines and mind your users (and where they come from - think newcomers to the GRASS world - "Don't Limit Your User Base" by being too different from others). If possible, this could be implemented as skin to give users choices to also get wxGUI as Multiple Document Interface (MDI, i.e, the wxGUI windows reside under a single parent window). More here.
Current wxGUI layout with detached window components
Proposal for wxGUI layout modification (Recomposition of existing toolbars, mapview and menus)
  • Continue in wxNviz development.
  • Create a fully functional command line interface with history within the GUI (see suggestion)
  • Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files.

Kriging GUI

Currently GRASS has no native support for Kriging. Kriging is done either with the R package or with the GStat package. Both are command driven and thus a GUI could be created to control the program. R could be maybe called directly or via a script to do the variograms etc.

Your job would be to create a GUI (in wxPython) that can:

  1. Do Kriging based on R
    • Create and edit R scripts
    • Call R to do variogram analysis. For efficiency the R environment should be done
    • Call R to do the actual Kriging. This includes importing the result back to GRASS.
  2. Do Kriging based on gstat.
    • Create and edit GStat command files
    • Call gstat to do variogram analysis
    • Call gstat to do the actual Kriging.
See v.autokridge in Addons

Willing to Mentor:Wolf Bergenheim


  • implement OpenMP (multithreading) as much as possible


  • implement OpenMP multithreading) as much as possible
  • Rewrite v.select to implement more spatial operators (currently only "overlap" is available) - see [1].
Probably merge v.select with v.overlay.
--HB: I'm not so sure that a merge is justified; they perform two conceptually different tasks. A full-summer project would probably require more than this one task
  • Implement vector conflation to match vector networks from different sources (even rasterized streets from aerial/satellite imagery)
  • Further development of network analysis, modules for calculating new indicators such as degree, betweenness, etc, a v.net.distance module (see ticket 521, integration of time tables (train, public transport) into routing, etc.
  • Update and enhance vector querying to give full query capabilities to GRASS vectors. See vector querying section of GRASS 6.4 Feature Plan.


  • GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implimented 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

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


  • Continue the development of GRASS for Windows. We are especially interested in having GRASS work on Windows Vista.

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:

  • Wolf Bergenheim (wolf+grass@bergenheim.net)

Getting started with GRASS coding

  • The source code is maintained in a SVN server which is easy to browse
Please review the SUBMITTING files there for our coding standards.
See also the development section of the GRASS user's wiki

Accepted Ideas