WFS 实现说明（Web Feature Service Implementation Specification）

这是摘自官网的文档中

Web Feature Service Implementation Specification

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 . 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:
1. 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.
2. 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.

3. Based on the definition of the feature type(s), the client application generates a request as specified in this document.
4. The request is posted to a web server.
5. The WFS is invoked to read and service the request.
6. 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”.

Operations
To support transaction and query processing, the following operations are defined:

GetCapabilities
A web feature service must be able to describe its capabilities. Specifically, it must indicate which feature types it can service and what operations are supported on each feature type.
DescribeFeatureType
A web feature service must be able, upon request, to describe the structure of any feature type it can service.

GetFeature
A web feature service must be able to service a request to retrieve feature instances. In addition, the client should be able to specify which feature properties to fetch and should be able to constrain the query spatially and non-spatially.

GetGmlObject
A web feature service may be able to service a request to retrieve element instances by traversing XLinks that refer to their XML IDs. In addition, the client should be able to specify whether nested XLinks embedded in returned element data should also be retrieved.

Transaction
A web feature service may be able to service transaction requests. A transaction request is composed of operations that modify features; that is create, update, and delete operations on geographic features.

LockFeature
A web feature service may be able to process a lock request on one or more instances of a feature type for the duration of a transaction. This ensures that serializable transactions are supported.

Based on the operation descriptions above, three classes of web feature services can be defined:
Basic WFS
A basic WFS would implement the GetCapabilities, DescribeFeatureType and GetFeature operations. This would be considered a READ-ONLY web feature service.
XLink WFS
An XLink WFS would support all the operations of a basic web feature service and in addition it would implement the GetGmlObject operation for local and/or remote XLinks, and offer the option for the GetGmlObject operation to be performed during GetFeature operations.
Transaction WFS
A transaction web feature service would support all the operations of a basic web feature service and in addition it would implement the Transaction operation. Optionally, a transaction WFS could implement the GetGmlObject and/or LockFeature operations.