ࡱ > ` g / bjbjVV r< r< # ' ' ^4 t4 5 5 5 $ 5 5 5 P H6 8 5 ? V : 4 @ A A A J ~ R $ 3T $ G 5 GU QJ @ J GU GU 4 4 A A c h h h GU 4 A 5 A h GU h h . \ v5 ^ A [: [ h | v 0 ? ? w] X ? \ ? 5 GU GU h GU GU GU GU GU c GU GU GU ? GU GU GU GU ? GU GU GU GU GU GU GU GU GU ' $3 : Open Geospatial Consortium Inc.
Date:2012-03-01
Reference number of this OGC project document: SUBJECT \* MERGEFORMAT OGC 12-027
Version: 0.1
Category: OGC Discussion Paper
Editor: AUTHOR "Timo Thomas" \* MERGEFORMAT Timo Thomas
WFS Temporality Extension
COMMENTS \* MERGEFORMAT Copyright 2012 Open Geospatial Consortium, Inc. All Rights Reserved.To obtain additional rights of use, visit HYPERLINK "http://www.opengeospatial.org/legal/" http://www.opengeospatial.org/legal/.
Warning
This document is not an OGC Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard.
Document type: OGC Discussion Paper
Document subtype: NA
Document stage: Draft
Document language: English
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Contents
TDC \o "1-3" \f \t "ANNEX,1,Introduction,9,zzBiblio,9,zzForeword,9,zzIndex,9,OGC Clause,1" 1 Scope PAGEREF _Toc318323732 \h 1
2 References PAGEREF _Toc318323733 \h 1
3 Conventions and Abbreviated Terms PAGEREF _Toc318323734 \h 2
4 AIXM 5 Temporality Model PAGEREF _Toc318323735 \h 2
4.1 Time Slice Interpretation PAGEREF _Toc318323736 \h 3
4.2 Sequences, Corrections and Cancellations PAGEREF _Toc318323737 \h 3
4.3 Differences to the GML Dynamic Feature Model PAGEREF _Toc318323738 \h 4
4.4 Conclusion PAGEREF _Toc318323739 \h 6
5 Use Cases for a WFS Service Serving AIXM 5 Data PAGEREF _Toc318323740 \h 6
5.1 Data Retrieval PAGEREF _Toc318323741 \h 6
5.2 Data Storage PAGEREF _Toc318323742 \h 7
6 Limitations of the WFS/FE 2.0 standards when applied to AIXM data PAGEREF _Toc318323743 \h 8
6.1 GetFeature PAGEREF _Toc318323744 \h 9
6.1.1 Ad Hoc Queries PAGEREF _Toc318323745 \h 9
6.1.2 Stored Queries PAGEREF _Toc318323746 \h 9
6.2 GetPropertyValue PAGEREF _Toc318323747 \h 10
6.3 Summary PAGEREF _Toc318323748 \h 11
7 Temporal Query PAGEREF _Toc318323749 \h 11
7.1 Filter Active Time Slices PAGEREF _Toc318323750 \h 12
7.2 Filter Outdated Time Slices PAGEREF _Toc318323751 \h 13
7.3 Extracting the Relevant Set PAGEREF _Toc318323752 \h 13
7.4 Creating Snapshots PAGEREF _Toc318323753 \h 14
7.5 Properties with Schedules PAGEREF _Toc318323754 \h 15
7.5.1 Evaluation for Filtering PAGEREF _Toc318323755 \h 15
7.5.2 Evaluation for Query Result Output PAGEREF _Toc318323756 \h 16
8 Compatibility with GML 3.2 Dynamic Feature Model PAGEREF _Toc318323757 \h 17
8.1 Time Slice Filter PAGEREF _Toc318323758 \h 17
8.2 Snapshot Generation PAGEREF _Toc318323759 \h 17
8.3 Incompatibilities PAGEREF _Toc318323760 \h 17
9 Compatibility with Existing WFS 2.0 Based Systems PAGEREF _Toc318323761 \h 18
10 Alternative Approaches PAGEREF _Toc318323762 \h 18
10.1 Introduction of Extended Projection Clauses PAGEREF _Toc318323763 \h 18
10.2 Web Processing Services PAGEREF _Toc318323764 \h 19
10.3 XQuery PAGEREF _Toc318323765 \h 20
11 Future Work PAGEREF _Toc318323766 \h 20
11.1 Formal Work PAGEREF _Toc318323767 \h 20
11.2 Exclusion of Properties PAGEREF _Toc318323768 \h 21
Preface
This discussion paper provides a proposal for a temporality extension for the WFS 2.0 standard. It is based on the work of and experiences made in several OWS test beds, in particular OWS-7 and OWS-8, Aviation threads and discussions at the 2011 OGC TC meeting in Brussels, Belgium. It partially replaces and advances the document HYPERLINK "https://portal.opengeospatial.org/files/?artifact_id=46616&version=1" OWS-8 Aviation: Guidance for Retrieving AIXM 5.1 data via an OGC WFS 2.0 [4].
Submission contact points
All questions regarding this submission should be directed to the editor or the submitters:
CONTACTCOMPANYTimo ThomasCOMSOFT GmbHRevision history
DateReleaseAuthorParagraph modifiedDescription2012-03-010.1Timo ThomasallInitial draft for general review
Introduction
The Aeronautical Information Exchange Model (AIXM) is designed to enable the management and distribution of Aeronautical Information Services (AIS) data in digital format. The newest version of this model, AIXM 5, is based on GML 3.2 and features an exhaustive temporality model loosely based on the GML Dynamic Feature Model.
Various interoperability test-beds at OGC, in particular OWS-7 and OWS-8, have applied OGCs WFS 2.0 standard on AIXM 5 data. Though it could be demonstrated that a basic interoperability is possible, it turned out that some key requirements couldnt be fulfilled. This paper summarises the observations made and shows that these requirements are not specific to AIXM 5, but more generally apply to any data model featuring temporality. To overcome these shortcomings, a proposal is made for an extended type of WFS query: a temporal query.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights. However, to date, no such rights have been claimed or identified.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
Scope
This document reflects the current state of the discussion about the application of the WFS standard to serve AIXM 5 data.
References
The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
[1] ISO/DIS 19142 and OGC 04-094, OpenGIS Web Feature Service 2.0 Interface Standard (2010-11-02)
[2] ISO/DIS 19143 and OGC 09-026r1, OpenGIS Filter Encoding 2.0 Encoding Standard (2010-11-22)
[3] OGC OGC 11-093r1, OGC OWS-8 Aviation Architecture ER (2011-09-30)
[4] OGC 11-073r2, OGC OWS-8 Aviation: Guidance for Retrieving AIXM 5.1 data via an OGC WFS 2.0 (2011-11-04)
[5] OGC 10-131r1, OGC OWS-7 Aviation AIXM Assessment Report (2010-08-18)
[6] OGC 05-007r7, OpenGIS Web Processing Service (2007-06-08)
[7] XQuery 1.0: An XML Query Language (Second Edition), W3C Recommendation 14 December 2010, at HYPERLINK "http://www.w3.org/TR/2010/REC-xquery-20101214/" http://www.w3.org/TR/2010/REC-xquery-20101214/
[8] OGC 11-171, Requirements for Aviation Metadata - OGC Best Practice (2011-11-10)
[9] OGC 11-172, Guidance on the Aviation Metadata Profile (2011-11-10)
[10] AIXM 5 Temporality Model 1.0 (2010-09-15)
Conventions and Abbreviated Terms
AIP Aeronautical Information Publication
AIRAC Aeronautical Information Regulation And Control
AIXM Aeronautical Information Exchange Model
API Application Program Interface
ER Engineering Report
FE Filter Encoding Specification
GML Geography Markup Language
HTTP Hypertext Transfer Protocol
ISO International Organization for Standardization
NOTAM Notice To Airmen
OGC Open Geospatial Consortium
UML Unified Modeling Language
URL Uniform Resource Locator
W3C World Wide Web Consortium
WFS Web Feature Service
WPS Web Processing Service
XML eXtended Markup Language
XPath XML Path Language
AIXM 5 Temporality Model
AIXM 5 is based on GML 3.2. All features inherit from the type gml:DynamicFeature which is the base class of the GML Dynamic Feature Model (DFM). The properties of a feature are all time-variant and encoded in time slices. The only exceptions to this are global identifiers, names, metadata and a bounding box. However, the term time slice as defined in GML 3.2 has different meaning in AIXM 5. In GML, it denotes a temporary state at property level, whereas in AIXM 5 it denotes a temporary state at feature level. A detailed comparison of the two models is given in REF _Ref315442668 \r \h 4.3.
In the following a brief introduction is given to the AIXM Temporality Model and to what makes it special compared to the Dynamic Feature Model in GML 3.2.
Time Slice Interpretation
AIXM 5 distinguishes four types of time slices: BASELINEs, PERMDELTAs, TEMPDELTAs and SNAPSHOTs. The time slice type is encoded in a property called interpretation. So from now on, the term time slice interpretation maybe used as a synonym to time slice type in this document. The function of the time slice types are described in REF _Ref314577974 \h Table 1. BASELINEs and SNAPSHOTs are the direct result of PERMDELTAs and TEMPDELTAs, which means that they are only a different representation of the information carried in the delta time slices. Their generation is the result of a merging process in which overlapping deltas are ordered according to their sequence number (which is a property of all AIXM 5 time slices) to define a unique and unambiguous result.
Table SEQ Table \* ARABIC 1 Time Slice Types in AIXM 5
Time Slice Type / InterpretationFunctionPERMDELTAContains all properties that change permanently; valid at a time instant. Example: a change in the length of a runway due to construction works.BASELINECurrent state of the feature as the result of permanent changes; valid for a time period (= the sum of all PERMDELTAs relevant for the time period)TEMPDELTAContains all properties that change temporarily; valid for a time period. Example: a closure of a runway due to icing.SNAPSHOTCurrent state of the feature as the result of all permanent and temporary changes; valid for a time instant A. (= the sum of all PERMDELTAs and TEMPDELTAs relevant for the time instant)A The concept of snapshots is extended to time periods later in this document
SNAPSHOT time slices cannot be stored in a WFS and a WFS cant retrieve them from a persistent storage. This is because in theory, an unlimited number of SNAPSHOT time slices exist as theyre valid for a single point in time.
Sequences, Corrections and Cancellations
An AIXM 5 feature never forgets its history, which includes expected events on the state of a feature to happen in the future, that were known at some point in the past. This implies that a time slice is never deleted or updated. Every change is communicated through the insertion of new time slices, for which overwrite rules apply. For this purpose AIXM 5 introduced the concepts of sequences, corrections and cancellations. Every time slice of a feature has a unique identifier (key) which consists of the following properties:
the interpretation (time slice type),
the sequence number and
the correction number
For every sequence (i.e. the set of time slices that share a sequence number), theres always only one active time slice: its the one with the highest correction number. All time slices with a lower correction number (in a sequence) are considered to be out-dated. If the active time slice is a cancellation, which is indicated by a specific value of the validTime property, the sequence is considered to be cancelled. This functionality makes possible to communicate both updates and deletions without loosing the history.
Differences to the GML Dynamic Feature Model
AIXM 5 is only loosely based on the GML Dynamic Feature Model. Important differences exist both
on a conceptual level (see REF _Ref315441990 \h \* MERGEFORMAT Table 2) as well as
in the structure of the features (see REF _Ref315442540 \h Figure 1).
Table SEQ Table \* ARABIC 2 Differences between AIXM and GML temporality models, conceptual level
ConceptAIXMGML 3.2Temporality ModelTemporary changes at feature level only, called time slices. Very few non-time-invariant properties: identifier, metadata, bounding box, name(s)Temporary changes at feature level = snapshots, temporary changes at property level = time sliceBase typesgml:DynamicFeatureType, but restricts the inheritance to only a few elements. gml:validTime and gml:history are not among them(gml:DynamicFeatureType)Types of temporary changesTime slice types: SNAPSHOT (current state), PERMDELTA (permanent change), TEMPDELTA (temporary change), BASELINE (current permanent state, excluding temporary changes)Snapshots (current state) and history (list of changes in time-variant properties)CorrectionsSupported through sequence and correction numbers No such conceptCancellationsSupported through special interpretation of validTimeNo such concept
EMBED Excel.Sheet.12
Figure SEQ Figure \* ARABIC 1 Comparison of the XML structure in the AIXM 5 Temporality Model and the GML Dynamic Feature Model
REF _Ref315442540 \h Figure 1 explained: each item below Feature represents an XML element (including the Feature element itself). Because XML can be quite verbose, tags, attributes and namespaces are completely left out as they are of little value in this comparison. Elements in type-writer notation denote real existing elements, whereas elements in italic letters denote elements of a certain type or class. Feature properties fall into two classes: time-variant properties (PropertyT) and time-invariant properties (Property). The latter only exist in the GML Dynamic Feature Model.
Conclusion
Despite the AIXM temporality model is based on the dynamic feature model of GML through the common base type gml:DynamicFeature, in practice theres little in common. Central elements of the GML dynamic feature model are not used (gml:validTime and gml:history) and some important new concepts are introduced: the distinction between temporary and permanent changes, corrections and cancellations. However, both models share the approach of modelling time-variant data by the introduction of time slices, which associate properties with a validity time.
Use Cases for a WFS Service Serving AIXM 5 Data
Data Retrieval
The use-cases for the retrieval of AIXM 5 data are manifold and come from different areas of applications. REF _Ref315341619 \h Table 3 categorises them, gives examples and derives the technical requirements of a query processor.
Table SEQ Table \* ARABIC 3 Use cases for AIXM 5 data retrieval
Use CaseCategoryExampleTechnical requirementsRetrieve the complete state of a feature at a point in timeVisualisation, decision supportRetrieve the state of a runway at the time of arrival.Filtering of features and generation of SNAPSHOT time slices.Retrieve all features fulfilling a certain criteria at a point in timeDecision supportRetrieve all runways at the time of arrival that are open, at least x m long, have a concrete surface etc.Filtering of features and generation and filtering of SNAPSHOT time slices.Retrieve all time slices of a feature relevant for (i.e. affecting the state at) a point in timeChange-aware visualisationRetrieve all time slices relevant for the time of arrival of a runway. (This enables the client to process any TEMPDELTAs (e.g. digital NOTAMs) received at a later point in time)Filtering of features and applying the SNAPSHOT generation algorithm to determine the relevant time slices.Retrieve the BASELINE of a feature valid at a point in timeAIP publicationRetrieve the BASELINE of an airport at an AIRAC effective date.Filtering of features and filtering the contained time slices, ignoring corrected and cancelled time slices.Retrieve all TEMPDELTAs of a feature fully or partly valid for a time period and matching a certain criteriaNOTAM communicationRetrieve all TEMPDELTAs affecting the operational status of a navigation aid until the time of arrival.Filtering of features and filtering the contained time slices, ignoring corrected and cancelled time slices.Retrieve all PERMDELTAs of a feature valid for a time periodReplicationRetrieve all PERMDELTAs of a feature valid now or in the future.Filtering of features and filtering the contained time slices, ignoring corrected and cancelled time slices.Retrieve specific time slices of a feature by their unique idReplication, technical verificationRetrieve the PERMDELTA time slice of feature X, sequence number Y, correction number Z.Filtering of features and filtering the contained time slices.Retrieve the full history of a featureBackupRetrieve all time slices of a feature (BASELINEs, PERMDELTAs and TEMPDELTAs) valid at any point in time.Filtering of features.
Four technical requirements of a WFS query operation on AIXM 5 data follow from this analysis:
The ability to filter features and time slices.
A filter expression to easily identify corrected and cancelled time slices.
A filter expression to easily identify the time slices that are relevant for a point in time.
The ability to generate SNAPSHOT time slices and to filter them.
These requirements will form the basis of the temporal query introduced in chapter REF _Ref314743430 \r \h 7.
Data Storage
Because the AIXM 5 temporality model does not allow the permanent deletion of information, there are only two use cases:
insert a feature
insert a time slice into a feature
This is already possible with the existing Transaction operation. If a feature is inserted, the Insert action has to be used. If a time slice is to be inserted, the Update action is necessary, because technically, the feature is changed (updated) by adding a new time slice to its list of properties.
EXAMPLE Insertion of a time slice into a feature of type T, with a gml:identifier I. Please note that the order of the time slices is irrelevant in AIXM. aixm:timeSlice[1] ... gml:identifier I
Limitations of the WFS/FE 2.0 standards when applied to AIXM data
In this chapter well show that there is only little support for the identified requirements in the WFS 2.0 standard.
The WFS 2.0 interface provides two operations for retrieving data:
GetFeature: returns a response containing a selection of zero or more features corresponding to the criteria defined in the request
GetPropertyValue: returns a response containing zero or more of the selected feature property values corresponding to query criteria defined in the request
Theres also a GetFeatureWithLock operation, but this does not extend the power of the query language compared to GetFeature and is therefore ignored in the following. Both the GetFeature and GetPropertyValue operations support two types of query:
wfs:Query: these are ad hoc queries generated by a client to retrieve specified feature types or property values
wfs:StoredQuery: this is a pre-defined parameterized query that has been stored on the server for re-use by clients
In the following it is shown that neither of them fully supports the requirements identified in the previous section.
GetFeature
The GetFeature operation request is used to retrieve features using one or more ad hoc queries (wfs:Query) or stored queries (wfs:StoredQuery).
Ad Hoc Queries
The wfs:Query element consists of two parts: a projection part and a filter definition.
The filter definition is a FE 2.0 filter expression and selects the features matching given criteria. An additional selection criterion is given by the typeNames attribute on the wfs:Query element: it is used to restrict the types of features to be returned.
The projection part is optional and may contain one or more projection clauses. In WFS 2.0, theres only one projection clause available: wfs:PropertyName. By default, non-mandatory properties of a feature are not returned in the response document unless theyre referenced by a wfs:PropertyName element in the request. In WFS, the properties of a feature are made up of all first-level child elements of the feature. For AIXM 5 data these are the gml:identifier, gml:name, gml:description, gml:boundedBy, gml:featureMetadata and aixm:timeslice elements. Except for the list of aixm:timeslice elements, all of these are non-mandatory. Thus, the PropertyName clause enables the client to include gml:identifier, gml:name, gml:description, gml:boundedBy, gml:featureMetadata in the response which are excluded otherwise.
Please note that the GetFeature operation does not provide any means to request a modified property or a modified list or properties according to criteria. Hence, there is support neither for the generation of SNAPHOTs nor the filtering of time slices. Only the use case Retrieve the full history of a feature is supported.
Stored Queries
From the specification:
A stored query expression is a persistent, parameterized, identifiable query expression. A stored query can be repeatedly invoked using its identifier with different values bound to its parameters each time.
Stored queries can use any language to implement their behaviour. The given parameters can be of any type. Hence, stored queries naturally have the power to support all AIXM 5 use cases. REF _Ref314733843 \h Table 4 shows that 3 different queries would be required. That said, what are the reasons that this paper does not simply define stored queries but instead promotes the introduction of a new query type? They are here:
Defining stored queries is not very different from introducing a new query type: generic WFS 2.0 clients cant support any of them because they cant know about the semantics of the query parameters or elements.
The textual representation of a stored query cant be as compact as a new query element because all parameters have to be surrounded by a Parameter element.
The intended use of stored queries is it to parameterise complex queries to improve readability, speed up server processing (by query pre-compilation on server side) and reduce the amount of text in the request document. Typical parameters are concrete values or objects like numerical values in a certain unit of measurement, a spatial object for comparison, etc. Here, the parameters include complex filters, which are used to define the query itself, and because of which the query cant be pre-compiled.
Table SEQ Table \* ARABIC 4 Required Query Functionality
DescriptionParametersReturn ValueQuery SNAPSHOTsa list of feature types
a feature level filter (optional)
a time instant or time period
a time slice level filter (optional)Collection of features containing generated (and optionally filtered) snapshot time slicesQuery relevant time slicesa list of feature types
a feature level filter (optional)
a time instant
a time slice level filter (optional)Collection of features containing a subset of time slicesQuery time slicesa list of feature types
a feature level filter (optional)
a time slice level filter (optional)
a marker (flag) whether to ignore corrected time slices of not
a marker (flag) whether to ignore cancelled time slices of notCollection of features containing all or a subset of time slices
GetPropertyValue
From the specification:
The GetPropertyValue operation allows the value of a feature property or part of the value of a complex feature property to be retrieved from the data store for a set of features identified using a query expression.
In other words, GetPropertyValue is combination of a GetFeature request with an XPath expression. A given filter is used to select features by criteria (this is the regular GetFeature operation), and in a subsequent process the XPath expression is used to extract XML elements out of the result.
One of the requirements is to generate and filter SNAPSHOT time slices. This requirement cant be met by the GetPropertyValue operation, because the XPath expression is only capable of extracting existing elements (for the discussion to use stored queries for this, see above). Another central requirement is the capability to filter the list of time slice properties contained in the feature. This is possible with GetPropertyValue. However, significant disadvantages are observed:
The filter criteria for time slices is likely to be quite complex. Spatial and temporal criteria are required for almost every common use case. The existing FE operators cant be used for this purpose, because theyre not available as XPath functions. Further on, custom XPath functions have to be introduced to make the exclusion of corrected and cancelled time slices possible.
The XPath expression has to be encoded in a single string. This string cant be validated through an XML schema. The expression will be very hard to read for humans, especially if complex spatio-temporal functions are involved.
the result of a GetPropertyValue operation is a collection of XML elements. In this case, these are timeslice elements. A timeslice element does not contain a reference to its parent feature, which means that if multiple features are targeted by the query, the result is ambiguous.
Summary
The previous section showed that only stored queries (in conjunction with GetFeature) meet all requirements for querying AIXM 5 data. In chapter REF _Ref314743440 \r \h 7 we will introduce a more efficient alternative to stored queries.
Temporal Query
Following the requirements identified in REF _Ref314733843 \h Table 4 and in section REF _Ref315442969 \r \h 5.1, a new type of query is introduced here: a temporal query. As well see later on, a temporal query isnt limited to the AIXM 5 temporality model. It is a query honouring time-variant properties structured in time slices, which applies to any data based on the GML Dynamic Feature Model.
The temporal query shall be defined on par with ad hoc queries and stored queries. This can be achieved by putting it into the common substitution group for queries, which is defined in the XML Schema of the WFS standard. Consequently, a temporal query can be used in all query operations of a WFS: GetFeature, GetPropertyValue, GetFeatureWithLock, LockFeature, etc. The output of a temporal query is a regular collection of features. The contained time slices, however, may represent
a subset of the features time slices or
be generated in case of a query for the complete state of the feature for a given point in time (snapshot query)
To distinguish the introduced elements from existing XML elements in WFS/FE 2.0, namespace prefixes are used in the following sections, where
wfs-aixm is bound to the namespace of the new elements
wfs is bound to the WFS 2.0 namespace
fes is bound to the FE 2.0 namespace
In the following, rather than starting off the XML schema of the temporal query elements, a more pragmatic way of explanation was chosen. Each type of query is explained by example, in which the variable parts are marked.
Filter Active Time Slices
This type of query corresponds to requirement a) in REF _Ref315442969 \r \h 5.1.
ElementDescriptionwfs-aixm:TemporalQueryTop-level query element, substitutes wfs:Query or wfs:StoredQuery. The typeNames attribute contains a list of feature types and has same function as in wfs:Queryfes:FilterFE filter on feature level. Feature level properties are time-invariant. This filter is mainly used for identifying features by their globally unique id, which is encoded in gml:identifier. wfs-aixm:TimeSliceFilterFE filter on time slice level. Time slice level properties are time-variant. The available time slice types are: BASELINEA, PERMDELTA and TEMPDELTA. For queries on SNAPSHOT time slices, see REF _Ref315445853 \r \h 7.4. Only active time slices are considered, i.e. corrected and cancelled ones are omitted.ABASELINE time slices and PERMDELTA time slices are mutually dependent. It is open to the WFS implementation whether to store one or both of them. Here we assume that both a queryable.
Filter Outdated Time Slices
This type of query corresponds to requirement b) in REF _Ref315442969 \r \h 5.1.
ElementDescriptionwfs-aixm:TemporalQuerySee REF _Ref315447518 \r \h 7.1fes:FilterSee REF _Ref315447518 \r \h 7.1wfs-aixm:TimeSliceFilterSee REF _Ref315447518 \r \h 7.1, except here, inactive time slices may be included, depending on the attribute values of includeCorrected and includeCancelled. If true, corrected and cancelled ones are included, respectively.
Extracting the Relevant Set
This type of query corresponds to requirement c) in REF _Ref315442969 \r \h 5.1.
ElementDescriptionwfs-aixm:TemporalQuerySee REF _Ref315446732 \r \h 7.2fes:FilterSee REF _Ref315446732 \r \h 7.2wfs-aixm:TimeSliceFilterSee REF _Ref315447518 \r \h 7.1and REF _Ref315447490 \r \h 7.2. Setting includeCorrected or includeCancelled to true is technically possible but contradicts the idea of this query, see below.wfs-aixm:LimitToRelevantSetFilters out any time slices that are not relevant for the state of the feature at the given point in time. In other words, only those time slices are returned that would have an effect on a SNAPSHOT time slice generated for the given time instant.
evaluateDuring: if true, the fes:Filter is applied to the SNAPSHOT time slice at the given time instant. This is important for requesting the relevant set depending on a constraint on the state of the feature at a given point in time. This is done silently, i.e. the SNAPSHOT is only used for evaluating the constraint and not part of the response. If false, the filter is applied to the time slices in the relevant set. This is identical to a logical AND operation on the relevant set filter and the provided fes:Filter.
Examples of application:
evaluateDuring=true: Give me all relevant time slices for a time instant t of all airports that are open and intersecting buffer b
evaluateDuring=false: Give me all relevant time slices for a time instant t of airports X,Y,Z excluding TEMPDELTA time slices
Creating Snapshots
This type of query corresponds to requirement d) in REF _Ref315442969 \r \h 5.1.
ElementDescriptionwfs-aixm:TemporalQuerySee REF _Ref315446732 \r \h 7.2fes:FilterSee REF _Ref315446732 \r \h 7.2wfs-aixm:SnapshotFilterThe presence of this is element triggers the generation of SNAPSHOT time slices. The fes:Filter child element optionally defines further constraints on the SNAPSHOT time slice(s)A.wfs-aixm:SnapshotTimeIf the child element is a gml:TimeInstant, a single SNAPSHOT time slice is created with the according validTime.
If the child element is a gml:TimePeriod, a single SNAPSHOT time slice or a list of SNAPSHOT time slices is returned. If no property changes in the whole time period, a single time slice is returned with the according validTime (time period). If there are property changes, the server shall return a list of consecutive time slices with disjoint validTimes that span the given time periodB.A This equals an implicit application of the evaluateDuring function introduced in REF _Ref316394935 \r \h 7.3 and also discussed in [4].
B If the requested time period lies completely or partly outside the life time of the feature, the requested time period is adjusted accordingly. This may result in an empty result set.
Properties with Schedules
In AIXM 5, a special property type exists for modelling periodic events: PropertiesWithSchedules [10]. It introduces an additional temporality aspect to properties which is overlaid onto the underlying temporality model. Good examples for schedules are the opening times of an airport (e.g. daily 8-18h) and the regular activation of airspaces for military operations (e.g. weekly on Saturday 8-16h). Schedules consist of a list of consecutive time sheets, where each time sheet contains a validity period and set of values.
The temporal query elements introduced so far are not aware of properties with schedules. That means that properties with schedules are handled as any other property with a complex content. This implies two issues:
Its the clients responsibility to correctly apply FE filters to define constraints based on properties with schedules. This is not easy to achieve as time sheets are not based on GML time instants and periods. Hence, the temporal operators of FE 2.0 cant be used.
If the client wants to display the value of a property with schedule at a certain time, it has to evaluate time sheets after retrieval. This complicates the client implementation.
The enhancements presented in the following sections overcome these problems.
Evaluation for Filtering
In some scenarios such as decision support, properties with schedules must be evaluated at the given point in time to correctly apply a filter constraint. Existing FE 2.0 operators are of little help, because time sheets are not based on simple GML time instants and periods. Here we introduce a switch that instructs the server to evaluate the properties with schedules before the filter is applied.
Element/AttributeDescriptionwfs-aixm:TemporalQuerySee REF _Ref315446732 \r \h 7.2fes:FilterSee REF _Ref315446732 \r \h 7.2wfs-aixm:SnapshotFilterSee REF _Ref316312861 \r \h 7.5.1. evaluateSchedulesInstructs the server to evaluate all properties with schedules at the given time or time period and apply the fes:Filter inside the wfs-aixm:SnapshotFilter on the result. If a time period is given, multiple values may be valid, in which case the matchAction attribute in the fes:Filter operators apply.The evaluation is only done for the constraint matching, the output is unchanged (i.e. all time sheets are returned).
Evaluation for Query Result Output
In some scenarios such as visualisation, the client might only be interested in the value of a property (with schedule) at a certain time. Here, we introduce a switch that moves the time sheet evaluation from the client to the server. This helps reducing the complexity of the client and saves bandwidth. To preserve backward compatibility, the evaluation of schedules is optional and only done on request.
Element/AttributeDescriptionwfs-aixm:TemporalQuerySee REF _Ref315446732 \r \h 7.2fes:FilterSee REF _Ref315446732 \r \h 7.2wfs-aixm:SnapshotFilterSee REF _Ref316312861 \r \h 7.5.1. outputEvaluatedSchedulesInstructs the server to replace the list of time sheets of each property with schedule by a single time sheet without a timeInterval element. The values of the properties are valid at the time instant given in the SnapshotTime element.Please note: combining evaluateSchedules=false with outputEvaluatedSchedules=true is possible but of very little use in real-world use cases.
Please see annex A for an example of this query.
Compatibility with GML 3.2 Dynamic Feature Model
The Temporal Query introduced in chapter REF _Ref314743430 \r \h 7 is tailored to the requirements of AIXM 5 data. However, essential parts of it are also applicable to an application schema more tightly based on the GML Dynamic Feature Model (DFM for short). This chapter briefly examines what parts are compatible.
Time Slice Filter
Time slice filtering is useful for both models, because it hides the separation between time-variant and time-invariant properties from the client. It also reduces the amount of data to be processed and communicated, because WFS 2.0s support for filtering the properties of features is limited (see REF _Ref316049290 \r \h 6).
EXAMPLE Given a WFS storing the position of cars. Time-invariant properties could be model, colour, etc. whereas the property encoding the location is dynamic. A client requesting for instance All cars that are red and located in Berlin at 2012/2/3 12:00 requires the filtering of time slices to carry out that sort of query.
Snapshot Generation
Snapshots represent the state of a feature, i.e. the value of all properties, at a certain point in time. This concept is also applicable to a pure GML DFM based application schema. Thus, the presence of a query for the retrieval of snapshots saves the client from parsing and merging a (potentially) long list of time slice history.
Incompatibilities
The filters for cancelled and corrected time slices and the concept of properties with schedules are specific to AIXM 5. The concept of the relevant set of time slices is bound to the presence of some sort of base line time slices, which are likely not to be present outside the AIXM 5 world.
However, the proposed extension to the WFS/FE XML schema could be separated into two parts: one to accommodate common temporality-specific elements, and one for AIXM-5-specific functionality.
Compatibility with Existing WFS 2.0 Based Systems
The proposed extension is established as a new XML schema which inherits from the existing WFS 2.0 XML Schema. Thus, the existing WFS 2.0 standard is preserved and a WFS 2.0 supporting the Temporal Query is fully backwards compatible.
To enable existing, non-temporality aware WFS 2.0 clients to query AIXM 5 data in a basic way, a proxy WFS could be installed which sits in-between the client and the temporality-enabled WFS and translates incoming requests to a snapshot query parameterised with the current time.
Alternative Approaches
Introducing a new query type isnt the only way to get the required functionality of a temporality-aware query interface. In the process of finding the best solution, several approaches were evaluated. In chapter REF _Ref316049290 \r \h 6 the existing WFS 2.0 standard was evaluated in how far it is matching the requirements. In this chapter we evaluate alternative approaches of extending the standard or utilizing other existing standards. For each approach advantages and disadvantages over the proposed temporal query are discussed.
Introduction of Extended Projection Clauses
In WFS 2.0, the PropertyName projection clause adds non-mandatory properties to the features in the result set. In SQL, the projection part defines the set of columns returned plus an arbitrary number of calculated values. Hence, the task of filtering time slices and the returning of new time slices (SNAPSHOT generation) makes the introduction of additional projection clauses an obvious choice.
Two projection clauses would be necessary: one for the filtering of time slices and one for the generation and filtering of SNAPSHOTs. Both projection clauses embody a FE filter itself for the time slice filtering. This approach is described in more detail in [4].
Discussion:
The existing wfs:Query element does not need to be replaced, i.e. the extension is less invasive to the WFS 2.0 standard. However, this does not enable existing, non-temporality-aware clients to use the extended elements, unless they support unknown elements in a very generic way.
By definition, projection clauses only modify the properties of a feature. Hence, the set of returned features is defined by the filter expression in the wfs:Query element only and cannot by changed by any projection clause. If the time slice filter in a projection clause doesnt match, the list of time slices is empty, but the feature is still part of the response. To solve this, the FE filter element needs to be extended such that it excludes features without matching time slices.
Summary
Though this approach is less invasive to the standard at first sight, the differences become less important in a fully elaborated version. The Temporal Query is preferred as it is better tailored to the temporality aspects of the data.
Web Processing Services
The Web Processing Service (WPS) is an OGC standard for processing geospatial data. A WPS provides client access across a network to pre-programmed calculations and/or computation models that operate on spatially referenced data. Data inputs can be legitimate calls to OGC web services, such as WFS.
It is possible to implement a WPS that meets all of the identified requirements. The general workflow is depicted in REF _Ref316284878 \h Figure 2.
SHAPE \* MERGEFORMAT
Advantages
Works with the existing WFS and WPS standards.
Disadvantages
For each query, the full history of time slices of the selected features has to be transmitted between the WFS and the WPS. This is inefficient and wont be acceptable for productive, long-running systems.
The client has to encode the filter on feature level into the URL of the WFS, whereas the FE filter on time slice level can be encoded in the XML document of the request (e.g. when using SOAP). This is an unnatural interface.
Still, though standard WFS and WPS are used, generic clients wont be able to make use of the temporal queries efficiently. Clients have to be temporality-aware.
Summary
The disadvantages clearly outweigh the advantages.
XQuery
XQuery is a powerful query and functional language designed to query collections of XML data. It is not an OGC standard and does not define an interface for a web service. Hence, XQuery is not ready to replace a WFS. However, the power of the query language qualifies it for a possible extension of a WFS improving its filtering capabilities. For the sake of completeness we will briefly evaluate its application on AIXM 5 data.
XQuery has the power to express all required queries including the generation of SNAPSHOT time slices. However,
There are no spatio-temporal operators available. The powerful FE filter operators have to be redefined using XPath functions
There is no feature model as XQuery is based on pure XML. There is no abstraction of the temporality models used in AIXM 5 or GML DFM.
The result is that even simple queries dealing with temporality aspects will require complex query expressions that are hard to build and read.
Future Work
This discussion paper proposes an extension to the WFS 2.0 specification, and as such it is work in progress. Detailed reviews by stakeholders are needed to bring it forward and to finalise it. During that process, changes to individual elements are likely. For this reason some work items arent finished here by intention. They are listed in the following sections.
Formal Work
Formal work for a new or extended standard includes:
the creation of an XML Schema covering all introduced elements and attributes
good examples for the common cases
reporting of temporal query feature in the Capabilities Document
the analysis of edge cases, error reporting, robustness, conformance classes
Exclusion of Properties
For some use cases only a subset of the properties of a feature (or time slice) need to be retrieved from a WFS. Additional information can always be skipped by the client, but it is generally more efficient not to receive it at all for saving bandwidth and processing time. This is especially true if the unwanted data is big in size compared to the data actually used, and if it is received very often. One example for this kind of data is metadata: there is time slice metadata, feature metadata and even message metadata defined in AIXM 5. For quite a lot of use cases, such as machine-to-machine communication in an operational scenario, metadata may not be processed at all.
The proposed extension could be further enhanced such that the client is enabled to define a list of properties to be excluded from the result. This resembles the existing PropertyName projection clause. However, the PropertyName clause only allows inclusion of optional properties, but not exclusion of unwanted ones.
Annex A
Examples
A.1 Example for section REF _Ref316314871 \r \h 7.5.2, Evaluation of properties with schedules for output
Data store contents:
0083defb-b42e-4417-9be2-7aba2db2674d
2011-07-01T00:00:00.000Z
2011-07-15T23:59:59Z
BASELINE
1
UTC+2
ANY
00:00
05:59
MILOPS
INACTIVE
UTC+2
ANY
06:00
17:59
MILOPS
ACTIVE
UTC+2
ANY
18:00
23:59
MILOPS
INACTIVE
Query:
gml:identifier[@codeSpace="http://www.example.org "]
0083defb-b42e-4417-9be2-7aba2db2674d
2011-07-01T08:00:00.000Z
Response:
0083defb-b42e-4417-9be2-7aba2db2674d
2011-07-01T08:00:00.000Z
SNAPSHOT
MILOPS
ACTIVE
A cancelled sequence is always closed and cant be re-opened by the insertion of another time slice with a higher correction number.
Identifying corrected time slices is not trivial using FE 2.0. The maximum correction number of a sequence has to be calculated for this purpose, which would involve a complex XPath expression.
Whereas in theory, custom XPath functions could be introduced to transform a list of time slices into SNAPSHOT time slices, this would be clearly against the semantics of the operation as defined by the WFS specification, which are to retrieve the value of a feature property or part of a complex feature property.
SUBJECT \* MERGEFORMAT OGC 12-027
SUBJECT \* MERGEFORMAT OGC 12-027
PGINA iv COMMENTS \* MERGEFORMAT Copyright 2012 Open Geospatial Consortium, Inc. All Rights Reserved.
COMMENTS \* MERGEFORMAT Copyright 2012 Open Geospatial Consortium, Inc. All Rights Reserved. PAGE 23
SUBJECT \* MERGEFORMAT OGC 12-027
PAGE 22 COMMENTS \* MERGEFORMAT Copyright 2012 Open Geospatial Consortium, Inc. All Rights Reserved.
DRAFT OpenGIS Specification SUBJECT \* MERGEFORMAT OGC 12-027
COMMENTS \* MERGEFORMAT Copyright 2007 Open Geospatial Consortium, Inc. All Rights Reserved. PAGE 1
Figure SEQ Figure \* ARABIC 2 - WPS/WFS Workflow for Temporal Queries
WPS
WFS
Client
Contents:- URL of WFS including URL-encoded FE filter for filtering features- parameters for temporal query: FE filter for time slices, snapshot time, etc
Contents:- standard WFS 2.0 query selecting features
Contents:- one or more features with their full history of time slices
Contents:- one or more features with the desired subset of time slices or generated SNAPSHOTs
! ) 3 P Q f g h ߾߾ߍ|reU hX hJ. hJ. B* CJ ph hX hJ. B* CJ ph h*K 5B*ph !h9;] 5B*CJ mH nH ph uj h*K 5B*CJ Uph h*K 5B*CJ ph h9;] B*ph j h*K B*Uph h*K B*ph h*K 5B*CJ H*ph h'7 5B*CJ ph h*K 5B*CJ ph h*K B*CJ ph h*K B*CJ$ ph ! 4
& G $
)6&*$. / a$ #F $d %d &d