search

ngageoint / opensphere

OpenSphere
Apache License 2.0
184 stars 90 forks source link

issue with WMS time support #661

Open tomkralidis opened 5 years ago

tomkralidis commented 5 years ago

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

Use case:

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 commented 5 years ago

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:

tomkralidis commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

wallw-teal commented 5 years ago

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 commented 5 years ago

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