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
- 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.
- 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 in wxNviz development.
- 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
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 grate a GUI (in wxPython) that can:
- Do Kriging based or 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.
- 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
Raster
- implement OpenMP (multithreading) as much as possible
Vector
- 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.
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.
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