Web Feature Service

The Maxar Web Feature Service (WFS) defines a set of functions that clients may use to return actual Features with geometry and attributes that can be used in any type of geospatial analysis.

Any client making requests that conform to the OGC WFS specification can interact with the WFS server. Web-based client/server architecture is a typical example of the structure of a Web Feature Service application.

Typical Structure of a WFS Application

In a WFS scenario, the client application requests desired information from the Web Feature Service server. The WFS server retrieves the appropriate information from the Feature store, including vector metadata and imagery footprints, and responds to the request with this information in a GML format.

WFS Client-Server Architecture

The following architecture depicts a sample integration of WFS client and server applications. Client Viewer is a series of HTML pages running inside a web browser that can interact with the WFS server via client application through HTTPS calls. The WFS client manages the interactions with WFS interfaces through HTTPS requests and dynamically generates HTML that can run in a web browser.

The WFS server accepts requests from the WFS client and viewer client in the form of HTTPS URL strings, and returns results encoded as XML, GIF, GML, and so on. The database stores geo-feature data that can be accessed and utilized by the WFS server to generate GML documents or draw Maps.

Sample WFS Client Server Application

WFS Service Details

The Maxar WFS provides vector metadata, including imagery footprints, in Geographic Markup Language (GML) format. The Maxar WFS supports the following OGC-defined operations:

  • GetCapabilities The GetCapabilities request is used to determine the supported FeatureTypes.
  • DescribeFeatureType The DescribeFeatureType request is used to discover the properties available for a supported FeatureType.
  • GetFeature The GetFeature request is used to get the properties of one or more instances of a supported FeatureType.

The Maxar WFS categorizes Features as one of the following types:

  • FinishedFeature This Feature type provides users with access to all finished product data via a single Feature.
  • TileMatrixFeature This Feature type provides users with access to all of the available metadata, for all of the Feature instances that occur in a particular tile.
  • ImageInMosaicFeature This Feature type provides users with access to the seamline information that is available with mosaicked finished products.
  • MaxarCatalogMosaicProducts This Feature type provides users with access to Vivid Mosaic product metadata via a single Feature.

  • MaxarCatalogMosaicSeamlines This Feature type provides users with access to the seamline information that is available for each Vivid production block.

  • MaxarCatalogMosaicTiles This feature type provides users with access to information about Vivid Mosaic granules.

Integration Procedure

A WFS client application is a program that communicates with the WFS server using the three functions GetCapabilities, GetFeature and DescribeFeatureType, as noted earlier. More specifically, in a typical WFS client/server interaction, the following steps can be followed:

Step 1

The client first has to request GetCapabilities from the WFS server in order to determine what the WFS server can do and what Features the WFS server can provide.

Step 2

The client can request GetFeature with the WFS server's capabilities information in order to get the Feature information. Once a user has obtained a description of the supported FeatureType, the GetFeature request is used to access the metadata associated with one or more Feature instances. Subsets of Features can be obtained by providing filtering information in the request. Available filtering capability includes:

  • Filtering on a list of specific Feature IDs
  • Filtering based on a geographic area (Bounding Box)
  • Filtering based on Feature property values (e.g., only return Features with a Cloud Cover of less than 5%)

https://evwhs.digitalglobe.com/catalogservice/wfsaccess?SERVICE=WFS&REQUEST=GetFeature&maxFeatures=25&typeName=DigitalGlobe:FinishedFeature&VERSION=1.1.0&connectId=<CONNECTID>&BBOX=39.346038,-105.424805,40.131711,-104.545898

Note: Replace <CONNECTID> with the connectId provided by Maxar. Parameters are not required to be in the same order as shown above.

Step 3

To get the description of the supported FeatureType, the user can use the following URL:

https://evwhs.digitalglobe.com/catalogservice/wfsaccess?service=WFS&request=DescribeFeatureType&version=1.1.0&typeName=DigitalGlobe:FinishedFeature&connectId=<CONNECTID>

Note: Replace <CONNECTID> with the connectId provided by Maxar. Parameters are not required to be in the same order as shown above.

Service Exceptions

In the event that a Web Feature Service encounters an error while processing a request or receives an unrecognized request, it will generate an XML document indicating that an error has occurred.

An <ExceptionReport> element will contain one or more WFS processing exceptions specified using the <Exception> element. The mandatory version attribute is used to indicate the version of the service exception report schema. For this version of the specification, this value is fixed at 1.1.0. Individual exception messages are contained within the <ExceptionText> element.

The following is an example of an exception report. This exception indicates that the first insert statement failed because of a missing closing XML tag in the request.

Copy
<?xml version="1.0" ?>
<ExceptionReport version="1.1.0" xmlns="http://www.opengis.net/ogc"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="owsExceptionReport.xsd">
    <Exception code="999" locator="INSERT STMT 01">
        <ExceptionText>
            parse error: missing closing tag for element Geom
        </ExceptionText>
    </Exception>
</ExceptionReport>

API Reference

API reference gives the list of all possible request parameters for every WFS operation and detailed information about corresponding response.

The client should provide the respective information in a Key-Value Pair (KVP) format for every WFS request, where the "name" field is the key, and the "value" field is the value; the data is supplied in the format "key=value"; for example, "service=WFS".