#2380: d.legend "use" argument makes legend disappear
-------------------------+--------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: wxGUI | Version: svn-trunk
Keywords: d.legend | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by hamish):
* component: Display => wxGUI
Comment:
Replying to [comment:7 cmbarton]:
> I thought you might be right about the space, but it turns out that it
makes no difference.
I'd expect it to fail with the space, I don't remember a G_squeeze()
anywhere which would remove them. Maybe atof() does that automatically.
I'd recommend to not put them in on purpose.
> The problem is when one of the numbers in the list is out of range.
ok, so the error message is not fed back to the user in an obvious way
when d.legend is launched from the wxGUI display button?
> Interestingly, the error says
{{{
> "Command 'd.legend rast=shortdomestic_dates@NeolSpread
> use=6600,6800,6900 at=5,50,7,10' failed
> Details: use=6600 out of range [6689.075, 7299.539] (extend
> with range= ?)"
}}}
> But specifying a wider range with range=? does not work. A work around
for this
> issue is to use r.colors to define a color table matching the desired
range
> (i.e., of even, round numbers). Then range=? works for the new range and
use=?
> does not cause the legend to disappear.
Right, the "extend with range=" message implies that, even though it
doesn't
say so. Referring to the man page:
{{{
The range option lets the user define the minimum
and maximum categories to be used in the legend. It
may also be used to define the limits of a smooth
gradient legend created from a raster containing
floating point values. Note the color scale will
remain faithful to the category values as defined
with r.colors, and the range may be extended to the
limits defined by the r.colors color map.
}}}
> It would be nice if range=? did this without the r.colors workaround.
It can't and won't do that. Only r.colors is allowed to (re)set color
tables,
d.legend will not. The alternative is to have [ugly] empty space beyond
the
min and the max of the color table range within the smoothed legend box,
I'd
prefer to not allow that. (the module cannot look up the color values
which
are outside of the raster map's color table, since they don't exist. *The
resulting out-of-bounds color isn't technically undefined, you can set it
with the r.colors "default" rule, but I'd rather treat it as an error in
the case of d.legend.)
Anna:
> I would say that warning would be more appropriate than fatal error.
> There is already a warning about exceeding range which is similar case.
Similar but different. One is recoverable, but may suggest user error. The
other
is not since it can't look up a color value which does not exist. fwiw
I've
considered downgrading the beyond-actual-range warning into a regular
message,
since for a long time-series with common color table (as asked about
recently
on the ML), such as series of temperature maps over a year, that happens
all
the time and can be too noisy when run in a loop.
regards,
Hamish
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2380#comment:9>
GRASS GIS <http://grass.osgeo.org>