id summary reporter owner description type status priority milestone component version severity resolution keywords cc 5115 2 examples of incorrect output by gdal_rasterize with zero-polygon valid query result. gbell warmerdam " Summary: BUG 1. Gdal_rasterize invents incorrect data values instead of burning nodata values in a reasonably common situation - a valid query returning geometry columns but zero polygon rows. BUG 2 (FIXED?). Command line output suggests that nothing is being done, yet a GeoTIFF with data values is silently rendered in the background. Example: Imagine we have a map whose extents are defined from 0 to 1000 in the X axis and 0 to 1000 in the Y axis as geometry in a postgres database. Situation 1 - rendering off-map with polygon rows in the query result. Specify gdal_rasterize with -a_nodata 255, and -te to burn a square area with extents 2000 to 3000 in x and y axis, i.e rasterizing an off-map area. We use PG: and -sql to specify the data layer to use. The layer returned contains 1000 polygons. Command line output: 0...10...20...30...40...50...60...70...80...90...100 - done. Result: A valid GeoTIFF raster is burnt with nodata values 255 everywhere which are marked as nodata. This is correct behaviour. Situation 2 - rendering off-map without polygon rows in the query result. As before, but now we use PG: and -sql to specify a datalayer that does not contain any polygons (e.g. perhaps clipping the original map with a bounding box that describes the area being rendered). Everything else, including the nodata value, remains the same. PostGIS returns columns correctly but there are no examples of polygons. Command line output: (nothing) Result: A valid GeoTIFF raster is burnt with data values 0 everywhere. This is wrong behaviour. Expected result: I would expect the semantics of gdal_rasterize in these two situations to be the same. The correct raster value for all pixels in the extent being rasterized is the nodata value (whether the polygons are clipped by postgis or by gdal_rasterize) since there is no data. Setting a '0' value is a bug. It is a data value, rather than nodata. The SQL query is returning correctly (e.g. it produces column names), so the fault lies with gdal_rasterize in how it renders that query result. Failing to produce command line output is also a bug, especially considering that a valid GeoTIFF file containing data values is produced silently. Also: (using -init 255 will produce a TIFF with suitable nodata values in the second scenario I described, as a workaround. However, gdal_rasterize still does not produce correct command line output in this situation, and also it should not be necessary for users to manually add a -init option and manually synchronise the value with the -a_nodata value to ensure valid output from gdal_rasterize) Regardless of the workaround, this is semantically wrong output, and I feel the fault should be addressed systematically for all users, rather than on an ad-hoc basis by users that are fortunate to be aware of it. Program version: gdal_rasterize --version GDAL 1.10.0, released 2013/04/24 ---- Even Roualt has pushed a patch for the command line output issue. Follow up discussion on GDAL-dev mailing list here: http://lists.osgeo.org/pipermail/gdal-dev/2013-June/036487.html http://lists.osgeo.org/pipermail/gdal-dev/2013-June/036488.html http://lists.osgeo.org/pipermail/gdal-dev/2013-June/036489.html My feeling is that GDAL should not be emitting semantically wrong output when correct values are trivial to produce, and it should certainly not produce wrong output in a unpredictable/inexplicable manner (from the user perspective) according to driver selected. Proposed solution: > That's semantically wrong. > > May I propose a fix for discussion that would work regardless of driver? > > If a user specifies -a_nodata X, then -init X should be *implicitly* > specified at the same time unless the value is overwritten by a manual > -init. " defect closed normal closed_because_of_github_migration GDAL_Raster 1.10.0 normal wontfix gdal_rasterize nodata even.rouault@…