[SOS-Server] eventTime not working

[tomkralidis]

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.

[tomkralidis]

test case. Untar in /tmp to maintain paths

[cplist]

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.

[assefa]

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.

[assefa]

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.

[tomkralidis]

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.

[cplist]

Thanks, guys. Will test and report back ASAP.

[cplist]

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.

[assefa]

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

[tomkralidis]

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.

[assefa]

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>

[tomkralidis]

Something must be wrong on my end:

 http://devgeo.cciw.ca/cgi-bin/mapserv/mapserv?map=/tmp/sos/madis_tst.map&service=SOS&version=0.1.2&request=GetObservation&offering=ndbc_44029&observedproperty=http://marinemetadata.org/cf%23air_pressure_at_sea_level&eventtime=%3Cgml:TimePeriod%3E%3Cgml:beginPosition%3E2005-01-01%3C/gml:beginPosition%3E%3Cgml:endPosition%3E2007-08-01%3C/gml:endPosition%3E%3C/gml:TimePeriod%3E&responseFormat=text/xml;%20subtype=om/0.14.7

[cplist]

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.

[tomkralidis]

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?

[tomkralidis]

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.

[cplist]

Were you able to pull obs w/ this set?

"sos_offering_timeextent" "2006/2009"

I couldn't (when I added the filter the URL).

[tomkralidis]

With "2006/2009", I was not able to pull data with:

 http://devgeo.cciw.ca/cgi-bin/mapserv/mapserv?map=/tmp/sos/madis_tst.map&service=SOS&version=0.1.2&request=GetObservation&offering=ndbc_44029&observedproperty=http://marinemetadata.org/cf%23air_pressure_at_sea_level&eventtime=%3Cgml:TimePeriod%3E%3Cgml:beginPosition%3E2005-01-01%3C/gml:beginPosition%3E%3Cgml:endPosition%3E2007-08-01%3C/gml:endPosition%3E%3C/gml:TimePeriod%3E&responseFormat=text/xml;%20subtype=om/0.14.7

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.

[assefa]

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.