[GRASS5] d.rast behavior
rgrmill at rt66.com
rgrmill at rt66.com
Tue Apr 23 18:42:20 EDT 2002
Glynn wrote:
> Actually, it erases the entire window (frame), not just any raster
> maps which were displayed within it.
I think that is correct behavior unless -o is specified, though I think
the documentation could be a little more clear on that point.
> The only reason which springs to mind is that the user might wish to
> retain something which is displayed in the portion of the frame which
> isn't overwritten, e.g. a legend. I've occasionally used an extreme
> aspect ratio to ensure that d.rast *didn't* overwrite a legend.
>
> As it stands, the user can have either behaviour; "d.rast ..." alone
> just draws the raster, "d.erase ; d.rast ..." clears the window and
> draws the raster.
It worked originally as "d.rast ..." erased the window and drew the
raster and "d.rast -o ..." just drew the raster. You get the same
behavior either way, except that with -o you get the added feature that
null values are transparent.
> Also, if the behaviour is so desirable when run without "-o", why not
> when run with "-o"? Of course, getting it right for "-o" is much
> harder to implement, but that doesn't mean that the issue ceases to
> exist.
I don't recall that there was any real problem with the way it worked
originally.
> A related issue is whether "-o" should be the default behaviour, with
> e.g. "-n" for "fill null cells". The existing behaviour is largely an
> artifact of the lack of a distinct no-data value in 4.x, where only
> the user knew if zero was zero or no-data.
I'm fine with the flags as they were. Displaying a raster without -o
always obscures any vector or raster already displayed and I don't think
there's a way around that. It makes sense to me that the default
behavior should be for d.rast to clear the display, and that there
should be an overlay option (-o) to specify that the existing display
content is not deleted and that null-valued cells are transparent.
I do think we need to go one way or the other on this now and to fix the
documentation accordingly.
Roger
More information about the grass-dev
mailing list