Persistence of Historical Timeslices Performance Aspects of Timeslice Use in Feature Portrayal Service

Copyright © 2011 Open Geospatial Consortium. 61 components of the Event Service are used, thus ensuring a high significance of the heartbeat messages. The disadvantage of clients not being able to specify the heartbeat interval was acknowledged, but considered not significant for the Pilot Study implementation. To produce the heartbeats, a small Java program was implemented. It can be configured to send messages to a given URL in a given interval. The messages look like this: The only content of the heartbeat message is the time and date of the generation. This allows clients to verify that the Event Service is not overloaded.

8.9 Persistence of Historical Timeslices

The AIXM 5.1 conceptual model states that a real-world aeronautical object should be represented by a single feature containing one or more timeslice objects representing the state andor events that have occurred or will occur during its lifespan. However, this conceptual representation poses a challenge for implementing systems using OGC WFS 2.0. The OGC WFS 2.0 assumes that the features contained within the service conform to the ISO 19109 General Feature Model and is designed to retrieve complete features or values for a single specified property. There is no operation within the WFS to return a feature containing a subset of objects. Therefore, if an aeronautical object is represented as a single feature containing multiple timeslice objects, then the service will return all the timeslices. This becomes problematic with airspace reservation TEMPDELTA timeslices collected over time, which generally are requested created on a daily basis. After discussion of several alternative ways for the WFS to support features with more than one timeslice, it was decided to persist all available timeslices, and to return them all in response to a feature request. This approach may be suboptimal for large scale WFS implementations where large numbers of BASELINE timeslices may exist, leading to very large feature definitions when encoded in AIXM5. This approach also implies the WFS will have a semantic responsibility to ensure that the collection of timeslices associated with a particular feature always represent a current valid state; e.g., at least one BASELINE, PERMDELTA or TEMPDELTA timeslice must be valid at any point in time. More information on the issue of subsetting timeslice information of a returned AIXM feature is provided in the OWS-8 WFS Guidance Engineering Report.

8.10 Performance Aspects of Timeslice Use in Feature Portrayal Service

There are two distinct approaches to exploiting the time element in AIXM within the Feature Portrayal Service. There may in the end not be too much to choose between them, but if the FPS provides data caching, it is possible that one approach is preferred to the other. The FPS has two main methods of selecting temporal data. The first is to specify an OGC Filter in the FPS Request. This filter would then select a specific timeslice for visualisation. These are hb:Heartbeat xmlns:hb=de.IfGI.swsl.SES.heartbeat hb:date2011-04-05T12:39:37.275Zhb:date hb:Heartbeat 62 Copyright © 2011 Open Geospatial Consortium. characterised by the structure of the request to the FPS, the resulting request to the WFS, and caching of the WFS response by the FPS. It is possible to define a filter request in the FPS which is passed along to the WFS to return a specific set of data for a given time. AIXM includes the construct of ‘Timeslice’ within featureType. Thus if a simple featureType is requested, the result will include a number of timeslices. Each timeslice is then accessed via an XPath expression. The alternative is to have a more selective Filter expression which can specify an individual timeslice. The result is then rendered directly. In the first approach, all data is read up front and cached. Further requests as the user pans along the timeline do not trigger a new WFS Query, as the FPS spots that the URL and query string are unchanged. Hence individual timeline increments are smooth, although the initial wait to retrieve the data is longer. The alternative is to continually modify the time interval or value defined in the WFS Request. The result of this approach is that a WFS request will be executed each time the user increments the timeline selection. Given the latency involved in repeated WFS queries, the simple featureType approach may not be as practical as using an OGC filter, and can result in a jerky visual display. 8.11 AIXM 5.1 Representation Issues 8.11.1 Defining inactive time for airspaces