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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
