<!--
Example in response to the mail from Carl Reed, August 11th 2009 to SWE.WG@lists.opengeospatial.org
Any comments or thoughts? The GeoPRIV community is discussing filters on measurements taken for moving objects. Sounds like something we can provide guidance on. Definitely an alerting application
>A fundamental thing that you would like to be able to control
>about location is how fast you get updates. If an entity has
>a variable rate of speed, and you set a motion filter, you
>also need to limit the rate. So "send me a notification when
>the target moves by 30 meters, but don't send more than one
>update per 10 seconds". So, there is an implied interaction
>between the movement filter and the rate filter.
Thanks!
Carl Reed, PhD
CTO and Executive Director Specification Program
OGC
-->
<!--
Imagine the incoming events have an attribute stating the distance traveled.
First use two simple patterns to connect to the input stream.
Then use complex pattern to check the distance traveled between two events and resuce output to one event per 10 seconds.
-->
<eml:EML xsi:schemaLocation="http://www.opengis.net/eml/0.0 C:/Arbeit/SCHEMAS_OPENGIS_NET/eml/0.0.1/emlPatterns.xsd" xmlns:eml="http://www.opengis.net/eml/0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:swe="http://www.opengis.net/swe/1.0.1" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc">
<eml:SimplePatterns>
<eml:SimplePattern inputName="input" patternID="simple1">
<!-- select the whole event for further computing -->
<eml:SelectFunctions>
<eml:SelectFunction newEventName="inputEvent1">
<eml:SelectEvent eventName="input"/>
</eml:SelectFunction>
</eml:SelectFunctions>
<eml:View>
<eml:LengthView>
<eml:EventCount>1</eml:EventCount>
</eml:LengthView>
</eml:View>
<eml:PropertyRestrictions/>
</eml:SimplePattern>
<eml:SimplePattern inputName="input" patternID="simple2">
<!-- select the whole event for further computing -->
<eml:SelectFunctions>
<eml:SelectFunction newEventName="inputEvent2">
<eml:SelectEvent eventName="input"/>
</eml:SelectFunction>
</eml:SelectFunctions>
<eml:View>
<eml:LengthView>
<eml:EventCount>1</eml:EventCount>
</eml:LengthView>
</eml:View>
<eml:PropertyRestrictions/>
</eml:SimplePattern>
</eml:SimplePatterns>
<eml:ComplexPatterns>
<eml:ComplexPattern patternID="complex1">
<eml:SelectFunctions>
<!-- select the result event -->
<eml:SelectFunction newEventName="result" outputName="output">
<eml:SelectEvent eventName="inputEvent2"/>
</eml:SelectFunction>
</eml:SelectFunctions>
<eml:View>
<!-- this view activates the select function every 10 seconds-->
<eml:TimeView isBatch="true">
<eml:Duration>PT0H0M10S</eml:Duration>
</eml:TimeView>
</eml:View>
<eml:Guard>
<!-- check if (event1.distance + 30m) > event2.distance -->
<ogc:Filter>
<ogc:PropertyIsGreaterThanOrEqualTo>
<ogc:Add>
<ogc:PropertyName>inputEvent1</ogc:PropertyName>
<ogc:Literal>
<swe:Quantity>
<swe:uom code="m"/> <!-- UCUM code for meter -->
<swe:value>30</swe:value>
</swe:Quantity>
</ogc:Literal>
</ogc:Add>
<ogc:PropertyName>inputEvent2</ogc:PropertyName>
</ogc:PropertyIsGreaterThanOrEqualTo>
</ogc:Filter>
</eml:Guard>
<!-- only accept pairs where the first event was received before the second -->
<eml:StructuralOperator>
<eml:BEFORE/>
</eml:StructuralOperator>
<!--work on output of pattern simple1-->
<eml:FirstPattern>
<eml:PatternReference>simple1</eml:PatternReference>
<eml:SelectFunctionNumber>0</eml:SelectFunctionNumber>
</eml:FirstPattern>
<eml:SecondPattern>
<eml:PatternReference>simple2</eml:PatternReference>
<eml:SelectFunctionNumber>0</eml:SelectFunctionNumber>
</eml:SecondPattern>
</eml:ComplexPattern>
</eml:ComplexPatterns>
<eml:TimerPatterns/>
<eml:RepetitivePatterns/>
</eml:EML>
The OGC Members (especially in Europe) have been developing and testing a
candidate OGC standard titled "Event Pattern Markup Language (EML - OGC
08-132). The Event Pattern Markup Language (EML) allows one to describe
event patterns for event (stream) processing and analysis. It can be used to
build multi stage filters for incoming events but also to derive higher
information through combining and correlating multiple events. It can be
applied on single events but is focused on handling of continuous event
streams. http://portal.opengeospatial.org/files/?artifact_id=29566
This work is being driven by numerous projects in Europe related to INSPIRE,
SANY, and ORCHESTRA, pan-European projects that deal with spatial data
infrastructures integrated with sensor networks (such as landslide
monitoring) and risk management/emergency services.
Attached is an example of a EML encoding related to the GeoPriv loc filter
discussions.
Perhaps not as "simple" and "concise" as this group is envisioning but this
is also not necessarily a simple problem when considering a more general
solution.
Hope this helps
Carl
----- Original Message -----
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext Carl Reed" <creed@opengeospatial.org>
Sent: Wednesday, August 12, 2009 1:20 AM
Subject: RE: [Geopriv] Clarification regarding Loc-Filters
> Thanks, Carl.
>
> I am interested to hear what their thinking is
>
>>-----Original Message-----
>>From: ext Carl Reed [mailto:creed@opengeospatial.org]
>>Sent: 11 August, 2009 18:33
>>To: Hannes Tschofenig; 'Brian Rosen'; Tschofenig, Hannes (NSN
>>- FI/Espoo); geopriv@ietf.org
>>Subject: Re: [Geopriv] Clarification regarding Loc-Filters
>>
>>All -
>>
>>I have forwarded this discussion thread to OGC members who 1.)
>>deal with location services applications and 2.) deal with
>>alerting applications driven by sensor networks.
>>
>>Cheers
>>
>>Carl
>>
>>----- Original Message -----
>>From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
>>To: "'Brian Rosen'" <br@brianrosen.net>; "Tschofenig, Hannes
>>(NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>; <geopriv@ietf.org>
>>Sent: Monday, August 10, 2009 9:48 AM
>>Subject: [Geopriv] Clarification regarding Loc-Filters
>>
>>
>>> The following statement from Brian explains the disconnect between
>>> Martin/Brian and myself:
>>>
>>>>A fundamental thing that you would like to be able to control about
>>>>location is how fast you get updates. If an entity has a variable
>>>>rate of speed, and you set a motion filter, you also need to
>>limit the
>>>>rate. So "send me a notification when the target moves by
>>30 meters,
>>>>but don't send more than one update per 10 seconds". So,
>>there is an
>>>>implied interaction between the movement filter and the rate filter.
>>>
>>> We clearly had different requirements in mind. For me the
>>requirement
>>> was just to provide the "send me a notification when the
>>target moves
>>> by 30 meters" functionality.
>>>
>>> I let someone else decide about this aspect (but at least I now
>>> understand the intention)[*].
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: [*] It is unfortunate that I wasn't at the IETF meeting
>>because I
>>> would have very likely recognized the disconnect between
>>> Brian/Martin's view and mine much earlier.
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>>
>
