[CP-03-020] GIS&T and Geospatial Web Services

Percivall, G. (2025).  GIS&T and Geospatial Web Services. The Geographic Information Science & Technology Body of Knowledge (2025 Edition), John P. Wilson (ed.). DOI: 10.22224/gistbok/2025.1.4

1. Overview
2. Geospatial data on the web - interoperability
3. OGC Web Services
4. OGC APIs
5. Data Interchange Formats used by OWS
6. Geospatial Web Services Implementations

1. Overview  

Geospatial Web Services makes geospatial information available through the World Wide Web.  Much like the WWW provides access to a variety of types of multimedia, geospatial web services provide access to geospatial information in many different forms and formats.  And as the WWW is based on open standards so to the geospatial web services discussed in this article are based on open standards.  Open consensus standards are the basis of open interoperability whereby any provider of information can expose their data through a web server making that data available to anyone with a web browser or client software that understands the open standards.

The Open Geospatial Consortium has defined a suite of standards for most of the geospatial web services defined in this article.  The OGC processes include a consensus standards track (Reed 2015) and a prototyping innovation track (Percivall 2015).   This article describes how the OGC Web Service (OWS) standards, OGC API standards, and several non-OGC standards provide interoperability for geospatial data on the web.

2. Geospatial Data on the Web - Interoperability

Spatial data is prevalent on the web.  Making it accessible for all users requires a variety of approaches based on concepts at the intersection of geospatial information science and WWW information technology.

Core concepts of geographic information in a web setting:

• Maps:  Constructing a map on the web was one of the first breakthroughs in interoperable geospatial web services.  In 1999, there were ten’s of methods for requesting maps on the Web.  This diversity of protocols was duplicative and served no purpose other than to protect lock-in to existing map servers.   This confusion was the major driver for OGC’s first Web Map Testbed resulting in OGC’s Web Map Service (WMS).  Subsequent developments resulted in Web Map Tile Service (WMTS) based on servers having a pre-calculated set of tiles, eliminating the need for creation of custom maps for each user’s request  WMTS provided a significant performance enhancement over WMS custom map requests.
• Features: GIS technology has long focused on Features as the meaningful geographic content.  Development of map services was quickly followed by the development of feature servers on the Web. OGC’s Web Feature Service (WFS) allows users to request feature collections or specific features; with the response containing feature attributes including geometry objects with spatial referencing tied to a chosen Coordinate Reference Systems (CRS). 
• Imagery and Coverages: Remote sensed imagery from satellites quickly became a desired feature of geospatial web services.  Representation of real-world phenomena as numerical values (height of the ground, aerosols in the air, sea surface temperature) often coming from remote sensing or predictive simulations.  The OGC Web Coverage Service (WCS) provides web access to remote sensed imagery as well as gridded environmental data from other sources such as numerical simulations.  The OGC Coverage standard defines how geographic coverages are a type of geographic feature.
• Coordinates:  Spatial representation of geographic data is typically done using coordinates.  Coordinate Reference Systems (CRSs) are the combination of coordinate systems typically in several dimensions combined with a datum that defines how the abstract coordinate system is anchored to physical locations.  For global data, the most popular CRS is WGS84 which is a family of geodetic coordinates based on approximating the shape of the global as an oblate ellipsoid.  The same approach is used for other celestial bodies, e.g., moon, Mars. 
• Spatial Relationships.  Relationships between spatial features is a core of geography.  Spatial proximity of features using well developed mathematical structures of topology define relations like inside of, outside of and features that touch or overlap. The OGC Simple Features Standard defines the topological relationships which are then used in the various OWS. Links between features define relationships without necessarily using coordinates or topology.  Linked Spatial Data builds on hyperlinks readily available in the WWW.  Linked Spatial Data is utilized in OWS and included in data encodings.

Core concepts of WWW information technology relevant to spatial data:

• Distributed computing: Model of computing in which a set of nodes coordinate activities by means of digital messages passed between the nodes.
• Interoperability: Capability to communicate, execute programs, or transfer data among nodes in a manner that requires the nodes to have little or no knowledge of the unique characteristics of the other nodes.
• Service: functionality that is provided by a node through APIs.
• Application Programming Interface (API): set of operations that allow communications with a node.
• Schema:  description of the content, structure and constraints applicable to information in a specific application domain, e.g. geographic feature model.
• Data interchange format:   technology specific syntax for transferring data between nodes, e.g., XML, JSON.  A schema for the interchange may be explicit or implicit in the format.

3. OGC Web Services

Discussions in OGC's WWW Mapping working group gave rise to Web Map Testbed-1 (WMT1), a rapid prototyping initiative in 1999, which produced a draft of the Web Map Service (WMS) specification.  

In the early 2000's, specifications developed in the OGC Interoperability Program became the OGC Web Service (OWS) Standards.   The OGC Interoperability Program provided a novel approach to innovation based on simultaneous implementation and specification development (Percivall 2015). 

OGC Web Services are a collection of open standards that provide interoperability to geospatial data on the WWW (Reed 2011) .

• WMS -  The Web Map Service (WMS) standard provides an HTTP-based interface for requesting geo-registered map images from one or more distributed geospatial databases.  Maps of arbitrary geographic extent can be requested. The response to a WMS request is an image of a map.
• WMTS - The Web Map Tile Service (WMTS) standard provides an HTTP-based interface for requesting map tiles of spatially referenced data using tile images with predefined content, extent, and resolution. The response to a WMTS request are tiled images forming a map.
• WFS - The Web Feature Service (WFS) standard provides an HTTP-based  interface for fine-grained access to geographic information at the feature and feature property level. The response to a WFS request are feature attributes, including geometry, encoded in well known data formats.
• WCS - The Web Coverage Service (WCS) standard provides an HTTP-based interface for requesting multi-dimensional coverage data.  The response to a WCS request are coverage data, e.g., gridded data, attributes, encoded in well known data formats.
• WPS - The Web Processing Service (WPS) standard provides an HTTP-based interface to control geospatial processing services, such as polygon overlay. The standard defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The data required by the WPS can be delivered across a network or they can be available at the server.
• CS-W - The Catalog Services for the Web (CS-W) standard provides the HTTP-binding of the OGC Catalog Service. Catalogue services support the use of one of several identified query languages to find and return results using well-known content models (metadata schemas) and encodings.
• CQL - The Common Query Language was initially specified in the CS-W standard.  As CQL is now used in a variety of services, CQL is now a stand-alone specification.  CQL is a generic filter grammar that can be used to specify how resource instances in a source collection of any item type, including features, can be filtered to identify a results set.

According to GeoSeer, as of March 2024, over 3.5 million distinct spatial datasets are available on the internet served by over 400,000 WMS, WMTS, WFS, and WCS operational services.

4. OGC APIs

OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way (Hobona, 2023). OGC APIs use OpenAPI Specification - a formal standard for describing HTTP APIs -  to define reusable API building blocks with responses in JSON and HTML (OpenAPI 2020). OGC APIs Standards build upon the legacy of the OGC Web Service Standards (WMS, WFS, WCS, WPS, etc.), but define resource-centric APIs that take advantage of modern web development practices.

The OGC API Standards development was initiated to meet the need for innovations about APIs in broader information technology.  During a March 2014 meeting, the OGC Board of Directors initiated discussions that led to development of the APIs the OGC Open Geospatial APIs Technical Paper (Percivall, 2017).  The paper triggered an OGC API Concept Development Study and in part led to a WFS3 Hackathon that created the first version of API-Features.   The OGC Open Geospatial APIs technical paper identified four themes:

1. By 2016, multiple products were defining geospatial APIs: Google Maps, OpenLayers, MapQuest API for OpenStreetMap, Leaflet, Esri ArcGIS REST, Mapbox, others
2. The proliferation and variation of geospatial APIs in products was degrading the interoperability that had been established with OWS standards.
3. Protocols can provide interoperability when implemented consistently across APIs. For example, the OGC WMTS protocol when implemented across multiple APIs enables interoperability to provide a consistent, composite map.
4. Implementation of APIs on resources across the broad distributed computing community, should be used to define OGC API standards to provide consistent implementation of geospatial protocols across multiple APIs. In particular, the OpenAPI specification was used to define OGC API building blocks.

Beginning with the OGC API for Features adopted in 2020, OGC has standardized a set of APIs for geospatial resources and the use of HTTP methods, e.g., Get, Post, to operate on the geospatial resources. The OGC is currently developing a coordinated set of OGC API standards organized by resource types:

• OGC API - Maps -  defines an API that presents data as maps by applying a style. The Standard allows a client application to request maps as images, or change parameters such as size and coordinate reference systems at the time of request, making them implementer-friendly and easily understandable by developers without geospatial experience.
• OGC API Tiles - defines building blocks for creating Web APIs that support the retrieval of geospatial information as tiles. Different forms of geospatial information are supported, such as tiles of vector features (“vector tiles”), coverages, maps (or imagery) and other types of geospatial information. Although it can be used independently, the OGC API — Tiles building blocks can be combined with other OGC API Standards and draft specifications for additional capabilities or increasing interoperability for specific types of data.
• OGC API Features - defines API building blocks to create, modify and query features on the Web. OGC API Features is comprised of multiple parts, each of them is a separate standard. Part 1, the “Core,” specifies the core capabilities and is restricted to fetching features where geometries are represented in the coordinate reference system WGS 84 with axis order longitude/latitude. Part 2 specifies the capabilities for fetching features that have geometries represented in all other coordinate reference systems. Additional capabilities that address more advanced needs will be specified in additional parts.  Currently under development are OGC API – Features – Part 4: Create, Replace, Update and Delete and OGC API – Features – Part 5: Schemas. Part 1 of this standard has also been published as ISO 19168-1: 2020.
• OGC API Coverages - this draft specification defines a Web API for accessing coverages. A coverage is a "function which returns values from its range for any direct position within its domain". Coverages are represented by some binary or ASCII serialization, specified by some data (en­coding) format. A  popular type of coverage is that of a gridded coverage. Gridded coverages have a grid as their domain set describing the direct positions in multi-dimensional coordinate space, depending on the type of grid. Satellite imagery is typically modeled as a gridded coverage.
• OGC Environmental Data Retrieval (EDR) API - defines a family of interfaces to access Environmental Data resources. Each resource addressed by an EDR API maps to a defined query pattern. This specification identifies resources, captures compliance classes, and specifies requirements which are applicable to OGC Environmental Data Retrieval API’s. This specification addresses two fundamental operations; discovery and query. 
• OGC API Processes - supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application. The standard specifies a processing interface to communicate over a RESTful protocol using JSON encodings. The standard leverages concepts from the OGC WPS Standard but does not require implementation of a WPS.

While the OGC APIs are less mature than OWS, the analysis leading to adoption of OGC APIs in future products and programs is well underway (Schleidt 2022).

5. Data Interchange Formats used by OWS

The OGC Web Services and APIs make use of data interchange formats that are defined independently from the services and interfaces.  In order to exchange data between nodes on a network, methods to encode the data are needed. OGC uses the following encodings for geographic data. Some of these encodings were developed from the beginning as OGC standards, e.g., GML. Some of the geographic encodings are based on more general standards, e.g. GeoTIFF.  Some of the encodings were developed by other organizations, e.g. GeoJSON.

• GML - The Geography Markup Language (GML) is an XML grammar for expressing geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet.  The WFS and API Features exchange data in GML. GML is also an ISO standard (ISO 19136:2007).
• CityGML and CityJSON - The CityGML standard defines a conceptual model and exchange format for the representation, storage and exchange of virtual 3D city models. CityGML standardises an information model, and can be implemented in a variety of technologies including GML.  CityJSON is a data exchange format for digital 3D models of cities and landscapes. The JSON-based encoding of CityJSON implements a subset of the OGC CityGML data model.
• IndoorGML - The IndoorGML standard specifies an open data model and XML schema for indoor spatial information. IndoorGML is an application schema of OGC GML. IndoorGML intentionally focuses on modelling indoor spaces for navigation purposes.
• GeoJSON - GeoJSON is an standard for geospatial data interchange format based on JSON. GeoJSON was standarized by the IETF.   It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. GeoJSON uses WGS84 and units of decimal degrees.  OGC is developing Features and Geometries JSON (JSON-FG) for data that is not in WGS84.
• KML - KML expresses geographic annotation and visualization web-based online and mobile maps (2d) and earth browsers (3d). KML was developed for Google Earth as the Keyhole Markup Language.  Google submitted to KML to OGC as a OGC Community Standard.
• GeoTIFF - The GeoTIFF standard specifies requirements and encoding rules for using TIFF format for the exchange of georeferenced or geocoded imagery.  GeoTIFF defines metadata required for describing geographic image data including use of the EPSG Geodetic Parameter Dataset.  Under development is Cloud Optimized GeoTIFF (COG) which aims to be backwards compatible with GeoTIFF.
• GeoPackage Encoding Standard - This standard defines GeoPackages for exchange and GeoPackage SQLite Extensions for direct use of vector geospatial features and / or tile matrix sets of earth images and raster maps at various scales. Direct use means the ability to access and update data in a "native" storage format without intermediate format translations in an environment (e.g., through an API) that guarantees data model and data set integrity and identical access and update results in response to identical requests from different client applications.
• NetCDF - the network Common Data Form (netCDF) standards suite support encoding of digital geospatial information representing space/time-varying phenomena.  The netCDF data model and encodings are particularly well suited to providing data for atmospheric and oceanic science as sets of related arrays.
• HDF5 - The HDF5 encoding standard is particularly suitable to scientific and engineering geospatial applications that employ multidimensional numeric arrays to describe temporally and spatially varying phenomena.

6. Geospatial Web Services Implementations

Implementation is essential to the adoption of open consensus standards.   Implementations based on both open-source or proprietary code were developed in tandem both with the OGC Web Services as well as with OGC APIs.  Both open-source and proprietary code were deployed in OGC Testbeds beginning in 1999 and continuing to this day.  In OGC Web Services Testbed 1, proprietary code was deployed by Compusult, Cubewerx, Esri, Intergraph (now Hexagon), PCI Geomatics, Ionic, Laser-Scan, Polexis, Syncline  and others.  Concurrently and contributing to these early testbeds, projects by the Open Source Geospatial (OSGeo) Foundation implemented and advanced the OGC standards development. 

Today over 400,000 live services from around the world serve geospatial data using OGC standards, according to GeoSeer.  These live services are supported by over 750 products that implement the OGC standards, and over 300 Certified Products have passed OGC Compliance tests and obtained the OGC Trademark License (OGC, n.d.). 

Analysis of OGC standards as part of the academic research and instruction are key to continuing the role of open standards in the future GIS&T technology base.  A study of reviewed papers from the Web of Science (WoS) Core Collection from 1994 to 2020 identified 963 papers that cited OGC standards (Huang 2022). 

The motivation for open standards generally and the OGC standards specifically is to enable technology to support the challenges faced by humanity.  Operational services providing real data to solve real world problems is a measure of meeting this goal.  A key milestone in Web Mapping was NASA’s “WMS Global Mosaic” which was the first map service of full-resolution, global coverage of LANDSAT demonstrated at the United Nations in December 2002 (Percivall and Plesea, 2003).   The WMS Global Mosaic continues on today as NASA’s Worldview server. 

• https://www.ogc.org/publications/ 
• https://ogcapi.ogc.org/
• https://www.ogc.org/resources/compliance/
• https://worldview.earthdata.nasa.gov/