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 Jerry, Jon is correct, TDS 4.2 is behind the ncWMS and does not handle alternate calendars. When 4.3 comes out, both netCDF-Java and TDS will handle a number of alternate calendars (including 360- and 365-day years). We are planning on an alpha release of 4.3 in the next few weeks. Jon, with netCDF-Java 4.3 supporting alternate calendars, any thoughts on how much work it will take to upgrade ncWMS to netCDF-Java 4.3? Cheers, Ethan On 1/3/2012 4:22 AM, Jon Blower wrote: > Hi Jerry, > > The Unidata folk could confirm, but I think this is because the WMS > version in TDS is a little behind the standalone ncWMS and does not > yet recognize 365-day calendars. A near-future release should fix > this. John or Ethan could advise on timescales. > > HTH, > Jon > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Dec 2011 16:25:32 -0500 > From: "Pan, Jerry Yun" <pany@xxxxxxxx> > To: "thredds@xxxxxxxxxxxxxxxx" <thredds@xxxxxxxxxxxxxxxx> > Subject: [thredds] FW: TDS 4.29 WMS/WCS issues > Message-ID: > <6F3F80C5681DB84D8688AF84F81E460FA83EDFB095@xxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="us-ascii" > > 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,2 008 > > -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: