#2382: d.legend: integer map legends should not be flipped upside-down
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: hamish
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Display | Version: svn-releasebranch70
Resolution: wontfix | Keywords: d.legend
Platform: All | Cpu: Unspecified
----------------------+-----------------------------------------------------
Changes (by hamish):
* status: assigned => closed
* resolution: => wontfix
Comment:
annakrat wrote:
> In my view, the order should be defined by the gradient/box legend, not
by
> the type of the map since it is not reliable. Gradient would have low
values
> in the bottom, and boxes would be ordered in the opposite direction.
This
> behavior could create less confusion and would be expected in most
cases,
> in my opinion.
"smoothed" legend != "gradient" legend
One is a visual change, the other a conceptual change. Visual adjustments
are easier to follow than conceptual ones. As the determining factor here
in rendering style is the height of the display frame -- a visual change
as well -- that's the smallest logical jump to make. A good demo of this
is if you have a map with the number of categories near to the maximum
number of boxes that will fit in the display frame, and tweak the size of
the window a bit taller and shorter to watch it jump back and forth
between rendering styles. For categorical maps it is not a gradient at
all, just a stack of blocks, often with random color transitions.
Again, there is no one right answer here for all use cases, and no way for
the software to know ahead of time. So we pick one way and hope it is the
right choice 51% of the time. Another way to make the choice is by how far
from the too-many-boxes threshold you are. That might make it do the right
thing more often for an integer elevation map with a range of 100s or
1000s of meters (admittedly a common alternative and the one which
inspired this ticket), but IMO the logic and arbitrary choice of threshold
value becomes too muddy to explain and it moves into the horrible realm of
software "auto correct"s.
wenzeslaus wrote:
> Sorry, I cannot agree entirely. I don't see the reason to have numbers
there
> when labels are the only important thing in case of of towns. Then of
course
> the order (order according category) is not important.
The towns map was just an example of a purely categorical, as opposed to
continuous gradient, CELL map with a useful number of categories. Of
course the category numbers are not very meaningful in that example, but
their order may very well be. Depends on the map! In practice for the
towns map the -c flag would be used to suppress the numbers.
> I generally agree with introducing these tricks (clever decision making,
> heuristics). However, in this case it is questionable if it creates more
> confusion then convenient/handy behavior.
I don't think the two flipping triggers I mentioned cause any confusion.
Certainly the rules= way logically flows from the way you type it in, and
the flipped at= order only happens if you know about it.
> Perhaps option order=ascending, order=descending and order=auto would
improve the
> situation by making things explicit. order=auto can be the default.
order=ascending
> and order=descending would disable any handy tricks.
It's over-engineering the problem. Just use the -f flag if you need to.
Claiming author's prerogative and closing as wontfix. I spent many many
hours thinking through these problems and experimenting with this on a
wide range of maps & display sizes, and for better or worse, depending on
your point of view, the current way came out on top.
regards,
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2382#comment:6>
GRASS GIS <http://grass.osgeo.org>