Warping: fix inconsistent replacement of valid value that collides with the dstnodata value#11713
Warping: fix inconsistent replacement of valid value that collides with the dstnodata value#11713rouault merged 2 commits intoOSGeo:masterfrom
Conversation
…th the dstnodata value Fixes OSGeo#11711
|
as the original bug issuer of #11711 : we don't need a backport, we have fixed our code internally to avoid hitting this corner case. But anyway thanks for the quick follow-up! |
|
I wouldn't be inclined to backport it because it changes behavior in a way that might not be expected. Since there is no unambiguously correct behavior in this situation I think it would be good to emit a one-time warning like ("value %d in the source dataset has been changed to %d in the destination dataset to avoid being treated as NoData. To avoid this, select a different NoData value for the destination dataset.") |
done |
|
@sgillies @rouault Another rasterio failure from a warp change with 6074ce4 |
|
@schwehr That's likely expected and should be filed on rasterio side. |
|
This commit triggered a test failure with the Earth Engine Data Catalog SMAP processing. Here is the fix:
|
Fixes #11711
While technically a bug fix, I'm somewhat 50% 50% to backport that to 3.10, in particular as it affects probably quite common use cases like Byte nearest resampling. Thoughts @dbaston ?