Something ought to be done about public_transport=stop_position and railway=stop.
There are still a number of sources that seem to say that public_transport=stop_position is mandatory. But at least for railways, it’s used as very specific tag (relating to the precise position of vehicles) for which we often don’t have data. Mostly railway stations are tagged as railway=station or railway=halt. public_transport=stop_position (and the corresponding railway=stop) are often not rendered.
Example, wiki/Key:public_transport leads with stop_position. wiki/Tag:public_transport%3Dstop_area describes it as “required” (although merely “Recommended” in the members table).
I propose to change public_transport=stop_position, and railway=stop to “Optional, if known” everywhere I can find them mentioned.
This will have some effect on bus tagging too, but it seems that a lot of places are still using highway=bus_stop or the (bizarre) public_transport=platform to refer to a pole with a sign on it! Normally I think bus passenger would like to know where the shelter or sign is and the often (especially in rural areas) the place where the bus stops is not even consistent, let alone visible.
Prompted by my efforts to fix the damage done in changeset/170695459 (and see also the comments there).
Both wiki pages public_transport=stop_position and the railway key page have issues, because they don’t anticipate the situation (such as in the UK) where there are multiple stop positions per platform per station**, depending on the length of the train that’s stopping. public_transport=stop_position is particularly egregious because it says that the value is “mandatory”.
What tends to get mapped in the UK is a “legal fiction” - there is a pretence that there’s only one place that there is only one place per platform or platform section where trains stop and in practice there are many.
I guess I could try and explain to people pushing public_transport=stop_position that “they’re doing it wrong” but I suspect that there would not be a successful outcome to that conversation. Therefore; let people carry on adding useless data and just ignore it.
The challenge (as you found in the other thread) is that people might actually remove valid OSM data because they don’t understand that what they are adding. My offer still stands, by the way.
** usually marked for the benefit of drivers; sometimes also differently labelled areas for passengers too.
You misunderstand. You can see there’s a bus stop because there’s a post with a sign on it saying “bust stop” (and maybe some info like a timetable). That’s perfectly mappable. public_transport=platform in the bizarre “new” scheme of things, or highway=bus_stop.
What isn’t mappable is stop_position because that’s not well-defined. The bus stops near the pole and sign but not in a particular position.
there is a pretence that there’s only one place that there is only one place per platform or platform section where trains stop and in practice there are many
This is hardly unique to the UK. I agree that letting people keep adding useless data is kind of OK (and probably inevitable; and sadly, we probably won’t even be able to stop people adding fictional stop_position data).
But we should stop saying (eg on the wiki, which is the tag documentation) that these tags are mandatory. That is asking people to add fictional data because the documented data model wrongly demands it.
I agree that there are a lot of problems with both tags, but it’s not clear what or how that could be improved.
railway=stop has the problem that the definition refers to the position where the driver stops. This immediately leads to a problem, that there would need to be multiple of those if the platform is used in both directions or by trains with different length. If a node also has public_transport=stop_position it’s even more confusing because where the driver stops is normally not where someone can expect to enter the train. Let alone that these positions can also be incosistent for the same train route.
A side effect of all this is, that roads or railways are splitted into enormous amounts of segments. A lot of these position are probably tagged because some PTv2 validation tools consider missing stop_positions in a route a problem, especially for the first and last stop.
The only real benefit of tagging the stop_position on the road/railway for users/data consumers is when dealing with large stations or bus hubs. Then the position may give some hint, on which side/part of the platform the vehicle may stop. And it’s sometimes usefull in cases where a bus stop node has been accidentally moved/deleted.
The most diplomatic approach would be the considers these nodes as “abstract hint where approximatly a vehicle might stop”, but I agree that having them as requirement isn’t really helpfull in many cases.
highway=bus_stop + public_transport=platform is the de facto standard for regular bus stops in many countries/regions and there’s nothing wrong with that. It just represents an abstract place (around the bus stop sign) where people can wait for a public transport bus. Both tags are indeed necessary because there are bus stops (and not to few) where only tourist busses stop.
In the case of a train, most new mappers grasp the concept of the platform as being somewhere you wait for a train. As a node, the platform does not get placed on the tracks as you do not wait there. The train, however, stays on its tracks and needs the stop position as a node on the tracks.
Similarly for buses, the bus stops on the road and therefore the stop position is placed on that way. The passengers wait at the “platform” (just like trains) before boarding the bus. This node is not placed on the road, but is often placed on pedestrian infrastructure, such as a footpath/sidewalk. (Similarly, such navigation aids are useful for train stations)
(oh, and by the way, the ferries have platforms too!)
To some degree, the mapping of bus stop positions is comparable with how stop signs are mapped on roads. (If a stop line exists, then you map the stop sign there. In other cases, you simply mark it on the road next to the sign.) Tag:public_transport=stop_position - OpenStreetMap Wiki says that stop position nodes next to bus stop signs add no information and “can be abandoned”, but it looks like they’re mapped anyway. Would it make sense to specify that information about the source of the stop position (stop_sign/stop_line/survey/estimated) needs to be given?
I think we need to fix this. The “where the vehicle stops” information is often not available (or even well-defined). There is nothing wrong with a PT station/stop marked without stop_position.
Right, but if there isn’t in fact a physical platform, what is public_transport=platform adding there? Bus stops with physical platforms do exist (as in your bus station example) but they’re not the usual case. More usually there’s just a pavement (US “sidewalk”), and maybe a layby or some “keep clear” road markings. And of course maybe a shelter of some kind.
The added value is making explicit that it’s a bus stop for public transport buses and not for touristic busses, prebooked tours, hop-on hop or similar. This makes it clear to users and data consumers that at stops missing this tag no “regular” bus is expected to stop and helps mappers when building/maintaining routes, especially at larger hubs where this can’t be easily determined from aerials. Sometimes alternatively a tag like tourism=yes is also used.
So in most cases it’s basically the same as public_transport=pole (but that was not included in the original pt scheme)
Another problem (I think?) is with rendering on different stlyes. Not exactly sure, but I think there are other “correct” tagging combinations where the bus stop still isn’t rendered at all.
As explained I agree, that this (especially in simple cases) is often redundant or roughly estimated. Sometimes though it can be derived from good aerials, when a stop line is visible etc.
I also agree that this is sometimes annoying and a burden to maintain, but the thing is OSM is quite often a bit redundant or estimated. And this specific tag doesn’t break anything other than that it’s use differs significantly from the original definition.
For bus and tram, I map the platform=stop_position where the first door of the vehicle opens and that is usually (and where available) where some tactile paving lead the visually handicapped people to the kerb.
That might be the case if this distinction was widely known and understood, but I’m not convinced that is the case. The original PTv2 proposal doesn’t seem to refer to this distinction and I don’t see anything in the wiki for either tag that would prompt mappers to think of that.
My understanding was that the motivation for the “platform” tag was to consistently tag the place passengers wait across various types of transport. I believe some regions had a practice at the time of placing highway=bus_stop on the road and “platform” was meant to remove that ambiguity.
That makes some kind of sense. At least it’s just another tag on the node. ISTM that tourism=yes is a “troll tag” which we oughtn’t to recommend. @alan_gr, how do you think a tourism bus stop should be mapped and distinguished from a normal service bus stop?
I think that is correct, if you have the information. (Eg, you’re mapping IRL and can see the relevant paving or watever.) I’m not sure how valuable that information is though. It might make sense if the same public_transport=platform has many different services with different stop_position but I would be tempted to map multiple platform for that.
The question I started trying to address here is this: is it legit to have a bus stop or railway station which has no associated stop_position? And I think the answer is “yes”. So tools which say that this is somehow wrong need to be fixed, especially if they are leading people to (for example) change the main railway=halt node into a stop_position.
There is also the troublesome Tag:route=train - OpenStreetMap Wiki which seems to suggest the use of railway=stop and public_transport=stop_position as the primary components of a train route relation. That can’t be right because we often don’t know where in the station the train stops. The route relation should contain the station.
Yes. This tag has been introduced as ‘mandatory’ with PTv2, for whatever reason. So, the tag is mandatory only if that stop-position is member of a PTv2 route relation which is ‘recommended if available’.
A node must exist at least at the start and end of a route relation. That’s where we split ways in order to differentiate between ways where passengers may sit in that bus and those ways where not. Those nodes are usually tagged with stop_position to make that clear.
Yeah and GTFS data for trains shows this clearly: some GTFS routes (equivalent to OSM route_master) have > 200 GTFS trips (eq. OSM routes) which often differ only in platform position and platform GTFS stop_id, …
Hmm, don’t know whether to agree here or not. What would be the benefit, the impact?
N.B. This would break the similarity of GTFS’ stop object with OSM’s platform object.
GTFS’ ‘parent_station’ (location_type=1) of a ‘stop’ (location_type=0) is called “Station”, which we would map as stop_area.
BTW: GTFS doesn’t know an object type similar to OSM’s stop_position.
I don’t really know GTFS. Maybe I’m wrong and the route relation shouldn’t contain the station, but I think the primary element in the route relation for a station mustn’t be stop_position since we often won’t have one of those. If not the railway=station, then the public_transport=platform.
Many small stations don’t have a stop_area and some don’t even have the platforms mapped. Such a thing can be useful and it would be good to be able to link it to the route without having to add elements (perhaps inventing platform postions etc.)
Maybe platform should be just “recommended” there? ISTM that if one is mapping a route, one might well add missing stops/stations. But we don’t want people adding “missing” stop_position. So the two things have a somewhat different relationship to the relation (sorry).
I’m not sure, arguably it shouldn’t have either of these tags. The description of highway=bus_stop in the wiki specifically says it is for “public buses”.
I think it’s a side issue to your main point anyway, I really just mentioned it as a warning against retrospectively attributing a logic to tags that doesn’t reflect how they emerged and is probably not reflected in current data.
If possible and known (which is usually not that hard to determine I would assume) it’s much better to include the platform in the route relation. Most stations typcially have 2 or more, e.g. one per direction. With PTv2 this provides a lot more information compared to just including the station itself (which is often just a simple node somewhere around the station area), because things like tactile_paving, wheelchair, height etc can be different on different platforms.
