Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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/
thredds archives: