[GRASS-dev] d.histogram and FP maps

[Hamish]

Hi folks,

Martin Landa wrote:
> > >> working with FP raster map (range: [0,1]) d.histogram does not
> > >> display real numbers along x-axis (see [1]).
> > >>
> > >> I have tried to fix it (see [2], fixed number of digits after the
> > >> decimal point -- 2).
> > >>
> > >> Maybe it would be sufficient to add a new parameter to enable
> > >> user to display more/less digits after the decimal point. Any
> > >> ideas?
..
> > >> [1]
> > >>
> > >http://gama.fsv.cvut.cz/~landa/.../tmp-grass-screenshots/histogram
> > >_fp-0.png
..
> > >> [2]
> > >>
> > >http://gama.fsv.cvut.cz/~landa/.../tmp-grass-screenshots/histogram
> > >_fp-1.png
..
> > I have added a new parameter 'ndigits' to the d.histogram module
> > 
> > [snip]
> > 
> >  ndigits   Number of digits after the decimal point (fp maps only)
> >            default: 1
>
> Markus wrote:
> Let me propose to call it 'dp' since r.out.ascii and
> v.out.ascii also have dp= (to avoid that too many different
> parameter names for the same thing are used).
>  
> > I am waiting for your comments... Shall I commit the patch to CVS
> > HEAD?


The FP axis labeling for d.histogram has been broken for some time
(overlaps, etc). I would rather we fixed that bug than add a new option
to work around the bug. It is simple enough to automatically pick a
useful number of significant digits, and I think we should try and make
this one automatic (e.g. ps.map's FP legend and d.legend do this).
Maybe use printf("%g") and/or G_trim_decimal() ...

A couple of months ago I had a quick look at this with Markus, as far as
I remember the problem had to do with the vertical graph segments being
broken up into 255 (nsteps=) bins but the axis tick labels not using
the same method. Anyway FP support was only grafted into d.histogram in
a half finished way, IMO we either have to implement that properly or
replace the module with a new WxPython version. Prob try and do both
with priority heavily on the second option. I've always found
d.histogram to be very useful but too ugly to show off- instead I've
done r.stats->Matlab (without the color table; other graphing software
would be just as good).


Hamish


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

[*] prior investigations: (5 Apr 2006)
> 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 FP 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.

[...]
Hamish