Generating Capabilities Document On the Fly

From CrisisGridWiki

Contents

Capabilities Document - Definitions

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

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)
 
<Service>
        <Name>OGC WFS implemented as WS</Name>
        <Title>CGL WFS no 1</Title>
        <Abstract>A WSDL interface is provided for the clients.</Abstract>
        <Keywords>WFS,OGC,WS,WSDL</Keywords>
        <OnlineResource>http://gf1.ucs.indiana.edu:7070/axis/services/wfs
        </OnlineResource>
        <Fees>No fees assigned</Fees>
        <AccessConstraints>WSDL,SOAP</AccessConstraints>
</Service>

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

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:

<DCPType>
  <HTTP>
       <Post onlineResource="http://127.0.0.1:8080/deegreewfs/wfs"/>
       <Get onlineResource="http://127.0.0.1:8080/deegreewfs/wfs"/>
  </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

<DCPType>
   <HTTP>
     <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
     <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
   </HTTP>
</DCPType>

A sample capabilities section is shown here:

<Capability>
 <Request>
   <GetCapabilities>
    <DCPType>
      <HTTP>
        <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
        <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
      </HTTP>
    </DCPType>
   </GetCapabilities>
   <DescribeFeatureType>
       <SchemaDescriptionLanguage>
           <XMLSCHEMA/>
       </SchemaDescriptionLanguage>
       <DCPType>
         <HTTP>
          <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
          <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
        </HTTP>
       </DCPType>
   </DescribeFeatureType>
   <GetFeature>
       <ResultFormat>
         <GML2/>
       </ResultFormat>
       <DCPType>
         <HTTP>
           <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
           <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>
         </HTTP>
       </DCPType>
   </GetFeature>
 </Request>
 <VendorSpecificCapabilities>
       CGL is providing a test version of WSDL
       interface to WFS. Please use the WSDL
       address provided in onlineResource elements.
 </VendorSpecificCapabilities>
</Capability>

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

<FeatureTypeList>
 <FeatureType>
    <Name>rivers</Name>
    <Title>California Rivers Feature Type</Title>
    <Abstract>
      A Feature that has coordinate
      information of california rivers.
    </Abstract>
    <Keywords>California,River,Rivers,WFS</Keywords>
    <SRS>null</SRS>
    <Operations>
       <Insert/>
       <Delete/>
       <Query/>
       <Update/>
    </Operations>
    <LatLongBoundingBox 
         minx="-124.287781" 
         miny="35.156409999999994"
         maxx="-118.074822"
         maxy="41.56559999999999"/>
    <MetadataURL type="0" format="txt">
         http://complexity.ucs.indiana.edu:6060/wfs/index.htm
    </MetadataURL>
 </FeatureType>
 <FeatureType>
    <Name>Fault</Name>
    <Title>California Fault data</Title>
    <Abstract>
        California Fault lines data,
        names, coordinates of the
        segments etc.
     </Abstract>
    <Keywords>California,Fault,Segment,WFS</Keywords>
    <SRS>null</SRS>
    <Operations>
       <Insert/>
       <Delete/>
       <Query/>
       <Update/>
    </Operations>
    <LatLongBoundingBox
      minx="0"
      miny="-124.41000366211"
      maxx="40.200000762939"
      maxy="0"/>
    <MetadataURL type="0" format="txt">
        http://complexity.ucs.indiana.edu:6060/wfs/index.htm
    </MetadataURL>
 </FeatureType>
</FeatureTypeList>

Implementing GetCapabilities request and response

A typical GetCapabilities request is like the following:

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

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.

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:

Image:Wfs md.jpg Figure – Admin interface for entering WFS Metadata

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

<wfs_config>

  <Service>

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

    <Title>WFS-NO3</Title>

    <Abstract>

This Web Feature Service provides

3 feature types. To add new feature

types use the admin interfaces.

    </Abstract>

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

    <OnlineResource>

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

    </OnlineResource>

    <Fees>None</Fees>

    <AccessConstraints>None</AccessConstraints>

    <VendorSpecificCapabilities>WSDL-SOAP</VendorSpecificCapabilities>

  </Service>

</wfs_config>
WFS Metadata file generated from the Admin input

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.

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: Image:Addfeature final.jpg

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

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

<feature>

  <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>

    <localaddress>

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

    </localaddress>

  </xml_instance>

  <map_file>

    <localaddress>

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

    </localaddress>

  </map_file>

  <xmlschema>

    <localaddress>

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>

  <Metadata>

    <Name>fault</Name>

    <Title>California Fault data</Title>

    <Abstract>

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>

    <SRS>SRS123</SRS>

    <Operations>

      <Operation type="Query"/>

      <Operation type="Insert"/>

      <Operation type="Update"/>

      <Operation type="Delete"/>

    </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">

<Service>

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

   <Title>CGL WFS no 1</Title>

   <Abstract>

      A WSDL interface is provided for the clients.

   </Abstract>

   <Keywords>WFS,OGC,WS,WSDL</Keywords>

   <OnlineResource>

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

   </OnlineResource>

   <Fees>No fees assigned</Fees>

   <AccessConstraints>WSDL,SOAP</AccessConstraints>

</Service>

<Capability>

 <Request>

   <GetCapabilities>

    <DCPType>

      <HTTP>

        <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>

        <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>

      </HTTP>

    </DCPType>

   </GetCapabilities>

   <DescribeFeatureType>

      <SchemaDescriptionLanguage>

          <XMLSCHEMA/>

      </SchemaDescriptionLanguage>

      <DCPType>

         <HTTP>

         <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>

         <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>

       </HTTP>

      </DCPType>

   </DescribeFeatureType>

   <GetFeature>

      <ResultFormat>

        <GML2/>

      </ResultFormat>

      <DCPType>

        <HTTP>

          <Get onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>

          <Post onlineResource="http://gf1.ucs.indiana.edu:7070/axis/services/wfs?wsdl"/>

        </HTTP>

      </DCPType>

   </GetFeature>

 </Request>

 <VendorSpecificCapabilities>

      CGL is providing a test version of WSDL

      interface to WFS. Please use the WSDL

      address provided in onlineResource elements.

 </VendorSpecificCapabilities>

</Capability>

<FeatureTypeList>

 <FeatureType>

    <Name>rivers</Name>

    <Title>California Rivers Feature Type</Title>

    <Abstract>

A Feature that has coordinate

information of california rivers.

    </Abstract>

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

    <SRS>null</SRS>

    <Operations>

       <Insert/>

       <Delete/>

       <Query/>

       <Update/>

    </Operations>

    <LatLongBoundingBox

minx="-124.287781"

miny="35.156409999999994"

maxx="-118.074822"

maxy="41.56559999999999"/>

    <MetadataURL type="0" format="txt">

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

    </MetadataURL>

 </FeatureType>

 <FeatureType>

    <Name>Fault</Name>

    <Title>California Fault data</Title>

    <Abstract>

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>

    <SRS>null</SRS>

    <Operations>

       <Insert/>

       <Delete/>

       <Query/>

       <Update/>

    </Operations>
    <LatLongBoundingBox
minx="0"
miny="-124.41000366211"
maxx="40.200000762939"
maxy="0"/>
    <MetadataURL type="0" format="txt">
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>
Project Contact Information