[GRASS-dev] [GRASS GIS] #2382: d.legend: integer map legends should not be flipped upside-down

[GRASS GIS]

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