Guidelines for pedestrian navigation

From OpenStreetMap Wiki
Jump to navigation Jump to search

This page aims to encourage good mapping practices for pedestrian navigation. By navigation we mean both routing and guiding, i.e. providing instructions to follow an itinerary. Pedestrian navigation implies to consider, in addition to « traditional » navigation, the interior of buildings as well as areas.

This page points towards a number of pages that describe elements useful to pedestrian navigation. It makes a number of recommendations to produce data that enables accurate and realistic navigation. These recommendations are based on existing topological rules and on the Simple Indoor Tagging model.

Routing on linear objects

Pedestrian ways and shared ways

Routing engines require ways to be connected together and form a directed graph. It is useful to distinguish two categories of ways, defined as follows:

  • Pedestrian ways (or distinct ways): ways reserved to pedestrians or where pedestrians have priority and can walk on the full width of the way: highway=footway, highway=pedestrian, highway=living_street, highway=path, highway=track and highway=steps.
  • Shared ways: ways that describe a carriageway used by vehicles. Pedestrian can walk on the sidewalk of the carrigageway when there is one. All ways with the key highway=* (other than pedestrian ways) where pedestrian have legal access are shared ways.

Recommendations

Sidewalks and crossings

Combining shared and distinct sidewalks

A sidewalk can be mapped as a pedestrian way (highway=footway + footway=sidewalk) or as a shared way (highway=* + sidewalk=left/right/both). More details can be supplied on distinct sidewalks, for instance the height of curbs with kerb=* and the presence of tactile_paving=*. The page Sidewalks describes both approches.

A pedestrian crossing is defined by a node tagged with highway=crossing and shared with the way that defines the carriageway. In addition it can be described with a way highway=footway + footway=crossing joining one or several distinct ways. Crossings shared with cyclists are described on the page footway=crossing.

The diagram Combining shared and distinct sidewalks shows both approaches to map a sidewalk.

Connecting a footway with no contrived detour

Recommendations

  • When a sidewalk is mapped separately, add the tag sidewalk:both=separate, sidewalk:left=separate, or sidewalk:right=separate to the carriageway it borders, depending on which side or sides of the street have a separately mapped sidewalk. This prevents mappers from describing the sidewalk twice.
  • Avoid distorting a pedestrian way to connect to a crossing: this could result in inconsistent detours when producing itineraries. See the diagram Connecting a way with no contrived detour.

Hints and tips

  • JOSM: the Sidewalks map style shows whether sidewalks are mapped on either side of carriageways.

Stairs and elevators, bridges and tunnels

Footbridge crossing a road

A stairway is mapped as a way with the tag highway=steps, an elevator is a node with the tag highway=elevator. A ramp is a highway=footway holding the tag incline=*. These objects must be connected top and bottom to the shared and distinct ways they join.

A footbridge is a way highway=footway with the tag bridge=yes. Similary an underground passage is defined by tunnel=yes. Mind the tag layer=* on these ways.

Things to check

  • Specify whether steps are going up or down with the tag incline=*. This tag defaults to true, meaning the steps are going up when following the direction of the way.
  • Preserve the length of stairways: do not extend steps beyond their actual footprint, instead add a highway=footway to join them to other ways.
  • Be careful not sharing a node between a bridge and the ways below, or between an underground passage and the ways above.
  • Where a way flies over another one, split the section located above the other way accurately and add the tag layer=* on this section alone.

See the diagram Footbridge crossing a road.

Obstacles

An obstacle on a way is a node holding the key barrier=* that is shared with the way. Some obstacles such as barrier=block and barrier=bollard are by default open to pedestrian.

Recommendations

  • As default access restrictions are not defined for most barriers, add foot=yes to obstacles that can be crossed by pedestrians, and wheelchair=yes if they can be crossed in a wheelchair.
  • Do not put a barrier on a node where several ways cross: this would block any access through the crossroad. See the examples on this note.

Ways inside buildings

Footways towards and inside a building

The Simple Indoor Tagging model describes how to map indoor areas of a building=*. Pedestrian ways can be added to indoor areas and used by a routing engine.

An indoor way must hold the tag level=* to define the floor where it is located. A change of level is described by a multiple value of level=* (e.g. level=1;2) on stairs highway=steps, on an elevator highway=elevator or a ramp highway=footway + incline=*.

Recommendations

  • Add the tag indoor=yes to ways located inside a building that is not mapped using the indoor model.
  • Check the level=* value of indoor ways is consistent with the indoor=* areas where they are located in or connected to.
  • Connect indoor ways to the doors door=* that enable to enter or exit a closed room indoor=room.
  • A door to enter or leave a building is mapped as a node with the tag entrance=* that is shared with the building outline as well as the indoor and outdoor footways.
  • Consider area routing on complex buildings !

Routing on areas

Pedestrian areas are spaces where pedestrians can walk freely, i.e. they don't need to follow a route. Routing on such areas can produce realistic itineraries, avoiding the need to create a vast number of artificial ways, that do not match any actual path visible on the ground.

Algortihms that produce a realistic route inside an area have been described, in papers such as:

Areas suitable for pedestrians

An area (or surface) can be mapped either as a closed way (possibly with the tag area=yes) or as a multi-polygon relation. The page Relation:multipolygon describes how to produce multi-polygons that are geometrically and toplogically correct.

Below is a list of tags that describe pedestrian areas (please, note this list is not comprehensive and should be adapted to every use case):

Sidewalks can also be mapped as pedestrian areas, they are defined by highway=pedestrian + area=yes or more rarely highway=footway + footway=sidewalk + area=yes.

Note: areas with the key area:highway=*, used to describe the shape of roads and sidewalks, are not meant to be used for routing.

When several pedestrian areas are contiguous, nodes should be shared along their junction – this helps routing engines to consider them as a single area.

Junctions between lines and areas

Connecting a way to a pedestrian area

Routing through areas only is hardly possible. Area routing can improve and should be combined with linear routing. Thus junctions between lines and areas are essential.

In order to enable routing engines to combine linear and area routing, it is essential to connect ways to the pedestrian areas they cross or get to. The connection between a way and an area is a node shared between the two objects – see the diagram Connecting a way to a pedestrian area.

Recommendations

  • Join together the ways leading to a pedestrian area, to enable linear routing engines to produce (possibly less realistic) itineraries that cross the area.
  • When a pedestrian square is crossed by a street that is not pedestrian, create two pedestrian areas (highway=pedestrian + area=yes) one for each side of the street, so that area routing engines do not cross the street anywhere. The square itself can be mapped with the tag place=square – see the diagram Pedestrian square crossed by a street.
Pedestrian square crossed by a street

Linear barriers and crossing points

A routing engine handling area routing should consider linear barriers located partially or fully inside a pedestrian area, or at the junction between two pedestrian areas. Whether a barrier can be crossed may vary depending on the pedestrian profile.

Linear barriers and crossing points

A linear barrier might be:

A crossing point enables pedestrians to cross linear barriers. It is defined by a node on the barrier with one of the following tags:

  • entrance=*: entrance of a park, a building, etc.
  • barrier=*: some values for this key actually describe a crossing point, for instance barrier=entrance is an opening in a linear barrier, and a barrier=cycle_barrier does not stop pedestrians. Such crossing points are typically connected to ways crossing the linear barrier.

Recommendations

  • If a linear barrier cannot be walked around, make sure to share its first and/or last nodes with the pedestrian area perimeter.
  • When a linear barrier is located at the junction between two contiguous pedestrian areas (for instance a fence between a square and a park), share its nodes with both areas.
  • Describe the access=* conditions on the crossing points, using the key foot=* for pedestrians. Consider describing their wheelchair=* accessibility and their opening_hours=* where suitable.

Inside buildings

Indoor pedestrian areas and floor level

The Simple Indoor Tagging model is strongly topological and naturally enables area routing. The key indoor=* introduces new types of objects for area routing:

A pedestrian area can span several levels, the tag level=* then has a multiple value (i.e. level=0;1 or level=1-3). The floor level of an indoor pedestrian area is the lowest level=* value: pedestrian routing occurs on this level only (until humans can fly). Walking across adjacent open spaces (indoor=area or indoor=corridor) can only be done if they have the same floor level.

If two adjacent open spaces cannot be walked across freely, create a linear barrier where they join and a crossing point anywhere the barrier can be crossed.

Stairs and geometrical junctions

Geometrical and topological connections

Stairs highway=steps enable pedestrian to go from one level to another. The levels served by stairs are described by level=*. The junction between the stairs and a pedestrian area is a node shared by the way that describes the stairs and the area perimeter.

The Simple Indoor Tagging also describes geometrical junctions between stairs and areas. A node of the stairs located inside a pedestrian area, with the tag door=* and a value of level=* equal to the floor level of the area, defines without ambiguity a junction between the stairs and the area.

Note that a topological junction can always be produced, by creating a multipolygon where holes define floor openings (see the diagram Geometrical and topological connections). Adding door=* to a node that defines a topological connection is possible but redundant.

An escalator is defined by highway=steps + conveying=*. A ramp is a highway=footway with the tag incline=*.

Stairs can also be described by areas, as proposed in this diagram. This complements but does not replace their linear description.

Elevator and elevator shaft

Elevator with/without shaft

An elevator or lift is defined by a node highway=elevator, where the tag level=* describes the served levels, either as a list of values (i.e. level=1;2;4) or as in interval (i.e. level =-1-4). A geometrical junction is defined between the elevator node and the pedestrian areas surrounding it and sharing the same level=*.

An elevator shaft can be added, as an indoor=room whose level=* defines its vertical extent (i.e. level=-1-4 for levels -1 to +4). The elevator node highway=elevator is then connected to the pedestrian areas it serves through a way highway=footway and a door door=*. When doors are located on the same side of the elevator, create a single door and footway and use the tag repeat_on=*.

Both approaches to map an elevator are illustrated on the diagram Elevator with/without shaft.

Pedestrian navigation in complex areas

Pedestrian navigation is particularly useful in complex areas : railway stations, airports, shopping malls (shop=mall), exhibition centres (Proposed features/Events centre), and so on. These places combine outdoor and indoor areas that can span over several levels, and are often linked to other pedestrian areas : squares, bus or underground stations, etc.

Pedestrian navigation inside and around complex areas require accurate mapping, and face several challenges to produce realistic routes and provide clear instructions that help people finding their way.

Entrances and exits

Every location where ones walks in or out of a building or a closed area is defined by a node entrance=*. This is often the junction between outdoor and indoor spaces, possibly also between linear and area routing. Nodes that define these crossing points must therefore be shared between all adjacent routing elements : distinct and shared ways as well as pedestrian areas.

For instance in a railway station, an railway=subway_entrance tag can be put on :

  • the door=* whereby one enters or leaves the building=train_station
  • the barrier=turnstile or any other barrier=* one crosses to walk in the station
  • the location along a pedestrian way where one is informed, or feels, that one enters the station (through a sign, a stairway, an underground passage, etc.)

Naming entrances and exits

Entrances often have a name, that is most often indicated in the exit direction (city centre, bus station, Church street, etc.) and is displayed along an itinerary through several signs. That name can be added on every entrance using the tag name=*. When an exit is referenced by a number or code, it can be added with the tag ref=*.

Sometimes the name changes depending on the direction ones crosses an entrance, for instance in a railway station or airport directly connected to an underground station. In order to name such a crossing point with no ambiguity, one can define a destination_sign relation relation for each direction. The name of the entrance or exit is put on the destination tag of the relation, whose members refer to the crossing point (role=intersection), where on comes from (role=from) and where one goes to (role=to).

The diagram Applying the destination_sign relation to pedestrian navigation shows how destination_sign relations can be defined for linear routing, for area routing, as well as both combined together.

Applying the destination_sign relation to pedestrian navigation

Note that the from and to members can be pedestrian areas (a platform, an indoor corridor, a pedestrian area, etc.). Also several members can have the same role, including the intersection members, for instance if an entrance is mapped with several adjacent doors.

Two views of the same door in the Boulainvilliers station in Paris

The pictures above show two opposite views of the same door, in the Boulainvilliers station in Paris. This door is referenced by two destination_sign relations, the relation with the tag destination=Voie 2 - Nord matches the picture on the left, the one with the tag destination=Sortie Rue de Boulainvilliers - Rue Singer matches the picture on the right. Note the symmetry of the from and to members between the two relations.

Walking restrictions

Using the restriction relation

Walking restrictions are common in underground stations and airports : oneway corridors, crossing points for boarding or disembarkment, and so on. These restrictions are generally indicated through a sign « No access » placed by an access control door or barrier, or at the entrance of a corridor or stairway.

A restriction relation relation with the tag restriction=no_entry can be created to describe such a restriction, with no ambiguity as to the direction that is forbidden. Similarly to the destination_sign relation, the relation members point to the crossing point (caution: role via rather than intersection), where one comes from (role from) and where one cannot go to (role to).

Several members with the same role may be defined when applying this relation to pedestrian routing, in particular when linear and area routing are combined together.