Proposed features/CompoundFacility

From OpenStreetMap Wiki
Jump to navigation Jump to search
Compound Facility
Proposal status: Abandoned (inactive)
Proposed by: Addict user
Tagging: compound_facility=*
Applies to: area
Definition: Model of a compound facility for pedestrians

Drafted on: 2013.11.29

Page details

  • The need for the current extension proposal emerged while we were working on a project, regarding Multimodal transportation.

A complex transportation system, where several modes of transportation is available, is called multimodal transportation system. In reality, these systems are not static, but constantly changing over time (for example: because of different density of traffic during the day). The number of passengers travelling, or utilizing such a system is in the scale of billions daily. This implies the importance of the current topic.

  • Please visit our page, where you can get an even more detailed picture about the project and how it led to this proposal.



Using current OSM data, routing information can be given to passengers about when and where they can change between transport modes, but there is no information about the details of a particular change: how they can pass between the stops of different public transport services indoor, or inside a complex facility like a station. To handle this problem, a new model is needed, which represents:

  • important structure of indoor / underground facilities
  • relevant data that routing applications can use

For this purpose, Compound Facility is modeled. The Compound Facility consists of one or more Levels which are connected to each other inside the facility. Pedestrians can access Compound Facility on foot through exit/entrance, or using other transport modes, like public transport vehicles, on Levels which contain BoardingArea. Besides modeling level parts for indoor infrastructure, relevant data for routing on level are described using ConvexAreaGroup, ConvexArea and RestrictedConvexArea.

Use cases

  • Complex facilities' maps: outdoor / indoor / mixed
  • Pedestrian routing data
    • can be calculated from facility's layout (grid)
    • different path for different user class/group can be explicitly defined

The Model /Tagging

Modeling compound facility (main relation)

  • compound facility is mapped as an OSM relation
  • members:
    • its levels with role: level
    • its entrances with role: facility_entrance
    • if there are bus / subway stops within the facility, they are also members with role: stop
  • key: name=*, name of compound facility. Example values: name="Keleti palyaudvar"


    <member type='node' ref='-24778' role='facility_entrance' />
    <member type='node' ref='1645007153' role='facility_entrance' />
    <member type='node' ref='1645007146' role='facility_entrance' />
    <member type='node' ref='688953662' role='facility_entrance' />
    <member type='node' ref='1294188425' role='facility_entrance' />
    <member type='node' ref='-24782' role='facility_entrance' />
    <member type='node' ref='-24780' role='facility_entrance' />
    <member type='node' ref='1294188429' role='facility_entrance' />
    <member type='node' ref='688953661' role='facility_entrance' />
    <member type='node' ref='2242754262' role='stop' />
    <member type='node' ref='276547699' role='stop' />
    <member type='relation' ref='-25561' role='level' />
    <member type='relation' ref='-25565' role='level' />
    <tag k='facility' v='public' />
    <tag k='name' v='Corvin negyed' />
    <tag k='type' v='compound_facility' />

Modeling levels

Level is spatial thing which extents in two dimensions support other objects and can be connected with other levels by level connectors. The zlevel indicates the vertical index of the level inside a facility (therefore must have integer value), compared to ground level, which is identified with zlevel=0.

  • levels are mapped as OSM relations
  • type = level
  • area = yes
  • The members of a level are OSM elements (node / way / relation) representing relevant indoor infrastructure parts:
    • boundary, closed polygon, role: boundary
    • level entrance, role: level_entrance
      • entrance
      • end of steps / elevator / escalator
    • Point Of Interest (amenity point), role: levelpart
    • moving_sidewalk: role: levelpart
    • inside area (smaller area, room , shop ...) : role: levelpart
    • boarding area, role: boarding_area
    • Convex Area Group which indicates routing for a certain user group, role: convex_area_group.
Key Description Example values
zlevel=* level number of the level; 0 is always the ground-level zlevel=0; zlevel=-1; zlevel=1
name=* the name of the corresponding level name=ground_level
height=* height of level in meter height=4
opening_hours levels may have opening hours


    <member type='way' ref='-25472' role='boundary' />
    <member type='node' ref='-24826' role='level_entrance' />
    <member type='node' ref='-24784' role='level_entrance' />
    <member type='node' ref='-24788' role='level_entrance' />
    <member type='node' ref='-24800' role='level_entrance' />
    <member type='node' ref='-24810' role='level_entrance' />
    <member type='node' ref='-24812' role='level_entrance' />
    <member type='node' ref='-24770' role='level_entrance' />
    <member type='node' ref='-24772' role='level_entrance' />
    <member type='node' ref='-24776' role='level_part' />
    <member type='node' ref='-24774' role='level_part' />
    <member type='relation' ref='-25555' role='convex_area_group' />
    <tag k='name' v='Corvin negyed - aluljaro' />
    <tag k='tunnel' v='yes' />
    <tag k='type' v='level' />
    <tag k='zlevel' v='-1' />

Modeling level infrastructure parts

  • Infrastructure elements which are on a level, can be mapped as node, polyline, closed polygon, or relation
  • Areas where foot movement is not allowed (e.g.: subway rail part, holes, etc.):
    • These areas are mapped as OSM areas.
    • key: levelpart=forbidden
    • Access permission for pedestrians: foot=no .
    • subway rail part:
      • together with tag: railway=subway
    • Holes:
      • together with tag: barrier=railing
  • Halls, areas where public access and pass is allowed:
    • mapped as OSM area
    • levelpart=hall
    • ref=*: the ref of the area, for example value: ref=Keleti.
    • type=*: type of the area, for example: type=waiting_hall.
  • Room-like areas, where no other element is contained inside, and public access is denied: shop, operator room ...
  • Explicit stairs, ramps
  • construction parts: columns, pillars, etc.
    • can be mapped as OSM area, OSM way or OSM node
    • levelpart=construction
    • type=*, for example: type=pillar, type=wall
  • Area access points: these are not part of level, but part of area, hall, room, or wall
    • mapped as an OSM node or OSM way
    • type=door | turnstile
    • door=manual | automatic
    • other properties:
      • height=*
      • width=*
  • step platform, escalator platform: the boundary of step/escalator on the actual level
    • mapped as OSM area
    • levelpart=step_platform
    • no one can pass through this area
    • the step/escalator end node must be on the boundary of this area

Modeling Boarding Point

  • Places, where passengers can take on or take off public transportation vehicles, typically where the doors of the arriving public transport vehicle are placed.
  • Boarding point is mapped as an OSM node.
  • Tagging: public_transport=boarding_point
  • Example:
  <node id='-1861' action='modify' visible='true' lat='47.485420241107924' lon='19.07066238647339'>
    <tag k='public_transport' v='boarding_point' />

Modeling Boarding Area

Boarding areas are the areas inside stations or complex public transport facilities, where passengers can board/unboard public transportation vehicles. Boarding area may contain boarding points (see previous section), which mark the exact positions inside a boarding area, where the boarding takes place (where the doors of the stopping public transportation vehicle opens). Boarding area is the member of Level relation, and information about the public transport route is attached to the boarding area.

  • mapped as an OSM relation
  • type=boarding_area
  • ref=*. Bus number or Metro number. Example value: ref=M3
  • Refers to the OSM_ID of route which this station/stop belongs to
    • if separate directions of route are available: route:id=*
    • if only one route is available:
      • the first one has route:id=*
      • the other one has route:backward:id=*
  • members:
    • boarding point OSM node, role:boarding_point/(blank)
  • Example:
    <member type='node' ref='-1715' role='' />
    <member type='node' ref='-1717' role='' />
    <member type='node' ref='-1861' role='' />
    <member type='node' ref='-1719' role='' />
    <member type='node' ref='-1721' role='' />
    <member type='node' ref='-1723' role='' />
    <member type='node' ref='-1725' role='' />
    <tag k='ref' v='M3' />
    <tag k='route:id' v='418604' />
    <tag k='type' v='boarding_area' />

    <member type='node' ref='-1729' role='' />
    <member type='node' ref='-1731' role='' />
    <member type='node' ref='-1859' role='' />
    <member type='node' ref='-1745' role='' />
    <member type='node' ref='-1743' role='' />
    <member type='node' ref='-1741' role='' />
    <member type='node' ref='-1727' role='' />
    <tag k='ref' v='M3' />
    <tag k='route:backward:id' v='418604' />
    <tag k='type' v='boarding_area' />

Modeling Reference Point

The purpose of reference points is to provide information for indoor navigation applications. The route of passengers travelling through an indoor area can be specified by a sequence of reference points. In our proposal, we introduce reference points, for make it possible to explicitly provide navigation information for indoor areas.

  • Reference points are used together with convex areas (see later).
  • Reference point either represent transport availability within a single convex area, or the connection between two adjacent convex areas.


  • Reference point is modeled as an OSM node.
  • ref_point=orientation
  • Explicit reference is not required in LEVEL relation, only in Convex Area

Modeling Convex Area

Areas make it possible for passengers to walk on the surface without restrictions. Indoor navigation of passengers deals with the problem of finding the optimal route between two arbitrary points inside an area. If the modeler adds reference points to the area, the problem can be reduced to connect some of these reference points with straight lines, such that, the first and last points are the source and destination of the passenger. The problem: how can we connect reference points without the line intersecting any obstacle? The idea is to split the area to convex areas. Inside a convex area, any inner points can be connected with a straight line without intersecting the boundary of the convex area. Convex areas have to be specified to exclude obstacles of the original area. More details behind this concept can be read on this page

  • Convex Area is mapped as an OSM relation.
  • type=convex_area
  • The members of a Convex Area are OSM nodes with individual role: ref_point (Reference Point) which may be
    • Point of Interest
    • entrance
    • Orientation reference point
    • end of explicitly mapped stair, ramp
    • Example:
    <member type='node' ref='-24788' role='ref_point' />
    <member type='node' ref='-24800' role='ref_point' />
    <member type='node' ref='-24810' role='ref_point' />
    <member type='node' ref='-24812' role='ref_point' />
    <member type='node' ref='-24768' role='ref_point' />
    <member type='node' ref='-24826' role='ref_point' />
    <member type='node' ref='-24784' role='ref_point' />
    <tag k='type' v='convex_area' />

Modeling Restricted Convex Areas

When describing a complex indoor area, with many obstacles, it may be more straightforward to forbid connections between groups of reference points contained by a convex area, instead of split the convex area to smaller ones. (For example, when a large area contains several columns in a row). The Restricted Convex Area is introduced for this purpose. For more information behind the concept, visit this page .

  • If a Restricted Convex Area exists, it has to be referred in Convex Area Group.
  • Similar to Convex Area, the Restricted Convex Area can be mapped as an OSM relation.
  • type=convex_area_restricted

Convex Areas relation

  • If there is an access restriction (no access from one convex area to another convex area) between adjacent Convex Area, it must be mapped as an OSM relation (e.g. one-way access restricted area: turnstile)
  • type=restriction
  • from= convex_area_identifier
  • to=convex_area_identifier
  • via=common_refPoint_identifier :optional
  • restriction = no_entry

Convex Area grouping within level

Convex Area Group indicates the type of user group, for which it defines transport possibilities. This approach makes it easier for map drawers to model indoor areas to serve data for routing algorithms to compute routes for appropriate user groups. It collects ConvexArea, RestricedConvexArea and ConvexAreaAccessRelation.

  • convex area group within an area is mapped as an OSM relation
  • type=convex_area_group
  • user= pedestrian | wheelchair | blind | tourist
  • Members:
    • convex area representing relations with role:convex_area/(blank)
    • restricted convex area with role: convex_area_restricted
    • access restriction between convex areas with role: access_restriction
  • Example:
 <member type='relation' ref='-25559' role='convex_area' />
 <member type='relation' ref='-25557' role='convex_area' />
 <tag k='type' v='convex_area_group' />
 <tag k='user' v='pedestrian' />

Modeling connections between different levels, between level and facility

  • Levels are connected by steps, elevators, escalators (vertical pass)
  • The end points must be placed on different levels, with appropriate attribute : step_end=yes | elevator_end=yes | escalator_end=yes
  • Elevators and Escalators have fix structure (ends, intermediate nodes ...), like steps, but they have direction which can be changed. Two alternatives to map elevator and escalator can be considered:
  1. just map their structure like steps, then their direction will be mapped separately
  2. map direction together with structure by using special tag
  • For maintain purpose, the later alternative is better.
  • they are mapped as OSM relations instead of OSM way. In this way, two overlapped end points on levels can be connected easily using OSM editor.
  • type="level_connector"
  • members are two level entrance nodes and intermediate nodes if any. In this case, member nodes must be ordered according to movement in order to define geometry way of this connector
  • if it is one-way connector:
    • tag oneway=yes must be used
    • role of level entrance members indicates a from-to relation: role: from/to
  • Can be used together with key:wheelchair
Key Description
step=yes it is a step
elevator=yes it is an elevator
escalator=yes it is an escalator
oneway=yes one direction only. Direction is specified by order of end points
length=* length of step, escalator
  • Example:
    <member type='node' ref='-24770' role='from' />
    <member type='node' ref='-24860' role='to' />
    <tag k='escalator' v='yes' />
    <tag k='note' v='fk_lc1_2_02' />
    <tag k='oneway' v='yes' />
    <tag k='type' v='level_connector' />

    <member type='node' ref='-1781' role='' />
    <member type='node' ref='-1827' role='' />
    <tag k='note' v='fk_lc01_04' />
    <tag k='step' v='yes' />
    <tag k='type' v='level_connector' />

Mapping demonstration in JOSM

  • Our example is Corvin-negyed(Budapest, Hungary)subway station with two floors underground. The first floor is a tunnel for pedestrians, while the subway station can be found on the second floor. The tunnel can be accessed from ground floor through 6 entrances, while the metro floor is connected with the first floor by four escalators. Since our goal is proposing solution to improve indoor transportation management, OSM elements will be demonstrated, which serves transportation for "pedestrian" user group. The following Points of Interest will be mapped:
    • on the first floor:
      • shops, telephones and public toilet
      • ticket shop
    • on the second floor:
      • places marked for subway boarding
      • information map
    • download OSM data file of the area where the new compound facility will be modeled

Example part1.jpg

  • place the entrance nodes of the facility. Since OSM data of the area was downloaded, every new node will have real coordinates
    • use the predefined railway=subway_entrance for these nodes.

Example part2.jpg

  • select other relevant nodes which will be part of the compound_facility and create the relation
    • facility=public
    • name=Corvin negyed M3
    • type=compound_facility

Example part3.jpg

  • for better visibility, create filter for facility, then disable this filter. Filter text: child (type:relation & facility:public & name:Corvin negyed M3)

Creating levels

Creating underpass level

  • If you have a blueprint, or something closely resembling to the area, you can use the PicLayer plugin of JOSM

Example part4.jpg

  • Insert the blueprint as a new layer: PicLayer -> New picture layer from file ...
  • Activate picture layer
  • After inserting, the picture should be placed and transformed according to reality, this way, the coordinates will be as accurate as possible.
  • In order to transform image
  • Select three check points using Green Arrow button (1,2,3 circle)
  • Select Red Arrow, move to selected place (1,2,3 circle) to transform image.
  • More about Picture Layer Plugin:
  • With the help of PicLayer, the boundary of the floor can be created easily

Example part5.jpg

Level relation
  • Create level relation and add the new way with role:boundary
    • type=level
    • name=Corvin negyed - aluljaro
    • tunnel=yes
    • zlevel=-1

Example part6.jpg

  • Although, setting the boundaries is an important step, but in regards of public transportation, so called Points of Interest are more valuable (compound facility entrances, level entrances , stop positions ... ) specially because of their coordinates, since other structure can be geo-referenced by them.
  • Setting properties of the tunnel level
    • Creating a multi polygon
      • the boundary is already set, it will get the role:outer in multipolygon
      • draw new areas with roles differing from the outer boundary, e.g.: shop, operator room, etc.
    • Add keys and values to the specific areas:
      • area=yes
      • highway=pedestrian
      • tunnel=yes
      • layer=-1

Example part8.jpg

JOSM Filtering
  • Working with level -1. Filter text: "child (zlevel:-1) | child child child (zlevel:-1)"
  • Working with level -2. Filter text: "child (zlevel:-2) | child child child (zlevel:-2)"

Mapping level entrances
    • Level entrances are the nodes where floors can be accessed from other levels

Example part7.jpg

Mapping levelparts
  • levelparts are spatial features which have effect on transportation management or for specific user groups.
  • In this example on floor (-1) , several objects are mapped as levelparts, like pillars, doors, toilet, shops and areas closed from the public, and ticket validation machines

Example part9.jpg

Creating Metro level

Level relation
  • creating the level itself is already explained in the previous section
    • difference: zlevel=-2
  • The following level parts can be found on the subway floor (-2)
    • two railway part
    • an area which pedestrian cannot access, however, it contains the operator room
    • boarding points
    • multiple obstacles - columns
    • information map
    • multiple benches
  • Railway
    • foot=no
    • levelpart=area
    • railway=subway

Example part10.jpg

Mapping obstacles
  • Areas closed from public or acting as obstacles
    • levelpart=area
    • foot=no
    • barrier=wall
    • Construction
      • levelpart=construction
      • type=pillar

Example part11.jpg

Mapping Boarding Area and Boarding Points
  • According to the number of doors on the subway train, set up the boarding points: public_transport=boarding_point
  • Collect these boarding points into a Boarding Area relation
    • ref=M3 (How the metro line is referenced)
    • route:id=418604 or route:backward:id=418604
    • type=boarding_area
  • Remember, that the route id can be different for different directions of the line
  • When the boarding areas are created, add them to the level relation with role=boarding_area

Example part12.jpg

Mapping convex areas

Let's start with a brief explanation: how can we access all the relevant points (entrances, information desk, escalator ends, etc.) from entrance E3? The first idea is we can connect E3 entrance with all other points directly using an OSM way. This solution is straightforward but we will have to do the same for all the other entrances as well. It increases the number of ways which must be stored and could result in a very bad rendering of the indoor map. Therefore we propose another solution for this problem: the use of Convex Areas. Within a convex area, every point can be accessed from all the others. According to the shape of the area and the numerous obstacles, many referce point and hence many different convex areas can be formed. It is hard to find the optimal solution. These points will be connected by "virtual edges" in routing applications and therefore, it will not affect the recent rendering tools, will only be used for routing. A possible layout of new reference points is below

Example part13.jpg

While the following image shows a possible layout of a few convex areas

Example part14.jpg

Metro level will need several reference points thanks to the many obstacles within the area

Example part15.jpg

Mapping Restricted Convex Areas

In many cases, reference points are placed between obstacles like in our example. In this case, the basic principle of a convex area is not met, because the reference points cannot be attached by a straight line thanks to the obstacle between. Restricted convex areas are created for such cases, meaning that the members of a restricted convex area cannot be connected

Example part16.jpg

Mapping convex area group

After convex areas were created, they should be grouped in order to indicate which user group they serve for. In this example, the user group is pedestrian and will be applied with tag: convex area group.

Example part17.jpg

Adding convex area group to level

Levels may contain more than one convex area group since they might be accessible for different user groups (pedestrian | wheelchair | blind). All of them need to be added to the level relation so they can be accessed by other applications.

Mapping levels connections

The level connections (connection between floors at level entrances) can be mapped as OSM ways. However the problem is more difficult when we have to map connections by elevator, where the 2 level entrances are overlapped. Therefore we propose to do it by mapping them as OSM relations, with "type=level_connector".

In this example, floors are connected by stairs and escalators which operate in one direction only. Thus, this level connection relation must have key and value : oneway=yes and roles "to" and "from" to the connector's ends in order to indicate their direction.

Example part18.jpg

Adding levels to compound_facility relation

facility should contain the level relations with role=level

Connection with outdoor features

  • use level_connector relation to connect entrances with outdoor subway entrances

Example part19.jpg

Compatibility with other editors

Other editors like ID and Merkaartor were tested and they were all capable of handling the new elements

Examples available

Several underground stations of Budapest, Hungary are already mapped using the tags in this proposal

They are available at:

Other examples

Examples which could be mapped according to this model

  • subway stations
  • airports