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
