[GRASS-dev] Google Summer of Code 2008

[Hamish]

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.

I don't quite understand what you mean by map symbol. Automatic
placement for legends, north arrows, and scale bars? (Seems reasonable,
even if I'm not sure I'd ever use it personally)

Or for 'd.vect type=point icon=symbol_class/symbol_name'? (I don't
think we should be perturbing spatially referenced markers)


> * Create new symbol file and add support for it to the GUI and a
>    d.icon command, and to the PS driver.

Again, I'm not quite following what this is about.

see d.graph, and "d.stations" + "d.mark" in the wiki addons, and
  http://grass.gdf-hannover.de/wiki/IconSymbols

> * Support native GRASS symbols, png, svg and others. Support
> specifying symbol in the database for each feature.

see the .eps note at the end of the d.graph help page, and note that
ps.map already supports .eps symbols; AFAIR "svg2eps" may be done from
directly from the command line with inkscape's command line options.

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

it would be good to write down exactly which modules are involved.
"all" will not be appropriate.

I see this more of a chore than an interesting new project challenge.


> * Improved line of sight (Paul Kelly's proposal from last year)

Yes please

> * 3D Vector line of sight (related)

example of how/when this would be used?
 
> * 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?

how does this releate to the new thematic tools?

> * 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?

example of how/when this would be used?
 
> * Implement new TIN algorithms from

In my personal opinion TINs suck and we don't need them. They are
useful for a vector based GIS which lacks support for decent raster
interpolation tools. The ongoing demand for TINs seems to come from
users coming from other (historically vector based) GISs who have not
yet discovered GRASS's vector -> raster interpolation modules.


> * Expand v.generalize with new methods (e.g merging, exaggeration, 
> collapse, displacement, point aggregation)

a big enough project?

> * create an SQL query builder tool to help build sql queries, if
> enough time add PostGIS queries [cooperation with PostGIS]

interesting.


> * rewrite v.buffer / v.parallel

yes please.

> * reimplement v.delauny (also possibly by going via some other data 
> structure)

has it been established that the method is bad? I do not remember
seeing anything which would suggest that problems could not be solved
with some small bug fixing, in which case it would be silly to throw
the whole thing away and start a new module.


> * R integration [there was some talk on this on the list]

Roger: thoughts?


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

wouldn't it be better to go for something more generic, like improving
the postscript dispaly driver? (probably as part of GRASS 7)

> * 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.

this is related to the R integration threads.

 
> r.external (from last year) via GDAL

interesting.


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

thanks for spearheading this Wolf.


maybe we could trawl through wishes in the bug trackers for more
ideas..



Hamish



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs