Web Feature Service (WFS)

Abhinaya Sinha

{}

University of Minnesota- Twin Cities, Minneapolis, USA

Keywords: Geographic Markup Language (GML), Vector data, Raster data, Web Map Service

1

DEFINITION:

The Web Feature Service (WFS) is an interface specified by the Open GIS Consortium (OGC) that allows for the exchange of geographic data across the Web. It defines the rules for requesting and retrieving geographic information using the Hyper Text Transmission Protocol (HTTP). The interface describes the data manipulation operations on geographic features. Extensible Markup Language (XML) -based Geographic Markup Language (GML) is used for exchange of information.It should be noted that WFS supports the vector data model.

HISTORICAL BACKGROUND:

The Open GeoSpatial Consortium, Inc (OGC) has been instrumental in the formulation of the Web Feature Service. OGC is an international industry consortium of companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications. Regarding Web Services, OGC has specified web interfaces based on a model supporting request and response rules using Hyper Text Transmission Protocol (HTTP) and XML. The web feature service specification was first introduced in May 2002 when OGC released WFS 1.0. The latest version, WFS 1.1., was released in May 2005. Updates could be frequent as and when changes are made.

SCIENTIFIC FUNDAMENTALS:

Web Services is any software that makes itself available over the Internet and allows standard XML messaging protocol such as SOAP (Simple Object Access Protocol) as a messaging system.Since web services are based on simple and non-proprietarystandards, they promote interoperability as the transmitted information can be understood by machines independent of their underlying operating system, programming languages, development environments or their locationThe main idea of a web service is that it is possible for machines to publish information about the kind of services they offer and the parameters that need to be passed to them so that they can provide the promised services. A web service is based on a service-oriented architecture, as shown in figure 1. There are three fundamental operations: publish, find and bind. Service providers publish services to a service broker. Service requesters find the service and bind to them. This concept can be applied to geographic data. Hence, WFS is a specification whereby one machine (say, machine A) can request some other machine (say, machine B) for geographic information. The reason the machine requests information is that it does not have that information itself and hence must resort to some other machine to provide that information. Once A has the information it needs, it is now possible for A to use that information according to its requirement. This is possible because the supplied information is encoded in XML-based GML and hence, is machine independent. Since in this case, we are talking about geographic data, A would normally use this information to construct a map or add additional layers to a map that it already was capable of rendering. This is the most common way in which the services provided by a web feature server may be used. However, there are other ways of utilizing the web feature service.

Figure 1: Web Service and its Service-Oriented Architecture [4]

Features of WFS:WFS provides interfaces for describing data manipulation operations on geographic features. Data manipulation includes:

  1. Creating a new feature instance
  2. Deleting a feature instance
  3. Updating a feature instance
  4. Locking a feature instance
  5. Getting or querying features based on spatial and non-spatial constraints.

The first four interfaces have to do with supporting transactions while the last one is concerned with retrieving geospatial data.

Figure 2 shows the operations defined to support transaction and query processing, in the form of a UML interface diagram.

These operations can be described as follows:

1.GetCapabilities

The web feature service should describe its ‘capabilities’, that is, the feature types that the WFS can service as well as the operations defined on each of those feature types. When this request is made, the web feature server must return an XML document describing the feature types that it can service and the operations defined on each on them.

An example of a GetCapabilities request is given next:

SERVICE=WFS&

VERSION=1.0.0&

REQUEST=getcapabilities

2. Describe Feature Type

A Web Feature Service must be able to describe the structure of any feature type that it can service. The following example requests the schema description of the feature type TreesA_1M.

SERVICE=WFS&

VERSION=1.1.0&

REQUEST=DescribeFeatureType&

TYPENAME=TreesA_1M

3. GetFeature

A WFS returns the GML data associated with the features specified in this request. This is the request that is used by a client to get the geodata associated with features supported by the web feature server.

The example below gets geographic data associated with parks:

SERVICE=WFS&

VERSION=1.0.0&

REQUEST=getfeature&

TYPENAME=park

4. Transaction

A web feature service may be able to service transaction requests. Note that this feature is optional. Even if the service does not provide this capability, it still is a web feature service. Transaction requests are concerned with operations that modify features on the server such as create, update and delete operations on geographic features.

The following example deletes all feature instances identified by “RoadL_1M.1013”

SERVICE=WFS&

VERSION=1.1.0&

REQUEST=Transaction&

  1. GetGMLFeature

A web feature service may, optionally, be able to service a request to retrieve element instances by traversing XLinks that refer to their XML IDs. The requirement of the client is that it must specify whether nested XLinks embedded in returned element data should also be retrieved.

Types of Web Feature Services: It is not necessary that a Web Feature Service provide support for all the above operations. Accordingly, Web Feature Services can come in three flavors: Basic WFS, XLink WFS and Transactional WFS.

These three types of WFS are explained as follows:

Basic WFS: A basic WFS only allows querying and retrieval of features. That is, it supports the GetCapabilities, GetFeatureType and GetFeature type of requests. Since such a kind of web feature service supports reading of data only, it is also known as a ‘read-only’ server.

XLink WFS: In addition to supporting all the operations of a basic web service, an XLink WFS also provides the GetGmlObject operation.

Transaction WFS: A transactional WFS supports all the operations of a basic web server and in addition, it also implements the Transaction operation. A transactional WFS may, optionally, support the GetGmlObject operation as well.

Data: The Geographic Markup Language (GML) is used for encoding the information that passed between a client and a server. Thus, it is required that both the client and the server support and understand GML.

Comparison of Web Feature Service to Web Map Service:Although WFS is closely related to its cousin, the Web Map Service (WMS), there are significant differences. With WMS, the machine that requests some other machine for information gets a completely rendered map in return for its request. The requesting machine does not get raw data. It gets a readymade map which it merely displays. In contrast, in WFS, the requesting machine gets the raw data for the geographic feature it had requested. This means that geographic co-ordinate data such as line, point and polygon features are returned. It is the prerogative of the requesting machine to use the returned information in whatever manner it wants. The information is returned in the form of GML (Geographic Markup Language), the geographic cousin of XML. Hence,WFS is the means to get feature-level geospatial data and use this data to render a map. By feature-level geospatial data, we mean geographic coordinate data such as points, lines and polygon features. Hence, it is understood that a WFS request could potentially involve a large amount of data transmission from a server to a client. Although the client is required to do more work in terms of making use of the geospatial data, WFS offers the client more flexibility. For instance, a client may save the returned features to a usable data file. In contrast, a requesting WMS client gets the rendered map back with no opportunity to use the data in any other way. That is, it may or not display the rendered map. However, since it does not have the raw data associated with the map, it cannot store the data. Though WFS provides more freedom to a client to make use of geospatial data, the work of the client is increased as it must now make appropriate use of that data, without which the data is just “data” and not useful information. Therefore, both WMS and WFS are beneficial in their own way, depending on the need of the client.

Thus, a WFS request consists of a description of the data manipulation that is to be applied to one or more features. The client composes this request and sends it to the server over HTTP. The server (called the web feature server) reads the request and executes it.

Requirements of a Web Feature Server

There are some important requirements that a server must satisfy before it can claim to be a Web feature server.

  1. The interfaces must be defined in XML.
  2. The server must be able to encode the geographic information using the Geographic Markup Language (GML).
  3. The client should not be required to have knowledge of the datastore used to store the geographic features. The client’s only view of the data should be through the WFS interface.
  4. The predicate or filter language must be defined in XML and be derived for the Common Query Language (CQL) as defined in the OpenGIS Catalogue Interface Implementation Specification [2]
  5. A Web Feature Service must also be able to describe the structure of each feature type defined by it.
  6. It must be possible for a client to specify which feature properties to fetch and to do so using spatial and non-spatial constraints.

Sequence of events: Interaction between a web feature server and a client generally follows a sequence, as illustrated in figure 3.

The sequence works as follows:

  1. A client application would make a request for a capabilities document from the WFS. As the name suggests, this document gives a description of all the operations supported by the WFS as well as the feature types that it can service.
  2. Next the client may make a request to the WFS for the definition of one or more of the feature types that the WFS can service. This step is optional and can be safely omitted by the client if the parameters needed to be passed in a request are already known by the client.
  3. Based on the definition of the feature type(s), the client generates a request.
  4. Once the request reaches the web server, it invokes the WFS to read and service the request.
  5. The WFS processes the request. On completion of the request, the WFS will send a status report back to the client. It will also notify the client if an error occurred during processing.

KEY APPLICATIONS: The utility of Web Feature Service is not as visible as its illustrious cousin, the Web Map Service (WMS). This is because web feature service provides interfaces for querying and modifying geospatial information. Data is returned to the requesting client in the form of GML. The visibility and use of this data is realized only after it is rendered in the form of maps. However, it is clear that WFS provides the raw material (data) for the finished product (the rendered map). The tremendous utility of web feature service is that a requestor of information can choose to use the raw data in any number of ways. For instance, the client may store the data or display the data.

FUTURE DIRECTIONS: As Web Feature Services is a protocol, it is under constant review and changes. This is especially so because it is a protocol that deals with web services in the upcoming area of geospatial services. The latest specification as well as the ones before it can be found at the Open GeoSpatial Consortium (OGC) website (

CONCLUSION:A Web Feature Service is a set of interfaces specified by OGC that gives a web user the facility to combine, use and manage the feature information of map(s) from one or more sources. The goal is to promote interoperability. The utility of web feature service is that a client can retrieve and update geospatial data stored in GML. There are certain requirements that must be met by a Web Feature Service.The getCapabilities, getFeature and describeFeatureType operations must be met by every web feature service. WFS defines the interfaces in XML and features are expressed in the form of GML. WFS provides a lot of flexibility to a client in terms of working with geospatial data.

RECOMMENDED READING

1.OpenGeoSpatial Consortium (OGC) specification on Web Feature Service

(

2. Web Mapping Illustrated by Tyler Mitchell (O'Reilly Series)

3. Beginning MapServer: Open Source GIS Development by Bill Kropla (Apress Publications)

4. Mapping Hacks by Schuyler Erle, Rich Gibson, and Jo Walsh (O'Reilly Series)

5. MapServer website (

6.

1