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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
