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.
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to