[GRASS-dev] Google Summer of Code 2008

Moritz Lennert mlennert at club.worldonline.be
Wed Feb 20 14:43:20 EST 2008


Some other ideas:

>From the GRASS 7.x ideas collection:
- implement file based spatial index (see "Keep topology and spatial index
in file instead of in memory" in Radim's Vector ToDo
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup)
- extend v.overlay to allow all types of overlay operations for all types
of vector (i.e. also points and lines)

More ambitious:
- implement an equivalent of eCognition's object-based classification (in
contrast to pixel-based classification)

Moritz

On Wed, February 20, 2008 17:04, Wolf Bergenheim wrote:
> 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
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>




More information about the grass-dev mailing list