Offering the World

The following is to some extent a continuation of my previous post. In addition to implementing my own styles and filtering I also wanted to investigate using web mapping protocols other then Tile Mapping (TMS – Tile Mapping Service). TMS is the easiest protocol to exploit, is the format offered by OpentStreetMap and other common map providers and is the technology used out of the box by Leaflet, the web mapping application I’m using as part of IPT’s YourMapData solution. However other protocols exist and I wanted to explore if any were better suited to meeting my requirements. And I needed to confirm that each of these could implemented using a QGIS server and Leaflet mapping application.

The results of my investigation are presented below and include:

1. A comparative description of the 4 web mapping protocols.
2. Recommendations when to use each of them.
3. What QGIS server supports.
4. What is supported by Leaflet.

TMS – From One, Many

The Tile Map Service (TMS) was created by the Open Source Geospatial (OSG) Foundation. The goal was something easier to consume by users; performance; and scalability. These came at the cost of less flexibility – images are delivered at fixed scales, with the provider imposing image dimensions, layer selection and styling. Tile maps cover a defined geographic extent but are cut up to form a grid-like matrix of smaller maps which match up at the corners and edges. In this way you can have a digital map that covers a large extent (like the world) but can conserve server resources by only having to provide a few relatively small images at a time. Each tile map consists of one or more tile sets – a tile set is a version of the map at a particular scale and map projection.

The other major characteristics of a TMS are:

• Each tile is the same size – 256 X 256 pixels is standard but other sizes are possible. The actual size of the map displayed in the browser is determined by the web designer and will use as many tiles as necessary to fill in that space.
• Tiles are created dynamically on demand, although a cache of most frequently served tiles is often maintained.

WMTS – Tiles With Options

The Web Mapping Tile Service (WMTS) specification was developed by the Open Geospatial Consortium (OGC) and took the TMS as a starting point. The OGC is a standards setting body that many geospatial providers conform with to ensure data quality and interoperability. WMTS differs from TMS in adding a few new capabilities and making the protocol compliant with the larger OGC framework.

Differences between WMTS and TMS:

• WMTS supports encoding in REST, SOAP and KVP; TMS only uses REST
• In general there is more ability to interrogate the server about what it provides.
• WMTS adds:
  • GetFeatureInfo, which allows the server to respond to a click event e.g. by returning co-ordinates for the map pixel clicked on.
  • Each layer can have more then one style defined.
  • Optionally can provide images to use in constructing a map legend.
  • Optionally can respond to multidimensional data requests. What this means is not only can you request image(s) for a certain geographic extent, you can specify e.g. features as they existed in a certain time period such as 1950.

WMS – One Image to Rule them All

This is one of the oldest protocols and is also an OGC specification. Like the two tiling services a Web Mapping Service (WMS) returns images – unlike TMS and WMTS only one image is ever returned (there are some exotic implementations of WMS that do send multiple, “tiled” images but these represent more of a workaround then a strict adherence to the standard).  WMS continues to be used since it allows for more control for both the requestor and the provider then the tiled services. For instance the requestor can specify a specific image size, and the provider can offer multiple styles for the same map.

The most important features WMS offers are:

• Requestors can select which features (layers) the map includes.
• Providers can offer layers in multiple styles; an optional enhancement to the WMS standard is that requestors can specify their own styles.
• Requestors define the size of images and the map extent.
• The optional GetFeatureInfo operation is supported; viewers clicking anywhere on the map image get additional information as defined by the provider.
• By supporting maps with undefined co-ordinate systems, layers based on hand-drawn images or where the projection is unknown can be displayed (with the caveat that other layers cannot be overlain).
• Multi-dimensions are supported so that you can specify e.g. layer features as they existed in a particular year or at a particular elevation.

WFS – For the Workaholic

A Web Feature Service (WFS) is different from all other standards in the sense that instead of delivering images it provides access to the data itself. As such WFS services are frequently used more for remote editing or extracting subsets of the data then for map viewing. What is delivered to the browser is not the same geographic data format as lives on the server but is a different representation of the same information. This means selection in the browser can be paired up to the equivalent data on the server and transactions to add, delete or modify features can be carried out. Alternatively such selection can be used as a filter or as parameters to download a subset of the data to a local storage drive.

An incomplete list of WFS capabilities includes:

• Describe a feature including its attributes (data fields).
• Return all features or only features matching a query. The requestor may
• Update, insert (add) or delete a feature (NOTE: This updates the data on the server).
• Lock a set of features for editing. What this does is prevent other users from editing the same features and prevents conflicts.

It should be noted that not every WFS implements all of these functions.

Basic WFS: Describes the features, returns the features and can filter based on a stored query advertised by the server (but requestor constructed queries not supported).

Simple WFS: Does everything the Basic WFS does plus the requestor can run custom queries.

 Transactional WFS: Can update, add or delete features on the server.

 Locking WFS: Can lock a selection of features preventing others from editing.

Security on a WFS

None of the web mapping standards discussed implement any security to access the data. If you want to prevent access to all comers you have to implement your own security. This is particularly important if your going to allow transactions on a WFS, since not only are you sharing data but your also giving users the power to alter it.

Some suggested security implementations include:

• Require clients to access via https or vpn.
• Use an unpublished URL (i.e. don’t share the URL except to trusted people). This can be enhanced by basing the URL on a long, randomly generated string.
• Add a query string parameter that includes some kind of id that needs to be validated before the update can proceed.

Choosing a Web Mapping Service

Service	Use when ...
TMS	Maximize performance and scalability Images display only a small part of the total geographic map extent Maps support zooming across a range of scales
WMTS	Everything that applies for a TMS plus: You need to prove adherence to a published standard. You would like to respond in some way when user clicks some part of the map.
WMS	You only need to deliver maps at a fixed scale. You want to enable users to select the map extent, image size and which features to display. You want to offer multiple styles. Display maps that are not in a known projection system. Display a published map with elements such as North arrow, legend, annotation, scale bar, embedded images.
WFS	Users need to download the underlying data. Users need to able to update the data on the server. You want to filter which features to show based on their attributes (e.g. show only major highways).

QGIS Support for Services

Service	Level of Support
TMS	No GUI interface to setup Can be implemented via manual configuration (plus some additional extensions to QGIS) TileLayer plugin implements a tile map solution but not one strictly compliant with TMS specification
WMTS	Not supported natively and little evidence that anyone is trying to implement a WMTS on QGIS
WMS	Supports the following capabilities: GetCapabilities GetMap GetFeatureInfo GetLegendGraphic (SLD profile) DescribeLayer (SLD profile) GetStyles (custom QGIS profile) + extra parameters such as File_Name (response is sent as a file with the File_name specified), Map (path to the QGIS project file), setting DPI, Opacity, Filter (by attribute),Selection (selected features highlighted)
WFS	Supports the following capabilities: GetCapabilities DescribeFeatureType GetFeature Transaction + extra parameters such as File_Name (response is sent as a file with the File_name specified), Map (path to the QGIS project file)

Leaflet Support for Services

Service	Support
TMS	Fully supported by Leaflet and what is typically used as the base map (Tile Layer).
WMTS	Not supported at all.
WMS	Limited support through the built-in L.tileLayer.wms. Some of the limitations include browser failure to load large images and poor labeling (because Leaflet will try to label each point or line). Also, you need to know the layer names beforehand and hard code them as parameters; or add a bunch of custom code that gets layer names from the metadata document and plugs these into the Leaflet code. The Leaflet.wms plugin adds GetFeatureInfo support and allows the manipulation of all layers from the same source as a unit.
WFS	Not supported out of the box. Some plugins exist - AZGS L.GeoJSON.WFS works only if the output format is GeoJSON, other plugins are often specialized for specific servers.

References

http://www.opengeospatial.org/standards

http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification

http://gis.stackexchange.com/questions/5686/securing-wms-against-unauthorized-access

http://gis.stackexchange.com/questions/9191/how-to-secure-wfs-services

http://docs.qgis.org/1.8/en/docs/user_manual/working_with_ogc/ogc_server_support.html

http://docs.qgis.org/testing/en/docs/user_manual/working_with_ogc/ogc_server_support.html