What is a Filter Expression A filter expression is portion of an XML document that specifies a

Querying Datasets is much like using a Spatial Database

A Filter is an XML element used to constrain responses. It is the subject of a whole companion specification to the WFS spec, available (link). It is a separate specification as it can be used by any service that needs a way to express predicates in XML. It specifies constraints based on properties of the objects requested to limit the number of objects returned. For those who know SQL, it is basically an XML representation of a WHERE clause. Filter includes both geometric and non-geometric operations, making it just like querying a spatial database.

Using a Filter

Using a Filter one can ask for things like:

• All freeways with less than 5 lanes.
• Any stream within a bounding box of 10,10,30,30
• Only plots of land with area greater than or equal to 500 acres.
• Fields with yield of greater than 200 bushels a year
• All cities that start with the letter 'C'
• Only walls are between 6 and 10 feet tall.
• All streams that cross a given road.
• The road with the feature identifier road.3532
• Any feature updated after December 15, 2002.

These can be combined with Logic operators for even more complex queries:

• All freeways with less than five lanes and speed limits over 55.
• Any city that starts with the letter C or D, that does not end with a Y.
• All streams that cross a given road.
• Any feature updated after December 15, 2002 that was edited by cholmes.

And there is no limit to the logic:

• Give me all roads of less than five lanes and speed limits over 45 that start with C or D, created by cholmes and updated between december 15 and 25, that fall in this polygon.

The Filter spec groups some of these possible requests together, into Spatial, Comparison, Logic, and FeatureId.

Spatial Filters

Spatial operators are only used against geometries, returning whether a geometry satisfies a given spatial relationship. These are the same as in the Simple Features for SQL specification, more details can be found in it (link). They are:
Equals, Disjoint, Touches, Within, Overlaps, Crosses, Intersects, Contains, DWithin, Beyond, and BBOX.

DWithin and Beyond both take an additional argument of Distance, they specify being in and outside of a certain distance from the given geometry. And BBOX is also a special case, as it is just a shortcut for Intersect, against a bounding box specified with just the lower left and upper right coordinates, instead of having to write the whole polygon.

One final source of confusion is the Intersect(s) Filter. And the authors are extremely annoyed that the OGC didn't bother to fix this confusion for the new 1.1 version of the specification. The confusion stems from the fact that in the Capabilities document it is specified as 'Intersect' (with no s), but for the actual request it is specified as 'Intersects'. For all other filters the way they are written in the Capabilities document is exactly as they are specified. It's likely just a typo, but it's an annoying one. In GeoServer we just decided to let clients specify it either way. The official way, as measured by the CITE conformance tests (link), and indeed the xml schemas, is 'Intersects' to make the request.

Comparison Filters

Comparison operators are only against non-geometry attributes. For most operations these can be numbers, strings, dates, times, and more - in short anything that can be ordered in two dimensions in some way. There are six 'simple' comparisons that Filters can support, PropertyIsEqualTo (=), PropertyIsNotEqualTo (<>), PropertyIsLessThan (<), PropertyIsGreaterThan (>), PropertyIsLessThanOrEqualTo (<=), PropertyIsGreaterThanOrEqualTo (>=). There are three more complex ones, PropertyIsNull checks to see if the value of the property to examine is NULL (0 is not null for this operation). PropertyIsBetween is basically a shortcut for value1 <= x <= value2. The values are specified with UpperBounds and LowerBounds. PropertyIsLike is limited to Strings, as it does pattern matching againt the characters contained in the String. The way to specify the pattern is given with the attributes for the Filter - wildCard matches 0 or more characters, singleChar matches exactly one character, and escapeChar is used to escape (cancel) the meaning of the wildCard, the singleChar, and the escapeChar itself (so that you can actually use the characters your using for your special characters).

Logic Filters

The Logical operators are pretty self explanatory - AND, OR and NOT. If both of two conditions must be true, use an AND, if either one of two conditions must be true, use a OR. And if the opposite of a condition must be true, use a NOT. These in turn can be combined in all sorts of ways.

Feature Identifiers.

The WFS specification implies that all features must have a unique, persistent 'featureId' that can be used to refer to the specific feature. The FeatureId filter is used to refer to one or more specific features based on their FeatureId.

Expressions

The expression concept is a little more slippery than a Filter. Filters are composed of Expressions, but Expressions themselves can be made up of Expressions. So whenever an expression is needed it is basically just a place holder for 'something'.

That something can be a Literal (a geometry, a number, a string, a date, ect.), or it can specify the PropertyName of a feature. Or it can be something more complex like the result of an Arithmetic operation (<Add>, <Div>, <Mul>, <Sub>), or a defined Function.

Literal and PropertyName

These are the most basic units of Expressions and Filters, all must ultimately composed by one of the two. A PropertyName specifies the property of a Feature to be evaluated. And a Literal is a set value to be evaluated. So in the filter 'all features with a length under 12', length would be the PropertyName of the feature to evaluate, and 12 would be the literal. The possible PropertyName values are based on the structure of the Feature, as delivered by the DescribeFeatureType response (the XML schema). If a PropertyName that is not part of the Feature is requested it will return an error. The Literal element is either a geometry as a fragment of GML, validated against the geometry.xsd schema, or it is of xml type 'any'. It is up to the server to interpret the literal as an integer, a double, a string, a date, or anything else, which is a bit of a flaw in the Filter spec. But a server should be able to interpret against the known schema when doing the filtering.

Arithmetic Operators

All arithmetic operators take two expressions and return the result of applying the operator to it. This opens the door for even more complex Filters, such as

all plots of land with area greater than 50 times the number of people in the household.
More examples.

Multiplication (Mul), Division (Div), Addition (Add) and Subtraction <Sub> can all be performed. They can be applied against Literals, PropertyNames, and even the results of other arithmetic operations against combinations of those.

Functions

Functions open the door to even more power, defining arbitrary operations that go beyond the simple arithmetic offered blah blah blah...

all you dave.

Examples