GetCapabilities Response |
The capabilities document is composed of four main sections: Service, Capabilities, Feature Type List, Filter Capabilities .
The service section provides information about the service itself.
Table 1 Service section elements
| Element name | Description |
|
Name |
A name the service provider assigns to the web feature service instance. |
|
Title |
Service title. The <Title> is a human-readable title to briefly identify this server in menus. |
|
Abstract |
Service summary. The <Abstract> is a descriptive narrative for more information about the server. |
|
Keyword |
Keyword. The <Keyword> element contains short words to aid catalog searching. |
|
OnlineResource |
OnlineResource. The <OnlineResource> element defines the top-level HTTP URL of this service.Typically the URL of a "home page" for the service. |
|
Fees |
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. |
The capabilities section is used to specifically define the list of WFS operations that a particular WFS implements.
A basic WFS would include the GetCapabilities, DescribeFeatureType and the GetFeature operations. A transactional WFS would also include the Transaction operation, possibly the LockFeature operation and/or the GetFeatureWithLock operation.
Table 2 Web feature service operations
| 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. |
|
Transaction |
The <Transaction> element is included to define the available distributed computing platforms for this service |
|
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. |
|
LockFeature |
The <LockFeature> element is included to define the available distributed computing platforms. |
The only available distributed computing platform is HTTP, for which two request methods are defined; GET and POST. The onlineResource attribute indicates the URL prefix for HTTP GET requests (everything before the question mark and query string: http://hostname[:port]/path/scriptname); for HTTP POST requests, onlineResource is the complete URL.
The <VendorSpecificCapabilities> element can be defined to include vendor specific extensions.
This section defines the list of feature types provided by WFS and operations on each feature type. Additional information, such as SRS, about each feature type is also provided.
The purpose of the <FeatureTypeList> element is to contain a list of feature types that a WFS can service and define the transaction and query elements that are supported on each feature type.
Table 3 Transaction and Query Elements on Features
| Element | Description |
|
Insert |
Insert. The <Insert> element is used to indicate that the WFS is capable of creating new instances of a feature type. |
|
Update |
Update. The <Update> element indicates that the WFS can change the existing state of a feature. |
|
Delete |
Delete. The <Delete> element indicates that the WFS can delete or remove instances of a feature type from the datastore. |
|
Query |
Query. The <Query> element indicates that the WFS is capable of executing a query on a feature type. |
|
Lock |
Lock. The <Lock> element indicates that the WFS is capable of locking instances of a feature type. |
Transaction and query elements can be specified globally for all feature types or locally for each specific feature type contained in the <FeatureTypeList> element. Globally specified transaction and query elements are inherited by every feature type contained in the <FeatureTypeList> element and can be augmented by specifying local transaction and query elements. For example, the <Query> element may be specified globally for all feature types contained in the <FeatureTypeList>, but the <Update> element may only be specified locally for a small number of feature types. If no transaction or query elements are defined anywhere, then the default element <Query> will be implied for all feature types contained in the <FeatureTypeList> element.
The following elements can be used to describe each feature type contained in a <FeatureTypeList> element:
Table 4 Elements to describe feature types
| Element | Description |
|
Name |
Feature type name. The namespace qualified name of the feature type. This element is mandatory. |
|
Title |
Feature title. The <Title> is a human-readable title to briefly identify this feature type in menus. |
|
Abstract |
Abstract. The <Abstract> is a descriptive narrative for more information about the feature type. |
|
Keyword |
Keyword. The <Keyword> element contains short words to aid catalog searching. |
|
SRS |
SRS. The <SRS> element is used to indicate which spatial reference system should be used to express the state of a feature. The SRS may be indicated using either the Petrotechnical Open Software Corporation form ‘EPSG:<POSC Code>?or the URL format. SuperMap iServer currently supports POSC (EPSG:4326) format only. |
|
Operations |
Operations. The <Operations>element defines which are operations are supported on a feature type. Any locally defined operations take precedence over any globally defined operations. |
|
LatLongBoundingBox |
Bounding Box. The LatLongBoundingBox element is used to indicate the edges of an enclosing rectangle in the SRS of the associated feature type. Its purpose is to facilitate geographic searches by indicating where instances of the particular feature type exist. Since multiple LatLongBoundingBoxes can be specified, a WFS can indicate where various clusters of data may exist. |
|
MetadataURL |
This knowledge aids client applications by letting them know where they should query in order to have a high probability of finding data. A WFS may use zero or more <MetadataURL> elements to offer detailed, standardized metadata about the data in a particular feature type. The type attribute indicates the standard to which the metadata complies; the format attribute indicates how the metadata is structured. Two types are defined at present: 'TC211' = ISO TC211 19115; 'FGDC' = FGDC CSDGM. |
This is an optional section. If it exists, then the WFS should support the operations advertised therein. If the Filter Capabilities Section is not defined, then the client should assume that the server only supports the minimum default set of filter operators as defined in the Filter Encoding Implementation Specification.
The version attribute specifies the specification revision to which this schema applies. Its format is one, two or three integers separated by periods: "x", or "x.y", or "x.y.z", with the most significant number appearing first. Future revisions are guaranteed to be numbered in a monotonically increasing fashion, though gaps may appear in the sequence.
The updateSequence attribute is a sequence number for managing propagation of the contents of the capabilities document. For example, if a feature server adds some feature types, it can increment the update sequence to inform catalog servers that their previously cached versions are now stale. The format is a positive integer.
The response of the Request example is as follows: