[gdal-dev] ReprojectImage and nodata

Even Rouault even.rouault at mines-paris.org
Wed Oct 23 12:49:55 PDT 2013


Le mercredi 23 octobre 2013 21:19:48, David Shean a écrit :
> Even,
> I encountered the issue you mention back in May:
> 
> http://osgeo-org.1560.x6.nabble.com/gdal-dev-ReprojectImage-and-nodata-td50
> 57270.html
> 
> The current ReprojectImage nodata handling is a bit confusing.  Do you see
> a relatively simple fix to mirror the behavior of gdalwarp?

Probably a matter of setting the padfDstNoData array to the target dataset 
nodata value, if that's the issue. There's also the INIT_DEST warping option 
that can play a role on this.

> 
> Thanks.
> -David
> 
> On Oct 23, 2013, at 10:25 AM, Even Rouault <even.rouault at mines-paris.org> 
wrote:
> > Le mercredi 23 octobre 2013 19:05:18, Ochs, Elke ERDC-RDE-CRREL-NH a écrit 
:
> >> ReprojectImage does not maintain areas of nodata as I would expect it
> >> should.  Small areas of nodata are getting erased and larger areas are
> >> reduced in size.  I'm reprojecting from geographic to Albers, using
> >> approximately the same  cell size (converted from dd to meters).  I'm
> >> using GDAL 1.9.2 in Python.
> >> 
> >> Gdalwarp does a better job of maintaining nodata cells.  Is there a way
> >> to get ReprojectImage to handle nodata in a similar way?
> > 
> > Elke,
> > 
> > Always difficult to diagnose those problems as there are a few variables
> > to consider.
> > Looking at the code of GDALReprojectImage(), I see it should take into
> > account the source nodata value, but it will ignore the nodata value
> > that you may have set on the target dataset, contrary to gdalwarp. That
> > might be your issue. Your source nodata values are likely to become 0 in
> > the target datasource.
> > 
> > Even

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


More information about the gdal-dev mailing list