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

Even Rouault even.rouault at mines-paris.org
Wed Jun 12 12:19:03 PDT 2013


Le mercredi 12 juin 2013 21:05:42, Graeme B. Bell a écrit :
> 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.

If you feel strong about that, you can file a ticket in Trac about that. Your 
proposal makes sense, although I suspect there could be use cases where it 
wouldn't be desirable, but I can't find them right now...

> 
> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html


More information about the gdal-dev mailing list