Opened 8 years ago
Last modified 5 years ago
#2992 new defect
r3.null creates a lot of new unexpected null cells likely by creating a null tile
Reported by: | wenzeslaus | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 7.6.2 |
Component: | Raster3D | Version: | unspecified |
Keywords: | r3.null, NULLs, tiles, Rast3d_flush_tiles_in_cube, data loss | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
When running r3.null
I get a lot of NULL cells as a result regardless of input. When I show it in 3D as slices one part of the raster is missing. It looks like all values in one tile are NULLs (the tile is a NULL tile).
It seems that the computational region is important. I don't get the behavior with arbitrary region.
> g.region -3 n=220180 s=219900 w=638360 e=638720 t=153 b=106 res=2 res3=2
When replacing value by NULL, I get more NULL cells than expected:
> r3.mapcalc --o expr="test_1 = float(col() + row() + depth())" > r3.univar map=test_1 total null and non-null cells: 604800 total null cells: 0 ... > r3.null map=test_1 setnull=10 > r3.univar map=test_1 total null and non-null cells: 604800 total null cells: 40356 ...
When replacing NULLs by value, I get a lot of NULL values.
> r3.mapcalc --o expr="test_1 = float(col() + row() + depth())" > r3.univar map=test_1 total null and non-null cells: 604800 total null cells: 0 ... > r3.null map=test_1 null=10 > r3.univar map=test_1 total null and non-null cells: 604800 total null cells: 40320 ...
There is a lot of different Rast3d_*lock*()
calls in the code but when I comment out the call of Rast3d_flush_tiles_in_cube()
, I get the right results (there is Rast3d_flush_all_tiles()
at the end). Documentation of Rast3d_flush_tiles_in_cube()
says tiles which are not stored in the cache are written as NULL-tiles.
Change History (11)
comment:1 by , 8 years ago
Milestone: | 7.0.4 → 7.0.5 |
---|
comment:2 by , 8 years ago
Milestone: | 7.0.5 → 7.0.6 |
---|
comment:3 by , 7 years ago
comment:4 by , 7 years ago
Milestone: | 7.0.6 → 7.4.0 |
---|
Added existing tests in r71418, tests for this ticket in r71420, removed the problematic code in r71421 from G7:r3.null. Tests now run.
This still points to a possible bug in the library.
comment:6 by , 6 years ago
Milestone: | 7.4.1 → 7.4.2 |
---|
comment:11 by , 5 years ago
Milestone: | 7.4.5 → 7.6.2 |
---|
In 71421: