GRASS SoC Ideas 2008: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
m (→‎Ideas: intorduction)
 
(57 intermediate revisions by 8 users not shown)
Line 2: Line 2:
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.
This is the GRASS page for [http://wiki.osgeo.org/index.php/Google_Summer_of_Code Google Summer of Code] 2008. Here we will list project ideas and and other information related to the GRASS GSoC projects.


* For inspiration see the [[GRASS SoC Ideas 2007]] page
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 =
= Timeline =
* Community bonding time (getting to know the students)
 
* Work Begins
([http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline GSoC timeline])
* Midterm evaluation
 
* Pencils down!
* {{done}} Community bonding time (getting to know the students)
* {{done}} Deadline for student's applications: April 7th [closed]
* {{done}} Accepted proposals announced (April 21)
* {{done}} Work Begins (May 26th)
* {{done}} Midterm evaluation (July 7th-14th)
* {{done}} Pencils down! (August 11-18th)


= Required Steps =
= Required Steps =


* List ideas
* List ideas {{done}}
* Assign Mentors to Ideas
* Assign Mentors to Ideas {{done}}
* Notify OSGeo
* Notify OSGeo {{done}}
* Process Student Applications. Deadline XXX
* Mentors evaluate student applications. '''Deadline April 18th''' {{done}}
* YYY: Accepted Students Announced
* April 21st: Accepted students announced {{done}}
* SVN branches and access for students
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves. {{done}}
* Coding begins...
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students {{done}}
* Students and mentors: Complete the Mid-term survey.
** Students must read and post agreement to [http://download.osgeo.org/grass/grass6_progman/rfc/ RFC2] to the [http://grass.osgeo.org/community/support.php grass-psc mailing list] to gain SVN access.
* Final commit and packaging for Google.
** Create a Wiki page for each accepted project, to be used as a progress reporting tool
* Coding begins... {{done}}
* Students and mentors: Complete the Mid-term survey. {{done}}
* Final commit and packaging for Google. {{done}}


= Ideas =
= Ideas =
Line 26: Line 37:
Here are some ideas you can base your application on
Here are some ideas you can base your application on
===wxPython===
===wxPython===
These project ideas have to do with the new GUI of GRASS


====3D Visualization====
These project ideas have to do with the [[WxPython-based GUI for GRASS]] of GRASS.
GRASS has an old Tcl based n-dimensional visualization tool. However since we are moving over to the new wxPython-based GUI we will need something similar for the new GUI.
 
====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.
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.


You should keep in mind that the code has to be very well documented (even insanely well) to facilitate better expandability.
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).


'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton
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
 
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/README Description of the capabilities of the GRASS OpenGL gsurf library]
* [http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/TODO Bugs and issues in the gsurf library which may need to be resolved]


====Color management====
====Color management====
Line 43: Line 61:
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# Create a color and interval editor tool which should be able to create files which are compatible with r.reclass, r.colors and friends.
# 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.
# 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.
<strike># 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.</strike> cf: http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats


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


====SQL====
====SQL====
Line 54: Line 72:
'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton
'''Willing to Mentor:'''Wolf Bergenheim, Michael Barton


====Kriging====
:Note there is already [[WxPython-based GUI for GRASS#Attribute table manager|Attribute Table Manager]] in [[wxPython-based GUI for GRASS|wxPython GUI]], anyway [http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_modules/sqlbuilder.py SQL Builder] need complete reconstruction. -- ML (2008/03)
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:
==== Cartography ====
# Do Kriging based on gstat.
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.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# 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
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 [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|graphical cartography tool]] for GRASS.


==== Cartography ====
'''Willing to Mentor:''' Michael Barton, Hamish Bowman, Moritz Lennert
GRASS is mainly focused on Analysis, but it also has good map making tools. These tools 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
''Implemented outside GSoC as {{Cmd|g.gui.psmap}}.''
 
'''Willing to Mentor:''' Michael Barton, Hamish Bowman


==== v.what ====
==== v.what ====
Line 84: Line 91:
These projects involve the GRASS raster library.
These projects involve the GRASS raster library.


====r.external====
====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 on is unfortunately limited to importing raster maps.
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.
Your job would be to create this r.external too for GRASS.
Line 94: Line 101:
'''Willing to Mentor:''' Wolf Bergenheim (GRASS), Frank Warmerdam (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 [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d here].


==== Raster Database ====
See details at [[Time series in GRASS]]
In GRASS vector maps can be connected to a database table as an attribute table. Many commercial GIS packages also allow this for raster maps.
 
''Implemented outside GSoC as GRASS Temporal Framework (see {{cmd|temporalintro|version=70}}).''
 
====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 {{cmd|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.
<!-- Many proprietary GIS packages also allow this for raster maps. --HB: so what? -->


Your job would be to implement this connection.
Your job would be to implement this connection.


'''Willing to Mentor:''' Wolf Bergenheim
'''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:
# Do Kriging based on gstat.
#* Create and edit GStat command files
#* Call gstat to do variogram analysis
#* Call gstat to do the actual Kriging.
# 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:''' [[V.krige_GSoC_2009|Anne Ghisla]]


==== Raster Objects ====
==== Raster Objects ====
Implement an equivalent of eCognition's object-based classification (in contrast to pixel-based classification)
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 {{cmd|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 [[GRASS GSoC 2012 Image Segmentation|GSoC 2012]] as {{cmd|i.segment|version=70}} and improved later.''


=== Vector ===
=== Vector ===
These ideas relate to the Vector library of GRASS.
These ideas relate to the Vector library of GRASS.


==== v.buffer and v.parallel ====
==== v.buffer and v.parallel (Accepted; Completed)====
These two modules are broken and need to be reimplemented.
These two modules are broken and need to be reimplemented or deeply debugged with at least a partial rewrite.


'''Willing to Mentor:''' Wolf Bergenheim
'''Willing to Mentor:''' Wolf Bergenheim
Rosen's progress is [[GSoC Buffer Implementation|here]]


==== Implement file based spatial index ====
==== Implement file based spatial index ====
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
Read "Keep topology and spatial index in file instead of in memory" in [http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup Radim's Vector ToDo]
'''Willing to Mentor:''' Wolf Bergenheim


==== v.voronoi / v.delauny ====
'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert
These modules need to be reimplemented as they are quite old an sub-optimal. There are many good algorithms that can be used.
 
==== v.voronoi / v.delauny (Accepted; Completed) ====
These modules need to be reimplemented or deeply debugged as they are <!-- quite old and --HB: so what? --> sub-optimal. There are many good algorithms that can be used.
 
'''Willing to mentor:''' Wolf Bergenheim


==== v.generalize take two ====
==== v.generalize take two ====
Last year Daniel Bundala created the v.generalize module, and implemented many line generalization algorithms.
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)
This year we'd like to expand the module with implementing algorithms to do the following methods (as defined by McMaster)
* merging
* merging
* exaggeration
* exaggeration
Line 132: Line 190:


==== v.overlay ====
==== v.overlay ====
Extend v.overlay to allow all types of overlay operations for all types of vector (i.e. also points and lines)
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
'''Willing to Mentor:''' Wolf Bergenheim, Moritz Lennert


==== Uniforming vector modules ====
==== 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.
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.


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
'''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 [http://en.wikipedia.org/wiki/HyperbolicTree HyperbolicTree] style tag cloud would be cool.


= Guidelines for Students =
= Guidelines for Students =


How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing the mentor directly, or come and talk to us in IRC (#grass).
How do you maximize your chances of getting picked? First read the [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Google SoC FAQ]. Then talk to us about your idea. Try emailing [http://lists.osgeo.org/mailman/listinfo/grass-dev 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 ==


= Suggested Ideas =
* The source code is maintained in a [http://trac.osgeo.org/grass/browser/grass/trunk SVN server] which is easy to browse
: Please review the SUBMITTING files there.


See [[Talk:GRASS SoC Ideas 2008]]
* There is lots of good info at the [http://trac.osgeo.org/grass/wiki GRASS Developer's wiki]
: see also the [[Development|development section]] of the GRASS user's wiki


= Accepted Ideas =
= Accepted Ideas =
See: http://code.google.com/soc/2008/osgeo/about.html
{{GSoC}}

Latest revision as of 04:25, 6 February 2014

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