[GRASS-dev] C replacement for d.vect.thematic

[Moritz Lennert]

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/