[GRASS-dev] Google Summer of Code 2008
wolf+grass at bergenheim.net
Tue Mar 11 11:52:16 EDT 2008
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
>>> * 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 ;)
:) yeah, replied before seeing your mail.
>>> * reimplement v.delauny (also possibly by going via some other data
>> 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
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.
<:3 )---- Wolf Bergenheim ----( 8:>
More information about the grass-dev