Proposal:Public transport schema: Difference between revisions

From OpenStreetMap Wiki
Jump to navigation Jump to search
(adjusted stop position-> stopping position and stop area->stop place as per CEN IFOPT recommendations - see talk for detais.)
Line 337: Line 337:


== Point-like traffic infrastructure ==
== Point-like traffic infrastructure ==
Concerning the major group within the public transport point-like traffic infrastructure – the ''stops'' – it is not possible yet to model these elements in a consistent way without having to distinguish explicitly between bus stops, railway halts, tram stops etc. Apart from that, there is no possibility yet to model stop areas, which are served by multiple public service vehicles and thus consisting of more than one stop positions, as interrelated elements. Furthermore, platforms, entrances or station buildings cannot be clearly assigned to one stop yet.
Concerning the major group within the public transport point-like traffic infrastructure – the ''stops'' – it is not possible yet to model these elements in a consistent way without having to distinguish explicitly between bus stops, railway halts, tram stops etc. Apart from that, there is no possibility yet to model stop place, which are served by multiple public service vehicles and thus consisting of more than one stopping points, as interrelated elements. Furthermore, platforms, entrances or station buildings cannot be clearly assigned to one stop yet.




Line 343: Line 343:
Therefore, a basic model for stops shall be established: The basic structure of this model is independent from the types of public service vehicles serving a stop or the traffic way a stop is related to. The model is kept as simple as possible and allows mappers to model very simple stops as well as very complex stops with many details. Therefore, the model consists of four components:
Therefore, a basic model for stops shall be established: The basic structure of this model is independent from the types of public service vehicles serving a stop or the traffic way a stop is related to. The model is kept as simple as possible and allows mappers to model very simple stops as well as very complex stops with many details. Therefore, the model consists of four components:


* the '''stop position''' of a public service vehicle on a traffic way
* the '''stopping point''' of a public service vehicle on a traffic way
* the '''access''' for passengers to the public service vehicles or the stop itself
* the '''access''' for passengers to the public service vehicles or the stop itself
* the '''stop area'''
* the '''stop place'''
* the '''stop area group'''
* the '''stop place group'''


[[Image:Stop_model.png|200px|center|thumb|Model for stops]]
[[Image:Stop_model.png|200px|center|thumb|Model for stops]]


The graphic above shows that the model consists of three steps at most: A stop area (as a relation) contains at least one stop position and either no access or an arbitrary amount of accesses. Consequently, a stop area builds the relationship between all the elements it contains. A stop area group (as a superior relation) shall be used if multiple stop areas have to be combined – e.g. because they are just representing multiple parts of one stop.
The graphic above shows that the model consists of three steps at most: A stop place (as a relation) contains at least one stopping point and either no access or an arbitrary amount of accesses. Consequently, a stop place builds the relationship between all the elements it contains. A stop place group (as a superior relation) shall be used if multiple stop place have to be combined – e.g. because they are just representing multiple parts of one stop.




=== Stop position ===
=== Stopping point ===
Stop positions shall be modeled as ''nodes'' and tagged with {{tag|public_transport|stop_position}}. The nodes shall be placed directly ''on'' the ways representing the traffic ways the stop positions are related to: This makes routing more easy and leads to more uniformity.
Stopping points shall be modeled as ''nodes'' and tagged with {{tag|public_transport|stop_position}}. The nodes shall be placed directly ''on'' the ways representing the traffic ways the stopping points are related to: This makes routing more easy and leads to more uniformity.


Although the described model for stops makes the stops independent from the public service vehicles, additional tags shall be used for stop positions to allow rendering systems to visualize them with adequate symbols and icons:
Although the described model for stops makes the stops independent from the public service vehicles, additional tags shall be used for stopping points to allow rendering systems to visualize them with adequate symbols and icons:


{| class="wikitable"
{| class="wikitable"
Line 382: Line 382:
|}
|}


If those additional tags shown above are missing, the absent information could still be read out from the line relations containing the stop position. But this would be considerably more difficult to implement.
If those additional tags shown above are missing, the absent information could still be read out from the line relations containing the stopping point. But this would be considerably more difficult to implement.


Another important aspect concerning stop positions is the following questions: When to record one stop position and when to record more than one? The answer: ''One'' stop position shall be modeled if there is just one in reality, if two bus stops are directly facing each other or if the stop relates to a single-track railway. In all other cases, ''more than one'' stop position shall be modeled, namely as much as there are in reality.
Another important aspect concerning stopping point is the following questions: When to record one stopping point and when to record more than one? The answer: ''One'' stopping point shall be modeled if there is just one in reality, if two bus stops are directly facing each other or if the stop relates to a single-track railway. In all other cases, ''more than one'' stopping point shall be modeled, namely as much as there are in reality.


=== Access ===
=== Access ===
Line 446: Line 446:
|}
|}


Buildings, ferry terminals, piers or other facilities can be integrated as accesses in a stop area relation, too. The existing modeling schema for those elements shall be maintained.
Buildings, ferry terminals, piers or other facilities can be integrated as accesses in a stop place relation, too. The existing modeling schema for those elements shall be maintained.


=== Stop area ===
=== Stop place ===
A stop area relation shall be tagged with {{tag|public_transport|stop_area}}. The additional tags a stop area relation can be equipped with mostly serve as unique identifiers of the stop area:
A stop place relation shall be tagged with {{tag|public_transport|stop_place}}. The additional tags a stop place relation can be equipped with mostly serve as unique identifiers of the stop place:


{| class="wikitable"
{| class="wikitable"
Line 467: Line 467:
|}
|}


A stop area relation is not always necessary: It would be superfluous if it contained just one stop position as a member. In such cases, the isolated stop position shall be equipped with the tags listed above which uniquely identify it – including the tag {{tag|operator|*}}.
A stop place relation is not always necessary: It would be superfluous if it contained just one stopping point as a member. In such cases, the isolated stopping point shall be equipped with the tags listed above which uniquely identify it – including the tag {{tag|operator|*}}.


=== Stop area group ===
=== Stop place group ===
A stop area group relation shall be tagged with {{tag|public_transport|stop_area_group}} and should ''not'' be mistaken for a "transfer relation" but shall be understood as a type of relation which can be used to combine multiple stop areas – e.g. because those stop areas are just representing multiple parts of one stop: One stop area tagged with <code>name=Church Square (East)</code> and another stop area tagged with <code>name=Church Square (West)</code> can be combined by a stop area group tagged with the name <code>name=Church Square</code>.
A stop place group relation shall be tagged with {{tag|public_transport|stop_place_group}} and should ''not'' be mistaken for a "transfer relation" but shall be understood as a type of relation which can be used to combine multiple stop place – e.g. because those stop place are just representing multiple parts of one stop: One stop place tagged with <code>name=Church Square (East)</code> and another stop place tagged with <code>name=Church Square (West)</code> can be combined by a stop place group tagged with the name <code>name=Church Square</code>.


A stop area group can also contain an arbitrary number of additional nodes which are representing ''other'' point-like traffic infrastructure:
A stop place group can also contain an arbitrary number of additional nodes which are representing ''other'' point-like traffic infrastructure:


* taxi stands and call boxes
* taxi stands and call boxes
Line 483: Line 483:


=== Examples for the application of the model for stops ===
=== Examples for the application of the model for stops ===
In the most simple case there is only one stop position with a name:
In the most simple case there is only one stopping point with a name:


[[Image:Stoppos_map.png|200px|center|thumb|Stop position (map view)]]
[[Image:Stoppos_map.png|200px|center|thumb|Stopping point (map view)]]
[[Image:Stoppos_data.png|200px|center|thumb|Stop position (data view)]]
[[Image:Stoppos_data.png|200px|center|thumb|Stopping point (data view)]]


If two accesses are "joining" the stop position a stop area shall be created:
If two accesses are "joining" the stopping point a stop place shall be created:


[[Image:Stoparea_map.png|200px|center|thumb|Stop area (map view)]]
[[Image:Stoparea_map.png|200px|center|thumb|Stop place (map view)]]
[[Image:Stoparea_data.png|200px|center|thumb|Stop area (data view)]]
[[Image:Stoparea_data.png|200px|center|thumb|Stop place (data view)]]


If two (not necessarily adjacent) stop areas belong to one stop a stop area group shall be created:
If two (not necessarily adjacent) stop places belong to one stop a stop place group shall be created:


[[Image:StopAreaGroup_Map.png|200px|center|thumb|Stop area group (map view)]]
[[Image:StopAreaGroup_Map.png|200px|center|thumb|Stop place group (map view)]]
[[Image:StopAreaGroup_Data.png|200px|center|thumb|Stop area group (data view)]]
[[Image:StopAreaGroup_Data.png|200px|center|thumb|Stop place group (data view)]]




=== Backward compatibility of the model for stops ===
=== Backward compatibility of the model for stops ===
The backward compatibility of the model described above is guaranteed because existing point-like traffic infrastructure can be preserved – merely the meaning of those map features will be interpreted in a different way from now on: The existing map features for stops (which are tagged with {{tag|highway|bus_stop}}, {{tag|railway|halt}} etc.) will be interpreted as stop positions if they are placed directly on traffic ways; if not, they will be interpreted as accesses – like all the other map features for accesses already existing (which are tagged with {{tag|highway|subway_entrance}}, {{tag|railway|platform}} etc.). By additional tagging, more information ({{tag|public_transport|stop_position}}, {{tag|public_transport|platform}} etc.) can be attached to the existing map features without any problems. The stop area and stop area group relations can be created on top of the existing data.
The backward compatibility of the model described above is guaranteed because existing point-like traffic infrastructure can be preserved – merely the meaning of those map features will be interpreted in a different way from now on: The existing map features for stops (which are tagged with {{tag|highway|bus_stop}}, {{tag|railway|halt}} etc.) will be interpreted as stopping points if they are placed directly on traffic ways; if not, they will be interpreted as accesses – like all the other map features for accesses already existing (which are tagged with {{tag|highway|subway_entrance}}, {{tag|railway|platform}} etc.). By additional tagging, more information ({{tag|public_transport|stopping_point}}, {{tag|public_transport|platform}} etc.) can be attached to the existing map features without any problems. The stop place and stop place group relations can be created on top of the existing data.


=== Suitability of the model for stops ===
=== Suitability of the model for stops ===
Line 552: Line 552:
* '''line variant'''
* '''line variant'''
* '''traffic way''' (as a relation member)
* '''traffic way''' (as a relation member)
* '''stop position''' (as a relation member)
* '''stopping point''' (as a relation member)
* '''access''' (as a relation member)
* '''access''' (as a relation member)


[[Image:Line_model.png|200px|center|thumb|Model for lines]]
[[Image:Line_model.png|200px|center|thumb|Model for lines]]


The graphic above shows that the model consists of three steps at most: A line variant (as a relation) contains an arbitrary amount of traffic ways, stop positions and/or accesses. A line (as a superior relation) shall be used to combine all the different variants of a line.
The graphic above shows that the model consists of three steps at most: A line variant (as a relation) contains an arbitrary amount of traffic ways, stopping points and/or accesses. A line (as a superior relation) shall be used to combine all the different variants of a line.




=== Line variant ===
=== Line variant ===
Separate relations shall be used for each direction of a line. Those relations contain all stop positions, accesses and traffic ways as members. The sequence of these members in the ordered list exactly expresses the connection between the source location and the target location of the line in reality. For a line variant relation, only the following tags are required:
Separate relations shall be used for each direction of a line. Those relations contain all stopping points, accesses and traffic ways as members. The sequence of these members in the ordered list exactly expresses the connection between the source location and the target location of the line in reality. For a line variant relation, only the following tags are required:


{| class="wikitable"
{| class="wikitable"
Line 577: Line 577:
To model alternate line courses separate relations shall be used, too, because using only one relation for all alternate line courses at once (e.g. applying the role <code>alternate</code> for alternate relation members) would make the correlation of different alternate relation members impossible: Consequently, when processing the relation the alternate line courses could no longer be reassembled.
To model alternate line courses separate relations shall be used, too, because using only one relation for all alternate line courses at once (e.g. applying the role <code>alternate</code> for alternate relation members) would make the correlation of different alternate relation members impossible: Consequently, when processing the relation the alternate line courses could no longer be reassembled.


By modeling a line variant relation, the mappers shall – apart form the topics mentioned above – consider further aspects, too: Firstly, the ways representing the traffic ways being included in the line variant relations don't have to be segmented at each stop position. Secondly, stop positions served on demand can be assigned with the role <code>on_demand</code>. Thirdly, the line variants of public service vehicles running on railways shall either include the correct rail track it is running on (if individual rail tracks are modeled) or the approximately correct rail track (e.g. if three of five rail tracks are modeled) or the only rail track or the trace (if only one rail track or a trace is modeled).
By modeling a line variant relation, the mappers shall – apart form the topics mentioned above – consider further aspects, too: Firstly, the ways representing the traffic ways being included in the line variant relations don't have to be segmented at each stopping points. Secondly, stopping points served on demand can be assigned with the role <code>on_demand</code>. Thirdly, the line variants of public service vehicles running on railways shall either include the correct rail track it is running on (if individual rail tracks are modeled) or the approximately correct rail track (e.g. if three of five rail tracks are modeled) or the only rail track or the trace (if only one rail track or a trace is modeled).


To model so-called "telescope lines", line variant relations are not necessarily required: Telescope lines feature occasional extensions by one or more stops, for example at certain times of day/night. To model telescope lines, it is sufficient to model one relation and to assign the role <code>additional</code> to the appropriate members representing occasional extensions.
To model so-called "telescope lines", line variant relations are not necessarily required: Telescope lines feature occasional extensions by one or more stops, for example at certain times of day/night. To model telescope lines, it is sufficient to model one relation and to assign the role <code>additional</code> to the appropriate members representing occasional extensions.
Line 761: Line 761:


== Network information (public transport networks) ==
== Network information (public transport networks) ==
Currently, public transport networks are not being modeled as superior relations very often in OSM. This situation shall be changed by means of this proposal: A public transport network relation shall contain ''all'' lines and stop positions of the network as members. At this, the incorporation of the stop positions is more important than the incorporation of the lines because the former delimit a network whereas the latter are often just partially included in a network: Such parts of lines can only be delimited and thus identified by the stop positions defining the line course. To mark a relation as a public transport network relation, the tag {{tag|public_transport|network}} shall be used.
Currently, public transport networks are not being modeled as superior relations very often in OSM. This situation shall be changed by means of this proposal: A public transport network relation shall contain ''all'' lines and stopping points of the network as members. At this, the incorporation of the stopping points is more important than the incorporation of the lines because the former delimit a network whereas the latter are often just partially included in a network: Such parts of lines can only be delimited and thus identified by the stopping points defining the line course. To mark a relation as a public transport network relation, the tag {{tag|public_transport|network}} shall be used.


Additional tags for public transport networks can be:
Additional tags for public transport networks can be:

Revision as of 14:35, 30 May 2009

Public transport schema - Other languages

This data modeling schema is a proposal for a more consistent and complete integration and visualization of public transport (PT) related data in OpenStreetMap (OSM). It was created to solve (at least most of) the numerous problems the existing modeling schema for PT related data is posing. The proposal is the result of a community workshop which took place from 16th to 17th of May, 2009, at Geofabrik, Karlsruhe (Germany). The list of all workshop participants can be found below:

All individual aspects of the schema presented in the text below arose from the following topics discussed during the workshop:

  • basic concept for line-like traffic infrastructure
  • basic concept for point-like traffic infrastructure
  • basic concept for network information (lines and routes)
  • basic concept for network information (public transport networks)
  • general separation of infrastructure data and network information
  • public transport routing and timetable information
  • rendering and visualization
  • (micro-)tagging
  • realization of automated data matching

Currently, there are some other activties within the OSM community working on enhanced modeling schemas for PT related data, too, which can be found in the transit category of the OSM wiki. Some aspects of the schema described in this proposal base upon two proposals which can also be found in the mentioned category:

In the NaPTAN category of the OSM wiki, all activities concerning the NaPTAN data import can be traced. These activities were also payed attention to during the developing process of this proposal.


Line-like traffic infrastructure

Currently, the largest problem concerning public transport line-like traffic infrastructure in OSM relates to the clear distinction between different railway types. To identify a railway type as exactly as possible and thus to model it correctly, mappers can use the following decision graph to take a decision already during data collection:

Decision graph for the modeling of different railway types

The following table lists all possible types of line-like traffic infrastructure in public transport. Apart from that, the table shows how those types are modeled in OSM according to the existing schema and how they shall be modeled in future according to this proposal. Elements, which are explained in the text passages below, are written in bold:

Type Geometry (so far) Geometry (proposed) Tag(s) (so far) Tag(s) (proposed)
bus guideways way way highway=bus_guideway highway=bus_guideway
traffic ways equipped with trolley wires nonexistent way nonexistent highway=* and trolley_wire=yes
railways for rails way way railway=rail railway=rail
railways for light rails way way railway=light_rail railway=light_rail
railways for metros way way railway=subway or railway=monorail railway=subway or railway=monorail
railways for trams way way railway=tram railway=tram
funiculars nonexistent way nonexistent railway=funicular
public conveyors nonexistent way nonexistent highway=conveyor
public escalators way way highway=steps and escalator=yes highway=steps and escalator=yes
aerialways way way aerialway=* aerialway=*
waterways for passenger ferries nonexistent way nonexistent waterway=ferry_way


Rail tracks and traces

If a mapper wants to model individual rail tracks instead of traces, she/he shall tag all the rail tracks of one trace in the same way (i.e. with the same attributes). But irrespective of whether individual rail tracks or traces are modeled, the additional tag tracks=* shall be used in all cases to record the number of tracks: The value of this tag will be 1 if individual rail tracks are modeled and more than 1 if traces are modeled.


Railways for rails

To distinguish between different types of railways for rails, in addition to railway=rail the tag usage=* shall be used – it describes the usage of a railway for rails:

Further tags for railways for rails are:

Key Value Description
service siding / spur / yard indicates different types of spur or side tracks
ref number or text railway number
name text railway name
maxspeed number speed limit in kilometers per hour
traction cable / rack indicates an auxiliary drive via cable or rack
disused yes / no no longer in use?
construction yes / no under construction?
planned yes / no planned?
tunnel yes / no tunnel?
bridge yes / no bridge?
gauge number gauge in millimeters
loading_gauge number loading gauge in millimeters
electrified yes / no / contact_line / rail type of electrification
voltage number voltage in volt
operator text operating infrastructure company


Railways for light rails

In addition to railway=light_rail, additional tags for railways for light rails can be:

Key Value Description
ref number or text railway number
name text railway name
traction cable / rack indicates an auxiliary drive via cable or rack
disused yes / no no longer in use?
construction yes / no under construction?
planned yes / no planned?
tunnel yes / no tunnel?
bridge yes / no bridge?
gauge number gauge in millimeters
loading_gauge number loading gauge in millimeters
electrified yes / no / contact_line / rail type of electrification
voltage number voltage in volt
operator text operating infrastructure company


Railways for metros

Metros can be divided into two different categories:

Modeling subways, a mapper shall always use the tag tunnel=* with the value yes for railways underground and with the value no for railways overground.

Modeling monorails, a mapper shall always use the tag monorail=* with the value hanging for suspended monorails and with the value magnetic for magnetic monorails.

Additional tags for railways for metros can be:

Key Value Description
ref number or text railway number
name text railway name
disused yes / no no longer in use?
construction yes / no under construction?
planned yes / no planned?
bridge yes / no bridge?
gauge number gauge in millimeters
loading_gauge number loading gauge in millimeters
electrified yes / no / contact_line / rail type of electrification
voltage number voltage in volt
operator text operating infrastructure company


Railways for trams

Railways for trams shall always be modeled as separate geometries, most notably when the railways are grooved. Otherwise, if only one geometry is used for a road and the grooved railway on it, additional tags cannot be clearly assigned to either the road or the railway.

Additional tags for railways for trams can be:

Key Value Description
ref number or text railway number
name text railway name
traction cable / rack indicates an auxiliary drive via cable or rack
disused yes / no no longer in use?
construction yes / no under construction?
planned yes / no planned?
tunnel yes / no tunnel?
bridge yes / no bridge?
gauge number gauge in millimeters
loading_gauge number loading gauge in millimeters
electrified yes / no / contact_line / rail type of electrification
voltage number voltage in volt
operator text operating infrastructure company


Funiculars

Funiculars did not appear as an independent category in OSM so far: From now on, they shall be modelled as ways with the tag railway=funicular.

Additional tags for funiculars can be:

Key Value Description
ref number or text railway number
name text railway name
disused yes / no no longer in use?
construction yes / no under construction?
planned yes / no planned?
tunnel yes / no tunnel?
bridge yes / no bridge?
gauge number gauge in millimeters
loading_gauge number loading gauge in millimeters
operator text operating infrastructure company


Public conveyors

Public conveyors also did not appear as an independent category in OSM so far: From now on, they shall be modelled as ways with the tag highway=conveyor.

Additional tags for public conveyors can be:

Key Value Description
oneway yes / -1 / no use in one direction only?
wheelchair yes / no / limited / only suitable for wheelchair users?


Waterways for passenger ferries

From now on, the waterways for passenger ferries shall be modeled as ways with the tag waterway=ferry_way to separate infrastructure data from network information.

Point-like traffic infrastructure

Concerning the major group within the public transport point-like traffic infrastructure – the stops – it is not possible yet to model these elements in a consistent way without having to distinguish explicitly between bus stops, railway halts, tram stops etc. Apart from that, there is no possibility yet to model stop place, which are served by multiple public service vehicles and thus consisting of more than one stopping points, as interrelated elements. Furthermore, platforms, entrances or station buildings cannot be clearly assigned to one stop yet.


Basic model for stops

Therefore, a basic model for stops shall be established: The basic structure of this model is independent from the types of public service vehicles serving a stop or the traffic way a stop is related to. The model is kept as simple as possible and allows mappers to model very simple stops as well as very complex stops with many details. Therefore, the model consists of four components:

  • the stopping point of a public service vehicle on a traffic way
  • the access for passengers to the public service vehicles or the stop itself
  • the stop place
  • the stop place group
Model for stops

The graphic above shows that the model consists of three steps at most: A stop place (as a relation) contains at least one stopping point and either no access or an arbitrary amount of accesses. Consequently, a stop place builds the relationship between all the elements it contains. A stop place group (as a superior relation) shall be used if multiple stop place have to be combined – e.g. because they are just representing multiple parts of one stop.


Stopping point

Stopping points shall be modeled as nodes and tagged with public_transport=stop_position. The nodes shall be placed directly on the ways representing the traffic ways the stopping points are related to: This makes routing more easy and leads to more uniformity.

Although the described model for stops makes the stops independent from the public service vehicles, additional tags shall be used for stopping points to allow rendering systems to visualize them with adequate symbols and icons:

Key Value Public service vehicle
bus yes / no served by bus?
rail yes / no served by rail?
light_rail yes / no served by light rail?
subway yes / no served by subway?
monorail yes / no served by monorail?
tram yes / no served by tram?
funicular yes / no served by funicular?
aerialway yes / no served by aerialway?
ferry yes / no served by passenger ferry?

If those additional tags shown above are missing, the absent information could still be read out from the line relations containing the stopping point. But this would be considerably more difficult to implement.

Another important aspect concerning stopping point is the following questions: When to record one stopping point and when to record more than one? The answer: One stopping point shall be modeled if there is just one in reality, if two bus stops are directly facing each other or if the stop relates to a single-track railway. In all other cases, more than one stopping point shall be modeled, namely as much as there are in reality.

Access

The geometry and the characteristical tag an access shall be modeled with depends from the type of the access:

Type Geometry Tags
platform or stop sign node or way or area public_transport=platform
entrance node public_transport=entrance


Additional tags for accesses can be:

Key Value Description
ref number or text reference (especially relevant for platforms)
name text name
operator text operating transportation company
bus yes / no served by bus?
rail yes / no served by rail?
light_rail yes / no served by light rail?
subway yes / no served by subway?
monorail yes / no served by monorail?
tram yes / no served by tram?
funicular yes / no served by funicular?
aerialway yes / no served by aerialway?
ferry yes / no served by passenger ferry?
wheelchair yes / no / limited / only suitable for wheelchair users?
bench yes / no bench available?
bin yes / no bin available?
shelter yes / no shelter available?
toilet yes / no toilet available?

Buildings, ferry terminals, piers or other facilities can be integrated as accesses in a stop place relation, too. The existing modeling schema for those elements shall be maintained.

Stop place

A stop place relation shall be tagged with public_transport=stop_place. The additional tags a stop place relation can be equipped with mostly serve as unique identifiers of the stop place:

Key Value Description
ref number or text reference ID
name text name
operator text operating transportation company
uic_ref number official reference ID according to the International Union of Railways
uic_name text official name according to the International Union of Railways

A stop place relation is not always necessary: It would be superfluous if it contained just one stopping point as a member. In such cases, the isolated stopping point shall be equipped with the tags listed above which uniquely identify it – including the tag operator=*.

Stop place group

A stop place group relation shall be tagged with public_transport=stop_place_group and should not be mistaken for a "transfer relation" but shall be understood as a type of relation which can be used to combine multiple stop place – e.g. because those stop place are just representing multiple parts of one stop: One stop place tagged with name=Church Square (East) and another stop place tagged with name=Church Square (West) can be combined by a stop place group tagged with the name name=Church Square.

A stop place group can also contain an arbitrary number of additional nodes which are representing other point-like traffic infrastructure:

  • taxi stands and call boxes
  • rickshaw stands
  • rent-a-car facilities
  • rent-a-bike facilities
  • car sharing facilities
  • water taxi stands and call boxes


Examples for the application of the model for stops

In the most simple case there is only one stopping point with a name:

Stopping point (map view)
Stopping point (data view)

If two accesses are "joining" the stopping point a stop place shall be created:

Stop place (map view)
Stop place (data view)

If two (not necessarily adjacent) stop places belong to one stop a stop place group shall be created:

Stop place group (map view)
Stop place group (data view)


Backward compatibility of the model for stops

The backward compatibility of the model described above is guaranteed because existing point-like traffic infrastructure can be preserved – merely the meaning of those map features will be interpreted in a different way from now on: The existing map features for stops (which are tagged with highway=bus_stop, railway=halt etc.) will be interpreted as stopping points if they are placed directly on traffic ways; if not, they will be interpreted as accesses – like all the other map features for accesses already existing (which are tagged with highway=subway_entrance, railway=platform etc.). By additional tagging, more information (public_transport=stopping_point, public_transport=platform etc.) can be attached to the existing map features without any problems. The stop place and stop place group relations can be created on top of the existing data.

Suitability of the model for stops

The model for stops described above is suitable for:

  • bus stops and bus stations
  • trolley bus stops and trolley bus stations
  • rail halts and rail stations
  • light rail halts and light rail stations
  • commuter rail halts and commuter rail stations
  • metro halts and metro stations
  • tram halts and tram stations
  • funicular stations
  • aerialway stations
  • passenger ferry terminals


Public elevators

Public elevators did not appear as an independent category in OSM so far. As the model for stops described above is not suitable for the modeling of public elevators, those elements shall be tagged as nodes with highway=elevator from now on.

Key Value Description
oneway yes / -1 / no use in one direction only?
wheelchair yes / no / limited / only suitable for wheelchair users?
capacity number maximum capacity
maxweight number maximum weight
toll yes / no or number toll?
operator text operating infrastructure company

Network information (lines and routes)

Currently, the largest problems concerning public transport lines in OSM relate to:

  • the missing possibility to clearly differentiate between the lines of different public service vehicles,
  • the missing possibility to distinguish between railway lines on the one hand and railway routes on the other hand and
  • absent rules for a clearly structured modeling of simple line courses as well as of complex line courses (e.g. with many alternate courses).


Basic model for lines

Therefore, a basic model for lines shall be established: The basic structure of this model allows mappers to easily design different types of lines as well as different ways there and ways back. The model is kept as simple as possible and allows mappers to design alternate line courses in a comprehensible way, too. Therefore, the model consists of five components:

  • line
  • line variant
  • traffic way (as a relation member)
  • stopping point (as a relation member)
  • access (as a relation member)
Model for lines

The graphic above shows that the model consists of three steps at most: A line variant (as a relation) contains an arbitrary amount of traffic ways, stopping points and/or accesses. A line (as a superior relation) shall be used to combine all the different variants of a line.


Line variant

Separate relations shall be used for each direction of a line. Those relations contain all stopping points, accesses and traffic ways as members. The sequence of these members in the ordered list exactly expresses the connection between the source location and the target location of the line in reality. For a line variant relation, only the following tags are required:

Key Value Description
from text initial stop
to text terminal stop

Accesses shall be included in line variant relations because of two reasons: Firstly, this approach makes it possible for pedestrian routing applications to refer pedestrians to the correct accesses (e.g. to platform F which grants accesses to subway line M). Secondly, this approach guarantees the backward compatibility of the whole model for lines, because all the existing map features tagged as stops (e.g. with highway=bus_stop) but being placed beside traffic ways can be preserved as valid relation members.

To model alternate line courses separate relations shall be used, too, because using only one relation for all alternate line courses at once (e.g. applying the role alternate for alternate relation members) would make the correlation of different alternate relation members impossible: Consequently, when processing the relation the alternate line courses could no longer be reassembled.

By modeling a line variant relation, the mappers shall – apart form the topics mentioned above – consider further aspects, too: Firstly, the ways representing the traffic ways being included in the line variant relations don't have to be segmented at each stopping points. Secondly, stopping points served on demand can be assigned with the role on_demand. Thirdly, the line variants of public service vehicles running on railways shall either include the correct rail track it is running on (if individual rail tracks are modeled) or the approximately correct rail track (e.g. if three of five rail tracks are modeled) or the only rail track or the trace (if only one rail track or a trace is modeled).

To model so-called "telescope lines", line variant relations are not necessarily required: Telescope lines feature occasional extensions by one or more stops, for example at certain times of day/night. To model telescope lines, it is sufficient to model one relation and to assign the role additional to the appropriate members representing occasional extensions.

Differentiation between railway lines and railway routes

There are railway lines and railway routes which shall be distinguished from now on: Railway routes are several ways that form some kind of entity, for example the railroad stretch from one city to another. Railway lines are the scheduled lines running on rail tracks, for example the subway "U96". So just as with cycle routes etc., routes are a way to bring several ways together under one name. Lines, on the other hand, are formed by vehicles moving regularly on this infrastructure.

To realize the differentiation between lines and routes, the tag route=* attached to relations will be ignored from now on if its value does not equal rail. The tag route=railway shall be used from now on to indicate relations for routes, all the other tags route=* will thus become obsolete. To model a line, the tag line=* shall be used from now.

Bus lines and trolley bus lines

Tags for bus lines and trolley bus lines can be:

Key Value Description
line bus indicates a bus line or trolley bus line
alternate yes / no indicates an alternate course or a main course
service busway / express / hail_ride / long_distance / school / shuttle special line concept: busway, express bus, hail and ride, long distance bus, school bus or shuttle bus?
ref number or text line number
nat_ref number or text national line number
name text special name (e.g. SpeedBus)
color text line color (HTML named color or web color in hexadecimal format)
text_color text line text color (HTML named color or web color in hexadecimal format)
by_night yes / no / only service by night?
on_demand yes / no / only service on demand?
operator text operating transportation company


Rail lines

Tags for rail lines can be:

Key Value Description
line rail indicates a rail line
alternate yes / no indicates an alternate course or a main course
service high_speed / long_distance / regional / commuter high speed, long distance, regional or commuter service?
ref number or text line number
nat_ref number or text national line number
name text special name (e.g. Raving Rantanplan)
color text line color (HTML named color or web color in hexadecimal format)
text_color text line text color (HTML named color or web color in hexadecimal format)
by_night yes / no / only service by night?
operator text operating transportation company


Light rail lines

Tags for light rail lines can be:

Key Value Description
line light_rail indicates a light rail line
alternate yes / no indicates an alternate course or a main course
ref number or text line number
nat_ref number or text national line number
name text special name (e.g. StarLine)
color text line color (HTML named color or web color in hexadecimal format)
text_color text line text color (HTML named color or web color in hexadecimal format)
by_night yes / no / only service by night?
operator text operating transportation company


Metro lines

Tags for metro lines can be:

Key Value Description
line subway or monorail indicates a metro line (subway or monorail line)
alternate yes / no indicates an alternate course or a main course
ref number or text line number
nat_ref number or text national line number
name text special name (e.g. Metro X)
color text line color (HTML named color or web color in hexadecimal format)
text_color text line text color (HTML named color or web color in hexadecimal format)
by_night yes / no / only service by night?
operator text operating transportation company


Tram lines

Tags for tram lines can be:

Key Value Description
line tram indicates a tram line
alternate yes / no indicates an alternate course or a main course
ref number or text line number
nat_ref number or text national line number
name text special name (e.g. CreepTram)
color text line color (HTML named color or web color in hexadecimal format)
text_color text line text color (HTML named color or web color in hexadecimal format)
by_night yes / no / only service by night?
operator text operating transportation company


Passenger ferry lines

Tags for passenger ferry lines can be:

Key Value Description
line ferry indicates a passenger ferry line
alternate yes / no indicates an alternate course or a main course
ref number or text line number
nat_ref number or text national line number
name text special name (e.g. Channel Star)
color text line color (HTML named color or web color in hexadecimal format)
text_color text line text color (HTML named color or web color in hexadecimal format)
by_night yes / no / only service by night?
operator text operating transportation company


Network information (public transport networks)

Currently, public transport networks are not being modeled as superior relations very often in OSM. This situation shall be changed by means of this proposal: A public transport network relation shall contain all lines and stopping points of the network as members. At this, the incorporation of the stopping points is more important than the incorporation of the lines because the former delimit a network whereas the latter are often just partially included in a network: Such parts of lines can only be delimited and thus identified by the stopping points defining the line course. To mark a relation as a public transport network relation, the tag public_transport=network shall be used.

Additional tags for public transport networks can be:

Key Value Description
name text name (e.g. Chicago Transit Authority)
abbreviation text abbreviation of the name (e.g. CTA)

See also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Public_transport_schema&oldid=278795"