Talk:Proposed features/Differentiation for routes of public transport

From OpenStreetMap Wiki
Jump to: navigation, search

prefix namespace

I like the new proposal. but did you need to prefix all key with a namespace ? for exemple score=national on a route relation is not enought ? Marc CH 26 octobre 2017

Thanks for removing the prefix for scope. The same should be done for stopping_pattern and service_period ? Marc CH (talk) 18:43, 13 November 2017 (UTC)
I agree. Long keys provoke mistakes, and these don't clash with anything. --Zverik (talk) 12:04, 25 November 2017 (UTC)
I was commenting on the same thing. Is there any reason to use public_transport:stopping_pattern=* instead of stopping_pattern=*? --AgusQui (talk) 17:32, 25 November 2017 (UTC)
I agree. Will change that. --Ialokim (talk) 19:53, 6 December 2017 (UTC)

My 0.02€

I understand the issues raised by the proposal, and I agree with the fact that additional tags should be used. However, I have a few remarks and suggestions to make.

  • As the previous comment says, I don't see the need of prefixing scope by route. The tag scope=* looks sufficient to me. Another concern is about the 'porosity' between scope classes... but this is more detail.
I agree with these comments and you are right, scope=* should be enough. There are only 20 occurrences up to now: TagInfo scope=*
  • I dislike the tag public_transport:stops=*. First, its key does not really correspond to what it aims to mean; and second, the proposed values are insufficient to express every line. (I was, in particular, thinking about a bus shuttle between an airport and a city, which stops at several points in the city). However, I see the precision you would like to make. I then suggest the following: stop_frequency=*, with values: direct (no intermediate stops at all), semi-direct (few stops along the way), main_stops, and all_stops. Maybe this needs refinement in parts on the route... but I don't see how this can be set into the current public transport scheme.
I understand your concerns regarding the key name and the values and I like the idea of stop_frequency=*, however your two first values does not really correspond to the key-tag either. What do you think about stopping_pattern=* with non_stop, main_stops, limited and all_stops?
I thought of public_transport:service_period=* to avoid confusion because service=* is currently used similar to the proposed public_transport:type=* (mostly for railways). And I didn't want to propose the same syntax as opening_hours, because timetables are simply to complex to be described in OSM and does not belong there either. There are other formats as for example GTFS to combine map and timetable data (see osm2gtfs for a work in progress). I proposed public_transport:service_period=* mainly to differentiate only-night form regular day transportation services.

--Bibi6 (talk) 20:43, 30 October 2017 (UTC)

--Ialokim (talk) 15:08, 2 November 2017 (UTC)

Route vs Route_master

Many properties described in this proposal are about the public transport line. They should therefore be added to the parent route_master object instead of the many route relations objects.

--Singing-Poppy (talk) 16:55, 2 November 2017 (UTC)

I agree for some cases, for example scope=* and public_transport:type=*, but there are indeed lines which have express and normal services or lines with different night services too (see my answer to your other thoughts). It should be possible to add these tags proposed here to type=route and/or type=route_master.
--Ialokim (talk) 22:31, 8 November 2017 (UTC)
The word route_master does not appear in the page. If your proposal adds tags that can be set on route and/or route_master, you should write that in your proposal. Singing-Poppy (talk) 15:50, 12 November 2017 (UTC)
I've now adapted the proposal page to include your concerns, please check it. --Ialokim (talk) 18:08, 13 November 2017 (UTC)
Good for me, thanks ! Singing-Poppy (talk) 18:49, 14 November 2017 (UTC)

More precise tagging

Singing-Poppy (talk) 16:56, 2 November 2017 (UTC) :

Some values are still quite white and black

public_transport:type=school is too vague : if I'm not a student, can I use this line ?

Here is an alternative proposal (already listed in the route_master page)

In this case, wouldn't it be better to have one type=route_master with ref=4 and four children:

We may need the same distinction with the public_transport:type=on_demand lines :

In this case, it would be:

And this applied also for

  • by_night = yes/only
  • tourism = yes/only
Similarly for these cases.
I don't like these values you proposed because they aren't very clear (I'm not sure if everybody understands that yes is not only if they are not very familiar with this tagging method?)
--Ialokim (talk) 22:31, 8 November 2017 (UTC)
I must agree on that : the yes vs only distinction is not very clear. But still clearer that only public_transport:type=on_demand (or night, or tourism, etc)... -- Singing-Poppy (talk) 16:02, 12 November 2017 (UTC)
Plus : I think the route_master should always be tagged, even if only some routes are concerned. If a OSM data user want to make gather the lines that have on_demand services (or school, or night, etc), they should not have to get the OSM routes and do some magic to group them and guess how many lines are concerned. -- Singing-Poppy (talk) 16:02, 12 November 2017 (UTC)

Why not

  • public_transport:type=on_demand
  • on_demand = partial / only

Singing-Poppy (talk) 16:02, 12 November 2017 (UTC)

I've now adapted the proposal page to include your ideas, please check it. --Ialokim (talk) 18:08, 13 November 2017 (UTC)
Why not adding a few more examples (Mobicaps 4, R61 and F8) in your example section ?
Done :) --Ialokim (talk) 03:15, 15 November 2017 (UTC)
Thanks. Singing-Poppy (talk) 19:32, 15 November 2017 (UTC)

exclusive tagging

This is just a quick observation going over this, but I noticed the in my opinion not so handy tagging for the exclusiveness of a route. The proposal states:

Example: School buses that are only for the school children vs. open to all public:

   public_transport:type=school + school=exclusive
   public_transport:type=school + school=not_exclusive

However, this means that each public_transport:type=x will need its own key to specify exclusiveness. Not only school=x, but also regular=x, factory=x etc. This is not handy, and in addition, the key names (e.g. "school","factory") say nothing about the contents of the tag. I think it would be better to adopt the more logical and clearer scheme of

   public_transport:type=school + exclusive=yes/no

This way, only a single key needs to be checked to know if the route is exclusive, and the key name actually reflects its contents, instead of vague "school","factory".--Mboeringa (talk) 16:33, 26 November 2017 (UTC)

You are very right, I'll do this change :) --Ialokim (talk) 19:52, 6 December 2017 (UTC)

stopping_pattern values

  • I suggest to add the following value to the key stopping_pattern=on_demand. This is for vehicles that can be stopped at almost any place, not necessarily on official stops. This is often times the case in more informal transit systems and/or on over land bus lines. --Xamanu (talk) 11:15 10 December 2017 (UTC)
I think that's the same idea as behind this proposal). I'm not sure which one is better as the other proposal adds the ability to only mark a part of the route as "hail and ride". --Ialokim (talk) 19:47, 5 January 2018 (UTC)
+1 Where I live there is a network in which buses can be hailed anywhere in some locations but only at designated stops in other locations, within the same city. --Fernando Trebien (talk) 18:06, 10 January 2018 (UTC)
on_demand is imho not the same as "hail_and_ride".
on_demand mean that the bus stop at a stop only if people request it. maybe it's better to have another tag like on_request=yes because you can have it for all stop_pattern.
hail_and_ride (or maybe stopping_pattern=everywhere) mean that the bus can stop everywhere if people request it
Marc marc (talk) 22:49, 10 January 2018 (UTC)


This needs some more specification, in my opinion. The values are pretty extensive and targeted to different purposes.

Those make a lot of sense to me:

Those are not fitting the idea of the 'type' in my opinion. This becomes more clear, if you think about exclusiveness. Can't a line be perfectly public_transport:type=regular and public_transport:type=tourism? So, they don't seem to be 'types' to me, more like purpose (or maybe some other wording):

I got your point regarding the unclear key name, but can't follow your argumentation about the exclusiveness: I've thought of public_transport:type=regular as a regular public transport service, dedicated for all sort of passengers, while public_transport:type=tourism would be public transport services dedicated only for tourism. In which cases would you tag both? Btw, on the Buses' Talkpage was raised another idea of tagging those, namely with the key passenger=*. What do you think?

Those are also not fitting the idea of the 'type' in my opinion. They are more around services on top that are provided on certain lines:

I would suggest to remove the from the proposal, or give them a separate tag.

I've included them to generalize all public transport service mapping and support all the values currently used by type=* on railway routes. We could indeed think about renaming them to give a clearer name, if you have some ideas?

This on is also not fitting the idea of the 'type' in my opinion.

It is on classification of the route, not it's 'type', or is it on the fewer stops? Then it seems to be a duplication of stopping_pattern=main_stops

Same idea as above, to support current railway conventions. But if you think that we wouldn't loose information removing it, I'm fine with it.
--Ialokim (talk) 20:05, 5 January 2018 (UTC)

--Xamanu (talk) 11:15 10 December 2017 (UTC)

Similarity between scope and network

Cycle routes use network=lcn;rcn;ncn, hiking routes use network=lwn;rwn;nwn and horse routes use network=lhn;rhn;nhn for the same function as the proposed scope tag. Maybe these tags could be somehow merged in a single tag that expresses the same idea. --Fernando Trebien (talk) 18:19, 10 January 2018 (UTC)