GRASS-Wiki - User contributions [en]

GSoC Buffer Implementation

2008-05-04T15:32:26Z

⚠️RMatev: /* Bugs in current implementation */

This page will show my progress on my GSoC project ([http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BB6EFE9C7844B517 Abstract])

== Bugs in current implementation ==
* '''v.parallel''', '''v.segment'''
** See [http://trac.osgeo.org/grass/ticket/90 Ticket #90]. Try the following to recreate the bug:
<pre>
v.parallel dist=500 input=railroads output=rail_par500
g.region n=4928200 s=4921100 w=605600 e=613200
</pre>

* '''v.buffer'''
** A bug from [http://intevation.de/rt/webrt?serial_num=2765 old RT tracker]. Both of the output maps are bad. See pictures on the first row [http://kufaya.googlepages.com/v.bufferbug%232765 here]

''ditch_1205.txt''
<pre>
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
</pre>
<pre>
v.in.ascii -n format=standard output=ditch_1205 input=ditch_1205.txt
v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
</pre>

== TODO List ==

GSoC Buffer Implementation

2008-04-29T23:11:40Z

⚠️RMatev: /* Bugs in current implementation */

This page will show my progress on my GSoC project ([http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BB6EFE9C7844B517 Abstract])

== Bugs in current implementation ==
* '''v.parallel'''
** This generates copy of railroads (at least it looks like one). When I try dist=501, things seem alright. See [http://trac.osgeo.org/grass/ticket/90 Ticket #90]
<pre>
v.parallel dist=500 input=railroads output=rail_par500
</pre>

* '''v.buffer'''
** A bug from [http://intevation.de/rt/webrt?serial_num=2765 old RT tracker]. Both of the output maps are bad. See pictures on the first row [http://kufaya.googlepages.com/v.bufferbug%232765 here]

''ditch_1205.txt''
<pre>
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
</pre>
<pre>
v.in.ascii -n format=standard output=ditch_1205 input=ditch_1205.txt
v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
</pre>

== TODO List ==

GSoC Buffer Implementation

2008-04-29T23:09:05Z

⚠️RMatev:

This page will show my progress on my GSoC project ([http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BB6EFE9C7844B517 Abstract])

== Bugs in current implementation ==
* '''v.parallel'''
** This generates copy of railroads (at least it looks like one). When I try dist=501, things seem alright. See [http://trac.osgeo.org/grass/ticket/90 Ticket #90]
<pre>
v.parallel dist=500 input=railroads output=rail_par500
</pre>

* '''v.buffer'''
** A bug from [http://intevation.de/rt/webrt?serial_num=2765 old RT tracker]. Both of the output maps are bad.

''ditch_1205.txt''
<pre>
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
</pre>
<pre>
v.in.ascii -n format=standard output=ditch_1205 input=ditch_1205.txt
v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
</pre>

== TODO List ==

GSoC Buffer Implementation

2008-04-29T22:53:47Z

⚠️RMatev:

This page will show my progress on my GSoC project ([http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BB6EFE9C7844B517 Abstract])

== Bugs in current implementation ==
* '''v.parallel'''
** ''v.parallel dist=500 input=railroads output=rail_par500'' - This generates copy of railroads (at least it looks like one). When I try dist=501, things seem alright. See [http://trac.osgeo.org/grass/ticket/90 Ticket #90]

* '''v.buffer'''
** <source>v.in.ascii -n format=standard</source>

== TODO List ==

GRASS SoC Ideas 2008

2008-04-27T12:04:23Z

⚠️RMatev: /* v.buffer and v.parallel */

= About =
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.

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 =

([http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline GSoC timeline])

* {{done}} Community bonding time (getting to know the students)
* {{done}} 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 {{done}}
* Assign Mentors to Ideas {{done}}
* Notify OSGeo {{done}}
* Mentors evaluate student applications. '''Deadline April 18th'''
* April 21st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves.
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** 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.
** 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

* [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====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# 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.
<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, 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 [[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)

==== 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 [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|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 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup 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 [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d 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:
# 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.

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

Rosen's progress is [[GSoC Buffer Implementation|here]]

==== 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]

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

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

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

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

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

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

* 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 =

[[Category:Development]]
[[Category:Community]]

GRASS SoC Ideas 2008

2008-04-27T12:03:33Z

⚠️RMatev: /* v.buffer and v.parallel */

= About =
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.

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 =

([http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline GSoC timeline])

* {{done}} Community bonding time (getting to know the students)
* {{done}} 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 {{done}}
* Assign Mentors to Ideas {{done}}
* Notify OSGeo {{done}}
* Mentors evaluate student applications. '''Deadline April 18th'''
* April 21st: Accepted students announced
* Students subscribe to the [http://grass.osgeo.org/community/support.php grass-dev mailing list] and introduce themselves.
* Create directory structure in the [http://trac.osgeo.org/grass/browser/grass-addons GRASS add-ons SVN] for projects and setup access for students
** 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.
** 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

* [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====
GRASS has good color management features, but lacks a good UI to mange colors.

Your job would be to extend the wxPython GUI to
# 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.
<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, 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 [[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)

==== 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 [[WxPython-based_GUI_for_GRASS#Cartography:_GUI_front_end_for_ps.map|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 [http://freegis.org/cgi-bin/viewcvs.cgi/grass/gips/gip-0002.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup 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 [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.rast4d 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:
# 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.

'''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
Rosen's progress is [[GSoC Buffer Implementation|here]]

==== 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]

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

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

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

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

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

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

* 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 =

[[Category:Development]]
[[Category:Community]]

GSoC Buffer Implementation

2008-04-27T11:49:24Z

⚠️RMatev: New page: This page will show my progress on my GSoC project ([http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BB6EFE9C7844B517 Abstract]) == TODO List ==

This page will show my progress on my GSoC project ([http://code.google.com/soc/2008/osgeo/appinfo.html?csaid=BB6EFE9C7844B517 Abstract])

== TODO List ==