Proposal:Refined Public Transport

Refined Public Transport
Proposal status:	Proposed (under way)
Proposed by:	Zverik
Tagging:	`public_transport=*` Data item
Applies to:
Definition:	We are refining the current PTv2, making it more practical and easier to use.
Statistics:
Draft started:	2018-07-08
RFC start:	2018-07-20

Proposal

The public transport proposal, approved in 2011, introduced many concepts into mapping public transport. Some of these were great, like splitting routes into variants. Others were too complex for a common mapper, and frankly, redundant — like stop positions. Mappers have made attempts at simplifying various aspects of PT mapping: like, limiting stops to nodes only, or dropping extra tags.

This proposal aims at simplifying the mapping of public transport stops and routes as much as possible. For example, with this proposal, mapping a route as a role-less collection of highway=bus_stop nodes would be correct. At the same time, it is mostly backward compatible with PTv2 and does not make any PTv2 routes obsolete. The proposed schema is better suited for applications besides renderers: e.g. for routing with public transport.

Rationale

While the current public transport v2 schema solved the issue of PT routes being an unsorted pile of everything remotely related to a route, it failed to address some other issues, and introduced some of its own. For example:

Stop positions. They complicate everything: from mapping (these points can be deduced automatically) to navigation (which side of the road is a platform on?) to route management (ever tried to reverse a route with stop positions and platforms?)
Object duplication. Instead of solving the tram_stop (on tracks) vs bus_stop (beside a road) issue, it made mappers put nodes both on tracks and beside them.
Tag duplication. You need to put all stop attributes both on the stop position and on the platform. And on the station object, if you have it. And on the stop area.
Uncertainty with stop areas. What are they even for?
Optional stops in route relations. For a relation to be useful, you need to know where to get on and to get off the bus. Mandatory highways benefit a renderer, but optional stops remove any usefulness from a route relation.

Mapping and using a public transport route should not be that hard. It takes a lot of work already to map all the stops and collect highway segments, why complicate it even further with extra tags up to 31 characters in length?

This proposal tries to remain compatible to PTv2 as much as possible, but to make both editing and using routes simpler. Three main changes from PTv2 are:

All stop/station-related tags go on just one "main" object.
public_transport=stop_position, =platform and =station are optional. They can be used, but they should be backed by proper main tags.
Stops (platforms) are mandatory for a route relation, and segments are not.

Also it improves on and makes clearer these points:

There is a single mandatory "main" object for each stop and station.
Entrances are part of the schema.
Usage of public_transport=stop_area is clarified.
public_transport=stop_area_group is reintroduced.
Most roles in relations were made optional.
ref=* or name=* are mandatory for routes.

Main Object

This proposal introduces a concept of a single main object for a stop or a station. While this has been a case for almost all stops by now, it was not clearly defined, which resulted in ambiguous stop area meaning and in complexity of assembling stop attributes.

Until now, we pretended a stop is a physical object, which can be mapped as per "truth on the ground". That's why we've got platforms and stop positions in PTv2 instead of some abstract bus stops. But this introduced many issues — exactly because a stop is a virtual object. It might not even have any physical manifestation — sometimes it's just a tiny timetable on a pole, or nothing at all. There would be no object to put public_transport tags on. But the stop is there — a virtual object does not depend on real objects.

That has been partly reflected in railway station tagging: the mandatory railway=station is virtual, unlike railway=platform and railway=stop. And in railway tagging, PTv2 is lacking: its public_transport=station is not an exact replacement, and the purpose is not obvious. By focusing on real objects, we can say PTv2 lost the stops.

What's the alternative? Reintroducing stops and stations, obviously. Borrowing from the railway station tagging, now every kind of stop has a "main object": the one that's got all the important tags, like name, operator, wikipedia link, and reference number. Unlike PTv2, you don't need to copy these tags all over, on platforms, stop positions, stop areas and so on. Just one object — and preferably a node — describes the entire stop or station.

A stop has a set of tags that doesn't intersect with platform tags. Which means, it is recommended to merge these two objects when both are points. To put it simply, a single railway=tram_stop node beside rails is enough to mark both a tram stop and its platform, when the exact geometry is not known.

This change also puts sense into stop areas: now they link parts of a stop to the main object. Most commonly, platforms and entrances. This means route relations need only platforms for each stop. And that you would need to create a stop_area relation every time you draw a railway=platform for a tram stop. Hopefully editors would make that as simple as clicking a button — which you can do even now with a preset.

Tagging Stops

Stops and Stations

Bus stops should be beside a road
Tram stops on rails are discouraged, unless there are platforms
Tram stops serve as platforms, like in bus stops

A stop or a station is a single object denoting an approximate location of where a vehicle stops to drop off and pick up passengers. It should be placed near a signpost or a platform, inside a station building, or between all the platforms for the stop.

Stations and stops are not much different: public transport stops at these, and they all can have platforms and other infrastructure. The difference is usually administrative, that is, stations are bigger than stops.

Use one of the following tags for the station object:

highway=bus_stop for bus and trolleybus stops.
amenity=bus_station for bus and trolleybus stations.
railway=tram_stop for tram stops.
railway=halt for light_rail and train stops.
railway=station for light_rail and train stations.
railway=station + station=subway for subway stations.
aerialway=station for aerialway stations.
amenity=ferry_terminal for ferry terminals.

Attributes are the same as before: use name=*, operator=*, ref=* and other tags.

If you wish, you can specify types of public transport that uses the stop or the station with bus=yes, tram=yes, subway=yes etc., although these tags are optional, often implied by the main tag. Useful additional tags, copied from the PTv2 proposal, are:

name=* with translations
ref=*
uic_name=* and uic_ref=*
operator=*
network=*

We recommend mapping a stop or a station with a single node. Using an area usually contradicts the One feature, one OSM element principle. It is okay to use an area, e.g. for a bus station, if it does not have any other meaning — but please do not make a multipolygon, use a closed way. Please consider splitting the stop or the station from:

Platforms

Single bus stop and two platforms
Possible, but not recommended: platforms as nodes. Use ways or two bus stop nodes
Platform is an area, common for railway stations

A platform is a physical object — a signpost, a shelter or an actual platform — where passengers wait for their vehicle. Routing engines should bring users to a platform object for a stop or a station. Route relations have platforms for stops.

In simple cases, a platform object is the same as a stop/station object. For example, a bus stop usually is a single highway=bus_stop node, which serves both as a stop object (i.e. it has all the attributes for a stop) and a platform (i.e. it denotes a physical object). For tram and railway routes, it is common to draw a separate platform, leaving a station node as a virtual object, or a stop position.

stop_positions are not mandated by this proposal. We recommend not to map them. A stop and a platform objects are enough for nearly all stops/stations. For data consumers, if a stop or a station has a stop_position, but no platforms, that stop_position serves as a platform. That is, it should be a part of route relations, and routing engines and renderers should approach it the same way.

Use one of the following tags for a platform object, when it is distinct from a stop or a station:

highway=platform for bus and trolleybus platforms.
railway=platform for tram, light_rail, train and subway platforms.
railway=platform_edge for the same.
man_made=pier for ferries.
public_transport=platform in general — not recommended, but okay if you prefer the PTv2 way, or cannot choose between the tags above.

We recommend mapping platforms as lines or areas. For point platforms, consider placing the stop or station node there instead.

A separate platform object should have only a name for convenience — all other attributes can be found on a stop or a station object.

Regardless of how the platform is mapped, you can use these additional tags on it, copied from the PTv2 proposal and taginfo:

area=yes (only when the platform is an area)
shelter=yes/no
bench=yes/no
bin=yes/no
covered=yes/no (different from shelter: it's when a platform is underground or covered by a bigger structure)
wheelchair=yes/no/limited
tactile_paving=*

Entrances

Subway entrance node
Entrances to a train station

When a station has a complex structure — for example, it is underground or indoors — please map entrances to it. Routers should direct users to entrances, where they can switch to using signs for navigation.

Entrances should be mapped as nodes only. Use one of the following tags for an entrance object:

entrance=yes/main/exit/entrance for buildings and overground stations.
railway=subway_entrance for underground stations.
highway=elevator for elevators. Combine it with subway_entrance tag if it is also an entrance into an underground station.

When an entrance is one-way, use either specific entrance values, or entry_only or exit_only role in the stop area relation. All entrances to a stop or a station should belong to at least one such relation.

Stop Areas and Groups

When a stop has more than the main object, it needs a stop area relation
A stop area must have just a single main object
Please link platforms to stop objects with a relation

When a stop or a station consists of more than one object, all objects mentioned above should be grouped in a stop area. It is a relation with only three mandatory tags:

Inside it should have the minimum number of objects that comprise a stop (roles are optional):

a single (!) stop or station object,
related platforms,
stop positions (only if they are present, please do not add these yourself),
entrances.

All stop tags go on the stop or station object, but you can override some of these (not name) with the stop_area relation. For example, ref:gtfs may be different for each platform (in different stop areas) for a single stop. You should try avoiding putting a single platform into multiple stop areas.

Stops that are close by and share a name should not be grouped in a stop area by that reason alone.

For example, two bus stops with the same name on different sides of a road are two separate stops, and provided they have extra features (e.g. platforms), they should have two separate stop_area relations. On the other hand, a subway station with several platforms is usually grouped into one stop_area relation.

When stops are identical (names and refs are the same), you can use just one stop object
Stop_area_group relation groups only stop_area relations

Multiple stop_area relations that are close by and are considered parts of a single stop group on maps and official documents, may be grouped in a public_transport=stop_area_group relation. They should be, if some of the stops are underground, or there are no highways or footways linking platforms or entrances of these stops or stations.

Examples are, subway stations inside an interchange, or bus stops located inside a bus terminal.

Tagging Routes

Route relations are tagged as they do now. There are no changes in tagging. Except that at least one of name=* and ref=* tags is now mandatory.

Routes still can be collected in route_master relations. Creating these is highly recommended.

A route relation has two non-interleaving groups of members: stops and route segments. The order of groups is not important, although we recommend listing stops first, for the ease of editing.

Each stop should have one and only one object in a route relation. Exception: when you entry using one platform and exit to another (group these in a stop_area and see roles below). Since many relations currently have more than one object per stop (e.g. stop_position and platform), it is also allowed, but all such objects must be grouped in a stop_area relation.
Roles for stops are the same: stop or platform (do not matter and may be omitted), entry_only, exit_only, and the same two with platform_ or stop_ prefix.
Route segments (highways, railways etc.) must form a continous line from the first to the last stop. If there are branches, make a separate route variant for them.
Route segments are added without roles. One exception is hail_and_ride role for hail-and-ride parts of the route.
If a route is circular (that is, in A→B→C→D→A→... you can get from C to A), the last stop in the route should equal the first. Also the first node of the first route segment should be the same as the last node of the last segment.
Stops are mandatory for a route relation, route segments are optional.

An example of a properly mapped route relation with platforms and route segments:

So the difference from PTv2 is:

Mandatory name=* or ref=*.
Roles are optional, except for entry_only, exit_only and hail_and_ride.
A single platform is enough for a stop.
Stops are mandatory, roads are optional.

Examples

Minimal correctly mapped bus route: single highway=bus_stop on stops (names are recommended, of course), collected in two routes: one from "Start" to "End" and one in the reverse direction. Only three tags are required on a route relation: type=route, route=bus and ref=* (or name=* if there is no ref). A Route Master relation is optional, though highly recommended.

Such kind of a bare-bones route is easy to map and assemble; with the magic of Sparse Editing you can map an entire bus network for a medium-sized city in a day. And then begin adding extra properties and roads to relations.

An extensively mapped subway route would mean stations like this in route relations that have platforms for stops and all railway=subway ways in order. All stations are grouped in stop areas (with stop area groups on interchanges), and all route relations are collected into route masters with matching tags.

Q & A

But this proposal does not change anything!: That was the intention, thank you. This proposal does not affect renderers and data users, since all of these tags have been used before. And it does not require any retagging, except for rare cases with public_transport=platform not backed up by a conventional tag.

Though it does, doesn't it?: A bit. You have to list all the platforms now (not just roads), and possibly link them to stop or station objects with stop areas. First is pretty common though.

How does it affect public_transport=* tags?: It makes stop_position, platform and station values obsolete. The latter two have been backed by other tags, e.g. by highway=bus_stop or railway=station. Stop positions are new, and supported by this proposal, although it does not require mapping these anymore.

Eight tags for stops and stations instead of two in PTv2! Isn't this worse?: All of these tags have been in use for much longer than PTv2 tags, and they are easier for novice mappers to understand. New public_transport tags are almost always backed by these, since most renderers cannot use the new tags. Eight tags replace a hundred combinations of PTv2 tags with bus=yes and such.

But these two tags were easy to remember and to understand!: The distrinction between PTv2's platform and stop_position is purely technical. You can derive a tag value from geometry: stop positions are on roads, platforms are not. So basically what PTv2 did, was removed the rainbow of PT tags and replaced them with a single inconsistent (you can't have bus=yes on platforms, only on stop positions) type of object. This proposal partly reverts that.

Why not create a single tag for the main object in a stop or a station then?: That would make millions of already mapped stops invalid. This proposal aims to be as compatible to PTv2 as possible.

Don't that many tags complicate things for a router?: That's the beauty of it: they don't. What matter for a router are objects that go in a route relation. These are always considered platforms. Which means, it has to navigate a user towards a closest non-segment object in a route relation. In more complex cases, it can check for entrances and main objects using stop_area relations. The answer is never more than three steps away.

Isn't it a revert to PTv1?: It takes the best of two versions. Tags are now better understandable, but route variants are there. The proposal also improves on object connectivity and hierarchy, so consumers know where to look.

So... Roles are optional, road segments are optional, virtually all tags are optional too. What isn't?: A single main object for a stop, and if there are other parts of that stop, a stop_area relation is required. And a platform or that main object should be included in some route relation.

Does railway=tram_stop go on tram tracks or on platforms?: You can do either. We recommend putting these at signposts when there are no platforms or there is just one track. That way people would know from which side to approach the stop. Otherwise you would need to group a tram_stop with a platform using a stop_area relation. In this proposal, there is no distinction between mapping a bus stop and a tram stop (or any other kind of stop or station).

What if a tram stop is also a bus stop?: It is possible to put both tags on a single object — go for it! We recommend putting the node beside a road, near the waiting area. For data consumers, specific tags don't matter: only types of routes that use the objects do.

It seems there would be too many stop_area relations.: Yes, there will. And there will be many occasions where this relation was omitted, making routers guess which platform belongs to which stop. That is okay, it's how OSM works. We have many other obscure relations, and people tend to accept it.

But people won't add these stop_area relations.: We hope that with validators and editor tools in place, they will. For now, data consumers can also find required objects by distance, though it is prone to errors.

Since road members are optional, won't people stop adding them? That would break the rendering!: Stops are optional in PTv2, and people still add them to virtually every route relation. It will be okay.

Should I use public_transport:version=3?: Please don't. A route is either correct or not, and public transport schema versions are not the same as software versions. The tag was invented because PTv2 was not accepted by everybody. This schema replaces (by incorporating) both of these, so the tag will be obsolete.

Features/Pages affected

All the pages related to public transport.

Comments

Please comment on the discussion page.

Proposal:Refined Public Transport

Contents

Proposal