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.roua...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
