Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#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)

sos_tst.tar (10.0 KB ) - added by tomkralidis 17 years ago.
test case. Untar in /tmp to maintain paths

Download all attachments as: .zip

Change History (18)

by tomkralidis, 17 years ago

Attachment: sos_tst.tar added

test case. Untar in /tmp to maintain paths

comment:1 by jmckenna, 17 years ago

Cc: jmckenna added

comment:2 by cplist, 17 years ago

Cc: cplist added; cplist@… 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 assefa, 17 years ago

Owner: changed from mapserverbugs to assefa
Status: newassigned

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 assefa, 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 tomkralidis, 17 years ago

Resolution: fixed
Status: assignedclosed

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:6 by cplist, 17 years ago

Thanks, guys. Will test and report back ASAP.

comment:7 by cplist, 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 assefa, 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 tomkralidis, 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 assefa, 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:12 by cplist, 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 tomkralidis, 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 tomkralidis, 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 cplist, 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 tomkralidis, 17 years ago

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.

comment:17 by assefa, 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.

Note: See TracTickets for help on using tickets.