> The netCDF file stored the depths as single-precision floats, and the
NetCDF-Java lib reads these floats and converts to double-precision
floats. If I would guess, that
> appears to be the step that introduces the low bit errors in the
values.
Hi Tim - yes, the conversion from 32- to 64- bit real numbers introduces
spurious precision. I think this is a general feature of digitised
floating-point numbers. In Java we don't have to worry about zeroing
out arrays and such-like - memory is "safe". We could ensure that the
numbers are only displayed to 32-bit precision even if they are 64-bit
internally - I've filed a "todo" for this
(http://www.resc.rdg.ac.uk/trac/ncWMS/ticket/184).
Cheers, Jon
From: Tim Pugh [mailto:T.Pugh@xxxxxxxxxx]
Sent: 03 August 2010 01:48
To: Jon Blower; thredds@xxxxxxxxxxxxxxxx
Subject: Re: [thredds] Incorrect values for elevation (WMS)
[SEC=UNCLASSIFIED]
Hi Jon,
I think the elevation error is only a presentation issue unless someone
is doing geospatial analysis, then they may be using the value. Given
the error is in the low order bits, the error should not cause any
issues, only inconsistencies with documentation.
I do not expect you to change the WMS code for this issue.
Jon, you did seem to highlight a general issue of single to double float
conversions in the NetCDF-Java libs. That could be a concern for more
general applications of the library.
The netCDF file stored the depths as single-precision floats, and the
NetCDF-Java lib reads these floats and converts to double-precision
floats. If I would guess, that appears to be the step that introduces
the low bit errors in the values. You might try zeroing the memory
before passing the variable to NetCDF-Java lib to see if produces a
different result.
- Tim -
On 3/08/10 1:29 AM, "Jon Blower" <j.d.blower@xxxxxxxxxxxxx> wrote:
Hi Tim, all,
The thing is that the NetCDF-Java libs (on which the WMS is based) give
access to the coordinate values as an array of double-precision numbers.
It would be possible, although complex in code, to circumvent this in
the WMS and find out whether the source files used 32- or 64-bit
numbers. This is doable, although I'm only prepared to add the extra
complexity if this is a serious issue. Is this really just a matter of
presentation or is there something deeper here?
Cheers, Jon
From: Tim Pugh [mailto:T.Pugh@xxxxxxxxxx]
Sent: 21 July 2010 09:27
To: Jon Blower; thredds@xxxxxxxxxxxxxxxx
Subject: Re: [thredds] Incorrect values for elevation (WMS)
[SEC=UNCLASSIFIED]
Hi Jon,
The 32-bit to 64-bit floating number conversion is flawed. As a
modeler, it's not an acceptable operation, and could lead to other
issues. For displaying elevations, it's probably not critical, but an
annoyance in WMS. Although, it would be nice to avoid all those user
questions, and not have to explain the inconsistency and conversion
issue again and again.
Regards,
- Tim -
On 20/07/10 6:35 PM, "Jon Blower" <j.d.blower@xxxxxxxxxxxxx> wrote:
Hi Pauline, Ethan, all,
The ELEVATION dimension for WMS is defined with the positive direction
going up. Since your metadata are defined with positive=down,
THREDDS-WMS is making all values negative. I think this is correct
behaviour so you shouldn't need to do anything.
However, if you're worried about the difference in precision between the
source metadata and the values in the Capabilities document, I'm not
sure what can easily be done about this. You are storing depth values
as 32-bit floats, but the WMS uses 64-bit doubles, hence the apparently
spurious precision. Is this an important thing to fix for you?
Cheers, Jon
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Jul 2010 08:46:57 +1000
From: Pauline Mak <Pauline.Mak@xxxxxxxxxxx>
To: THREDDS THREDDS <thredds@xxxxxxxxxxxxxxxx>
Subject: Re: [thredds] Incorrect values for elevation (WMS)
Message-ID: <4C44D5E1.7030302@xxxxxxxxxxx>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Hi Ethan,
Yes! It does indeed have an attribute of:
positive: "down"
So should we convert values (and metadata) to have positive values going
up?
Cheers,
-Pauline.
On 20/07/10 1:48 AM, Ethan Davis wrote:
> Hi Pauline,
>
> Does the zt_ocean variable have a "positive" attribute with a value of
> "down"?
>
> zt_ocean:positive = "down" ;
>
> If so, then the WMS may be converting the values so that positive Z is
> upwards.
>
> Ethan
>
> On 7/18/2010 11:19 PM, Pauline Mak wrote:
>> Hi all,
>>
>> I've found some problems with how the WMS servlet shows elevation
values.
>>
>> We have a NetCDF file with these values in it (using the OPeNDAP
>> ASCII
>> response):
>>
>> zt_ocean[47]
>> 5.0, 15.0, 25.0, 35.0, 45.0, 55.0, 65.0, 75.0, 85.0, 95.0, 105.0,
>> 115.0, 125.0, 135.0, 145.0, 155.0, 165.0, 175.0, 185.0, 195.0, 205.0,
>> 216.50769, 232.35658, 254.85658, 285.51538, 324.8566, 372.3566,
>> 426.50772, 485.00003, 545.0, 609.0192, 684.0192, 774.0192, 879.0192,
>> 995.0, 1115.0, 1237.4758, 1366.8885, 1506.3256, 1656.8885, 1817.4758,
>> 1985.0, 2155.0, 2404.449, 2861.898, 3576.449, 4499.0
>>
>> However, in the WMS GetCapabilities document, the elevation values
>> are shown like so:
>>
>> <Dimension name="elevation" units="meters" default="-5.0">
>> -5.0,-15.0,-25.0,-35.0,-45.0,-55.0,-65.0,-75.0,-85.0,-95.0,-105.0,-11
>> 5.0,-125.0,-135.0,-145.0,-155.0,-165.0,-175.0,-185.0,-195.0,-205.0,-2
>> 16.5076904296875,-232.35658264160156,-254.85658264160156,-285.5153808
>> 59375,-324.8565979003906,-372.3565979003906,-426.5077209472656,-485.0
>> 000305175781,-545.0,-609.0192260742188,-684.0192260742188,-774.019226
>> 0742188,-879.0192260742188,-995.0,-1115.0,-1237.475830078125,-1366.88
>> 85498046875,-1506.3255615234375,-1656.8885498046875,-1817.47583007812
>> 5,-1985.0,-2155.0,-2404.448974609375,-2861.89794921875,-3576.44897460
>> 9375,-4499.0
>>
>> </Dimension>
>>
>> The values are float32s:
>>
>> Float32 zt_ocean[zt_ocean = 47];
>>
>> So it looks like there's some precision problems?
>>
>> I am using TDS Version 4.2.20100607.1833 - 20100607.1833
>>
>> Cheers,
>>
>> -Pauline.
>>
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
