[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