[GRASS-dev] Google Summer of Code 2008

Sun Mar 9 05:09:53 EDT 2008

Hi all,

just some thought on the SoC project(s)

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

If this is just about feature labeling: I believe the people at
www.qgis.org have a similar SoC project in mind, so it might be possible
to cooperate with them on the basic collision detection algorithm(s).

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

Unless it also involves getting basic 3D topology into the GRASS
vector kernel: "point in sphere", some 3D object intersections,
voxel<->3D vector would all be challenging (especially if done
efficiently) things and VERY useful to future development of 3D
functionality in GRASS.

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

Using GFPU?

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

This could go together with a little C library that implements things
such as "natural breaks" and others which could then also be used
by r.reclass, v.reclass and possibly other modules that need to break
number ranges into discrete classes.

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

I believe this is the old idea of a "cell spaces", where a raster map
contains primary keys into database records holding values of
interest instead of the values themselves.
Apparently, such a data model aids the creation of object centric
models, such as cellular automata and agent based models.
You can totally do without it, same as you can totally do without
object-oriented programming languages. However, it does make certain
classes of models more elegant in design.
Anyway ArcGIS has it ;)

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

I absolutely agree that TINs are useless for terrain models. However,
They do represent an unaltered version of the original input data that
can be processed especially efficiently by GPUs and interchanged with
many external 3D modeling apps.
This they can be a VERY useful in general 3D vector modelling, e.g. for
processing laserscan clouds of objects on the terrain.
This would require a TIN algorithm that gracefully deals with true
3D data (including undercuts) and at best would be able to triangulate
any open or closed object surfaces/skins in 3D space (we discussed using
algorithms from e.g. qhull for this a while back; more interesting OS
algorithms here: http://meshlab.sourceforge.net/). In all cases, an open
source algorithm that does things like breaklines would be a big
step forward.

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

See above: the current module does not handle 3D input/output. Would
be easy enough to fix this, but might be more interesting to create
a unified module for 2D and 3D triangulation including the Delaunay
method.

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

SVG? This would easily go into OpenDraw, inkscape, etc.
We'd need to push legends, north arrow, map borders and grids
etc into SVG, as well.

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

Definitely a very weak point of GRASS currently. I think
we need to have really good kriging ASAP.

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

-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
benjamin.ducke at oxfordarch.co.uk