In Bogota, Colombia, we are defining a guide to map public transport, initially for buses. We want to define the tagging schema with its possible values and define a JOSM preset. However, looking at the wiki documentation, we found that some pages are incomplete, with differences for highway=bus_stop with public_transport=platform.
So, I decided to list the tags mentioned in each article to see the most common documentation. This is the list:
I identified these elements, and I put the corresponding value for Bogota:
Pole, bus sign (on one node of the waiting area)
highway=bus_stop
name=*
Wating area (way or area)
public_transport=platform
shelter=*
bench=*
bin=*
tactile_paving=*
name, ref, operator, and network will not be included because they will be in the stop_area relation.
Shelter in the waiting area. In Bogota, the waiting areas are bigger than the shelter.
amenity=shelter
Bus stop on the highway
public_transport=stop_position
name, ref, operator, and network will not be included because they will be in the stop_area relation.
Relation to group the previous elements.
type=public_transport
public_transport=stop_area
name=*
ref=XXX#YY
network=SITP
operator=One of the 20 operators.
public_transport:version=2
Member:
stop: public_transport=stop_position
platform: public_transport=platform
EMPTY: amenity=shelter
The pole (bus_stop) is not included in the relation. It seems it is used for legacy software.
What do you think about the
As part of the differences in the article, I found:
highway=platform is only mentioned in some articles. The most confusing one is Public Transport on the table.
The highway=bus_stop article lists the same tags as public_transport=platform, so I consider this article does not differentiate between “bus stop sign” and “waiting area.”
Few articles include the concept of relation to not duplicate values like name, ref, operator, and network. Therefore, they propose to include them, which leads to duplicate values in the database.
The area=yes tag is mentioned in some articles, saying it is required; in others, it says it is unnecessary.
What do you think about these differences in the articles?
X means it is mentioned but does not specify if it is mandatory or optional.
Empty: it means it is not mentioned in that article.
NO: it states that it is not necessary to be used.
E: This is the definition: " The highway=platform tag is used for platforms (raised structures) along the side of a road where passengers get on and off buses and/or trams." Therefore it is not very clear.
S: If the “stop” (platform or stop_position) is going to be included in a “stop_area,” then this is not necessary. Otherwise (no stop_area relation), the element should include that tag.
As you probably noticed, I am not an English speaker, and these differences in the articles create a lot of confusion. Spanish translations are not in sync with English, and the problem is even worse in understanding how to map public transportation system stops.
Everything looks fine except for this: the pole is the thing that I, and I presume others, use for pedestrian routing above anything else, so it’s more than just a legacy tag. I guess you can include either pole or platform in the relation: there are many bus stops in UK where the pole is the sole feature. I think iD adds both tags to the pole node.
There are many variations in the way public transport is mapped all over the world. In many areas, especially when mapping resources are scarce, mapping stops as single nodes is often considered enough. In larger cities, you will sometimes see huge collections of nodes (stop posts), ways/areas (platforms), stop position nodes, stop_area relations and PTv2-compliant route relations. There have been several proposals to establish common standards for PT mapping but reaching a consensus is really difficult.
Your tagging scheme looks good, despite it might make sense to include the highway=bus_stop node in the stop_area relation.
Also, public_transport:version=2 is to be used on route relations, not on stop_area relations.
(One more thing: if there are many new mappers in your area, especially if they use iD or StreetComplete, you should be prepared to review your bus stops regularly, because users will be encouraged to “fix” tags (iD automatically adds public_transport=platform to nodes having highway=bus_stop… and once this tag is set, StreetComplete will bug users into filling bench=*, bin=*, lit=*, shelter=* and tactile_paving=* on those nodes; you might end up with different values on the nodes and the platforms.)
The public_transport=stop_position is hardly used by software at all, and should be optional at most. It has at least two substantial problems:
On a single carriageway (i.e. a non-oneway) one does not know the direction of the stop
In many places, the stop position is not visible on the ground or not defined at all. Mapper then guess, and the software cannot know whether it is a real thing or a guess.
From developing various tools for public transit, the following needs often appear:
make a list of served stops (usually by their names) where two consecutive stops of the same name sometimes exist
draw the way the bus takes through the street
route pedestrians from and to the bus stops
Whatever you finally make as a tagging scheme, it should be straightforward to do these things from data.
In many places it has proven useful to have highway=bus_stop and name on the poles beside the road and these poles and the used itinerary of the bus line in the relation, one per each direction.
In particular stop_area relations are painful to edit, painful to evaluate, and add little value. There is evidence that rather few people correctly distinguish between stop_area and stop_area_group, rendering the whole thing dubious. Repeating the name is much simpler for anyone.
What do you think about these differences in the articles?
The people who have written the wiki pages were not the people who did the mapping or wrote the software in the past, some years ago. Attempts to let the wiki reflect actual usage have found quite loud opposition from the wiki fiddlers, so we arrived at the current state where each page remained at a different and somewhat random content, depending on who had latest their territory there.
The information of the direction is existing in the relation, the node is part of.
In case on a simple bus stop the location the location will be matching with the post, just be part of the highway. In such a case there might be not so much gain for PT-users, but maybe for others it might be helpful. Waiting buses may slow down the traffic, you need to be more careful in that area…
I don’t see a reason to require markings on the ground. You can see, where the busses(trains) are stopping.
