[GRASS-dev] WxPython front-end to ps.map

[Michael Barton]

Moritz,

Sorry for the confusion. I'm thinking of how map layers are presented to
users in the layer control panel. It might be cleaner to have a single
"vector" layer button instead of "vector", "thematic map", and "thematic
chart" buttons. In the options panel for the vector layer, you could decide
whether this would display a single color vector map, thematic display of
the vector map, or a thematic chart of the vector map. In other words, there
would be a single control/options panel that would wrap d.vect,
d.vect.thematic, and d.vect.chart.

Again, I'm not talking about what we should do with the modules, only how
they could be presented to a GUI user. However, if we have a different way
of rendering vectors (i.e., a rewrite of the vector display somehow), I
think it should include the thematic and chart mapping, rather than just the
simply vector display.

Michael


On 2/9/07 1:33 AM, "Moritz Lennert" <mlennert at club.worldonline.be> wrote:

> On 09/02/07 04:46, Michael Barton wrote:
> 
>> Thematic maps and charts seem like they should be a vector option rather
>> than separate layers. This could be done with GUI code without needing to
>> combine the d.* modules. However, if we did true vector rendering for
>> primitives, we'd want the same quality in thematic maps and charts.
>> 
>> I'm not sure if this makes any considered recoding any easier or not. But
>> the upshot is that vector primitives, thematic maps, and charts seem the
>> best candidates for some reworking of the C code for display. Most of the
>> other d.* effects can work with current code or be replaced by GUI generated
>> graphics if we want. As you point out, this is more work at the GUI coding
>> end. I'm not sure which will take more effort.
> 
> 
> I'm not sure I completely understand what you mean here, and as we are
> still (albeit slowly, I admit) working on a C replacement of
> d.vect.thematic, it would be good to know what we should take into account.
> 
> I do have to agree with Glynn, though, in that we should try to not code
> two parallel and different ways of drawing things, one for the command
> line and one for the GUI. I am afraid that this would almost inevitably
> lead to inconsistencies and definitely to twice the work load trying to
> keep everything up to date. IMHO, GRASS's strength is its modularity and
> the GUI should be on top of that, not replace it.
> 
> Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton