Introduction to OGC

From the OGC home page :

The OGC (Open Geospatial Consortium) is an international not for profit organization committed to making quality open standards for the global geospatial community. These standards are made through a consensus process and are freely available for anyone to use to improve sharing of the world’s geospatial data.

OGC provides standard for both data and protocols to exchange it.

Data standards

Some example of standards at the data level include:

  • GML (Geographic Markup Language), a XML dialect used to exchange both vector and raster data
  • KML (Keyhole Markup Language), a XML dialect used to exchange mostly vector data and control its visualization
  • NetCDF, a multi-dimensional raster format commonly used in science and metereology
  • GeoPackage, a “database in a file” format storing vector and raster data in a sqlite database,

GeoServer supports the above as either inputs or outputs.

Styling standards

OGC created SLD (Styled Layer Descriptor) and SE (Symbology Encoding) as a way to allow interchange of styles between GIS systems. These are XML dialects, not easy to write, but made popular even as direct editable ones by their GeoServer adoption. See more about these, and other simpler to use styling languages, in the Pretty maps with GeoServer section.

Protocol standards

Protocols define how a network communication between two system should take place. OGC defined several protocols, that the INSPIRE directly aptly classifies in the following classes, based on their nature:

  • Discovery services
  • View services
  • Download services
  • Transformation services

Protocols summary view

The idea is simple, a user would first use discovery to locate the data of interest, then use a view service for a visual inspection, and when satisfied, eventually download the data for offline usage, or use a transformation service to perform an online spatial analysis.

Discovery services are implemented using CSW (Catalog Services for the Web), a protocol designed to lookup data and services by querying their metadata. An interaction with a CSW (e.g., GeoNetwork) typically results in finding links to other OGC protocols to view and download the data. GeoServer has a CSW module that’s still in its infancy, this training does not yet cover it.

View services are implemented using WMS (Web Map Service) and WMTS (Web Map Tile Service), both designed to allow a client to view maps that some organization prepared. These are the easiest services to use and understand, they simply provide a list of maps that a user can view and combine, eventually query, but not modify or change the style of. You can learn more about WMS in Pretty maps with GeoServer and about WMTS in Caching maps with GeoWebCache

Download services are implemented using WFS (Web Feature Service) and WCS (Web Coverage Service). Both protocols allow downloading the source data behind maps, either in vector (WFS) or raster (WCS) form, allowing to perform the following extra actions during the download:

  • Spatial filtering (e.g., by bounding box), thus extracting only a certain subset of the data
  • Alphanumeric filtering (only WFS), or extraction by time (also WCS)
  • Selection of attributes of interest (WFS) or bands (WCS)
  • Change of map projection
  • Rescaling (only for WCS, e.g., allows to download a version of raster at a lower resolution to save on bandwidth)

WFS is covered in Delivering Raster Data while WCS is covered in WCS requests for multidimensional coverages.

Transformation services are used to perform online spatial analysis on vector and raster data. The protocol is in this case WPS (Web Processing Service) and is covered in _geoserver.wps

Common requests in protocol standards

In order to interact with a service a client makes requests, each one has a different role and different services show different calls, but there are a few commonalities.

Here are common requests and their meaning:

  • GetCapabilities: this is the only request present in all protocols, and it returns a long XML document describing what the server can do and what it contains. It allows the client to discover which parts of a protocols are actually supported (some can be optional), what formats are supported in return, and which “subjects” or “contents” are available in the server (might be maps, vector data, raster data, and so on)
  • Describe<Content>: present in some protocols, it allows to get some more information about a particular content delivered by the server. For example, DescribeFeatureType in WFS provides the list of attributes for a particular vector layer, while DescribeProcess in WPS describes inputs and outputs of a spatial analysis process.
  • Get<Content>: this call retrieves the particular content, normally providing extra parameters to control the production/extraction of the output. For example, we have GetMap in WMS, GetFeature in WFS, and GetCoverage in WCS

These requests are normally performed in sequence by the client, each one enabling the usage of the next.


A client interacting with a WFS server

Ways to encode requests

Requests in OGC protocols can normally be performed using two different paradigms:

  • KVP or Key Value Pair, it’s a simple URL that sports all the requests parameters as pairs of keys and values in the query string. The HTTP request is a GET in this case. Here is an example of a WFS GetFeature in KVP mode:
  • XML POST, in which a XML document describing the request is sent to the server as a HTTP POST request. Here is an example of a WFS GetFeature using HTTP POST mode:

    <wfs:GetFeature service="WFS" version="1.0.0"
        <wfs:Query typeName="topp:states">
              <gml:Box srsName="">
                 <gml:coordinates>-75.102613,40.212597 -72.361859,41.512517</gml:coordinates>