GRASS SoC Ideas 2012
- See also previous Google Summer of Code ideas from 2011.
This is the GRASS page for Google Summer of Code 2012. Here we will list project ideas and and other information related to the GRASS GSoC projects.
* OSGeo Flyer at
- 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
- 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
- Mentor will create directory structure in the GRASS add-ons SVN for projects and setup access for students
- Coding begins...
- Students and mentors: Complete the Mid-term survey
- Final commit and packaging for Google
- Project ideas of your own are also most welcome and often the best.
- Offer also (optional) "conventional" GUI layout: For some users, the current approach of separate windows (SDI) leads to a windows flooding. This is a common complaint especially from newbies. Especially on large monitors or dual screen systems catching the wxGUI windows can be tedious when they appear on separate monitors (depends on windows manager, the much used KDE scatters typically the wxGUI windows all over the screen real estate). Almost each task generates a new wxGUI window which is freely floating around on the screen: example 1 and example 2. On a dual-screen this may sum up to 50cm of distance! The idea is to capture all those windows in one frame. For details, see WxGUI#Layout.
- Add WMS and/or TiledMapService and/or WMS-T layer support for wxGUI. Tiles/WMS images should not be stored as GRASS rasters but only used for displaying purposes (i.e. stored in temp folder). Such tool should provide user-friendly setting choices based on service GetCapabilities response. GRASS WXGUI WMS service rendering project GSoC wiki page
- 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 NVIZ's animation tools, and the Movies creation wiki page. (co-mentor Helena Mitasova). , ,
- Your idea here
- Add RTENOTITLE parallelization where appropriate, for example , , . 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. A good working knowledge of ANSI C and OpenMP is required. (OpenCL and pthreads are fine too!)
- Create a new GRASS module to find the topographic_prominence of peaks from a raster elevation map within the region. (probably this would only make up 1/4 to 1/2 of a multi-part GSoC project)
- Expand maximum grid size for r.watershed. Lidar-based elevation grids are at finer resolution than previous elevation models, often overwhelming the integer variable limit for grid size.
- Your suggestion here!
Willing to Mentor: Hamish (co-mentor parallelization and prominence projects), (your name here)
- Add OpenMP parallelization where appropriate, for example, and (co-mentor Helena Mitasova). (OpenCL and pthreads are fine too!) 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.
- Add break lines support to interpolation modules (Geospatial Analysis - a comprehensive guide. 3rd edition for description. [*] well, some support exists, see . , , ). Current implementations provide no support to specify locations of cliffs or faults* thus leading to improper results within non-continous datasets. See
- Speed up wxGUI handling and 2D display of large point clouds (several million points). This is likely to include additional "Level-1 Vector" support in the backend modules (for which a working knowledge of ANSI C is req'd).
- Your idea here ...
- GRASS's imagery modules (for satellite, scanned maps, and orthophotos) act as enhanced raster modules. In GRASS 5 and 6 they were mostly implemented 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 (where appropriate; OpenCL and pthreads are fine too)
- In addition to the porting of the georectification tools mentioned above, it would be interesting to implement an orthorectification tool for satellite imagery. Currently, GRASS only has i.ortho.photo for aerial photographs.
- Implement image segmentation algorithms and tools
- Implement region-based classification
- Implement hierarchical classification tools (e.g. being able to create a large class "forest", with subclasses of different types of forests)
- Your idea here
Willing to Mentor: Hamish (co-mentor for parallelization), (your name here)
- Optimize OGSF (and NVIZ/wxNVIZ) to display large 3D point clouds with uninterupted tought speed. OGSF + (wx)NVIZ should be able to rotate point cloud (i.e. LiDAR dataset) with 4 millions of points on medium hardware (i.e. 2GHz CPU with 2Gb RAM and GPU with hardware transform and lighting support and dedicated video RAM) with response time not greater than 1.0 second.
- 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, SVG, and/or simple EPS symbols.
- Drape multiple color maps over topography (equivalent to running r.patch or r.composite and draping the result; second raster is currently supported as transparency).
Willing to Mentor: Martin Landa (for 2), co-mentor for 1 and 4: Helena Mitasova, (your name here)
- implement color management for 3D rasters : r3.colors
- develop r3.flow for computing 3D flow lines and 3D flow accumulation from 3D rasters
- enhance volume interpolation module for handling of data in space-time cube, including computation of gradients and hypercurvatures
Willing to Mentor: co-mentor Helena Mitasova, (your name here)
- See also the GRASS wish list
- Design and implement modern metadata management system for GRASS to support OGC CSW and INSPIRE discovery a view services
- Design sophisticated Python scripting interface for GRASS based on GRASS Python Scripting Library
- Your idea here
Willing to Mentor: (your name here)
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:
- If you are thinking about applying, do make a point of reading the "Flip bits not Burgers: The Student's Guide to the Summer of Code" eBook
Getting started with GRASS coding
- The source code is maintained in a SVN server which is easy to browse
- Please review the submitting files for our coding standards
- for C coding rules
- for Python coding rules
- for Documentantion coding rules
- There is lots of good info at the GRASS Developer's wiki
- See also the development section of the GRASS user's wiki
Guidelines for Mentors
- Project name
- Student: Your name here
- Mentor: Your mentor's name here
- Backup mentor: Your backup mentor's name here
- Wiki page: wiki page maintained by you (typically in this GRASS wiki, or the trac development wiki)
- Project name
- Student: Someone else's name here
- Mentor: Their mentor's name here
- Backup mentor: Their backup mentor's name here
- Wiki page: wiki page maintained by them (typically in this GRASS wiki, or the trac development wiki)