OGC WMS specification had included “TIME” dimension since version 1.1.0, in which it guides the WMS implementations on how “TIME” is involved in filtering feature that will finally be visible in either a result map or a query result (aka. GetFeatureInfo result). To me, what it defines about “TIME” dimension in WMS spec seems to be both accurate and ambiguous. It is accurate because it introduces the ISO 8601 standard to cover the exchange of date and time related parameters between a WMS server and a WMS client, which eliminate the risk of misinterpretation where numeric representation of dates and times are interchanged across national boundaries, and to avoid the confusion and other consequential errors or losses (quoted from wiki ISO8601 entry). But it’s also ambiguous in two places (1) where an interpretation is needed for an ISO standard time string; (2) where a temporal attribute has different meanings for different types of features. In this blog let’s skip the accurate part that I am happy with, but discuss the ambiguous part using a few examples.
The first ambiguity is actually not a problem of WMS spec itself but comes from the nature of the data when a temporal attribute value has different meanings for different types of features. Basically time values can ne divided into two different types: time as a individual time point and time as a time window. Time as a time point doesn’t have any relation to its history or future, one good example is a rocket feature with a time attribute called “launch” that has a value of “2000-03-04T00:00:00Z”. It means the rocket launched at Mar.4th 2000 at 12 am which has nothing to do with any time before it or after. But time as a time window instead expand backward or forward. One example is a house feature that has time attribute called “built” with a value of “2000”, it actually affects the time after 2000 because the house exists since then. Another example is an animal species with time attribute “extinct” of value “2000”, which actually affects the time before 2000 because the animal species had existed before 2000. Given the fact that all of those single time values are treated the same in database, it will potentially affect the result of a query on those features.
The second ambiguity in WMS spec, as I mentioned above is the interpretation for a time value. For example, when you send a WMS request like “http://…/…request=GETMAP&…&TIME=2010”, what does it exactly mean? It sounds like a stupid question because everyone knows “2010” meaning year 2010, which is clearly defined in ISO8601 as valid. But how do you interpret this request is ambiguous. Assume you’re a time-enabled WMS server and you have some features with time stamps between 2010 and 2011 (any month, day, hour, minute, or second within 2010), will you include those features in the map response to request “…&TIME=2010”? I bet you answer yes without hesitation because naturally “TIME=2010” means within 2010. But will you give it a second thought if I give a different request “http://…/…request=GETMAP&…&TIME=2010-12-10T12” on the same set of features? Do you still think you should include all the features between 12pm and 1pm on 2010-12-10? I don’t think so but that’s actually the same logic you used when you process request “http://…/…request=GETMAP&…&TIME=2010”.
If you’re implementing a TIME-enabled WMS at server-side you probably already encountered those two problems, and I don’t think the solution is simply throwing the TIME values to database for string comparison even if the database is aware of date/time type. The best way I can think of is always using time window internally (even though sometimes that time window is very small) for both feature temporal attributes and time parameter in the WMS request. To be more specific, when serving out you data if you have a rocket feature launched at “2000-03-04T00:00:00Z” then explicitly treat it as “2000-03-04T00:00:00.000Z/2000-03-04T00:00:00.999Z”; if you have a house built on “2010” then explicitly treat it as “2010/far future”; and finally if you have an animal species extinct in 2000 then explicitly treat it as “long ago/2000”. Now when it comes to time parameter in WMS request, the spec allows syntaxes like “TIME=time1”, “TIME=time_start/time_end”, “TIME=time1,time2” and “TIME=time_start1/time_end1,time_start2/time_end2” but no matter what client sends to you, my suggestion is to always treat each single time value as a time window based on its smallest interval. For example, if “TIME=2000” then treat it as “TIME=2000/2001” (the smallest time interval is year); if “TIME=2000-03-04T00:05Z” treat it as “2000-03-04T00:05Z/2000-03-04T00:06Z” (the smallest time interval is minute) and so on. By using this mechanism every time relate value is a time window, which makes the query more straight forward, just include the feature either in map or query results if the query time window touches, intersects or contains the time window of feature temporal attribute. Although it won’t totally solve the ambiguity above, it helps improve the accuracy.
No comments:
Post a Comment