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

Hamish hamish_nospam at yahoo.com
Sat Nov 4 22:40:39 EST 2006


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




More information about the grass-dev mailing list