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

[Moritz Lennert]

On 31/12/07 16:34, Michael Barton wrote:
> 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?

Yes, will do.

> 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.

Or we could just go for a g.class with rast= and vect= options...


> 
>>
>> 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?

Yes. The only issue will be size of the raster as in its current form it 
loads the entire vector of values into memory. Don't know how well it 
would handle 100 million cells...

> 
>>> 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).

After thinking about it some more, I actually tend towards separating 
them. Seems cleaner.

> 
> 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.
> 

On 01/01/08 00:52, Hamish wrote:
 > How would that differ from the current TclTk G_parser() RGB color
 > picker tool? Filled preview square of the appropriate color in the
 > module's GUI window?

I was still thinking in discrete classes with a color for each. In that 
case, a gui tool where you can decide on the number of classes and then 
chose a color for each class, seeing them all next to each other to be 
able to compare them.

See the attached thuban.png for what I mean. QGIS unfortunately does not 
allow this as you have to click on each class to see its attributes, 
including colors (qgis.png).

This is also useful for when you do not work with a color ramp, but 
rather with categorical data (e.g. land use classes).

Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis.png
Type: image/png
Size: 58079 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20080102/55396eb7/qgis-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thuban.png
Type: image/png
Size: 12707 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20080102/55396eb7/thuban-0001.png