Talk:GRASS SoC Ideas 2008

From GRASS-Wiki
Revision as of 16:45, 21 February 2008 by Wolf (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Okay, making a raw dump of ideas here, so that we can more easily keep track of them.

Displaced symbols

  • Create a module to place map symbols on a map, so that the feature and other overlap information is minimized (NP-Complete problem). The map symbol should be referenced to their original location, by using a reference line.
    • Create new symbol file and add support for it to the GUI and a d.icon command, and to the PS driver.
    • Support native GRASS symbols, png, svg and others. Support specifying symbol in the database for each feature.

Mentor: Wolf Bergenheim <wolf+grass []>

Uniforming the vector modules

    • Vector 3D support. Make all vector modules work in 3D space.
    • Add where= and cats= to as many modules as possible, where reasonable (also see ml discussion on this)

Mentor: Wolf Bergenheim <wolf+grass []>

Line of sight

  • Improved line of sight (Paul Kelly's proposal from last year)
  • 3D Vector line of sight (related)
  • See [GRASS SoC Ideas 2007]


  • Graphical colour and interval and category selections. This would create a file which could be used in r.reclass, r.colors and friends. Maybe a similar tool for the vector equivalent?
  • create an SQL query builder tool to help build sql queries, if enough time add PostGIS queries [cooperation with PostGIS]
  • I've heard many complaints about GRASS lacking a Kriging module. One of these ideas could fix that (maybe both)
   * gstat GUI (would create gstat files, run gstat, and provide a GUI for all file editing tasks)
   * The same except would create an R script.

Mentor: Wolf Bergenheim <wolf+grass []>


  • raster db connections. The raster category value would be a cat in a database. Introduce maybe a new kind of map otherwise identical to an INT map, but the values should be treated as DB cat id's.
    • is this at all feasible?

Mentor: Wolf Bergenheim <wolf+grass []>

  • Implement new TIN algorithms from and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion) Mentor: Wolf Bergenheim <wolf+grass []>

  • Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)

Mentor: Wolf Bergenheim <wolf+grass []>

  • rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)

Mentor: Wolf Bergenheim <wolf+grass []>

  • reimplement v.delauny (also possibly by going via some other data structure)

Mentor: Wolf Bergenheim <wolf+grass []>

  • R integration [there was some talk on this on the list]
  • v.out.odg To create OO draw files (we could maybe collaborate with OO.o on this one, e.g. one mentor form each organisation)
  • r.external (from last year) via GDAL

Ideas by Moriz Lennert

implement file based spatial index

More ambitious:

  • implement an equivalent of eCognition's object-based classification (in

contrast to pixel-based classification)

Ideas by Helena Mitasova

Getting a start for the next generation visualization tool for GRASS - just a simple demo that can be done in 3 months to display surface(s) in 2D and smoothly transfer the view into 3D. Do we have a potential mentor? (I can be the second mentor, but we would need somebody to mentor the programming part).

Ideas by Michael Barton

  • v.what to 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).