d.legend "use" argument makes legend disappear

[cmbarton]

If I put a list of values into d.legend use= , the legend disappears in the GUI and the attribute GUI cannot be opened again. Not sure if this is a d.legend problem, a GUI problem, or a combination.

[cmbarton]

I find that you must put this list in quotes "7321, 7300,7100,7000,6955" instead of 7321, 7300,7100,7000,6955 as indicated in the manual. Unfortunately, this turns the legend into a series of discrete colored boxes instead of a smooth gradient.

What I'd like to do is make a legend that encompasses all values but also is a nice set of ticks marked at regular decimal intervals (10 or 100's).

[annakrat]

Replying to cmbarton:

If I put a list of values into d.legend use= , the legend disappears in the GUI and the attribute GUI cannot be opened again. Not sure if this is a d.legend problem, a GUI problem, or a combination.

It disappears when the values are out of the range of the raster map. Look in console for an error, it might be the case. You can display again a legend when you click on show/hide (twice, first as hide, second for show).

[cmbarton]

The values were in range. I tried clicking legend show/hide a couple of times and nothing happened.

[annakrat]

Replying to cmbarton:

The values were in range. I tried clicking legend show/hide a couple of times and nothing happened.

Any error?

[hamish]

Replying to cmbarton:

I find that you must put this list in quotes "7321, 7300,7100,7000,6955" instead of 7321, 7300,7100,7000,6955 as indicated in the manual.

are the spaces real? there shouldn't be any around the commas.

Unfortunately, this turns the legend into a series of discrete colored boxes instead of a smooth gradient.

That's exactly what the use= option does; it uses those discrete values. E.g. for a logarithmic scale.

What I'd like to do is make a legend that encompasses all values but also is a nice set of ticks marked at regular decimal intervals (10 or 100's).

Generally the way to do that is to pick a min,max for range= near a whole number (I don't think it needs to be exact?) then set the labelnum= option appropriately to get the ticks on nice clean divisions.

ps.map uses a completely different logic for selecting the tick mark values; I tend to prefer d.legend's way as it gives the cartographer more control, but using ps.map may automagically give you what you're looking for.

regards, Hamish

[cmbarton]

I thought you might be right about the space, but it turns out that it makes no difference. The problem is when one of the numbers in the list is out of range. 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. It would be nice if range=? did this without the r.colors workaround. So this part is an enhancement request now.

The biggest problem from a user standpoint is that when the legend disappears and you have closed the command dialog (i.e., by pressing "OK", there is no way to get it back. Selecting "Show/hide legend" in the toolbar menu will not make the command dialog reappear. You can only fix it by closing the display and opening a new one. While perhaps not a bug per se, this is not desirable.

[annakrat]

Replying to cmbarton:

I thought you might be right about the space, but it turns out that it makes no difference. The problem is when one of the numbers in the list is out of range. 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= ?)"

I would say that warning would be more appropriate than fatal error. There is already a warning about exceeding range which is similar case.

The biggest problem from a user standpoint is that when the legend disappears and you have closed the command dialog (i.e., by pressing "OK", there is no way to get it back. Selecting "Show/hide legend" in the toolbar menu will not make the command dialog reappear. You can only fix it by closing the display and opening a new one. While perhaps not a bug per se, this is not desirable.

Hm, for me the dialog reappears, at least in the newest GRASS version. What about any Python error message in the console?

[hamish]

Replying to 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

[neteler]

Milestone renamed

[neteler]

Does the problem persist after the recent d.legend updates?

[annakrat]

I think this is fixed.