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

[Michael Barton]

On 2/8/07 6:37 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> Michael Barton wrote:
> 
>> Something I proposed is that we really limit the number of d.* modules used
>> in the new GUI. All the decorations (e.g., scale, north arrows, text,
>> histogram, maybe grids or others) would be better done within wx.Python
>> rather than rendered into raster maps by a d.* module as they are now. They
>> would look much better and offer greater flexibility in placement options
>> and appearance. I'm not proposing that we get rid of such modules, just not
>> use them in the new GUI. That would reduce the amount of d.* module
>> rewriting needed perhaps.
> 
> d.* aren't just for interactive use. Any new architecture needs to
> allow for scripted creation of graphics (e.g. web applications).

Indeed. That's why I don't propose we get rid of them.

> 
> BTW, there are two distinct types of graphics: georeferenced and not.
> Of the above examples, all but histograms are georeferenced (or may
> be; text can be either). Having graphics generated by two different
> mechanisms would require some effort to ensure that "annotations"
> actually aligned with the maps.

I'm not sure that it's important to have scales and north arrows
georeferenced. Some may disagree of course. But scales were georeferenced in
earlier versions of MapInfo and I always thought it was a pain.

Georeferencing of some text is indeed important. Vector labels are the best
example. But these are created from a text file generated by v.label. I've
already got a simple example in TclTk of how such a file can be parsed into
labels generated by the GUI. Doing something like contour labels would be
nice, but we don't have a particularly good way to do that now by any method
(a "contour" setting for v.label might be nice).

Grids are georeferenced of course. The ones we have are pretty nice, but it
wouldn't be that hard to generate them in the GUI since it is necessary to
track earth coordinates for region setting of the display anyway. This would
allow more control over stroke form, width, and color, as well as grid label
placement.

An RGB/HIS display seems like it needs to stay as a layer. Cell numbers and
arrows might be better wrapped into the raster control in the GUI, even if
they remain separate d.* modules.

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.
 

Michael

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

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