Web Feature Service Implementation Specification with Corrigendum. Version 1.1.3.

Abstract

This document describes the OGC Web Feature Service (WFS) operations. The WFS operations support INSERT, UPDATE, DELETE, LOCK, QUERY and DISCOVERY operations on geographic features using HTTP as the distributed computing platform.

In the context of this document, a transaction is a logical unit of work that is composed of one or more data manipulation operations. Since the manner in which geographic features are persistently stored is not addressed in this document, no transaction semantics, such as atomic failure, are assumed to exist. It is the function of a web feature service, in its interaction with the data storage system used to persistently store features, to ensure that changes to data are consistent. However, the document also acknowledges the fact that many systems do support standard concurrent transaction semantics and so proposes optional operations that will allow a web feature service to take advantage of such systems (e.g. relational database systems based on SQL).

Geographic features

This document adopts the same concept of a geographic feature as described in the OGC Abstract Specification (http://www.opengeospatial.org/specs/?page=abstract) and interpreted in the OpenGIS® Geographic Markup Language(GML) Implementation Specification [2]. That is to say that the state of a geographic feature is described by a set of properties where each property can be thought of as a {name, type, value} tuple. The name and type of each feature property is determined by its type definition. Geographic features are those that may have at least one property that is geometry-valued. This, of course, also implies that features can be defined with no geometric properties at all.

Processing requests

This section of the document outlines, in general terms, the protocol to be followed in order to process web feature service requests. Processing requests would proceed as follows:

A client application would request a capabilities document from the WFS. Such a document contains a description of all the operations that the WFS supports and a list of all feature types that it can service. A client application (optionally) makes a request to a web feature service for the definition of one or more of the feature or element types that the WFS can service. Based on the definition of the feature type(s), the client application generates a request as specified in this document. The request is posted to a web server. The WFS is invoked to read and service the request. When the WFS has completed processing the request, it will generate a status report and hand it back to the client. In the event that an error has occurred, the status report will indicate that fact. Note that “client application” may include Registries and other middleware, as well as conventionally understood “end-users”.