Encoding Standards

Producer Field Guide

Producer Field Guide

Filter Types and Encodings

Filter expressions are encodings used to identify a subset of object instances to be operated upon by constraining property values of an object type. Filters for geographic information are widely available and follow a variety of different formats. In ERDAS APOLLO Server, we rely upon the OGC Filter Encoding Specification 1.0 to define which filter types are valid in our product components, such as the WFS, CSW, and SLD. OGC filters are written in XML and are the equivalent of a SQL WHERE clause that allows restriction of features extracted from the data set by expressing operations on scalar or geometric properties.

Because all filter expressions for OGC are based on XML, the filters must be able to address feature names and properties encoded as XML elements or attributes. Therefore, all filter expressions follow a subset of XPath, the WC3 XML Path Language. This is a specification for addressing parts of an XML document or referencing feature properties that are encoded as XML elements or attributes. The filter specification only needs a subset of the XPath language to define an OGC compliant filter expression; it does not need to support the full XPath language.

For more information on filters, see the OGC Filter Encoding Specification 1.0. For more information about XPath, see the W3C specification at W3.org.

Spatial filters are often referred to as map algebra. These spatial filters are a subset of the available topological operators that allow one to do analysis and problem solving on spatial or geographically-based data.

Scalar filters compare or restrain the magnitude of various data aspects. These filters include the ability to process logical expressions, comparisons, and/or arithmetical operations.

Spatial Filters

The following are spatial filter operators based on the ISO and OGC geometry models:

  • Disjoint - a geometric relationship where two objects do not interact in any way. Two disjoint objects do not share any elements or pieces of their geometry.
  • Touches - a geometric relationship where two objects share a common point on their boundaries, but their interiors do not intersect.
  • Crosses - two lines cross each other if they meet on an internal point. Note that this relationship is different than a touch relationship because a touch is only on the boundaries. Similarly, a line crosses an area if the line is partly inside the area and partly outside.
  • Within - when a geometry's interior and boundary are completely contained by another geometry, it is said to be within the second geometry.
  • Overlaps - the interior of one geometry is partially included in the interior of another geometry and vice versa.
  • Equals - a geometric relationship in which two objects are considered to represent the same geometric figure. The two objects must be composed of the same number of points, although the ordering of the points defining the two objects' geometries may differ (clockwise or counterclockwise).
  • Intersect - the topological integration of two spatial data sets that preserves features that fall within the area common to both input data sets.
  • Contains - describes a geometric relationship where one object encompasses another and the interior object does not touch any boundaries of the exterior object. The outer object contains the inner object.
  • Beyond - the operator tests whether the value of a geometric property is beyond a specified distance of the specified literal geometric value.
  • Within - this operator is the opposite of beyond and similar to a buffer operation.

Scalar Filters/Common Catalog Query Language

The definition of scalar relates to a quantity of something that has magnitude, but no direction. OGC defines the following types of operators as scalar.


The operators AND, OR, and NOT, are logical, boolean operators.

AND: This logical operator is used in queries to specify that both condition 1 AND condition 2 must be met before data is returned. When used in combination with a logical OR operator, the AND operator takes precedence over the OR operator. For example, the expression "condition 1 AND condition 2 OR condition 3" is evaluated as (condition 1 AND condition 2) OR condition 3. Typically, parentheses are used in queries that have both AND and OR operators to ensure the correct order of precedence.

OR: This operator is used to specify that you would return data if either or both condition 1 or condition 2 is met. See the above explanation for more information about using the OR operator with the AND operator. If order is not explicitly and properly defined in the WHERE clause, the OR operator can produce every possible combination.

NOT: This operator returns TRUE if its operand is FALSE, and FALSE if its operand is TRUE. NOT is used to perform logical negation on a single condition.


PropertyIsEqualTo - The equality operator defines the relationship that two numeric or text properties are equal if both their values are equal.

PropertyIsLessThan - The less than operator defines the relationship that a numeric or text property is less than another if its magnitude is less than the other one.

PropertyIsGreaterThan - The greater than operator defines the relationship that a numeric or text property is greater than another if its magnitude is greater than the other one.

PropertyIsLessThanOrEqualTo - The less than or equal to operator defines the relationship that a numeric or text property is less than another if its magnitude is less than the other one or that the two numeric or text properties are equal if both their real parts and imaginary parts are equal.

PropertyIsGreaterThanOrEqualTo - The greater than or equal to operator defines the relationship that a numeric or text property is greater than another if its magnitude is greater than the other one or that the two numeric or text properties are equal if both their real parts and imaginary parts are equal.

PropertyIsLike - The PropertyIsLike operator retrieves records where a text string appears and reflects the placement of the specified value(s). It finds patterns in character string data. Comparisons can be made only between compatible data types. PropertyIsLike allows the use of a wildcard, which is a character that may be substituted for any of a defined subset of all possible characters. The two most common wildcards used with the PropertyIsLike operator are the percent (%) and underscore ( _ ) characters.

PropertyIsNull - Retrieves only records where the item HAS NO value.

PropertyIsBetween - Retrieves only records where the item lies BETWEEN (and EQUALS) the specified values.


ADD - Addition is an arithmetic operator used to add two numbers.

SUB - Subtraction is an operator used to subtract two numbers or to change the sign of a number.

MUL - Multiplication is an arithmetic operator used to multiply two numbers.

DIV - Division is an arithmetic operator used to divide two numbers and return a floating-point result.

Arithmetic operators can also include functions, which are specific types of procedures that perform a distinct computation. A function may accept zero or more arguments as input and generate a single result. A function is composed of the name of the function encoded using the attribute name and zero or more arguments contained within the <functions> element. The arguments themselves are expressions.

The ERDAS APOLLO Server WFS supports the following Oracle-based expressions: Upper and Lower to reference the character data type for string based expressions, Distance to determine if two geometries are within a specified distance from one another, and Score to allow the ordering of a query result.

Example Capabilities Fragment

In the context of a WFS, the capabilities request will publish the specific operators supported. A WFS may support one of any of the OGC operators available. The decision of which filters to support and when to support them is really up to the implementors and publishers of the WFS.

The following is an example of a capabilities fragment for a service that supports some of the filtering capabilities defined in this document. This example also demonstrates named arithmetic functions.

Example: Operators in Capabilities

For more information on OGC Simple Feature-SQL and Filter Encoding Specifications see opengeospatial.org. For more information on Oracle spatial operators, see oracle.com. For more information on Java JTS filter specifications see java.com.

Geography Markup Language (GML)

GML is an open, nonproprietary language used to created geospatial objects for the purpose of data sharing. GML also serves as a data transport for geospatial objects and provides a means for describing geospatial web services.

Previous versions of GML were concerned with what the OGC calls simple features, or features whose geometric properties are restricted to 'simple' geometries for which coordinates are defined in two dimensions and the delineation of a curve is subject to linear interpolation.

GML3 handles the following needs that were not addressed or adequately met by the previous version:.

  • Logical expressions are used to process AND, OR, or NOT operators.
  • Comparison operations are used to indicate the types of comparison operators supported by a service. Simple comparisons such as =, <, <=, >, and >= are supported. Elements such as LIKE, BETWEEN, and NULLCHECK are used to indicate whether the service can support a like, between, or null operator.
  • Arithmetic operators elements can be used to determine which arithmetic operators the services support. Simple arithmetic is used to indicate that the service supports addition, subtraction, multiplication, and division. The functions elements indicates whether additional functions are available via the service.
                  .…more functions defined here…
      ©All rights reserved - OGC 2002

  • Provides an open, vendor-neutral framework for the definition of geospatial application schemas and objects
  • Allows profiles that support proper subsets of GML framework descriptive capabilities
  • Supports the description of geospatial application schemas for specialized domains and information communities
  • Enables the creation and maintenance of linked geographic application schemas and datasets
  • Supports the storage and transport of application schemas and data sets
  • Increases the ability of organizations to share geographic application schemas and the information they describe
  • Represents geospatial phenomena in addition to simple 2D linear features, including features with complex, non-linear, 3D geometry, features with 2D topology, features with temporal properties, dynamic features, coverages, and observations
  • Provides more explicit support for properties of features and other objects whose value is complex
  • Represents spatial and temporal reference systems, units of measure, and standards information
  • Uses reference system, units, and standards information in the representation of geospatial phenomena, observations, and values
  • Represents default styles for feature and coverage visualization
      <![CDATA[<?xml version="1.0" encoding="utf-8"?>
      <xs:schema version="1.0.0"
        <xs:import namespace="http://www.opengis.net/sld"
        <xs:element name="ViewContext" type="context:ViewContextType"/>
        <xs:complexType name="ViewContextType">
            <xs:element name="General" type="context:GeneralType"
              minOccurs="1" maxOccurs="1"/>
            <xs:element name="LayerList" type="context:LayerListType"
              minOccurs="1" maxOccurs="1"/>
          <xs:attribute name="version" type="xs:string" use="required" fixed="1.0.0"/>
          <xs:attribute name="id" type="xs:string" use="required"/>
        <xs:complexType name="GeneralType">
            <xs:element name="Window" type="context:WindowType"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="BoundingBox" type="context:BoundingBoxType"
              minOccurs="1" maxOccurs="1"/>
            <xs:element name="Title" type="xs:string"
              minOccurs="1" maxOccurs="1"/>
            <xs:element name="KeywordList" type="context:KeywordListType"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="Abstract" type="xs:string"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="LogoURL" type="context:URLType"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="DescriptionURL" type="context:URLType"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="ContactInformation" type="context:ContactInformationType"
              minOccurs="0" maxOccurs="1"/>
            <xs:element name="Extension" type="context:ExtensionType"
              minOccurs="0" maxOccurs="1"/>

GML version 3.1.1 maintains backward compatibility for GML version 2.1.2 instance documents by preserving, but deprecating, some schema components that have been replaced by different constructs in the current version.

For more information see the GML Specification on opengeospatial.org.

Scalable Vector Graphics (SVG)

SVG stands for Scalable Vector Graphics and is an XML grammar for stylized graphics.

Scalability infers that something can increase or decrease uniformly. SVG graphics are scalable to different display resolutions for different uses. A printed SVG graphic will use the full resolution of the printer and also display at the same size on screens of different resolutions. The same SVG graphic can be placed at different sizes on the same Web page and reused at different sizes on different pages. SVG graphics can be magnified to see fine detail. SVG graphics can also be referenced or included inside other SVG graphics to allow a complex illustration to be built up in parts, perhaps by several people.

SVG models graphics at the graphical object level rather than as individual points. SVG includes font elements so that both the text and graphical appearance are preserved.

Vector graphics contain geometric objects, such as lines and curves. Typically, vector graphics can also integrate raster images and can combine them with vector information such as clipping paths to produce a complete illustration, and SVG is no exception.

SVG fills a gap in the market of XML grammars by providing a rich, structured description of vector and mixed vector/raster graphics. It can be used in a stand-alone fashion, or as an XML namespace with other grammars. Since it is written in XML, SVG builds on this strong foundation and gains many advantages such as a sound basis for internationalization, powerful structuring capability, and an object model. SVG graphics may also be included in a document which uses any text-oriented namespace, including XHTML.

Styled Layer Descriptor (SLD)

SLD defines a styling language that the client and server can both understand, to portray the output of Web Map Servers, Web Feature Servers, and Web Coverage Servers.

SLD - Architecture


The above figure illustrates the SLD architecture in the ERDAS APOLLO Server product. While the complete SLD mechanism is intended for adding to WMS requests, the portrayal engine contained in this product is also able to style specific feature types using a subset of the SLD tags.

OGC Web Map Contexts

A context is an XML document that essentially stores WMS service URLs, layers you want to view on each server, and the area of interest for each layer. A mapping client can then just read the context file and display a map that you can modify or send without having to host the data or be tied to a specific server. Context documents include information about the servers providing the layer in the overall map, the bounding box and map projection shared by all the maps, sufficient operational metadata for client software to reproduce the map, and ancillary metadata used to annotate or describe the maps.

Context Uses

The context document makes a map that is assembled from several different services easier to view and style. The context document can provide a convenient default startup view for users who often deal with only one designated set of geospatial information.

Ease of Use

Human readers can easily understand the context document because it is written in XML. The context document stores not only the current settings, but also additional information about each layer such as available styles, formats, and SRS. This makes map viewing and manipulation easier for the end user because it is not necessary to query map servers again for layers that are contained within the context each time they are accessed.


The context document can be saved from one client session and transferred to a different client application to start up with the same context. Contexts could be cataloged and discovered, thus providing a level of granularity broader than individual layers.

Example: Beginning of a Context document

For more information see the OGC Web Map Context Document Specification on opengeospatial.org.