[GRASS-dev] [GRASS GIS] #2380: d.legend "use" argument makes legend disappear

GRASS GIS trac at osgeo.org
Mon Jul 28 22:29:04 PDT 2014

#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


 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 at 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
 > (i.e., of even, round numbers). Then range=? works for the new range and
 > does not cause the legend to disappear.

 Right, the "extend with range=" message implies that, even though it
 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
 d.legend will not. The alternative is to have [ugly] empty space beyond
 min and the max of the color table range within the smoothed legend box,
 prefer to not allow that. (the module cannot look up the color values
 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.)

 > 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
 is not since it can't look up a color value which does not exist. fwiw
 considered downgrading the beyond-actual-range warning into a regular
 since for a long time-series with common color table (as asked about
 on the ML), such as series of temperature maps over a year, that happens
 the time and can be too noisy when run in a loop.


Ticket URL: <http://trac.osgeo.org/grass/ticket/2380#comment:9>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list