User:Polyglot/Bus stops and routes

Proposal for a simpler way of mapping public transport

• How can we describe bus stops in such a way that there is no limit to the amount of detail we can add, without ever needing to convert from a node to a way/area/relation? Or transfer tags from one node next to the way to a node on the way?
• What is the minimum we need to describe bus routes and make maps of them? If we want to get more mappers involved with mapping public transport, what I see happening in several places in Europe is too complex.

All we really want to know is where we can take the bus and how those buses get from one stop to the next.

The basic premise of this proposal is the use of 1 OSM object to represent a bus stop. For buses and trams a node next to the highway is what makes most sense.

Very often this node will start as:

highway=bus_stop.

To comply with the PT v2 scheme, we add:

public_transport=platform

And a mode of transport:

bus=yes
trolley_bus=yes
tram=yes

So far we have:

highway=bus_stop
public_transport=platform
bus=yes
trolley_bus=yes

or

railway=tram_stop
public_transport=platform
tram=yes

or

highway=bus_stop
railway=tram_stop
public_transport=platform
bus=yes
tram=yes

If there is an actual platform (and you like to see it rendered), add a way or an area:

highway=platform
tactile_paving=yes (optionally)
wheelchair=yes (if it is (in part) heightened)
area=yes (if mapped as a closedway)

At first I added public_transport=platform to these ways, but it's not strictly necessary for anything and some people get confused if there are 2 objects tagged public_transport=platform.

Of course we also need:

name
ref
operator
network
route_ref

And we could add:

bin=yes
bench=yes
shelter=yes

Although we can also map those as separate amenity=waste_basket, amenity=bench, amenity=shelter/shelter_type=public_transport objects.

I don't think it matters much that both the bus stop node makes a reference to the separate objects or not. I wouldn't remove bench=yes from the bus_stop node, simply because the waste_basket was mapped on its own separate node as well.

OK, so now we have nodes with all the relevant information about a bus stop. Let's use these nodes in the route=bus relations!

So what is all this talk about stop_position nodes, you ask? Well PT v2 wanted to unite people mapping bus stops as nodes on the highway with people who mapped them next to the highway. This seemed like a good idea at the time, but what we ended up with was a horribly complex scheme, where information is duplicated and thus harder to manage.

Some people will add the stop_position nodes to the routes, some will add the platform nodes and some will add both. Some will want to forgo the public_transport=platform nodes, or first convert them into platform ways (regardless of whether there is an actual platform) and add stop_position nodes and platform ways alternatingly.

If you want an answer to the question: how many stops does this variation of a line serve, you'll have to deduplicate those doubles first.

If you want to reorder the stops, you'll have twice as much work to do.

So please only add those highway=bus_stop/public_transport=platform nodes to the route relations, not the stop_postion nodes, not the platform ways.

If we do it that way, we only need name and the other details once. No need to add those details to the stop_position nodes.

Where I think the public_transport=stop_position nodes are definitely needed is at the start and the end of the itineraries. If the ways are split on those nodes, it allows to nicely describe where the bus starts its passenger route and where the last passengers get off.

All the other stop_position nodes in between are nice to have, but not crucial. No need to add them to the route relations and hence no need to duplicate the name tag to them.

Tagging

Proposal for a simpler public_transport scheme based on PT v2

Tags

Platform node (mandatory)

Key	Value	Mode	Use	Remark
Platform Node placed where the passengers await the vehicle or where the pole is, if present.
public_transport	platform		mandatory
train	yes		when applicable	mandatory
subway	yes		when applicable
monorail	yes		when applicable
tram	yes		when applicable
trolleybus	yes		when applicable
bus	yes		when applicable
highway	bus_stop		mandatory
name	Stop name		recommended
ref	reference or id		optional	recommended when known
local_ref	Platform identifier		when applicable	max 2 characters, is rendered as part of the name since 2014)
route_ref	semicolon separated List of line identifiers		when known, either because operator's data is available, or because it was surveyed	no real need to remove this when all routes are mapped as relations. It can still be used during validation too.
bin	yes / no		optional
bench	yes / no		optional
passenger_information_display = yes / no			optional
shelter	yes / no		optional
ref:IFOPT	de:xxxx:xxxx:x:x		when known	replace de with actual country code
tactile_paving	yes / no		when applicable
wheelchair	yes / limited / no		optional

Platform way (optional)

Key	Value	Mode	Use	Remark
Platform If there is an actual platform. .
highway	platform
railway	platform
tactile_paving	yes / no		if present
wheelchair	yes / limited / no		if elevated

Stop Position (optional)

Key	Value	Mode	Use	Remark
Stop Position as a node on the highway, front of the vehicle
public_transport	stop_position
train	yes		when applicable
subway	yes		when applicable
monorail	yes		when applicable
tram	yes		when applicable
trolleybus	yes		when applicable
bus	yes		when applicable
railway	stop		mandatory	railway=station or halt or tram_stop, should only be mapped once for every station

Stop Area (optional)

Key	Value	Mode	Use	Remark
Stop Area
type	public_transport		mandatory
public_transport	stop_area		mandatory
name	Stop name		mandatory
Relation members
Role	Referenced on	Mode of transport	Use	Remarks
stop	public_transport=stop_position	]	when applicable	Stop positions of vehicle
platform	public_transport=platform		when applicable	Passenger area
	amenity=*		when applicable	ex.: shelter, bench, bicycle_parking
building	train_station		when applicable	station building

Stop Area Group (optional)

Key	Value	Mode	Use	Remark
Stop Area Group
type	public_transport		mandatory
public_transport	stop_area_group		mandatory
name	Stop group name		when applicable	avoid name collision with stop_area relations
relation members
Rolle	referenziert auf	Verkehrsmittel	Verwendung	Bemerkung
	public_transport=stop_area		when applicable

Route

Key	Value	Mode	Use	Remark
Route One relation for each direction of travel and their variants.
type	route		mandatory
route	train		mandatory
	subway		mandatory
	monorail		mandatory
	tram		mandatory
	trolleybus		mandatory
	bus		mandatory
public_transport:version	2		mandatory	obviously only for routes that follow PT v2 conventions
name	Tram 310: Bochum=>Witten		mandatory	Eigenname oder Verkehrsmittel+Nummer+Routenhinweis z.B.: Bus CE64: Wuppertal=>Solingen Regel: Eindeutig aber kurzer Text
ref	N19		mandatory	only line reference
from	Bochum Höntrop		mandatory	locality and stop name of first stop
to	Witten Heven
via	Bochum Hbf		optional	only to distinguish between itinerary variants
network	VRR		when applicable	rowspan="2"	VRR#Betreibergesellschaften letzte Spalte.
operator	BOGESTRA		when applicable
wheelchair	yes / limited / no		optional
Relation members of route
Role	Referenced on	Mode	Use	Remark
platform / platform_exit_only / platform_entry_only	public_transport=platform		when applicable	stops appear in the correct order, twice if served twice
	highway=xxx oder railway=xxx		mandatory	sequence of ways without gaps traveled in the correct order from=* .. to=*

Route Master

Key	Value	Mode	Use	Remark
Route Master
type	route_master		mandatory	Neues Schema (PTv2)
route_master	train		mandatory
	subway		mandatory
	monorail		mandatory
	tram		mandatory
	trolleybus		mandatory
	bus		mandatory
ref	310		mandatory	Line number
name	Tram 310		mandatory	Name
network	VRR		when applicable	.
operator	BOGESTRA		when applicable
Relation members of route_master
Role	referenced on	Mode	Use	Remark
	public_transport=route		mandatory	relations for all variations of a line }