Re: [thredds] Simple fix => much smaller TDS WMS GetCapabilities size (for model output)

Jon,

because you asked:
> Does anyone have any thoughts on this before I start an
> implementation?

- All the examples in this thread contain TIME values with millisecond precision. In many cases this is not required and the precision for the TIME values can be optimised. We use a very short TIME statement in our WMS Capabilities to offer monthly climate related statistics:

<Dimension name="time" units="ISO8601" default="1901-01" nearestValue="0">1901-01/2003-11/P1M</Dimension>

In case this is not already a feature of TDS it might be worth considering in an upcoming code revision.


Regards,
Matthias

Am 04.01.2011 11:54, schrieb Jon Blower:
Hi all,

I can certainly see that there is a problem that needs to be addressed here 
(explicit lists of all individual TIME values cause the Capabilities document 
to blow up).  There are actually two approaches to this, which could be used 
individually or in combination:

1) Use the syntax start/stop/period, potentially multiple times, to define the 
TIME values instead of listing them explicitly.

2) Use Layer inheritance properties to define the time dimension once only, if 
the same time axis is shared by all the children of a parent layer:

<Layer>
   <Title>My Model Output</Title>
   <!-- Non-displayable parent Layer -->
   <Dimension name="time">  ... values ...</Dimension>
   <Layer>
     <Title>sea_water_temperature</Title>
     <Name>TMP</Name>
     <!-- Inherits time axis from parent -->
   </Layer>
   <!-- More child layers -->
   <!-- Children can override the time axis if theirs is different for some reason 
-->
</Layer>

The most concise possible Capabilities doc would be achieved by combining both 
approaches.

I feel that we should ensure that only those time values that are actually present should appear in 
the Capabilities doc - I think things get a bit confusing if the Capabilities doc advertises 
"missing" times (what would the returned image from a missing time look like?).  I also 
agree with Bob Simons that the use of "nearest" values is dangerous, even though it's in 
the spec (sorry Kyle) - the client can always perform the nearest-neighbour calculation if this is 
required, given the server's advertised capabilities.  (Feel free to disagree with me of course!)

I can see two potential problems:

1. Solution 1 above is a bit tricky to implement in the general case, avoiding 
the corner cases.  (Solution 2 would actually be pretty easy to implement.)

2. As Ethan and Roy have pointed out, third-party client support for 
multidimensional WMS is, er, generally not great.  It's hard enough to find a 
client that supports TIME at all, never mind all the possible syntaxes.  I'm 
torn on this - in one respect it's not our problem, but we don't want to cut 
out portions of the user base.

So, after all this, I propose a solution:

1. Implement one or both measures above, ensuring that the Capabilities 
document is accurate.  This may involve being conservative.  The default 
Capabilities doc would be much smaller.

2. Allow clients to specify a URL parameter to GetCapabilities that triggers the 
generation of a Capabilities document that *does* list all the time values explicitly, 
allowing compatibility with some GIS clients.  (Clients usually require a URL to the Cap 
doc, which could include this non-standard URL parameter.  Or the parameter could be 
considered part of the "base URL").

Does anyone have any thoughts on this before I start an implementation?  It's tempting to 
implement the "layer inheritance" solution first since it's easiest; I think 
this would be effective in TDS, where each Cap doc usually represents a single model run, 
which will usually have a single time axis, shared among all variables.

Happy New Year!
Jon

--
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading, UK
Tel: +44 (0)118 378 5213
http://www.resc.reading.ac.uk


_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe,  visit: 
http://www.unidata.ucar.edu/mailing_lists/



--
Matthias Müller
Dipl.-Geogr. | Research Associate

Technische Universität Dresden
Geoinformation Systems
01062 Dresden

Phone: +49 351 463-31953
Fax: +49 351 463-35879
Mail: Matthias_Mueller@xxxxxxxxxxxxx

www: http://tu-dresden.de/fgh/geo/gis



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