[gdal-dev] Problem with results on two different versions of gdal_wrap

[Etienne Tourigny]

Perhaps differences in the hdf driver between the two versions could
explain differences in output.

Try converting netcdf file to gtiff with gdal_translate (using one gdal
version), then try gdalwarp from that common gtiff file.


On Sat, Mar 8, 2014 at 7:22 AM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> >
> >
> > This is the problem step:
> >
> > gdalwarp -rcs -ts 8800 6600 -s_srs EPSG:32662 -t_srs EPSG:4326 temp.tif
> > target.tif
> >
> > gdalinfo -mm -stats target.tif
> >
> > is showing that the range of values in the image are dramatically
> > different on the two servers!
> >
> > summary old:
> > Band 1 Block=8800x1 Type=Int16, ColorInterp=Gray
> >      Computed Min/Max=-3877.000,32767.000
> >    Minimum=-3877.000, Maximum=32767.000, Mean=25235.731, StdDev=10612.642
> >
> >
> > summary new:
> > Band 1 Block=8800x1 Type=Int16, ColorInterp=Gray
> >    Min=-9314.000 Max=32561.000   Computed Min/Max=-9314.000,32561.000
> >    Minimum=-9314.000, Maximum=32561.000, Mean=19166.800, StdDev=7786.806
> >
> >
> > Ok, so you can see that the values are radically different. My question
> > is how do I get values like the old system? These values represent
> > temperatures and I need to get the same values.
> >
> > My one thought on this is that if is another side effrct of proj4
> > behaving differently as I had to adjust the position above to get it to
> > align. So maybe the gdalwarp is messing up the pixel values when it
> > reprojects it also. But I'm totally lost on how make this work correctly.
> >
> > Any thoughts on how to fix this?
>
> Stephen,
>
> I think we already had a discussion some time ago about differences between
> spherical or ellipsoidal projections, or am I confusing with someone else ?
>
> Well, it is not clear from your experiment if the difference is due to
> reprojection or to the resampling method.
>
> There's a difference between both GDAL versions, but is the new result
> worse
> than the previous one (from visual inspection) ?
>
> Cubic spline resampling seems to produce overshoot artifacts in both
> situations (since -3877.000 or -9314.000 in output < 377 in input). That's
> probably due to the maths behind.
>
> Maybe just try with the default nearest resampling to see if it is due to
> the
> resampling kernel or the reprojection.
>
> I'm also wondering if your data doesn't have a nodata value that you should
> explicitely set. As I can only guess, 32767 would be a good candidate given
> that the data type is Int16. But the " _FillValue=[65535]" in the metadata
> makes me wonder if the datatype shouldn't be UInt16 rather than Int16 in
> your
> initial conversion from netcdf to geotiff, and the nodata would rather be
> 65535
> ?
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140308/60fb4075/attachment.html>