[GRASS-dev] d.rast.edit replacement candidate

GRASS GIS GRASS GIS developer
1

I'm looking into replacing d.rast.edit with a Tcl/Tk program.

I've committed a "first draft" in scripts/d.rast.edit. Currently, it
doesn't do everything which the existing d.rast.edit does.

Primarily, it doesn't offer the option to run d.zoom in the middle of
an editing session. OTOH, you aren't restricted by having to select a
small region so that the cells are large enough to select; the cells
are never smaller than 12x12 pixels.

Also, I haven't added the option to display slope arrows; I'm not
entirely sure whether that's actually useful, but I can add it easily
enough if it is.

Probably the main limitation at present is that it won't show the
correct colours for any modified cells with values which aren't in the
original map (there doesn't appear to be any way to determine the
colour for a given category value from outside a C program).

Any comments (or bug reports) would be appreciated.

--
Glynn Clements <glynn@gclements.plus.com>

2

I tried running it on Windows - looks neat enough. A few comments:
Couldn't get it running directly: as far as I can see the
exec "$GRASS_WISH" "$0" "$@" syntax is having problems with confused Msys/Windows paths or something. Hard to get to the bottom of.
But running g.parser directly on the script file works OK. I came across the problem with r.out.ppm always returning an error code but I see you've already fixed that in CVS. Does that mean nobody had ever tried running it from Tcl before?
The 2>@stderr syntax doesn't work on Windows and when I changed it to 2>NUL: everything ran OK.
Noticed a bug: can only save the output map once - the second and subsequent times I get a broken pipe error - caused by error message from r.in.ascii about over-writing the file - possibly call it with --overwrite option? I guess if there was a pre-existing map it will have been checked at the time the script was started, so d.rast.edit will only be over-writing what it itself created.

Also it would be good if there was some way it could determine if the region was too large and abandon startup instead of using up lots of memory and taking a long time to do nothing. Maybe you could calculate something from the width of the black lines between the cells and the size of the canvas in pixels, and determine when there would be so many cells that the lines between them would merge together, and refuse to run then? I suppose you would need to provide an option then for people with huge monitors and high-spec PCs - maybe it could read the initial screen size from the environment variables for the monitor size or something.

Also: title bar currently says d.rast, not d.rast.edit.

Paul

On Mon, 12 Mar 2007, Glynn Clements wrote:

I'm looking into replacing d.rast.edit with a Tcl/Tk program.

I've committed a "first draft" in scripts/d.rast.edit. Currently, it
doesn't do everything which the existing d.rast.edit does.

Primarily, it doesn't offer the option to run d.zoom in the middle of
an editing session. OTOH, you aren't restricted by having to select a
small region so that the cells are large enough to select; the cells
are never smaller than 12x12 pixels.

Also, I haven't added the option to display slope arrows; I'm not
entirely sure whether that's actually useful, but I can add it easily
enough if it is.

Probably the main limitation at present is that it won't show the
correct colours for any modified cells with values which aren't in the
original map (there doesn't appear to be any way to determine the
colour for a given category value from outside a C program).

Any comments (or bug reports) would be appreciated.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

3

Paul Kelly wrote:

I tried running it on Windows - looks neat enough. A few comments:
Couldn't get it running directly: as far as I can see the
exec "$GRASS_WISH" "$0" "$@" syntax is having problems with confused
Msys/Windows paths or something. Hard to get to the bottom of.

Hmm. I could add a front-end shell script which does the g.parser
stuff then explicitly invokes $GRASS_WISH on the Tcl script.

But running g.parser directly on the script file works OK. I came across
the problem with r.out.ppm always returning an error code but I see you've
already fixed that in CVS. Does that mean nobody had ever tried running
it from Tcl before?

I presume so.

The 2>@stderr syntax doesn't work on Windows and when I changed it to
2>NUL: everything ran OK.

Noticed a bug: can only save the output map once - the second and
subsequent times I get a broken pipe error - caused by error message from
r.in.ascii about over-writing the file - possibly call it with --overwrite
option? I guess if there was a pre-existing map it will have been checked
at the time the script was started, so d.rast.edit will only be
over-writing what it itself created.

I originally figured that if you run the d.rast.edit script with --o,
it would set GRASS_OVERWRITE, and if you didn't use --o, you would
want overwrite to fail. I didn't allow for saving it twice.

I'll change it to explicitly use --o when calling r.in.ascii.

Also it would be good if there was some way it could determine if the
region was too large and abandon startup instead of using up lots of
memory and taking a long time to do nothing. Maybe you could calculate
something from the width of the black lines between the cells and the size
of the canvas in pixels, and determine when there would be so many cells
that the lines between them would merge together, and refuse to run then?
I suppose you would need to provide an option then for people with huge
monitors and high-spec PCs - maybe it could read the initial screen size
from the environment variables for the monitor size or something.

The cells will never be any smaller than 12x12; it will enlarge the
view if necessary (hence the scrollbars). However, it might take a
long time to start up if you have a lot of cells.

FWIW, spearfish at 100m resolution (190x143 = 27170 cells) takes 7
seconds to start up on a P3/800. I would expect it to take over a
minute at the default 30m resolution (634x477 = 302418 cells).
Obviously, using it on high-resolution data isn't going to be
practical.

Choosing a "sane" limit is hard, given the range of hardware.
Ultimately, the user can always kill it with Ctrl-C if it takes too
long. It might be worth adding a progress bar to give the user some
advance warning.

Also: title bar currently says d.rast, not d.rast.edit.

Presumably, the Windows Tcl/Tk treats ".edit" as the executable's
extension and omits it as it would ".exe".

I'll add a "wm title ...".

I'll also replace the hard-coded canvas width/height and cell size
with options.

--
Glynn Clements <glynn@gclements.plus.com>

4

Glynn Clements wrote:

> Also it would be good if there was some way it could determine if the
> region was too large and abandon startup instead of using up lots of
> memory and taking a long time to do nothing. Maybe you could calculate
> something from the width of the black lines between the cells and the size
> of the canvas in pixels, and determine when there would be so many cells
> that the lines between them would merge together, and refuse to run then?
> I suppose you would need to provide an option then for people with huge
> monitors and high-spec PCs - maybe it could read the initial screen size
> from the environment variables for the monitor size or something.

The cells will never be any smaller than 12x12; it will enlarge the
view if necessary (hence the scrollbars). However, it might take a
long time to start up if you have a lot of cells.

FWIW, spearfish at 100m resolution (190x143 = 27170 cells) takes 7
seconds to start up on a P3/800. I would expect it to take over a
minute at the default 30m resolution (634x477 = 302418 cells).
Obviously, using it on high-resolution data isn't going to be
practical.

Choosing a "sane" limit is hard, given the range of hardware.
Ultimately, the user can always kill it with Ctrl-C if it takes too
long. It might be worth adding a progress bar to give the user some
advance warning.

If editing large maps is desirable, another option is to use a scaled
image rather than drawing each cell as a polygon. However, you still
need the array of category values, and Tcl's arrays aren't exactly
efficient; they're associative arrays, with both the key (i.e. the
coordinate pair) and value stored as strings, so memory consumption
will always be much worse than the 4/8 bytes per cell you would have
in C.

Ultimately, the question is whether the ability to operate upon large
regions is useful. If it is, I'm going to need to look at other
approaches, e.g.:

1. Operating upon smaller subregions, with the user having to
explicitly pan around the region.

2. Avoid reading the cell values altogether. That would eliminate the
ability to continuously show the value under the pointer; instead, you
would have to explicitly query cell values (d.rast.edit would use
r.what for this).

This would eliminate the need for explicit panning, but also eliminate
the ability to overlay arrows or cell values; a Tk canvas can handle a
1000x1000 image easily enough, but it can't easily handle a million
text items (overlayed numerical values) or line items (overlayed
arrows)

3. Export the cell values to a raw binary file using r.out.bin, and
perform random lookups on this file from Tcl. This might be fast
enough to all continous display of cell values, but still doesn't
allow for any overlays.

--
Glynn Clements <glynn@gclements.plus.com>

5

Glynn Clements wrote:

If editing large maps is desirable, another option is to use a scaled
image rather than drawing each cell as a polygon.

Actually, that doesn't help much; I forgot that the Tk canvas doesn't
allow images to be scaled, and scaling the image itself increases
memory consumption proportionally, making it potentially worse than
using a polygon per cell.

--
Glynn Clements <glynn@gclements.plus.com>