GRASS SoC Ideas 2009

About

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)

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.

• 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

Willing to Mentor: Martin Landa

• 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 and Markus's new g.extension module in GRASS 6.5+. Now available as g.extension and Extension (Addons) manager in GUI.

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

• Implement graphical modeller. It is implemented.

• Develop a graphical cartographic module - something like a GUI front-end or replacement for ps.map. Implemented outside GSoC as g.gui.psmap.

• Create a fully functional command line interface with history within the GUI (see suggestion) [update: now mostly complete]

• Develop a GUI module in wxPython for creating animations from multiple maps and saving animation outputs to animated GIF, MOV, or MPEG files. Implemented outside GSoC as g.gui.animation.

Kriging GUI

Note: has been implemented as v.krige (GSoC 2009)

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 pthread support for r.mapcalc is 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

--HB: IMO this is probably too far complete to justify a full SoC project. The r.viewshed module added to AddOns last year definitely needs a few bug fixes and cleanup before it can be moved to main GRASS, and I think that has to happen before it can be widely tested and the worth of extensions to it evaluated.

• 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: chosen as GSoC 2009 project]

• 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

Accepted Ideas

See: http://socghop.appspot.com/gsoc/org/home/google/gsoc2009/osgeo

• Network Analysis by Daniel Bundala

The goal of this project is to further develop vector network analysis in GRASS. This would involve computation of many centrality measures(degree, closeness, betweeness, eigenvalue…), requested v.net.distance module, time tables integrated into routing, various algorithms such max flows, min cuts, weakly and strongly connected components, minimum spanning trees, all pairs shortest paths, k-connectivity, articulation points, bridges, etc.

• v.krige by Anne Ghisla

As GRASS presently lacks kriging capability, it is performed via an add-on, v.autokrige, that delegates analysis to R (package automap). This module is written in bash and has the classical autogenerated GUI. The project aims to rewrite the module in Python, creating a new GUI in wxPython that allows the user to refine parameters. I therefore plan to examinate present v.autokrige code and port it into Python, possibly improving it at the same time, and add a wxPython GUI.

• OssimPlanet integration in Grass and Qgis by Massimo Di Stefano (Shared with OSSIM and QGIS)

Develop a plug-in for the ossimPlanet application for interface with other Open Source G.I.S software such as Grass and Qgis. This will allow export of elevation data from grass to OssimPlanet and add the ability to load Grass data (both raster and vector) in Ossim. The end result will be to synchronize the grass maps canvas extent with the Ossimplanet scene.