[GRASS-dev] [bug #1977] (grass) d.histogram produces illegible axes labels

https://intevation.de/rt/webrt?serial_num=1977

When using the d.histogram feature on a floating point raster such as
elevations, the resulting axis tic marks and labels are often illegible.

Workaround: Greatly reducing the number of bins (nsteps) in the histogram will
produce resonable axes tic marks.

Axes labels and tic marks should handle large numbers of bins gracefully.

It would be really good to get the horizontal ticks/labels problem
fixed. Is there anyone who is willing to take a look? I tried a while
but didn't find a solution (maybe it isn't that hard, though).

Markus

-------------------------------------------- Managed by Request Tracker

Markus Neteler via RT wrote:

https://intevation.de/rt/webrt?serial_num=1977

> When using the d.histogram feature on a floating point raster such
> as elevations, the resulting axis tic marks and labels are often
> illegible.
>
> Workaround: Greatly reducing the number of bins (nsteps) in the
> histogram will produce resonable axes tic marks.
>
> Axes labels and tic marks should handle large numbers of bins
> gracefully.

It would be really good to get the horizontal ticks/labels problem
fixed. Is there anyone who is willing to take a look? I tried a while
but didn't find a solution (maybe it isn't that hard, though).

from previous attempt at fixing this bug:

==============================================

From: Hamish
Subject: Re: d.histogram label bug
Date: Wed, 5 Apr 2006 13:01:34 +1200
To: Markus

you will probably know the attached d.histogram label
bug (see screenshot).

yes

It seems to be "just" the density of tics/labels
which isn't estimated correctly (maybe divide by 10
or so to make it readable).

The raster map stats are:

n: 1116427
minimum: -23.1376
maximum: -8.79618
range: 14.3414
mean: -16.509
standard deviation: 2.02468
variance: 4.09934
variation coefficient: -12.2641 %
sum: -18431148.6160733774

AFAICT it only happens with FP maps, and if you stretch the window
larger or smaller it can fix itself.

I have tried a while but don't really understand
how it works in bar.c.

Maybe you could take a few minutes to investigate?

It's a bit complicated...
default for fs maps is to reduce to 255 cats as in r.stats, but the
calculation for tick spacing is using the FP range: conflict of units.
As proof of concept this fixes the ticks (I think, not a proper fix),
but the labels need changing too, as now they won't match up.

bar.c line ~120
// while((range_dmax - range_dmin)/tics[i].every > max_tics)
    while ((num_cats/tics[i].every) > max_tics)
         i++;

but I'm not sure if ticks should line up with the 255 rectangles or line
up with whole numbers of the FP range.

anyway, some why. Maybe I will look into it further once I have my next
batch of models running.

Hamish