User:Rurseekatze/Simple Public Transport Draft
![]() | This page describes my thoughts about a simplified way of public transport mapping. Do not use this tagging yet, it is still in development! |
This page describes a draft of a simplified method of modelling public transport in OpenStreetMap.
Motivation
PTv2 considers mapping every route variant with separate relation. This is not practicable for public transport lines with a fragmented timetable with a lot of route variants (example), as it requires a lot of relations with redundant information.
Goals
- Reduce the required work
- Reduce dependencies of data
- Better support in editing tools
Description
The focus of this draft is less to create a complete new tagging schema, but to collect all information related to public transport and to create a roadmap on how to establish this schema by improving documentation, adding support to editors and renderers and creating quality assurance tools.
Tagging
Infrastructure
Both stop positions and platforms are always required for a public transport stop. Mapping just one of both may reduce redundancy in some cases, but makes it difficult to use the data because applications have to consider different cases. Mapping both stop positions and platforms explicitly makes it also easier for quality assurance tools to check the completeness of the data.
Stop positions
A stop position is a place where a public transport vehicle (bus, train, etc.) stops along a public transport route to pick up or drop off passengers. It is mapped as a node on the way (road, railway track, waterway or aerialway). This tag can be used for any transport mode, or combination of transport modes. A stop position should have an associated platform. Stop positions are necessary for routing purposes because they ensure the right position of a public transport stop in the network graph of roads, railways, waterways or aerialways.
Tag | Description | Recommendation |
---|---|---|
public_transport=stop_position | Defines this node as a stop position of a public transport vehicle. | required |
name=* | The name of the stop position. | required |
operator=* | TODO | required |
operator:wikidata=* | TODO | optional |
network=* | TODO | required |
ref:IFOPT=* | TODO | optional |
local_ref=* | TODO | optional |
Platforms
A platform is a place where passengers are waiting and entering or leaving a public transport vehicle. It is mapped either as a node, a way or an area. This tag can be used for any transport mode, or combination of transport modes. A platform must have an associated stop position. Platforms are necessary for rendering on a map and routing passengers to the platform.
Tag | Description | Recommendation |
---|---|---|
public_transport=platform | Defines this node, way or area as a platform. | required |
name=* | The name of the platform (equal to the name of the associated stop position). | required |
operator=* | TODO | required |
operator:wikidata=* | TODO | optional |
network=* | TODO | required |
ref:IFOPT=* | TODO | optional |
local_ref=* | TODO | optional |
Stations
Stop areas
Relations of stop areas are not necessary in most cases because they provide redundant information. A stop area can also be created by grouping stop positions and platforms by their name, their operator, a reference like ref:IFOPT=* or their geographic distance, for example with a GROUP BY
statement of a database.
Stop area relations are necessary, if applications are not able to easily recognize that stop positions and platforms are forming a single stop. This is the case when their name=*, operator=* or type of transit (bus, train, etc.) differs within the stop. If all stop positions and platforms of a stop have the same name=*, operator=* and type of transit, a stop_area relation is not necessary.
Routes
Tag | Description | Recommendation |
---|---|---|
type=route | Defines this relation as a route relation. | required |
route=train/light_rail/tram/subway/bus | TODO | required |
service=high_speed/long_distance/regional/commuter/car/car_shuttle/night/tourism | TODO | required |
ref=* | TODO | required |
name=* | TODO | required |
service=* | TODO | required |
operator=* | TODO | required |
wikipedia=* | TODO | optional |
wikidata=* | TODO | optional |
color=* | TODO | optional |
text_color=* | TODO | optional |
public_transport:version=1 | TODO | required |
Route direction
This solution is similar to PTv1, but the relation contains just the ways, but no stop positions and platforms. There would be just one relation collecting every way that is used by this line without a correct order being necessary. Adding stop positions or platforms to the relation is not necessary because stop positions are already part of the ways. There would not be any mapping of route variants.
Pro
- Sufficient for rendering maps such as OpenPtMap; no preprocessing necessary
- Just one relation for each line necessary
- Very easy to map lines with a lot of route variants example timetable
- Less redundancy of route variants that differ only in details
- Still contains the information which ways exactly are used by a line. This allows it to calculate the correct route by routing. To route a single route variant, just download the relation and use the member ways as routing graph.
Contra
- Still dependencies between ways and route relations with a risk of broken relations
- Does not contain information about route variants, external information necessary to be able to calculate a route variant using exactly the right platforms and stop positions
- Mapping of very long routes, e.g. long distance trains or travel coaches requires a lot of manual work and creates relations with a lot of members
Route master
Route master relations are not necessary any more because route variants are not mapped as separate relations in this schema. Route master relations would also provide redundant information.
Examples
Simple bus stop
Combined bus and tram stop
Railway station
Bus route
Local train route
Long-distance train route
Advantages
Disadvantages
Differences to PTv2
Use Cases
Retagging of old data
Status
- Write a tagging draft (in Progress)
- Discussion on mailing lists, on the talk page and the forum
- Write a JOSM tagging preset
- Create example data to check the pratical usage and get experience
- Develop implementations that use the new schema
- Write validation rules and develop quality assurance tools for mapper feedback and as a help to update old tagging to the new schema
- Develop automatically generated lists that replace the existing manual lists in this wiki