#763: r.statistics method=distribution: no percentages for negative basemap
values
--------------------+-------------------------------------------------------
Reporter: peifer | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: | Platform: Unspecified
Cpu: x86-32 |
--------------------+-------------------------------------------------------
Comment(by glynn):
Replying to [comment:1 neteler]:
> Could it be the lack of sufficient NULL detection?
>
> See
source:grass/branches/releasebranch_6_4/raster/r.statistics/o_distrib.c#L68
I suspect that "basecat > 0" should be either "basecat != 0" or absent,
depending upon whether category zero causes problems for some other
component (e.g. r.stats).
A question, perhaps for Markus:[[BR]]
Why should cat=0 cause problems for r.stats or r.statistics? It is a legal
value, by the end of the day. I also vaguely remember that some
r.stats/r.statistics/r.report output doesn't show the counts for cat=0. At
the time, my workaround was to reclassify 0 to 99999 or some such, in
order to get correct statistcs.
#763: r.statistics method=distribution: no percentages for negative basemap
values
--------------------+-------------------------------------------------------
Reporter: peifer | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: | Platform: Unspecified
Cpu: x86-32 |
--------------------+-------------------------------------------------------
Comment(by glynn):
Replying to [comment:3 peifer]:
> Why should cat=0 cause problems for r.stats or r.statistics? It is a
legal value, by the end of the day.
Prior to 5.x, category zero was often used as a no-data value. 5.x added
support for a distinguished null value (as well as floating-point), but
some code still follows the old zero-is-null convention. In particular:
* If a raster map doesn't have a null bitmap, any zeros are converted to
nulls upon read.
* The functions G_get_map_row() and G_get_map_row_nomask() convert any
nulls to zeros upon read, so any module which uses these functions cannot
distinguish between zero and null.
Given the large number of occurrences of G_get_map_row[_nomask]() in 6.4,
I can't help wondering whether all of the modules which were converted to
use Rast_get_c_row() in 7.0 were actually converted correctly, or whether
the function call was changed without any effort made to handle nulls.
Replying to [comment:4 glynn]:
> Prior to 5.x, category zero was often used as a no-data value.
> 5.x added support for a distinguished null value (as well as
> floating-point), but some code still follows the old zero-is-null
> convention.
...
> Given the large number of occurrences of G_get_map_row[_nomask]()
> in 6.4, I can't help wondering whether all of the modules which
> were converted to use Rast_get_c_row() in 7.0 were actually
> converted correctly, or whether the function call was changed
> without any effort made to handle nulls.
as a test point, r.surf.contour in 6.4 still treats 0 as NULL (and is not
FP-aware), so if there are problems in the transition, they'll probably
show up there.
#763: r.statistics method=distribution: no percentages for negative basemap
values
--------------------------+-------------------------------------------------
Reporter: peifer | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: r.statistics | Platform: Unspecified
Cpu: x86-32 |
--------------------------+-------------------------------------------------
Comment(by peifer):
Replying to [comment:4 glynn]:
> ...but some code still follows the old zero-is-null convention.
>
[[BR]]
This is what I observed, from a simple end-user perspective. But actually,
I didn't want to believe it and I never dared to create a ticket whenever
I came across such an observation.
As stated: my current practice is to reclassify my maps so that all
legitimate 0's (and negative values) are replaced by some more or less
meaningful positive integer. Can you confirm that this continues to make
sense, if one wants to be on the safe side?