Proposal talk:Public Transport/Archive 2010

Funicular

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: http://www.bus-bild.de/name/einzelbild/number/10770/kategorie/Bustypen~Stadtbusse~Mercedes-Benz+O+405++(Hochflur-Stadtversion).html --Grille Chompa 14:26, 8 December 2010 (UTC)

Talk-transit

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)

Stations

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)

color

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

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

Fallback

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 http://www.openstreetmap.org/?lat=49.0094&lon=8.404&zoom=18&layers=M

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)

Example

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: http://www.openstreetmap.org/browse/relation/140238 --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: 1283483 1283483 --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 http://media-cdn.tripadvisor.com/media/photo-s/01/03/ca/e1/i-trolley-stop-at-maingate.jpg 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)

Proposal:

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