[GRASS-dev] C replacement for d.vect.thematic
michael.barton at asu.edu
Mon Dec 31 10:34:18 EST 2007
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
> 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
>> 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!
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
More information about the grass-dev