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

[Michael Barton]

Thanks for the replies Moritz,

A couple responses.

On Dec 31, 2007, at 2:45 AM, Moritz Lennert wrote:

> On 29/12/07 18:25, Michael Barton wrote:
>> 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?
>
> It prints to standard output so you can redirect to a text file.  
> But I'm not sure I see how it is so similar to r.stats... Will  
> think about it.

Unless there is an explicit text out option, you cannot send to a  
file from the GUI. Can you add this?

Regarding r.stats, I guess I was thinking that it can give you cell  
counts according to a number of predefined user 'breaks'. Thinking  
more, it could certainly be nice if there was a raster module that  
did the same kind of classification as you've done here with vectors.  
So, reconsidering, I agree with the name v.class...and now wish for  
an r.class too.

>
> I'm actually also thinking about modifying the function to take  
> arbitrary float vectors, and not dbCatValArrays, thus allowing the  
> classification of any data, not only vector, and also avoiding to  
> carry around a whole dbCatValArray structure where only the actual  
> values are needed.

Does this raise the possibility of an r.class?

>> 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?
>
> For me lines and points are symbols and I put them together into  
> d.symbol.thematic, but I guess we should split them.

I see no problem combining these, especially since both rely on  
varying size and color. I could also see putting the line functions  
in with areas so that area boundaries could be visually classified.  
Or doing lines as a separate module. But if combined, the name should  
probably reflect such combinations (e.g., d.thematic.ptln or some  
such thing).

>
>> 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.
>
> This would be great. I have also been thinking about a way to  
> integrate the ColorBrewer palettes. Don't know their exact  
> licensing, but I think uDig has integrated them, so should be  
> possible. This could then lead to a g.colorbrewer which allows you  
> to chose a palette according to different criteria and then output  
> it for d.thematic or other modules.
>
> I think it would also be great to have a GUI colorchooser module,  
> but I think this will have to be a GUI element as IIUC g.parser  
> does not allow for color buttons to change according to the color  
> you chose and thus you cannot see all the colors you chose side by  
> side (one of the most annoying things in QGIS IMHO).

If d.thematic.* modules could use the color table approach, a GUI  
could indeed be created for visual color picking. Take a look at the  
GUI for d.vect.thematic in the TclTk GIS manager. In fact, the  
wxPython version of automatic GUI dialog builder for GRASS commands  
(menuform.py) currently creates a colored button that launches a  
visual color picker for fields that take a color value.

I consider the current GUI for color rules in the TclTk and wxPython  
GUIs as only a stop-gap. Ultimately, I'd like to have a GUI for color  
table creation sort of along the lines of the one for point  
classification in NVIZ.

> So, yes, lot's left to do...

But this is a really great start. Thanks!

Michael
____________________
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>