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

[Paul Kelly]

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 at gclements.plus.com>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>