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>
