[gdal-dev] bugs: 2 examples of incorrect behaviour by gdal_rasterize with zero-polygon valid query result.

[Graeme B. Bell]

Summary: 

I noticed that gdal_rasterize invents data values instead of burning nodata values, incorrectly, in what is probably a common situation - a valid query returning geometry columns but zero polygon rows. 

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. 


Thoughts?

Graeme.