Proposal talk:PTv2 Improvements wrt Rapid Transit

Can this be expanded to things other than subways?

Subways aren't the only form of mass urban rail transportation where routing would be useful. Your proposal is currently subay-specific. Could this be extended to also apply to any kind of rail, like funiculars, monorails or underground tram stops? -- Stereo (talk) 14:14, 16 December 2017 (UTC)

Yes, it could. I've added funiculars to the list in "Applies To", and mentioned underground trams. Thanks. --Zverik (talk) 15:12, 16 December 2017 (UTC)

Thank you. Then I'd just like to request the minor change that the role 'entrance' and its family can be applied to any node, not just subway_entrance and elevator. --Stereo (talk) 00:21, 18 December 2017 (UTC)

You can apply this role to anything, but only a subway_entrance object can be used for entering and exiting subway. --Zverik (talk) 20:59, 18 December 2017 (UTC)

Interval

I believe the inverval section would merit a little more attention. Usually the intervals depend on the time of the day, so we would need some time dependent tagging, maybe realizable with a format similar to the opening hours syntax. --Dieterdreist (talk) 12:23, 18 December 2017 (UTC)

+1, two possibilities (at least):

- keep it simple and rename to peak_hour_interval. If the purpose is to choose between lines, it's probably sufficient (the lines with highest frequencies will remain the same). At least clarify that it's the highest frequency to map

- create a tag with the opening_hours syntax with the interval as comment on each time Mo-Su 05:00-06:00 "10 min", Mo-Su 06:00-08:30 "5 min"

--Nospam2005 (talk) 19:25, 18 December 2017 (UTC)

My intention is not to discuss the interval proposal in this one. I peeked at that proposal and added a line about time-dependent tagging. We can improve it later; for most purposes the single "interval" key is enough, and already used in a few cities (not by me). I'd also prefer not to complicate the interval values much. --Zverik (talk) 21:04, 18 December 2017 (UTC)

And your experience shows you should remove this part from this proposal: keep it simple. As seen here, "interval" with a simple numeric value is not sufficient: wrong key or wrong value. Not in line with the proposal ;-).

--Nospam2005 (talk) 21:21, 18 December 2017 (UTC)

I am just including what is already in use. See https://taginfo.openstreetmap.org/keys/interval#values If you want to change that, discuss it on Talk:Proposed features/Interval. --Zverik (talk) 21:25, 18 December 2017 (UTC)

Optional route members

While platforms remain optional for some route relations, the proposal suggests it becomes now "mandatory" to add platforms to route relations if there are different platforms for different directions. What does the term "mandatory" mean here? Is there a difference between "mandatory" and "recommended" in the context of OSM? IMHO we should recommend to add these details (and more), but we cannot enforce anything. --Dieterdreist (talk) 12:34, 18 December 2017 (UTC)

Of course we cannot. "Mandatory" on any wiki page means "highly recommended". Like, having ways required in a route relation — nobody can enforce this, but wiki still says that in red letters. With this proposal I'd like to switch mandatory and recommended members in rapid transit route relations: stops and some platforms should be mandatory, since routing is impossible without these, and ways become optional, since they can be interpolated or just plain skipped. --Zverik (talk) 21:11, 18 December 2017 (UTC)

Yes, for detailed routing it is important to have platforms, but only if there are more than one. For simple stations (the typical Berlin light-rail (S-Bahn) and subway (U-Bahn) station has a single platform which allows to take trains in both directions) they're not really needed (it was you telling me that underground stations can't be surveyed to map a station outline, platforms are basically the same in these situations (you can estimate them, but it doesn't typically lead to the same precison as overground stuff you traced from aerial imagery). --Dieterdreist (talk) 17:25, 22 December 2017 (UTC)

Well, I write that platforms in route relations are mandatory if they are mapped, and if there are more than one. Otherwise they are not. It seems we're talking about the same thing from different angles :) --Zverik (talk) 18:08, 22 December 2017 (UTC)

Stop area groups

Paris simple subway stations typically have two platforms, one on each side of the tracks running in opposite directions. I would expect to map those stations as a single stop_area relation even though it would take more than 1 minute to walk from one platform to the other (note one would not typically do so however, unless willing to travel back). Can you please clarify whether your proposal requires to map them as a group of 2 stop_area relations (seems overkill) ? --Carto'Cité (talk) 17:29, 18 December 2017 (UTC)

That would be a single stop_area, of course. I explained a criteria for choosing a way to map several platforms here: Proposed features/Metro Mapping#Interchange (type 2 means a stop_area_group relation).

I dislike the idea of triggering the need for a stop_area_group based on the time it takes to walk from one platform to the other : people with a pushchair or on a wheelchair may need to take a different and longer route from others. It is also inconsistent with overground public transport, where a single stop_area relation typically holds several platforms from several bus lines. Shouldn't a stop_area_group only be required for complex connections, i.e. connections that imply changing transportation mode (bus, railway, boat, tram), or changing level (underground/overground), or changing network (hence possibly ticket scheme) ? --Carto'Cité (talk) 16:48, 18 December 2017 (UTC)

Walking time is just an example. That's what "e.g." means. The proposal deals only with rapid transit, since for overground transport stops, as you mention, stop_areas are a matter for a long discussion. Stop_area_group basically means, there is an interchange on a route map, or you change... well, all the things you've listed. --Zverik (talk) 21:23, 18 December 2017 (UTC)

Subway entrances and exits

When an entrance leads to several stop_areas (through corridors and stairs and elevators), should it be a member of the stop_area_group relation ? Could it be a member of several stop_area relations or should it be referenced only once within a stop_area_group ? Or does it not matter wrt. your proposal ? The reality might lead to one case or the other... (Note : does the sentence "No subway entrance should be outside a stop area." mean "All subway entrances and exits should be members of a stop_area relation" ?) --Carto'Cité (talk) 17:01, 18 December 2017 (UTC)

You just add entrances to all stop_area relations that they lead to. Adding entrances (and other non-stop_area objects) to stop_area_groups will lead to confusion: a stop_area_group can be extended in time to include bus stops and other stop_areas. And what about an entrance leading to 2 of 3 stop_areas in a group? I'll rephrase the subway entrance sentence. --Zverik (talk) 21:14, 18 December 2017 (UTC)