WFS - Capabilities

Generating WFS-Capabilities Document on the Fly

I – Capabilities Document - Definitions

Each WFS generates a document to describe its capabilities. A WFS Capabilities document is composed of four main sections:

1. Service section

This part provides information about the service itself. This section can be considered as metadata about the WFS and includes following sub elements:

ELEMENT NAME	DESCRIPTION
Name	A name the service provider assigns to the web feature service instance.
Title	The <Title> is a human-readable title to briefly identify this server in menus.
Abstract	The <Abstract> is a descriptive narrative for more information about the server.
Keyword	The <Keyword> element contains short words to aid catalog searching.
OnlineResource	The <OnlineResource> element defines the top-level HTTP URL of this service. Typically the URL of a "home page" for the service.
Fees	The <Fees> element contains a text block indicating any fees imposed by the service provider for usage of the service or for data retrieved from the WFS. The keyword NONE is reserved to mean no fees.
AccessConstraints	The <AccessConstraints> element constain a text block describing any access constraints imposed by the service provider on the WFS or data retrieved from that service. The keyword NONE is reserved to indicate no access constraints are imposed.

(Table 1 – OGC WFS Spec 1.0 p54

<Name>OGC WFS implemented as WS</Name>

<Abstract>A WSDL interface is provided for the clients.</Abstract>

<OnlineResource>http://gf1.ucs.indiana.edu:7070/axis/services/wfs

</OnlineResource>

<Fees>No fees assigned</Fees>

</Service>

Since our implementation is based on WSDL-SOAP we include the Web Service address as the only online resource.

2. Capabilities Section

This section describes the operations WFS supports. A basic WFS would support GetCapabilities, DescribeFeatureType and the GetFeature operations. Our current implementation supports all three.

ELEMENT NAME	DESCRIPTION
GetCapabilities	The <GetCapabilities> element is included to define the available distributed computing platforms for this service.
DescribeFeatureType	The <DescribeFeatureType> element is used to define the available distributed computing platforms for this service and indicate what schema description languages can be used to describe the schema of a feature type when a client requests such a description. XMLSCHEMA is the only mandatory language that must be available. The SCHEMALANGUAGES entity can be redefined to include vendor specific languages.
GetFeature	The <GetFeature> element is used to define the available distributed computing platforms for this service and enumerate the formats available for expressing the results of a query. The RESULTFORMATS entity defines the mandatory output format of GML but can be redefined to include additional vendor specific formats.

(Table 2 – OGC WFS Spec 1.0 p55)

This section may also include the <VendorSpecificCapabilities> element which can be used to define vendor specific extensions.

For a straightforward WFS implementation any one of the above operations in this section would include a DCPType element to define urls for HTTP GET and HTTP POST requests, for instance:

<HTTP>

</HTTP>

</DCPType>

However since our implementation is different we assign the WSDL address to the Post and Get elements. A future OGC WFS Schema should consider the usage of Web Services as well so that we can have an element to define the Web Service URL. In this case our DCPType element looks like the following

<HTTP>

</HTTP>

</DCPType>

A sample capabilities section is shown here:

<HTTP>

</HTTP>

</DCPType>

</GetCapabilities>

</SchemaDescriptionLanguage>

<HTTP>

</HTTP>

</DCPType>

</DescribeFeatureType>

<GML2/>

</ResultFormat>

<HTTP>

</HTTP>

</DCPType>

</GetFeature>

</Request>

CGL is providing a test version of WSDL

interface to WFS. Please use the WSDL

address provided in onlineResource elements.

</VendorSpecificCapabilities>

</Capability>

3. FeatureTypeList section

This section contains a list of feature types that the WFS can service and define the transaction and query elements that are supported on each feature type. The possible transaction and query elements are:

ELEMENT NAME	DESCRIPTION
Insert	The <Insert> element is used to indicate that the WFS is capable of creating new instances of a feature type.
Update	The <Update> element indicates that the WFS can change the existing state of a feature.
Delete	The <Delete> element indicates that the WFS can delete or remove instances of a feature type from the datastore.
Query	The <Query> element indicates that the WFS is capable of executing a query on a feature type.
Lock	The <Lock> element indicates that the WFS is capable of locking instances of a feature type.

Table 3 – Transaction and Query Elements on Features (OGC WFS Spec 1.0 p55)

This section basically lists all the geographic features that can be reached using this particular WFS.

For each feature type supported transaction and query elements (table 3) must be defined. If none of them is defined then the default element <Query> will be implied for all feature types. (OGC WFS Spec 1.0 p56)

The critical point in inserting information about supported feature types into the Capabilities document is making sure that the Data Store that provides this particular feature type is alive.

In our implementation each feature type has a config file that resides in the server which contains information to connect the feature’s database etc. Using this config file the WFS connects to the various databases that provides the features and retrieves the most current information like minx, miny etc. This way whenever a Capabilities document is requested only the available ones are listed inside the <FeatureTypeList> element.

A sample FeatureTypeList section is given here

<Name>rivers</Name>

<Title>California Rivers Feature Type</Title>

A Feature that has coordinate

information of california rivers.

</Abstract>

<Keywords>California,River,Rivers,WFS</Keywords>

</Operations>

<LatLongBoundingBox

minx="-124.287781"

miny="35.156409999999994"

maxx="-118.074822"

maxy="41.56559999999999"/>

http://complexity.ucs.indiana.edu:6060/wfs/index.htm

</MetadataURL>

</FeatureType>

<Name>Fault</Name>

<Title>California Fault data</Title>

California Fault lines data,

names, coordinates of the

segments etc.

</Abstract>

<Keywords>California,Fault,Segment,WFS</Keywords>

</Operations>

<LatLongBoundingBox

minx="0"

miny="-124.41000366211"

maxx="40.200000762939"

maxy="0"/>

http://complexity.ucs.indiana.edu:6060/wfs/index.htm

</MetadataURL>

</FeatureType>

</FeatureTypeList>

II – Implementing GetCapabilities request and response

A typical GetCapabilities request is like the following:

<?xml version="1.0" encoding="ISO-8859-1"?>

In response to this request the WFS should generate a Capabilities document which contains the elements discussed in the previous section.

We have developed several schemas and user interfaces to record necessary metadata about the WFS and the supported feature types to make it easy to generate a Capabilities document. In this section some of these interfaces and XML Schemas are discussed.

1. WFS Metadata

As explained in the Service element Capabilities document contains metadata about the WFS. We have created an XML Schema for collecting WFS metadata from the Service administrators.

We use Castor Data Binding Framework to generate source codes from the schemas which then used for Data Binding. We generate user interfaces to collect required information from the users and then use source code generated by Castor to create XML files that contain this information. The XML files are easily marshaled or un-marshaled by Castor.

The user interface and a sample WFS Metadata XML file are shown below:

Figure – Admin interface for entering WFS Metadata

<?xml version="1.0" encoding="UTF-8"?>

<wfs_config>

<Name>Web Feature Service No 3 in CGL</Name>

This Web Feature Service provides

3 feature types. To add new feature

types use the admin interfaces.

</Abstract>

<Keywords>WFS, OGC, Web Services</Keywords>

http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl

</OnlineResource>

</Service>

</wfs_config>

WFS Metadata file generated from the Admin input

2. WFS Capabilities

Since our implementation is based on Web Services approach we don’t provide HTTP Post and Get URLs. Instead a WSDL address is given as the <onlineResource> element. A WFS user (A graphical client or a WMS etc.) only needs this address to generate the client stub from the WSDL.

3. FeatureTypeList

This is perhaps the most important part of the Capabilities document. A WFS should provide an up do date list of the feature types that can be serviced.

Features are stored in various formats and in different data stores. The most common way to store the data is to use a relational database like MySQL, but GML Files or Native XML Databases (like Berkeley DB XML or Xindice) are other storage options. Our current implementation supports data retrieval only from MySQL databases using JDBC , other data store types will also be supported in future versions.

We have created a XML Schema to encapsulate required information for defining a feature type. Since the feature data reside on databases this schema also contains database connection information. We have admin-user interfaces for creating and editing feature metadata info. As in the WFS metadata interface gathered data are used to create xml files which are called ‘feature configuration file”.

Admin uses this interface to add a new feature type to the WFS inventory. After all information about the feature is successfully entered and the config file is created the WFS provides information about this feature inside its Capabilities document.

The user interface for adding a new feature to the WFS’s interface is shown in the following picture:

The feature configuration file created from the admin input is shown here:

<?xml version="1.0" encoding="UTF-8"?>

<db>

<type>mySQL</type>

<serveraddress>gf8.ucs.indiana.edu</serveraddress>

<name>SEGMENT</name>

<driver>com.mysql.jdbc.Driver</driver>

<username>galip</username>

<password>dbpassword</password>

</db>

<xml_instance>

C:/Projects/WFS/xml/galip/faultinstance.xml

</localaddress>

</xml_instance>

<map_file>

C:/Projects/WFS/xml/galip/mapfault.xml

</localaddress>

</map_file>

C:/Projects/WFS/xml/schemas/fault_gml2.xsd

</localaddress>

</xmlschema>

<maxmin_column_names>

<minx>LatStart</minx>

<miny>LatStart</miny>

<maxx>LonStart</maxx>

<maxy>LonEnd</maxy>

</maxmin_column_names>

<Name>fault</Name>

<Title>California Fault data</Title>

California Fault data. MySQL database

is provided by USC. More information

about the data can be found here:
http://grids.ucs.indiana.edu/~gaydin/servo/index_seismicity.htm

</Abstract>

<Keywords>California,Fault,Segment,WFS</Keywords>

</Operations>

<MetadataURL>http://www.opengis.org</MetadataURL>

</Metadata>

</feature>

When the WFS receives a GetCapabilities request it checks the config files directory. This directory contains config files for all supported feature types. The WFS extracts the connection information from the files and tests to see if the Databases are alive. If the connection attempt for a particular feature type fails then it is not included in the Capabilities document’s FeatureTypeList element. Otherwise the feature list is constructed by getting the required data from the feature config file.

Complete Capabilities Document

A sample capabilities document that contains all the elements discussed in this text is shown here:

<?xml version="1.0" encoding="UTF-8"?>

<WFS_Capabilities xmlns="http://www.opengis.net/wfs" version="1.0.0">

<Name>OGC WFS implemented as WS</Name>

A WSDL interface is provided for the clients.

</Abstract>

http://gf1.ucs.indiana.edu:7070/axis/services/wfs

</OnlineResource>

<Fees>No fees assigned</Fees>

</Service>

<HTTP>

</HTTP>

</DCPType>

</GetCapabilities>

</SchemaDescriptionLanguage>

<HTTP>

</HTTP>

</DCPType>

</DescribeFeatureType>

<GML2/>

</ResultFormat>

<HTTP>

</HTTP>

</DCPType>

</GetFeature>

</Request>

CGL is providing a test version of WSDL

interface to WFS. Please use the WSDL

address provided in onlineResource elements.

</VendorSpecificCapabilities>

</Capability>

<Name>rivers</Name>

<Title>California Rivers Feature Type</Title>

A Feature that has coordinate

information of california rivers.

</Abstract>

<Keywords>California,River,Rivers,WFS</Keywords>

</Operations>

<LatLongBoundingBox

minx="-124.287781"

miny="35.156409999999994"

maxx="-118.074822"

maxy="41.56559999999999"/>

http://complexity.ucs.indiana.edu:6060/wfs/index.htm

</MetadataURL>

</FeatureType>

<Name>Fault</Name>

<Title>California Fault data</Title>

California Fault data. MySQL database

is provided by USC. More information

about the data can be found here:
http://grids.ucs.indiana.edu/~gaydin/servo/index_seismicity.htm

</Abstract>

<Keywords>California,Fault,Segment,WFS</Keywords>

</Operations>

<LatLongBoundingBox

minx="0"

miny="-124.41000366211"

maxx="40.200000762939"

maxy="0"/>

http://complexity.ucs.indiana.edu:6060/wfs/index.htm

</MetadataURL>

</FeatureType>

</FeatureTypeList>

<Filter_Capabilities>

<Spatial_Capabilities>

<Spatial_Operators>

<BBOX/>

</Spatial_Operators>

</Spatial_Capabilities>

<Scalar_Capabilities>

<Arithmetic_Operators>

<Simple_Arithmetic/>

</Arithmetic_Operators>

</Scalar_Capabilities>

</Filter_Capabilities>

</WFS_Capabilities>