Proposal:Simplified Public Transport Scheme
| Public Transport | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | stanton |
| Tagging: | [[Key:*|*]]=[[Tag:*=*|*]] |
| Applies to: | node,way,area,relation |
| Definition: | Stops and routes of public transport lines |
| Statistics: |
|
| Rendered as: | Various |
| Draft started: | 2011-01-27 |
Summary
Defines a tagging scheme for public transportation stops/stations (bus, tram, underground, suburban rail etc.) and routes of lines serving them.
Reasoning
A lot of efforts to map public transport already exists in different parts of the world. However, the tagging schemes are not well-defined: a number of different practices exists and, as a result, tagging is inconsistent between areas and sometimes even within the same city, and many discussions about the correct tagging scheme have taken place.
The present proposal is the first attempt at providing a universal standard. It is intentionally limited to the most basic features in order to keep the proposal and discussion manageable. This does mean that at this stage it cannot fully represent some of the more complex situations. Once the proposal is approved, further features for more complex cases can be submitted for separate discussion and approval.
Design goals for this proposal are:
- Reality (stops and routes) must be represented in a clear, correct and unambiguous manner
- Information should be easy to maintain and update
- Tagging should be compatible with existing schemes: de facto standards should be abandoned only if they are in conflict with one of the above criteria
How to Map
Stops
Underground, suburban/light railway and railway stations can be tagged as a node. Large stations can also be tagged as an area. The tag to use is always railway=station. For details refer to Railway stations.
Bus, trolleybus and tram stops are represented by a node beside the way, at a position where passengers would normally board the vehicle. This approach is preferred over placing the node on the way because it offers the following advantages:
- Stops are typically located at one side of the street; placing the stop beside the way maintains this information. (For two facing stops, one on each side of the road, map two stops.)
- Certain attributes (shelter, reference numbers) typically apply only to one side of the road; merging two facing stops into one single point would cause confusion.
Association with a way (where needed) is still possible by analyzing spatial information (stops can be assumed to belong to the nearest road) and certain tags (e.g. layer).
This approach is already widely in use for bus stops. The original proposal included switching tram stops to the same scheme, though there appears to be some controversy on this point. The arguments for either side are listed below:
| Tram stop next to way | Tram stop on the way |
|---|---|
|
|
Useful tags:
| Tag | Description |
|---|---|
| highway=bus_stop | Required for bus/trolleybus stops. Identifies the point as a bus stop. It is also used for trolleybus stops as the infrastructure is usually the same for both (passengers would perceive them in the same way). Whether the stop is actually served by buses, trolleybuses or both can be derived from route relations. |
| railway=tram_stop | Required for tram stops. Identifies the point as a tram stop. |
| name=* | Recommended. The name of the stop. |
| Required for stops on bridges or in tunnels. Use the same tags as for the road to which the stop belongs; this will allow associating the stop with the road in case of multi-level traffic. | |
| shelter=* | Optional. Indicates whether or not the stop is equipped with a shelter. |
| ref=* | Optional. Asset number of the stop (where known), usually a plaque on the pole or shelter. Not all networks use it (or do not use it for all stops). |
| Optional. If relations exist for each route and the stop is a member of them, this information can be derived from the stop's membership in route relations. If you map a stop without immediately adding it to the appropriate route relations, you may still want to use these tags in order to allow other mappers to correctly join the stop to a route. | |
| uic_ref=* | Optional. The UIC reference number of the stop, if known. This is a unique reference number which will allow other applications to exactly identify the stop. |
Routes
The routes of public transport services used are represented by relations. The route relation specifies the transport type; the classification in this proposal follows the principle found on the Public Transport page:
- So, when choosing which type a particular public transport service falls into, it's generally best to go with whatever the users of that service general understanding of it would be.
Thus the following transport types are used:
- rail: Regional or long-distance railway services, operating on standard railroad infrastructure
- light_rail: Light or suburban rail services, often with one common inner-city section in a tunnel; also used for light rail/tram hybrids which use both railway and tram infrastructure (a system pioneered in Karlsruhe, Germany)
- subway: Underground/subway/metro/U-Bahn services: mostly underground and confined to a city though in some cases may include overground sections and may extend beyond the city boundaries
- tram: Tram services: mostly urban, on rails embedded in streets or on separate rail lines running parallel to streets; also used for interurban trams (metrotrams)
- trolleybus: Trolleybuses, powered by an electrical overhead wire
- bus: Fuel-powered buses
- ferry: Ferry services; can be anything from the Venetian vaporetti (urban/suburban services) or the Kiel-Klaipėda line (with transit times close to 24 hours)
Tagging suburban rail services (e.g. S-Bahn in German-speaking countries) as route=light_rail differs from current usage, which seems to distinguish between services using mainline-like infrastructure with an overhead wire and those using a dedicated, subway-like system with an electrified third rail. However, since the technology difference is irrelevant to the user and both systems are advertised with the same brand name and logo, the principle of matching users' expectations mandates using the same tag for both.
It does, however, match current tagging practice for the hybrid system in Karlsruhe, which uses the S-Bahn logo and the letter S in line numbers, though without using the name S-Bahn.
Trolleybus services are distinguished from bus services since trolleybuses are usually articulated and, due to their faster acceleration, have reduced transit times compared to fuel-powered buses, hence users will most likely perceive buses and trolleybuses as different services. This is also consistent with current usage and with the way services are advertised by their operators.
Bus and ferry services are a wide category, which may range from urban to international. Additional tags to distinguish the range are possible and probably worthwhile but are not part of this proposal.
Relation members:
| Role | Description |
|---|---|
|
|
Used for ways; specifies in which direction the route follows the way. Consistently with other relations, the role is relative to the direction of the way (forward means in the direction of the way, backward means against it). It has nothing to do with the outward or return direction of the service; either of them may have members with either role. |
 stop
|
Used for stops, which can be nodes or areas (ways are unlikely but renderers should not rely on that). |
Useful attributes:
| Tag | Description |
|---|---|
| Required. Indicates that the relation represents a public transport route of the indicated type. | |
| ref=* | Required. The line number as shown on timetables, stops and vehicles. |
| Recommended. Name of the first and last stop (beginning and end of course). | |
| via=* | Optional. Can be used to distinguish route variants with the same number; this can be a stop, place, area or route section served only by this route variant. |
| network=* | Recommended. The public transport network to which the service belongs. The principal characteristic of a network is usually a common ticketing system; common advertising and information (network scheme issued by the participating transport companies) are also indicators. |
| operator=* | Optional. The company actually providing the service. In smaller towns operator and network may be identical, bigger networks may have multiple operators for different services. |
| colour=* | Recommended where applicable. If the operator/network consistently uses one color unique to that line to identify it (e.g Underground lines in London), use that here. Specify as a color name (colour=red) or as a RGB color (colour=#FF00FF). |
| name=* | Optional. If the service is known by a name (e.g. Piccadilly Line), enter it here. Note that this tag is sometimes misused to repeat values of the ref/from/to/via tags in order to make the relations distinguishable in the editor; this is strictly speaking incorrect usage. The author of this proposal hopes that editors will one day come up with a more intelligent way of identifying relations in the list, eliminating the need for this incorrect usage. |
One Relation per Course
Keeping the course for outward and return directions in separate relations clearly associates ways with the outbound or return direction. It also allows for easy detection of missing pieces by arranging all ways in such a manner that each way shares one node with its predecessor and one with its successor in the list.
For the simple case of a route which goes from A to B and back, this would imply two relations (one for the course from A to B, one for the course from B to A).
Multiple relations belonging to the same line can easily be identified by analyzing their type=*, route=*, ref=* and network=* tags (they would be identical); optionally also operator=* and name=* can be used. For extra certainty, the convex hulls of members can be analyzed using standard GIS database procedures: if they overlap, the relations most likely belong to the same route.
Keep Relations Sorted
In order to allow precise identification of the route, keep ways and stops ordered by their position on the course. This is particularly important for self-crossing routes where this information cannot be reliably determined otherwise. Some renderers (e.g. for route sketches) depend on the correct order of stops.
Stops and ways should be kept separate: first all the ways, then all the stops or viceversa.
This approach also makes it much easier to verify ways and stops for completeness. Ways can be analyzed as described above, stops can easily be compared to an existing list.
Circular lines
Circular lines may be served in either one or two directions; depending on that, create one or two relations. The first stop is also the last stop and in fact gets added to the relation twice: once at the beginning and once at the end of the stop list.
Identifying the first stop of a circular line may be difficult if passengers may travel between any two stops on the line and is somewhat arbitrary. Pick one single stop on the line which satisfies as many as possible of the criteria below:
- Indicated as the destination of the route by the operator
- Early morning/late evening/peak-hour courses begin or end at this stop
- Longer than usual waiting time (several minutes) to allow compensation for delays in schedule
Spoon lines
Spoon lines are lines which start from a terminus with a piece of route served in both directions, then follow a (one-way) loop and return on the first piece of route, this time in the opposite direction, giving a route sketch a spoon-like shape.
A typical stop sequence would be A-B-C-D-E-F-C-B-A. With such lines it is difficult (if not impossible) to tell where the outward course ends and the return course begins.
Assuming that passengers can travel any piece of way (i.e. there is no single stop on the way at which all passengers are expected to get off), such lines can be treated as a special case of circular lines (with one clearly identified terminus) and are thus best represented by a single relation. (A second relation would make sense if there were a second course serving the same stops in the opposite direction, i.e. A-B-C-F-E-D-C-B-A).
Tag the Route Only
Often a bus will not follow the whole length of a road but only a section of it. Where this is the case, split the way and add to the relation only the part which actually forms part of the route. This also goes for roundabouts - split it as needed and maintain the junction=roundabout tag on all pieces.
How to Render
Stops
The stop types mentioned in this proposal are already being rendered on the main map. Changes to current rendering are not part of this proposal.
Routes
Routes are not intended to be rendered on the main map. Specialized public transport tabs may render routes as colored lines on the roads, labeled with the line numbers.
Comments
Constructive criticism, comments and discussion can be posted on the talk-transit mailing list or on the Discussion page.