<div dir="ltr">Perhaps differences in the hdf driver between the two versions could explain differences in output. <div><br></div><div>Try converting netcdf file to gtiff with gdal_translate (using one gdal version), then try gdalwarp from that common gtiff file.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 8, 2014 at 7:22 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">><br>
><br>
> This is the problem step:<br>
><br>
> gdalwarp -rcs -ts 8800 6600 -s_srs EPSG:32662 -t_srs EPSG:4326 temp.tif<br>
> target.tif<br>
><br>
> gdalinfo -mm -stats target.tif<br>
><br>
> is showing that the range of values in the image are dramatically<br>
> different on the two servers!<br>
><br>
> summary old:<br>
> Band 1 Block=8800x1 Type=Int16, ColorInterp=Gray<br>
>      Computed Min/Max=-3877.000,32767.000<br>
>    Minimum=-3877.000, Maximum=32767.000, Mean=25235.731, StdDev=10612.642<br>
><br>
><br>
> summary new:<br>
> Band 1 Block=8800x1 Type=Int16, ColorInterp=Gray<br>
>    Min=-9314.000 Max=32561.000   Computed Min/Max=-9314.000,32561.000<br>
>    Minimum=-9314.000, Maximum=32561.000, Mean=19166.800, StdDev=7786.806<br>
><br>
><br>
> Ok, so you can see that the values are radically different. My question<br>
> is how do I get values like the old system? These values represent<br>
> temperatures and I need to get the same values.<br>
><br>
> My one thought on this is that if is another side effrct of proj4<br>
> behaving differently as I had to adjust the position above to get it to<br>
> align. So maybe the gdalwarp is messing up the pixel values when it<br>
> reprojects it also. But I'm totally lost on how make this work correctly.<br>
><br>
> Any thoughts on how to fix this?<br>
<br>
</div>Stephen,<br>
<br>
I think we already had a discussion some time ago about differences between<br>
spherical or ellipsoidal projections, or am I confusing with someone else ?<br>
<br>
Well, it is not clear from your experiment if the difference is due to<br>
reprojection or to the resampling method.<br>
<br>
There's a difference between both GDAL versions, but is the new result worse<br>
than the previous one (from visual inspection) ?<br>
<br>
Cubic spline resampling seems to produce overshoot artifacts in both<br>
situations (since -3877.000 or -9314.000 in output < 377 in input). That's<br>
probably due to the maths behind.<br>
<br>
Maybe just try with the default nearest resampling to see if it is due to the<br>
resampling kernel or the reprojection.<br>
<br>
I'm also wondering if your data doesn't have a nodata value that you should<br>
explicitely set. As I can only guess, 32767 would be a good candidate given<br>
that the data type is Int16. But the " _FillValue=[65535]" in the metadata<br>
makes me wonder if the datatype shouldn't be UInt16 rather than Int16 in your<br>
initial conversion from netcdf to geotiff, and the nodata would rather be 65535<br>
?<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br></div>