GRASS SoC Ideas 2008

About

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

Timeline

• http://wolf.bergenheim.net/tmp/check.png Community bonding time (getting to know the students)
• Work Begins (May 28th)
• Midterm evaluation (July 14th)
• Pencils down! (August 11th)

Required Steps

• List ideas http://wolf.bergenheim.net/tmp/check.png
• Assign Mentors to Ideas http://wolf.bergenheim.net/tmp/check.png
• Notify OSGeo http://wolf.bergenheim.net/tmp/check.png
• Process Student Applications. Deadline April 10th
• April 14th: Accepted Students Announced
• SVN branches and access for students
  • 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

Here are some ideas you can base your application on

wxPython

These project ideas have to do with the WxPython-based GUI for GRASS of GRASS.

3D Visualization

3-D visualization in GRASS is currently achieved using the ageing "Nviz" tool. Nviz is a hybrid Tcl/TK and C application, which makes extending and improving it a very complicated task. GRASS is moving to a new wxPython-based GUI and the task of 3-D visualization needs to be integrated with this new GUI.

This is potentially a very large task, but in 3 months we would expect to have a workable demo (but release quality code ;)) to display surface(s) in 2D and smoothly transfer the view into 3D. GUI needs to be consistent with the new wxPython GUI for GRASS.

NVIZ is itself a frontend to the underlying OpenGL gsurf library (part of GRASS) which reads GRASS datasets and interfaces with OpenGL at a C API level. It is anticipated that this approach will be retained with the new GUI. Thus one approach to the task might be to "clean and tidy" this library and develop a modular interface to it, i.e. to develop individual GRASS modules to access the 3-D visualization functionality directly without having to use NVIZ. This would make the 3-D visualization capabilities of GRASS "scriptable" and possible to run in a modular way from any GUI toolkit. The development of a wxPython frontend would then be a simple exercise in user interface design and consistent with the way the GUI interfaces with other GRASS modules (other than v.digit, which is also a hybrid C application).

Other approaches may also be possible. You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.

Willing to Mentor:Wolf Bergenheim, Michael Barton, Paul Kelly

• Description of the capabilities of the GRASS OpenGL gsurf library
• Bugs and issues in the gsurf library which may need to be resolved

Color management

GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to

1. Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
2. A similar tool for vector data would also be very nice, which would simply store the colors in the GRASSRGB column of the attribute table.

# For added fun a C library that implements things such as "natural breaks" and others which could then also be used by r.reclass, v.reclass and possibly other modules that need to break number ranges into discrete classes. cf: http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats

Willing to Mentor:Wolf Bergenheim, Michael Barton, Moritz Lennert

SQL

GRASS has excellent SQL support, however many people who are using GRASS are not SQL gurus.

Your job would be to create a SQL query builder to help build SQL queries. Additional cool features are welcome!

Willing to Mentor:Wolf Bergenheim, Michael Barton

Cartography

GRASS is mainly focused on Analysis, but it also has good map making tools. These tools have a strong back end but lack a good GUI.

Your job would be to create a GUI for the ps.map tool which creates PostScript maps. This would be a first step towards a graphical cartography tool for GRASS.

Willing to Mentor: Michael Barton, Hamish Bowman, Moritz Lennert

v.what

Your job would be to make v.what take xy coordinates (single xy or line of xy's with a buffer distance to find stuff within that buffer distance of the coordinates; set of at least 3 xy's to ID a polygon and find the stuff within it).

Willing to Mentor: Michael Barton

Raster

These projects involve the GRASS raster library.

r.external: Virtual raster map linking

GRASS can link to external vectors (as well as importing them) vi the GDAL OGR library. On the raster side the user still has to always import raster maps.

Your job would be to create this r.external too for GRASS.

• See the GRASS raster "live links" proposal for more information.

This project will be done in cooperation with GDAL.

Willing to Mentor: Wolf Bergenheim (GRASS), Frank Warmerdam (GDAL)

Time series management in GRASS

A lot of people seem to be interested in having some standardized, documented format for dealing with time series in GRASS, so that we can deal with data (e.g. climate station, water gauges), link with models, etc., without having to come up with a custom solution each time. This could also lead to modules to help with interpolation to deal with missing values, etc. A SQL based raster/vector map management is desired. A prototype is available here.

See details at Time series in GRASS

Improved Line of Sight Analysis

Line of sight determination is a very important analysis to have available in a GIS. The GRASS module that currently performs this function, r.los, has a number of limitations, including being very slow to run and unable to handle large high-resolution datasets. The task: write a new r.los module based on the paper 'A Fast Algorithm for Approximate Viewshed Computation' published in 'Photogrammetric Engineering & Remote Sensing' July 2003: http://www.asprs.org/publications/pers/2003journal/july/2003_jul_767-774.pdf Incorporate features of r.cva (http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html), which cannot currently be incorporated in GRASS for licensing reasons, and extend with other functionality as appropriate.

The work will involve familiarisation with the GRASS raster library for reading and writing maps, the GRASS vector library for reading analysis location sites. It is expected that the GRASS directed graph library will also be useful for implementing many features of the algorithm (specifically, determining the crossing points and distances between the cells).

Willing to Mentor: Paul Kelly

Raster Database

In GRASS vector maps can be connected to a database table as an attribute table. GRASS's CELL (integer) maps include label support via the v.category module. Currently this is rather basic, labels may have a dynamic component but they are still just labels (see the r.category help page; e.g. using the Spearfish sample dataset: "r.report landcover.30m", "r.category geology", ). The idea is to seamlessly link the CELL value with a integer "cat" column in a database table. That cat ID in the database would be linked to any number of other attributes. Once the DB connection is made, a method of raster cell selection by SQL query would be needed. See the db.* and v.db.* modules for GRASS's existing database management code.

Your job would be to implement this connection.

Willing to Mentor: Wolf Bergenheim, Hamish Bowman

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:

1. Do Kriging based on gstat.
   • Create and edit GStat command files
   • Call gstat to do variogram analysis
   • Call gstat to do the actual Kriging.
2. 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.

Willing to Mentor:Wolf Bergenheim, Michael Barton

Raster Objects

Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification). See GRASS's existing i.* imagery modules for current clustering and classification modules.

Willing to Mentor: Moritz Lennert (as second mentor for the contents, not the programming)

Vector

These ideas relate to the Vector library of GRASS.

v.buffer and v.parallel

These two modules are broken and need to be reimplemented or deeply debugged with at least a partial rewrite.

Willing to Mentor: Wolf Bergenheim

Implement file based spatial index

Read "Keep topology and spatial index in file instead of in memory" in Radim's Vector ToDo

Willing to Mentor: Wolf Bergenheim, Moritz Lennert

v.voronoi / v.delauny

These modules need to be reimplemented or deeply debugged as they are sub-optimal. There are many good algorithms that can be used.

v.generalize take two

Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.

This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMAster)

• merging
• exaggeration
• collapse
• point aggregation

Willing to Mentor: Wolf Bergenheim

v.overlay

Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines; i.e. merge in v.select)

Willing to Mentor: Wolf Bergenheim, Moritz Lennert

Uniforming vector modules

GRASS has over 100 vector modules (many of which have multiple functions), and many of these modules very different input parameters, and lach where= and cats= parameters.

Your job would be to clean up these modules and that way ease the learning curve of GRASS.

(would happen in the GRASS 7 development branch)

Willing to Mentor: Wolf Bergenheim

Auto-tuning for spline surface interpolation

GRASS's regularized spline with tension (RST) modules* do a very nice job of generating raster surfaces from point data (often massive point datasets) using a thin plate spline method. Good results currently require a lot of trial and error to fine-tune the modules' tension and smoothing parameters to match the input data and deal with segmentation jumps when the input data points are not evenly distributed in space. Your job would be to implement auto-tuning algorithms into the RST modules to short circuit the manual trial and error process, possibly taking advantage of the existing cross-validation support.

[*] v.surf.rst (2.5D), v.vol.rst (3D), r.resample.rst

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 the mentor directly, or come and talk to us in IRC (#grass).