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

[cmbarton]

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@lists.osgeo.org wrote:

From: Moritz Lennert <mlennert@club.worldonline.be>

Date: December 29, 2007 9:22:44 AM MST

To: GRASS devel <grass-dev@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>

[neteler]

Great efforts!

On Dec 29, 2007 6:25 PM, Michael Barton <michael.barton@asu.edu> wrote:
...

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

that would be cool, see
http://wald.intevation.org/tracker/?func=detail&aid=382&group_id=21&atid=188
"v.colors -> add raw colr rules file parsing to r.what.color"

for related ideas.

Markus

[Hamish]

Moritz:

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.

This is good. thanks!

- d.symbol.thematic: a module for line and point symbol thematic
mapping, including symbol size variation

It would be easy to make up a prototype script using d.graph, also very
easy to use the d.graph C source to quickly make something like this.

It will be nice to be able to make things like bubble graphs in one
place. Right now you can use d.vect.chart (pie, 1 column), v.buffer
(sizecol=), d.vect (in a loop with SQL), d.graph, ps.map, ... to do
that, but it is not very clean/clear.

Variables to consider are size, color(s), rotation. Colors can be
specified as primary/secondary which is more flexible than line/fill.
See d.graph, d.vect source. ps.map even allows symbol by cat number
(via dynamic .eps filename).

Michael:

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

I agree. Consistency and intuitiveness are so very important. They
short circuit the nasty learning curve.

Michael:

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

Markus:

that would be cool, see

http://wald.intevation.org/tracker/?func=detail&aid=382&group_id=21&atid=188

"v.colors -> add raw colr rules file parsing to r.what.color"
for related ideas.

Support for parsing the r.color table format would be great. I think it
is very resource wasteful to store a full GRASSRGB varchar(11) column
for every category if you don't need to. e.g. displaying vector LIDAR
data which has no DB table where you want the size=0 "x" symbol's color
to change with elevation. Please reuse the same colr/ table format!

Personally I prefer a constant color gradient, not stepped/binned
legend like Arc produces. I consider that to be a relic from the days
of 16 or 256 max color pallets. Of course I work with mostly FP data
and not categorical, so I'm biased. I guess the legend should follow
the nature of the data, be it categorical, a continuous linear range, a
continuous logarithmic range, a +/- differences map centered on 0, etc.
Anytime you introduce an unneeded histogramming step you are getting
dangerously near to writing a new chapter for "How to lie with
statistics" (great book).

2c,
Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

[mlennert]

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.

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.

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

ok.

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.

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

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

Moritz

[mlennert]

On 30/12/07 02:32, Hamish wrote:

- d.symbol.thematic: a module for line and point symbol thematic mapping, including symbol size variation

It would be easy to make up a prototype script using d.graph, also very
easy to use the d.graph C source to quickly make something like this.

I was planning on using d.vect and my d.vect.chart2 as basis to create a module which uses any of the GRASS symbols. Any reason I should prefer d.graph ?

It will be nice to be able to make things like bubble graphs in one
place. Right now you can use d.vect.chart (pie, 1 column), v.buffer
(sizecol=), d.vect (in a loop with SQL), d.graph, ps.map, ... to do
that, but it is not very clean/clear.

That's exactly what d.thematic.point should do: allow the display of point data with any arbitrary symbol whose size can vary in proportion to one attribute (or expression) and whose color can vary according to another attribute (or expression).

We really do need an easy way to create GRASS symbols though...

Variables to consider are size, color(s), rotation.

Hadn't thought about rotation, but that would definitely be good...

Colors can be
specified as primary/secondary which is more flexible than line/fill.

> See d.graph, d.vect source.

I'm not sure I understand what this means. I'll look into the d.graph and d.vect source to see if I see what you're hinting at.

ps.map even allows symbol by cat number
(via dynamic .eps filename).

Yes, I love this feature which allows nice combination of R and GRASS for symbols. Don't know how feasible this would be for normal display, though, unless we allow the display of eps symbols...

Support for parsing the r.color table format would be great. I think it
is very resource wasteful to store a full GRASSRGB varchar(11) column
for every category if you don't need to. e.g. displaying vector LIDAR
data which has no DB table where you want the size=0 "x" symbol's color
to change with elevation. Please reuse the same colr/ table format!

Would be great, yes.

Personally I prefer a constant color gradient, not stepped/binned
legend like Arc produces. I consider that to be a relic from the days
of 16 or 256 max color pallets. Of course I work with mostly FP data
and not categorical, so I'm biased. I guess the legend should follow
the nature of the data, be it categorical, a continuous linear range, a
continuous logarithmic range, a +/- differences map centered on 0, etc.
Anytime you introduce an unneeded histogramming step you are getting
dangerously near to writing a new chapter for "How to lie with
statistics" (great book).

Interesting point. Will have to think about it. In human geography categorising data to display in discrete classes is the usual way of doing things. But I don't know whether there are any other reasons for it than technical relics and a desire for simplification. In any case, I think that discrete ranges should still remain a possibility.

Moritz

[cmbarton]

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>

[Hamish]

ichael:

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

Moritz:

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.

see r.cpt2grass on the wiki addons page.

* r.cpt2grass is a GRASS script for importing a GMT .cpt color table
into GRASS. It can save to a text file suitable for r.colors or
automatically apply the color table to a raster map.
For a large collection of GMT .cpt files see
http://sview01.wiredworkplace.net/pub/cpt-city/

download: http://hamish.bowman.googlepages.com/grass_color_maps

I don't know about ColorBrewer, will have to look into that. But you
just have to parse into the "r.colors color=rules << ..." format.

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

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?

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[Hamish]

Moritz:

>> - d.symbol.thematic: a module for line and point symbol thematic
>> mapping, including symbol size variation

Hamish:

> It would be easy to make up a prototype script using d.graph, also
> very easy to use the d.graph C source to quickly make something
> like this.

Moritz:

I was planning on using d.vect and my d.vect.chart2 as basis to
create a module which uses any of the GRASS symbols. Any reason I
should prefer d.graph ?

Only that d.graph is a simpler and cleaner example.
I am not familiar with d.vect.chart2 yet.

We really do need an easy way to create GRASS symbols though...

?
D_symbol() and D_symbol2() should be very easy to use. Examples are
given in the functions source code comments (lib/display/symbol.c) and
implemented in d.graph, d.vect, ...
see wiki add-ons page for tips on authoring new symbols (svg->grass
symbol format would be a nice add-on tool)
?

> Variables to consider are size, color(s), rotation.

Hadn't thought about rotation, but that would definitely be good...

I don't know when you would want to use it, but line width is another
controllable variable.

> Colors can be specified as primary/secondary which is more
flexible than line/fill. See d.graph, d.vect source.

I'm not sure I understand what this means. I'll look into the
d.graph and d.vect source to see if I see what you're hinting at.

see D_symbol2(). Basically for the "x" symbol you want the lines drawn
in the primary color, but for the "o" symbol you want it filled in the
primary color with the border line being in the secondary color.

> ps.map even allows symbol by cat number
> (via dynamic .eps filename).

Yes, I love this feature which allows nice combination of R and GRASS

for symbols. Don't know how feasible this would be for normal
display, though, unless we allow the display of eps symbols...

It is a wish for many years to get a simple eps -> d.graph translating
script.

Hamish:

> Personally I prefer a constant color gradient, not stepped/binned
> legend like Arc produces. I consider that to be a relic from the
> days of 16 or 256 max color pallets. Of course I work with mostly
> FP data and not categorical, so I'm biased. I guess the legend
> should follow the nature of the data, be it categorical, a
> continuous linear range, a continuous logarithmic range, a +/-
> differences map centered on 0, etc. Anytime you introduce an
> unneeded histogramming step you are getting dangerously near to
> writing a new chapter for "How to lie with statistics" (great

book).
Moritz:

Interesting point. Will have to think about it. In human geography
categorising data to display in discrete classes is the usual way of
doing things. But I don't know whether there are any other reasons
for it than technical relics and a desire for simplification.

The critical thing is who chooses where the bounds of those discrete
classes lie, & why. Based on a power or multiple of 10? Then based on
the genetic accident that we have 10 fingers, and thus usually count in
base 10 and bias towards that. And nature generally works in spectrums
not hard dichotomies, which are often false simplifications by us. This
is of course a much wider question than just GRASS, but ....

Michael mentioned rasters and r.stats, before writing any code note
GRASS automatically calculates some histogram data for rasters and / or
r.univar percentile= in a loop can get you that data.
(??) This also affects the GUI rewrite of d.histogram.

In any case, I think that discrete ranges should still remain a
possibility.

Sure, if people want that, go for it. I just don't like making the new
+ default behaviour a known (self-)deceptive solution, without at least
offering the better alternative.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

[mlennert]

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

(attachments)

[Florian_Kindl]

Jerry:

Personally I prefer a constant color gradient, not stepped/binned
legend like Arc produces. I consider that to be a relic from the days
of 16 or 256 max color pallets. Of course I work with mostly FP data
and not categorical, so I'm biased. I guess the legend should follow
the nature of the data, be it categorical, a continuous linear range, a
continuous logarithmic range, a +/- differences map centered on 0, etc.
Anytime you introduce an unneeded histogramming step you are getting
dangerously near to writing a new chapter for "How to lie with
statistics" (great book).

Moritz:

Interesting point. Will have to think about it. In human geography
categorising data to display in discrete classes is the usual way of doing
things. But I don't know whether there are any other reasons for it than
technical relics and a desire for simplification. In any case, I think that
discrete ranges should still remain a possibility.

Hello,
I'd like to give my opinion on this from a cartographic point of view:
Forming classes by assigning the same color to a range of values does
not come from any technical limitations. It is an established and
necessary technique in cartography.
The reason is to make a map a) readable and b) not to pretend accuracy.

ad a):
Even though the computer can distinguish millions of colours and screen
or print devices technically may be able to reporoduce several hundreds
of thousands, this does not allow for the use of so many shades for a
map. The reason for this is that the human eye can only distiguish some
tens of different shades, and about ten or so of the same hue.

ad b):
The use of a "pseudo-continuous" (using so many shades that we can't see
the difference, you get the crucial point here?) color ramp tries to
mimic a high level of accuracy in the data presented. However, that
accuracy does not reach the reader of the map as we cannot reliably
connect one position on the color ramp to a given pixels color on the
map.
Additionally, the value resolution of the color ramp could exceed
the precision of the values.
For example, a DEM has values from 0 to 1000 meters. You colour it with a
ramp of 100000 shades, therefore claiming an accuracy of height of 1 cm in
your map. Unlass you have such precise data, that is just nonsense. Even
if one was able to distinguish one value from the other.

To address your concern of "lying with statistics":
It lies in the responsibility of the cartographer to make a map which
conveys its message in the best way. Of course it is possible to make
very biased maps by categorizing values. How the map-maker decides this
is a matter of his own goals and ethics, which I cannot judge here, and a
question of following cartographical rules, which you find condensed in
the any textbook on cartography.

To conclude:
If a GIS wants to produce output that possesses cartographic quality,
the possibilibity to categorize cannot be left out.

Sincerely,
Florian Kindl

--
Mag. Florian Kindl
Geographie Innsbruck

[Hamish]

Michael Barton wrote:

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.

r.reclass with support for FP maps and an option to automatically
calculate the break points?

As for splitting d.vect.thematic into 3 d.vect.themearea/point/line
modules, that should be decided based on the command line option
interface. Do you mean cleaner to code or cleaner user interface?
How much overlap is there in the module options? GUI tabs can help with
complicated UIs a lot... (opt->gui_section)

If they share very similar UIs but the code is all different they
should be in one module compiled from multiple C functions+files...

The current d.vect is probably too complicated for one user module, but
having 400+ modules is also very complicated in another way.

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[mlennert]

On 02/01/08 22:22, Hamish wrote:
  > As for splitting d.vect.thematic into 3 d.vect.themearea/point/line

modules, that should be decided based on the command line option
interface. Do you mean cleaner to code or cleaner user interface?

User interface. Code shouldn't be much trouble...

How much overlap is there in the module options? GUI tabs can help with
complicated UIs a lot... (opt->gui_section)

If they share very similar UIs but the code is all different they
should be in one module compiled from multiple C functions+files...

d.thematic.symbol/d.thematic.ptln [-lnx] map=name data=string breaks=string[,string,...] colors=string[,string,...] [icon=string] [lstyle=string] [secondary_color=string] [size=value] [sizecolumn=string] [scale=value] [rotation=value] [layer=value] [where=sql_query] [render=string] [--verbose] [--quiet]

unique options with defaults in parentheses:

unique to points: icon(=circle), secondary_color(=black), rotation(=0)
unique to lines: lstyle(=full line) (supposing that this will be possible with a new display system in grass 7.x), render(=l) (irrelevant for points (I think) and probably no longer necessary with 7.x)

So looks like we can leave them as one module.

I'm not sure I like d.thematic.ptln as name as this is a bit cryptic, but d.thematic.pointline might be a bit long...

Moritz