NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi, I sent the following to support-thredds, but maybe I should have sent to this email list? I am looking for help on the issues I saw on the WMS/WCS services regarding interpretation of "time" dimension. I tried a few options detailed in this email below. Thanks in advance. -Jerry From: Pan, Jerry Yun Sent: Thursday, December 29, 2011 3:16 PM To: 'support-thredds@xxxxxxxxxxxxxxxx' Subject: TDS 4.29 WMS/WCS issues Hi, We just setup an instance here at ORNL to serve some NetCDF gridded files (in Lambert Conformal Conic Projection), with a time dimension of calendar days and the Lambert x, y dimensions. The Lat/Lon are provided in the files (based on the x,y). We encountered problems with WMS/WCS, as detailed below. The sample time is all the calendar days for 2008 (1-365). This is a TDS 4.29 install, with Tomcat6, and I did not do anything special other than just turn all the services on and pointing to my data directory in a datascan instruction. Could someone shed some light on this, is there anything we should be doing to make this work, or these issues are known deficiencies in TDS? Thank much in advance, -Jerry Pan Problem descriptions below: ================================================ 1) Time dimension's calendar attributes caused exception: The original file (CF-compliant) looks like this one: http://webmap.ornl.gov/temp/vp.nc, where the "time" is 365 day of the year 2008 (since 1980 Jan 1), no leap year (many model output uses straight 365 day for each year). The "time" dimension has a "calendar" attribute set to "365_day" On the testing TDS server, we encountered issues with the WMS/WCS data access options - the server is not public but the wms link (get capability) encountered error: " <?xml version="1.0" encoding="UTF-8" ?> -<http://daymet.ornl.gov:9080/thredds/wms/allUS/2008/12464_2008/vp.nc?service=WMS&version=1.3.0&request=GetCapabilities> <ServiceExceptionReport version="1.3.0" xmlns="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wms/1.3.0/exceptions_1_3_0.xsd<http://www.opengis.net/ogc%20http:/schemas.opengis.net/wms/1.3.0/exceptions_1_3_0.xsd>"> <ServiceException>Unexpected error of type java.lang.IllegalArgumentException: The calendar system 365_day cannot be handled</ServiceException> </ServiceExceptionReport> 2) Seeing that the calendar attribute "365_day" caused the problem, we than changed the calendar attributes to "noleap" : still get the exception The modified file is accessible from: http://webmap.ornl.gov/temp/vp_modified.nc<http://webmap.ornl.gov/temp/vp.nc> On our testing server, the same error is encountered when access the WMS link: <?xml version="1.0" encoding="UTF-8" ?> -<http://daymet.ornl.gov:9080/thredds/wms/allUS/vp_modified.nc?service=WMS&version=1.3.0&request=GetCapabilities> <ServiceExceptionReport version="1.3.0" xmlns="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wms/1.3.0/exceptions_1_3_0.xsd<http://www.opengis.net/ogc%20http:/schemas.opengis.net/wms/1.3.0/exceptions_1_3_0.xsd>"> <ServiceException>Unexpected error of type java.lang.IllegalArgumentException: The calendar system noleap cannot be handled</ServiceException> </ServiceExceptionReport> 3) Now we stripped out the "calendar" attribute completely for the "time" dimension, the WMS would work but the time is off This version of the file is accessible from http://webmap.ornl.gov/temp/vp_modified2.nc This works, and the returned WMS getCapability is valid XML, but the time interpretation is off by a few days as the leap year are considered: The snippet in the WMS getCapability (the wms link) around the time stamps starts like: <Dimension name="time" units="ISO8601" multipleValues="true" current="true" default="2008-12-23T12:00:00.000Z">2007-12-25T12:00:00.000Z,2007-12-26T12:00:00.000Z,2007-12-27T12:00:00.000Z,2007-12-28T12:00:00.000Z,2007-12-29T12:00:00.000Z,2007-12-30T12:00:00.000Z,2007-12-31T12:00:00.000Z,2008-01-01T12:00:00.000Z,2008-01-02T12:00:00.000Z,2008-01-03T12:00:00.000Z,2008-01-04T12:00:00.000Z,2008-01-05T12:00:00.000Z,2008-01-06T12:00:00.000Z,2008-01-07T12:00:00.000Z,2008-01-08T12:00:00.000Z,2008-01-09T12:00:00.000Z,2008-01-10T12:00:00.000Z,2008-01-11T12:00:00.000Z,2008-01-12T12:00:00.000Z,2008-01-13T12:00:00.000Z,2008-01-14T12:00:00.000Z,2008-01-15T12:00:00.000Z,2008-01-16T12:00:00.000Z,2008-01-17T12:00:00.000Z,2008-01-18T12:00:00.000Z,2008-01-19T12:00:00.000Z,2008-01-20T12:00:00.000Z,2008-01-21T12:00:00.000Z,2008-01-22T12:00:00.000Z,2008-01-23T12:00:00.000Z,2008-01-24T12:00:00.000Z,2008-01-25T12:00:00.000Z,2008-01-26T12:00:00.000Z,2008-01-27T12:00:00.000Z,2008-01-28T12:00:00.000Z,2008-01-29T12:00:00.000Z,2008-01-30T12:00:00.000Z,2008-01-31T12:00:00.000Z,2008-02-01T12:00:00.000Z,2008-02-02T12:00:00.000Z,2008-02-03T12:00:00.000Z,2008-02-04T12:00:00.000Z,2008-02-05T12:00:00.000Z,2008-02-06T12:00:00.000Z,2008-02-07T12:00:00.000Z,2008-02-08T12:00:00.000Z,2008-02-09T12:00:00.000Z,2008-02-10T12:00:00.000Z,2008-02-11T12:00:00.000Z,2008-02-12T12:00:00.000Z,2008-02-13T12 Where it should have started from Jan. 1, 2008 - this is of course, due to the fact that the "time" dimension in this file was specified as "units: days since 1980-01-01T00:00:00Z" 4) WCS Time is off On all three versions of the NetCDF file (calendar=365_day, calendar=noleap, or no calendar attribute), the WCS getCapability return valid XML but the time portion appears to be the same, i.e., it does not respect the calendar attribute and the timeposition would be off just like WMS: -<http://daymet.ornl.gov:9080/thredds/wcs/allUS/2008/12466_2008/vp.nc?service=WCS&version=1.0.0&request=GetCapabilities> < <lonLatEnvelope srsName="urn:ogc:def:crs:OGC:1.3:CRS84"> < gml:pos>-90.32101885741514 47.836444067446045</gml:pos> < gml:pos>-87.69008805672274 50.1671881389257</gml:pos> < gml:timePosition>2007-12-25T12:00:00Z</gml:timePosition> < gml:timePosition>2008-12-23T12:00:00Z</gml:timePosition> </lonLatEnvelope> WC 5) WCS not working at all when access from ArcGIS, it is returning anything back from the THREDDS server - Could this be due to the projection? The describeCoverage call would return something like <supportedCRSs> < requestCRSs>OGC:CRS84</requestCRSs> < responseCRSs>EPSG:9802 [Lambert_Conformal_Conic_2SP]</responseCRSs> </supportedCRSs>
thredds
archives: