Web Feature Service (WFS)

Overview

A Web Feature Service (WFS) allows a client to perform data manipulation operations on one or more geographic features. Data manipulation operations include the ability to Get or Query features based on spatial and non-spatial constraints, Create a new feature, Modify a feature, or Delete a feature.

A WFS is primarily a feature access service that also includes elements of a feature type service, a coordinate conversion/transformation service and a geographic format conversion service. WFS offers direct fine-grained access to geographic information at the feature and feature property level. However, Web Feature Services does not confer administrative rights over the data to WFS clients. Clients can only retrieve or modify the data of the specific feature(s) they are seeking; they cannot retrieve the complete file or underlying data store containing the feature data.

Additional Information

Standards

OpenGIS® Web Feature Service (WFS) Implementation Specification, and

OpenGIS® Web Feature Service 2.0 Interface Standard

Related Information

Web Map Service (WMS)

Geography Markup Language (GML)

Filter Encoding (FE)

Notes

The Web Feature Service Standard and Specification have been developed by the Open Geospatial Consortium (OGC).

The OpenGIS® Web Feature Service 2.0 Interface Standard is also published as ISO 19142:2010, Geographic Information – Web Feature Service ^{Footnote 1}.

Users may find the following OGC® tutorial useful: Using a Web Feature Service.

Additional Information: Web Feature Service (WFS)

WFS Operations

Classes of WFS

WFS Implementation

WFS Client Applications

WFS Operations

The Web Feature Service standard specifies the behaviourof a service that provides transactions on and access to geographic features in a manner independent of the underlying data store. It specifies 11 different operations, grouped as discovery operations, query operations, locking operations, transaction operations and operations to manage stored parameterized query expressions.

NOTE: The WFS standard does not address access control issues.

Discovery operations allow the service to be interrogated to determine its capabilities and to retrieve the application schema that defines the feature types that the service offers:

• GetCapabilities: A WFS 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 WFS must be able, upon request, to describe the structure of any feature type it can service.

Query operations allow features or values of feature properties to be retrieved from the underlying data store based upon constraints on feature properties, defined by the client. 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:

• GetPropertyValue
• GetFeature
• GetFeatureWithLock (query & locking operation)

Locking operations allow a lock request on one or more instances of a feature type for the duration of a transaction, to ensure that serializable transactions are supported:

• LockFeature

Transaction operations that service transaction requests, are composed of operations that modify features, i.e. create, update, or delete operations on geographic features:

• Transaction

Stored query operations allow clients to create, drop, list and describe parameterized query expressions that are stored by the server, and can be repeatedly invoked using different parameter values:

• CreateStoredQuery
• DropStoredQuery
• ListStoredQueries
• DescribeStoredQueries

Classes of WFS

Based on these operational descriptions, three classes of Web Feature Services can be defined:

• Basic WFS, or WFS-Basic: implements the GetCapabilities, DescribeFeatureType and GetFeature operations. This is considered a READ-ONLY Web Feature Service;
• XLink WFS: supports all the operations of a WFS-Basic, plus it implements the GetGmlObject operation for local and/or remote XLinks, and offers the option for the GetGmlObject operation to be performed during GetFeature operations; and
• Transaction WFS, or WFS-T: supports all the operations of a WFS-Basic, plus it implements the Transaction operation. Optionally, a WFS-T can also implement the GetGmlObject and/or LockFeature operations.

WFS Implementation

When software vendors implement their products in compliance with an open geospatial web service interface and data encoding specifications, end-users benefit from a larger pool of inter-operable web-based tools for geodata access and related geo-processing services.

The OGC® Web Map Service (WMS) products that have been developed to implement the international standard are prime examples of such tools. The GetCapabilities and GetMap interfaces defined in that specification give users on the web an interoperable way to combine and view map images from different sources. And the GetFeatureInfo interface gives those users a way to obtain attribute information about geographic features displayed in a map with a simple mouse click.

The OGC® Geography Markup Language (GML) Implementation Specification describes an encoding specification for geodata in XML that enables the storage, transport, processing, and transformation of geographic information. 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.

The WFS takes the next logical step by defining interfaces for data access and manipulation operations on geographic features using HTTP as the distributed computing platform. Via these interfaces, a web user or service can combine, use and manage geodata – the feature information behind a map image – from different sources by invoking the following WFS operations on geographic features and elements:

• Create a new feature instance,
• Delete a feature instance,
• Update a feature instance,
• Lock a feature instance, or
• Get or query features based on spatial and non-spatial constraints.

The Web Map Service (WMS) allows a client to overlay map images for display served from multiple Web Map Services on the Internet (often referred to as “mash-ups”). Similarly, the WFS allows a client to retrieve and update geospatial data encoded in Geography Markup Language (GML) from multiple Web Feature Services. The retrieval process can be made more selective by using Filter Encoding (FE).

WFS Client Applications

For WFS, a transaction is a logical unit of work that is composed of one or more data manipulation operations. It is the function of a Web Feature Service, in its interaction with the developer’s data storage system, to ensure that any changes to data are consistent. However, many systems do support standard concurrent transaction semantics, so optional operations will allow a Web Feature Service to take advantage of such systems (e.g. relational database systems based on SQL).

In general terms, here is the protocol to be followed to process web feature service requests:

1. A client application requests 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.
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 for 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”.