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 Kyle, Great that you've had a go at #1. I'll chew it over and merge it when I get a chance. Regarding the custom URL parameter - generally I agree that non-standard params are to be avoided if possible, but actually in the case of a Capabilities doc I don't think it's so bad. A GIS will often ask for the full Capabilities URL, in which case you can simply add the custom parameter to the URL that's given. If the GIS asks for the "base" URL, it can still work, i.e. you pass it: http://myserver.com/wms?CUSTOM_PARAM=foo instead of http://myserver.com/wms. ncWMS does this already, in fact, with the DATASET parameter (which isn't used in TDS-WMS). Cheers, Jon -----Original Message----- From: Kyle Wilcox [mailto:KWilcox@xxxxxxxxxxxxxx] Sent: 04 January 2011 15:10 To: 'Jon Blower'; thredds@xxxxxxxxxxxxxxxx Subject: RE: [thredds] Simple fix => much smaller TDS WMS GetCapabilities size (for model output) I'd prefer a configurable setting rather than a custom URL parameter. I try to avoid extending specifications if at all possible. No existing clients will know about the additional parameter, and some datasets won't benefit from start/stop/step. On the downside, the GetCap could list all of the times for some datasets, and use start/stop/step for some others. At least with a URL parameter, it would be consistent. I took a simple stab at #1 a few weeks ago. The rounding isn't triggered by a flag in the GetCapabilities request, it is instead enabled by using a checkbox in the admin panel on each dataset It finds the smallest interval between all timesteps in the dataset and then assumes that this interval is consistent throughout the dataset. It steps through all of the timesteps and if the interval between two adjacent timesteps is greater than the smallest found interval, it ends the current "start/stop/step" and starts another. >From what I've seen, it works, but I haven't tested it at all. https://github.com/asascience/ncWMS/commit/9e2925fc607a05d6484299e017db0180a2200fa4 --------- Kyle Wilcox, Engineer Applied Science Associates 55 Village Square Drive South Kingstown, RI 02879 p: (401) 789-6224 e: kwilcox@xxxxxxxxxxxxxx -----Original Message----- From: thredds-bounces@xxxxxxxxxxxxxxxx [mailto:thredds-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jon Blower Sent: Tuesday, January 04, 2011 5:54 AM To: thredds@xxxxxxxxxxxxxxxx Subject: Re: [thredds] Simple fix => much smaller TDS WMS GetCapabilities size (for model output) 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/
thredds
archives: