Even, Thank you for your very kind explanation of a probable origin for the bug I've described.
Regardless of the point in the GDAL infrastructure that the bug is occuring at, it appears that gdal_rasterize (as a whole) is prone to unpredictably writing data values in places where there is no data and when a nodata value has been specified. 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. To me, this makes sense semantically, because all drivers should (by default) output the 'nodata' value in places where there is no data, rather than occasionally inventing their own data values in an arbitrary and unpredictable way. Assuming that your explanation is correct - the present situation, where an entire raster extent can change from being full of data values to being completely empty of data values depending on the output driver (and without any warning!) seems very broken. Graeme. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
