[GRASS-dev] testing v.thematic.area

[Michael Barton]

On Mar 2, 2008, at 12:38 PM, Moritz Lennert wrote:

> On 01/03/08 21:53, Michael Barton wrote:
>> I just tested v.thematic.area and v.class. There still seems to be  
>> a problem with the v.class breaks.
>> I tried it with fields from Spearfish. I added a column named  
>> "area" with the area of each field.
>> d.thematic.area map=fields at PERMANENT column=area breaks='v.class - 
>> g map=fields at PERMANENT column=area algo=int nbcla=5'  
>> colors='blue,red,green,yellow,grey' bwidth=0 bcolor=black render=l
>
> You need to use backticks (`) and not simple quotes (') around the  
> v.class command.

OK. This works from the command line with the backquotes.

But it still doesn't work from the GUI. It renders all areas in the  
2nd color in the list. I've tried only backquotes, backquotes inside  
curly braces and inside regular quotes. Previously I tried no quotes  
at all, single quotes, double quotes, and curly braces. All give the  
same result--i.e., it's not executing v.class.

>
>> ...colors all fields with the 2nd color, whatever it is. But it  
>> will not use the other colors.
>> I notice that there is a lot of overlap in the information needed  
>> for v.thematic,area and v.class. It would make this easier to use  
>> and much easier to use in the GUI if we could simple pick  
>> algorithm and nbcla within d.thematic.area instead of having to  
>> insert a v.class command with duplicate info.
>
> I had the feeling that the current scheme better respects the KISS  
> principle and at the same time left the greatest flexibility. IMHO  
> combining the two should be done either via a script, or via the GUI.
>
> But if there is demand for adding an algorithm and a nbclasses  
> option to d.thematic.area, then that shouldn't be too difficult.

This may seem to be a simpler solution, but in terms of usability, I  
think the current way is problematic. Even if it did work in the GUI  
(whic it doesn't right now), the result would be that people using  
the GUI instead of the command line, would still have to type a  
command and embed it into a field in the GUI, probably using some  
kind of special delimiter (backquotes, quotes, etc -- and these might  
be different on Windows and other systems). This kind of obviates the  
advantages of the GUI.

Of course we could write a script or a custom GUI module, but then we  
have to create a new GUI by hand and change it any time the command  
changes. That is, we can't depend on the command parser to make a  
thematic mapping GUI. This also makes implementing the command  
considerably more complicated. My feeling is that if it is not too  
difficult, it would make using this command (and the upcoming  
v.thematic.pointline) a lot easier if it incorporated the v.class  
break generation routine. But I also think it is worth keeping  
v.class, if it's not too hard to maintain along with the other  
commands. It could be useful for a variety of purposes.

My 2.5c worth (inflation and declining dollar)

Michael