[GRASS-dev] d.* commands

[Michael Barton]

Hamish answered some of these overnight. I'll add some more items of
explanation.

Michael
__________________________________________
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


> From: David Finlayson <david.p.finlayson at gmail.com>
> Date: Tue, 23 May 2006 14:32:02 -0700
> To: grass developers list <grass-dev at grass.itc.it>
> Subject: [GRASS-dev] d.* commands
> 
> I think there are around 56 d.* commands for interacting with the X11
> terminals. What needs to be done to these modules so that they can
> communicate with the new Tk display canvas?

Most of them either already do display, using the PNG driver, or I've
written alternative versions in TclTk. The latter are ones that require
interactive input via the X display window (e.g., d.zoom). This is why Glynn
is emphasizing getting rid of *requirements* for interactive use of GRASS
commands. There is no way to make d.zoom do interactive zooming in a TclTk
canvas, because it *requires* interaction with an X display. The same goes
for d.what.vect.

In the former case, I wrote a set of TclTk functions that handle zooming and
panning by sending coordinates to g.region. In the latter case, Trevor Wiens
wrote v.what that can do a query by inputing xy coordinates and outputing
the vector information at that locality. I then added a TclTk wrapper to get
the xy coordinates from the screen and sent them to the command.

This is kind a model of how things probably should work. Basic display
management (e.g., zooming) should be handled by the GUI/display system;
interaction between the display and GRASS data files (e.g., querying) should
be handled by interaction between the GUI/display system controls and GRASS
commands that accept text input and produce text output.

> 
> Has anyone thought about the best way to integrate d.* commands from
> the terminal and GIS manager?

Yes. Glynn is working on this. The goal is to produce a generic protocol
that could be applied in different GUI/display systems.

> 
> I guess I envision that they need to create a layer in the png driver
> and add it to the stack used by g.pngcomp and then cause a refresh of
> the screen. I figure they should get the new transparency options as
> well a hard or soft screen redraw option.

Thre are really 3 levels to deal with. At the most basic of typing a command
to display a map, an easier way might be simply to build in a simple PNG/PPM
display command that could give a quick view of items to be displayed. At
the level of scripting, all display functions can currently be scripted
using GRASS commands (that's how TclTk does it now). Interactive display
management is best done with a dedicated interactive display management
system.

> 
> A few questions:
> 
> Is the drawing stack accessible from outside of GIS Manager so that
> g.pngcomp can be called with the existing screen elements intact?

g.pnmcomp only composites a set of ppm/pnm graphic files of the same
geometry into a single output graphic file. It can set tranparency,
background color, and output geometry also. Because this is a GRASS command
that accepts text input and produces output in the form of a pnm graphic
file, it is completely accessible from any program that can run GRASS
commands.

> 
> Is there a good way to let GIS manager know that the screen has a new
> drawing element

This has been tricky, but basically checks to see if any of the options
(including file name) of a layer has changed. If anything has changed the
file is re-rendered (i.e., a new *.ppm file is created); if not, the
existing file on disk is used by g.pnmcomp. This is why if you change the
color table using r.colors or change a color in an rgb file for a vector
using an external dabase manager, the GIS Manager has no way of knowing. I
added the re-render button to deal with this.

> 
> Maybe command line draws should not be persistent in the GUI at all?

Not sure what you mean, but I'll try to answer what I think you mean. It
would be difficult to get something called from the command line to display
in an existing canvas, and I'm not sure what the advantage would be of doing
so. Each canvas is incrementally numbered in an array variable $can($mon)
and has an associated layer tree it uses for input. This allows each canvas
to have its own individual set of layers to display and individual
zoom/region settings. Also, displaying something in a TclTk canvas requires
TclTk commands, not GRASS commands.

It would be much easier if something from the command line were to display
in a simple display window (e.g., a simple command line PNG/PPM displayer).
The commands needed to display a set of maps, using the PNG driver,
compositing the maps into a single graphic display, calling wish,
determining the array value for the canvas desired, and creating the image
for the canvas are complicated and would take considerably longer to figure
out and type than simply adding the desired layers to the layer tree and
pushing the display button.

On the other hand, you can use display commands to create a *.PPM image that
can be displayed or imported into another application, without bothering
with a TclTk canvas.

> 
> If this is something that I can do, I would like to try and get a few
> of the more important ones updated before the feature freeze. I am not
> a great C coder, however, so this could get ugly.

Thanks very much for offering to help. IMHO, the most valuable thing anyone
could do to make GRASS 6.2 a complete system would be to port i.points
and/or v.digit to the new architecture so that they could work in a TclTk
canvas rather than requiring X11. NVIZ seems already on track to get there
soon.

Michael