Matt and I were just having a discussion regarding this topic today.
While I agree it is a compelling argument to implicitly interpret a
non-precise instant request (2012, for example) as a range
(2012-2013), I believe it should be avoided in favor of explicit
requests. I agree the WMS specs (1.1.1 and 1.3) are somewhat unclear
on this, but I believe clarity can be derived from the annex sections
C.5.2 and C.4.3 (1.1.1 and 1.3, respectively) that discuss this:
"""A WMS may declare that it will choose the closest available value
for a dimension if an exact value is not
specified. This allows, for example, hourly data whose actual
recording time is precise to the millisecond to be
requested simply by stating the desired date and hour. The
nearestValue attribute of the <Dimension> element, if
present and nonzero, indicates that this behaviour is enabled."""
While this applies more to the 'closest' (snapping) value than to
implicit conversion of an instant to an extent, I think the motivation
is similar - be explicit and when other behavior occurs, let the
client know.
Additionally, while it may make sense for certain instants to be
interpreted, e.g. 2012 means 2012-2013, it most certainly does not for
others, e.g -200000 (most likely the data is imprecise beyond a year).
While the implied period approach works well for simple,
multiplier-of-1 ranges, may domains use other ranges (10 year, 3
month, 6 hour, 30 minute, etc.) and may expect a similar behavior
(e.g. 2012-01-01T12:15:00 means 2012-01-01T12:00:00 to
2012-01-01T12:30:00 since the interval of that specific data is 30
minute).
So, I would argue that according to the spec:
1) 2012 means 2012-01-01T00:00:00Z
2) 2012/2013 means 2012-01-01T00:00:00Z-2013-01-01T00:00:00Z
(inclusive on both sides as per the spec)
Since most clients of a time aware mapping service will not require
the user to type out full-precision or ranges and will perform the
requests for the user, these implicit instant-to-extent "short-cuts"
can be taken there, but IMHO, don't belong on the server.
Cheers,
On Tue, Jun 5, 2012 at 5:32 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Tue, Jun 5, 2012 at 8:33 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:
On Mon, Jun 4, 2012 at 10:21 PM, Martin Davis <mdavis@anonymised.com> wrote:
> Here's a couple of data points for this discussion:
>
> http://mapserver.org/ogc/wms_time.html
>
> MapServer has addressed this issue (see the section Interpreting Time
> Values), but they seem to do different things depending on the back-end
> data
> source. For PostGIS at least they use the "time as time window"
> approach,
> by virtue of using the DB date_trunc function, which amounts to the same
> thing). One takeaway from this: I would suggest we want a data
> source-independent strategy.
>
>
> http://augusttown.blogspot.ca/2010/03/two-ambiguities-about-time-in-ogc-wms.html
>
> This blog post discuss the issue, and weighs in on the side of treating
> all
> time values as time windows (with duration determined by precision).
> This
> seems to make sense to me. Although, what then is meant by a TIME of
> 2012-06-01/2012-06-02". Is that the window including exactly June 1, or
> does it include June 1-2 ?
I agree the time window approach makes sense, and yes, the current
implementation
switches to a interval only if you explicitly ask for an interval,
otherwise the time
elements missing are assumed to be zero (from memory, at least).
Yup, it expands out by appending the zeros.
It may be an easy fix, inside the time kvp parser, if the time is not
fully specified
turn it into a interval?
We already handle t1/t2 as an extension to the wms spec (which would ask
for
a third parameter, the period).
Agreed, looks like is relatively straight forward and constrained to the kvp
parser. On my todo list to come up with a patch.
However... how do we handle a list of values that have no full precision?
Turn it into a list of intervals? Now, this we don't handle...
Yeah, good question. I will hunt through the spec to see if says anything
about that.
--
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.