15 Open Geospatial Consortium (OGC) services
The Open Geospatial Consortium (OGC) is an international industrial consortium with more than 500 companies, government agencies, and universities participating in the creation of publicly available geospatial standards. These standards support interoperable solutions including spatial data in Web, wireless, and location-based services in the IT industry in general. They also enable persons and organizations working on technological development to produce complex solutions in the field of spatial information and services, which will be useful and usable will different types of applications and on different platforms.
OGC develops interfaces for geospatial Web services relying on W3C protocol for Web-based information exchange. Web services function through interfaces and operations enabling exchange of information with certain coding. The service represents functionalities which is offered by an entity through a collection of interfaces. In this sense, an interface contains a set of requests that the user can send to the entity to perform a certain process (e.g., query or transformation of data). Typically, the interface defines operation names, a collection of necessary parameters that the user inputs and their allowed values. In the context of Web services, an operation represents a request sent to the server. Some of the used standards are WMS, WCS, WFS, WPS, and SLD.
15.1 WMS (Web Map Service)
Web Map Service (WMS) is a standard protocol within HTTP for servicing georeferenced raster images via the Internet; practically, WMS delivers cartographically stylized spatial layers, Figure 15.1. These layers can be used as background maps within a GIS application, or they can be part of a Web map. Serviced images are typically in JPEG or PNG formats (not as source GIS files, as WCS does), and the service supports transparency settings, i.e., it is possible to overlap several layers at once.
.](_media4/image2.png)
Figure 15.1: Scehmatized representation of Web services. © CartouCHe 2004-2007 (Creative Commons).
OGC realized several versions until now:
WMS v. 1.0.0, April 2000;
WMS v. 1.1.0, June 2001;
WMS v. 1.1.1., January 2002;
WMS v. 1.3.0, January 2004.
The WMS protocol is implemented in a large number of applications, both commercial and free or open source ones. Two most-often used open code implementations are GeoServer (described in one of the following chapters) and Mapserver. Popular commercial versions are ArcGIS Server, ArcIMS, GeoMedia and others.
This protocol prescribes parameters of queries made towards serviced layers (Figure 15.2), with the most important ones being
GetCapabilities – provides a description of the server (WMS settings), and a list of available layers,
GetMap – returns a raster image depending on the parameters defined in the query (requested layers, coordinates of frame edges, etc.).
.](_media4/image3.png)
Figure 15.2: GetMap and GetCapabilities queries, source © CartouCHe 2004-2007 (Creative Commons).
Beside the above mentioned query parameters, depending on the implementation, the WMS user can also use the following queries to access information: GetFeaturerInfo (obtaining attribute data), DescribeLayer (obtaining additional layer information), GetLegendGraphic (obtaining a cartographic display legend).
Furthermore, when receiving data using WMS queries, it is necessary to define additional parameters: Layers (selecting chosen displayed layers), Styles (combining styles for visualizing spatial data), SRS/CRS (defining a desired coordinate system), Height and Width (height and width of the output image), Format (output image format), etc.
An example of a simple GetMap WMS query for a seismic layer is: “Map of local ground surface intensity for a return period of 975 years.” This layer is serviced via a Geoserver which is part of the Laboratory for developing open source geospatial technologies at the Faculty of Civil Engineering Belgrade, http://osgl.grf.bg.ac.rs. The layer name in the Geoserver application is povrsina_lokalnosti_975_region.
As a result of this query (written into the address line of an Internet browser), a raster image of the target area will be displayed, Figure 15.3. The first part of the query is separated from the rest by the question mark ‘’?’‘, and other parts are separated with the ampersand’‘&.’’
Figure 15.3: WMS GetMap, Seizmic Hazard Maps: Intensity on local soil, average return period for 975 years
http://osgl.grf.bg.ac.rs/geoserver/osgl_3/wms # wms server address
?wms&version=1.3.0 # service and version
&request=GetMap # WMS query
layers=povrsina_lokalnosti_975_region # queried layer
&bbox=18,40,24,48 # spatial range
&width=512&height=512& # display size in pixels
format=image/png # display formatA table 15.1 with all GetMap query parameters is provided below.
| Parameter | Required? | Description |
| service | Yes | Service name. Value is WMS. |
| version | Yes | Service version. Value is one of 1.0.0, 1.1.0, 1.1.1, 1.3.0. |
| request | Yes | Operation name. Value is GetMap. |
| layers | Yes | Layers to display on map. Value is a comma-separated list of layer names. |
| styles | Yes | Styles in which layers are to be rendered. Value is a comma-separated list of style names, or empty if default styling is required. Style names may be empty in the list, to use default layer styling. |
| srs or crs | Yes | Spatial Reference System for map output. Value is in form EPSG:nnn. crs is the parameter key used in WMS 1.3.0. |
| bbox | Yes | Bounding box for map extent. Value is minx, miny, maxx, maxy in units of the SRS. |
| width | Yes | Width of map output, in pixels. |
| height | Yes | Height of map output, in pixels. |
| format | Yes | Format for the map output. See WMS output formats for supported values. |
| transparent | No | Whether the map background should be transparent. Values are true or false. Default is false |
| bgcolor | No | Background color for the map image. Value is in the form RRGGBB. Default is FFFFFF (white). |
| exceptions | No | Format in which to report exceptions. Default value is application/vnd.ogc.se_xml. |
| time | No | Time value or range for map data. See Time Support in GeoServer WMS for more information. |
| sld | No | A URL referencing a StyledLayerDescriptor XML file which controls or enhances map layers and styling |
| sld_body | No | A URL-encoded StyledLayerDescriptor XML document which controls or enhances map layers and styling |
The GetCapabilities operation is a protocol by which server metadata is requested in a format readable for computers and humans, typically XML, Figure 15.4. The message content contains information on server data and parameters which can be forwarded. The following example illustrates the use of GetCapabilities queries:
http://osgl.grf.bg.ac.rs/geoserver/osgl_3/wms?service=wms&version=1.3.0&REQUEST=getcapabilities
Figure 15.4: The result of the GetCapabilities query in an Internet browser.
The following is an example of an individual layer decription using the DescribeLayer query:
{"version":"1.1.1",
"layerDescriptions":[{"layerName":"osgl_3:povrsina_lokalnosti_975_region",
"owsURL":"http://osgl.grf.bg.ac.rs:80/geoserver/osgl_3/wfs?",
"owsType":"WFS",
"typeName":"osgl_3:povrsina_lokalnosti_975_region"}]
}The GetFeatureInfo operation requires attribute data for a layer on a specific location.
GetLegendGraphic is a query for downloading legends, Figure 15.5.
Figure 15.5: The result of GetLegendGraphic query.
15.1.1 WMS Tile Caching (WMS-C)
The WMS Tile Caching (WMS-C) standard is an upgrade of the WMS protocol, and its purpose is to speed up the delivery of raster images of certain areas’ cartographic displays. This is achieved using prerendered cashed images which typically cover a significantly smaller area than required by the user. Combining a large number of images into a rectangular grid through tiling or tessellation, the coverage of a much larger area is achieved.
Although this method significantly speeds up the process of delivering spatial data images to the end-user, it has certain limitations due to the way it is performed. Since images are prerendered, during querying, the user cannot change the image’s appearance by defining additional parameters in the query. For example, visualization different from the prerendered one is disabled, the data output format is fixed, layers cannot be displayed or hidden according to user’s choices, image height and width are predefined, and the WGS 84 coordinate system is exclusively used.
In case the WMS-C proxy server receives a full WMS query (with all arguments defined in it), the server returns an error message or redirects the query to a classical WMS server. In that case, the speed of cartographic image delivery is lost.
The WMS-C protocol uses the NASA World Wind service to display satellite images of Earth’s surface. Services such as Google Maps operate in a similar way to the WMS-C protocol, thus enabling a fast and efficient spatial data image delivery to a large number of users simultaneously.
15.1.2 Tile Map Service (TMS)
The Tile Map Service (TMS) is a standard set up by OGC, enabling access to cashed images of georeferenced data. This standard defines the ways in which a user requests image units (tiles), which are then arranged in a rectangular grid to achieve a cartographic display of an area.
Using this protocol, similar to the WMS-C protocol, the user takes prerendered tiles already cashed on the server. The tiles are available only in predefined scales, they contain predefined layers, they are in a predefined projection, etc. For example, changing the scale, the user takes another string of tiles. This means that the server does not prepare the display of spatial data after the user’s query; rather, a collection of tiles is already cashed.
The advantage of this way of servicing spatial data is the speed of delivering images of an area (which is easily noticeable if the service based on this protocol is used by a large number of clients). The disadvantage of this standard is its inflexibility, i.e., inability of adjusting spatial data display according to specific user needs.
15.2 Web Features Service (WFS)
Web Features Service (WFS) is a protocol which enables the downloading and editing of spatial data over the Internet, using standardized queries. Just as the previously mentioned standards, it is developed and maintained by OGC.
WFS service versions are 2.0.0, 1.1.0, and 1.0.0.
Unlike the WMS protocol, which delivers a raster image of the requested area as a result of each query, the WFS protocol practically enables downloading source vector data.
This form of data enables the execution of much richer analyses in further work (editing the visualization style of spatial data, combining with other spatial data, downloading the data by the user, etc.), instead of simply viewing a map, as is the case with the WMS protocol.
Spatial data downloaded with WFS are typically delivered to the user in Geography Markup Language (GML) format. Besides GML, formats such as ESRI Shape, JavaScript Object Notation (JSON), and others, can be used.
Besides downloading spatial data, an extended specification called the Transactional Web Feature Service (WFS-T) protocol enables editing in terms of creating new or deleting and editing existing data. Additionally, it is possible to lock spatial data, which is used in situations when multiple users are accessing a single data set simultaneously. Standard WFS queries are:
GetCapabilities – for downloading service, layer, and parameter descriptions.
DescribeFeatureType – for XML structures enabling the client to parse results.
GetFeature – for downloading vector entities.
GetGmlObject (available only for version 1.1.0) – for a vector entity (element) received with the forwarded element ID.
Transaction (optional) for editing an element (operations: creating, updating, or deleting entities).
LockFeature (optional) for disabling editing entities in a time interval or indefinitely (important in cases when multiple users are working on data modification simultaneously).
A WFS request is sent via HTTP from the user device to the server which then chooses which information will serve, depending on the request parameters. The server then sends the user a response in the form of geometry with attributuse, e.g., in GML format.
Figure 15.6: Schematic view of a WFS GetCapabilities request ( © CartouCHe 2004-2007 (Creative Commons))
The following example illustrates the GetFeature request for receiving two points from a layer representing temperature trends in Serbia for the period of 1970–90; the service is describe on the metadata server OSGL Beograd.
{
"type": "FeatureCollection",
"totalFeatures": 64,
"features": [
{
"type": "Feature",
"id": "tac_trends_annual.1",
"geometry": {
"type": "Point",
"coordinates": [
504984.47472919,
4810811.705007
]
},
"geometry_name": "the_geom",
"properties": {
"Stanice": "Aleksandrovac",
"NV": 360,
"temp50": 10.74,
"temp1": 10.29,
"trend1": -0.05049,
"sgn1": 1,
"amp1": 10.31,
"temp2": 11.15,
"trend2": 0.03703,
"sgn2": 0,
"amp2": 10.61,
"cor": 0.5457,
"god_p": 1985,
"trend1_dec": -0.5049,
"trend2_dec": 0.3703
}
},
{
"type": "Feature",
"id": "tac_trends_annual.2",
"geometry": {
"type": "Point",
"coordinates": [
616218.37037067,
4769607.0385912
]
},
"geometry_name": "the_geom",
"properties": {
"Stanice": "Babusnica",
"NV": 495,
"temp50": 10.04,
"temp1": 9.69,
"trend1": -0.00839,
"sgn1": 0,
"amp1": 10.07,
"temp2": 10.62,
"trend2": 0.06799,
"sgn2": 1,
"amp2": 10.84,
"cor": 0.5299,
"god_p": 1992,
"trend1_dec": -0.0839,
"trend2_dec": 0.6799
}
}
],
"crs": {
"type": "name",
"properties": {
"name": "urn:ogc:def:crs:EPSG::3046"
}
}
}The first section of the request provides the Internet address of the server containing the requested spatial data. This section is separated from the rest of the query with the question mark ‘’?’’.
The second section is mandatory and defines the protocol to be used for receiving the requested spatial data. In this case, it is the WFS protocol described in this section. The third section is also mandatory if the WFS protocol is used, and it defines the version of the protocol to be used.
The fourth section defines the action which the user wants the server to perform. In this case, data is downloaded in the form of geometry with attributes; hence, the GetFeatures operation is used. Then, the number of entities to be prepared and their format is given, GeoJSON.
When using the WFS protocol, it is possible to use the following parameters:
- sortBy – sorts data depending on their attributes (which can be multiple, separated with a comma),
- bbox – defines the range boundaries with two pairs of comma-separated coordinates.
15.3 Web Coverage Service (WCS)
The OGC Web Coverage Service (WCS) is a standard which enables receiving raster data comprising a single spatial coverage: digital geospatial information modeling spatially-variable phenomena, fields, or a raster approach.
Stated more simply, what WCS is for raster data that which WFS is for vector data. Hence, one of the main functionalities of this service is the ability to receive published source raster. WCS has several versions, with 2.0.1 being the most recent.
It is necessary to draw a distinction between WCS and WMS. These services are very similar and can provide the client with similar raster formats, but WCS enables a larger amount of feedback information, including metadata on the chosen raster, as well as a larger number of available raster formats which are georeferenced and can be used in any GIS software. The result of queries sent to WCS can be used for more complex modeling and analysis, enabling the extraction of a larger amount of information from published data. Queries which can be sent by the client can also be defined for a part of the range, not necessarily for the entire raster. For example, if the published raster is a Digital Elevation Model (DEM), during a WMS request for DEM, the server response would not differ significantly from a scanned DEM map which is useless in GIS tools without prior georeferencing since it contains only pixel coordinates, if used without a cartographic service.
Every WCS service supports three interfaces: GetCapabilities, DescribeCoverage, and GetCoverage.
A query example is given for a layer representing average temperatures in Serbia, and the service is described at OSGL Beograd katalogu metapodataka.
The parameters are similar to previous examples.
15.4 Web Processing Service (WPS)
Web Processing Service (WPS) is a standard interface which provides access to predefined processes on spatial data. WPS contains control operations for process initiation, as well as control, and monitoring of process (i.e., algorithm) execution. Such an algorithm execution process typically produces new data which can be spatial data or new information based on spatial data.
Key operations supported by WPS are the following:
GetCapabilities – Provides metadata on the service with a list of provided processes.
DescribeProcess – Provides a detailed description of the process with an explanation of input and output parameters.
Execute – Serves to initiate a server process using input parameters necessary to return output parameters.
Furthermore, if the server offers asynchronous processes, three additional requests are possible:
GetStatus – For the status of a job executed asynchronously.
GetResult – For receiving results of an asynchronous process.
Dismiss – For termination of an asynchronous process.
Besides the previously mentioned OGC standards, there are many more which can be applied for different purposes; a list of all available standards is given at http://www.opengeospatial.org/standards/common.