Publication Date: 2017-06-15

Approval Date: 2016-09-15

Posted Date: 2016-10-21

Reference number of this document: OGC 16-024r2

Reference URL for this document:

Category: Public Engineering Report

Editor: R. Martell

Title: Testbed-12 — Catalog Services for Aviation

OGC Engineering Report


Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit

WARNING This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.


Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.


This Engineering Report (ER) presents guidance concerning the use of OGC® catalog services in the aviation domain. A wide variety of metadata resources can be readily published and discovered using the OGC CSW-ebRIM application profile, which marries the CSW catalog interface to the OASIS ebXML registry information model (ebRIM). However, existing SWIM registries currently under development by the FAA and Eurocontrol do not implement any OGC standards. This report explores the prospects for enhancing SWIM registries by a) integrating OGC catalog functionality, and b) accommodating OGC service descriptions.

Business Value

In the same way that one cannot stroll into a library and just pluck a desired book off a shelf, discovering and accessing services and data of interest in an operational environment generally requires the use of a catalog. This report describes how catalog services can help to enable the realization of complex workflows and to make SWIM registries more accessible to a broader community of users.

What does this ER mean for the Working Group and OGC in general

This report identifies issues and concerns regarding the use of OGC® catalog services in the aviation domain. It offers guidance that may influence specification development and suggests various mechanisms for integrating catalog functionality into SWIM registries, thereby promoting a broader level of interoperability among civil aviation authorities.


testbed-12, catalog, registry, SWIM, SDCM

1. Introduction

1.1. Scope

This engineering report is concerned with two topics regarding the use of registry services:

  • the use of OGC® catalog services in the aviation domain; and

  • the integration of OGC catalog functionality into the SWIM registries under development by the FAA and Eurocontrol.

In this report a registry is construed to be a type of catalog that offers additional capabilities supporting lifecycle governance. While the CSW-ebRIM profile does offer registry functionality, those aspects are not in scope.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name Organization

R. Martell (ed.)

Galdos Systems, Inc. (rmartell[AT]galdosinc[DOT]com)

1.3. Future Work

No future work is contemplated for this document, but change requests against other OGC specifications may arise from it.

1.4. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

  1. Whiteside, A., Greenwood, J.: OGC Web Services Common Standard, Version 2.0.0. OGC 06-121r9 (2010)

  2. Kaplun, M., Blomqvist, P., Uri, C., Haggstrom, N.: Service Description Conceptual Model (SDCM) 1.0. SESAR CP 2.1 Working Draft (2014)

  3. Martell, R.: CSW-ebRIM Registry Service — Part 1: ebRIM profile of CSW. OGC 07-110r4 (2009)

  4. Fuger, S., Najmi, F. et al.: ebXML Registry Information Model, Version 3.0. OASIS ebXML Registry TC (2005)

  5. Martell, R.: CSW-ebRIM Registry Service — Part 2: Basic extension package. OGC 07-144r4 (2009)

  6. Nebert, D. et al.: OpenGIS® Catalogue Services Specification, Version 2.0.2. OGC 07-006r1 (2007)

  7. Berners-Lee, T., Fielding, R., et al.: Uniform Resource Identifier (URI): Generic Syntax. IETF RFC 3986 (2005)

  8. Cox. S.: Name type specification — definitions — part 1 — basic name. OGC 09-048r3 (2010)

  9. Vretanos, P.A.: OpenGIS® Filter Encoding Implementation Specification, Version 1.1.0. OGC 04-095c1 (2012)

  10. OpenSearch 1.1 (Draft 5),

  11. Gonçalves, P.: OGC® OpenSearch Geo and Time Extensions, Version 1.0.0. OGC 10-032r8 (2014)

  12. Nebert, D. et al.: OGC® Catalogue Services 3.0 Specification — HTTP Protocol Binding. OGC 12-176r7 (2016)

  13. Nottingham, M., Sayre, R.: The Atom Syndication Format. IETF RFC 4287 (2005)

  14. Martin, D. et al: OWL-S: Semantic Markup for Web Services. W3C Member Submission (2004)

  15. ISO/TC 211: ISO 19119: Geographic information — Services. International Organization for Standardization, Geneva (2005)

  16. ISO/TC 46: ISO 3166-1: Codes for the representation of names of countries and their subdivisions — Part 1: Country codes. International Organization for Standardization, Geneva (2013)

  17. ISO/TC 46: ISO 3166-2: Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code. International Organization for Standardization, Geneva (2013)

  18. Web Service Taxonomies (FAA-STD-066),

  19. Kaplun, M. et al.: Utilization of Faceted Classification in the Context of the SWIM Service Registry,

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OGC Web Service Common Implementation Specification [1] shall apply. In addition, the following terms and definitions apply.

Service Description Conceptual Model

graphical and lexical representation of the properties, structure, and interrelationships of all service metadata elements.

System Wide Information Management

program overseen by the Federal Aviation Administration (FAA) designed to facilitate greater sharing of Air Traffic Management (ATM) system information

Transport Layer Security

cryptographic protocol that provides privacy and data integrity between two communicating applications

4. Conventions

4.1. Typographical conventions

The following typographical conventions are used in this document:

Constant width

Used for program listings, as well as within paragraphs to refer to API elements such as variable or function names.


This element signifies a tip or suggestion.


This element signifies a note intended to clarify or elaborate on some statement.


This element indicates a warning or caution.

4.2. Abbreviated terms

  • API Application Program Interface

  • ATM Air Traffic Management

  • COTS Commercial Off The Shelf

  • CMS Content Management System

  • NSRR NAS Service Registry/Repository

  • SDCM Service Description Conceptual Model

  • SCR SWIM Common Registry

  • SWIM System Wide Information Management

  • TLS Transport Layer Security

5. Overview

The requirements that motivated this work are outlined in Requirements. Candidate solutions are summarized in Solutions, along with the recommended solutions that were explored during the testbed.

The technical content of this report covers two main topics:

  • Using a CSW-ebRIM registry service in aviation applications; and

  • Enhancing SWIM registry services:

    • OpenSearch Geo extension;

    • Implement a CSW-SDCM profile (CSW adapter on SDCM); and

    • Accommodating OGC service descriptions.

6. Requirements

6.1. Current state of affairs

Catalog (and registry) services play an essential "matchmaker" role in a service-oriented architecture, enabling resource producers and consumers to interact without possessing prior knowledge about service capabilities and endpoints. Clients may search a catalog for resources of interest, and then use the results to obtain the resource from some provider by employing the appropriate protocol or "binding" (see figure below, Role of catalog services).

Role of catalog services
Figure 1. Role of catalog services

Within the aviation domain, the catalog role is primarily fulfilled by a SWIM-compliant registry. Existing SWIM registries developed by the FAA and Eurocontrol are based on the Drupal content management system and incorporate concepts from the Service Description Conceptual Model [2] (SDCM). However, they do not currently support spatial queries and cannot readily accommodate OGC service descriptions.

6.2. Requirements statement

Section 4.5 in Appendix B of the RFQ is concerned with advancing the use of catalog services in the aviation domain. Several functional requirements are presented:

  • demonstrate a CSW-based registry solution integrated with the existing FAA registry (NSRR v2) so as to provide a single entry point for service discovery;

  • provide a simple user interface for executing geospatial queries such as bounding box queries and "semantic querying of geospatial data";

  • enable discovery of content provided by web services, including pub-sub content (i.e. JMS topics);

  • search across multiple SWIM domain registries deployed by the FAA and Eurocontrol;

  • implement the harmonized Service Description Conceptual Model (SDCM); and

  • facilitate cost-effective governance of service metadata, including quality and integrity.

7. Solutions

Two candidate registry solutions were considered for this testbed:

  1. OGC CSW-ebRIM registry - a profile of the OGC Catalogue 2.0 specification; and

  2. FAA NAS Service Registry/Repository (NSRR) v2 registry - a custom solution implemented using Drupal, an open-source content management system.

7.1. Targeted Solutions

7.1.1. CSW-ebRIM registry

The following figure is a UML component diagram summarizing the CSW-ebRIM registry interfaces [3]. Several of these are common to all CSW catalogue services, but even then they must be tailored for the specific information model supported by the implementation.

CSW-ebRIM interfaces
Figure 2. CSW-ebRIM interfaces

In this case, the extensibility of the ebRIM model [4] is very appealing as it allows the registry to be readily adapted for particular application domains. Domain-specific extensions can include new types of content, controlled vocabularies (e.g. taxonomies, code lists), lifecycle stages, or functional enhancements. For example, an extension package might be defined to create a registry of standard and user-defined coordinate reference systems. There is an extension package based on ISO 19115 that focuses on providing detailed technical metadata about geographic information resources ( OGC 13-084r2).

A basic premise of the demonstration scenarios is that client and server component interactions are not "hard-wired" in advance. That is, the registry fulfills its key role of enabling the discovery of and access to a variety of information resources. For example, consider the following.

  • Data broker configuration: The data broker component acts as an intermediary between WFS service providers and consumers; it searches the catalog for services and uses service-related metadata to configure brokered access.

  • Service and data discovery: The aviation visualization client searches the catalog for services and data of interest, and then uses the results to retrieve and portray flight trajectories.

7.1.2. NAS Service Registry/Repository

The NSRR v2 registry was under active development during the testbed and an early-access release was made available to testbed participants ( The NSRR v2 registry provides a web-based interface for browsing registry content (NSRR user interface), but no API.

Figure 3. NSRR user interface

While the development of an API to allow programmatic access to registry content is under consideration, the absence of one made it impossible to demonstrate interworking with the NSRR registry via metadata harvesting or federated search. Effort was then redirected to considering how the notional API might take advantage of existing standards.

7.2. Recommendations

The prospects for improving the interoperability of SWIM registries by adopting existing standards were explored; this work should help to guide the future development of these implementations. Two main recommendations arise that reflect varying degrees of conformance and development effort.

  1. Implementing the OpenSearch GeoTemporal extensions promises to be the easiest way to enable a spatial search capability for a SWIM registry. However, this falls short of actually complying with any OGC catalog standard.

  2. Implementing a CSW adapter for the SDCM information model would be one way to accomplish this, and restricting it to read-only interactions would significantly reduce implementation effort. The goal of such an undertaking would be to achieve a "Basic" level of conformance that permits CSW clients to search SWIM registries.

8. Using a CSW-ebRIM registry in aviation applications

8.1. Functional overview

A CSW-ebRIM registry can process the service requests summarized below, most of which are common to all CSW-based catalog services.

  • GetCapabilities: This request allows a client to retrieve a resource that describes the essential capabilities and non-computational characteristics of the service.

  • DescribeRecord: This request allows a client to discover the information model(s) supported by the catalog and to retrieve type definitions.

  • GetRecords: This request allows a client to search the registry and retrieve all or some of the items in the result set.

  • GetRecordById: This request allows a client to retrieve a representation of one or more registry objects by identifier.

  • GetDomain: This request produces a description of the value domain for a specified data element or request parameter.

  • GetRepositoryItem: This requests allows a client to retrieve the repository item corresponding to some extrinsic object.

  • Harvest: This request enables a "pull" style of registration whereby a resource is retrieved from some remote location and inserted into the catalog.

  • Transaction: This request allows a client to directly insert, update, or delete catalog content.

A basic read-only implementation supports only search and retrieval operations; this constitutes the lowest level of conformance. The component used in this testbed is fully capable and allows authorized users to submit harvest and transaction requests. Anonymous users may search and retrieve registry content.

The registry service implements a web service API based on the OGC CSW-ebRIM profile. The API is used by other software components to programmatically search and update registry content. As indicated in the following figure, some of the client components may be web applications that present a graphical interface to human users; however, these applications make use of the same underlying API.

Registry clients
Figure 4. Registry clients

8.2. Registry information model: OASIS ebRIM 3.0

The CSW-ebRIM profile marries the CSW catalog interface to the OASIS ebXML registry information model [4]. The extensibility of the underlying model is what makes a CSW-ebRIM registry so broadly useful. The main extension points are presented in the following figure (Extension points in ebRIM).

ebRIM extension points
Figure 5. Extension points in ebRIM

The highlighted extension points apply to several types of registry objects:

  1. Slot: denotes an object property represented as a name-value pair;

  2. ExtrinsicObject: describes an arbitrary information resource, the content of which—​a repository item—​conforms to some media type (e.g. a PDF document, a video, or an XML Schema);

  3. Association: links two registry objects that are related in some manner;

  4. ClassificationNode: a concept or term in some controlled vocabulary that is used to classify a registry object; and

  5. ClassificationScheme: controlled vocabulary such as a taxonomy, thesaurus, or code list.

Application-specific extensions are bundled within an extension package (EP) to promote interoperability and reuse. An extension package is itself a registry object (rim:RegistryPackage) that can be imported and enabled in any CSW-ebRIM service. The 'Basic' package [5] is common to all implementations and provides general support for describing geographic services and data sets.

8.3. Metadata harvesting

Metadata harvesting exemplifies a convenient pull-style of publication whereby resources are retrieved and ingested in accord with predefined mapping rules. The OGC catalogue specification [6] defines a Harvest request for this purpose. A representation of an XML request entity is shown below. The required Source and ResourceType elements are absolute URIs that identify the target resource and its type, respectively.

Listing 1. Harvest request entity
<Harvest xmlns=""
  service="CSW" version="2.0.2">
  <!-- send asynchronous response to this destination when processing is complete -->

The participants in this effort have implemented a specialized CSW-ebRIM harvester for WFS 2.0 services. The source must refer to a WFS service description (an OGC capabilities document). The corresponding resource type is "", which is the service type identifier assigned by the OGC Naming Authority (OGCNA). The ebRIM mapping rules are summarized in the figure below (Output of WFS v2 harvester).

Output of WFS v2 harvester
Figure 6. Output of WFS v2 harvester

The root registry object is a Service; it includes a ServiceBinding for the GetCapabilities request and is classified using the geographic services taxonomy defined in ISO 19119. There is an associated ExtrinsicObject (of type "urn:ogc:def:ebRIM-ObjectType:OGC:Dataset") for each feature type listed in the capabilities document; it is linked to a service using the "OperatesOn" association. Each Dataset object has a slot that contains a gml:Envelope representing the approximate spatial extent of the feature data.

Finally, the service is linked to a ServiceProfile object (another type of ExtrinsicObject) that provides information about the general characteristics of the service. In particular, a copy of the OGC capabilities document is available from the registry as a repository item. However, if the service is a protected resource that is not publicly accessible then no ServiceProfile is created. Information about applicable access constraints will need to be obtained from the service provider.

If credentials are required to harvest a protected resource they must be conveyed to the registry in some manner. However, no OGC catalog specification allows for this. The solution adopted here was to exploit the generic syntax for URIs [7], which defines a userinfo field in the authority component in accord with these syntax rules:

authority = [ userinfo "@" ] host [ ":" port ]
userinfo  = *( unreserved / pct-encoded / sub-delims / ":" )

In this testbed access to some service capabilities documents was restricted using the "basic" authentication scheme. The user information consists of a user name and password in the format "user:password"; this data is inserted into the Source element of the Harvest request entity as indicated below:


This technique is only appropriate if the harvest request is submitted to the registry over a secure connection using TLS. The message payload is then kept private.

8.4. Stored queries

A CSW-ebRIM registry offers a stored query capability whereby predefined queries can be published and invoked by user agents that are permitted to do so. Such a facility provides a simpler means of searching the registry, since detailed knowledge of the underlying information model is not required; this is in contrast to building an ad hoc query with multiple filter criteria. Furthermore, a stored query can be invoked by simply submitting a GET request to the GetRecords endpoint. A stored query may accept parameters that act as filter criteria or affect the presentation of the search results. The parameters are included in the query component of the target URI in the usual manner.

The Basic EP defines several stored queries that are publicly accessible. For example, the findServices query accepts a serviceType parameter that identifies a service type in the ISO 19119 geographic services taxonomy. The GET request in the following listing returns a list of all OGC WFS 2.0 services.

Listing 2. Find WFS 2.0 services (stored query)
GET /query?qid=urn:ogc:def:query:OGC-CSW-ebRIM::findServices&serviceType=urn:ogc:def:serviceType:OGC::WFS:2.0 HTTP/1.1
Accept: application/xml
Accept-Encoding: gzip, deflate

The OGC Naming Authority (OGCNA) maintains a collection of official definitions: service types, stored queries, reference systems, and many more. All entries are formally identified by an 'http' URI in the "" domain. An equivalent Uniform Resource Name (URN) may be derived in accord with the naming rules described in the OGCNA policy document, OGC 09-048r3 [8].

Anyone may invoke a publicly accessible stored query (showStoredQueries returns a list of these). A registered user may define a stored query and choose to label it as private, in which case it may only be invoked by the owner.

8.5. Sample requests

The OGC filter grammar [9] allows a wide variety of queries to be expressed, including ones that involve multiple registry object types that are interrelated in some manner. Examples of some common requests are listed below; these are all GetRecords requests that contain compound filter predicates.

The following listing is a request to find data sets by area of interest. The BBOX predicate specifies a GML envelope that defines a bounding box. The relevant registry object property is a slot having the name ""; such a slot (defined in the "Basic" package) may be used to express a spatial extent using a GML geometry representation.

Listing 3. Find data sets by area of interest (bounding box)
<GetRecords xmlns=""
  <Query typeNames="wrs:ExtrinsicObject">
    <Constraint version="1.1.0">
            <Envelope xmlns="" srsName="urn:ogc:def:crs:EPSG::4326">
              <lowerCorner>49 -124</lowerCorner>
              <upperCorner>50 -123</upperCorner>

A more complicated query is shown below. It seeks to find WFS services that offer data in some area of interest. Note that several PropertyIsEqualTo predicates serve to filter for Service objects related to the matching Dataset objects by the "OperatesOn" association.

Listing 4. Find WFS services offering data in some area of interest
<GetRecords xmlns=""
  service="CSW" version="2.0.2" maxRecords="100" resultType="results">
  <Query typeNames="wrs:ExtrinsicObject_e rim:Association_a rim:Classification_c rim:Service">
    <?indicio-distinct-values true?>
    <ElementSetName typeNames="rim:Service">full</ElementSetName>
    <Constraint version="1.1.0">
            <Envelope xmlns="" srsName="urn:ogc:def:crs:EPSG::4326">
              <lowerCorner>49 -124</lowerCorner>
              <upperCorner>50 -123</upperCorner>
          <!-- related services -->
          <!-- constrain service type -->

8.6. The perils of meager metadata

Service descriptions are harvested in the form of service capabilities documents presented by all OGC services. A WFS advertises the spatial extent of available feature types as indicated in the following listing. The ows:WGS84BoundingBox element specifies a bounding box in the WGS 84 coordinate reference system (with non-standard axis order longitude, latitude).

Listing 5. Feature type metadata in a WFS capabilities document
  <wfs:Name xmlns:aixm="">aixm:Runway</wfs:Name>
    <ows:LowerCorner>-180.0 -90.0</ows:LowerCorner>
    <ows:UpperCorner>-30.0 90.0</ows:UpperCorner>

In this instance the spatial extent covers almost the entire surface of the planet; it nearly coincides with the valid area for the coordinate reference system. If feature data are not in fact available throughout such a large area, a client may be (mis)lead into searching for data where none exist. That is, a catalog search may produce a "false positive" that will yield nothing when querying a data access service. When confronted with such a default setting that is unlikely to be correct, a "dynamic" catalog might periodically query the data service in order to automatically refresh the corresponding registry item(s). This is an option that was considered during the testbed but was not implemented.

9. Enhancing SWIM registry services

The service registries currently being developed by the FAA and EUROCONTROL are based on the Service Description Conceptual Model (SDCM 1.0) which defines a comprehensive schema for service metadata. The flagship implementation, the NAS Service Registry/Repository (NSRR v2), is implemented using the Drupal content management system. It does not currently have a spatial query capability nor does it readily accommodate descriptions of geographic services and data. The aim of this section is to explore various options for integrating OGC catalog capabilities into SWIM registries.

9.1. SWIM Common Registry

The concept of a SWIM Common Registry (SCR) is driven by the desire to share service-related information among SWIM communities that implement registries according to their needs and local requirements. Relevant information assets include:

  • Service instances;

  • Interoperability resources: standards, data exchange models, etc.;

  • Communications; and

  • Stakeholders.

The common information model is SDCM, a high-level view of which is shown below. The three top-level elements of a service description are broken down into their constituent parts in a platform-independent manner. That is, the model is agnostic with respect to particular technology choices.

High-level view of SDCM
Figure 7. High-level view of SDCM

A common interface will enable interworking within and between SWIM communities. Work in this area is ongoing, but it is worth considering whether existing interfaces might be adopted in whole or in part.

9.2. Integrating OGC catalog functionality

The integration of OGC® catalog functionality into SWIM registries is not an "all or nothing" proposition. Several options are explored that entail varying degrees of effort:

  • OpenSearch GeoTemporal services;

  • CSW-SDCM application profile; and

  • Augmenting SDCM to accommodate OGC service descriptions.

9.2.1. OpenSearch GeoTemporal Services

While OpenSearch [10] is not itself an OGC specification, the OGC has published a set of extensions for it that deal with spatial and temporal queries: OGC® OpenSearch Geo and Time Extensions [11]. These extensions are collectively called "OpenSearch GeoTemporal Services" and offer a way to provide a fairly simple spatial query facility; while this does fall short of achieving OGC catalog compliance, it can be regarded as a step in that direction.

The OGC Catalog 3.0 specification [12] that was recently published includes support for OpenSearch as an optional conformance class. In particular, it requires that an implementation:

  • presents an OpenSearch description document;

  • presents search results as an Atom feed; and

  • supports spatial search by bounding box.

Search requests are submitted as GET requests that contain parameters in the query component of the target URI. The target URI must adhere to a URL template advertised by the service. For example, the listing shown below defines a template containing the geo:box parameter:

Listing 6. OpenSearch URL template
<Url type="application/atom+xml" xmlns:geo=""

Note that extensions must reside in a namespace that is not ""; a namespace prefix—​mapped to a namespace name (URI)--is used to accomplish this separation. In a URI constructed from this template, the value of the optional 'bbox' parameter must conform to the constraints imposed by OGC 10-032r8 [9]. More specifically, the bounding box is expressed as the west, south, east, and north bounding coordinates (given in decimal degrees) using the geographic 2D coordinate reference system known as "EPSG 4326".

EPSG Geodetic Parameter Dataset

The International Association of Oil & Gas Producers (IOGP) maintains the EPSG Geodetic Parameter Dataset, a collection of definitions of coordinate reference systems and coordinate transformations. The coordinate reference system (CRS) identified by the code '4326' is a global geodetic 2D reference system commonly known as "WGS 84". The formal definition of this CRS, as well as those of many others, may be viewed in the official EPSG registry.

A sample GET request is shown below. The search term includes the value "notam" and the bbox parameter specifies a region of interest in the northeastern US extending roughly from Washington, DC to Boston.

Listing 7. Sample OpenSearch request
GET /qry?q=notam&bbox=-77.1,38.9,-71.0,42.4 HTTP/1.1
Accept: application/atom+xml

The query response is expected to be an Atom feed [13] that contains an entry for each matching record (see sample listing below). Note that the geographic extent of the entry is defined by a gml:Envelope in the coordinate reference system identified by the srsName attribute (WGS 84).

Listing 8. OpenSearch results (Atom feed)
<feed xmlns=""
  <title>ACME Catalogue ENVISAT ASAR Wide Swath Mode</title>
  <os:Query role="request" count="20" geo:box="-77.1,38.9,-71.0,42.4"/>
    <category term="NOTAM"/>
    <title>Mauris sed neque</title>
    <summary>Proin sit amet justo. In justo. Aenean adipiscing nulla id tellus.</summary>
      <gml:Envelope srsName="">
        <gml:lowerCorner>40.59 -74.10</gml:lowerCorner>
        <gml:upperCorner>41.22 -73.89</gml:upperCorner>
  <!-- remaining entries -->

9.2.2. CSW-SDCM application profile

The OGC catalogue specification defines a common interface that is designed to be profiled. In effect, a profile imposes application semantics by coupling the common interface to a particular information model. With respect to the SWIM Common Registry, a basic level of OGC conformance could be achieved by implementing an application profile that binds CSW query operations to the SCR information model, SDCM. A profile may also require that one or more options from the base standard—​such as federated search—​be implemented.

Minimal conformance encompasses the following capabilities:

  • Provide a read-only "Basic" catalogue service that implements search and retrieval operations;

  • Support the OGC filter encoding syntax (BBOX, logical, and comparison predicates);

  • Define an XML representation of SDCM entities; and

  • Map SDCM entities to the common XML representation (csw:Record).

OGC® Catalogue Services 3.0 Specification

The Basic-Catalogue conformance class defined in the latest revision of the OGC catalogue specification (OGC 12-176r7) requires that the following capabilities be implemented in order to claim conformance:

  • KVP-encoding of the GetCapabilities request;

  • KVP-encoding of the GetRecordById request; and

  • KVP-encoding of the GetRecords request, subject to the following requirements:

    • Support all basic retrieval parameters;

    • Implement the Filter-FES-KVP conformance class;

    • Implement the CSW-response conformance class; and

    • Implement the ATOM-response conformance class.

Rather than resorting to the development of a custom XML schema, it would be advisable to adopt an existing grammar or hypermedia format if practicable. For example, perhaps the Atom syndication format would suffice, with extension elements introduced as needed to accommodate SDCM concepts.

Another possibility is to adopt RDF as an open-ended data interchange standard, using the XML syntax for CSW catalog interoperability. This approach would be facilitated by using RDF Schema or OWL to describe the underlying data model. Indeed, SDCM concepts do seem to lend themselves to a more explicit semantic treatment.

9.2.3. Augmenting SDCM to accommodate OGC service descriptions

Every OGC service is described by what is colloquially referred to as a "capabilities document". Its core elements are defined in the OGC Web Service Common specification (WSC), but most services extend this content model with service-specific metadata elements. An XML representation is obtained by submitting a GetCapabilities request. An OGC service may also provide alternative descriptions such as WSDL or WADL, but this is not required.

Given an OGC service described by a capabilities document, how might it be registered in a SWIM Common Registry implementation? The NSRR registry maintained by the FAA does describe some OGC services, such as the "CDDS WFS NonGridded Weather Products (CIWS WFS)". But it’s unclear how OGC service metadata are mapped to the underlying information model, if at all.

This ER considers several possibilities for enhancing the description of OGC services:

  • Map a capabilities document to SDCM as a Service Profile entity; and

  • Add support for standard geographic classification schemes, such as:

    • ISO 19119 geographic services taxonomy - to categorize a service according to its general functionality; and

    • ISO 3166 country (subdivision) codes - to enable geographic referencing by identifier.

OGC service capabilities

For many years OGC services have been described using a custom XML document based on the OGC Web Service Common Implementation Specification [1]. In a CSW-eBRIM registry a capabilities document is mapped to a ServiceProfile object, which is a concept borrowed from the ontology of services defined in the OWL-S framework [14]. Since SDCM also incorporates this concept, a similar mapping would seem appropriate.

However, there are many constituents of a Service Profile in SDCM, including security and quality of service constraints that are rarely found in an OGC capabilities document. At the very least the content of a capabilities document could produce the following types of registry items:

  • Service Profile (key attributes: name, description, version, category);

  • Service Provider (organization and points of contact); and

  • Service Function (one per service operation).

In SDCM a Service Profile may be classified according to the type of service provided. There are several relevant schemes used by CSW-ebRIM registries that could also be employed by SWIM registries.

Geographic classification schemes

ISO 19119 [15] defines a geographic services taxonomy that is used to categorize OGC services. The six top-level categories of the scheme are shown below, along with a few selected subcategories.

Geographic services taxonomy
  • Human interaction services

    • Catalogue viewer

    • Geographic symbol editor

  • Model/information management services

    • Feature access service

    • Map access service

    • Catalogue service

  • Workflow/task management services

  • Processing services

  • Communication services

  • System management services

A Web Feature Service (WFS) is a kind of Feature access service. A Web Map Service (WMS) is a Map access service. Almost every OGC service type can be classified in this manner.

Spatial references can be based on either geographic coordinates or geographic identifiers. The latter may be systematically arranged into a formal scheme such as the country and country subdivision codes defined in ISO 3166 (parts 1 and 2). Currently there are some 249 countries, territories, or areas of geographical interest officially identified in ISO 3166-1 [16]. Codes for country subdivisions are defined in ISO 3166-2 [17]. For example:

  • CA-BC: British Columbia (Canada);

  • US-WA: Washington state (United States); or

  • DE-NW: Nordrhein-Westfalen (Germany).

These codes can be used to simply characterize the spatial extent of a service or dataset when more precise coordinates are either unavailable or unnecessary. The UN/LOCODE coding scheme offers an even finer-grained means of applying a spatial tag; it currently includes more than 100,000 locations in 249 countries. In most cases airport locations are identified by the standard IATA code.

Classification schemes in the aviation domain

NSRR employs a set of taxonomies defined in FAA Standard Practice FAA-STD-066 [18], all of which are hierarchically structured to varying degrees. Examples include:

  • FAA Service Category Taxonomy;

  • Service Criticality Taxonomy; and

  • Delivery Channel Taxonomy.

In contrast to a highly structured scheme such as a hierarchy or a tree, a faceted scheme is "a set of mutually exclusive and jointly exhaustive categories" [19]. It would appear that such a scheme can be regarded as a kind of unstructured code list (e.g. days of the week, aircraft manufacturers). An item can be labelled using any number of applicable facets so as to support advanced search scenarios.

It should be noted that CSW-ebRIM allows for faceted classification without requiring any changes to the underlying information model. A rim:Classification object is essentially a link that relates a registry object to a concept in some scheme (see listing below).

Listing 9. Classification in ebRIM
<Classification xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
    <LocalizedString xml:lang="en" value="Bombardier Inc (Canada)"/>
    <LocalizedString xml:lang="en" value="Aircraft Manufacturer"/>

The classifiedObject attribute refers to the parent registry object; the classificationNode attribute refers to a term or concept in some scheme. A classificationScheme attribute may also appear, but this is usually unnecessary since it can be determined from the referenced node. A registry object may have multiple classifications and a search request may filter on any of them.

Appendix A: Revision History

Table 2. Revision History
Date Editor Primary clauses modified Descriptions


R. Martell


First draft


R. Martell


Final draft


R. Martell

7.1, 9.2.2

Address comments from Catalog SWG


R. Martell

8.1, 8.6 (added)

Describe limitations of harvested metadata