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

[Glynn Clements]

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 at gclements.plus.com>