[GRASS-dev] Google Summer of Code 2008

[Helena Mitasova]

On Feb 20, 2008, at 2:43 PM, Moritz Lennert wrote:

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

I wanted to suggest this one too (this should also remove the need
for constant rebuilding of spatial index whenever you want to query  
vector data)
- we should try to find a way how to make this task sound exciting so  
that there
is an interest to do it - or maybe make it part of some of the vector  
processing topics
suggested by Wolf.

Another topic that I was thinking about was 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).

Helena


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