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