[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