Bug report #14678
Raster calculator fails with large raster in QGIS 2.14.1
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Raster Calculator | ||
Affected QGIS version: | 2.14.1 | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 22642 |
Description
I'm working in QGIS 2.14.1 with a DEM ranging from 200 feet to 1600 feet elevation called "dem_3m_Zft1b" (geotiff, 16822 X 33349 cells, No-data =-9999)
If I enter "dem_3m_Zft1b" > 0
in the raster calculator I get a result that has a value of 0 everywhere in the raster extent. The calculator does not seem to recognize the existence of any values or of the no-data flag.
With a subset/portion of the DEM called "atest9b@1" (4489 X 6175 cells, No-data=-9999), If I enter "atest9b@1" > 0 in the raster calculator I get a result that has a value of 1 where there was data and a value of no-data where there was no-day. Everything seems OK when using the subset.
The larger DEM "dem_3m_Zft1b" seems OK in other ways, e.g. the "Identify" tool finds valid values for Band1, but the raster calculator doesn't seem to recognize the data in it.
I tried the same operation on the large DEM in the Processing Toolbox, SAGA, Raster Calculator with the syntax: g1 > 0 and I get the correct results, i.e. 1 where there is data and no-data where there isn't.
History
#1 Updated by Giovanni Manghi over 8 years ago
- Category set to Raster Calculator
#2 Updated by Giovanni Manghi over 8 years ago
There is (was?) already a ticket on this matter, but now I can't find it. If is still open this should merged with that one.
Meanwhile just use SAGA or GRASS rastercalc, they are much more reliable and robust.
#3 Updated by john coleman over 8 years ago
in the bug report;
If I enter "dem_3m_Zft1b" > 0
should read:
If I enter "dem_3m_Zft1b@1" > 0
#4 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#5 Updated by Nyall Dawson almost 6 years ago
- Resolution set to fixed/implemented
- Description updated (diff)
- Status changed from Open to Closed
This was fixed in 3.4