Re: [thredds] FW: TDS 4.29 WMS/WCS issues (Pan, Jerry Yun)

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.



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
Content-Type: text/plain; charset="us-ascii"


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.


From: Pan, Jerry Yun
Sent: Thursday, December 29, 2011 3:16 PM
To: 'support-thredds@xxxxxxxxxxxxxxxx'
Subject: TDS 4.29 WMS/WCS issues


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:, 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" ?> 
 <ServiceExceptionReport version="1.3.0" xmlns=""; 
  <ServiceException>Unexpected error of type 
java.lang.IllegalArgumentException: The calendar system 365_day cannot be 

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:<>

On our testing server, the same error is encountered when access the WMS link:
  <?xml version="1.0" encoding="UTF-8" ?> 
 <ServiceExceptionReport version="1.3.0" xmlns=""; 
  <ServiceException>Unexpected error of type 
java.lang.IllegalArgumentException: The calendar system noleap cannot be 

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

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" 

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 

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:

 <  <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>

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
  <  requestCRSs>OGC:CRS84</requestCRSs>
  <  responseCRSs>EPSG:9802 [Lambert_Conformal_Conic_2SP]</responseCRSs>

-------------- next part --------------
An HTML attachment was scrubbed...

End of thredds Digest, Vol 35, Issue 17

  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: