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

[Glynn Clements]

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