Proposal talk:Public Transport/Archive 2011

Route variants / segments

The proposal says that alternate routes should be entered into the route_master relation as well, but doesn't tell how. Should every possible route between the end points be a separate route relation? Will a common section then have 16 relations if a route has a variant for three parts of the route? What to do if the route is shortened sometimes and the bus doesn't ride to its end point? What if a certain bus stop isn't in use during some hours, will that mean an entire new relation between both end points? Why the restriction that each direction has a relation? Wouldn't it be possible (and better) that one direction could exist out of several section relations instead with arbitrary section end points to cut down on the number of relations for more than one variant? --Eimai 08:37, 11 January 2011 (UTC)

Yes, in theory you can end up with plenty of relations. In practice it is not possible to create/maintain. I personally leave away relations that are used only once or twice a day, or variants that are only part of other variants. This reduces the number of variants. We also thought about a kind of subrelations for the identical part of variants. We decided to not include this into this proposal. We will cover this with another proposal (to be done). --Teddych 15:56, 11 January 2011 (UTC)

Well, either fix it so it can handle everything properly or don't include it in the proposal then... By suggesting these new rules now you'll make things worse once we finally figure out how to do it. Especially because this new proposal doesn't have that many abilities beyond the current method yet increases the mapping complexity a lot... --Eimai 17:07, 11 January 2011 (UTC)

What can not be handled properly? Is there anything that can not be handled with this proposal? Or is it just the difference between the theory and practice? --Teddych 18:07, 11 January 2011 (UTC)

The fact that you ignore the variants that are used once or twice a day already says you know that it's not handling them well... If you later introduce segments you'll then have a third layer of relations below the routes and that's getting too much. Many mappers don't even seem to be able to handle a single one.

I wish we could step away for a while from the tagging method we have now and try to understand what we actually need. Look up how these bus companies store their data for example, how they can connect their timetables (which we really don't want in OSM) with the routes. Find a tagging method so we too can connect timetables with our data. --Eimai 19:20, 11 January 2011 (UTC)

I personally agree with Emai. Looking at the long bus routes in London, it's hard enough to maintain them while users split and reconnect parts of the routes, ignoring relation memberships. And I created only two of them, still looking after them from time to time. That's why I made the "shared segment" proposal above. However, I can live without it in this proposal. And I can see one good reason to handle it outside: It could update the "route" feature in general. There is no need to restrict it to public transport. And yet I prefer to have it in here, because there is some drive in this proposal. And when it is accepted (and followed), it will spill over to other routes anyway. Otherwise, it would be an approach "out of the blue" and people might ignore it. --Marl 22:39, 11 January 2011 (UTC)

I'd prefer to include something like route segments in this proposal, too.

It seems consensus that it is impractical, if not impossible, to maintain all variants of a route, unless it is a really simple one. Like Teddych, I have used a workaround so far: I only create a route relation for the "main route", which covers the ways most of the buses take.

But if we want to collaborate with projects like the upcoming Transiki, we must be able to identify every single route variant. In such a collaboration it would make sense for Transiki to provide the time table data and to use OSM for routing and visualization. And that means we need a sensible way to describe all route variants.

To put it bluntly (and exaggerate a little): At the moment the proposal gives us a fancy way of tagging bus stops. But it leaves off where it gets really interesting: The question how to tag routes in their entirety and with reasonable amount of work.

Addressing this problem would be a huge step forward for public transport tagging, making it possible to describe a transport network completely and making the routes maintainable for mappers. On the tactical side, that advantage might even convince the "This-is-all-too-complicated-and-we-don't-need-it"-crowd which has - IMHO - valid arguments at the moment.

Regarding the implementation details, I'd prefer another layer of relations, something like type=route_segment which can then be used in the route relation instead of single stops/ways. --MetiorErgoSum 10:56, 12 January 2011 (UTC)

Splitting up routes into segments could be interesting (and is done) also for other route types then only public transport (e.g. cycle route). Wouldn't it be better to put this into another proposal? --Teddych 13:28, 12 January 2011 (UTC)

Possibly. Public transport routes are special, though, because they include not only ways, but stops and platforms. These elements have to be addressed in a proposal. That's why I think it would fit in here. --MetiorErgoSum 11:27, 13 January 2011 (UTC)

The whole discussion (including the various "unusual route" and "boarding/deboarding only stop" requirements) suggests to me that there are still some problems left that must be tackled with an understandable and feasible (from a workload point of view) concept. And I have something in mind, covering most, if not all requirements. The only drawback I see right now is that it is ugly in theory, because it loads data into relation membership role keys. And there are two other things about it:

It is quite public transport focused (though not limited to it), so I feel it must be introduced into this proposal or at least created and read together with this proposal
It also solves the problem of having to over-engineer simple routes consisting of just one way that is used in both direction, stopping at the same stop positions and with no platforms mapped so far, by creating the choice of a range of compatible tools.

This is a first approach (very similar to my previous Shared Route Segments proposal above):

A simple route is as described in the current "Rout Direction / Variant" proposal on the main proposal page, with some small, but powerful changes:
- Unlike in that proposal, there is need for a route master - at least if all variants are covered inside one single route relation.
- There is a new, optional tag "oneway" (we already know it from somewhere else), defaulting to "no" (we already saw that before as well). So if the ways and stops are identical, a route is two-way by default. They are valid in the membership order for one way and in reverse order on the way back. If it is tagged "oneway=yes", a return route should be defined somewhere else, including the option of doing it according to the current proposal (which I do not prefer). We can also think about other "oneway" values, such as "circular" (which raises the problem of defining entry and exit points for vehicles).
- If the way back is slightly different (one-way roads / roundabouts or precisely defined platforms on both sides of the road), we can use the condition/filtering syntax from above. We still don't need a route master.
- Route segments can be included as members for forward or backward interpretation, as described above. That helps us combining routes from primitives as needed. It also includes the option of separating stops from ways, so express buses can use the same route way definition.
To increase the compatibility of this proposal with existing implementations, route segments are also relations tagged with "type=route" and not "type=route_segment". So even the oldest software will display segments just over (or under) the actual routes. For new software, we add the tag "segment=yes" to keep it from displaying incomplete parts. So routes tagged with "segment=yes" are not seen as full routes. They are just building blocks. This also reduces the perceived complexity, because there is no new relation type.
If a mapper has intentionally separated stops from ways (for example because of express buses or, more importantly, express trains), he should make this information available to other mappers. That's why I propose to define a tag "donotadd=<semicolon separated list of thinks not to add>". This list can contain "way;stop;platform" and all allowed tags, such as "ref;operator;name;colour".
In order to address the remaining points, we replace the role membership name for stops by a string consisting of different parts.
- In the simplest case, a stop role membership is just "stop", so there is no change.
- I already talked about some filtering, such as appending "_only_forward" or "_only_backward" according to the route direction.
- Additionally, we can prepend something, such as "boarding_" / "deboarding_", possibly resulting in a role membership like "deboarding_stop_only_forward".
- To make the proposal complete, we add vehicle entry and exit point information to the role. Let's append "_exit-<aName>" or "_entry-<anotherName>". These names may consist of letters and digits only, so parsing them is easy. Timetable services can refer to them, stating exactly where a service starts and where it ends that time. If everybody agrees, these names can even be used twice, in case there are two stop positions for different directions at the same location and they are correctly filtered according to the directions. Of course, one and the same stop can be _entry-something and _exit_somethingElse at the same time, so the full role membership syntax I have described is

[boarding_|deboarding_]stop[_only_forward|_only_backward][_entry-<aName>][_exit-<aMaybeOtherName>]

- An example: A full route goes from A via B and C to D and back. At B and C, the stop positions on the forward way are different from the platforms on the way back. And at C, passengers cannot enter the vehicle on the way forward, while on the way back they cannot leave the vehicle (the Helsinki example from one of the unusual routes). Sometimes, the route is run between B and D only. This are the relation membership roles:
  - stop: A
  - stop_only_forward_entry-btown: B
  - stop_only_backward-exit-btown: B (the other one, on the way back)
  - deboarding_stop_only_forward: C
  - boarding_stop_only_backward: C
  - stop: D

Timetable services can display the route like this:

Forward departing at 8:00, 8:30 (from "btown" only), 9:00, 9:30 (from "btown" only), 10:00, ...
Backward departing at 8:00, 8:30 (to "btown" only), 9:00, 9:30 (to "btown" only), etc.

This also enables us to cover variants covering parts of a long route inside one relation, avoiding the need for route masters even in these cases. And it should also work for circular routes or worse, up to star-shaped routes, because the entry and exit and boarding/deboarding definitions are part of the membership role and one and the same station can be in the relation multiple times.

The only thing I'm unsure about is what we should do with the platforms. Of course, they need to be filtered. But I don't think we need to define all the entry/exit/boarding/deboarding stuff for them.

OK, I hope that I didn't forget anything. Right now, I have a good feeling with it. What do you think?

--Marl 21:29, 12 January 2011 (UTC)

You have written plenty of text... Conclusion: 1. type=route_segment should be changed to type=route+segment=yes. 2. You want to add something with forward/backward.

The first makes sense, but I will do it in another proposal, because it is not limited to Public Transport, it also can be used for hiking or cycle routes.

I will not add something like forward/backward. There is only one direction per relation: forward. What should backward mean?

--Teddych 06:22, 13 January 2011 (UTC)

Yes, it is about the reverse direction. This is exactly what disturbs me. It doubles the effort for even the simplest route and that's why I want to avoid it. At least until anybody can give me a good reason to do so. And it seems to be shared by most of the people around here. I know that it was one of the main points in the OXOMOA proposal, but I could find no written justification for doubling the effort. So I tried to imagine why they did it and proposed an answer to the problems I supposed. Do you have a clue what the separated relations are for (other than doubling work)? By the way, I still wonder why nobody from these guys are taking part in the discussion. Maybe they can explain their original aims.

--Marl 08:24, 13 January 2011 (UTC)

The reason for separating the two directions probably was that at least the platforms are different on the two directions, even if the ways were identical. The question is: How many routes are identical on the outwards and backwards way. I live in a medium sized town, and even here I don't have a single bus line where this applies. There's always a few one-way streets and streets with separated lanes, and many stop_positions plus all platforms are different. It is probably different in strictly rural areas, but in all cities I know it makes sense to separate the both directions of a round-trip. Mapping a return route doesn't take twice the effort, by the way, because you can simply copy the forward trip and reverse the order of its elements. Maintenance is more time-consuming, though, and it increases the danger of data inconsistencies.

I don't see a problem with an optional tag like oneway that says "This route can also be used for the return trip, just reverse the order of way and stop elements." But I wouldn't make this the default. --MetiorErgoSum 12:12, 13 January 2011 (UTC)

Your guess is part of what I guessed and what I accounted for with the only_forward and only_backward filtering. I agree in so far that on well-mapped routes, most (if not all) platforms differ between directions and many ways (let's say 25%) of the ways are different as well. In smaller towns, only very few ways per route differ. Tools such as the JOSM Public Transport addin make it easy to record ways and stop_positions, not platforms. And here is where I see the biggest saving if we allow both directions in one relation. The second benefit is that we get rid of the route_master overhead in many cases, which is more a saving of brain resource than a saving stupid work. On an OSM munch in Hamburg somebody told me that he stopped mapping public transport routes as soon as the idea of all this came up. I personally still put everything into one relation, with the old and bad forward/backward semantic, until something else is agreed upon. I feel that many others go one of these two ways, at least here in London. And as you mentioned, reversing a relation copy saves some initial effort indeed, at the expense of having to maintain the redundant fragile information. The same goes for shared segments. If they share most of the ways, they should be usable in both directions. --Marl 20:46, 13 January 2011 (UTC)

I began a new proposal that allows to split routes: Proposed_features/Route_Segments. Feel free to discuss/add there. --Teddych 10:00, 24 January 2011 (UTC)

Comments

Add under platform the tag departures_board = yes/no (found in the german county Bremen).

And what exactly should this mean? --Teddych 10:34, 20 January 2011 (UTC)

Indicates whether there is a departures board at the platform or not (electronic table showing departure times of buses etc.) --Ant 13:59, 20 January 2011 (UTC)

There are two different types of these boards. In Dresden Saxony we have some wich are dynamic. So you can see the correct time when the vehicle depart.

http://de.wikipedia.org/wiki/Datei:DFI_integriert_in_Haltestellenschild_Carolaplatz_2010-02-14.JPG

http://de.academic.ru/pictures/dewiki/68/DFI2.JPG

http://de.academic.ru/pictures/dewiki/68/DFI_Dobritz.jpg

But in smaler citys like Bischoswerda we have boards wich only show the time from timetable and the platform. If the veheicle is late so it erased from the board.--Viw 06:48, 26 February 2011 (UTC)

Possibly this would fit better under information=*, somehow? Possibly. I'd also like to see distinction between realtime predictions and those counting down to simple timetable values. So, I've used departures_board=realtime. Some stops have one line displays that alternate between all the lines using that stop, and bigger displays that show all lines at the same time; even the predicted time to the second next bus. Alv 08:39, 28 February 2011 (UTC)

Can't wait for the voting to start

Vovkav 20:28, 30 January 2011 (UTC)

I would like to make sure that the content is compatible with the just started route segments proposal, because there may be dependencies. At least I haven't got an idea yet how it will look like in one or two weeks. And I think that we need a good integration with route segments. --Marl 22:41, 30 January 2011 (UTC)

I was too buzy to work for OSM, but now the vote started. --Teddych 14:54, 31 March 2011 (BST)

Platform tags

I believe that there needs to be some more tags to define the platform. The first is the tag pole = yes/no. The reason is that there may not be any pole at the position yet it is used as a bus stop. This can be quite common in rural areas here in Australia and I also imagine in developing countries. The other one is the existing tag tactile_paving (another term is Tactile Ground Surface Indicator (TGSI)) this would define if there these disability aids at the stop. The TGSI are a requirement for our Disability Discrimination Act(DDA) compliance for bus stops in Australia and I assme that they would be in wide use in most developed countries.

I agree. But I did not want to include it in this proposal. We have to create another one for disabled (and others). Extending some existing things is always possible. --Teddych 14:57, 31 March 2011 (BST)

light_rail

I'm missing light_rail in the list tram/bus/train/subway/...=yes/no ... In Karlsruhe, we have light_rails, that can use tram tracks AND train tracks, they are tagged light_rail at now ... --Mueck 17:41, 14 March 2011 (UTC)

You can also use light_rail=yes. The list probably never will be complete. --Teddych 08:43, 31 March 2011 (BST)

I added light_rail to the list, but did not link it to the access page. --PJ Houser 23:55, 9 January 2012 (UTC)

tram/...=yes/no

Just no, tram=yes is used for stop_position. For platform it is wrong?? A platform may be used e.g. by bus AND tram, bus at the beginning / tram at the end or bus at the left side, tram at the right side so tagging might bei different for stop_pos./platform (or both at the same stop_position) --Mueck 17:41, 14 March 2011 (UTC)

I would not call it "wrong". If it helps, add this tag also to highway=platform. In the proposal it is not included, I would call it redundant. But perhaps we have to add this later, we will see. --Teddych 15:02, 31 March 2011 (BST)

wheelchair

At now, wheelchair only has yes/no/limited

For future, there should be more detailled information, e.g. the height of platform and vehicules

In Karlsruhe we have more sorts of wheelchair access:

tram and some light_rail route (the DC routes S1/S11 in future and at now half of S2 trams) have a vehicule (?) height of 34 cm

other light_rail routes (the AC routes S4/S41, S31/S32, S5, ...) have a height of 55 cm

the "S-Bahn" S3 has a height of 76 cm

and platforms vary: 0, 15, 34, 38, 55, 76 cm, some of them mixed

at Durlach Bahnhof and some others 55 cm at one end, 76 cm at the other end

in future at some platforms inside city 34 cm and 55 cm serial

This problem shoud be solved one day to get better plans for wheelchair users, but I don't know, if it should be inside this proposal or a new one --Mueck 17:41, 14 March 2011 (UTC)

Using the terms in http://en.wikipedia.org/wiki/Railway_platform_height

platform_height=... at platform and/or stop_position

at platform-way: it's length should represent the length, which can be used with this height. If not, way has to be split.

at nodes: platform_length=...

floor_height=... at route

and some information at route:

if all trams have this floor_height

wheelchair:description:de=... ? additional to wheelchair=limited at route

where to find suitable door

wheelchair:description:de=... too? or something, which can be evaluated by program?

--Mueck 14:44, 15 March 2011 (UTC)

Another item for platforms: http://wiki.openstreetmap.org/wiki/Tactile_paving --Mueck 14:44, 15 March 2011 (UTC)

bin

bin=yes is often tagged at some platforms in KA --Mueck 17:41, 14 March 2011 (UTC)

You can continue tagging bin=yes. --Teddych 14:50, 31 March 2011 (BST)

IBNR

searching for IBNR in wiki http://wiki.openstreetmap.org/w/index.php?title=Special%3ASearch&search=ibnr shows, that someones propose to add IBNR as uic_ref=... for local public transportation using http://www.ibnr.de.vu/ but this site not only return uic_ref with 7 digits, but also IBNR outside UIC numbers with 6 digits. Comparing http://taginfo.openstreetmap.de/search?q=ibnr#keys and http://taginfo.openstreetmap.de/search?q=uic#keys shows, that uic_ref is widely used, for ibnr there is no widely used tag ... This service http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?zoom=18&lat=50.813864&lon=7.164081&layers=B00T seems to use different taggings: http://www.openstreetmap.org/browse/node/642356639 http://www.openstreetmap.org/browse/node/642356655 Seems to work also tagged with uic_ref only with correct UIC http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?zoom=18&lat=49.0093&lon=8.404&layers=B00T and olso with ibnr-only uic_ref http://www.netzwolf.info/kartografie/osm/bus_und_bahn/abfahrt?zoom=18&lat=49.0092&lon=8.3953&layers=B00T So what to do with IBNR? --Mueck 14:17, 15 March 2011 (UTC)

The numbers known as IBNR are only useful with timetable applications using HAFAS by Hacon. We should not use german abbreviations within OSM, so ref:hafas would be a better tag. As long as Michael Dittrich has not given the permission to use his database in OSM, we should not use it. --Ajoessen 14 April 2011

Also note, that the IBNR is not needed for Germany, as the HAFAS and EFA timetables services work with ref_name=*, which was designed as a best possible universal name of (national) timetable services. ref_name=* (at least for Germany) is the name of the stop, written ref_name=<stop_name>, <town/village>. This tag already works on http://openptmap.org.

highway=bus_stop !

For gods sake, what is the problem with getting this compatible with highway=bus_stop and get on with the voting to end this confusion?

1. public_transport=platform (to be rendered) for nodes off the way and as a fallback and compatibility highway=bus_stop

2. public_transport=stop_position (not to be rendered) for nodes on the way and highway=bus_stop if no platform is around so rendering is still made (until some other tag will be thought of and properly used by renderers for this issue)

Dr Jan Itor 20:37, 27 March 2011 (BST)

Stop area and route

It seems a bit redundant to have a relation stop_area including all the elements belonging to the stop, and then in the route relation including both the stop node and the platform for every stop. Why not allow for instead including all the stop_area relations into the route relation? It is a bit more complicated to map. But it will make the route relation less cluttered, and it will associate any extra info in the stop_area relation with the route. Evil saltine 13:39, 31 March 2011 (BST)

With your idea it is not clear, which platform/stop_position is used for which direction. --Teddych 14:48, 31 March 2011 (BST)

Good point, I hadn't thought about that. Evil saltine 16:55, 31 March 2011 (BST)

I do not understand the problem, a route relation is only used for one direction, so how can there be any ambiguity?

best practice for backward compatibility

the proposal could use a best practice section, which explains on how to use the new mapping scheme together with the old tags to achieve a maximum of backward compatibility with current renderers and map applications. currently i tag bus stops for all directions of a stop area with public_transport=stop_position and highway=bus_stop. therefore i get two bus-icons in mapnik and no name, since it is defined in the relation for the stop_area. this resulted in more than just one direct message from angry mappers in that area. should i put highway=bus_stop on just one of the stop positions and additionally add a redundant name tag on it? because somehow i have the feeling that the mapnik programmers just don't know how to implement complex constellations that use relations (type=site doesn't get rendered either). --Flaimo 22:14, 5 April 2011 (BST)

If and when the proposal gets approved, this should be done in the features pages, not in the proposal itself. Teddych 06:53, 7 April 2011 (BST)

any ideas, now that it got approved? --Flaimo 18:47, 19 May 2011 (BST)

name as "prose description"?

The proposal suggests to use the name key for a "prose description of route variant". I've noticed that only now, and I disagree with this suggestion, as this is clearly not a proper use of the name key - especially when used on values like the example "Example: Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi". Better choices would be description or note. It should be noted that e.g. editors can use these tags in absence of a name to make relations identifiable, and at least JOSM actually does so. --Tordanik 21:06, 6 April 2011 (BST)

Second that. Names are in the local language, anyway, when such exist. What's mentioned in the documentation (the same as the example copied above) is a description. Alv 13:58, 22 August 2011 (BST)

Please convince us, what makes a made up "prose description" a "name". (Sure some lines are advertised with a name, esp. when you can read it off the front of the bus.) Alv 06:11, 23 November 2011 (UTC)

This is historically grown. When the proposal has been approved over 70'000 objects (today 114'000 objects) already have been mapped with this name-tag. --Teddych 12:26, 23 November 2011 (UTC)

Where does that number come from? Number of any name=* (including proper names) on objects that have any route=* tag is 93 750; there are only 29 755 route=bus tags on relations and the next relevant route=* values have far less uses. Alv 16:03, 23 November 2011 (UTC)

You are right, I picked the wrong number (public_transport=* with name=*). --Teddych 06:57, 24 November 2011 (UTC)

The correct reaction when you notice that bad tagging is widespread is not to further encourage its use. Instead, instantly document a clean alternative. As long as there are still a lot of name tag abuses, it should be mentioned that "name" was originally used for this information, but that it should no longer be used for new routes and retagged on old ones. During a transition period, applications can support both tags as equivalent alternatives. --Tordanik 14:41, 23 November 2011 (UTC)

I did not realize the abuse of the name tag while writing the proposal. You brought this up after approving the proposal. --Teddych 06:57, 24 November 2011 (UTC)

Custom tagcheck for JOSM Validator

Hi,

I've set up a small custom tagcheck file for JOSM/Validator. It's really helpful as JOSM does not yet support this proposal :)

If you see some checks that could be added into, please let me know :)

--Don-vip 01:02, 25 April 2011 (BST)

How to differentiate route variants

There is a difficulty to identify variants and directions in a master route relation using this proposal.

The task for direction and variant identification appears in real-time routing applications. We need there to identify, what whole route variant is used (or should be used) right now by this particular vehicle. Information about whole route variant is required f.e. in a forecast job.

The best and minimal solution for this job IMHO is using role names and order of members of the master route.

My suggestions:

The whole route variant consists of route master members with the same role name
Master route member role name identifies whole route variant in a free form
Empty role name is used to identify 'default' whole route variant
Order of route master members with the same role defines sequence of route directions (segments?) to pass on the whole route variant, if their number is greater than 2
If the same route direction (segment?) is used in different whole route variants, it is included into the master route relation several times, with different roles accordingly to the whole route variant inclusion

These suggestions may be used also to resolve all issues related to compound route segmentation, sharing route segments between routes etc.

--Nnseva 13:09, 27 April 2011 (BST)

Additionaly. It is important to identify circle and linear routes easy and unambiguously. Vehicle on the circle route always moves only to one direction, while vehicle on the linear route passes forward and backward directions sequentially.

The suggestion also applicable to separate circle and linear routes. Two whole route variants - default empty role (clockwise) and 'counter' role (counter-clockwise) - might be used to describe two directions of circle route, while the linear route will have two directions - forward and backward - within one default route variant.

--Nnseva 15:35, 27 April 2011 (BST)

One route variant always represents one direction. The backward direction has always to be in another route variant relation. So you NEVER have forward and backward in the same relation. --Teddych 08:09, 28 April 2011 (BST)

Sure. Imaging that the whole linear route (represented by the master route) have 2 variants. F.e. one for working week, and one for weekend. We will have 4 members of the master route, two directions multiple by two variants for every direction. The question that I am trying to resolve in this case - what variant of the backward direction continues every of variants of the forward direction? In other words - what members of the master route represent the working week variant of the whole route, and what members represent a weekend variant of the whole route?

Imaging that you are just looking to stored data, and you didn't know about real route up to this moment. You will see 4 members of the master route. In the existent proposal you will see empty role name for every member. Looking to members, you will see both ends of members, so you can probably separate two route directions. But basing on existent data you can than construct 3 possible whole route variants instead of 2 existent in the real world, so you will be messed up. My suggestion is - using master route member role name we can logically unite some members to the whole route variant. In the example - we can use role name 'weekend' to unite two directions of the weekend variant of the whole route, so other two members will be united to the 'default' variant of the whole route.--Nnseva 09:01, 28 April 2011 (BST)

Your problem is not solved with this proposal. And your problem is bigger then your example. I know examples of variants that are only used once a week at monday mornging. So if you want to solve your problem you have to find a solution to define the whole timetable into OSM. Otherwise you will never be able to catch all exceptions. And including timetable or transit-routing is not able with OSM and this proposal. For this we need another (big) step. --Teddych 12:27, 28 April 2011 (BST)

Sure, the timetable should solve this task completely. But:

even having timetable of any structure approved it is useful to have already unique identification of the whole route variant referenced from the timetable, instead of grouping route direction relationships in the timetable itself
while the timetable proposals are not approved we have a situation with route directions and variants mixed together in a route master, and no any possibility to differentiate them - even for different rendering, f.e.

--Nnseva 13:34, 28 April 2011 (BST)

What about simply add opening_hours=* to the variants ? I think it solves your problem more efficiently than the roles approach.--Don-vip 19:28, 18 May 2011 (BST)

I agree, the solution like this may resolve the problem. Then the tag extension of the proposal may contain the following tag definition for the route variant:

opening_hours=* - must be present for all variants/directions included into master route if more than one way to pass the whole route (one whole route variant) is present. Time conditions for different whole route variants should be exclusive.

--Nnseva 14:59, 19 May 2011 (BST)

Partial way inclusion

The important note which should be IMHO included into the head of the proposal is that the proposed scheme, contrary to the old one, allows to avoid way segmentation (splitting) while adding a route.

Strict way order on the route direction allows to calculate strict way node order easily almost in all cases, except:

start and stop way of the route direction
multiple crossing of two neighbour ways

In all other cases ways may be included into the route partially, and this partial inclusion is unambiguous.

--Nnseva 14:13, 27 April 2011 (BST)

Even if some consumers were able to deduce where to split the ways when parsing, it would be bad data for all current users. There's even no mention of such relaxed style in the proposal. They're bound to be split anyway for other tags, eventually. Alv 16:47, 27 April 2011 (BST)

Strict way order is not something that we can be assured that editors will keep. --NE2 21:50, 27 April 2011 (BST)

Strict way order is what the proposal defines: "The ways should be inserted beginning with the way at the initial stop position and ending with the way at the terminal stop position.". Also way members of the route (in the table) are commented by "in sequence from=* .. to=* representating the route of the vehicle". These both sentences define strict way order on the route direction IMHO. --Nnseva 09:34, 28 April 2011 (BST)

Answering the both - the proposal already breaks existent rules for routes and avoids using some software, in particularly - requiring strict order for stops and platforms, as well as for ways in the route direction relation. --Nnseva 09:39, 28 April 2011 (BST)

It does not break with existing rules. Until now the order was not defined. Now it is defined. --Teddych 11:48, 28 April 2011 (BST)

The proposal implicitly prevents using existent software (which was not oblige to save strict order of elements in a route, and so may break this order) to edit new kind of route (direction) relations. Additionally it makes some required tags (ref f.e.) optional for the direction having master route relation, restricting using software which uses such tags to render this route. That's what I meant. --Nnseva 14:10, 28 April 2011 (BST)

Then we should add preserving way order when splitting ways to the list of things that editors must support (do we have such a list?) and ban editors that don't comply. --NE2 02:30, 29 April 2011 (BST)

Page renaming ?

Shouldn't it be renamed to Approved features/Public Transport now ? :) --Don-vip 00:38, 29 April 2011 (BST)

I personally would, but on Proposed_features#Post-vote_clean-up I found the recommendation to NOT move the page. But the advantages/desadvantages are not described there. --Teddych 14:40, 2 May 2011 (BST)

Combined routes

I'm wondering if there's any standard way to combine routes that share significant sections. For example, here in Orlando, three routes head south from downtown along Orange Avenue. The three routes have headways of 1 hour, 1 hour, and 1/2 hour, but are scheduled so there's a bus every 15 minutes on Orange Avenue. This is definitely useful information to have in easily-accessible form. So is there any standard way to tag a relation for the combined section with headway=15 minutes? --NE2 01:52, 20 May 2011 (BST)

See Proposed_features/Route_Segments --Teddych 08:37, 20 May 2011 (BST)

Rare inconsistency in case of opposite platforms on duplicate way in a direction

I've found some inconsistence which may appear rarely in case of opposite platforms connected to the same node (stop) on the way like 30000199 30000199.

Imaging that we have a new-style route like 1244886 1244886, which contains one direction like Bus 201 (XML, JOSM, osmose, sketch-route), but which includes the way 26127215 26127215 twice in both directions.

The route stop 30000199 30000199 participating in the way 26127215 26127215 then also should be included into the route direction twice, followed by two different platforms, 89550242 89550242 in one direction, and 89550243 89550243 in another one.

In this case, we can't directly determine, what inclusion of the stop 30000199 30000199 into the route direction corresponds to passing the way 26127215 26127215 in forward direction, and what corresponds to backward direction. Answer to this question is available only after complex analysis of the route direction itself as a whole.

Proposed solution: Additional tagging platforms 89550242 89550242 and 89550243 89550243 using something like platform=forward and platform=backward may help in this case.

Yes, you have to analyze the route relation to know, which platform belongs to which direction. This proposal does not know a forward and a backward direction. There is a route relation for each direction and each variant. And all of them are used only forward, none backwards. --Teddych 19:54, 11 July 2011 (BST)

light_rail considered harmful

The distinction between various forms of infrastructure takes up a lot of this proposal and a lot of discussion. The fact is there are not hard lines between the various categories even among transit professionals.

Let the railfans create and map such categories. But for transportation purposes it may be far easier to map based on function:

tourism=yes (for routes that are not general purpose transport, e.g. amusement park loops or pure scenic loops)
grade_separation={full,partial,none}
tracks=2-4 (Typically two track line with passing tracks. The IRT express lines in NYC would be tracks=4-4)
average_speed=45 (this is the key key for routing)
maximum_speed=80 (this is the key key for routing)
ride_quality={rail,maglev,tire,cable}

Model what the traveler and router needs to know. The mode/guideway type tag is there only because travelers have strong preferences for particular modes due to comfort reasons.

Something like light_rail would then become grade_separation=no, ride_quality=rail. A busway is grade_separation=partial, ride_quality=tire, average_speed=18. San Francisco's Cable cars would show up as rail, though at a slow speed (9mph maximum). Brycenesbitt 17:44, 28 August 2011 (BST)

Binding subway entrances to stop area

Should we bind subway entrances to something? I have to map subway entrances which are in the middle of a public_transport=station area. I think the prefered way would be to bind subway entrances to the relation public_transport=stop_area (with role subway_entrance). It seems to be already used at Hauptbahnhof Nord Hauptbahnhof Nord but there is no mention of that in the proposal. Could it be added to this proposal? --Oligo 13:37, 28 September 2011 (BST)

Yes, do it as you have proposed and as it has been done with

Hauptbahnhof Nord. We should not add anything else to the proposal because it is already approved. --Teddych 05:30, 29 September 2011 (BST)

How do I tag a large asphalt plane where the buses can run

How do I tag a large asphalt plane where the buses can run around to get into the right platform? How should I tag the different bus routes that go there? Should I draw a way for each bus route into its platform, or should I add each bus route reltion to the plane? Here's an example what I mean: [[1]] How should I tag a bus parking where the buses are placed when not in use or maintenance. --Magol 11:07, 26 November 2011 (UTC)

I did draw a way for each route, see here. --Michi 03:50, 27 November 2011 (UTC)

Long distance bus routes (Greyhound, Berlin Bus)

How to tag? Relation with type=coach? See Fernbuslinien --Lulu-Ann 14:58, 2 December 2011 (UTC)

I'd say the standard route tags: type=route, route=bus, maybe with vehicle:type=coach?

I also once tried to map long distance routes of the Berlin Linien Bus, but I decided not to map that route, because I had not enough data. --Michi 20:04, 2 December 2011 (UTC)

Vehicle-based attributes

My mention of a vehicle:*=* tag in the discussion above got me thinking... How about mapping things like vehicle capacity (vehicle:capacity=*), wheelchair-access ramp and low floor (vehicle:ramp=yes, vehicle:low_floor=*), bicycle transport (vehicle:bicycle_transport=*), etc.? --Michi 20:14, 2 December 2011 (UTC)

Frequency of buses

Several of the public transport routes are very frequent with small headway (every 2 minutes), some are very rare (every 40 minutes), plus there are night buses. Maybe the word "frequency" is not good, so using "headway". Some tags like

headway:rush_hour=2
headway:day=8 (preferably, or just headway=8)
headway:night=off

would indicate a bus that operates every 2mins during rush hour, every 8mins during day and is not operating during the night. Exact times when night starts should be connected to operator. Renderers have then choice of displaying separate routes for night/day and suppress infrequent buses which have a relation (e.g. long distance bus which operates once a day) --MichalP 10:38, 6 December 2011 (UTC)