#2154 closed defect (fixed)
[SOS-Server] eventTime not working
Reported by: | tomkralidis | Owned by: | assefa |
---|---|---|---|
Priority: | normal | Milestone: | 5.0 release |
Component: | SOS Server | Version: | |
Severity: | major | Keywords: | |
Cc: | assefa, cplist, jmckenna |
Description
The following long URL should not return any hits since there is no record in our db that falls between the eventTime range I specify as part of the URL.
http://sos-web.tamu.edu/sos-cgi/madis?service=sos&request=GetObservation&version=0.1.2&offering=ndbc_44029&responseFormat=text/xml;%20subtype=om/0.14.7&observedProperty=http://marinemetadata.org/cf%23air_pressure_at_sea_level&eventTime=<gml:TimePeriod><gml:beginPosition>1990-01-01</gml:beginPosition><gml:endPosition>1990-02-01</gml:endPosition></gml:TimePeriod>
There is always only 1 row that should be returned -- the most recent observation. As of right now, the time is <time>2007-07-12 07:04:00-05</time> which isn't anywhere near the TimePeriods defined in the query URL.
Attachments (1)
Change History (18)
by , 17 years ago
Attachment: | sos_tst.tar added |
---|
comment:1 by , 17 years ago
Cc: | added |
---|
comment:2 by , 17 years ago
Cc: | added; removed |
---|
Hi, all. I am wondering where this bug fits in the release priority queue. We are working on an OGC Interoperability Experiment (http://www.oostethys.org/ogc-oceans-interoperability-experiment) that would greatly benefit from this bug's resolution. As well as what appears to me to be a related eventTime WFS feature request http://trac.osgeo.org/mapserver/ticket/1583. Of course, I'm happy to help in whatever way possible.
comment:3 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
It is set to be fixed for the 5.0 release. I won't be able to adress it before late next week. Will update the bug when I work on it.
comment:4 by , 17 years ago
Commited fix in r6426. The issue in this case with the sample data, was that there was nothing done on the layer if the eventTime passed did not satisfy the sos_offering_timeextent set on the layer. The fix was to turn the layer off if that happens.
Plase verfify and close.
comment:5 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Tested on svn trunk. Works.
Here's an exmaple (my mapfile defines MAP/LAYER/METADATA/sos_offering_timeextent = "1990/2006"
http://devgeo.cciw.ca/cgi-bin/mapserv/sostest?service=SOS&version=0.1.2&request=GetObservation&offering=Water&observedproperty=WaterQuality&responseFormat=text/xml;%20subtype=om/0.14.7&eventtime=<gml:TimePeriod><gml:beginPosition>1988-01-01</gml:beginPosition><gml:endPosition>1989-02-01</gml:endPosition></gml:TimePeriod>
Charlton: let us know if you still have problems.
comment:7 by , 17 years ago
Hmm. If I enter a time out of bounds, it works fine (no data returned). But I can't pull back any data when I specify what I think should be a valid time bound.
<gml:TimePeriod><gml:beginPosition>2007-07-11</gml:beginPosition><gml:endPosition>2007-07-13</gml:endPosition></gml:TimePeriod>
I'm still using the original .csv from the example, and its lone time is <time>2007-07-12 07:04:00-05</time>.
I can see it just fine w/o passing any eventTime. I am using the nightly snapshot tarball.
comment:8 by , 17 years ago
This URL return the record for me (mapserver from svn today) : http://127.0.0.1/cgi-bin/mapserv.exe?map=c:/msapps/tmp/sos/bug2154/madis_tst.map&service=sos&request=GetObservation&version=0.1.2&offering=ndbc_44029&responseFormat=text/xml;%20subtype=om/0.14.7&observedProperty=http://marinemetadata.org/cf%23air_pressure_at_sea_level&eventTime=<gml:TimePeriod><gml:beginPosition>2007-07-11</gml:beginPosition><gml:endPosition>2007-07-13</gml:endPosition></gml:TimePeriod>
Note that I have commented out the "sos_offering_timeextent" on the layer
comment:9 by , 17 years ago
I ran the same test against Charlton's test data this time and can confirm the same result. Charlton: can you confirm?
Assefa: if I set sos_offering_timeextent "2006/2007" on the test mapfile, I get no results; if I set to "2006/2008", I still get no results. Should this not work?
Charlton: somewhat unrelated, but you might want to think about encoding your observedproperty id's without the '#' character, which has to be encoded (%23) to be processed accordingly, this might trip up clients, especially when binding from GetCapabilities responses.
comment:10 by , 17 years ago
Tom,
2006/2007 should not return any value since 2007 is interpreted as 2007-01-01
I just set the "sos_offering_timeextent" "2006/2008" and I get the following results as expected:
<?xml version="1.0" encoding="ISO-8859-1"?> <om:ObservationCollection xmlns:gml="http://www.opengis.net/gml" xmlns:ows="http://www.opengis.net/ows" xmlns:swe="http://www.opengis.net/swe" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sos="http://www.opengis.net/sos" xmlns:om="http://www.opengis.net/om" gml:id="ndbc_44029" xsi:schemaLocation="http://www.opengis.net/om http://schemas.opengis.net/0.14.7/om.xsd">
<om:eventTime>
<gml:TimePeriod>
<gml:beginPosition>2006</gml:beginPosition> <gml:endPosition>2008</gml:endPosition>
</gml:TimePeriod>
</om:eventTime> <om:member>
<om:Observation>
<time>2007-07-12 07:04:00-05</time> <om:procedure xlink:href="urn:ogc:def:procedure:ndbc_44029"/> <observedProperty>http://marinemetadata.org/cf#air_pressure_at_sea_level</observedProperty> <om:result>
<gml:featureMember xmlns:gml="http://www.opengis.net/gml">
<gml:layer_1>
<gml:boundedBy>
<gml:Envelope>
<gml:lowerCorner srsName="EPSG:4269">-70.57 42.52</gml:lowerCorner> <gml:upperCorner srsName="EPSG:4269">-70.57 42.52</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy> <msGeometry>
<gml:Point xmlns:gml="http://www.opengis.net/gml" srsName="EPSG:4269">
<gml:coordinates xmlns:gml="http://www.opengis.net/gml">-70.57,42.52</gml:coordinates>
</gml:Point>
</msGeometry> <air_pressure_at_sea_level>100590</air_pressure_at_sea_level> <longitude>-70.57</longitude> <latitude>42.52</latitude> <depth>0</depth> <time>2007-07-12 07:04:00-05</time>
</gml:layer_1>
</gml:featureMember>
</om:result>
</om:Observation>
</om:member>
</om:ObservationCollection>
comment:11 by , 17 years ago
comment:12 by , 17 years ago
I can confirm that commenting out "sos_offering_timeextent" does the trick. I get data when I should and don't when I shouldn't. But I would have expected "sos_offering_timeextent" "2006/2009" not to break anything since our obs is in Jul '07. Is the key to not use the "sos_offering_timeextent" at all?
As far as that awful observedproperty_id goes, Tom, I think it stinks, too. It's what the group is trying to shoot for, however -- mucho beyond my control.
comment:13 by , 17 years ago
So what does sos_offering_timeextent do, exactly? Or what should it do? I think it should:
- output an offering's time extent in GetCapabilities responses; if sos_offering_timeextent is not defined, then do not output an offering's time extent
- for a GetObservation request, when eventtime is passed, test for a valid extent before performing the query as an early out
The code looks like it does this. Is there a problem elsewhere, or with maptime.c?
comment:14 by , 17 years ago
I just did some deeper testing and this works as expected.
I think the confusing part here is that "2007" does not include all of 2007 (i.e. 01-01 to 31-12). Is this how ISO8601 defines how a YYYY value should be interpreted?
We've run into this issue before with time requests.
comment:15 by , 17 years ago
Were you able to pull obs w/ this set?
"sos_offering_timeextent" "2006/2009"
I couldn't (when I added the filter the URL).
comment:16 by , 17 years ago
With "2006/2009", I was not able to pull data with:
This is because, while the data is in 2007, the time extent test (i.e. comparing 2005/2007 to 2006/2009) comes back false, hence no data.
So the time validation is not checking for overlaps.
I'll start another ticket on time extent, as I think this is a general MapServer time processing issue.
comment:17 by , 17 years ago
On windows at leat I am able to get the data back for "2006/2009". Comparing should be something like this is 2007-07-11 >= 2006 and 2007-07-13 <= 2009. These 2 comaprison seems to work in my case. I will need to build Mapserver on Linux to check this but this might not be possible for me before next week.
test case. Untar in /tmp to maintain paths