Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default attribute should not be used to serve response inside Time extent #260

Closed
jfbourgon opened this issue May 21, 2020 · 0 comments · Fixed by #279
Closed

Default attribute should not be used to serve response inside Time extent #260

jfbourgon opened this issue May 21, 2020 · 0 comments · Fixed by #279
Assignees

Comments

@jfbourgon
Copy link

jfbourgon commented May 21, 2020

According to the WMS 1.3.0 specifications, the default attribute defined on the Timedimension should only be used when the TIME parameter is omitted.

Default field: Attribute indicating default value that will be used if GetMap request does not specify a value. If attribute is absent, then shall respond with a service exception if request
does not include a value for that dimension.

Current implementation serves the default Time for any non existent Time period requested between the Time Extent boundaries defined in the WMS GetCapabilities.

For instance, based on the following Time Extent:

<Layer queryable="false">
<Name>red</Name>
<Title>Red band of LandSat Mosaic</Title>
...
<Dimension default="2014-07-01T12:00Z" units="ISO8601" name="time">2014-07-01T12:00:00Z/2016-07-01T12:00:00Z</Dimension>
...
</Layer>

with following Time period available in the source dataset:

<TemporalDomain>
<gml:TimePosition>2014-07-01T12:00:00Z</gml:TimePosition>
<gml:TimePosition>2015-07-01T12:00:00Z</gml:TimePosition>
<gml:TimePosition>2016-07-01T12:00:00Z</gml:TimePosition>
</TemporalDomain>

GetMap requests will throw BadRequest ServiceException for TIME=2017-07-01T12:00:00Z (value outside of the provided Time extent) but will serve the Default for TIME=2015-09-01T12:00:00Z (non existent value located inside the provided Time extent)

The expected behaviour would be to raise a ServicException in both cases.

Another option would be to implement support for the nearest attribute that would inform clients that the nearest value would be served if the request is not exactly matching one of the existing time period.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants