Introduction to OpenStreetMap and Computer Maps

Introduction

This article provides an introduction into open and free computer cartography. We will discuss the underlying technology and concepts as well as practical aspects such as using online maps, self-hosting maps, creating custom maps and map content, and contributing new or improved data.

The main components of an end-to-end cartography solution are:

On the server side:

1. A geographic database of all features, such as roads, buildings, playgrounds, parks, rivers, lakes, administrative boundaries, and so on

2. A rendering system, which combines geo features, map backgrounds (e.g. elevation lines or satellite images), and stylesheets to produce map images (so-called “tiles”)

3. A tile server, which invokes renderer and/or serves cached tiles using protocols such as WMS, TMS, KML, or Slippy (all of which are based on top of HTTP)

4. An optional proxy server which caches data for offline use or translates between various input and output formats for wider application compatibility

On the client side:

1. An optional proxy server which caches data for offline use or translates between various input and output formats for wider application compatibility

2. Viewer programs (in-browser or as standalone apps), which load and display map tiles and allow interaction with the map

3. Editor programs (in-browser or as standalone apps), which allow not only viewing but also editing the map

4. And, in case of editing, some underlying data that is used for making maps edits, such as GPX traces or legally-accessible map databases

Let’s look into each of those components and how they are used within the OpenStreetMap (OSM) ecosystem.

Geographic Database (OpenStreetMap)

OpenStreetMap (OSM) is a project that was originally started by Steve Coast in 2004.

OSM is producing and maintaining a free, unrestricted geographic database of the whole world. Everyone can view data, and everyone with an account can edit data. The OSM project is also organizing documentation and tools needed for creating, managing, and using that data.

OSM initially started as a tool to map streets, but it quickly grew to mapping all features – from all kinds of roads, ways, buildings, parks, and infrastructure (e.g. pipelines) to small items like individual trees, postboxes, phone booths, and toilets.

OSM also contains data about entities that are not identifiable from landscape itself, such as administrative boundaries, country borders, details of land use, bus routes, etc.

In a word, OpenStreetMap aims to have a record of every feature on the planet.

The project does not expect contributions to be perfect – it fully accepts an iterative approach where every new contributor interested in parts of the map will improve map data if needed.

OSM does not use any existing geographic information system (GIS) format to store data. It uses its own data model, whose primary characteristic is that it is simple and optimized for editing. It is the duty of client programs to interpret and display data in a way best suited for their purpose.

Finally, OSM does not restrict or prescribe usage in any way. Users can focus on whatever aspects they find important. For example, hiking, skiing, and cycling routes have always been very well represented in OSM. To get a usable custom map sometimes it even enough to just add (or verify) your routes on the OSM map and use a customized stylesheet to emphasize desired elements over the rest.

The standard data interchange format for OSM is XML. Users are not required to view or edit XML because applications abstract those parts behind GUI options and features, but being familiar with the format is helpful for understanding OSM and using the OSM API. In parallel, availability of JSON in tools has been increasing, helped by standardizations such as GeoJSON.

Naming Confusions in OSM

Important for a successful start with OSM is knowing that it uses uniquely confusing terminology for almost all of its main elements. It stems from Steve Coast’s very narrow initial scope of the project as well as his British English origin.

Here is a list of the most important naming confusions, to help put things in perspective:

• OpenStreetMap includes “Street” in its name, but is used for mapping all possible geo features, not just streets

• OSM has three basic database elements. One of them is called a “way”, which would intuitively imply some sort of a road or transport path. But “ways” in OSM are just lists of points that are physically connected. So they are completely generic and used for marking everything, from streets (which are lines and have a direction) to boundaries of objects (which are closed loops, and whose direction is usually ignored). Examples of boundaries include edges of buildings, parking lots, playgrounds, rivers, lakes, country borders, etc.

• All roads, trails, paths, and land-based routes in OSM, regardless of size and classification, are called “highways” and have a base tag of highway=*. The value for highway= can then be motorway, trunk, primary, secondary, tertiary, residential, track, service, pedestrian, unclassified, etc.

• All geographical boundaries, from continents and countries to suburbs and villages, are called “places” and have a base tag of place=*. The value for place= can then be country, state, region, province, county, district, subdistrict, city, town, farm, etc.

• All items on the map are called “amenities” and have a base tag of amenity=*. They include everything from single-point elements (like trash cans and postboxes) to polygons such as restaurants, bars, schools, boat rentals, taxi stops, banks, doctors, etc.

These naming choices are ultimately not a showstopper, but they require getting used to.

Community

OpenStreetMap is made possible by a large community of users who survey the land with sufficiently accurate GPS receivers and by free or donated maps whose data is imported into OSM.

The main OSM wiki page is https://wiki.openstreetmap.org/ and it takes a while to get familiar with its main sections and groups of pages. There are many pages on the Wiki – many of them are interesting for reading once or twice initially, but later usually only a couple pages will be visited on a regular basis.

Arguably the most important and heavily used page on the wiki is Map Features, a reference for commonly used tags.

Another important page is OSM Software, which serves as an entry point into finding the right applications and software to use with OSM.

OSM also maintains a Platform Status page with the current status of all services.

The best place to get live help from other mappers is on the Internet Relay Chat (IRC). The most popular place is channel #osm at OFTC.

Other resources worth mentioning are the Open Source Geospatial (OSGeo) Wiki, the Open Geospatial Consortium (OGC) repository of standards, and Switch2OSM which contains useful, practical tutorials.

OSM Map in Action

OpenStreetMap data can be browsed at https://www.openstreetmap.org/.

Basic and intuitive use of the map includes searching for places, moving around the map, and zooming in and out.

Apart from that, the following menu items in the sidebar on the right may be useful:

• Layers (4th icon) – ability to choose the base (background) layer. Different layers display or emphasize different map features, making them more suitable for a particular purpose (e.g. city traffic routing vs. offroad cycling).

  “Cycle Map” is a good example of a specialized base layer; it shows cycle networks overlaid on the background of contour lines showing height. It was one of the first alternative renderings of OpenStreetMap data, and it also has its own website at https://www.opencyclemap.org/.

• Add a note to the map (7th icon) – ability to add notes to the map. But beware – OSM notes cannot be deleted (only hidden), and in general notes should not be used!

• Query features (last icon) – ability to click on a feature and display its location, tags, and latest changeset. By following the changeset ID link, one can then see its author and revision history. The same functionality on a larger scale can be obtained by enabling “Map Data” under Layers; afterwards, just clicking on a feature’s edge will open the same information

The center of the map is always reflected in the web browser’s URL. Copying the URL allows sharing the chosen position and view with others. A more detailed sharing link with a marked pin can be obtained by clicking Share (6th icon) in the sidebar on the right.

Also, any map region that is currently in view can also be exported as XML by clicking Export among the options on the top-left. The map coordinates will be filled in automatically, but can be overridden. The view to export must be within size limits and contain less than 50,000 nodes.

More guidance on efficiently using the map can be found in OSM - Browsing the map.

OSM Database, Primitives, and Tags

Features that are rendered and visible on map images come from the OpenStreetMap’s database.

As already mentioned, OSM uses its own data model that prioritizes simplicity of creating and editing data.

The model contains only three basic database elements, combined with a free-form tagging scheme.

The three elements are nodes, ways, and relations. Because there are only three, they are used everywhere and even for purposes that are not immediately obvious, such as for the earlier-described outlining of buildings (and all areas) with closed “ways”.

Primitives are generic and do not have an intrinsic meaning. What gives them meaning are tags attached to them, that clients need to interpret. Tags are key=value pairs, and even though they can be arbitrary, users are certainly expected to use common tag names and values. After all, if something is marked with a newly introduced name or value, chances are it won’t be recognized by existing tools.

Let’s look at the basic elements and concepts in more detail.

Nodes

Nodes are actual points on the map. They are the only primitive that has position. All other primitives rely on nodes for location.

Nodes are used for two purposes:

• As standalone elements, to mark points of interest, such as junctions between two ways, sightseeing points, water fountains, or postboxes

• As part of ways or areas, as points where features change direction (e.g. road curves, corners of buildings, etc.)

Nodes’ 7-decimal latitude and longitude used by OSM give latitudinal resolution of 1 cm, and longitudinal resolution of 1 cm at the equator or around 0.6 cm at Greenwich.

The OpenStreetMap API doesn’t check for duplicate nodes, so it is possible to have two nodes in exactly the same place. There are tools that check for duplicate nodes and do other map management functions.

XML data for a node may look like the following:

<osm version="0.6" generator="OpenStreetMap server">
<node id="483034256" lat="55.9458449" lon="-3.2035477" version="1" changeset="2369219" user="spytfyre" uid="166957" visible="true" timestamp="2009-09-04T13:35:42Z">
<tag k="name" v="The Blue Blazer"/>
<tag k="amenity" v="pub"/>
</node>
</osm>

Ways

As mentioned earlier, “ways” are ordered lists of connected nodes, minimum two, from the first to last. They can describe linear features, such as roads, or closed loops that have an outline and surface, such as buildings, parking lots, lakes, or administrative boundaries.

Ways exist in the database independently from nodes they contain – a node does not change when it is made part of a way, and a way does not change when its existing nodes are modified (for example, when their coordinates change). This approach has interesting consequences – even if you move all nodes in a way to a different position, no new version of the way will be created and no change will show up in the way’s history. That’s because the way itself (the list of connected nodes) did not change.

Nodes in a way have an implicit direction which runs from first to last node in the list. Most editors indicate direction with arrows. The direction might not always be important, depending on what is being described. For example, it is important for one-way streets, but not for outlines of buildings.

When used to describe linear features, points in a way should be placed along the center line of the feature (e.g. middle of the road); when used for surfaces, they should be on the edges (e.g. outer borders of buildings).

If the first and last node of a way are the same, the way forms a closed area which can be tagged to indicate what the area represents. If a more complex shape than a simple polygon is needed to describe a feature, such as a building with a courtyard in the middle, or a forest with a clearing, this is done by using several separate ways and adding a “relation” to describe their relationship.

Note that there is no technical restriction that would prevent a closed way from self-intersecting. However, that would create problems with renderers and should be avoided.

Ways can cross without being joined (e.g. roads below bridges), so it is safe to assume that ways are physically connected only when they actually share nodes.

Relations

Relations are lists of other primitives (including other relations) with associated tags. Relations exist to allow mappers to model features that can’t be described using a single node or way, or where two of the same type of feature overlap. Examples include complex street branches, long distance routes, or turn restrictions at junctions.

Relation’s child elements are a list of members and a list of tags. Each member element has the usual attributes, plus a role.

The role attribute is a simple string whose values and significance are defined by the type of relation itself. The role can be left blank for relation types that don’t require one.

In the following example, type is given as a restriction at a junction, members show the route that’s illegal to take using the node representing the junction with turn restriction, and ways representing the roads that shouldn’t be accessed:

<osm version="0.6" generator="OpenStreetMap server">
<relation id="113421" visible="true" timestamp= "2009-11-03T10:08:27Z" version="2" changeset="3023369" user="Jonathan Bennett" uid="5352">
<member type="node" ref="270186" role="via"/>
<member type="way" ref="4418767" role="from"/>
<member type="way" ref="4641665" role="to"/>
<tag k="restriction" v="no_right_turn"/>
<tag k="type" v="restriction"/>
</relation>
</osm>

This particular relation represents a turn restriction, and does not render visually on maps. It is used by a routing algorithms to avoid making an illegal turn. There are many other types of relations, and this is maybe the least mature part of OpenStreetMap’s data model.

Common Attributes

There are some low-level attributes common to all primitives:

• Type (node, way, or relation)

• Per-type unique ID

• Version number

• Last modification timestamp

• Changeset ID (the ID of last write that affected this element)

• Display name and ID of last user (changeset author)

Tags

In addition to common attributes, primitives can have an unlimited number of tags attached to them.

Tags give primitives their meaning; they tell what individual features are. The OpenStreetMap data model can be viewed as a mixed graph consisting of vertices and edges.

Each tag is a simple key=value pair, where keys and values are strings and can contain up to 255 UTF-8 characters.

Only one value per key is supported, so if one needs to record multiple values for a particular key, the normal practice is to use a prefix or suffix to the key, separated by a colon. Most commonly this is used for place names in multiple languages. For example, the node for London gives its name in many different languages as follows:

<osm version="0.6" generator="OpenStreetMap server">
<node id="107775" lat="51.5072647" lon="-0.1278328" version="29" changeset="2628959" user="EdinburghGael" uid="170586" visible="true" timestamp="2009-09-25T23:04:28Z">

<tag k="place" v="city"/>
<tag k="is_in" v="England, United Kingdom, UK, Great Britain, Europe"/>
<tag k="capital" v="yes"/>

<tag k="name:zh" v="伦敦"/>
<tag k="name:sv" v="London"/>
<tag k="name:fr" v="Londres"/>
<tag k="name:cy" v="Llundain"/>

</node>
</osm>

Use key=value when value is known, or key=* for a key with no particular value.

You may notice <tag k="amenity" v="pub"/> – that is OSM’s syntax for recognizing a POI as a pub. Tags are covered in more detail below.

The only child elements of nodes are tags attached to them.

Features / POIs / Waypoints

There are many points and areas of interest in the real world besides obvious things like streets and buildings. Somewhat confusingly they are also called “waypoints”.

For example, single-point features may include street items, such as postboxes, bus stops, and telephones. Areas features may include things such as parks, playgrounds, and pedestrian zones.

All these items are not represented in OSM in any special way – they are just usual nodes or ways with appropriate tags attached.

Changesets

Changesets aren’t part of the data model, but are groups of changes made to data primitives, sort of like transactions in database terms.

Changesets were introduced to make it easier to identify related changes on the map, and to tidy up attribution of data.

Changesets are opened by editor applications before uploading any edits, then closed once they’re done. Every edit to OpenStreetMap data must be assigned to a changeset. One mapper can have any number of changesets open at any time, although idle changesets are closed automatically by the server after one hour.

The first thing you’ll notice is that the changeset XML doesn’t contain any details of changes. If interested in changes themselves, you can download a separate XML file containing them.

Changeset data contains an ID, mapper’s display name, mapper’s user ID, timestamps for when the changeset was opened and closed, and the four corners of the bounding box for the changeset. Bounding box is the smallest rectangle that contains all the edits in the changeset, and can be very large if the edits in it are far apart.

An XML for a changeset looks as follows:

<osm version="0.6" generator="OpenStreetMap server">
<changeset id="1787116" user="Jonathan Bennett" uid="5352" created_at="2009-07-10T09:52:28Z" closed_at= "2009-07-10T09:52:31Z" open="false" min_lon="-4.4224237" min_lat="56.1382502" max_lon="-3.9613266" max_lat="56.6330162">
<tag k="created_by" v="JOSM"/>
<tag k="comment" v="Additions and edits to NCR7"/>
</changeset>
</osm>

Planet File and API

The full OpenStreetMap database, known as the Planet file, is released every week, with updates/diffs released on a daily, hourly, and minute schedule.

All planet files are hosted on https://planet.openstreetmap.org/, including full dumps and diffs. The latest weekly planet file is always at https://planet.openstreetmap.org/planet-latest.osm.bz2, and in each subdirectory containing diff files there is also a text file, timestamp.txt, which contains the timestamp of the most recent diff.

Apart from bulk downloads, OpenStreetMap provides its main OSM API which is optimized for editing, and Overpass API which is optimized for high-volume reading.

Features out of Scope

Based on the above descriptions, we now better understand what data is collected in OSM. But, notably, OSM does not handle the following parts:

• Street view (although street view combined with OSM data is available from Mapillary or KartaView)

• Navigation (although OSM database does contain information for navigation, and there are multiple programs implementing navigation using OSM)

• Media files of any kind (although editors such as JOSM do have support for placing content icons next to recorded coordinates or time, for easier editing)

Furthermore, for certain things there are no established standards. For example:

• There is no standard how a POI, marked in GPS software, should be translated to OSM (however, if the GPS software supports defining custom tags, so that OSM-compatible tags can be produced, editors like JOSM can automatically import them)

Finally, OSM database lacks information that could technically be stored in OSM, but people or institutions in charge do not use OSM. Examples include countries’ land registries with parcel boundaries, etc.

Rendering System

The term rendering usually refers to server-side generation of pre-cut, square, 2D raster (e.g. JPG, PNG) images called “tiles”. However, since more options became available over time, it can now also refer to other combinations, such as client-side rendering, 3D, vector (SVG), or larger, non-tiled images.

Renderers combine geo data with some map background (e.g. elevation maps or satellite images) and chosen stylesheet to produce visual images. The final map that users browse and move through consists of these images placed next to each other. This can also be overlaid with other stuff on top to view multiple layers at once.

Some protocols are intended to always render tiles on the fly (e.g. WMS), some pre-generate and cache them (e.g. TMS and Slippy), and some serve geo data in XML or JSON format without classical rendering (e.g. OSM API or WFS).

OpenStreetMap’s default renderer is renderd, which uses Mapnik backend. An alternative, used on some OSM-related sites, is the more capable Tirex renderer. There is a comparison of renderd and Tirex available.

Tile Servers

Tile servers serve tiles (map images) using a couple possible protocols, but all based on top of HTTP. As mentioned, if tiles aren’t pre-generated and already available (i.e. cached), they are created on the fly.

Common protocols for serving tiles include:

• Web Map Service (WMS), an old and capable format, mostly used by traditional GIS software. Generates tiles as they are requested, without caching

• Tile Map Service (TMS), a middle ground, simple URL-based model like Slippy Map while also supporting alternate spatial referencing systems like WMS. Tiles are cached

• Web Map Tile Service (WMTS), cached WMS tiles. This standard is based upon TMS

• Keyhole Markup Language (KML), XML for geographic annotation and visualization in 2D and 3D Earth browsers

• Slippy Map, a simple format used by OSM, Google, and many others. Tiles are cached

The steps involved in serving map tiles can vary dramatically – from something as elaborate as WMS to something as simple as TMS or Slippy Map.

To be useful out of the box, OpenStreetMap (OSM) also acts as a tile server using Slippy Map format, with template URL being https://tile.openstreetmap.org/ZOOM/X/Y.png. However, OSM tiles should not be used for production purposes. For production, one should use other tile providers or set up their own tile server. A big page with different base layers and map providers can be found at Leaftlet’s Leaflet Providers Demo.

Let’s take a look at all the mentioned tile serving protocols in more detail.

Web Map Service (WMS)

Web Map Service (WMS) is one of OGC standards, intended for serving georeferenced map images over HTTP. Map images are generated on the fly and sent for displaying on computer screen.

WMS is not used in the OpenStreetMap toolchain, so it is not necessary to read this section. However, it is described here because it is often used by external systems, such as traditional GIS software, countries’ land registries, etc. Also, WMS is more complex than other protocols, almost like their superset. Once you get generally familiar with the concepts supported by WMS, all other protocols will seem simple in comparison.

WMS is dynamic and flexible. A WMS client can request a map to be created by overlaying an arbitrary number of map layers, over an arbitrary geographic area, with an arbitrary background color and stylesheet, at an arbitrary scale, and in any supported coordinate reference system.

However, all this flexibility comes at a cost: server image processing must scale with the number of connected clients, and caching isn’t effective since most images are different.

WMS tiles are defined by the coordinates of its corners.

WMS groups data into “layers”. There are base layers and overlays. Base layers are opaque and thus mutually exclusive – only one can be active at a time. Overlays are usually transparent and can be combined on top arbitrarily.

WMS offers predefined “styles” in which layers can be displayed. In this mode, styles can be chosen, but not customized or overridden by users. However, if the WMS service is Styled Layer Descriptor (SLD)-enabled, then a WMS server can first obtain parseable (XML) feature data from a Web Feature Service (WFS) server, then apply custom styling provided by the user, and then return the final, rendered image.

Responses from a WMS server come as either “picture formats” (raster/bitmap such as PNG, GIF, or JPEG) or “graphic elements” (vector data in SVG or WebCGM format). Vector data is scale-independent and can be used for points, lines, curves, text, and vector images.

Multiple images generated with the same geographic parameters and size can be overlaid accurately to produce a composite map. Furthermore, different layers can be requested from different servers.

Applications commonly used with OSM and support WMS are listed in https://wiki.openstreetmap.org/wiki/WMS.

Current non-final standard is WMS version 1.3 from Mar 2006. The version number also refers to the XML schema version.

To speed up WMS, attempts at caching the tiles were done under the name of WMS-C, later superseded by standards TMS and WMTS. WMS itself remains uncached.

It is important to note that WMS concerns itself with the generation and delivery of map tiles – the delivery of parseable geo features in XML or JSON format is not part of WMS; retrieval in those formats is offered by OpenStreetMap’s own API and/or other standardized protocols, such as the mentioned Web Feature Service (WFS).

One of better-known WMS servers is GeoServer. GeoServer supports WMS as well as other OGC Web Services (OWS) such as Web Feature Service (WFS), Web Coverage Service (WCS), Web Processing Service (WPS), and Web Map Tile Service (WMTS).

WMS Interface / API Calls

WMS requests are made to servers using HTTP GET or POST methods. Servers’ support for GET is required, while support for POST is optional.

In case of GET requests, the Online Resource URL (endpoint URL) for making API calls is used as a prefix to which additional parameters are automatically appended by the client to construct a valid request. In case of POST requests, the URL is used as-is, and the request content in placed as XML in the POST body.

All WMS requests have parameters, some are mandatory and some optional. Common parameters are VERSION, REQUEST, and FORMAT. Parameters can be given in any order, values are case-sensitive, and parameters whose values are lists should have elements separated by a comma.

WMS specifies a couple API requests that servers should support. Two are required by “Basic WMS” server:

• GetCapabilities returns parameters about the WMS server (map image format, WMS version compatibility) and available layers (map bounding box, coordinate reference system, URI of the data, and whether the layer is mostly opaque or not)

• GetMap returns a map image. Parameters include what to show on the map, which region to show, the coordinate reference system, rendering style, and image size and format

“Queryable WMS” servers should also respond to:

• GetFeatureInfo returns data about a coordinate on the map if a layer is marked as “queryable”

And in addition, other request types that WMS servers may optionally support include:

• DescribeLayer returns the feature types of the specified layer or layers, which can be further described using WFS or WCS requests. This request is dependent on the Styled Layer Descriptor (SLD) Profile of WMS

• GetLegendGraphic returns an image of the map’s legend image, giving a visual guide to map elements

Let’s take a look at the mentioned requests in more detail.

GetCapabilities

SERVICE=WMS&REQUEST=GetCapabilities [&FORMAT=text/xml&UPDATESEQUENCE=abc&VERSION=ver]

E.g.:

curl https://wms1-gs-services.domain.com/ows2-m/wms?SERVICE=WMS&REQUEST=GetCapabilities

When looking at the response, the most important parts in the metadata are the Layers and Styles offered by the WMS server. The geographic information content offered for display by a WMS server is organized into “layers”; metadata about the content is subdivided into descriptions of each layer, and a request for a map references the names one or more layers.

GetMap

GetMap request is used to obtain actual tiles from the WMS server.

Parameters:

VERSION=1.3.0 
REQUEST=GetMap
LAYERS=layer_list,
STYLES=style_list,
CRS=namespace:identifier
BBOX=minx,miny,maxx,maxy
WIDTH=output_width 
HEIGHT=output_height
FORMAT=output_format

E.g.:

https://oss.domain.com/OssWebServices/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng8&TRANSPARENT=true&LAYERS=public_10m_admin&tiled=false&ratio=2&serverType=geoserver&CRS=EPSG:3395&STYLES=&WIDTH=3840&HEIGHT=1208&BBOX=...

https://wms1-gs-services.domain.com/ows2-m/wms?&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=oss_parcels&STYLES=oss_parcel_names&tiled=false&ratio=2&CRS=EPSG:3395WIDTH=3840&HEIGHT=1208&BBOX=...

If using HTTP POST, the XML body would look like (example from an unrelated request):

<?xml version="1.0" encoding="UTF-8"?>
<ogc:GetMap xmlns:ogc="http://www.opengis.net/ows"
            xmlns:gml="http://www.opengis.net/gml"
   version="1.1.1" service="WMS">
   <StyledLayerDescriptor version="1.0.0">
      <NamedLayer>
        <Name>topp:states</Name>
        <NamedStyle><Name>population</Name></NamedStyle>
      </NamedLayer>
   </StyledLayerDescriptor>
   <BoundingBox srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
      <gml:coord><gml:X>-130</gml:X><gml:Y>24</gml:Y></gml:coord>
      <gml:coord><gml:X>-55</gml:X><gml:Y>50</gml:Y></gml:coord>
   </BoundingBox>
   <Output>
      <Format>image/png</Format>
      <Size><Width>550</Width><Height>250</Height></Size>
   </Output>
</ogc:GetMap>

GetFeatureInfo

In the list of layers, if a layer is marked with queryable="1", then GetFeatureInfo can be invoked on its elements.

The GetFeatureInfo operation is designed to provide WMS clients with more information about features in the map images that were returned by previous Map requests.

The standard use case for GetFeatureInfo is that a user sees the response of a Map request, chooses a point (I,J) on that map for which to obtain more information, and then calls GetFeatureInfo on it.

This basic operation provides the ability for a client to specify which pixel is being asked about, which layer(s) should be investigated, and what format the information should be returned in.

Because the WMS protocol is stateless, server doesn’t know which WMS tile is being looked at, and the GetFeatureInfo request must include the same parameters that were used to produce a map tile with GetMap (all the same parameters except VERSION and REQUEST, of course).

From the spatial context information (BBOX, CRS, WIDTH, HEIGHT) in that GetMap request, along with the I,J position the user chose, the WMS can identify the exact position and return additional information.

WMS GetFeatureInfo request is similar to the WFS GetFeature operation, but is less flexible in both input and output. One advantage of using the WMS variant, however, is that its request uses an (I,J) pixel value from the previously returned WMS image. That is easier to invoke and does not require the client to perform true geographic referencing.

Parameters:

SERVICE=
VERSION=
REQUEST=
LAYERS=
STYLES=
CRS=
BBOX=
WIDTH=
HEIGHT=
QUERY_LAYERS=
I=
J=
INFO_FORMAT= # Optional, can be application/json

Some software such as GeoServer offer filter= and cql_filter= options for additional filtering of output; also if INFO_FORMAT=application/json is passed, the data will be returned as GeoJSON rather than XML.

See also GeoServer’s GetFeatureInfo - GeoJSON page.

DescribeLayer

This request is used by clients that understand Styled Layer Descriptor (SLD)-enabled WMS. In order to make an SLD one needs to know the structure of the data, which this request returns.

Both WMS and WFS support this operation, so the DescribeLayer request just gets routed internally in the server to the appropriate service.

Parameters:

SERVICE=
VERSION=
REQUEST=
LAYERS=
outputFormat= # Optional

GetLegendGraphic

The GetLegendGraphic operation provides a mechanism for generating legend graphics as images beyond the limited capabilities of LegendURL reference of WMS Capabilities.

It generates a legend based on one of server’s styles, or alternatively based on a user-supplied SLD.

It is a surprisingly complex request with many parameters and considerations.

Time Support

WMS supports a TIME attribute in GetMap requests for layers that are properly configured with a time dimension. This is used to specify a temporal subset for rendering.

For example, there can be a dataset with weather observations collected over time.

Coordinate System (CS)

WMS uses two principal classes of coordinate systems: a Map Coordinate System (CS) and a Layer Coordinate Reference System (CRS):

Map Coordinate System (CS) applies to the map rendering generated by the WMS. It is used in GetMap requests.

A WMS map is a rectangular grid of pixels displayed on a computer screen. The Map CS has a horizontal axis denoted i, and a vertical axis denoted j. Values i and j have only non-negative integer values. The origin (i,j) = (0,0) is the pixel in the upper left corner of the map; i increases to the right and j increases downward.

Layer Coordinate Reference System (CRS) applies to the bounding box of source data. It is used in the BoundingBox element in the service metadata, in the BBOX parameter in GetMap requests, and in the BBOX parameter in map request parts of the GetFeatureInfo request.

A Layer CRS is a horizontal coordinate reference system for geographic information that serves as the source for a map. In addition, a layer may have an associated vertical, temporal, or other coordinate system.

More information for understanding CRS can be found in the Coordinate Reference System (CRS) Wikipedia page and Leaflet’s page CRS Simple.

During a rendering operation, WMS converts or transforms geographic information from a Layer CRS into a Map CS.

Vertical CRS

Some geographic information may be available at multiple elevations (for example, ozone concentrations at different heights in the atmosphere). A WMS may announce available elevations in its service metadata, and the GetMap operation includes an optional parameter for requesting a particular elevation. A single elevation or depth value is a number whose units (and the direction in which ordinates increment) are declared through a one-dimensional vertical CRS. Depending on the context, elevation values may appear as a single value, a list of values, or an interval.

Temporal CRS

Some geographic information may be available at multiple times (for example, an hourly weather map). A WMS may announce available times in its service metadata, and the GetMap operation includes a parameter for requesting a particular time. Depending on the context, time values may appear as a single value, a list of values, or an interval.

Bounding Boxes

Bounding box values specify the portion of Earth to be mapped through two pairs of coordinates in a specified Layer CRS. The first pair specifies the minimum coordinate value in the Layer CRS, the second specifies maximum coordinate value (i.e. a rectangle specified by two points).

For most CRSes with axes incrementing to the east and north this means that coordinates represent the lower left and upper right corner of the area of interest. However, the minimum and maximum values might be at other points in some instances. For example, when using geographic coordinates to describe an area over a pole, or when the layer CRS axes increment in directions other than east and north.

The order in which ordinates in each pair are listed and the values they have should be as defined by the Layer CRS; x corresponds to the first axis in the Layer CRS, and y to the second.

Bounding Box values appear in the following entities relevant to the WMS – the element in the service metadata, the BBOX parameter in the GetMap request, and the BBOX parameter in the map request part of the GetFeatureInfo request.

Practical Guidance

Good tutorials to further read about WMS and use it in maps are Leaflet’s Using WMS and TMS and QGIS’ Working with WMS Data.

TMS

Tile Map Service (TMS) is a simple specification for serving maps as tiles i.e. for splitting the map up into a pyramid of images at multiple zoom levels. It was developed by the Open Source Geospatial Foundation (OSG).

At zoom level 0, the whole map is one 256x256 pixels image. At every further zoom level, each tile from a previous level is divided into 4 more detailed 256x256 pixels tiles.

Tiles use a very simple referencing scheme – https://example.domain.com/TILESET/ZOOM/X/Y.png.

Tileset/stylesheet is an optional argument (possibly named after a stylesheet used), ZOOM is a zoom level starting from 0, and X and Y are tile numbers both starting from 0 at the map’s bottom-left.

There are simple functions that convert latitude and longitude to X and Y tile numbers and back.

The TMS protocol tries to hit a middle ground between the complexity of WMS and simplicity of Slippy map used by OpenStreetMap. It provides simple URLs to tiles while also supporting alternate spatial referencing systems.

See Tile Map Service Specification and Slippy Map below.

The protocol was used as a basis, and was somewhat superseded, by WMTS.

WMTS

As WMS is uncached, it proved difficult to serve WMS requests quickly in cases where short response times were important. For most WMS services it was not uncommon to require 1 or more CPU seconds to produce a response.

To overcome the CPU-intensive realtime rendering problem, application developers started using pre-rendered 2D map tiles.

Several open and proprietary schemes were invented to organize and address these map tiles. An earlier specification for this purpose was the Tile Map Service (TMS), which is simpler than WMTS. WMTS also defines the square (0,0) to be on the top-left rather than the bottom-left used by TMS.

WMTS traded the flexibility of WMS’ custom map rendering for the scalability possible by serving static data (base maps) where the bounding box and scales have been constrained to discrete tiles. The fixed set of tiles allowed for the implementation of a WMTS service using a web server that simply returns existing files. The fixed set of tiles also enabled use of standard network mechanisms for scalability such as distributed cache systems.

In general, the matrix and zoom level of tiles looks like:

And since this standard comes from the same body and spirit as WMS, the main requests it uses are:

• GetCapabilities, e.g. https://domain.com/maps?service=WMTS&version=1.0.0&request=GetCapabilities

• GetTile, e.g. https://domain.com/maps?service=WMTS&request=GetTile&version=1.0.0&layer=etopo2&style=default&format=image/png&TileMatrixSet=WholeWorld_CRS_84&TileMatrix=10m&TileRow=1&TileCol=3

• GetFeatureInfo, e.g. http://domain.com/maps?service=WMTS&request=GetFeatureInfo&version=1.0.0&layer=coastlines&style=default&format=image/png&TileMatrixSet=WholeWorld_CRS_84&TileMatrix=10m&TileRow=1&TileCol=3&J=86&I=132&InfoFormat=application/gml+xml;version=3.1

See also Web Map Tile Service Implementation Standard.

KML

Keyhole Markup Language (KML) (see documentation or KML page at Wikipedia) is an XML language focused on geographic visualization in 2D and 3D Earth browsers, including annotation of maps and images.

“Keyhole” refers to the company name of the inventor, Keyhole, Inc., not to a technical characteristic of the format.

Geographic visualization includes not only the presentation of graphical data on the globe, but also users’ navigation in terms of where to go or where to look.

It was used by Google as a file format used to display geographic data in an Earth browser Google Earth. It is now now one of OGC standards.

KML is complementary to most of the key existing OGC standards including GML (Geography Markup Language), WFS (Web Feature Service), and WMS (Web Map Service). Currently, KML 2.2 utilizes certain geometry elements derived from GML 2.1.2. These elements include point, line string, linear ring, and polygon.

Slippy Map

Slippy map is very similar to TMS, but like WMTS it has tile (0,0) on the top-left rather than bottom-left.

Other than that, it is the same hierarchical structure of cached map tiles, accessible via URLs in the form of https://example.domain.com/TILESET/ZOOM/X/Y.png:

• Tileset/stylesheet component is optional, and in fact not used on the default OSM map

• Zoom levels go from 0 (zoomed out) to 18, and on some maps like OSM they go to level 19 (maximum zoom in). Pages with an intuitive description of zoom are Leaflet’s zoom levels and GridLayer Demo.

• X and Y are latitude and longitude converted to tile numbers. A location’s lat/lng, which are needed as basis for converting to tile numbers, can be read directly from OSM map URLs or after clicking Share (6th icon) in the sidebar on the right

Page Slippy map tile names contains ready-made functions in many programming languages for converting latitude and longitude values into X and Y values and back.

Cached tiles can be served from any web server. However, if they are not all pre-generated and realtime generation must be possible, then a web server needs a handler that will invoke the renderer for missing files. Typically, this handler is called mod_tile.

Proxy Servers

Proxy servers cache data and/or transparently translate between formats for greater application compatibility.

One such server is MapProxy which supports WMS, WMTS, TMS, Slippy, and KML on input and output.

Map Viewer Programs

As mentioned, OSM uses Slippy map for map tiles.

In-browser Slippy map viewers include Leaflet and OpenLayers. A full list of alternative JavaScript libraries for viewing maps can be seen in deploying your own Slippy map.

Since there are a lot of maps and map styles available, a resource at https://mc.bbbike.org/mc/ allows previewing and comparing more than 250 maps, up to 3 at a time.

Desktop viewers include apps like QGIS and Marble.

Desktop, Android, iOS, and other apps and libraries can be seen in OSM Software Libraries - Native Widgets.

In case you need additional recommendations, note that all OSM map editors (listed below) are also useful map viewers.

For more choices, see OSM - Software.

Map Editor Programs

Map editors can be used for correcting or contributing new data to OSM database as well as for populating your own maps.

In-browser map editors include OSM’s default iD and its fork Rapid.

Desktop editors are JOSM and Merkaartor.

Mobile editors include Go Map!!, OsmAnd, OSMTracker, Vespucci, and Organic Maps. OsmAnd and OSMTracker allow configurable single-click actions which insert tags into the track, which can then be loaded into JOSM.

See list of editors and comparison of editors.

For more choices, see OSM - Software.

Surveying with GPS

The OSM database of geographic data is maintained by contributors.

One way of producing map data is by importing data from public or donated proprietary databases. Such data still requires reviewing, but may save time or provide information on features that would otherwise be difficult to obtain. One of the first databases donated to the project was GeoJunxion’s 2007 donation of its AND dataset for Netherlands.

Another big group of contributors are users who edit data based on surveying with GPS receivers.

Basics of GNSS / GPS Navigation

A Global Navigation Satellite System (GNSS), sometimes generically called the Global Positioning System (GPS), is a system using satellites for determining user position. It is a receive-only system that does not emit anything from the user side outwards; it only monitors signals emitted from satellites towards Earth.

(No data is sent outwards if speaking about GPS only. But many devices support using ground-level facilities, such as WiFi networks, for improving position accuracy.)

GPS is a staple of cartography for using maps in the field as well as contributing map data.

There are a couple systems in operation, e.g. NAVSTAR (GPS, US), Galileo (EU), GLONASS (Russia), BeiDou (China), QZSS (Japan), and IRNSS (India).

NAVSTAR uses a coordinate system known as WGS84, which defines a spheroid representing the Earth, and a fixed line of longitude or datum from which other longitudes are measured. This datum is very close to, but not exactly the same as the Prime Meridian at Greenwich in South East London. The equator of the spheroid is used as the datum for latitude. This coordinate system is not used for printed maps.

Many GPS receivers can calculate the amount of error in detected position due to the configuration of satellites used. The value is called Dilution of Precision (DOP). The higher the DOP, the less accurate the calculated position is. The precision of a GPS fix improves with the distance between the satellites used. If they are close together, such as mostly directly overhead, DOP will be high.

Which satellites a GPS receiver is using isn’t something that users can typically control, but many GPS chipsets will automatically try to use the best configuration of satellites available, rather than just those with the strongest signals. However, DOP still only takes errors caused by satellite geometry into account, and not other possible sources of error, so a low DOP does not guarantee absolute accuracy.

GPS Traces

A GPS trace or tracklog is simply a record of GPS positions over time.

Interestingly, even though GPS traces are not directly used in OSM, they can be uploaded to the OSM database and traces marked “public” will be visible on the map if you go to Layers (4th icon) in the sidebar on the right and enable “Public GPS Traces”.

GPS traces in OSM are more of a convenience than a foundational feature. They can be used for quickly previewing your own traces on the map, informally checking which OSM users traveled certain paths, and/or estimate relative popularity of certain routes.

Traces are uploaded with description, tags, and chosen visibility settings. Once uploaded, traces can’t be edited, but can be deleted and re-uploaded.

The only accepted format for GPS traces in OSM is GPS Exchange format (GPX), an XML spec for traces and POIs.

GPX files uploaded to OSM must have timestamps on each trackpoint. This is to prevent users from uploading traces that have been converted from an existing map database, without actual surveying.

If your GPS receiver doesn’t save files in GPX format, you’ll need to convert them to GPX. Fortunately, there are applications that can convert most formats into GPX, such as GPSBabel or GpsPrune.

GPS Features / POIs / Waypoints

In addition to position, most GPS receivers also allow marking specific points of interest (POIs). They are useful for recording the location of point features, such as post boxes, bus stops, park benches, and other amenities that one would like to map.

However, there could be a lot of data to record about a POI, such as its name, street name or number, description, shape, type, date of creation, possibly a picture, etc.

That means additional equipment will sometimes be necessary to adequately record POIs. It may include a pen and paper, a voice recorder, or a digital camera.

For easier editing, editors such as JOSM have support for local linking of points on the map with supporting files. That is done by reading GPS coordinates embedded in files, or as a fallback by correlating GPX timestamps with media creation/modification times.

On a related note, if you are interested in obtaining as much existing information as possible about an area you are in, you could use https://wiki.openstreetmap.org/wiki/Wikipedia2Go to load all Wikipedia entries with a defined latitude and longitude in GPI format into your device.

Recording GPS Traces

For best results, GPS receivers should be configured as follows:

• WGS84 coordinate system

• Recording frequency as high as possible (smallest interval between recorded data points)

• “Snap to streets” disabled, if such option exists

In addition, devices should be placed where they can get a good signal, they should not move until a good fix from satellites is obtained, and any bias during recording should be minimized or later corrected. Bias can occur for many reasons, including obvious ones such as driving on one side of the road instead of in the middle.

During surveying or later, confidence in traces’ accuracy can be checked with questions like (answer should be Yes to each):

• Are straight lines actually straight? A good trace accurately reflects the shape of the area, even if absolute positioning isn’t 100% accurate

• If a particular segment is recorded twice (e.g. going there and back), are traces very similar and aligned?

• When device is moved in a different direction, does the trace reflect change immediately? A good signal won’t take long to react

• If POIs are recorded, do they line up with traces?

Survey Locations

If you want to test first edits, the easiest way is to do it on e.g. offroad paths, which aren’t critical. They can be tagged with highway=track.

One can find offroad routes easily, for example by finding points on Google Maps where roads end. Google cars always prefer paved roads.

Contributing Map Data

Editing consists of creating or correcting OSM nodes, ways, and relations, tagging them with appropriate tags, and publishing the changesets to OSM.

GPS traces and possibly other supporting data are loaded in some map editor.

https://www.gpsbabel.org/htmldoc-development/fmt_garmin_gpi.html

https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

Processing GPS Traces

GPS information is not uploaded into the map directly, but only serves as a local basis for edits. GPS data is simply not usable as OSM data since it often contains:

• At least momentary positioning errors, or pauses in GPS recording

• Excessive data points due to staying in a single place for a while, moving in circles, going back the same way, etc.

• Undesirably connected nodes, such as roads being connected to outlines of buildings

• Inaccurately positioned traces, such as when driving to the side of a road instead of in the middle, or moving to avoid other vehicles

Another reason for not using GPS traces directly is that they often also lack data (e.g. for POIs) or data is too imprecise (e.g. for exact outlines of buildings or other features). GPS software might have only limited support for POIs, or users could decide to deal with exact shapes and tags of POIs later, not in real time during surveying.

In summary, producing map data later based on GPS traces is the preferred method. It relieves users of having to focus on too many things during surveying, and it gives a chance to review updates before publishing, possibly on a big screen rather than mobile device.

Tagging

A common rule of thumb in OSM is “don’t tag for visual look”. Data in OSM should be verifiable and real, separate from any visual style applied during rendering.

That’s because if you want a map where certain features appear in particular colors or styles, you should do so by rendering your own map with a customized stylesheet, not by choosing incorrect tags that visually seem OK on the default map.

The easiest way to get a feel for how tags are used in OSM is to look around the map in “Map Data” mode. Clicking on edges of features will then display their tags in the sidebar on the left.

Wiki page Map Features contains a list of commonly used tags. Here are some to give you a first impression:

The most mapped features in OpenStreetMap are roads. All roads, footpaths, and other land-based routes use tag highway=*, and the main values for highway=* are:

• highway=motorway for long-distance, high-speed roads with access restrictions

• highway=trunk for other long-distance roads with less strict access restrictions

• highway=primary for major general purpose roads

• highway=secondary for minor general purpose roads

• highway=tertiary for other through routes, possibly signposted routes

• highway=unclassified for through routes not covered by any of the previous tags

• highway=residential for roads in residential areas (whether urban or rural), where there is generally no through traffic

• highway=service for alleys, driveways, and other roads that only provide access to a single location

• highway=footway for any footpath, whether paved or unpaved, rural or urban. There are more specific versions of this tag for particular types of path, but you should start by using highway=footway

• highway=track for tractor, quad, and similar unofficial trails

Amenities (loosely, “all things”) are the next most mapped category. Some common values for amenity=* are:

• amenity=parking for public car parks. Further tags specify whether there’s a charge, how many spaces are there, and whether it’s outdoors or indoors

• amenity=place_of_worship for a religious building of any religion or denomination. Extra tags give the religion

• amenity=fuel for a vehicle filling station. The particular fuels on sale can be specified in extra tags. Note that other fuels, such as solid fuels for heating, aren’t mapped using this tag

• amenity=post_box for a post box. The operator, collection times, and any reference number can also be tagged using ref=*

• amenity=cafe for a cafe, possibly serving food

• amenity=pub for a public bar serving alcoholic drinks

• amenity=hospital for any hospital, with availability of emergency treatment specified in a separate tag, emergency=*

Settlements are mapped using the place=* tag, the main values for which are:

• place=country for a country, although it’s believed that all countries in the world are already mapped

• place=county

• place=city for very large settlements, although what exactly is a city varies from country to country

• place=town

• place=village

• place=hamlet

• place=suburb

Note: always also add a name=* tag along with place=*.

The waterway=* key covers all linear water features, such as rivers, as follows:

• waterway=river

• waterway=stream

• waterway=canal

• waterway=ditch

Ways tagged with waterway=* should point in the direction of flow where appropriate. There are also tags for features found along waterways such as lock gates, weirs, and waterfalls.

And of other / misc tags we could mention the following ones:

• landuse=* and natural=* specify what use man has put an area to, and what naturally exists there, respectively. These two tags are always used on closed ways, and ideally the areas should be contiguous, but not overlap

• leisure=* for leisure facilities, such as sports centers, sporting venues, or pitches

• railway=* covers most features related to railways, including the tracks themselves, stations, and level crossings. Miniature and funicular railways are also included

A full list of recommended tags with descriptions can be looked up in the mentioned Wiki page Map Features.

Please note that track roads are rendered only above certain level of zoom in OSM. You may need to zoom in more than usual to see them.