[GRASS-dev] Google Summer of Code 2008

[Wolf Bergenheim]

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