Web Feature Service (WFS)
Abhinaya Sinha
{sinha@cs.umn.edu}
University of Minnesota- Twin Cities, Minneapolis, USA
Keywords: Geographic Markup Language (GML), Vector data, Raster data, Web
Map Service
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-proprietary
standards, they promote interoperability as the transmitted information can be understood
by machines independent of their underlying operating system, programming languages,
development environments or their location The 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
1
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.
«interface»
Web Feature Service
+getCapabilites()
+describeFeatureType()
+getFeature()
+getGmlObject()
+insertFeature()
+updateFeature()
+deleteFeature()
+lockFeature()
Figure 2:Operations supported
by a WFS
2
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:
http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?
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.
http://www.someserver.com/wfs.cgi?
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:
http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?
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”
http://www.someserver.com/wfs.cgi?
SERVICE=WFS&
VERSION=1.1.0&
REQUEST=Transaction&
3
5. 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
4
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.
5
WFS Client
WFS
GetCapabilities
Reply(1)
GetFeatureType
Reply(2)
Insert/Delete/Create Feature
GetGMLObject
Reply(3)
Figure 3: Sequence of events
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
6
as well as the ones before it can be found at the Open GeoSpatial Consortium (OGC)
website (http://www.openspatial.org)
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
(http://www.opengeospatial.org/docs/02-058.pdf)
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 (http://www.mapserver.gis.umn.edu)
6. http://ww.en.wikipedia.org
7