Talk:Tag:public transport=stop area

Too much duplicate information?

Many tags proposed here (name, operator, network, ref, uic…) are already used on the platform node as well. This creates a risk of discrepancy if mappers fail to update both objects simultaneously. Wouldn’t it be better to aim for minimalism in the number of tags used for stop area relations? Bxl-forever (talk) 22:52, 15 May 2019 (UTC)

It should be explicitly written that name, ref, etc. tags should be either on the relation or on the platform node (I am for it being on the relation). What do others think? rayleigh1 19:27, 31 August 2019 (UTC)

I'm not aware of many tools or database users that currently handle stop_area relations, so I would keep the information on the highway=bus_stop and railway=platform nodes. --Jeisenbe (talk) 12:10, 1 September 2019 (UTC)

OSMand does (since 2016). And with more than 200k stop area relations and ~2000k platform primitives currently in the database, they make up for way more than 10% of all platforms. So data consumers definitely have to think about it and just because some do not, we should not duplicate the data in the database for them.

Use of this information?

Are there any routing applications or other database users that interpret these relations? It seems like to would be more difficult to use these relations than to just find nearby features, for example, it's trivial to find a highway=platform around a highway=bus_stop node, or a railway=platform within a railway=station area, and it's not difficult to find a platform near a bus_stop or station node either. --Jeisenbe (talk) 07:05, 1 August 2019 (UTC)

OsmAnd~ uses stop area relations to show the names on the map itself and on their PT-navigation feature, but using the name of the bus stop nodes would be an interesting alternative.

Stop area relations are particularly useful in dense urban cores, as found in many European cities, especially when we have several platforms and stop position nodes close to each other: grouping them, e.g. based on the distance between nodes, would be error-prone, especially for bus stations or central islands with vehicles stopping on both sides. Bxl-forever (talk) 10:24, 1 August 2019 (UTC)

Ok, I understand the original purpose was to combine a public_transport=stop_position node with a rail platform or bus stop. However, it seems there is nearly a consensus that the =stop_position tags are not needed for routing or rendering. So if they are dropped, it looks like stop_area is usually not needed. If you have a train station or bus station with mapped platforms, the bus stop node or rail station feature can be the main feature used for routing (it's already usually what's rendered), and rail platforms could also be used for routing in the places where trains from one line always stop at the same platform. But in that case, the train station can be mapped as an area which includes the platforms, if needed.

It seems the one case where it might be ambiguous would be an underground interchange/transfer station where it's difficult to map individual platforms, but where the entrances to the station are mapped. There the relation might combine the entrance nodes with the station feature when they are all mapped as nodes.

But that's all theoretical. I would like to know if anyone has actually used that data to help people walk to the right entrance or right platform, and still needs it. Since adding these relations will increase complexity and the time needed for mappers to map and maintain the data, and the relation itself is an imaginary feature, not a real-world objefct, we should only ask mappers to add it if it's truly needed for a useful purpose. I'm asking because of the proposal Refined_Public_Transport which looks like a good idea, except that it still recommends adding too many stop_area features, as several people have commented. --Jeisenbe (talk) 12:02, 1 August 2019 (UTC)

It seems the relations do not even work for the original purpose (matching 1 stop to 1 platform), as the wiki itself mentions putting multiple platforms and stop_positions into the same relation (or the whole interchange). I have also seen it being used only in large bus stations where all the platforms were put into the same relation, not even the members ordered to have the stop_position and its platform being together. So I really wonder what they are for. Also the wiki mensions 'name:*' for each operator, but then there is only one 'operator' tag for the whole stop_area. Aceman444 (talk) 10:27, 16 February 2021 (UTC)

There is only one operator tag but you can combine multiple values with the semicolon separator, as the wiki explains: https://wiki.openstreetmap.org/wiki/Key:operator#Public_transport Bxl-forever (talk) 22:43, 16 December 2022 (UTC)

entrance role

I think adding station entrances railway=subway_entrance to the station relation with the role `entrance` would be good. Any thoughts? Aharvey (talk) 03:05, 13 October 2019 (UTC)

I like that idea. Nielkrokodil (talk) 11:06, 25 May 2024 (UTC)

Several stations in a stop_area

As we read above, the use of stop_area relation is called into question. I claim the relation IS used in real PT-routing apps, but its usage is hindered by its vague, controversial or too broad definitions/interpretations.

stop_area is really useful in determining a connection between subway_entrances and stop_positions with a railway=station object at transport hubs with several stations. Please, look at the picture with interchange of two subway lines (at different levels). Imagine all the presented features except rails are combined into one large stop_area, including two station nodes. There are also route=subway relations for U1 and U3 lines composed of stop_positions, platforms and rail segments. Such stop_area (which resembles a collection of features rather than a way to structurize them) doesn't allow to answer the important question: when you are on U3 line at stop_position 'sp3', at which station are you? A station object (not stop_position) is the main source of the name and name translations, wikidata, wikipedia etc. Also, not every subway_entrance necessarily leads directly to each of two stations at an interchange. There is no information about entrance-to-station relationship when you have such a collection of features.

My appeal is to introduce one requirement for stop_areas at interchanges of several routes of the same transport mode for railway transport: include no more than one station into stop_area. Otherwise there would be no simple and upright method to deduce stop_position-to-station and entrance-to-station relationship. Desirable mapping is shown on the picture: there are 2 stop_area relations, each including one station, only related stop_positions and platforms and only those entrances that lead directly to the station.

Some text removed. Please do not add your considerations on someone else's behalf.

All 200+ subway (and some other rapid transit) systems in the world were mapped this way and have been maintained for several years, and this allowed to prepare data for routing on subways from OSM for Maps.me/Organic maps apps. Now is the next time a stop_area in Vienna has been remapped to a collection, and routing became impossible. --Alexey.zakharenkov (talk) 12:18, 22 January 2022 (UTC)

Have you looked at public_transport=stop_area_group? --- Kovposch (talk) 12:30, 25 January 2022 (UTC)

Yes, I know. At the aforementioned station there were separate stop_areas and a stop_area_group no so long ago, but that has been rearranged into one huge stop_area. And such cases happen from time to time. Currently wiki encourages huge stop_areas and discourages stop_area_group relation at all. So I ask for correction of a stop_area definition that would allow only one railway station in a stop_area relation to avoid stop_position-to-station, entrance-to-station and maybe some other types of ambiguity. --Alexey.zakharenkov (talk) 13:28, 25 January 2022 (UTC)

This is suggested in Proposed_features/Refined_Public_Transport#Stop_Areas_and_Groups, although i don't fully agree with other parts. --- Kovposch (talk) 15:41, 25 January 2022 (UTC)

But this is in fact the one part of the Refined Public Transport proposal that I strongly object to, see Talk:Proposed_features/Refined_Public_Transport#Stop_areas. Unfortunately, my objections have received little feedback, and most importantly, the proposal was not modified. If this goes to vote as is, I will have to urge everyone to oppose that proposal, which is unfortunate because the proposal is otherwise sound. --Kevin Kofler (talk) 17:14, 1 February 2022 (UTC)

I do not see where you see 2 stations here: There is exactly one subway station, it is called "Stephansplatz", and 2 lines in 2 directions each stop at that station. There are no stations called "Stephansplatz (U1)" or "Stephansplatz (U3)", any such tagging (as was actually introduced 2 days ago due to the broken validator complaining about the previous, perfectly valid tagging) is artificial and an abuse of the name= tag. And the subway station is actually just a part of the larger public transport interchange, all called "Stephansplatz", which also includes city bus (1A, 2A, 3A) stops. IMHO, these all belong into the same stop_area. stop_area_group only makes sense when an interchange contains stops with different names. Then it makes sense to use one stop_area per name. But not per line or, worse, per direction, because then you need a stop_area_group for what I would consider just a stop_area, and then you end up needing something like a "stop_area_group_group" for the larger interchanges. See Talk:Proposed_features/Refined_Public_Transport#Stop_areas for details, I do not wish to repeat myself. You state that "A station object (not stop_position) is the main source of the name and name translations, wikidata, wikipedia etc.", but that is exactly the point, the name is "Stephansplatz" for both subway lines, so we should not require the name to be translated more than once. The issue here is/was not the consolidated stop_area, but that there were two station objects instead of one. --Kevin Kofler (talk) 17:37, 1 February 2022 (UTC)

There are two railway=station objects: n3500528328 and n4560869722, they were created over 5 years ago, and I took that for granted. If they are in the same big stop_area it's impossible to bind a stop_position to a specific station that prevents routing over the railway network. That's my main point to separate stop_areas around each railway=station.

Even if we would have only one railway=station object, strong reasons to have two distinct stop_areas remain. Some problems like "the nearest entrance" routing problem cannot be solved without separation (unless all stations are perfectly indoor-mapped).

Interchange station may include homonymous or not homonymous "stations" (in the sense of "boarding spaces"). So, a wagon speaker announces either "Station A; change here to the line L" or "Station A; change here to the station B of the line L". In both cases this is an interchange from passenger point of view. Separating stop_areas and grouping them into stop_area_groups allows routing engines to consider interchanges and therefore to provide instructions for passengers and make other good things. I think structural/spatial aspect should prevail over naming peculiarities. Alexey.zakharenkov (talk) 12:07, 2 February 2022 (UTC)

For the station you originally complained about (Wien Stephansplatz), both subway lines actually share the exact same surface entrances. So why would you need separate stop_areas to find the best entrance there? If you want the entrance that is closest to the platform, then use the platform object as the reference for the distance, not the stop_area. (You can find the platform object in the same route relation where you also find the stop_position.) I can see your point in cases such as Volkstheater (the U2 part is currently closed, but when it will be operating again), where there are actually entrances more suitable for one line or the other, though even there, you can actually reach both lines from all entrances without going back to the surface. The optimal route is best found by doing pedestrian routing on the indoor mapping. Note that there are also stops like Rathaus (also currently closed) where you actually have to use a different entrance depending on the direction of the same line you want to board, going from one side to the other is only (legally and safely) possible through the surface. (You definitely do not want to cross the rails, it is illegal and potentially deadly, also due to power rails carrying high-power electricity close to the ground.) (In that particular station, there will actually be a subterranean connection from one side to the other when the U5 line will be finished and both U2 and U5 will stop at Rathaus.) Do you want a separate stop_area per direction there?

As for "Station A; change here to the station B of the line L", they never actually say that in Vienna, they just say "change to the line L" no matter how the line L station is called. (But subway lines use the same station name anyway, even if it is not really accurate, e.g., there are U2 platforms under construction at the station Neubaugasse that is not actually under Neubaugasse, but at the other end of the current U3 station. The stop will still be called Neubaugasse for both lines.) The different naming is more a thing for tramway and/or bus stops that are connected to the subway station, and often the reason is that the tram stops at both ends on the subway station (e.g., tramway 49 "Volkstheater Ⓤ" vs. "Ring, Volkstheater Ⓤ"). In that case, I think we really need different stop_areas for the different tramway stops (because it makes a difference whether you need to get off the tram at one stop or the other), but I would put the whole Volkstheater Ⓤ area in a group because it is all one interchange. (My suggestion would be to have one stop_area for "Volkstheater Ⓤ" including U2 (currently closed), U3, 49, 48A, N46, N49, one stop_area for "Ring, Volkstheater Ⓤ" including 1, 2, 46, 49, 71, D, U2Z, 48A, N25, N38, N46, N60, N66, one stop_area for "Schmerlingplatz, Volkstheater Ⓤ" of tramway 46, and one stop_area_group containing those 3 stop_areas.) --Kevin Kofler (talk) 03:15, 3 February 2022 (UTC)

PS: Compare this with train stations, which are also railway=station: A station usually serves several destinations and has several platform pairs. Would you use a separate railway=station for every destination? For every platform pair? I would guess neither. So why do that for subways then? "Stephansplatz (U1)" and "Stephansplatz (U3)" should be one station and one stop_area, both named just "Stephansplatz". --Kevin Kofler (talk) 17:45, 1 February 2022 (UTC)

I am not a supporter of undue splitting of stop_areas. But if some boarding areas have their own train_station_entrances, turnstiles or other facilities, then having one big stop_area wouldn't allow to relate the facilities to the platforms. Reaching one such area from another could be named an "interchange/transfer". Note that combining all features of all stop_areas from a stop_area_group is a simple task, the reverse task is unsolvable in general case. Alexey.zakharenkov (talk) 12:07, 2 February 2022 (UTC)

Since you were complaining in particular about the mapping in Vienna, FYI, the Vienna subway does not have any turnstiles. There are marked points beyond which a ticket is required, but going in and out of the ticket-required area, e.g., to go through another line's platform, does not automatically invalidate your ticket, even if it is a one-way ticket. (And normally, you do not even have to leave the ticket-required area for that to begin with. But it does not matter if you do.) But I can see how this can be a concern in cities such as Paris. (And IMHO, the answer there is, it is the same station and the same stop_area if and only if there is a "correspondance" corridor that does not leave the turnstile area. Which is actually the case almost everywhere within the metro system, whereas the interchanges between metro and RER are more of a mess.)

As for the last sentence: the issue you have then is that you do not have such a thing as a "stop_area_group_group", so if you use stop_area_group for what I think should be a stop_area, you have no hierarchy level left to do the higher grouping. So you either end up flattening the group (having one big "Volkstheater Ⓤ" stop_area_group containing a dozen stop_areas with different names, losing the information that "Volkstheater Ⓤ" is not the best stop to get off tramway 49 if you want to switch to tramway 1) or having separate stop_area_groups (e.g., one for "Volkstheater Ⓤ", one for "Ring, Volkstheater Ⓤ", and one for "Schmerlingplatz, Volkstheater Ⓤ", losing the information that they are part of a single interchange and the corresponding line change options, e.g., tram 1 to subway U3). I think that the finegrained stop_areas only make sense if we add an extra hierarchy layer (which will not make things less complicated for sure, but if finegrained stop_areas are needed, the extra layer is needed, too). --Kevin Kofler (talk) 03:15, 3 February 2022 (UTC)