Talk:Proposed features/Public Transport

From OpenStreetMap Wiki
Jump to: navigation, search



Oxomoa presented an idea how to tag funiculars. I do not value if it's good or not. I think it's in better to place it in an other proposal. --Teddych 07:32, 1 December 2010 (UTC)

type=route vs. type=line

The original Oxomoa idea tried to rename the route-realtions tags type=route into type=line and redefine type=route to the underlaying track instead of the line running on the track. I personally think it does not make sense to rename an uncontested tag usage. --Teddych 07:46, 1 December 2010 (UTC)

To add the possibility to represent a track as a route it can be added without renaming type=route. --Teddych 07:46, 1 December 2010 (UTC)

In fact this would be the opposite - a line is the physical infrastructure, while a route would be a specific service that runs along it. --NE2 19:49, 5 December 2010 (UTC)
I don't know, what exactly you want to say. The problem is: Originally a bus line is tagged as type=route defined in Relation:route#Public_Transport_Routes. Oxomoa wants to rename a line to type=line. I did not take over that from Oxomoa and reused the old and well known style type=route to tag a bus line. --Teddych 05:28, 6 December 2010 (UTC)
Which is also known as a bus route, or bus service. But on a railway the line is more properly the actual infrastructure, rather than the service that uses that infrastructure. --NE2 21:55, 6 December 2010 (UTC)
I think route is the most appropriate term here too. You have a train line over which multiple train routes/services run. Some start and finish on different lines, others may just run on the one line. It just confuses things calling it a line--Pobice 22:31, 6 December 2010 (UTC)

I'm not native english speaking, so I'm a bit confused. What exactly is called a line and what is a route/service? When I understand corretly a line is more the underlaying infrastructure and a route is a service that is based on an infrastructure and possibly more then one line. Correct? So the old style is more what we want to represent and Oxomoas style is completely wrong. --Teddych 08:03, 7 December 2010 (UTC)

The terms are a little interchangeable, but yes line=physical, route=service appears to be the most widely used and in IMHO is more correct. --Pobice 22:57, 7 December 2010 (UTC)
I have corrected this and I hope, it is better now. --Teddych 12:44, 8 December 2010 (UTC)
So far I've only seen type=line relations used in the way described in the proposal as type=route_master, i.e. the bus route from A to B is tagged as type=route, the way back from B to A is tagged as type=route as well and both are child relations to one type=line relation. If there are alternate routes, for example during rush hour or late at night, the type=line may have more than two child relations. At least when coming from a German background the terminology makes perfect sense: “Route” is one specific way to get from A to B and “Linie” is the abstraction of one or more routes, usually associated with a number, letter and/or color, such as “Bus 42”, “U3” or the “red line”. ——octo 22:09, 24 January 2011 (UTC)
type=line was introduced by oxomoa and other German speaking people. As you can read more above, the English word line represents the infrastructure. The German word Linie represents the service based on that infrastructure, which differs to English. So in English the type=line is wrong to represent the route master. A more correct alternative would be type=service. --Teddych 22:30, 24 January 2011 (UTC)
Gotcha, thanks for your explanation, this didn't become clear to me from the above posts. I think what added to my confusion is the fact that JOSM includes a (German) translation for type=line as "Linie". Better translations might be "(Ober)Leitung", "Strecke" (ambiguous and easily confused with "Route", imho), or "Trasse". (Not that I see the point of putting the physical infrastructure into a relation, I have to admit.) —octo 07:19, 25 January 2011 (UTC)

type=route for route master?

Resolved: renamed type=route to type=route_master in the proposal. --Teddych 10:37, 20 December 2010 (UTC)

The problem I see is that with this proposal, the route variant relation and the route master relation use the same type. How should people or software distinguish between them without having to check their members, especially if the optional tags aren't present? I think they should use different values for the type-key so you can clearly distinguish and you can only get the relations you need. It probably would be the best, if we used something like type=route_variant on the route variants, but as the route variants are closer to the old route relations, it might be more backwards compatible to find a different relation type for the master relation. --Errt 16:02, 14 December 2010 (UTC)

Your are right. What do you think of type=service for the master? --Teddych 10:20, 18 December 2010 (UTC)
I think that using the word "service" as a relation type would be sort of hijacking it for Public Transport. There could be other services using relations. And somebody coming across a type=service might wonder what it is all about. I would prefer a hint to Public Transport in the type, such as "public_transport_service". This does not apply to a route. Unlike a service, a "route" is not public transport specific. It is just a proposed or commonly used set of ways. If Public Transport is running on it, there are other (Public Transport specific) attributes. Unfortunately, I also don't feel that the word "service" is a good description of what the route master means. I'm not a native speaker, but my perception from announcements in the UK is that "service" actually means one individual vehicle trip along a predefined route from one end to the other. The following vehicle seems to be the a different "service". Are there any native speakers who can help? --Marl 12:44, 18 December 2010 (UTC)

Fearing that we deviate too much from the general "type=route" definition, I have reread Relation:route, ignoring the Public Transport related parts and thought about its compatibility with our route variants, route masters and route and route segments.

This is my opinion so far:

  • Route segments and route variants both fit perfectly into the into what I have found there
    • Route variants that do not contain references to route segments are identical with the basic routes described there.
    • Route segments are basic bus/railway/etc. routes with no "route variant" or "route master" related attributes. This is why different route variants and even different routes can share them.
    • Route variants that do contain route segments are a perfect example of the super-relations described there.
  • I am unsure about route masters, because they do not always define "a (one) customary or regular line of passage or travel", but a collection of these.

As far as I understood, the single reason why a route master is needed is to combine the usually two direction variants and other possible variants of the route into one relation. Obviously, somebody felt this is safer than holding the ref/operator/network/etc. tags redundantly in all variants, creating a risk of inconsistencies.

Existing software seems to work well with everything just being "type=route", reading all details out of them and handling redundant information by removing it or just drawing it twice.

Combining the impression that route masters are something very similar to routes, but slightly different - why not expressing this in the type name, requiring only minimal changes (if any) to existing software? We could do that by appending something to the word "route". Software could handle all relations with "type=route*" the same way. Of course, it would need to handle child relations correctly anyway. The easiest proposal would be "route_master", because the word was already mentioned. Another proposal derived from something existing would be "route_service" (which I do not prefer due to reasons stated above). I don't see the optimal word to append to "route" yet, but I think that we should append something to the string "route_" to build the type name for route masters.

--Marl 14:58, 18 December 2010 (UTC)

I have renamed type=route to type=route_master in the proposal. --Teddych 10:37, 20 December 2010 (UTC)
After that change, the route variants contain all attributes from the route master - which brings back the risk of inconsistencies. If so, what is the advantage of having a route master at all? --Marl 21:46, 22 December 2010 (UTC)
Good question. There are several local recommendations to not use a route_master=*. So I'm looking for a way between not using a route_master=* at all and the elimination of redundancy. I have set most to optional if route_master=* exists. --Teddych 06:01, 23 December 2010 (UTC)

Line Variant

Resolved: This is explained more in detail in the proposal now. --Teddych 06:38, 6 December 2010 (UTC)

Can someone involved in this proposal explain more detailed how stops should be integrated in the routes? In User:Oxomoa/Public_transport_schema#Basic_model_for_lines the line variant contains the stop position as well as the platform, which in my eyes is quite complicated. Especially because there is no rule how to sort all this information. I have seen all stop positions in a row and then all platforms in a row, i have seen the platform always following the corresponding stop position and i have seen routes containing only the stop positions athough the platforms are also mapped. In this proposal i only read "the stops" should be inserted in sorted order, which i don't find really helpful. --Almich 14:23, 5 December 2010 (UTC)

This is explained more in detail in the proposal now. --Teddych 06:38, 6 December 2010 (UTC)

Route Master

Resolved: This is explained more in detail in the proposal now. --Teddych 12:57, 9 December 2010 (UTC)

How about route variants and route directions. Should both be added to the route master ?--Immo 09:25, 9 December 2010 (UTC)

Yes. This is explained more in detail in the proposal now. --Teddych 12:57, 9 December 2010 (UTC)

highway=bus_stop ?

This proposal is very much oriented about public transport network description where I describe what I see on the ground. For instance, when I survey a street, I may see two bus stops, one on each side and not necessarily face-to-face and I put a node beside the way to show where the stop is really for the "end users", not for the "operator" (tagged with highway=bus_stop, name=*, and shelter=yes/no). In your proposal, I don't see what is planned about this tag for bus stop. Is it deprecated ? by your stop proposal which does not show which side of the street is served ? -- Pieren 09:55, 5 December 2010 (UTC)

When you survey a street usually on each side of the street you see a pole, a platform and the yellow zigzag lines on the street. In your editor you put a node on the way (street) where you see the yellow zigzag lines and tag it with public_transport=stop_position. There where you have placed highway=bus_stop until now (at the pole/shelter) you tag a node with public_transport=platform. Alternatively you can also tag a way or area with public_transport=platform where the passengers effectively are waiting. The majority of mappers have mapped highway=bus_stop beside the street (like you), but especially in central Europe about 20% (continuously growing) of the nodes are on the way (at the stop_position and not the pole/shelter). So highway=bus_stop is in fact a fuzzy thing and is therefore not used anymore in this proposal. This proposal is for a more exact usage (for real public transport users). For those they want to reduce a bus stop to a single node it will be best still to use highway=bus_stop. --Teddych 06:00, 6 December 2010 (UTC)

You will get a lot more acceptance for this proposal if you include highway=bus_stop on a node next to a road as a legitimate alternative to public_transport=platform+bus=yes on a node. Anything more complex (eg marking the stop-position) should be strictly optional. A pair of highway=bus_stops either side of a track, both with the same name would probably be entirely adequate data for a typical tram stop. Relations are only really needed for places where stop names differ from the name for the whole area.--RichardMann 23:47, 9 December 2010 (UTC)

highway=bus_stop is defined on the wiki page Tag:highway=bus_stop. We do not have to redefine that. highway=bus_stop is not part of this proposal. So if this tag should be on or beside the way (stop position or platform/pole) is not relevant here. From the proposals point of view both is possible. This proposal explicitly does NOT make a suggestion. --Teddych 07:04, 10 December 2010 (UTC)
I cannot agree here. Either you accept to reuse the existing tag highway=bus_stop (and you mention it in your proposal )or you suggest an alternative where the old tag should be deprecated. What you do now is just creating a different tag. Please clarify this. I'm not against the changes, I'm against chaos. --Pieren 17:43, 11 December 2010 (UTC)
Do you mean something like the fallback-idea below? bus_stop is stop_position if on the way and bus_stop is platform if beside the way, or something like this? --Teddych 10:09, 12 December 2010 (UTC)
The fallback is needed for sure, but marking highway=bus_stop and the others as deprecated or obsolete would help reducing chaos. The highway=bus_stop wiki pages already suggest tagging both, highway=bus_stop and public_transport=stop_position. There's no use for that, this proposal should present one solution for public transport, not variants of them. People will always use variants and software developers will always need to check against all of them, but I think there will be less chaos or edit wars if there's only one, commonly accepted, new way of tagging. If people adopt the way of tagging that is proposed here, we should even thing of automatically changing the old tags to the new ones using a bot. --Errt 16:02, 14 December 2010 (UTC)

Stop position tags

I don't like train = yes/no, subway= yes/no, ... what about a tag like transport_type = train / subway / ... --wiso 15:44, 6 December 2010 (UTC)

Your idea does not work because there can be more than one type of vehicle at one stop. --Lulu-Ann 16:36, 6 December 2010 (UTC)
Just think about a combined tram and bus stop like this: --Grille Chompa 14:26, 8 December 2010 (UTC)


I suggest an email is sent to talk-transit regarding this proposal--Pobice 22:59, 7 December 2010 (UTC)

Done. Thanks for the hint. --Teddych 12:47, 8 December 2010 (UTC)


Resolved: Section station rewritten by Marl. --Teddych 06:09, 1 January 2011 (UTC)

Does a station always belong to only one stop area?

I feel that it usually belongs to a stop area group, due to the mentioned importance required to be a station. Of course, it might be just one stop area (building at the end of several routes sharing the same way).

So I propose to clarify what a station exactly is and how to include it into the whole system, such as this:

"A station is an area or building dedicated to Public Transport, containing stop positions, platforms and the highways or rails connecting them to the outside. It can be a node, closed way or multipolygon. It is added to the stop area group relation it belongs to, even if some of these stop areas are outside the station (the dedicated area). If the station belongs to only one stop area, it can be added to the stop area directly. The membership role is 'station' ".

Marl 10:33, 11 December 2010 (UTC)

I have rewritten the section about stations. A station is now a building and can not be an area (which is covered by the stop area). Is it clearer now? --Teddych 08:43, 14 December 2010 (UTC)
I can live with this, but I liked the mentioning of "area" in the original wording, because operators as well as users use the word "station" not for buildings only. That's where my "dedicated area" wording came from. Maybe the wording could be more precise, such as "building or area dedicated for boarding Public Transport vehicles, containing at least one rail track or dedicated service highway". And I think that a big roof over multiple platforms with no further function should also qualify a building (would this be a building at all?) to be a "station". And, by the way, a stop_area may have more than one station as members. This might be mentioned explicitly somewhere. --Marl 21:49, 16 December 2010 (UTC)
Would the station as an area not better be covered by landuse=public_transport? AFAK this does not exist yet but would cover better what should be expressed.--Teddych 07:47, 17 December 2010 (UTC)
That's not the same. landuse=transport is far less specific. I would use it for other things, such as a fenced area along rail tracks, marshalling or maintenance yards or depots. A station is something special, because passengers have a good reason to go there and think "that's a station". Reducing it to a an existing building would also be insufficient. If you think about bus stations, they often do have a service building. But this is exactly not the area where the platforms and service highways with their stop_positions are. The buildings are usually along one edge of such a station. --Marl 22:22, 17 December 2010 (UTC)
OK, you are right. So a station for you is primary the area where all is located. But it also can be a building, correct? --Teddych 09:57, 18 December 2010 (UTC)
Well, yes. I just would not say "where _all_ is located". From my point of view, a station has got a defined outline. The outline may or may not be a building. It can also be a fence or a green area. If the outline is not a building, buildings may located inside the station. In some cases, not 'all' is located inside the station. For example, there are often simple bus stops outside a station. Being outside the station outline does not keep them from being part of the stop area or carrying the name of the station they belong to. --Marl 10:39, 18 December 2010 (UTC)
I think I understood what you want to say, but I think I'm unable to manage this in English. Marl, feel free to rewrite the section station. --Teddych 13:24, 21 December 2010 (UTC)
Done - hope it's not too long. Tried to cover all ambiguities and input from here. --Marl 21:41, 22 December 2010 (UTC)

Tagging of some unusual routes

I think that tags from/to for route variant are useless. Everyone may extract that names from first and last members of relation.

It can be extracted from the route members, yes. For software this is easy. For humans this usually requires additional effort. --Teddych 09:24, 12 December 2010 (UTC)
You can click on first and on last member of relation and look for value with name tag.
Look on scheme for 721 route below. You will need to add from=метро Новые Черёмушки and to=метро Новые Черёмушки to the lone route direction of this route. This is absolutely senseless information. --Shurik 08:26, 13 December 2010 (UTC)
You think of a kind of ring-line. What is then the formal end for? Isn't one direction from=метро Новые Черёмушки to=formal_end and the other direction the other way round? I will make an example soon with a similar problem. Then you see how to solved it. --Teddych 09:59, 13 December 2010 (UTC)
No, this is not ring route, only part of route is ring-like. You can enter to bus before formal end and exit only after formal end. One variant instead of two will help you to make appropriate routing on this route. --Shurik 16:04, 13 December 2010 (UTC)
You enter the bus before formal end. In theory you travel to the formal end, change the bus (because it is another variant/direction) and travel to the station you want to leave the bus. In practice you do not have to change the bus, because the bus immediately continues his journey back (on the different backward route). --Teddych 06:18, 14 December 2010 (UTC)

I think anyway that from/to may be useful for master relation. Some routes may contain formal end not only at the end of route direction, but also on generic stop. Examples:

  • Route 721 has same stops at the ends of route direction (that is a lone direction of this route), but formal end is usual stop on the circle.
The bus 221 here seams to be something similar like 721 I think. It is officially a ring route, but the first three stops are identical to the last three stops. --Teddych 13:41, 21 December 2010 (UTC)
In contrast to that there is the bus 201. Officially this has two directions. But to come from Uitikon Waldegg, Bahnhof to Ringlikon, you have to take the bus to Uitikon, Wängi stay in the bus and continue/go back with the same bus but this time via Ringlikon, where you are able to leave the bus. --Teddych 13:41, 21 December 2010 (UTC)
  • Route 81 has formal end that differs from real end.
In the master relation from/to definitely does not make sense. What is from, what is to? Why not the other way round? What about lines which has a divided end? Which end do you enter? --Teddych 09:24, 12 December 2010 (UTC)
From and to is not names of dividers. They're names of ends that well-known for local passengers.
If you enter to bus on route 721 before formal end on ring, you go to "name_of_this_end" and see this name on labels as target end of route. But when you arrived to this stop, you'll see "name_of_another_end" on labels and will go to another end. You cannot extract this information from route direction relation because it contains one stop_area_group as both ends of direction.
I may suggest to add formal end/divider stop twice, with usual role and with another role as some "virtual mark" afterwards. This is another solution. Routing service program may suggest user something like "Go on bus XXX that goes in direction to _next_virtual_mark_on_route_direction_ and exit on stop _name_of_stop_after_virtual_mark_". --Shurik 08:26, 13 December 2010 (UTC)

Another usage of from/to: some routes between cities, towns and other places may be labeled like "City X - City Y" on vehicles, stops and time schedules, but really end stops may be named as "Station A (in city X)" and "Station B (in city Y)". So we can tag this route with from=City X and to=City Y.

--Shurik 12:50, 11 December 2010 (UTC)

The official naming here is always City-name, Station-name. The bus is labeled different. A bus line within a city is labeled only with the terminal station name. A bus line between cities/villages is labeled with the terminal city name. I would use the official name. In other countries/cities/networks this may be different. --Teddych 09:24, 12 December 2010 (UTC)

Tagging of unusual routes, 2nd kind

Resolved: Added to the proposal. --Teddych 10:06, 24 January 2011 (UTC)

We have a bus line crossing the city border, and it is meant for Helsinki city center - Vantaa airport traffic, but not limited to that (There's a private and bit more expensive bus line that only stops once at some hotels on the way, so it's 10-20 minutes faster). The catch with entering the regular bus line in osm is, that when boarding the bus inside Helsinki, the first stop where you can get off is only after the city border. Likewise in the other direction you can't board the bus inside Helsinki, but you can get off at any bus stop it passes. On the route section in Vantaa it operates like any other bus. Not something too important at this time given the scarcity of data for future applications, but would give false results in a journey planner if not respected. One way to store it would be a new role for those bus stops, e.g. stop_exit_only, stop_entry_only. Alv 11:32, 12 January 2011 (UTC)

I think this should be, but is not yet covered by the proposal. --Teddych 13:22, 12 January 2011 (UTC)
I have added stop_exit_only/platform_exit_only. Does an entry only make sense? Do you have an example? --Teddych 06:25, 13 January 2011 (UTC)
It's the line I took last time I went to the airport. This line has now some stops from here to the city border (and back) with those roles, and only some inside the next city to start an example. (Actually, it seems the line has nowadays 6 variants with different routes inside Vantaa - but the ref always changes (some letter suffix) if the route is different, so today we'd enter them as separate relations. The entry/exit only limit is the same on all variants.) Alv 07:59, 13 January 2011 (UTC)
I know that it's not good English, but reversing the component order to [platform|stop]_only_[entry|exit] would have advantages:
  • makes it easier to add further components. We have already appended this entry/exit_only and there may be other reasons to append something else, such as the generic filters that I proposed in generic filters for route segments
  • makes it more compatible with the turn restrictions
--Marl 22:51, 30 January 2011 (UTC)


Should it be colour=*? --Zversky 16:46, 11 December 2010 (UTC)

Resolved: Fixed now --Teddych 09:31, 12 December 2010 (UTC)


Resolved: Done in the proposal. --Teddych 09:46, 12 December 2010 (UTC)

It seems there's much discussion because this proposal doesn't mix with the old schema. But it should, and Oxomoa had written a separate chapter on that.

Just state clearly that highway=bus_stop, railway=tram_stop, railway=halt are considered stop_position when placed on the line and platform when placed besides it. Also, railway=platform is considered platform and railway=station = station.

Also, relation stop_area should be recommended, but not mandatory, when the whole stop consists of only one object (e.g. highway=bus_stop). So, route relation may include single nodes/ways as stops or platforms.

This is a good tip. Included in the proposal. --Teddych 06:25, 25 December 2010 (UTC)

BTW, what's the difference between platform and station? It's not very clear.

Now most bus route relations include highway=bus_stop with role stop. But in your schema those should have roles platform. Nobody will update hundreds of route roles, so you probably should think of a way for those relations to be relevant in your schema.

Depends on where highway=bus_stop is located: on or beside the way. And there the meanings differ. This proposal want to clarify this by not using highway=bus_stop anymore, but with two clearly defined new tags. --Teddych 06:25, 25 December 2010 (UTC)

Ways in route relations usually added with roles forward / backward depending on whether route follows across the way direction. This is useful and should probably added to your schema as recommended (but not mandatory, of course).

No, I don't. If a route is mapped according the old schema then it contains forward / backward. Anyone is free to use this also with an approved proposal. According to this proposal forward / backward is not needed anymore. --Teddych 06:25, 25 December 2010 (UTC)

You seem not to know about public transport plugin for JOSM that simplifies creating routes in Oxomoa way.

--Zversky 17:32, 11 December 2010 (UTC)

Yes, I know the plugin. I write a proposal that covers best the needs of the mappers. And this is not Oxomoa 1:1. I will never write a proposal for existing software. The software has to be written to cover the proposals and APIs. --Teddych 06:25, 25 December 2010 (UTC)

I mostly agree to the fallback principle, with some small differences and additional thoughts. I think that we just have different levels of maturity of a mapped area or public transport network coding - which changes the fallback to an evolution idea.

For highways, there are different levels of maturity as well. The OSM represenation of most highways evolves over time.

While the least specific representation (highway=road) is rarely used, most highways start with just a classification and maybe a one-way attribute. Over time, details are added, up to some traffic signs, lanes, widths and information about footways and cyle ways. The idea of one mapper mapping a certain area "properly", in a way that everything is done, is sometimes assumed on this Wiki, but it does not match with my experience. And I do the same. When I decide to improve a certain area of the map, I always concentrate on the most important things and try to cover as much of the area as I can, leaving lower priority aspects to other mappers or later visits.

It is the same here:

  • A highway=bus_stop on a highway is the lowest level of information: Some bus service stops here, probably in both directions if the highway is not one_way. Software can handle it as a stop_position with two platforms directly beneath.
  • A highway=bus_stop besides a highway is slightly more information. It tells us about where the pole is (in most cases where the two poles are) and the side of the highway gives us an indication about the direction. When handling this information automatically, some software heuristics can place a corresponding stop_position onto the nearest point on a highway for each pole and even combine several highway=bus_stop with the same name within a certain distance to a stop_area_group for further processing.
  • Mappers with more interest, time or experience can add detail to this information as appropriate, converting one or more highway=bus_stops into stop_area relations with their stop_positions and platforms and combine related stop_areas to stop_area_group relations.

So I think that both schemes have their value (on their respective maturity level) and are compatible enough to co-exist. The important thing is to have a clear common understanding about the relation between the two schemes. This is my proposal for that relation.

--Marl 09:00, 12 December 2010 (UTC)

stop_area vs. stop_area_group

Resolved: Fixed in the proposal. --Teddych 09:02, 14 December 2010 (UTC)

In the description of a stop_area, it is mentioned that a stop_area is about "the stop_position" and "the platform". I feel that the author meant a stop_area can contain only one stop_position and one platform. If we think about precise pedestrian routing, it might be a good idea not to have more than one platform in a stop_area, in order to route the passenger to the correct platform. However, the routes contain both stop_positions and platforms, so the restriction is not really needed.

Several platforms and stop_positions are allowed per stop area (each direction has a separate platform and can have separate stop positions). This is fixed in the proposal. --Teddych 09:02, 14 December 2010 (UTC)

When it comes to a stop_area_group, the author talks about combining several stop_areas "each representing a ... station". OK, if it is a train station with only one platform, it's alright. But nearly every bus stop needs two platforms (one for each direction), so it consists of two stop_areas that will probably form a stop_area_group, if I understand it correctly.

Both directions of a bus line come into the same stop area. They have the same UIC reference (at least in switzerland). --Teddych 09:02, 14 December 2010 (UTC)

Am I wrong with this? If so, I guess that the stop_area description should use a plural form of "stop_position" and "platform".

Is fixed in the proposal now. --Teddych 09:02, 14 December 2010 (UTC)

And if I am wrong - what are stop_area_groups needed for? ... and what exactly is the difference between a stop_area and a stop_area_group?

--Marl 09:37, 12 December 2010 (UTC)

One stop_area can contain more then one platform/stop_position (to be fixed in proposal). Rule of thumb: Everything that has/belongs to the same station name is in a stop_area. --Teddych 10:03, 12 December 2010 (UTC)
Stop_area_group: Think of the example of a train station with name Mainstation. In the north there is a bus station with name Mainstation North and in the south one with the name Mainstation South. the three stations are represented with three stop_area relations. The stop_area_group relation contains the three stop_area relations. --Teddych 10:03, 12 December 2010 (UTC)

... or like this example
4 stop_positions (4 platforms inside pedestrian not yet mapped there)
2 stop_positions are stop_group "Marktplatz (Pyramide)", 2 stop_positions are stop_group "Marktplatz (Kaiserstraße)"
all 4 stop_positions are stop_area_group "Marktplatz"
route 2, 5, S4, S41 stop 2x, rest stops 1x at Marktplatz
--Mueck 17:04, 14 March 2011 (UTC)

Shared Route Segments

I remember a former discussion about shared route segments somewhere else and I liked the concept. The other discussion ended with "good concept, but the existing software doesn't support it". As most of the stuff we are discussing here ist unsupported by current software as well, I think it is worth trying to fit it into the current proposal status.

Most routes share segments, especially after splitting up the directions and variants of routes and recombining them to route masters.

In general, it is a big effort to keep the way parts of routes complete. Splitting them up multiplies that effort, so I think that we need a well organised sharing of route segments.

Of course, in the current age of roundabouts, most bus routes even in small towns cannot share the whole way even for both directions of the same route.

That brings me to a concept of a generalisation of shared route segments with variants. Of course, real route variants should be combined out of multiple route segments, but minor things, such as different parts of the same roudabout, should be handled by a route segment variant.

What about this:

A route can contain ways as usual, but also other relations with type=route_segment. The membership role would be "forward" if the parts of the route_segment are to be included in the order of appearance in the relation. The membership role would be "backward" if the route segment relation is included in reverse order.

The rules of filling a route segment are nearly the same as for routes, with some exceptions:

  • They do not have to be complete, because they are just part of the routes.
  • Members of route_segments may be marked with conditions. While such a condition concept is probably extendable, the conditions I have currently in mind are coded by appending _only_forward or _only_backward to a stop_position or platform membership role, similar to the coding of turn_restrictions. For conditional way members (most of them will be roundabout parts or other one way roads), the leading underscore is omitted, because their initial role is empty and the condition is the only part of the role.

Co-existence with "old" routes with their forward and backward membership roles would be possible. The old roles do not filter. This difference is visible to mappers, because they have no "only" in their role name. Software would not be confused anyway, because it would recognise old routes from their "forward/backward" way role memberships.

This would save a huge amount of work for mappers and I think it is not too complicated.

--Marl 10:43, 12 December 2010 (UTC)

The idea is great. I thought about route segments too. I have the concrete problem that the first 5km five bus lines share the same way through the city. Outside the city the bus lines take different ways. It would make sense to use a shared route segment. My concrete problem is, what to enter in the ref field? --Teddych 11:46, 12 December 2010 (UTC)
I don't attach a ref field to the route segment, because only the route master gets the ref tag (or the route, if the master proposal is going to be rejected). In the same way, there is no need for a route segment to have a "from" or "to" tag. The only thing that it really needs is a "type" tag. The route segment just contributes way elements and maybe more to a route ... so another probably important tag is "notes", so that others can understand the intended use of a route segment. For example, if such a segment contains only ways, while the corresponding stop_positions and platforms are combined in a different relation, other mappers should know that and not try to add these things. However - if the common way has got an official name or ref (assigned by the network operator), nobody stops you from adding this attribute to the segment. Of course, this information cannot be inherited by routes, because their references would be completely different. --Marl 13:11, 12 December 2010 (UTC)
I personally think it is a good thing and I already use it in practice. But I'm not sure if it is better to put it into a separate proposal. This proposal is already big enough, I think. What do think others? --Teddych 09:07, 14 December 2010 (UTC)
I began a new proposal that allows to split routes: Proposed_features/Route_Segments. Feel free to discuss/add there. --Teddych 10:02, 24 January 2011 (UTC)


I got the hint to add an example into OSM. I will do that hopefully very soon. --Teddych 09:45, 13 December 2010 (UTC)

What belongs to a stop_area_group?

Resolved: Removed from the proposal. --Teddych 10:01, 24 January 2011 (UTC)

"A stop area group is the combination of several stop areas where passengers can walk from one stop area to the other for changing train/subway/monorail/tram/bus/trolleybus/aerialway/ferry"

The whole city is a "combination of several stop areas where passengers can walk from one stop area to the other", if the only just walk long enough. ;-)

This is a misconcept overtaken from these restricted database based eletronic timetable services, which consist of no own geodata to find the next transportation service nearby. --Fabi2 10:45, 14 December 2010 (UTC)

Would you leave completely away the stop_area_group? --Teddych 19:21, 14 December 2010 (UTC)
This is no easy question. The only time I used stop_area_group was associate a additional amenity=taxi to a bus station, as it was one lane of that bus station and as it is done in the example on the German Oxomoa-Scheme page. At least it is not needed to specify where you can change trains to. But a router can also easy get, that there is a taxi stand nearby. If the platforms are right connected to the footways, then routing to the the platforms nearby should be no problem. So I also decided, that everything with the exactly same name=* belogs to the same stop_area. Maybe the stop_area_group can be used to group additional features, which are not direct belonging to the stop_area. If for a station, the stop_area consists of the platform and the stop_positions, to what belongs such things as a subway entrance? Maybe it can be used for such additional station fatures, but where then to stop? For example if there is a station building, some shops inside the building and a telephone and taxi stand on a highway=service before it? --Fabi2 19:54, 14 December 2010 (UTC)
I personally do not add taxi or carsharing into a stop area or stop area group. If it should be called public transport depends of the point of view. --Teddych 16:29, 15 December 2010 (UTC)
When thinking about it, I also can't find a good reason for a stop_area_group. I had three candidates in mind: "Hamburg Hbf" (Central Station) with two connected underground stations ("Hauptbahnhof Süd" and "Hauptbahnhof Nord") and the central bus station ("ZOB"). The second candidate was the Hamburg underground stations "Jungfernstieg" (three lines from different operators in total) with connected bus stops and the linked underground station "Rathaus". The third candidate was London Paddington, the mainline station with two connected underground stations and several bus stops around it. Looking into all of them with all is said here in mind, they have only one thing more than other stations in a comparable distance: The network operators recommend these places to interchange between Public Transport systems. They do it on maps and through guidance along the connecting footways. In Hamburg, there are also special pedestrian tunnels, so they feel a little bit more like one station, despite of the considerable distance. However, when routing people, this apparent optimisation often turns out to be wrong (in my first example, in many cases, it makes much more sense to change at Berliner Tor instead of Hauptbahnhof; a good router could find it out directly, giving a correct coding of the stop_positions and platforms, because the lines sharing one platform in one station and being hundreds of meters apart from each other in the other station). So at the end, I feel that we don't need stop_area_groups - at least until somebody comes up with a convincing example. --Marl 23:00, 14 December 2010 (UTC)
I did not ask the original Oxomoa authors about their thoughts. Until now I used different stop areas when there where uniquely UIC references and different UIC names. All what is defined by the operators for changing between the uniquely UIC stations is combined within a stop area group. Your are right a router can do it probably better then a mapper. --Teddych 16:29, 15 December 2010 (UTC)
My above example is the bus station "Bahnhof Süd" which is beside the train station "Greifswald Süd". These tunnels for changing trains are also often found in Berlin. They are there between different subway stations and mostly to connect the subway with the light rail. If we get them mapped and can connect the subway entrances in some kind, we don't need the stop_area_group. The subway entraces can also be found by a distance search done by the router, but this works not for two or more stations with intermixing entrances. --Fabi2 14:56, 15 December 2010 (UTC)
I do not have experience with subways, but I think they have their own UIC reference/name. The router does not have to find the entrance of the subway it has to find the platform of the subway (via entrance). --Teddych 16:29, 15 December 2010 (UTC)
Yes, you can not get routed to the platform without the router is also knowing the subway entrance tunnels beside the subway entrances on street level. So I think, we don't need public_transport=stop_area_group any longer. --Fabi2 22:29, 15 December 2010 (UTC)
Is this another example of our maturity/fallback problem? Do we need stop_area_groups only where there is a lack of footways on the map? --Marl 21:53, 16 December 2010 (UTC)
Some personal comments about both higher groupings of stops (whatever they are called) and Paddington.
  • The NaPTAN import did include data equivalent to stop areas and stop area groups where the relevant transport authority defined them. These are visualised on OePNVKarte, but at too high a zoom level to be conveniently seen. My impression is that there are many errors in these data sets. Most appear to be administrative/planning in nature rather than reflecting the rather dynamic perceptions of passengers using stops in a particular vicinity which may be affected by any number of parameters (time of day, personal comfort, luggage, service frequency etc.).
  • Paddington,as already noted above, exemplifies this well. In practice it has two separate underground stations, both called Paddington Station, but a transfer from the Hammersmith & City platforms to Bakerloo/District/Circle line platforms is a significant walk and involves at least two stairways. If I am carrying bags I will use completely different services, stops and routing. The recent change in Circle Line trains service pattern (circle to spiral) affected how I travel through Paddington. Similarly anything which does not include Lancaster Gate within any Paddington stop area group would be erroneous. Journey times to the City of London can be shortened by 15-20 minutes by walking from Paddington to Lancaster Gate and using the Central Line. So, in summary, the more sophisticated data we add will enable finely tuned routing decisions which will be much more flexible than some a priori grouping of stops. Furthermore I suspect these groupings probably change fairly frequently if they are used for planning transport provision, and we will then have a sourcing problem: given that we have access to the data in the first place. SK53 23:35, 15 December 2010 (UTC)
oops, a second stop_area_group discussion ... One example of oxomoa-group see above, a second one is this one: --Mueck 17:20, 14 March 2011 (UTC)

Where to put the stop_position node?

Resolved: Added an example to the proposal. --Teddych 06:06, 1 January 2011 (UTC)

Some bus stops have a small service way, which separates from the highway, before their platform. The bus stops along these service way besides the street. Where exactly on these service way the public_transport=stop_position should be placed? Should it placed in the middle of the stopped bus, besides the pole or on a other position? It should also be specified in the proposal, that every in reality existing stop position must be tagged seperatly for it's own. --Fabi2 23:20, 15 December 2010 (UTC)

public_transport=stop_position has to be be put on the highway=service-way in the middle of where the bus stops. The pole would be tagged with a public_transport=platform-node beside the way, or alternatively the platform with a public_transport=platform-way/area. --Teddych 08:40, 16 December 2010 (UTC)
I have added an example to the proposal: Relation 1283483 (iD, JOSM, Potlatch2, history, analyze, manage, GPX, XML) --Teddych 06:06, 1 January 2011 (UTC)

Compatibility List - bus stops on highways

Resolved: Clarified in the proposal. --Teddych 18:41, 20 December 2010 (UTC)

I like that list. However, as we have reached a good detail level now, there is a pitfall: Some highway=bus_stop on highways are actually platforms, not stop_positions. This is obvious if the bus_stop is on a footway. Unfortunately, the border between the two is not absolutely clear. My proposal is to interpret it as a stop_position when bus traffic is allowed on that way (which includes service ways and tracks and excludes footways, cycleways and paths). --Marl 22:00, 16 December 2010 (UTC)

This is an important detail. I am not sure about the tracks. I would exclude that. --Teddych 07:54, 17 December 2010 (UTC)
Having thought about your response over night, I know now why I proposed to use the criteria "allowed on that way". Simply because I felt uncomfortable starting to create an own criteria list that in doubt will not be complete. The track was my original example. For that one, I thought "there probably will be no stop_positions on tracks, so it doesn't matter ... OK ... if so, it must be a track inside a natural reserve with a bus service for hikers -> another match". But there will be more surprising combinations that I tried to avoid to clarify explicitly. That's why I proposed to delegate this case to where it was solved before - the "on ways where buses are allowed". And I found another example where this approach works: A highway=pedestrian with PSV=yes. A delegation to "where buses are allowed" automatically puts it in the right place. It's all about avoiding to reinvent the wheel. --Marl 11:01, 18 December 2010 (UTC)
I added beside/on the way/street where the bus goes through. I don't know if it is good english, but I think it covers your suggestion. --Teddych 18:41, 20 December 2010 (UTC)
That may or may not be interpreted as a totally different approach. We are back to the maturity level of a mapped route here. Your proposal works well where all bus routes near or via the node are already mapped correctly. It does not work well if the route memberships are incomplete. For example, if we have a highway=bus_top on a highway where the highway itself is not member of a route relation. That would make the node a platform instead of a stop position, as soon as there is something nearby that the interpreter (may or may not be software) considers to be something a "bus goes through". This interpretation is based in preferences. The decision might be made from existing route memberships or one of the proposals above (special highway types or PSV access). So different routers may produce different results. --Marl 23:13, 20 December 2010 (UTC)

The new compatibility list contains examples that I was unaware of before. I considered only nodes being tagged as highway=bus_stop, not ways. I think that the differentiation "where buses are allowed" should apply for both nodes and ways.

This is my new proposal:

Node on a way where buses are allowed stop_position
Node not on a way where buses are allowed (avoids any doubts about what "beneath" means) platform
Way on a way where buses are allowed not discussed before; the natural solution might be a stop_position in the middle
Way not on a way where buses are allowed Platform

--Marl 22:04, 22 December 2010 (UTC)

Where did you find highway=bus_stop as a way? highway=bus_stop is designed to use as a node. If I used highway=bus_stop as a way this is a mistake. --Teddych 06:10, 23 December 2010 (UTC)
Oops, sorry - I didn't realise that the tag name is "amenity" in some of the lines, just assumed that it's always highway. I thought that the only difference between the lines was "tagged as node" and further assumed that you found a lot of platforms tagged "highway=bus_stop". Having said that - why should we distinguish between highway=bus_stop and amenity=bus_stop? --Marl 11:29, 24 December 2010 (UTC)
Where did you find amenity=bus_stop? Did you mean amenity=bus_station? --Teddych 05:50, 25 December 2010 (UTC)
OK, you are right. I was so much focused on the right that I still didn't remember the left side correctly. So I paste it in this time: "amenity=bus_station tagged as node on a way/street". I think that this should be handled the same as "highway=bus_stop" --Marl 08:27, 25 December 2010 (UTC)

stop_area with multiple names

Resolved: Added to the proposal. --Teddych 06:42, 24 December 2010 (UTC)

company A operates a bus line which stops at a specific stop area and calls the stop "Stop X". company B operates a different bus line which also stops at the same stop area but calls it "Stop Y". how should this be handled?

i would suggest that, if there is a name displayed at the physical location, than this should be mapped as "name". if there is no name displayed, the name should be used that the operator of the stop area uses. other names should be tagged with "name:<network-name>"

another alternative would be to use multiple stop area relations on the same elements (stop position, shelter, ...). but how should a render handle multiple stop area relations at the exact same location?

i can't imagine that i'm the first one with this problem. how do you handle this in your area? --flaimo 23:23, 23 December 2010 (UTC)

Note that there may also be multiple names. For example has separate poles, one for each operator (but the Lynx one to the right has no name, since Lynx doesn't publicly name their stops). --NE2 23:23, 23 December 2010 (UTC)
I have added this to the proposal. --Teddych 06:42, 24 December 2010 (UTC)

Below the Surface

Having just mapped an Underground station (which happened also to be under ground) and seeing Mapnik unable to render it well, I became aware of missing information.

To render covered things correctly, software must have a chance to know that they are covered. This is obvious as long as something is layered above it. But in many cases, there is nothing like that. Landuse is an information about how an area is used in general. It does not cover anything.

That's what covered is for. I have included it into my station proposal. And I think it should also go into the platform part.

Done also for platform. I removed the recommendation to map also entrances/tunnels correct. I think this is obvious (even if it is not always done). --Teddych 06:03, 25 December 2010 (UTC)
Yes. And I already felt that it doesn't belong into the table. However, I saw this as an easy way to make people aware that surface level entrance buildings are different from a covered station and must be handled somehow. The easiest way is to map them as a different building. A more sophisticated way is to map the station as a multipolygon consisting of covered and on-surface parts. The entrance buildings can be considered to be part of the station or outside. I have a small preference for outside. Back to the main point: Do you think it's worth mentioning? ... and if so, where? --Marl 08:35, 25 December 2010 (UTC)

It is not needed for footways or rails in tunnels, because tunnels are covered by default.

By the way, Mapnik still doesn't render that station well. However, a parking lot covered by a park look really nice. But fixing that is up to the Mapnik developers.

--Marl 12:30, 24 December 2010 (UTC)

Redundant Tags on Stops, Platforms, and Stop Areas

Resolved: Clarified in the proposal. --Teddych 06:03, 1 January 2011 (UTC)

Some tags, e.g. name, operator or uic_ref are listed for several elements of a stop. Most prominent is the name tag which is used on stop_position, platform, and stop_area. In your first example you actually put the stop's name on all 3 elements. Is this redundancy intended or even mandatory? It could cause inconsistencies, particularly because the correct name of a stop is often in dispute between platform operator, sign maker, bus line operator, timetable author, mapper A and mapper B. On the other hand, having a name tag makes work in the relation editor easier because a node is identifiable by name.

Some recommendations might clarify things. For example: The name of a stop must be defined on the stop_area relation, it can optionally be added to the stop_position and platform. --MetiorErgoSum 13:19, 26 December 2010 (UTC)

I inserted a new row recommendation, to clarify what is when needed. Hope this will solve most of the questions. I will use the tag name always on stop position, platform AND stop area, because then JOSM presents the members of a relation by that name. Theoretically it is only needed in the stop area. --Teddych 06:03, 1 January 2011 (UTC)
Makes sense to me. Possible inconsistencies like different names might even be corrected automatically in the future. It shouldn't be too difficult for consistency checking programs like OSM Inspector to uncover those types of problems. --MetiorErgoSum 10:03, 4 January 2011 (UTC)


  • If there are inconsistencies, they show exactly what is found on site.
  • The virtual feature stop area's attributes reflect the attributes shared by most of its members.
  • If a stop area has got an attribute, it is inherited by all its members that do not redefine the same attribute.
  • If one stop_position/platform pair has got a totally different name, it should be a different stop area.
  • If all members of a stop area share at least "(network AND (name OR ref)) OR uic_ref", then there is no need to add a stop_area at all
  • If all members of a route_master share at least "network AND route AND (name OR ref)", then there is no need to add a route_master at all

The last two points might lead to trouble if network names are not unique. Today, Google showed six different networks named "KVG" on the first result page alone (Kiel, Kassel, Stade, Braunschweig/Brunswick, Aschaffenburg, Zittau). ... which from my point of view does not so much support a need for stop_areas and route_masters, but for "network" relations, containing all routes of a network and probably a bounding box. --Marl 12:18, 27 December 2010 (UTC)

I hope my changes cover most of your proposed ideas. With the two last points I am not happy. --Teddych 06:03, 1 January 2011 (UTC)
Yes, they do cover my ideas, including the last two points (need for a stop_area or route_master). Some attribute duplication is needed until the tools (renderers and editors) support inheritance from relations. So you seem to be unhappy just about my formula language. Or do you mean the network relations? --Marl 00:03, 2 January 2011 (UTC)
If someone omits stop_area, stop_area_group or route_master (with identical network and so) I do not have a problem with that. But I would not recommend to omit, like I read your proposal. --Teddych 05:45, 2 January 2011 (UTC)

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
    • 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)


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.
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)


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)


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)


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
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: --Mueck 14:44, 15 March 2011 (UTC)


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)


searching for IBNR in wiki shows, that someones propose to add IBNR as uic_ref=... for local public transportation using but this site not only return uic_ref with 7 digits, but also IBNR outside UIC numbers with 6 digits. Comparing and shows, that uic_ref is widely used, for ibnr there is no widely used tag ... This service seems to use different taggings: Seems to work also tagged with uic_ref only with correct UIC and olso with ibnr-only uic_ref 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

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)
See also Use proper typography in Route names

Custom tagcheck for JOSM Validator


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 Node 30000199 (iD, JOSM, Potlatch2, history, XML).

Imaging that we have a new-style route like Relation 1244886 (iD, JOSM, Potlatch2, history, analyze, manage, GPX, XML), which contains one direction like Relation.png Bus 201 (XML, JOSM, osmose, sketch-route), but which includes the way Way 26127215 (iD, JOSM, Potlatch2, history, XML) twice in both directions.

The route stop Node 30000199 (iD, JOSM, Potlatch2, history, XML) participating in the way Way 26127215 (iD, JOSM, Potlatch2, history, XML) then also should be included into the route direction twice, followed by two different platforms, Way 89550242 (iD, JOSM, Potlatch2, history, XML) in one direction, and Way 89550243 (iD, JOSM, Potlatch2, history, XML) in another one.

In this case, we can't directly determine, what inclusion of the stop Node 30000199 (iD, JOSM, Potlatch2, history, XML) into the route direction corresponds to passing the way Way 26127215 (iD, JOSM, Potlatch2, history, XML) 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 Way 89550242 (iD, JOSM, Potlatch2, history, XML) and Way 89550243 (iD, JOSM, Potlatch2, history, XML) 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:

  1. tourism=yes (for routes that are not general purpose transport, e.g. amusement park loops or pure scenic loops)
  2. grade_separation={full,partial,none}
  3. tracks=2-4 (Typically two track line with passing tracks. The IRT express lines in NYC would be tracks=4-4)
  4. average_speed=45 (this is the key key for routing)
  5. maximum_speed=80 (this is the key key for routing)
  6. 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 Relation 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 Relation 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)

see also Proposed_features/Headway

"Headway" is a common term. --NE2 18:34, 6 December 2011 (UTC)
headway looks nice and common. I updated above --MichalP 16:51, 10 December 2011 (UTC)
Why "routeheadway" rather than just "headway"? (By the way, I've been using a generic "headway" tag for the standard midday non-rush headway on local routes.) --NE2 05:06, 11 December 2011 (UTC)
"routeheadway" was from frequency (which is used for different purposes), upgraded. --MichalP 20:00, 11 December 2011 (UTC)
above headway is in minutes, which is suitable for most city buses, however long distance buses have headway of several hours. should there be a 'm' or 'h' suffix (eg 8m and 2h and off) ? or long distance buses should use numbers like 300 for every 5 hours ? --MichalP 20:00, 11 December 2011 (UTC)

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)

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:

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         \
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 !
                 |         ^
                 |         |
                 v         |
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 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:
                |         |
                |         v
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).
 A -----------> B ----------> Y --------->+ Z
                         exit_only     no_passengers
 A -----------> B ----------> Y ........... Z
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.
 A -----------> B .......>.........> Y--------------> Z
            exit_only            entry_only
               |                    ^
              (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

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: Way 449095206 (iD, JOSM, Potlatch2, history, XML).
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)