4-Dimensional Weather Data Cube



4-Dimensional Weather Data Cube

Web Feature Service Reference Implementation (WFSRI)

Requirements

Version 2.32 (Draft)

11/18/200901/13/2010

National Oceanic and Atmospheric Administration/Global Systems Division

National Center for Atmospheric Research

MIT Lincoln Laboratory

DOCUMENT REVISION REGISTER

|Version |Date |Content Changes |Editors |Contributors |

|0.1 |03/13/2009 |Preliminary draft |Minna Win |Patrick Hildreth, Glen Pankow, Paul |

| | | |MarySue Schultz |Hamer, Minna Win, MarySue Schultz, Chris|

| | | | |MacDermaid |

|1.0 |3/27/2009 |Initial version |MarySue Schultz |Aaron Braeckel, Eric Mandel, Chris |

| | | |Minna Win |MacDermaid, Kajal Claypool, Oliver |

| | | | |Newell |

|2.0(draft) |10/15/2009 |Updates |Kajal Claypool | |

| | | |Ai-Hoa Sanh | |

|2.1 |11/18/2009 |Updates to 2.0 Draft |Kajal Claypool |Minna Win, Steve Newton, Mark Simons |

|2.2 |11/18/2009 |Formatting, minor edits of 2.1 |Dan Tennant | |

Please direct comments or questions to:

Kajal Claypool

MIT Lincoln Laboratory

244 Wood Street

Lexington, MA 02420

claypool@ll.mit.edu

(781) 981-5404

Ai-Hoa Sanh

MIT Lincoln Laboratory

244 Wood Street

Lexington, MA 02420

asanh@ll.mit.edu

(781) 981-5816

TERMS OF USE – NNEW DOCUMENTATION

The following Terms of Use applies to the NNEW Documentation:

1. Use. The User may use NNEW Documentation for any lawful purpose without any fee or cost. Any modification, reproduction and redistribution may take place without further permission so long as proper copyright notices and acknowledgements are retained.

2. Acknowledgement. The NNEW Documentation was developed through the sponsorship of the National Oceanic and Atmospheric Administration and the Federal Aviation Administration.

3. Copyright. Any copyright notice contained in this Terms of Use, the NNEW Documentation, any software code, or any part of the website shall remain intact and unaltered and shall be affixed to any use, distribution or copy. Except as specifically permitted herein, the user is not granted any express or implied right under any patents, copyrights, trademarks, or other intellectual property rights with respect to the NNEW Documentation.

4. No Endorsements. The names MIT, Lincoln Labs, UCAR, and NCAR may not be used in any advertising or publicity to endorse or promote any program, project, product, or commercial entity.

5. Limitation of Liability. The NNEW Documentation, including all content and materials, is provided "as is." There are no warranties of use, fitness for any purpose, service or goods, implied or direct, associated with the NNEW Documentation and MIT and UCAR expressly disclaim any warranties. In no event shall MIT or UCAR be liable for any damages of any nature suffered by any user, or any third party resulting in whole or in part from use of the NNEW Documentation.

TABLE OF CONTENTS

1 PURPOSE 7

1.1 DOCUMENT SCOPE 7

1.2 OTHER DOCUMENTS 7

2 4-D WX DATA CUBE BACKGROUND 8

2.1 DATA PROVIDER FEDERATION 8

2.2 WEATHER CUBE DOMAINS 9

2.3 DATA PROVIDERS AND CONSUMERS 10

2.4 DATA TYPES AND STANDARDS 11

2.4.1 Data Types 11

2.4.2 Service Standards for Non-Gridded Data Dissemination 12

2.4.3 Web Feature Service (WFS) for Non-gridded Data Dissemination 13

2.4.4 WFS Implementations 13

2.5 WFSRI FOR THE 4-D WX DATA CUBE 14

3 REQUIREMENTS CATEGORIES 15

4 REQUIREMENTS – FUNCTIONAL 16

4.1 DATA MANAGEMENT 16

4.2 FEATURE SUBSETTING 16

4.2.1 Geometric Filtering 16

4.2.2 Temporal Subsetting 17

4.3 FEATURE FORMATS 18

5 REQUIREMENTS – WFS SPECIFICATIONS 19

5.1 COORDINATE REFERENCE SYSTEMS (CRS) 19

5.2 ENCODINGS 20

5.3 WFS OPERATIONS 20

5.3.1 GetCapabilities Request 20

5.3.2 GetCapabilities Response 21

5.3.3 DescribeFeature Request 22

5.3.4 DescribeFeatureType Response 23

5.3.5 GetFeature Request 24

5.3.6 GetFeature Response 24

5.3.7 GetMetadata Request and Response 25

6 REQUIREMENTS – 4-D WX DATA CUBE INTEGRATION 26

6.1 REAL-TIME DATA DISSEMINATION 26

6.2 4-D WX DATA CUBE ARCHITECTURE 27

6.3 DATA MANAGEMENT 28

6.4 FEATURE METADATA 28

6.5 MONITORING 29

6.6 AUDITING 30

6.7 LOGGING 30

6.8 SECURITY 31

7 REQUIREMENTS – SWIM INTEGRATION 33

8 REQUIREMENTS – DEPLOYMENT AND CONFIGURATION 35

9 REQUIREMENTS – CHANGE MANAGEMENT 36

10 REQUIREMENTS – TEST SUITE AND VALIDATION 37

11 ACRONYMS 38

12 DEFINITIONS AND TERMS 39

13 REFERENCES 40

TABLE OF FIGURES

Figure 1. Federated 4-D Wx Data Cube 8

Figure 2. 4-D Wx Data Cube Domains 9

Figure 3. Populating the 4-D Wx Data Cube 10

Figure 4. Interoperability Stack 13

Figure 5. NNEW Components 27

Figure 6. The SWIM Container and the WFSRI 35

Figure 7. SWIM, FTI and Program Relationships 36

PURPOSE

1.1 DOCUMENT SCOPE

To satisfy the requirements of the virtual 4-Dimensional Weather Data Cube (4-D Wx Data Cube), it is envisioned that a number of components will comprise the physical solution. The components will be based on a set of standards that have been adopted by the NNEW Program, including the Open Geospatial Consortium (OGC) Web Feature Service (WFS) and Web Coverage Service (WCS). Reference implementations for the WFS and WCS will be produced, providing a definitive interpretation of the standards, as well as production-quality services for operational parties and an example that can be used by operational data providers that choose to implement the standards differently. The reference implementations will be developed and licensed in an open, standards-based fashion to allow for broad usage.

This document describes the requirements of the Web Feature Service Reference Implementation (WFSRI), which is well-suited for serving non-gridded feature data. This document has two purposes:

1. To describe the requirements of this phase of development in adequate detail to enable the development of the WFSRI. This description will facilitate subsequent design, implementation, and deployment phases of the NNEW Program.

2. To describe the general (abstract) requirements of serving feature data, independent of the underlying technologies. These requirements may be used as guidance in future developments outside the scope of the current NNEW Program development effort.

1.2 OTHER DOCUMENTS

High-level requirements for the 4-D Wx Data Cube have been established over the past several years by the Joint Program Development Office (JPDO). Documents describing these requirements include the “Concept of Operations for the Next Generation Air Transportation System" [?], the “Four-Dimensional Weather Functional Requirements for NextGen Air Traffic Management "[?], and others. With these high-level requirements in mind, the lower-level “NNEW IT CONOPS" [?] captured a set of 4-D Wx Data Cube requirements relevant to network-enabled weather. The NNEW IT CONOPS document provides a representative set of use cases that are intended to aid system architects in understanding typical usages of the 4-D Wx Data Cube. Though not exhaustive, the selection of use cases represents an attempt to ‘span the problem domain,’ covering both functional and non-functional scenarios.

This document focuses more closely on implementation issues than the NNEW IT CONOPS document, and may generate new information that is relevant to the latter. It uses the concepts described in the higher-level documents to produce specific requirements for feature data dissemination.

4-D WX DATA CUBE BACKGROUND

2.1 DATA PROVIDER FEDERATION

The 4-D Wx Data Cube is a virtual entity comprised of a federation of distributed data sources, rather than a large, centralized weather data warehouse. This architecture is illustrated in Figure 1. The virtual 4-D Wx Data Cube uses the concept of the "Single Authoritative Source" (SAS) for weather, whereby a single ‘best’ data source for a given data type (e.g., temperature) is used to provide a common weather picture to all NAS users.

[pic]

Figure 1. Federated 4-D Wx Data Cube

2.2 WEATHER CUBE DOMAINS

Though one of the most common uses of the 4-D Wx Data Cube will be to access weather information from the SAS, other data domains will also be supported. The key domains identified to date in the 4-D Wx Data Cube are shown in Figure 2, which represents the SAS as one of a number of domains of weather data within the Cube.

[pic]

Figure 2. 4-D Wx Data Cube Domains

As shown in the figure, the bulk of the data within the 4-D Weather Data Cube (including the SAS) will be made available on an open and unrestricted basis. The regulatory category (Domain 2b) overlaps the SAS, but includes additional regulatory information, such as the Terminal Aerodrome Forecasts (TAFs) for destination airports that are required of all pilots.

2.3 DATA PROVIDERS AND CONSUMERS

Some key data providers and consumers are depicted in Figure 3. Raw observations are provided to the Cube from a wide variety of weather sensors, including aircraft. Forecasting systems act first as data consumers, using observations to set the initial conditions for their models, and then as data providers, making generated forecast data available to other consumers. Higher-level integration functions access weather data, producing information in a variety of forms for end users.

[pic]

Figure 3. Populating the 4-D Wx Data Cube

The interactions shown in Figure 3 fall into a number of categories. Communication may rely on either “pushing” or “pulling” the transferred data. Bandwidth restrictions will influence the choice of formats used in data transfer, particularly in the earlier stages of NextGen development. In addition, timing, data archiving, and system stability will influence the architecture of the 4-D Wx Data Cube. An effective architectural solution for NNEW will need to support a variety of approaches to meet these different needs.

2.4 DATA TYPES AND STANDARDS

2.4.1 Data Types

From Figure 3, it is apparent that a variety of data types fall within the weather domain. Numerical models generate continuous grids of data values, representing a large area and volume. Conversely, data from surface observations represent sensor measurements at individual, irregularly spaced locations. Clearly, these types of data are fundamentally different.

Weather data can be loosely categorized into features and coverages, as defined by the OGC. According to the OGC’s Reference Model[?]:

A feature is an abstraction of a real world phenomenon. A geographic feature is a feature associated with a location relative to the Earth. A digital representation of the real world can be thought of as a set of features.[...] A feature is not defined in terms of a single geometry, but rather as a conceptually meaningful object within a particular information or application community, one or more of the feature's properties may be geometric.[...] A feature collection is a feature that represents a collection of features that have common metadata and formal relationships. Collections possess all the characteristics of a feature.

Geographic phenomena fall into two broad categories, discrete and continuous. Discrete phenomena are recognizable objects that have relatively well-defined boundaries or spatial extent. Examples include buildings, streams, and measurement stations. Continuous phenomena vary over space and have no specific extent. Examples include temperature, soil composition, and elevation. A value or description of a continuous phenomenon is only meaningful at a particular position in space (and possibly time). Temperature, for example, takes on specific values only at defined locations, whether measured or interpolated from other locations. These concepts are not mutually exclusive. In fact, many components of the landscape may be viewed alternatively as discrete or continuous. Historically, geographic information has been treated in terms of two fundamental types called vector data and raster data.

"Vector data" typically deals with discrete phenomena, each of which is conceived of as a feature.

Raw meteorological data is available via a number of mechanisms and standards. A complete description of these is outside the scope of this document and readers are directed to the referenced documents listed below.

Under the terms of the Initial Operating Capability (IOC) (See Reference i) and associated data list, the standards used for the types of data to be considered for the WFSRI are to be found in:

• ICAO Meteorological Service for International Air Navigation, Annex 3 [?]

• WMO Publication No. 306 – Manual on Codes [?]

• WMO Table-Driven Code Form – FM 94 BUFR [?]

• Federal Meteorological Handbook Nos. 1, 3, 11 and 12 [?]

The proposed result model for WFS queries will be based on the joint Eurocontrol/FAA Weather Information Exchange Model (WXXM). From the introductory pages of the WFS/WCS requirements documents, one can understand the OGC definition of a feature. The following specific data types are considered candidates for the WFS:

• Lightning Data

• Pilot Report (PIREPs)

• Aviation Routine Weather Report (METARs)

• Significant Meteorological Information (SIGMET/G-SIGMET)

• Airmen's Meteorological Information (AIRMET/G-AIRMET)

• Meteorological Data Collection and Reporting System (MDCRS)

• Terminal Aerodrome Forecasts (TAFs)

• Automated Surface Observing Systems (1-min ASOS data)

• Level-III NEXRAD:

o VAD Wind Profile

o Storm Structure

o Hail Index

o Mesocyclone

o Tornadic Vortex Signature

o Storm Tracking Information

The population of a data store with these data in real-time will be required.

2.4.2 Service Standards for Non-Gridded Data Dissemination

One of the primary goals of NNEW work to date has been to identify the standards that will be used for weather data dissemination. The use of standard data formats and communication protocols enables integration across disparate systems, and eliminates the need for system-specific adapters. Within the GIS community, the standards for representing data are generally divided into feature and coverage categories. Below are brief descriptions of contemporary protocol standards that define feature data access:

• Open-source Project for a Network Data Access Protocol (OPeNDAP) – OPeNDAP is a client-server software framework that allows simple access to remote data. OPeNDAP servers make local data accessible to remote locations by implementing a client/server protocol over HTTP. The protocol is not oriented toward service-oriented architectures, and does not provide direct support for SOA-like technologies such as SOAP and Web Services Interoperability (WS-I).

• Joint METOC Broker Language (JMBL) – JMBL is a standard developed by the Air Force Weather Agency and United States Navy to support Meteorological and Oceanographic Data (METOC), in both gridded and non-gridded formats. JMBL was developed specifically to fit the needs of the Department of Defense (DOD) communities, and precedes many of the OGC and ISO standards developed for geospatial data. It has been adopted primarily by the US Air Force and US Navy.

• Web Feature Service (WFS) – The Web Feature Service, developed by the Open Geospatial Consortium (OGC), specifies a standard access protocol for feature data. The OGC is a “non-profit, international, voluntary consensus standards organization that is leading the development of standards for geospatial and location based services.” Justification for the adoption of this standard as part of NNEW and the 4-D Wx Data Cube is included in the following section.

2.4.3 Web Feature Service (WFS) for Non-gridded Data Dissemination

The WFS specification was chosen as the standard for the NNEW Program’s weather data dissemination for a variety of reasons. The WFS specification is built upon other open and broadly used standards (e.g., ISO 19105). The inclusion of a wide community of organizations in the standards definition process promotes a general solution that likely satisfies the interests of the majority of stakeholders, while minimizing the influence of individual intentions. As a result, the standards produced by the OGC are generally and widely applicable. The WFS, developed by the OGC, specifies a standard access protocol for feature data. The OGC defines many widely adopted standards related to the geospatial data interchange and definition, including GML, WFS, WMS, etc. The consortium consists of over 370 members, including governmental agencies, private companies, and educational institutions.

The WFS specification has broad geospatial applicability beyond the weather domain. This allows other disciplines—such as aeronautical, environmental, and air traffic information—to share data and access protocols through geospatial constructs rather than through domain-specific (e.g., weather-specific) constructs. Figure 4 illustrates one such approach to interoperability.

[pic]

Figure 4. Interoperability Stack

Other aviation programs, both within the FAA and internationally, have shown interest in adopting OGC-related standards. The presence of aviation and weather organizations on OGC committees increases the likelihood that their needs are met. NNEW and other participating organizations are able to influence the standards definitions process by participating in OGC committees and working groups. In most cases, the generality and flexibility of the specification allows for extensions to be defined to meet additional needs.

2.4.4 WFS Implementations

There are existing WFS implementations that can be leveraged by the NNEW program for operational use. Commercial and open-source WFS implementations exist for both the WFS 1.0 and 1.1.0 specifications. GeoServer, an open source implementation, was tested with METAR and PIREP data at the FAA William J. Hughes Technical Center in the fall of 2008. It was found to be unsatisfactory for an operational environment, as it is not scalable and its performance is considerably slower than current data acquisition mechanisms. In addition, the open source spatial database (PostgreSQL with a PostGIS extension) used in the demonstration cannot store XML data that can be spatially queried. A spatial database that can store and allow spatial querying of XML data is essential for supporting the WFS spatial filtering requirements as specified in the OGC WFS Filter Specification as well as the NNEW throughput requirements. There are, however, existing commercial implementations of the WFS that support this functionality. A survey of the OGC's Registered Products web page[?] indicates the existence of a considerable number of vendors with varying degrees of expertise in building OGC web services.

2.5 WFSRI FOR THE 4-D WX DATA CUBE

There are several goals for this Reference Implementation of a Web Feature Service:

• Robust implementation of the WFS 1.1 specification. An implementation of the standard promotes interoperability across the broad spectrum of weather data producer and consumer communities.

• Out-of-the-box solution. The intention of the WFSRI is to provide a baseline implementation that may be used, out of the box, by any non-gridded data Service Provider participating in the 4-D Wx Data Cube. This implementation should be easy to install and configurable by the Service Provider. This will alleviate the need for Service Providers to develop their own custom WFS solutions.

• Operational quality. The WFS Reference Implementation is intended to be used as guidance for future development, as well as an operational instance. Future development may entail a vendor implementation of the WFS for the 4-D Cube, and in that sense, the WFSRI can be used as guidance. However, the WFSRI is also intended to be deployed as part of IOC, and therefore mandates a production/operational quality implementation. This also implies that enterprise-level capabilities, such as monitoring, security, etc, be supported in some fashion, either by the WFSRI itself or by the infrastructure in which the WFSRI will operate.

• 4-D Wx Data Cube integration. There are several NNEW-foundational components that will comprise the 4-D Wx Data Cube, including the WCSRI, WFSRI, and the Registry/Repository. Though the WFSRI may be functional within an isolated environment, it will also need to integrate with the other components (the Registry/Repository, in particular) in order for it to be operational within the 4-D Wx Data Cube.

• System Wide Information Management (SWIM) and FAA Telecommunications Infrastructure (FTI) integration. The FAA SWIM program provides an infrastructure for service-oriented capabilities within the FAA. FTI provides a network infrastructure. Since at least a portion of the 4-D Wx Data Cube will be run within the FAA, within SWIM and over FTI, the WFSRI must integrate with that infrastructure.

REQUIREMENTS CATEGORIES

The requirements for the WFSRI can be loosely categorized into areas of general applicability and areas more specific to integration efforts:

• Functional – This section describes the functional requirements for a non-gridded data server.

• WFS Specification – This section describes the requirements of the WFSRI as they pertain to the access protocol outlined in the WFS specification. The WFS has dependencies on the GML and Filter Encoding specifications, which will also be described in this section.

• 4-D Wx Data Cube Integration – This section lists the requirements for integrating with the 4-D Wx Data Cube. It summarizes the 4-D Wx Data Cube components (e.g., Registry/Repository) and services that the WFSRI will need to interoperate with in order to provide an integrated solution.

• SWIM Integration – At a minimum, when installed at FAA locations, the WFSRI will need to integrate with or conform to the SWIM architecture. As of this writing, this entails integration with the SWIM service container, a robust Enterprise Service Bus (ESB). This section explores how the WFSRI’s services will be deployed, and other special considerations for integration.

• Deployment and Configuration – The WFSRI will be installed and configured by a Service Provider, who will also set up the service container to host the WFSRI services. This section describes a few installation, configuration and deployment requirements, with the goal of easing the burden on the Service Provider.

• Change Management – As with any complex system, it is critical to consider how the system will evolve to handle change. Change manifests itself in many ways, including changes in: data formats, requirements, design elements, and architectural assumptions. This section summarizes the requirements imposed by the need to support iterative development of the WFSRI.

• Test and Validation – A successful WFSRI implementation and installation will need to be validated for correctness. This section describes the validation requirements for the WFSRI.

In addition, the requirements within this document are numbered for referencing purposes and to improve traceability. The “requirements” have been broken down into two categories:

• Requirement – an identified and documented need to be addressed, though specific deadlines are not implied.

• Potential Requirement – a possible need that may become a true requirement as additional information becomes available. These are noted to guide future requirements development, to promote flexibility in the implementation, and for completeness.

REQUIREMENTS – FUNCTIONAL

These functional requirements can be broadly grouped into the following categories:

1. Data Management

2. Subsetting

3. Formats

4.1 DATA MANAGEMENT

The main purpose of a feature server is to provide access to a specific set of non-gridded data sets. These exposed datasets are also referred to as features, and each will typically require a unique identifier, descriptive name, and relevant metadata. The server shall provide configuration capability for supported features and metadata.

Requirement 4.1.1: The WFSRI shall provide the capability for the Service Provider to specify the supported features.

Requirement 4.1.2: The WFSRI shall provide the capability for the Service Provider to configure the following for each feature offered by the WFSRI:

1. Name of the feature.

2. Descriptive metadata for the feature.

Feature data can exist in different data stores: relational databases, GML/XML files, native XML databases containing GML, or shapefiles. The WFSRI will only provide support for relational databases. Databases are employed for their transaction management support, high accessibility, the SQL query language, and numerous other attributes. The WFSRI will leverage the strengths of relational databases.

Requirement 4.1.3: The WFSRI shall support the relational database data store.

Requirement 4.1.4: The WFSRI shall provide output in an ISO 19139 format.

Requirement 4.1.5: The WFSRI shall provide a lifecycle management system that will allow Service Providers to specify policies for deleting data beyond a certain time period and/or archiving data for a specified period of time.

4.2 FEATURE SUBSETTING

Some clients are interested in a subset of a feature, whereas others (i.e. decision-support tools) are interested in entire features. Retrieving an entire feature without applying temporal or spatial constraints can be prohibitive due to limited bandwidth and disk space. Subsetting or filtering is typically performed on a combination of the following: one or more specific fields, time, or geometry.

Requirement 4.2.1: The WFSRI shall allow subsetting by zero or more fields (e.g., temperature, reflectivity). If no fields are indicated, all available fields shall be returned. All fields specified as mandatory by the data provider will be returned, irrespective of the user request. The mandatory fields will be specified by the data provider at the time of registration of the feature type.

4.2.1 Geometric Filtering

Requirement 4.2.1.1: The WFSRI shall support geometric filtering of features, including the following:

• 3D Volume. For this case, a 3-dimensional bounding box may be specified with dimensions defined by X, Y, Z value (such as latitude, longitude and altitude) ranges. A user can query for data that coincides with this volume.

• Horizontal 2-D Cross-section. If a constant altitude level is specified, a horizontal (latitude/longitude) slice will be taken through the feature volume.

• Vertical 2-D Cross-section. For this case, a vertical slice is taken through a feature. The path for the cross-section is defined by a set of XY waypoints and a sample density.

• Sounding. A feature may be subsetted by requesting a vertical column of data whose location is specified by a latitude/longitude point.

• Point. A feature may be subsetted by requesting a single point specified by X, Y, and Z values.

• Trajectory. A feature may be subsetted along a trajectory (a 3-D path) by specifying the latitudes, longitudes, and altitudes of two or more ordered waypoints. The returned feature will be a “line” of data along that 3-D path, where the geo-locations of the interpolated data points are determined with either Euclidean or Great Circle geometry.

• Corridor. A feature may be subsetted by extruding a rectangular area along a trajectory. A rectangular cross-section, orthogonal to and along a trajectory can be extracted from the feature volume by specifying the two or more ordered waypoints, the vertical range and the horizontal range. This rectangular cross-section is a corridor. In addition, this is a superset of the horizontal and vertical cross-sections, and may be used for cross-section subsetting.

At a future date, itIt may prove useful to allow arbitrary geometric subsetting beyond rectangular bounding boxes. For example, the CONOPS document1 mentions a “Sector,” which may be defined as an arbitrary, 3-dimensional, polygonal space. There are many possible use cases that can be satisfied by providing complex geometries such as this., though the full range of geometric capability is not currently required.

Potential Requirement 4.2.1.1P2: The WFSRI shall provide support for arbitrary geometric subsetting beyond rectangular bounding boxes.

4.2.2 Temporal Subsetting

Some products and requests for data warrant additional time constraints than those in the dataset. For instance, data may need to be recreated for a particular point in time to assist with accident investigation. In this case, a transaction time and request time will be required in addition to the dataset’s valid time.

Time constraints can be simple, such as a valid time closest to a given time instance, or more complex, such as when forecast data for a given time can be retrieved from different files generated at different times. In the latter case, a time constraint may specify a particular forecast generated at a particular ‘analysis time.’

Requirement 4.2.2.1: The WFSRI shall be capable of providing a list of valid times from datasets that are temporally aggregated.

Requirement 4.2.2.2: The WFSRI shall provide the capability to constrain features by requesting a single valid time.

Requirement 4.2.2.3: The WFSRI shall provide the capability to constrain features by requesting a range of valid times.

Requirement 4.2.2.4: The WFSRI shall provide the capability to constrain features by requesting additional time constraints such as transaction time, for accident reconstruction.

Potential Requirement 4.2.2.1P: The WFSRI shall provide the capability to constrain features by specifying complex time constraints. Examples of these are: Closest To, Latest, First Before, First After, If-Modified-Since, etc. These complex time constraints shall be consistent, wherever possible, with those identified in the WCSRI Requirements Document.

4.3 FEATURE FORMATS

The WFSRI will support the relational database data store. The data can be exposed via the external interface and presented in various formats. The WFS specification 1.1.0 requires that GML be used to express features within the interface and at a minimum present features using GML.

Requirement 4.3.1: The WFSRI shall require the use of GML(OGC 03-105R1) to express features within the interface and at a minimum, be used to present features. The GML version will conform to the version specified in WFS specification.

Note: THE WFSRI will support GML versions specified by the WFS specification.

The WXXM (Weather Information Exchange Model) is an information exchange model developed to address the needs of air traffic management (ATM). The model arose from a collaborative effort among ATM users, Aviation Meteorology (MET) providers, Air Navigation Service Providers (ANSP) and members from industry. Version 1.1 of WXXM and its schema (WXXS) are available for use and will be supported by the WFSRI.

The DOD compared several existing tactical message formats to their XML equivalents, and reported a 10-100x bandwidth increase.[?] With the volume of weather information anticipated to be in use by the operational 4-D Wx Data Cube, a 10-100x increase in the bandwidth usage of current formats is unlikely to be acceptable. Techniques to enable the efficient usage of XML will be required in many, if not all cases. A number of efficient XML solutions would significantly reduce both CPU usage and bandwidth requirements.

Requirement 4.3.3: The WFSRI shall support WXXM 1.1 encodings of XML as input and output formats.[?]

Requirement 4.3.4: The WFSRI shall support an efficient XML encoding of WXXM 1.1 output.

REQUIREMENTS – WFS SPECIFICATIONS

When completed, the official WFS document[?] will become a set of requirements for the WFSRI. This section summarizes what the WFSRI will support and provides details on how the WFSRI extends the protocol.

The WFSRI will support WFS version 1.1.0. The OGC is working on WFS 2.0. The ISO (International Organization for Standardization) has accepted 19142 (WFS) and 19143 (Filter Encoding Specification) as Draft International standards. The 2.0 document may not be completed in time to guide the implementation of the WFSRI for NNEW’s Initial Operating Capability (IOC). However, the WFSRI will be adaptable to future WFS specification versions.

Requirement 5.1: The WFSRI shall support the WFS version 1.1.0 specification.

Requirement 5.2: The WFSRI shall be designed to support future WFS specification versions.

The WFS specification requires that a WFS server communicate its capabilities. For instance, a WFS server shall indicate all supported version of the WFS specification. This property is important for client-server version negotiation, and for supporting multiple versions.

Requirement 5.3: The WFSRI shall support version negotiation as outlined in the WFS 1.1.0 specification.

5.1 COORDINATE REFERENCE SYSTEMS (CRS)

The WFS specification requires that the server indicate all supported CRSs, including the default CRS.The WFS specification requires the supported CRSs be available in a capabilities document. In the NextGen environment [or more specifically, with a service-oriented architecture (SOA)], one cannot anticipate users of the services or client applications that may be developed. Therefore, it is important to provide machine-accessible CRS definitions to communicate the details of a deployed WFS.

Requirement 5.1.1: The WFSRI shall initially provide at a minimum support for the European Petroleum Survey Group (EPSG) CRS.

Requirement 5.1.2: The WFSRI shall allow the user to request a CRS that is not the default and is supported by the WFSRI.

Requirement 5.1.3: The WFSRI shall return data using the default CRS if no CRS is specified.

The WFS 1.1.0 specification requires that CRSs be requested in one of three ways:

1. EPSG:

2.

3. urn: EPSG:geographicCRC:

The WFSRI will make CRS definitions electronically available; therefore, Uniform Resource Locators (URL) will be preferred over Uniform Resource Names (URN). URLs also guarantee uniqueness in that they resolve to a URL, whereas URNs are difficult to ensure uniqueness.

Requirement 5.1.4: The WFSRI shall use Uniform Resource Locators (URL) wherever it is appropriate for CRS identifiers.

5.2 ENCODINGS

In the general sense, the WFSRI will support SOAP and Plain Old XML (POX) encodings that are transmitted over HTTP POST. However, the Service Provider will require the ability to enable/disable each of those encodings.

Requirement 5.2.1: The WFSRI shall provide a means for the Service Provider to enable/disable the WFS operations by encoding type. (e.g., the Service Provider may wish to disable POX-style WFS operations.)

5.3 WFS OPERATIONS

The WFS standard defines interfaces and operations for data access and manipulation on a set of geographic features. A WFS must implement the following operations:

1. GetCapabilities – Discovers the features and services the WFS provides by obtaining its capabilities document. The returned document will be in XML and will contain metadata about the server capabilities. The GetCapabilities service is required by the WFS specification.

2. DescribeFeatureType – Returns an XML schema describing a dataset structure .

3. GetFeature – Returns the data of a feature.

For each operation, a request and a response structure has been defined. These are described in detail in the next sections.

5.3.1 GetCapabilities Request

The GetCapabilities request is sent from a client to the WFS server to request the server’s GetCapabilities document. The request is performed by using the element in an XML request as defined in this XML schema fragment:

This can also be obtained using a keyword-value pair (KVP):



When invoking a web feature service, the value of the ‘service’ attribute shall be WFS.

Requirement 5.3.1.1: The WFSRI shall support Key-Value Pair (KVP) encoding over http GET for the GetCapabilities operation.

Requirement 5.3.1.2: The WFSRI shall support Plain Old XML (POX) encoding over http POST for the GetCapabilities operation.

Requirement 5.3.1.3: The WFSRI shall support SOAP encoding over http POST for the GetCapabilities operation.

5.3.2 GetCapabilities Response

The GetCapabilities response is an XML document from the WFS server that describes the WFS server’s services, capabilities, and features.

A typical response has the form:

...

...

...

...

The section of the GetCapabilities document contains metadata about the WFS as a whole.

Examples of these server metadata are (per OGC WFSIS OGC 02-058 ):

|ELEMENT NAME |DESCRIPTION |

|Name |A name the service provider assigns to the web feature service instance. |

|Title |The is a simple title to briefly identify this server in menus. |

|Abstract | is a descriptive narrative for more info about the server. |

|Keyword |The element contains short words to aid catalog searching. |

|OnlineResource |The element defines the top-level HTTP URL of this service. |

| |Typically the URL of a "home page" for the service. |

|Fees |The element contains a text block indicating any fees imposed by the |

| |service provider for usage of the service or for data retrieved from the WFS. |

| |The keyword NONE is reserved to mean no fees. |

|AccessConstraints |The element constrain a text block describing any access |

| |constraints imposed by the service provider on the WFS or data retrieved from |

| |that service. The keyword NONE is reserved to indicate no access constraints are|

| |imposed. |

The section is used to define specifically the list of WFS operations that a particular WFS implements. A basic WFS would include the GetCapabilities, DescribeFeatureType and the GetFeature operations. A transactional WFS would also include the Transaction operation, possibly the LockFeature operation and/or the GetFeatureWithLock operation. Examples of these are (per OGC WFSIS OGC 02-058 ):

|ELEMENT NAME |DESCRIPTION |

|GetCapabilities |The element is included to define the available |

| |distributed computing platforms for this service. |

|DescribeFeatureType |The element is used to define the available |

| |distributed computing platforms for this service and indicate what schema |

| |description languages can be used to describe the schema of a feature type |

| |when a client requests such a description. XMLSCHEMA is the only mandatory |

| |language that must be available. The SCHEMALANGUAGES entity can be redefined|

| |to include vendor specific languages. |

|Transaction |The element is included to define the available distributed |

| |computing platforms for this service |

|GetFeature |The element is used to define the available distributed |

| |computing platforms for this service and enumerate the formats available for|

| |expressing the results of a query. The RESULTFORMATS entity defines the |

| |mandatory output format of GML but can be redefined to include additional |

| |vendor specific formats. |

|LockFeature |The element is included to define the available distributed |

| |computing platforms. |

Requirement 5.3.2.1: The WFSRI shall provide an XML document indicating services, capabilities, and features.

5.3.3 DescribeFeature Request

The DescribeFeature request returns an XML document that describes the data set structure. It lists each field and its datatype. The XML document defines how the WFS expects features to be encoded for input and how the features will be generated for output. The XML encoding of a DescribeFeature request is as defined in the following XML schema fragment:

or, as KVP:



Note that the only mandatory output format in response to a DescribeFeatureType operation is XML Schema, denoted by the value XMLSCHEMA for the outputFormat attribute. Other vendor-specific formats are also possible, but they must be advertised on the capabilities document.

Requirement 5.3.3.1: The WFSRI shall support Key-Value Pair (KVP) encoding over HTTP GET for the DescribeFeature request.

Requirement 5.3.3.2: The WFSRI shall support Plain Old XML (POX) encoding over http POST for the DescribeFeature request.

Requirement 5.3.3.3: The WFSRI shall support SOAP encoding over http POST for the DescribeFeature request.

5.3.4 DescribeFeatureType Response

In response to a DescribeFeatureType request, where the value of the outputFormat attribute has been set to XMLSCHEMA, a WFS implementation must be able to present an XML document that is a valid GML application schema and defines the schema of the feature types listed in the request. An example of a response is:

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download