Hello fellow developers.
Google Summer of Code is going to start again soon, and this year I'd
like to start preparation a bit ahead of time ;) I have been collecting
some SoC ideas over the previous year.
So before I dump them all to the wiki I'd like to hear some of your
comments.
* 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.
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)
* Improved line of sight (Paul Kelly's proposal from last year)
* 3D Vector line of sight (related)
* 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?
* 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?
* 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)
* Expand v.generalize with new methods (e.g merging, exaggeration,
collapse, displacement, point aggregation)
* create an SQL query builder tool to help build sql queries, if enough
time add PostGIS queries [cooperation with PostGIS]
* rewrite v.buffer / v.parallel (maybe need to remap the GRASS map in
another datastructure, like winged edge)
* reimplement v.delauny (also possibly by going via some other data
structure)
* 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)
* I've heard many complaints about GRASS lacking a Krigin 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.
r.external (from last year) via GDAL
Thoughts? More ideas? Listing an Idea won't require any commitment. I
think it is more important to get more ideas, later we will see who can
mentor what. (I suspect that we will have sround 2 slots this year for
GRASS)
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
