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

[GRASS GIS]

#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 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
 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>