Proposal talk:Public Transport

Longer car train route

With the presumption that this reaches interested parties, I ask opinions on how to model a "nonsimple" train route. The route is about 1 000 km long (overnight), and you can bring along your car. The hard part is, that the car wagons are first loaded separately, then the driver must walk some hundred meters to the regular train station, wait for them to assemble the full train at the yard some distance away, and only then can one board the train on foot (regular sleep-over coaches). At the destination the passengers hop off as they disconnect the car wagons and a second engine takes the car wagons to the unloading bay, where the drivers must again walk for some distance. It might be reasonably easy to enter, if you could only travel with the car, but anybody can do regular long distance journeys as a pedestrian traveller. I tried to check the Channel Tunnel for car transport/routing, but to date it has been ignored save for some of the loading service ways. Alv 16:21, 22 March 2012 (UTC)

Stop positions with different directions

Is there a possibility to tag two stop positions being part of the same stop, but differing in their name by the direction they are located in, differently? e.g. "Berliner Platz Ost" bzw. "Berliner Platz West".--Hno 21:36, 23 March 2012 (UTC)

Stop positions with different names usually do not belong to the same stop. Do you have an example relation? --Teddych 05:51, 24 March 2012 (UTC)

I found out that these stops are really named differently, although they are just nearby the same major road, opposite each other. So there is no problem to solve anymore. --Hno 13:25, 5 April 2012 (BST)

Example. We can use Role 'stop_area' with member 'stop_area'-relation -- dr&mx (talk) 20:48, 14 November 2022 (UTC)

Use proper typography in Route names

The proposal recommends a schema like this for route names

<vehicle type> <reference number>: <initial stop> => <terminal stop>

Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi

But => is not a real symbol. Its an equality sign followed by a greater-than sign which looks a bit like an arrow. We should use a real arrow symbol instead. I recommend → or ⇒. Example:

<vehicle type> <reference number>: <initial stop> → <terminal stop>

Bus 201: Uitikon Waldegg, Bahnhof → Uitikon, Wängi

The ↔ sign is already in use --Shmias 08:58, 9 January 2013 (UTC)

How about stopping the abuse of the name tag alltogether? The proposal already contains 'from' and 'to' keys for the initial and terminal stop. From these, a renderer or other application can automatically build a string with whatever symbol they like. --Tordanik 09:13, 9 January 2013 (UTC)

Oh, right. I'd support this as well --Shmias 09:50, 9 January 2013 (UTC)

So the name tag should not longer be recommended if the line has no specific name. right? --Shmias 14:09, 9 January 2013 (UTC)

Yes, I think so. I'm not sure whether everyone will agree, though. --Tordanik 14:27, 9 January 2013 (UTC)

I agree, too. name=* is only reasonable if the line has a real name, like "Kanonenweglinie". --Michi 18:18, 9 January 2013 (UTC)

+1, --Nzara (talk) 08:36, 27 September 2014 (UTC)

the Berlin Ringbahn would still have names like name="Ring ↺" and name="Ring ↻"--Shmias 16:37, 9 January 2013 (UTC)

Archiving of this page

moved from users talk page

Hello Kaitu. You reverted my last edit on Proposed_features/Public_Transport with the comment "the Public transport documentation page redirects to the proposal". Could you please state which "Public transport documentation page" you meant? There is a own standing documentation page named Public_Transport which is no redirect. It makes no sense to have redundant information. --Andi (talk) 22:18, 14 February 2013 (UTC)

Hello Andi. Sorry, my comment wasn't clear at all. I should have probably said "links" instead of "redirects". Several times the page Public_Transport, refers to Proposed_features/Public_Transport for more details:

- in section "Railways": "A more detailed description about stations and halts is described in the approved feature Public Transport"

- in section "Service routes": "Other tags may apply for different types of service, see approved feature Public Transport for more details"

- in section "Tagging": "The approved feature Public Transport defines all the tags related to the public transport".

Until those details are incorporated directly in Public_Transport, the page Proposed_features/Public_Transport contains information that is not redundant. I agree that the current situation is confusing, because only part of the information in duplicated, and an approved proposal page is not the right place to search for information, but as long as it contains details which cannot be found elsewhere, I deem it shouldn't be archived. --Kaitu (talk) 23:47, 14 February 2013 (UTC)

Acoustic information for blind people

Our new bus station is equipped with a switch to activate acoustic information on each platform. I set a node with public_transport=pole (although it isn't a pole in a strict sense, it's rather some kind of wall with time-tables) and combined it with speech_output:de=yes

Clarification of wrong statement

I know that this has been aprooved and should not be altered, but there is clearly wrong clarification. The sentence

Please note that more than one station can be member of one and the same stop area. Conversely, it can happen that one station belongs to more than one stop area - if the station contains stop areas (or parts of these) with different attributes, such as different networks.

is very confusing. The case that a station is member on more stop areas is possible but very unusual case. If I understand it correctly, than most of the time station is collection of stop areas and some other things. Or not? --Jakubt (talk) 13:06, 12 March 2015 (UTC)

Transfer information

The new schema for route relations does not allow us to capture transfer information, since only the actual stop positions are tagged as stop in the relation and the common station node are not tagged as part of the relation. For determining transfers, it will be very useful to know what routes serves a particular common station node.

My proposed change to the new schema is to tag stop positions in relations as stop_position, and station nodes as stop (as per the old schema). This facilitates compatibility with the old schema by only requiring the new stop_position to be added, and can be enhanced to be the new schema relation by adding stop_positions to the relation. Most importantly, the common station node can be used to determine what lines serves a station. --JaLooNz (talk) 16:48, 4 August 2015 (UTC)

Stop_position not appearing in map

I recently updated some stops to the new schema, but the icon of the stop dissapears from the map. Am I doing it wrong?

This is the area where I did the changes: https://www.openstreetmap.org/#map=19/41.62798/-0.88175

Thanks in advance --Robot8A (talk) 23:07, 25 September 2015 (UTC)

route/forward/backward and special scenarios

I've recently started a discussion on whether the roles route, forward and backward are allowed in PTv2. The overwhelming response was that they are forbidden in this version of the scheme. However, soon after I found a special case: a route that consisted of a single way. Without such roles, it is impossible to know the direction of travel, unless from=* and to=* match station names, which they are not required to (see discussion here). It seems like the only way to handle this scenario is to require PTv2 routes to have at least two ways. --Fernando Trebien (talk) 19:07, 9 January 2018 (UTC)

I'm not sure this is the right place to discuss it since the proposal is accepted. the best is to discuss it either on the ml tagging or on the current wiki page (but the 2 places at the same time it is not practical)

keep it simple as possible !

put a from and to name, using name from operator. it several stop exist with the same operator name, use a name that people use for those stops.

you can have valid route with only one way, put 1st stop, 2nd stop and the way. it's done. Marc marc (talk) 22:34, 9 January 2018 (UTC)

Another case where the absence of roles causes ambiguity is this one; when the ways from B to C, from C to D, and from D to B are all bidirectional, you cannot determine without roles if the route is

• (A, B, C, D, E, C, Y, Z) or
• (A, B, C, E, D, C, Y, Z) without forward/backward roles!

 A ------>B----->C------->Y--------> Z
                / ^
               /  |
              /    \
             /      \
            |        \
            v         \
            D--------->E

Another cases where a single route in a single direction from A to Z (via B, C, D, E, F, D, C, B, see below) has to perform a run to a lateral branch and come back from it. This requires referencing the same way(s) twice in the same relation (and this is not an error), with one case in the forward dirction and the other case in the backward direction. You cannot do that with iD (which also does not allow properly setting the correct order of members and sort tham randomly: the direction forward/backward disambiguate this and allows restoring the correct order). In this example below the way from B to C is taken twice ! (you'll need "forward:1" and "backward:2" roles on occurences of way B-C, or "backward:1" and "forward:2"; for other ways the direction is implicit provided you know from which way you'll start the route (but "from=A" and "to=Z" attributes in relations are too much ambiguous, you should prefer to add node members for A and Z with roles "from" and "to" to disambiguate !

 A------>B------->C------->Y------>Z
                 |^
                 ||
                 v|
                 D<--------F
                 |         ^
                 |         |
                 v         |
                 E-------->E

Same (simpler) case for a short branch with a half-turn on D (without a terminal loop of ways, when D is itself a "turning circle" node or a parking with maneuvre area around), the effective route is (A, B, C, D, C, Y, Z). This case is very frequent in long-distance lines via motorways, where the branch is taken both-ways to reach the center of a town/village:

 A------>B------->C------->Y------>Z
                 |^
                 ||
                 v|
                 D

A similar case occurs when the branch is in fact a loop, and the same way(s) is(/are) taken twice in the same direction (backward or forward). And the only way to disambiguate the route (if we cannot assert the correct order of members in the direction, as with iD) is to add another role extension specifying the occurence number where the way is taken. In this example this is the way from B to D (the route is A, B, C, D, E, F, C, D, Y, Z); this case is frequent when the segment C-D is one-way only:

 A----->B------>C-------->D---->Y---->Z
                ^----X--->|
                |         |
                |         v
                F<--------E

The diagrams above are not invented and not theoretical, they effectively exist in various urban bus networks if you study them correctly and want to avoid approximations !

In summary the prohibition of roles in PTv2 route relations, is stupid and was never thought correctly ! There are many cases where you'll still want them to disambiguate them.

And we should have node members with roles "stop:from" and "stop:to" (which are also stop positions, but not necessarily "entry_only" or "exit_only": people may stay in the bus to get backward and reach a branch or loop which is taken only once, for example above, they would enter at Y, would go to Z, then in the reverse direction back to D where the bus does not stop at Y and then go back via D, E, F, C to reach X, the bus would then go again on D, a roundabout, and back to C directly without stoppping at X)

You'll also note that even though the bus passes twice via nodes C, X, and D on the direction shown above, it may stop there only once, or not at all in that direction (only in the reverse direction). The stop positions will also need to be added twice, but with diffferent roles (no_stop, entry_only, exit_only, or both) and for each one an occurence number appended to the role !

Another intesting case is the existence of sections of routes where the bus drives but has no passengers (they must exit_only before that section and can entry_only after that section. This case occurs for liaison links and notably near the terminus where there are two stop positions on both sides of the street, one for each direction, and they are connected by the bus going via a service way or roundabout nearby to perform the u-turn (in some cases, the u-turn will occur in a restricted area, such as an undergound garage or service area with barriers, closed to the public).

So ways in relations may need a role to say "no_passengers", but these ways connects the full line (this case is quite frequent for terminus of bus lines within many cities, where the terminus is in fact a pair of stops but with a service link which is too far away to be useful for serving the area, as there are restrictions against pedestrians in that section or the final roundabout or crossing and u-turn is judged too dangereous for them even and not accepted if they stay in the bus).

                         no_stop->
 A -----------> B ----------> Y --------->+ Z
                              <-----------+
                         exit_only

                         exit_only     no_passengers
 A -----------> B ----------> Y ........... Z
                              <...........:
                         entry_only

Or passengers must get down the bus at one stop, and reach by foot another stop where they'll get in, after passing themselves some checkpoints such as identity control; the bus will wait them there (this case occurs on some buses that perform international relations to pass the border customs, or police checks, or must buy another ticket or pay some additional transit fees not included in their travel ticket, and this cannot be done within the bus itself but in a dedicated transit area). Here also you need "no_passenger" role on this segment of the bus route.

                    no_passengers             
 A -----------> B .......>.........> Y--------------> Z
            exit_only            entry_only
               |                    ^
               v>>>>>>>>>>>>>>>>>>>>|
              (by foot or other means)

— Verdy_p ^(talk) 20:34, 9 January 2018 (UTC)

I've just found in the text of the proposal that applications are supposed to determine the direction of the route by the order of the stops in the relation, which solves the ambiguity in my example. Way members must be ordered too, which solves the ambiguities in some of your examples. A simple algorithm to do that is to take the first two stops, start with the first way, travel through it in one direction and through subsequent way members of the relation until both stops are visited in order; if unsuccessful, try travelling in the opposite direction. Traveling is somewhat easy since the current way shares a node with the next. It may require some slightly cleverer algorithm to handle cases such as A-B-A-B-C (that is, the first way traveled multiple times). I'm not sure if JOSM is already validating all that, but I agree that iD should support editing relations in this way. --Fernando Trebien (talk) 22:09, 9 January 2018 (UTC)

The case in which the bus does not stop on the first pass by Y though can only be solved if stops are interspersed with ways on the relation. This also means that ways would need to be split at stops. Both are probably undesirable. --Fernando Trebien (talk) 22:16, 9 January 2018 (UTC)

You need to go back and read the instructions again. You put the stop/platforms in order at the top of the member list, then you put the ways in order at the end. Adavidson (talk) 10:20, 10 January 2018 (UTC)

As for the no_passengers case, I think this could be mapped as separate routes, one before and one after the checkpoint, even though in reality they might be the same route. The journey planner would then instruct passengers to leave the bus, walk, then take another (the same) bus. Pedestrian access would have to be either yes or permissible, which may not be desirable at certain checkpoints. --Fernando Trebien (talk) 22:16, 9 January 2018 (UTC)

Passengers that get down cannot take another bus, their luggages remain in it and will be controled separately. They must take the bus again !

In that case, then indeed the current proposal is inadequate. The best that can be done now is to pretend that the bus goes through the checkpoint footways. (it is silly but it works) --Fernando Trebien (talk) 22:56, 9 January 2018 (UTC)

Silly, it won't work, when the passengers ways are not usable by buses (this could be on footway only or through rooms inside buildings, or pasengers may need to take another local mandatory navette bus, while their bus may take place in a vehicle-only ferry or train, not suitable for passengers). Passengers may also have to get down the bus because of weight restrictions over a bridge and use another light bridge or pass separately on the same bridge, they'll meet again on the other side. — Verdy_p ^(talk) 23:05, 9 January 2018 (UTC)

Also the strict ordering is not convenient at all, notably in iD where there's no way at all to control the order: members are in unpredictable order, and the only thing that can disabiguate it is the roles, allowing to reconnect the elements in logical order (but iD does NOT allow us to add a member a second time to a relation, and we clearly need duplicate node members and duplicate way members that an aonly be distinguished by role). — Verdy_p ^(talk) 22:40, 9 January 2018 (UTC)

That's indeed a problem, we should submit an issue to iD's issue tracker in Github. I also think that iD has never made editing complex relations easy. --Fernando Trebien (talk) 22:56, 9 January 2018 (UTC)

Also JOSM complains first when we try to include the same member twice (and in simple edit mode does not allow this, you need to enable an advanced option to make such addition, and it will still alert the user when modifying any relation that has "duplicate" members, even if they have distinct roles).

In my opinion we don't use the "roles" with all the capabilities they can offer: they are effectively tags (but unstructured and more limited, these are list of identifiers possibly separated by ":").

Note that the cases above are not distinct variants of the line and for one direction only. You cannot represent them as multiple "route" relations that are members of a "router_master" relation, but eventually they may be represented by some new "route_fragment" relation as members of a "route" relation. See the talks about the proposed "superroutes" (notably for EuroVelo where routes are split in sections per country/region and the actual complete route is a super-route, itself possibly member of a "route_master" with PTv2, because a single route object will contain really too many members that are difficult to manage and are effectively managed by distinct authorities; the same applies to "European routes" that are made of multiple sections, not always interconnected completely). All these cases above are for a single travel. — Verdy_p ^(talk) 22:59, 9 January 2018 (UTC)

Passenger drop-off/pick-up zones

Mentioned at https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Station

How can I map where cars can drop off/pick up passengers from outside a station? There are normally designated zones for this outside most UK stations. --Lakedistrict (talk) 16:16, 22 February 2018 (UTC)

If you want to know how to tag the way, this example from Cambridge (UK) seems reasonable to me: 449095206 449095206.
There is no PTv2-tag. If you would like to have it in PTv2 style, you could add it to a public_transport=stop_area relation. U30303020 (talk) 21:37, 11 April 2018 (UTC)

Reason of a proposal page | Proposal to reverting and protecting the page

My first question is: What is the reason of such a proposal page? I searched the wiki, but did not find a concise answer. My personal opinion is that it should display the original proposal and the voting result. First of all, I would like to know if someone objects.

If nobody objects to this and the following, I would like to revert this page to the version of the original proposal (version April 21, 2010 10:38 UTC by Teddych; bot changes excluded) and propose to protect it afterwards to avoid edit wars (which happened a lot on this page).

Reasons for my plan:

• This page is the only one which contains the original PTv2-proposal.
• This page does not have any content that changes over time as the proposal is approved for years.
• If someone would like to read the original proposal (like a newbie), this would be the first source (increased reliability).
• There were editing wars on this page making it difficult to reconstruct which changes were reverted (157 changes after the voting ended).
• Linking to a certain section for referencing would be safe as one could write "according to PTv2 Section Route_master relations ..." and know that this still stands on there and was not changed to reflect current tagging practices or for some different reason.

I am open for a discussion and interested in your opinion. Thx, U30303020 (talk) 21:10, 11 April 2018 (UTC)

I agree with you that proposal pages should not be updated after the vote to represent changes in tagging practice. Of course, people may argue that prominently displaying tagging guidelines which are no longer recommended might confuse the reader. In this case, I feel it would therefore be best to replace the content with Template:Archived proposal, linking to the approved revision of the page. Documentation of current tagging practice belongs on Public transport and related pages, in my opinion. --Tordanik 16:22, 6 June 2018 (UTC)

+1 to Tordanik, approved and probably de-facto active proposals should be freezed / archived. We are generally not doing very well on change management or documentation, would be nice to see the process documented from proposal to current definition (currently it is distributed and mostly unconnected between wiki history and external discussions on any internet channel imaginable, like mailing lists, fora, irc, social media etc.). --Dieterdreist (talk) 17:20, 6 June 2018 (UTC)

Thanks for your answers. Following your suggestion, I archived it linking to the version directly after the vote was approved. Asking administrator Lyx, he spoke out against protecting this page. U30303020 (talk) 12:45, 24 June 2018 (UTC)

Station definition wrt particularly designed

Currently the description for public_transport=station reads: A station is an area dedicated to and particularly designed for passenger access to Public Transport, considerably bigger than a pair of bus stops or tram stops. I take issue with "particularly designed" because if an area wasn't particularly designed for acting as a public transport station, but effectively would function as a station, I would not see a reason not to call it a station, while an area which was particularly or specifically designed as a station but doesn't function as a station would not be a pt station. In short I believe this part can be completely removed. --Dieterdreist (talk) 16:46, 24 May 2018 (UTC)

I could not find this phrase on the page you mentioned. Maybe the link was faulty or I checked the wrong pages? I scanned Key:public_transport, Tag:public_transport=station and Tag:railway=station using automated browser text search. What does "wrt" mean? U30303020 (talk) 10:53, 25 May 2018 (UTC)

wrt = with respect to Johnparis (talk) 17:16, 26 May 2018 (UTC)

It is on this page, here: Proposed_features/Public_Transport#Station --Dieterdreist (talk) 08:26, 28 May 2018 (UTC)

I have also added a similar question here, because it applies as well to that page: Talk:Tag:public_transport=station#Designed_to_access --Dieterdreist (talk) 08:33, 28 May 2018 (UTC)

I oppose changing the proposal itself as you can see one section above. I will therefore comment on the other page. @Johnparis Thanks for clarification. U30303020 (talk) 11:50, 2 June 2018 (UTC)

You are right, discussion should continue on this page. --Dieterdreist (talk) 10:01, 4 June 2018 (UTC)