[GRASS-dev] Google Summer of Code 2008

[Wolf Bergenheim]

On 03/09/2008 11:09 AM, benjamin.ducke at ufg.uni-kiel.de wrote:
> 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).

Point-feature labeling with icons. I'm working on an automatic labeling 
module for GRASS whenever I have a few minutes to spare (unfortunately 
not as many minutes, nor often enough.. *sigh*) Hmm there might be some 
avenue of cooperation with qgis here. Is there anything in qgis that 
needs support in the GRASS side?

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

I agree :) We'd need someone with strong 3d skills to help mentor the 3d 
part.

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

Exactly! :)

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

:) yeah, replied before seeing your mail.

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

That would indeed be interesting.

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

I think it would be better to maybe focus on some sort of integration 
tool to the existing good Kriging tools out there.

--Wolf

-- 

<:3 )---- Wolf Bergenheim ----( 8:>