[GRASS-dev] C replacement for d.vect.thematic
Moritz Lennert
mlennert at club.worldonline.be
Sat Dec 29 11:22:44 EST 2007
Hello everyone,
I have finally started living up to my many promises over the last year
about trying to write a C replacement for the d.vect.thematic script.
I have decided to split the script up into several modules as I think
d.vect.thematic is a bit overloaded. In the end I would like to come up
with something like:
- library functions for classification of vector attribute data using
different algorithms
- v.class: a module for classifying vector attribute data
- d.area.thematic: a module for choropleth area maps
- d.symbol.thematic: a module for line and point symbol thematic
mapping, including symbol size variation
- d.thematic.legend: a module which takes the output of the other two
d.* modules and draws a nice legend
At this stage I have the two first modules in a usable state, i.e.
v.class and d.area.thematic. For those interested, they are available at
[1]. I deliberately kept d.area.thematic very simple, forcing the user
to enter class breaks and colors, but you can use v.class -g to create
the class breaks for d.area.thematic (see example in description.html).
In my eyes it is better (and more in the spirit of GRASS) to create a
toolchain of small modules which can feed into each other. It should be
no problem combining them in a gui or a script.
I still need to enhance documentation (of the module and of the functions).
At this stage I have all the classification functions in a file with
v.class, but I think it would be good to move them to a library pretty
soon so that they can be shared by modules.
But before I go on (which in any case probably won't happen within the
next week), I have a few questions:
- Any fundamental disagreement with the general scheme (i.e. several
separate modules) ?
- I guess I should create a new library with vector stats functions,
which could then hold the classification functions, but also the
(currently named) dbCatValArray_stats function for basic stats. The
latter (+ extensions) could then also be used for e.g. v.univar. Any
suggestions as to where to put the library (lib/ or lib/vect) ? If in
lib, I suggest calling it libgrass_vstats as a counterpart to the raster
libgrass_stats. Any opposition ?
- Could someone look over the code to see if I have not done anything
bad ? The class_discont function in v.class/class.c is extremely
difficult to read and could do with some better variable naming and
probably refactoring. It is actually a direct translation of some 15-20
year old fortran code that we use inhouse, but as it works as it is, I'm
not sure I want to spend much time on that now.
As soon as I either get answers or just impatient, I'll upload the code
to svn, so that others can start hacking on it.
Moritz
[1] http://geog-pc40.ulb.ac.be/grass/thematic/
More information about the grass-dev
mailing list