The WFS specification defines an interface for a generic network-accessible XML-based data store, typically implemented in practice on top of a SQL database. Similarly to SQL, it supports the ability to do transactions (Insert, Update, Delete), as well as supporting a flexible query interface (GetFeature). From the query perspective, the WFS specification heavily leverages a companion specification, OGC Filter 2.0, which itself layers spatial and temporal queries on top of the core XPath query specification.

WFS Base Functionality

WFS base functionality in the context of typical FAA use cases includes the following:

• Spatial Queries

  Filtering of data based on spatial extent is a common use case in the NAS. A typical use case would be filtering of CONUS data based on the geometry of a particular en-route sector. The WFS supports a wide range of spatial operators and operands for this purpose. Spatial operators supported by the reference implementation include BBOX, Crosses, Disjoint, Equals, Intersects, Overlaps, Touches, and Within. Supported spatial operands are based on the Geography Markup Language (GML), and include gml:Point, gml:Curve, gml:Polygon, and gml:Envelope (simple bounding rectangle).

• Temporal Queries

  Weather data has a number of associated temporal properties, including observation time, forecast time, and forecast generation time. Similar to the spatial case, the WFS specification provides a variety of temporal operators and operands. Temporal operators supported by the WFSRI include Before, After, and TEquals. Temporal operatands include gml:TimeInstant and gml:TimePeriod.

Additional Functionality

The basic temporal operators are sufficient for the most common weather data queries. In the WFSRI, additional capability is provided in the form of the TimestampAdd function, which allows for more complex queries such as "Get me the forecast where ForecastTime = (ForecastGenerationTime + deltaTime)".

• General Property Queries

  A number of weather products, such as the METAR and TAF have an associated station identifier, the ICAO airport identifier. The WFS provides the general ability to filter on this and other string or numerical fields via a set of scalar operators and operands. Supported operators include PropertyIsEqualTo, PropertyIsLessThan, PropertyIsGreaterThan, PropertyIsLessThanOrEqualTo, PropertyIsGreaterThanOrEqualTo, and PropertyIsNotEqualTo. Supported operands include XML string, integer, float, and double data types.

• Combined Queries

  These queries combine the aforementioned spatial, temporal, and property-based filtering criteria, using the boolean And, Or, and Not operators. This query capability allows queries for complex spatial volumes such as a multi-layered airport departure airspace (the so-called 'inverted wedding cake') to be specified.

• Caching of Data for Efficient Access by Multiple Users

  The WFS supports in-memory caching of data that is requested frequently, minimizing the need for repeatedly accessing the underlying data store when multiple users are requesting the same data.

• Data Archival

  An instance of a WFS is capable of serving as a data archive. The time frame for the data store is dependent on the particular application and deployed WFS node location. For example, a WFS node deployed in the National Airspace System (NAS) may be required to maintain 15 day's worth of data, for accident reconstruction purposes. A WFS node elsewhere in the system may only be required to store data in the recent past (~ 2 hours) - sufficient time to support initializing or re-initializing the history of an end-user display.

The WFS is by design relatively generic with respect to the data products it handles. Most commonly, the data is encoded in XML, and in addition the XML conforms to the GML Application Schema conventions whereby spatial elements in particular are encoding using the GML XML syntax. In the weather domain, the WXXM weather data is just such a GML application schema, making it a natural fit for use with a WFS data access service.

Though primarily tested to date using XML weather products using the WXXM encoding, neither the WFS specification or the WFSRI implementation are restricted to WXXM. As mentioned earlier, the WFS specification, and particularly the 2.0 version of the specification, is intentionally generic, supporting other XML-based formats such as the OASIS Common Alerting Protocol (CAP). The service specification is also not weather-specific. Examples of non-weather data types supported by the WFS specification would include Runway and En-Route Airspace Sector data encoded using the Aeronautical Information eXchange Model (AIXM) XML schema, and flight data encoded in XML.

On MDL's WFSRI web service suporting prototying efforts with the FAA, we offered up the following feature information:

• National Convective Weather Forecast (NCWF)
• Aircraft Meteorological Data Relay (AMDAR)
• Pilot Reports (PIREP)

WFSRI User Experiences and Examples