search

MapServer / MapServer-import

3 stars 2 forks source link

[SOS-Server] eventTime not working #2154

Open tbonfort opened 12 years ago

tbonfort commented 12 years ago

Reporter: tomkralidis Date: 2007/07/12 - 16:24 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:TimePeriodgml:beginPosition1990-01-01/gml:beginPositiongml:endPosition1990-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 which isn't anywhere near the !TimePeriods defined in the query URL.

tbonfort commented 12 years ago

Author: cplist Date: 2007/07/18 - 21:27 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.

tbonfort commented 12 years ago

Author: assefa Date: 2007/07/18 - 21:57 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.

tbonfort commented 12 years ago

Author: assefa Date: 2007/07/31 - 21:07 Commited fix in fd42ee6caff24365362e17f72c0e290a3bc0e79f (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.

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/02 - 13:34 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:TimePeriodgml:beginPosition1988-01-01/gml:beginPositiongml:endPosition1989-02-01/gml:endPosition/gml:TimePeriod

Charlton: let us know if you still have problems.

tbonfort commented 12 years ago

Author: cplist Date: 2007/08/02 - 15:10 Thanks, guys. Will test and report back ASAP.

tbonfort commented 12 years ago

Author: cplist Date: 2007/08/02 - 15:30 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:TimePeriodgml:beginPosition2007-07-11/gml:beginPositiongml:endPosition2007-07-13/gml:endPosition/gml:TimePeriod

I'm still using the original .csv from the example, and its lone time is .

I can see it just fine w/o passing any eventTime. I am using the nightly snapshot tarball.

tbonfort commented 12 years ago

Author: assefa Date: 2007/08/02 - 15:40 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:TimePeriodgml:beginPosition2007-07-11/gml:beginPositiongml:endPosition2007-07-13/gml:endPosition/gml:TimePeriod

Note that I have commented out the "sos_offering_timeextent" on the layer

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/02 - 15:49 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.

tbonfort commented 12 years ago

Author: assefa Date: 2007/08/02 - 15:57 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:eventTime gml:TimePeriod gml:beginPosition2006/gml:beginPosition gml:endPosition2008/gml:endPosition /gml:TimePeriod /om:eventTime om:member om:Observation http://marinemetadata.org/cf#air_pressure_at_sea_level om:result gml:layer_1 gml:boundedBy ``` -70.57 42.52 -70.57 42.52 -70.57,42.52 100590 -70.57 42.52 0 ``` /om:member /om:ObservationCollection
tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/02 - 16:01 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

tbonfort commented 12 years ago

Author: cplist Date: 2007/08/02 - 16:03 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.

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/02 - 16:14 So what does sos_offering_timeextent do, exactly? Or what should it do? I think it should:

The code looks like it does this. Is there a problem elsewhere, or with maptime.c?

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/02 - 16:34 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.

tbonfort commented 12 years ago

Author: cplist Date: 2007/08/02 - 17:15 Were you able to pull obs w/ this set?

"sos_offering_timeextent" "2006/2009"

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

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/02 - 17:19

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.

tbonfort commented 12 years ago

Author: assefa Date: 2007/08/02 - 17:26 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.