Proposal:Public transport schema
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.
Background
Workshop June 2009
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:
- Markus Bader
- Christian Berreth
- Christoph Eckert
- Heiko Jacobs
- Matthias Merz
- Melchior Moos, author of a public transport map based on OSM data
- Frederik Ramm
- Thomas Reincke, employee of Aachener Verkehrsverbund GmbH (public transport authority of Aachen, Germany)
- Frank Sautter
- Sebastian Schwarz
- Jochen Topf
- Malte Ahrens
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 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.
Infrastructure on which public transport vehicles operate
Public transport vehicles operate on roads, railway lines (subway, mainline), tram tracks, rivers, canals and on routes across open water such as ferry services on lakes and the sea. Conveyor services also need to be modeled, as do monorail services and guided buses.
The following table lists all possible types of line-like traffic infrastructure in public transport. The table also shows how those types are currently (May 09) modeled in OSM according to the existing schema and suggests how they would be modeled 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) |
---|---|---|---|---|
Aerialways | aerialway=* | aerialway=* | ||
Conveyors | nonexistent | nonexistent | highway=conveyor | |
Escalators | highway=steps and escalator=yes | highway=steps and escalator=yes | ||
Ferry | nonexistent | route=ferry | waterway=ferry_way | |
Funicular railway infrastructure | nonexistent | nonexistent | railway=funicular | |
Guided bus infrastructure | highway=bus_guideway | highway=bus_guideway | ||
Light Rail services | railway=light_rail | railway=light_rail | ||
Mainline railway infrastructure | railway=rail | railway=rail | ||
Metro infrastructure | railway=subway or railway=monorail | railway=subway or railway=monorail | ||
Tram infrastructure | railway=tram | railway=tram | ||
Trolley buses infrastructure | nonexistent | nonexistent | highway=* and trolley_wire=yes |
Aerialways
to be added
Continuous services (escalators, 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? |
Highway services (bus, coach, guided bus, trolley bus)
to be added
Railway Infrastructure
OSM currently models railway services in an inconsistent way. 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:
Modeling multi-track railway lines
Multi-track parallel railway lines in close proximity can be modeled as a single way with tracks=x, or as a number of parallel ways. If individual tracks have different tagging requirements (max-speed, electrification, gauge etc) then the tracks should be modeled appropriately. The tracks=* tag should be used to record the number of tracks with a default value of 1
being assumed where this is not supplied.
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 |
Light railway
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 |
Metros/ Underground
Metros should be tagged railway=subway.
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.
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 |
Mainline Railway
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:
- usage=main for main lines
- usage=branch for branch lines
- usage=industrial for industrial railways
- usage=military for military railways
- usage=tourism for touristically used railways
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 |
text | loading gauge as per Wikipedia Loading gauge article |
electrified |
yes / no / contact_line / rail |
type of electrification |
voltage |
number | voltage in volt |
operator |
text | operating infrastructure company |
Monorails
Monorails shouild be tagged:
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.
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 |
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 |
Waterway services (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.
Places where people access public transport
It is not possible yet to model the places where people access public transport (bus stops, tram stops, railway stations, airports, ferry terminals etc) in a consistent way. Additionally there no way to model a transport interchange which served multiple public service vehicles with multiple platforms, entrances etc.
The Stop Place model
A standard set of terms are proposed to cover all transport modes, avoiding calling a point where one boards a vehicle either a bus stop (bus), tram stop (Tram), a platform (Train/Underground/Metro), a quay (ferry) and a gate (airport). 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:
- A stop place comprising one or more locations where vehicles may stop and also ones where passengers may board or leave vehicles or prepare their trip. A STOP PLACE will usually have one or more well known names and may also be associated with entrances. A railway station, airport, or pair of bus stops on opposite sides of the road are all Stop Places.
- the stop place group A group of Stop places that where passengers may board or leave vehicles or prepare their trip. It will usually have one or more well known names. For example Heathrow Airport is made up of a number of Terminals, an underground station, a railway station and a coach station as well as taxi ranks and other bus stops.
- An access is a feature such as bus stop, platform, stance, gate or quayside where passengers have access PT
vehicles, taxis or other means of transportation. An Access may serve one or more stopping places (for example where one platform serves trains from either side.
- A stopping place is a position on the vehicle trackway where vehicles stop in order for passengers to board or alight from a vehicle.
The graphic above shows that the model consists of a stop place (as a relation) contains at least one stopping place and either zero or more Accesses. 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 place
A stop place (a station, airport, pair of bus stops etc) shall be modeled as a relation and 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 |
If a Stop Place would contain a single Access, the the above tags can as an alternative be associated with the Access and no Stop Place is requires. – including the tag operator=*.
Stop place group
A stop place group (a grouping of Stop Places such as an associated Railway station and Airport or Railway Station and group of Bus Stops shall be modeled as a relation and tagged with public_transport=stop_place_group. It 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
Access
An Access is a railway platform, ferry quay, bus stop, taxi rank or similar. The geometry and the characteristic tag an access shall be modeled with depends from the type of the access:
Type | Geometry | Tags |
---|---|---|
platform or stop sign | or or | public_transport=platform |
entrance | 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.
Stopping place
Stopping place shall be modeled as nodes within the highway, or railway, tramway etc and should be tagged with public_transport=stopping_place.
Although the described model for stop places makes the stops independent from the public service vehicles, additional tags shall be used for stopping places 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 places. But this would be considerably more difficult to implement.
Q: When should one relate a number of bus stops as a single Stop Place? A: If two bus stops are directly facing, a number of stops in a row close together or form a group around a junction and if they are known by the same name then they should be modelled as a single Stop Place.
Examples for the application of the model for stops
In the most simple case there is only one stopping place with a name:
If two accesses are "joining" the stopping place a stop place shall be created:
If two (not necessarily adjacent) stop places belong to one stop a stop place group shall be created:
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 places 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 place (as a relation member)
- access (as a relation member)
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 places 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 places, 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 places. Secondly, stopping places 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 places of the network as members. At this, the incorporation of the stopping places 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 places 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) |