Changeset: 86251646
New York City subway: combine stop_areas at a station into groups; use stop_positions/platforms instead of stations in routes to unambiguously identify stop_area
Closed by azakh-world
Tags
created_by | JOSM/1.5 (16538 ru) |
---|
Discussion
-
Comment from clay_c
Hi there. I noticed you added stop_area_group relations to encapsulate the subway stations I've split into separate directions due to lack of in-station transfer between the two platforms. These are stations where one must exit, cross the street, and pass through a different entrance (paying additional fare) to change to the opposite direction. So I deliberately left them without stop_area_group relations.
Should these be grouped together if there is no free transfer between them? I sometimes come across relations like this one [1] where someone has explicitly marked that stations without free transfers are not to be grouped. The wiki doesn't have straightforward guidelines on what a stop_area_group relation is intended for, so I guess this is subjective.
Perhaps a relation grouping by itself isn't enough to denote a free transfer and might necessitate a tag on the stop_area_group. I just want to make sure we're mapping things consistently going forward.
-
Comment from azakh-world
Hi.
None of the rapid transit network in the list on http://osm-subway.maps.me treated opposite platforms within one station as belonging to different stop_areas. You were the first and we accept it to be a proper way. It took a lot of effort to keep routing in our application by means of the (possibly temporal) solution with stop_area_groups.
I think no tag for paid/free transfers could save the situation. Imagine there is a transport hub with subway1, subway2, bus and commuter train stop_areas, where subway1-subway2 transfer is free, subway-train transfer is on discount, and bus is paid separately. An adjacency matrix of transfers, or multi-level stop_area_groups built on the cost basis, would be required, which is far from the current OSM mapping reality. What matters is general routing needs. The forementioned user's argument - to not create a transfer if one have to leave the transport area and pay to enter it again - makes sense, provided there is some way to do routing through such stations, particularly direction switching. Again, imagine that a subway station with two separated stop_areas has transfer to a train station, then both subway stop_areas would be added to a large stop_area_group, and "need-for-pay" property of subway-subway transfer would be completely lost. So, for now I appeal to consider creating a stop_area_group for closely located stop_areas a more general approach that helps routing or even makes it possible. -
Comment from azakh-world
I think relation 9813444 should not be a stop_area_group due to stop_areas spatial separation along with "need-for-pay" consideration.
BTW, it seems subway_entrances are distributes not correctly between the stop_areas. -
Comment from clay_c
Thanks for pointing out the subway_entrance discrepancy—it should be fixed now.
Stations lacking free transfer between directions are typically not found at transfer hubs. Bleecker Street (6) used to be an exception, where the southbound platform connected to Broadway–Lafayette Street (B,D,F,M) but the northbound platform was isolated from the rest of the station complex until recent renovations established a connection. Nearly all other split stations are somewhere in between train/subway transfers, so the most probable transfers happening at these places would be to and from buses on the surface.
Which brings me to pedestrian routing, the original reason I split these stations into separate stop_area relations. If you're riding the NYC Subway for the first time (like I was a few years ago), you might enter the station you're looking for and find out that you need to exit and re-enter, paying additional fare. It's improbable, probably nonexistent, that a routing algorithm would actually direct someone to make this sort of opposite-direction transfer. So I think it's sensible to add stop_area_group relations, though personally I'd only add them if there's nearby stop_area relations for buses.
-
Comment from azakh-world
"... that a routing algorithm would actually direct someone to make this sort of opposite-direction transfer."
Nevertheless it's a nonfictional case. At some subway station the eastbound platform and entrances were closed for 2 years for reconstruction, allowing (un)boarding only from the westbound platform. When you travelled east to this station, you must have go one stop further, change direction and go one stop back. Our routing algorithm copes with such cases as long as the turn station has one stop_area or two stop_areas combined into a stop_area_group.
Ways (7)
- IND Queens Boulevard Line (46340231), v17
- IND Queens Boulevard Line (46340278), v10
- BMT Canarsie Line (552734861), v7
- BMT Broadway Line (797157461), v5
- BMT Fourth Avenue Line (803113093), v2
- IRT Lexington Avenue Line (804373929), v3
- BMT Broadway Line (804373930), v3
- 49th Street (N,R,W) (11174974), v1
- 46th Street (M,R) (11174975), v1
- 40th Street-Lowery Street (7) (11174976), v1
- 3rd Avenue (eastbound L) (11174977), v1
- 36th Street (M,R) (11174978), v1
- 33rd Street (6) (11174979), v1
- 28th Street (R,W) (11174980), v1
- 28th Street (6) (11174981), v1
- 28th Street (1) (11174982), v1
- 25th Street (R) (11174983), v1
- 23rd Street (N,R,W) (11174984), v1
- 23rd Street (6) (11174985), v1
- NYCS - 1 Train: South Ferry→Van Cortlandt Park-242nd Street (364630), v69
- NYCS - L Train: 14th Street–8th Avenue → Canarsie–Rockaway Parkway (366763), v54
- NYCS - M Train (Counterclockwise) (366767), v81
- NYCS - F Train: Coney Island–Stillwell Avenue → Jamaica–179th Street (366772), v100
- 3rd Avenue (eastbound L) (3420619), v4
- 25th Street (downtown R) (7065179), v4
- 23rd Street (downtown N,R,W) (7120456), v7
- 28th Street (downtown R,W) (7125649), v6
Nodes (20)
- 49th Street (downtown N,R,W) (7595933440), v1
- 49th Street (uptown N,R,W) (7595933441), v1
- 46th Street (eastbound M,R) (7595933442), v1
- 46th Street (westbound M,R) (7595933443), v1
- 3rd Avenue (eastbound L) (7595933444), v1
- 3rd Avenue (westbound L) (7595933445), v1
- 36th Street (westbound) (7595933446), v1
- 36th Street (eastbound) (7595933447), v1
- 33rd Street (downtown) (7595933448), v1
- 28th Street (downtown) (7595933449), v1
- 28th Street (uptown) (7595933450), v1
- 28th Street (downtown) (7595933451), v1
- 25th Street (downtown) (7595933452), v1
- 25th Street (uptown) (7595933453), v1
- 23rd Street (downtown) (7595933454), v1
- 23rd Street (uptown) (7595933455), v1
- 23rd Street (downtown 6) (7595933456), v1
- 28th Street (uptown) (7142969921), v2
- 33rd Street (uptown) (7142969930), v2
- 23rd Street (uptown 6) (7142969941), v2
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |