Web Registry Service Demonstrations Demo Data Considerations

Copyright © 2011 Open Geospatial Consortium. 17

6.3.3 Flight Conduction

During the course of the flight, the activation schedule for an airspace on the route is changed. The Dispatch Office is notified by the ARTCC, and radios the change to the flight. The crew checks the new activation schedule and location of the airspace and finds that it does not directly affect the flight. ES UC 1b2b

6.3.4 In-Flight Replanning

Severe weather is encountered and the flight has to be diverted. For planning a diversion route, the crew uses the client application, which displays on the enroute chart all SAAs, represented differently e.g., colored depending of their activation time e.g., currently active becomes active in 248 hrs. The crew plans a diversion route avoiding active airspaces. WFS UC 1, ES UC 3, ES UC 1a2a

6.3.5 After Flight

The subscription is removed. ES UC 3

6.4 Web Registry Service Demonstrations

The Web Registry Service demonstrations include publication, discovery and life-cycle management capabilities, described briefly below. More information on the Web Registry Service design is provided in the OWS-7 publication Aviation Portrayal ER 10-127r1. Discovery Search for datasets by bbox bounding box and keyword e.g. AIXM Retrieve dataset metadata of interest from search above Discover styles SLDs and services Envitia and Luciad FPS associated to the dataset found above Retrieve two different SLD docs - view as html table legend Retrieve FPS capabilities including service endpoints and capabilities Dataset Metadata AIXM Metadata for datasets in GMLISO 19139 encoding Service Metadata determine the endpoints and capabilities of services that provide AIXM data in a given area of interest, including FPS andor WFS Portrayal Data get SLDs relevant to a chosen dataset get Symbols Data loading publication load dataset metadata load FPS capabilities and endpoint urls load SLDsSymbols 18 Copyright © 2011 Open Geospatial Consortium. Lifecycle Managment View audit trail related to SLDs andor symbols versions submittedchangedupdated CreationPublishing Create ebRIM model using Designer client Publish model to Registry Additional Functionality notification of changes in registry e.g. to inform FPS of new SLDs

6.5 Demo Data Considerations

In preparing for the scenario demonstrations, two ways to provide sample data to drive the demo events were considered. Updates, at least to the dynamic data, could be simulated via a special demo schedule feed that the WFS and Event Service Adapters would access. With this approach, relevant demo events are triggered by a pre-defined schedule feed. This would require: a separate custom feed endpoint functionality for client providers to perform update of schedule feed upon request exact content of feed entries to achieve desired events would need to be defined higher frequency of scans by ES Adapter during demo to pick up changes immediately, since waiting several minutes to continue in the demo would not be feasible having the ES Adapter set to the time that is used in actual demonstration because the ES Adapter detects hot activations based upon current time, which could be different based upon the timeframe that best suits the demo scenario. Figure 6-1 illustrates the use of a demo schedule feed: Copyright © 2011 Open Geospatial Consortium. 19 Figure 6-1. Scripted Airspace Reservation Schedule Updates The advantage of this approach would be that the whole component chain is demonstrated, and that the demo schedule feed would automatically trigger events to be sent to the Event Service, and also insert the changes into the WFS. Figure 6-2. Manual triggering of WFS updateevent 20 Copyright © 2011 Open Geospatial Consortium. An alternative approach would be to use a tool to manually send the necessary events to the Event Service and to update the WFS, as seen in Figure 6-2. With this approach, simulated airspace activation changes are triggered manually, which has the following advantages: changes can be triggered as needed no need for components to synchronize and reset their state before running the demo This would also require that the demo Event Service Adapter functionality be validated through additional testing. To minimize the need for synchronizing timestamps among different sets of demo data for use by different components, the latter approach of manually generating event messages was adopted to demonstrate SAA data dissemination in the Pilot Study. An additional Event Service Adapter Tester component was developed to ensure that the adapters work as expected. Details of this additional component can be found in section 7.2.3. Copyright © 2011 Open Geospatial Consortium. 21 7 SAA Pilot Components This section describes the OGC components implemented for the SAA Pilot Study. Note: a summary of the standards relevant for the implementation of these components is provided in chapters three and four of the Request For Quotation And Call For Participation In the FAA SAA Dissemination Pilot – Annex B

7.1 Event Service Implementation