Bug report #14115
Processing: GDAL Proximity - incorrect result if "Values" is not filled
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | Victor Olaya | ||
Category: | Processing/GDAL | ||
Affected QGIS version: | 2.12.2 | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | invalid |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 22117 |
Description
Rasterize (GDAL Rasterize) the attached shapefile using ID as value
Run Proximity with the resulting raster
Output raster has the same value in every pixel
Proximity grid from SAGA GIS works as expected and generates a raster with distances.
History
#1 Updated by Filipe Dias almost 9 years ago
- File roads.zip added
#2 Updated by Alexander Bruy almost 9 years ago
- Resolution set to up/downstream
- Status changed from Open to Rejected
Running gdal_proximity.py from command line gives same result, so seems this is GDAL issue not Processing. Please submit ticket to GDAL track.
#3 Updated by Filipe Dias almost 9 years ago
- Subject changed from Processing: GDAL Proximity appears to be broken to Processing: GDAL Proximity - incorrect result if "Values" is not filled
Alexander, thanks for testing.
I filled "Values" with 10 (the ID value with which the roads raster was created) and it worked as expected.
It seems the algorithm needs the user to fill it with the appropriate value. Does this still qualify as a GDAL bug?
#4 Updated by Alexander Bruy almost 9 years ago
- Status changed from Rejected to Feedback
- Resolution deleted (
up/downstream)
With passed "Values" it produces correct result. I still think that this is GDAL bug, as from documentation, "values" is
A list of target pixel values in the source image to be considered target pixels. If not specified, all non-zero pixels will be considered target pixels.
Maybe it takes in account also NODATA values
#5 Updated by Giovanni Manghi almost 9 years ago
- Resolution set to invalid
- Status changed from Feedback to Closed
I really don't see anything wrong here. GDAL expects a list of values and so (of course) does QGIS. If not provided it uses all non zero pixels. Someone could argue about nulls, but that must be done in the gdal tracker.