GRASS SoC Ideas 2009

About

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.

Promotion:

  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

Timeline

(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

Ideas

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

wxGUI

• 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)

• Implement new extension manager which downloads from GRASS Addons SVN (Unix based systems) or from precompiled Windows binaries (OSGeo4W?). See the R packages manager

• Continue wxNviz development for enhanced 3-4D visualization and analysis.

• Implement graphical modeller.

• Develop a graphical cartographic module - something like a GUI front-end or replacement for ps.map

• 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

• Develop a graphing toolkit that could be used by other modules and by GUI to create analytical graphs like histograms and scatter plots.

Raster

• implement OpenMP (multithreading) as much as possible
  • Experimental MP support for r.mapcalc is already done in GRASS 7svn
  • 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

• Enhance current visibility module to encompass cumulative viewshed analysis and related functions (see B. Ducke's site). Considerable code already started in AddOns

• Anisotropic spreading simulator. Bring wildfire simulation modules up to date in GRASS 6.4-7 and make them into a more general anisotropic spreading module (useful for other kinds of spreading phenomena).

Vector

• implement OpenMP multithreading) as much as possible
  • 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

• 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

--HB: looks like Martin has just done this using the GEOS library

• 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.

Imagery

• 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.

Other

• 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.

• There is lots of good info at the GRASS Developer's wiki

See also the development section of the GRASS user's wiki