GRASS SoC Ideas 2010

About

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

• Official Google Summer of Code 2010 homepage
• OSGeo SoC 2010 homepage

Promotion:

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

• √ Mentoring organization applications open (March 8-12)

• √ Accepted mentoring organizations announced (March 18)

• √ Interested students should initiate preliminary discussions with projects (March 18-29)

• √ Student applications open (March 29)
• Deadline for student's applications (April 9)

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

• Accepted proposals announced (April 26)

• Community bonding time (getting to know the students)

• Work Begins (May 24)

• Midterm evaluation (July 12-16)

• Pencils down! (August 9)
• Final evaluations submitted to Google (August 16)

Required Steps

• List ideas
• Assign Mentors to Ideas
• Notify OSGeo
• Mentors evaluate student applications
• 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 and 2009 which are still open.
• Project ideas of your own are also most welcome.

wxGUI

Willing to Mentor: Helena Mitasova (wxnviz, xganim), (your name here)

• wxGUI layout customization - reorganize the wxGUI layout to be more similar to QGIS and likeminded with all-in-one-frame interface (see figures 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 at all possible, this should be implemented as a skin to give users the choice to also use 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 wxNviz development for enhanced 3-4D visualization and analysis.
  • Update: accepted project for 2010

• Develop a graphical cartographic module GUI front-end for ps.map

  Willing to co-mentor: H.Bowman for ps.map advice but need to find a lead mentor who knows wxGRASS

  • Update 2011/03: Under development by Anna Kratochvilova, see GUI for ps.map
• 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, and nviz's animation tools.

• Implement graphical modeller.
  • Update 2011/03: Graphical modeler mostly implemented, see WxGUI Modeler

Raster

• 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

Vector

• Large vector maps: Currently a few modules which are important for massive datasets (like LIDAR data) are able to operate on maps which do not have topology built. (thus avoiding the associated per-feature memory overheads) It would be great if more modules could speak to these big-but-dumb maps (starting with v.info). This probably isn't enough for a full SoC project, so in addition the vector engine should be audited for places where memory optimization could take place.

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

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

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

• Design system for building manual pages based on DocBook system

• Design and implement modern metadata management system for GRASS to support 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 and/or SVG symbols.

• Zap-a-bug!: There are many old and neglected bugs in the three bug tracker(s). Reach 100 points by the end of the summer:
  • trival bugs are 1 point
  • minor bugs are 2 points
  • normal bugs are 3 points
  • major bugs are 4 points
  • critical bugs are 7 points
  • blocker bugs are 10 points

Rules: Bugs must be in the tracker before I thought of this idea (13 March 2010) and priority is counted from that time as well. (exemptions may be given for fixing wishes and newly reported critical|blocker bugs only with prior permission of both your mentor and co-mentor). Points for fixing old wishes may be allocated at the discretion of your mentor (but no more than 10pts per wish). The bug fix must include a code patch, and your mentor is explicitly responsible for deciding when a bug is done and marking it as "fixed" in the trac system, not you. You get no points for bugs fixed before the SoC officially starts, but it could impress the judges and allow you to get in enough practice to hit the ground running. Good sense of humor, communication skills, and a thick skin are a must, as you will not be working in isolation. Students who are officially enrolled at their university and the SoC program with the given name of "Frank" (or obvious lingual/gender equivalent) will start the summer with an automatic 10 points. Members of the dev team with SVN write access may award 1 bonus point per week for any bug fixed within that week if they are especially impressed with your solution.

(A great way to learn the entire GIS and get to know the dev team!)

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:

• The OSGeo SoC mailing list
• 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

Martin Landa

WxNviz development for enhanced 3/4D visualization and analysis

Seth Price

GPU accelerated imagery resampling and reprojection (GDAL+GRASS) - R.sun