My eyes were pretty red as well after going through both standards!
It would be nice if the CITE tests shed some light on this point. I was a
bit disappointed at how vague both the WMS and ISO standards were, though.
You'd think for something as critical and well-understood as time they'd
be able to produce a complete, unambiguous spec!
Good idea about trying to find a official WMS list.
On Tue, Jul 17, 2012 at 7:35 AM, Justin Deoliveira <[email protected]>wrote:
> This Martin, this helps a lot having something go through the specs. I can
> read them for about 5 minutes before my eyes start to bleed :) I will see
> what I can get out of the cite tests. I know there are tests for time but
> we don't ever run them and i thought i remembered Andrea trying and having
> serious issue with them.
>
> Doesn't anyone know of a wms-dev list like there is a wfs-dev list? I find
> you can usually get these types of answers there.
>
>
> On Mon, Jul 16, 2012 at 2:11 PM, Martin Davis <[email protected]> wrote:
>
>> A couple of other data points for this discussion:
>>
>> 1. The WMS spec for temporal says that it is an extension of ISO 8601.
>> References for that spec are:
>>
>> http://en.wikipedia.org/wiki/ISO_8601
>> http://dotat.at/tmp/ISO_8601-2004_E.pdf
>>
>> ISO 8601 says that it allows for the concept of "reduced accuracy" by
>> omitting lower-order time elements. (Sec 3.1 of the standard). The WMS
>> spec refers to this as "reduced precision" (Sec D.2.1). To my mind this
>> has to be interpreted to mean that a time string with omitted components
>> refers to a time *interval* of the appropriate size, rather than a
>> high-precision time instant. Otherwise, the term "reduced
>> precision/accuracy" has no meaning.
>>
>>
>> 2. This is more of a side comment, but it does have some relevance.
>> While the WMS spec says that it "extends" ISO 8601, it appears more that
>> it *alters* it. ISO 8601 allows time intervals to be specified using the
>> formats "start/end", "start/duration" and "duration/end". WMS appears to
>> allow only the syntax "start/end/duration". This forces the user to always
>> specify the end time. Since the end time is inclusiv, this is problematic
>> for specifying things like "all records from 2012". Using the obvious
>> 2012/2013/P1Y or even 2012-01-01T00:00:00Z-2013-01-01T00:00:00Z/P1Y would
>> potentially include some records from 2013 as well.
>>
>> (It seems like the WMS spec should allow for intervals specified as
>> start/end as well, but I can't see this in the spec. )
>>
>> The relevance of this is that if WMS really does only allow
>> "start/end/duration", in the absence of the ability to utilize "reduced
>> precision" clients are forced to specify a full precision end time, which
>> can be problematic to determine (think the classic February in leap years).
>>
>> The ISO way of allowing a time instance and a duration doesn't have this
>> problem, since the duration can be sized appropriately to the time
>> specified.
>>
>> I realize this verges on hair-splitting standards wonkery, but in the
>> absence of clearer language and examples there's not much else to go on.
>>
>>
>>
>>
>> On Mon, Jul 16, 2012 at 12:05 PM, Martin Davis <[email protected]>wrote:
>>
>>> The problem with making this configurable is that then nobody will know
>>> how any given GeoServer instance works. I would say that providing both
>>> options should be a last resort if it really ends up to be impossible to
>>> decide on a reasonable interpretation of the spec.
>>>
>>> Is it possible to ask OGC what the correct interpretation should be?
>>> Are there CITE tests which clarify this?
>>>
>>> And perhaps it's possible to see how other implementations have
>>> interpreted this? CubeWerx for instance?
>>>
>>> On Mon, Jul 16, 2012 at 9:31 AM, Justin Deoliveira <[email protected]
>>> > wrote:
>>>
>>>> Interesting take, and a good argument. On the one hand the spec does
>>>> seem to require the expansion into an interval, and other servers such as
>>>> mapserver have implemented it this way. On the other hand you poke some
>>>> pretty good holes in that heuristic. Maybe this is something worth
>>>> splitting the difference on and making it a configurable option?
>>>>
>>>>
>>>> On Fri, Jul 13, 2012 at 1:30 PM, Ian Schneider
>>>> <[email protected]>wrote:
>>>>
>>>>> 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 <
>>>>> [email protected]> wrote:
>>>>> >
>>>>> >
>>>>> > On Tue, Jun 5, 2012 at 8:33 AM, Andrea Aime <
>>>>> [email protected]>
>>>>> > wrote:
>>>>> >>
>>>>> >> On Mon, Jun 4, 2012 at 10:21 PM, Martin Davis <[email protected]>
>>>>> 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Justin Deoliveira
>>>> OpenGeo - http://opengeo.org
>>>> Enterprise support for open source geospatial.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Geoserver-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> Martin Davis
>>> OpenGeo - http://opengeo.org
>>> Expert service straight from the developers.
>>>
>>>
>>
>>
>> --
>> Martin Davis
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
--
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
