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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
