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

[Michael Barton]

Moritz,

I'm really excited about this. Thanks so much for the efforts. I'll  
certainly try it out if I can (intensive proposal writing for the  
next week). In the meantime, here are a few comments based on your  
email and the html docs.

I agree with the idea of chaining smaller modules. d.vect.thematic is  
really complicated and bloated by having to include all the  
functionality into a single module.

v.class is similar to r.stats in what it does. You might want to  
consider naming it v.stats to make it easier for users to grok this  
similarity. I assume that v.class will also output to a text file?

I'd rename the thematic modules to d.thematic.area, d.thematic.point,  
d.thematic.legend. This lets them easily group in any alphabetical  
listing and clearly associates them. It also uses consistent GIS  
objects for the subname of each (i.e., point instead of symbol,  
because points and areas are the objects being displayed).

What about lines? Can v.class classify lines and boundaries, and  
d.area.thematic  display them by color and thickness? Or will that  
need another module?

Finally, is there any way to make use of color table capabilities,  
like used with r.colors? This would allow a lot of nice displays more  
easily than having to list colors.

Thanks again for doing this.

Michael



Can we make use of the kind of color tables used by r.colors to get  
color ramps in d.area.thematic?

On Dec 29, 2007, at 10:00 AM, grass-dev-request at lists.osgeo.org wrote:

>
> From: Moritz Lennert <mlennert at club.worldonline.be>
> Date: December 29, 2007 9:22:44 AM MST
> To: GRASS devel <grass-dev at lists.osgeo.org>
> Subject: [GRASS-dev] C replacement for d.vect.thematic
>
>
> 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/
>



____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20071229/7bbbd1ae/attachment.html