[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