issue with WMS time support

[tomkralidis]

Using the demo at https://master-branch-opensphere-ngageoint.surge.sh, our WMS with time support appears to have problems being displayed.

Use case:

• add server https://geo.weather.gc.ca/geomet
• add layer 'Weather Radar/North American radar mosaic (1km)/ RADAR - Radar reflectivity (Rain) (1 km) [dBZ]'
• sample of the actual WMS request: https://geo.weather.gc.ca/geomet?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&EXCEPTIONS=INIMAGE&LAYERS=RADAR_1KM_RDBR&TIME=2019-07-09T00%3A00%3A00Z%2F2019-07-10T00%3A00%3A00Z&WIDTH=512&HEIGHT=512&CRS=EPSG%3A3857&STYLES=&BBOX=0%2C10018754.171394622%2C10018754.171394622%2C20037508.342789244

Here we see that the TIME parameter passes a time extent:

TIME=2019-07-09T00:00:00Z/2019-07-10T00:00:00Z

Our WMS service accepts time instants (which are described in the GetCapabilities response (start/end/frequency).

[wallw-teal]

The WMS/WMTS TIME support in OpenSphere is intended to only cover the absolute interval case described here. This best corresponds to the "Continuous Interval" value for the "Presentation" field when publishing a layer via GeoServer. This particular case indicates that any arbitrary time range can be sent by the client. However, the case is not well-represented in the WMS 1.3.0 specification, nor is it represented in the Best Practices for WMS with Time document. There is no value in the GetCapabilities <Dimension> tag that indicates that a server supports a continuous interval versus only supporting the instants/ranges at the specified period (GeoServer sends PT1S as the interval when that option is selected but that is not necessarily indicative of arbitrary interval support from other servers).

I would like to see better support for dimensions in both WMS and WMTS. We currently do not parse the <Dimension name="time" ...> tag other than to check whether it exists. <Dimension name="reference_time"> is completely ignored along with <Dimension name="elevation"> and other arbitrary dimensions.

This would entail the following work:

• Parse full <Dimension> tags from capabilities
  • Mark them as continuous if it uses units="ISO8601" and has a single interval with /PT1S or /0 as the resolution or has no interval defined e.g. <Dimension name="time" units="ISO8601/>
• The WMS 1.3.0 spec says that dimensions are to be inherited by enclosed layers, which I am 99% sure we aren't doing properly, so fix that.
• Pass those dimensions on the layer config to the layer
• WMS/WMTS animation should consult the name="time" dimension. If it is continuous, use the current logic. Otherwise use the best value from the dimension that intersects the current time window.
  • Update the cesium TileSynchronizer's updateAnimationCache_ in a similar fashion
  • I don't completely understand if <Dimension name="reference_time"> (or DIM_REFERENCE_TIME in the request) should be automatically adjusted when TIME is adjusted or if it should be left to the user as a manually adjusted dimension. Kinda sounds like it should be automatic. Is that simply the nearest instant in the interval/period to the selected TIME value?
• create a UI for adjusting manual dimensions
  • Use a select dropdown for lists and something better for ranges (spinner for numbers, maybe something nicer for dates); no idea how to represent multiple intervals
  • Note that only TIME and ELEVATION are requested with the name directly in WMS. All other dimensions use DIM_<name> in the request
• Adjust WMTS in a similar fashion and reuse as much as possible from the above work

[tomkralidis]

@wallw-bits thanks for the info.

I don't completely understand if (or DIM_REFERENCE_TIME in the request) should be automatically adjusted when TIME is adjusted or if it should be left to the user as a manually adjusted dimension. Kinda sounds like it should be automatic. Is that simply the nearest instant in the interval/period to the selected TIME value?

DIM_REFERENCE_TIME refers to the given time of a model run. I would imagine this would be set manually as a user may want to adjust TIME in the context of a given DIM_REFERENCE_TIME.

Feel free to use our WMS at https://geo.weather.gc.ca/geomet for tests (most layers are time enabled). Happy to test/provide feedback as required -- thanks!

[bradh]

I think weather people understand this a bit differently to the rest of us.

Imagine you have a computer model for weather prediction run once per day (6 or 12 hours is more usual, but daily will be enough for this analogy), and it predicts temperatures at each hour over the next week (so hours go from 0 to 167). TIME is which of the 168 hours you want.

REFERENCE_TIME is which set of forecasts (i.e. group of 168 estimates) you want. So do you want the numbers that were run today, yesterday (which has a partial overlap of 168 estimates, but with different values), or some other number of days ago?

Non-technical users almost always want the most recent forecast (i.e. greatest available reference time), which is conveniently the default. Any other reference time is an advanced feature.

[wallw-teal]

REFERENCE_TIME is which set of forecasts (i.e. group of 168 estimates) you want.

I get that. However, if you animate over historical predictions, some TIME values will be invalid for the default (most current) DIM_REFERENCE_TIME. That's why changing it automatically might be necessary, but there are also multiple valid DIM_REFERENCE_TIME values in the past for that particular TIME so that could also be odd.

Also, @tomkralidis, we would be happy to use that server for testing, but it does not seem to be sending the InvalidDimensionValue and NoMatch exceptions as recommended by the WMS TIME Best Practices. I am seeing "Internal Server Error" instead.

[tomkralidis]

@wallw-bits can you provide the URL causing the 500?

[wallw-teal]

https://geo.weather.gc.ca/geomet?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=RADAR_1KM_RDBR&TIME=2019-07-09T00%3A00%3A00Z&WIDTH=512&HEIGHT=512&CRS=EPSG%3A3857&STYLES=&BBOX=0%2C10018754.171394622%2C10018754.171394622%2C20037508.342789244

[tomkralidis]

@wallw-bits we've pushed an update. Can you try again?