OpenStreetMap and Computer Cartography

Table of Contents

Introduction

Unlike in some other areas, in computer cartography open standards have almost prevailed and offer a usable ecosystem.

This article explains all the basic elements of open and free computer cartography – how individuals can use maps and contribute new or updated geo data.

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

1. A geographic database of features like roads, rivers, buildings, parks, benches, etc. This is provided by OpenStreetMap (OSM)

2. A rendering system, which combines geo data, map background (e.g. elevation lines or satellite images), and stylesheet 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 working on top of HTTP

4. Optional proxy server which caches results for offline use or translates between input and output formats for wider application compatibility

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

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

7. And, in case of editing, some original data that is used as basis for making maps edits, such as GPX traces or donated map databases

Let’s continue with a description of each section.

Later, after you become familiar with the ecosystem, the three main reference/documentation points will be OpenStreetMap (OSM) Wiki , Open Source Geospatial (OSGeo) Wiki , and Open Geospatial Consortium (OGC) repository of standards .

Geographic Database – OpenStreetMap

OpenStreetMap (OSM) is producing and maintaining free, unrestricted geographic data of the whole world. Everyone with an account can edit data, and OSM keeps track of changes over time. The project also organizes documentation and relevant tools for creating, managing, and using the data.

OSM initially started as a tool to map streets (as its name suggests), but it quickly grew to mapping all features – from paths, buildings, infrastructure (e.g. pipelines), parks, and beaches, to items like individual trees, postboxes, phone booths, and toilets.

OSM also contains data about entities that are not identifiable from landscape features themselves, 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 the data slightly, if or when they are able.

OSM does not use any existing geographic information system (GIS) format to store its data. It uses its own model, whose primary characteristic is that it is simple and optimized for editing. It transfers the task of interpreting the data to the clients who use or display data.

OpenStreetMap does not prescribe or restrict usage of its data in any way. Because of the communal and voluntary aspect of the project, urban city roads are not the only focus of mappers. Hiking, skiing, and cycling paths are also very well represented in OSM, and there are a good number of mapping and routing projects optimized for this purpose. Sometimes it is enough to just use a different background and selection of features to show or emphasize different features on the map.

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. However, being familiar with the format is helpful for understanding OSM and using the OSM API. In parallel, availability of JSON in tools increasing, helped by standardizations such as GeoJSON .

Naming Confusions

Important for a successful start with OSM is knowing that it uses some uniquely terrible and confusing terminology.

Here are a couple of examples in random order, to help put things into perspective:

• OpenStreetMap (OSM) includes “Street” in its name, but is used for mapping everything without discrimination

• One of OSM’s basic primitives is a “way”. But it is not specific to ways and roads – it is a generic container for a list of connected nodes, from first to last. As such, it is used to map everything that contains connected nodes, from roads (which are linear) to closed loops (polygons) that are used to mark outlines and boundaries of all objects, such as fields, buildings, and parking lots

• All roads, paths, and other land-based routes are called “highways”, and have a tag of highway=*. This terminology supposedly stems from the author’s British English origin, where “highways” refer to all public roads, even unpaved ones suitable only for farm vehicles

• Geographical boundaries of everything from suburbs to countries are tagged using place=*, where * can be one of country/county/city/town/village/hamlet/suburb

• All items on the map are basically called “amenities”, and range from anything single-point (like trash cans or postboxes) to polygons such as shops or pubs (e.g. amenity=pub)

These naming choices are ultimately not a showstopper, they just require some practice with OSM’s tag names and values.

Community

OpenStreetMap is made possible by sufficiently accurate GPS receivers, good Internet links, and a large community of users.

The main wiki page is https://wiki.openstreetmap.org/ , and it requires some amount of browsing to gain familiarity with its main sections and groups of pages. There are many pages on the Wiki – many of them are interesting to read at least once, but after the initial learning usually only a couple pages are 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. Most other things can be memorized more easily and do not require repeated lookups to documentation.

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

OSM also maintains a Platform Status page.

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

OSM Map in Action

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

The 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).

  The Cycle Map is an example of custom rendering; it shows cycle networks overlaid on a map with contour lines. It was one of the first alternative renderings of OpenStreetMap data, and also has its own interface 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.

Map currently in view can also be exported by clicking Export among the options on the top-left. The map coordinates will be filled in, which can be manually overridden.

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

Database

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

OSM uses its own data model that prioritizes simplicity of creating and editing data, instead of simplicity of displaying it.

The model contains only three primitive types, combined with a free-form tagging scheme.

The primitive types are nodes, ways, and relations. Because there are only three, they are applied everywhere and even for purposes that are not immediately obvious, such as for the earlier-described outlining of buildings with closed “ways”.

Primitives are generic and do not have embedded meaning. What gives them meaning are tags that are attached to them. 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 properly recognized by existing tools.

Nodes

Nodes are actual points in space. 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, at 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 lists of nodes, minimum two, from first to last. They can describe linear features, such as roads, or closed areas that have an outline and surface, such as buildings or lakes.

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 nodes are changed, including being repositioned. 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.

The ordering of nodes in a way is preserved. Ways have an implicit direction which runs from the first to the last node in the list. Most editors indicate direction with arrows. The direction might not always be important, depending on what is being described.

When used to describe linear features, points in a way should be placed along the center line of the feature; when used for surfaces they should be on the edges.

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 almost certainly 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 primitives, including other relations. 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, branching streets, long distance routes, or the turn restrictions at junctions.

Relation’s child elements are a list of relation 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 the relation itself. The role can be left blank for relation types that don’t require one. In our example, the type is given as a restriction, and the members show the route that’s illegal to take using the node representing the junction with the turn restriction, and the ways representing the roads that’s illegal to access.

The XML for a relation looks as follows:

<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 doesn’t render on maps. It is used by a routing algorithm to avoid making an illegal turn. There are many other types of relations, and this is perhaps the least mature part of OpenStreetMap’s data model and mapping.

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 unlimited number of tags attached to them.

Tags give primitives on the map their meaning; they tell what all 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. The most common use of this is 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 a node are the key=value tags applied to that node.

Features / POIs / Waypoints

There are many points and areas of interest in the real world besides obvious things like streets and buildings.

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

All these items are not represented in OSM in any special way – they are simply nodes or ways with appropriate key=value pairs 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 note is that the changeset XML doesn’t contain any details of the changes themselves. This information is stored in the OpenStreetMap database, and you can download a separate XML file containing the changes, but they’re kept separate from the changeset description.

The changeset description XML tag contains, like other primitives, an ID, again only unique to changesets, the display name of the mapper, his/her user ID, timestamps for when the changeset was opened and closed, and the four corners of the bounding box for the changeset. The bounding box describes the smallest rectangular box containing all the edits in the changeset, and can be very large if the edits are far apart.

The 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 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 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 waypoint, marked in GPS software, should be defined (however, if software supports OSM-compatible tagged notation, editors like JOSM can automatically import it)

Finally, OSM may lack information on data that could technically be stored in OSM, but the institutions in charge did not do so. Examples include countries’ land registries with parcel boundaries, etc.

Map Tile and Data Renderers

The term rendering usually refers to server-side generation of pre-cut, square, 2D raster (e.g. JPG, PNG) images called “tiles ”. However, strictly speaking, it can also refer to other combinations, such as to 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 side by side. 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 renderer. An alternative, used on some OSM-related sites, is more capable Tirex . There is a comparison of renderd and Tirex available.

Map Tile and Data Servers

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

Common protocols for serving tiles include:

• Web Map Service (WMS) , an old and flexible 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, while also supporting alternate spatial referencing system 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

What is involved in serving map tiles can vary significantly – from something as elaborate as WMS to something as simple as TMS or Slippy.

To be useful out of the box, OpenStreetMap (OSM) also acts as a tile server, with template URL https://tile.openstreetmap.org/ZOOM/X/Y.png. However, OSM tiles are not to be used for production purposes. For production, one should use other tile providers or set up their own tile server .

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 then suitable for displaying on a computer screen.

WMS is more complex than its alternatives. It is not used in the OpenStreetMap toolchain, but is described here because it is often used by systems you’d like to interface to, such as countries’ land registries etc.

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

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

WMS classifies its data into “layers” and offers predefined “styles” in which those layers can be displayed. In this mode, styles cannot be chosen by users. If a WMS service is Styled Layer Descriptor (SLD)-enabled, then WMS can alternatively obtain parseable feature data from a Web Feature Service (WFS), and then apply custom styling information provided by the user, returning the final, generated images.

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) which are 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, layers can be requested from different servers.

Applications commonly used with OSM, which 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 delivery of generated map images – retrieval of parseable geo features is not part of this standard; it is part of OpenStreetMap’s own API and/or standardized protocols such as 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 (support for GET is required) or POST (support for POST is optional).

In case of GET requests, the Online Resource URL (endpoint URL) for making API calls serves as a prefix to which additional parameters are 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 number of different request types. Two are required by “Basic WMS” server:

• GetCapabilities returns parameters about the WMS (map image format, WMS version compatibility) and available layers (map bounding box, coordinate reference systems, 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

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 clients of a WMS 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 is that the request uses an (I,J) pixel value from a 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, and also if INFO_FORMAT=application/json is passed, the data will be returned as GeoJSON .

See also GeoServer’s GetFeatureInfo - GeoJSON page.

DescribeLayer

This request is used by clients that understand SLD-based 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 LegendURL reference of WMS Capabilities.

It generates a legend based on the style defined on the server, 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 CS applicable to the map rendering generated by the WMS, and a Layer CRS for a Bounding Box applied to the source data.

During a rendering operation, WMS converts or transforms geographic information from a Layer CRS into a Map CS. In addition, a Layer may have an associated vertical, temporal, or other coordinate system.

A WMS map is a rectangular grid of pixels displayed on a computer screen (or a digital file that could be so displayed). The Map CS has a horizontal axis denoted i, and a vertical axis denoted j. i and j shall 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.

Map CS is used in GetMap requests.

A Layer Coordinate Reference System (CRS) is a horizontal coordinate reference system for the geographic information that serves as the source for a map.

Layer CRS is used in the element in the service metadata, the CRS parameter in the GetMap request, and the CRS parameter in the map request part of the GetFeatureInfo request.

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 CS

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 the Earth to be mapped through two pairs of coordinates in a specified Layer CRS. The first pair specifies the minimum coordinate values in the Layer CRS, the second specifies maximum coordinate values.

Although for most CRSs with axes incrementing to the east and north this would be the lower left and upper right corners of the area of interest, 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 shall be as defined by the Layer CRS; x corresponds to the first axis in the Layer CRS, and y to the second. This order may not coincide with the Map CS axis order i, j. The bounding box coordinate values shall be in the units defined for the Layer CRS.

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.

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 set of tiles (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 bottom-left of the map.

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 system.

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 on the fly rendering problem that happens with WMS, 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 trades the flexibility of WMS’ custom map rendering for the scalability possible by serving of static data (base maps) where the bounding box and scales have been constrained to discrete tiles. The fixed set of tiles allows for the implementation of a WMTS service using a web server that simply returns existing files. The fixed set of tiles also enables the 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 Web Map Tile Service Implementation Standard .

KML

Keyhole Markup Language (KML) (documentation and KML - 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 the control of the user’s navigation in the sense of where to go and 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 has tile (0,0) on the top-left instead of 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 is optional, and in fact not used on the default map

• Zoom levels go from 0 (zoomed out) to 18, and some maps like OSM go to 19 (maximum zoom in)

• 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 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 on the fly generation and caching is desired, then a web server needs a handler that will invoke the renderer for missing files. Typically, this handler is called mod_tile .

Map Proxy Servers

Proxy servers cache or translate between formats for greater application compatibility.

One such is MapProxy which supports Web Map Service (WMS) , WMTS, TMS, Slippy, and KML on input and output.

Map Viewers

As mentioned, OSM uses Slippy map for map tiles.

In-browser 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 Editors

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

Desktop editors are JOSM and Merkaartor .

Mobile editors include Go Map!! , Vespucci , and Organic Maps .

See list of editors and comparison of editors .

For more choices, see OSM - Software .

Basics of GNSS / GPS

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.

It is a staple of cartography for using maps 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’re 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 isn’t a guarantee of absolute accuracy.

GPS Traces

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

Interestingly, GPS traces can be uploaded to OpenStreetMap , and traces with public visibility will be displayed on the map if you go to Layers (4th icon) in the sidebar on the right and enable “Public GPS Traces”.

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

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

Also, GPX files uploaded to OSM must have timestamps on each trackpoint to be accepted. 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 .

Overall, uploading GPX tracks in OSM is more of a convenience than a foundational feature. The functionality can be used for either previewing traces on the map or getting a relative impression of popularity of certain routes (if/when users upload their traces).

GPS Features / POIs / Waypoints

In addition to movements, most GPS receivers also allow marking specific coordinates, often called waypoints. They are useful for recording the location of point features, such as post boxes, bus stops, and other amenities that one would like to map.

However, sometimes there is a lot of data to record about a waypoint, such as its name, street name or number, description, building type, date of creation, possibly a picture, etc.

That means additional equipment will sometimes be necessary to adequately record waypoints. That may include a pen and paper, a voice recorder, or a digital camera. For easier editing, editors such as JOSM have support for linking 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.

Recording GPS Traces

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

• WGS84 coordinate system

• Recording frequency as high as possible (e.g. every 2 seconds)

• “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 the correct side of the street 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 waypoints are recorded, do they line up with traces?

How to Edit Maps

The OSM database of geographic data is maintained by contributors.

One way of producing map data is by importing 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 .

GPS Surveying

GPS information is usually not uploaded into the map directly, but only serves as a local basis for edits. There are numerous reasons for this, most stemming from the fact that GPS data 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, primarily for points or interest (POIs or waypoints). The most common reasons why POIs are missing are that the GPS software used did not have support for waypoints, or the support was too limited, or users did not bother to create all properly tagged POIs in real-time during surveying.

Producing map data later, based on GPS traces, is easy and gives a chance to review updates before publishing. Also, it relieves users from having to be focused on too many things at once during surveying.

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.

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

Editing

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

Editing consists of creating or correcting nodes, ways, and relations, and tagging them with appropriate tags.

Tagging

A common rule of thumb in OSM is “don’t tag for the renderer”. 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.

The easiest way to get a feel for how tags are used is to look around the OSM 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:

The most mapped features in OpenStreetMap are roads. All roads, footpaths, and other land-based routes use key highway=*. 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 are the next most-used category of features. 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

Always add a name=* tag with a place=* tag.

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.

• 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