WFS Filter Capabilities and Limitations

Title page

WFS Filter Capabilities and Limitations

Overview

Continuing on the "Map Service Capabilities" Wiki entry found here, a more in-depth look at Web Feature Services (WFS) is necessary to fully evaluate the capabilities of filtering records.

Introduction

One of the WFS Services that has been stood up at the NGA Gateway is a sample placenames service, built using a full Geonames data file. This produced a service that makes available over six million features. As such, the response time from the server, when returning all the features was, in a word, slow. When many large queries are executed they may block and prevent shorter queries from executing until completion of the excessively long queries. In addition, large responses can hang a client viewer. In order to speed up the response time from the server, a look into the filter capabilities of WFS was necessary.

Evaluation

There were several locations where filters could be placed in order to limit the amount of records returned by a WFS request. Most clients, like ArcIMS, have several built-in ways to set limits to the number of requested features when making GET_FEATURES requests.


 * Setting a global feature limit.
 * Setting feature limits in a map configuration file.
 * Requesting a specified number of features.

Setting a global feature limit
A global feature limit can be set in the Spatial Server configuration files limiting the number of requested features from all layers in all services. By default, the feature limit is 2000 for queries made to Image and ArcMap Image Services, however, no upper limit is set for Feature Services.

Setting feature limits in a map configuration file
If you do not wish to set a global limit on the number of features returned, or you want to refine the feature limit, it is possible to set limits on a layer by layer basis for Feature Services.

Setting a feature limit in a configuration file is implemented via the SPATIALQUERY element.

Requesting a specified number of features
The third way in which the number of features can be limited is to set a feature limit when requesting data from a client. In many cases, you may want to limit the number of returned features to something manageable. For example, you many want to return only 10 records at a time and allow users to page for the next or previous 10 records.

Feature limit hierarchy
The hierarchy for all the feature limit settings are as follows:

1. The feature limit in the Spatial Server configuration files is the maximum that can ever be returned in one request. For example, you never get more than 2000 records because of the feature limit (or whatever the limit is currently set).

2. SPATIALQUERY featurelimit in a map configuration file overrides the value in #1 if it is smaller.

3. GET_FEATURES featurelimit overrides the values in #1 and #2 if it is smaller.

4. In a GET_FEATURES request, SPATIALQUERY featurelimit overrides GET_FEATURES featurelimit. In both elements, the feature limit must be smaller than #1 or #2, or it is ignored.

Additionally, the use of the filter in a WFS GetFeature request can be used.

OGC Filter Implementation

One of the challenges with implementing OGC WFS is to be able to create and parse XML documents that contain Filters. Filters are used to define constraints on a query.

GetFeature requests contain  < Query >  element which in turn may contain  < Filter >  element to constraint the query. If no  < Filter >  element is contained in  < Query >  than the query is unconstrained and all feature instances should be retrieved.

According to the WFS Specification, Filters can be used to specify both spatial and/or non-spatial constraints in a query; however, our initial forays into using the filter in a WFS request have been unsuccessful in combining spatial and non-spatial constraints. A look at the filter schemas may provide insight as to why.

A Filter may include an operation element in one of the following three operation types:

1. Spatial Operations

2. Comparison Operations

3. Logic Operations

These operation types are defined as substitution groups in Filter Schema as following picture shows:

The picture tells us that at any given time a Filter may have one element from one of the three groups and any sub element under these groups may substitute each other.

In the following version of the schema the Filter has a choice which in turn has three choices that correspond to three substitution groups in the original schema. This may be why the filter has a problem when trying to implement two different types of operations (i.e. one choice from spatialOpsChoice and one choice from comparisonOpsChoice).

Conclusion

Further investigation is needed as to why the filter operation on a WFS request is only honoring one of the filter choices. As results are compiled and limitations overcome, those will in turn be posted to the development Wiki.