Talk:GRASS SoC Ideas 2008: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(more structure)
Line 27: Line 27:
Are these projects large enough to be their own individual SoC projects or should they maybe be one?
Are these projects large enough to be their own individual SoC projects or should they maybe be one?


= other =
= Raster =
 
* GDAL based live-linking of raster maps to avoid import: r.external (from last year) via GDAL


* 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.
* 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.
Line 33: Line 35:
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>


= Vector =
* Implement new TIN algorithms from http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
* Implement new TIN algorithms from http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
Line 44: Line 47:
* reimplement v.delauny (also possibly by going via some other data structure)
* reimplement v.delauny (also possibly by going via some other data structure)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
= Statistics =


* R integration [there was some talk on this on the list]
* R integration [there was some talk on this on the list]
Line 49: Line 54:
* 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)
* 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)
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
**'''Willing to Mentor:''' Wolf Bergenheim <wolf+grass@bergenheim.net>
* r.external (from last year) via GDAL


= Ideas by Moriz Lennert =
= Ideas by Moriz Lennert =

Revision as of 23:00, 24 February 2008

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.

Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>

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)
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>

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]

wxGui

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

Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>

Are these projects large enough to be their own individual SoC projects or should they maybe be one?

Raster

  • GDAL based live-linking of raster maps to avoid import: r.external (from last year) via GDAL
  • 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?
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>

Vector

  • Implement new TIN algorithms from http://www.cs.cmu.edu/~jrs/jrspapers.html#dtstreamn and Digital elevation model construction from structured topographic data: The DEST algorithm (see list discussion)
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>
  • Expand v.generalize with new methods (e.g merging, exaggeration, collapse, displacement, point aggregation)
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>
  • rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in another datastructure, like winged edge)
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>
  • reimplement v.delauny (also possibly by going via some other data structure)
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>

Statistics

  • 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)
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>

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).
    • Willing to Mentor: Wolf Bergenheim <wolf+grass@bergenheim.net>