Gazetteer Service
Overview
A Gazetteer is an online "dictionary" of geospatial words or terms, with or without applicable feature geometries. The Gazetteer Service can be used to relate place names to stored geometry. The geometry is specific with respect to the coordinate reference system.
For example, a Gazetteer system may be able to transform the name of a city into a polygon or a single point that represents that city. A Gazetteer system may include the capability to do geo-coding, which means it would be able to convert a street address to a geographic location.
The Gazetteer Service specification is a specialization of the Web Feature Service (WFS) specification. The Gazetteer Service also provides for multi-lingual environments.
Best Practice
Gazetteer Service – Application Profile of the Web Feature Service Implementation Specification, OGC® Document 05-035r2
Note: The WFS Gazetteer Profile is on the OGC Agenda for 2011 approval as a standard.
Related Information
Geography Markup Language (GML)
Notes
Currently the OGC® Best Practice document is not an OGC® standard. The OGC Standards Working Group has distributed the Profile for review and comment, and intends to publish the revised version as a Version 1.0 implementation standard, possibly in 2011. It is subject to change without notice and may not be referenced as an OGC® standard.
The Gazetteer Service implementation standard is being developed by the Standards Working Group (SWG) of the Open Geospatial Consortium (OGC).
Please also see the OGC blog post by Jeff Harrison, OGC Advances Best Practice for Sharing Geographic Names, presenting the OGC Gazetteer Service Best Practice that is fully compliant with ISO 19112:2003, Geographic Information – Spatial Referencing by Geographic Identifiers*.
Additional Information: Gazetteer Service
Development Status of a Gazetteer Standard
The ISO definition of a Gazetteer is a “dictionary of instances of a class or classes of features containing some information regarding position”. A Gazetteer is essentially a geospatial dictionary of geographic labels, together with their locations and other descriptive information. A geographic label might be:
- A proper name for some natural feature or man-made construct, such as Saltspring Island or the Lion’s Gate Bridge,
- A street address, or
- A telephone area code or postal code.
Traditionally a Gazetteer supports look-up of the geographic location of a place identified by its proper name. Digital Gazetteers have expanded this concept to allow look-up by other labels such as: addresses, codes, named events, and similar data. The purpose of the Gazetteer Service is to provide a network-accessible service that offers this functionality.
To illustrate: when using a traditional paper Gazetteer to look up the location of “London, Ontario”, one would look up “London” in an alphabetized list and then select the appropriate “London” from those locations listed. To provide this capability, the Gazetteer Service supports the following sorts of queries:
- Give me the geographic location of all cities with the name “London”. This query should return a list that provides, for each entry, unique information to identify the city (such as the country name in which it is located) and each city’s geographic location.
- Give me the geographic location of the city named “London” in the country “Canada”. This query should return a similar list, but with the cities named “London” that are located only in Canada.
- Give me the geographic location of the city named “London” within the provided boundary. This query should return a similar list, but only those cities located inside the given boundary.
A Gazetteer Service is a network-accessible service that retrieves one or more features given by a query request. A Gazetteer Service is a specialization, or Application Profile, of the Web Feature Service (WFS). Hence, it is often referred to as WFS-G. A Gazetteer Service can be distinguished from a Web Feature Service because:
- The features returned by a Gazetteer Service are consistent; the features are derived from either SI_LocationInstance or SI_LocationInstance_Brief;
- Queries support parent/child relationships so that such hierarchies of features can be easily navigated; for example: a WFS-G query can navigate from the city of London to the province of Ontario.
A Gazetteer Service must also support spatial and thematic search constraints, as provided in the OpenGIS Filter Encoding Standard (FES)*.
Development Status of a Gazetteer Standard
There is growing interest in the development of a common feature-based model for access to named features, often referred to as a Gazetteer. Two major activities form the basis of this specification: an OGC® Discussion Paper on Gazetteers, and an ISO draft standard for geographic identifiers. Work has also been undertaken by the National Spatial Data Infrastructure (NSDI).
OGC® Standards Working Group (SWG)
The OGC-SWG is refining the existing Best Practice paper "Gazetteer Service - Application Profile of the Web Feature Service Implementation Specification" (Document #7 on the listing: OGC® Document 05-035r2) with publication planned as a Version 1.0 implementation standard. The document defines a Gazetteer Service Profile of the OGC® Web Feature Service Implementation Specification. The OGC® Gazetteer Service allows a client to search and retrieve elements of a geo-referenced vocabulary of well-known place names.
OGC WFS-GApplication Profile
The Gazetteer Service is a specialized Application Profile of a Web Feature Service (WFS) that specifies a minimum set of Feature Types and operations required to support an instance of a Gazetteer Service. Instances within a collection of Gazetteer features may be related to each other, and constitute a hierarchical vocabulary of geographic places. The overall information model is implemented as a GML application schema that defines a general feature type to be served by a Gazetteer Service.
The proposed Gazetteer Service exposes the following interfaces to query location instances in a Gazetteer database:
- Get or Query features based on thesaurus-specific properties (broader term (BT), narrower term (NT), related term (RT)); and
- Retrieve properties of the Gazetteer database, such as the location type class definitions and the spatial reference system definitions.
As a Profile of the WFS Implementation Specification, the OGC® Gazetteer Service is related to and makes use of the OGC® Web Feature Service (WFS), OGC® Filter Encoding, and OGC® Geography Markup Language (GML), specifications, and ISO 19139: 2007, Geographic Information – Metadata – XML schema implementation*. The Profile implements the minimal set of elements from the ISO 19112 model to provide useful, standardized services.
The OGC® Gazetteer Service allows a client to search and retrieve elements of a geo-referenced vocabulary of well-known place names. It extends the WFS interface in a way that a client is able to:
- Determine if a WFS implementation is acting as a Gazetteer Service;
- Query the Gazetteer Service, to retrieve place-name features without closer examination of the Feature Type definitions; and
- Access metadata about the Gazetteer(s) provided.
To ensure semantic interoperability, this Profile defines the response schema elements according to the Gazetteer data model defined in ISO 19112.
The overall design principle of this Profile is to make the Gazetteer Service behaviour completely predictable, and allow set-up as easily as possible, provided that a Web Feature Service instance is available. The following list gives an overview of the specific characteristics of a Gazetteer Service in comparison to a Web Feature Service:
- The service type is “WFS”, which allows a server instance to act both as a general Web Feature Service and as a Gazetteer Service;
- The Gazetteers (collection of locations) are described by metadata objects of a well defined feature type SI_Gazetteer. Presence of this Feature Type is sufficient to determine that a service acts as a Gazetteer for the FeatureTypes described by the collection of SI_Gazetteer objects;
- The Gazetteer WFS serves at least one FeatureType derived from SI_LocationInstance and described by a feature of type SI_Gazetteer;
- To support absolute URL references to single instances of a place-name database, a Gazetteer Service is able to process KVP-encoded GetFeature requests issued by using HTTP GET.
Services compliant with these Gazetteer Service operations must provide Feature Types derived by extension from the well-known Feature Type SI_LocationInstance. In addition, they may support queries based on the (parent/child) relationships of feature instances, as defined in ISO 19112. Note that the object model for ISO 19112 has been re-factored according to the rules of ISO19118: 2005, Geographic Information – Encoding*, to allow generation of normative GML-3 application schemas.
The Gazetteer Service is intended to provide SI_LocationInstance-derived objects, and metadata via SI_Gazetteer objects. FeatureTypes (SI_LocationType) are assumed to be implemented in a Feature Type Catalog in accordance with ISO 19110: 2005, Geographic Information – Methodology for Feature Cataloguing*; therefore, no requirement to serve these non-spatial definition objects is specified. SI_LocationType Feature Types maybe supported by a Gazetteer Service to describe the Gazetteer’s internal organization.
A Gazetteer defines a set of location instances, each of which provides a binding between representations of a location within aCoordinate Reference System(CRS) and as an identifier. Each location instance is a Feature, and consists of a representation (possibly one of many) of a “real-world” object. The representation of the real-world object within the Gazetteer is designed to be used to perform this translation, and to allow the set of such Features to be discovered and searched.
The Gazetteer Service is thus a WFS serving a predictably structured set of features representing Gazetteers and the sets of location instances they contain.
Gazetteer Services Operations
To support query processing, a Gazetteer Service includes the following operations:
GetCapabilities
The mandatory GetCapabilities operation allows clients to retrieve service metadata from a Gazetteer server. It specifies the XML document that a Gazetteer server must return to describe its capabilities.
The response to a GetCapabilities request contains service metadata about the server, including specific information about the feature types it can service and the supported operations for each feature type. As a Web Feature Service, a Gazetteer Service must be able to describe its capabilities. Specifically, it must indicate which feature types it can service, what operations are supported for each feature type, and what the structure of the Gazetteer database is like.
DescribeFeatureType
The DescribeFeatureType operation allows Gazetteer clients to retrieve schema descriptions which define how the Gazetteer server will generate feature instances on output (in response to a GetFeature request). As a Web Feature Service, a Gazetteer Service must be able, upon request, to describe the structure of any feature type it can service. Gazetteer service feature types are derived from the base type SI_LocationInstance.
GetFeature
The GetFeature operation allows retrieval of features from a Gazetteer Service. A GetFeature request is processed by a WFS-G and when the value of the outputFormat attribute is set to text/gml; subtype=gml/3.1.1, a GML instance document, containing the result set, is returned to the client. As a Web Feature Service, a Gazetteer server must be able to service a request to retrieve feature instances.
In addition, the client should be able to specify which feature properties to fetch, and should be able to constrain the query spatially and non-spatially.A typical request would query for features with a "geographicIdentifier" of some literal value (e.g. "Bonn*"), possibly limited to features with a particular locationType:identifier (e.g. City), and possibly within a particular geographic extent.
(The above operations are common to versions 1.0 and 1.1 of the WFS specification. Additional constraints are that WFS 1.0 must support the GML 2.1 implementation of each FeatureType, whereas WFS 1.1 must support the GML 3.1.1 implementation. Each may optionally advertise and support the alternative format, thus a WFS 1.0 conformant service may support GML3.1.1 as an optional output format. Additionally, a Gazetteer Service supporting WFS 1.1 interface may implement the GetGMLObject operation.)
GetGMLObject
A Gazetteer Service may be able to service a request to retrieve element instances by traversing XLinks that refer to their XML IDs.
Processing Requests
Based on the descriptions of the above operations, two classes of Gazetteer Services can be defined:
- Basic Gazetteer Service: would implement the GetCapabilities, DescribeFeatureType and GetFeature operations.
- XLink Gazetteer Service:would support all the operations of a Basic Gazetteer Service and, in addition, it would implement the GetGMLObject operation for local and/or remote XLinks, and offer the option for the GetGMLObject operation to be performed during GetFeature operations.
Below, in general terms, is the protocol to be followed to process Gazetteer Service requests. Processing requests should proceed as follows:
- A client application (optionally) requests a capabilities document from the WFS-G. Such a document contains a description of all the operations that the WFS-G supports, a list of all feature types that it can service, and a description of the structure of the underlying Gazetteer datastore.
- A client application (optionally) makes a request to a Web Feature Service for the definition of one or more of the feature or element types that the WFS-G can service. (This option may be used to discover additional elements.)
- A client application (optionally) requests the set of Gazetteer metadata SI_Gazetteer objects to identify the feature types that implement the Gazetteer data model. (These feature types will be SI_LocationInstance or a type derived from this by extension.)
- Based on the definition of the SI_LocationInstance feature type, and possibly other properties of a specified Feature Type that extends this, the client application generates a request as specified in the WFS interface.
- The WFS-G is invoked to read and service the request.
- When the WFS-G has completed processing the request, it will generate a status report and return it to the client. In the event that an error has occurred, the status report will indicate that fact.
Notes: A “client application” may include Registries and other middleware, as well as conventionally understood “end-users”.
A client may be “bound” to the Gazetteer Service content by configuration, or discover the implementing SI_LocationInstance Feature Types through a services registry and may, therefore, be able to skip Steps 1, 2 and 3.
The definition of the WFS-G Profile is intended to make the discovery and invocation of WFS-G services possible through service registries.
* © ISO – All rights reserved
Page details
- Date modified: