GRASS SoC Ideas 2008

From GRASS-Wiki
(Redirected from /GRASS SoC Ideas)
Jump to navigation Jump to search

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.

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 7th [closed]
  • √ Accepted proposals announced (April 21)
  • √ Work Begins (May 26th)
  • √ Midterm evaluation (July 7th-14th)
  • √ Pencils down! (August 11-18th)

Required Steps

  • List ideas √
  • Assign Mentors to Ideas √
  • Notify OSGeo √
  • Mentors evaluate student applications. Deadline April 18th √
  • April 21st: 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

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 (Accepted; Completed)

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

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

Note there is already Attribute Table Manager in wxPython GUI, anyway SQL Builder need complete reconstruction. -- ML (2008/03)

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

Implemented outside GSoC as g.gui.psmap.

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 (completed outside of GSoc)

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.

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

Implemented outside GSoC as GRASS Temporal Framework (see temporalintro).

Improved Line of Sight Analysis (Completed outside of GSoC: r.viewshed, but see trac #390)

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

the authors of r.viewshed have a modified version which corresponds to r.cva

Willing to Mentor: Paul Kelly

Raster attribute management in SQL 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.
See v.autokridge in Addons

Willing to Mentor: Wolf Bergenheim, Michael Barton

Assigned Student: Anne Ghisla

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. While GRASS has i.smap as segmentation algorithm this does not perform hierarchical classification. An idea might be to use the vector engine with topology for this.

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

Implemented in GSoC 2012 as i.segment and improved later.

Vector

These ideas relate to the Vector library of GRASS.

v.buffer and v.parallel (Accepted; Completed)

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

Willing to Mentor: Wolf Bergenheim

Rosen's progress is here

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 (Accepted; Completed)

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

Willing to mentor: Wolf Bergenheim

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). Support both topological (cut out) and simple features (take entire object) intersection and more.

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 lack 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

Manual related

  • Develop a searchable keyword navigator to easier find commands. Each command provides at least one keyword (should be more), a tree based navigator with free text entry could guide users through the available commands. Also a HyperbolicTree style tag cloud would be cool.

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-mailinglist, 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.
see also the development section of the GRASS user's wiki

Accepted Ideas

See: http://code.google.com/soc/2008/osgeo/about.html

Retrieved from "https://grasswiki.osgeo.org/w/index.php?title=GRASS_SoC_Ideas_2008&oldid=20169"