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

[Stephen Woodbridge]

Sorry meant to send this to the list.


-------- Original Message --------
Subject: Re: [gdal-dev] Problem with results on two different versions 
of gdal_wrap
Date: Sun, 09 Mar 2014 15:22:23 -0400
From: Stephen Woodbridge <woodbri at swoodbridge.com>
To: Even Rouault <even.rouault at mines-paris.org>

Even, Etienne,

I'm still working on this. Thanks you both for your suggestions. I spent
10-12hr yesterday trying your suggestions and variation on that to make
things work (on this on top of past efforts) with little progress.

Etienne, I tried your suggestion but it did not make a difference so we
can eliminate the hdf reader as the problem.

Since I'm dealing with a multi-step process of downloading MODIS SST
(sea surface temperatures) and mapping them to geotif for display and
query in mapserver that I inherited. I have decided to try and recreate
the process from scratch starting with trying to get documentation from
the USF IMaRS site so I can better understand what I'm working with.

1. download sst hdf
2. convert to geoTiff
3. add color LUT as .vrt
4. render image in mapserver
5. query image and report temps in degrees C and F

I'm waiting on some email response from USF on documentation for the hdf
files. And I need break from banging my head against a wall :)

To be continued ...

Thanks,
   -Steve

On 3/8/2014 5:22 AM, Even Rouault 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
>