Proposal talk:Differentiation for routes of public transport

From OpenStreetMap Wiki
Jump to navigation Jump to 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)

public_transportːtype

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)


Vot?

when we started the voting? --AgusQui (talk) 17:39, 30 March 2018 (UTC)

Many proposals and real expirience

It is the good proposal. I wanted propose anything such, but i hadn't time for such work. But i try used the analogical scheme, when i inserted the routes in Ekaterinburg city, Russia into the OSM DB. You can see the results.

Main problems, i finded

1. The classical schema don't allow to draw the routes on the maps beautifully (the dirty points of the urban routes in the cites and a empty space around isn't good picture), to select the urban, intercity and long-distance routes in the reference and navigation applications and to make a color differentiation of the routes on the maps. Although a commuter electric train and long-distance train is very different types of the transit it are simple trains for OSM.

2. Also there is a great problem of the showing of the stops. The current Mapnik style is useful for the stops of the urban transit. For intercity and even commuter transit it isn't comfortable. You must use 16-th zoom to find the bus stop. There is a distance between two neighbor stops can be up to 40 km in Russia. And the user must scroll map during a very long time to find the stop.

I want propose:

1. Instead of the tag "public_transport:type" use a tag "service". It is useful for a compability with a German railroad taging schema and with the our data. This tag is more short and understood. Also it must be mandatory with default value “urban”. It allow to separate the routes with a different purposes and a law statuses. It must have a values "urban" (default), "commuter", "regional", "long_distance" and "hign_speed" but nor "regular". "Regular" can be a value of a "service_period" tag. This values make the route description in the on OSM DB similar with a official status. Also it make a "scope" tag non-mandatory. The render or the navigation application can understand a scope of the regular PT route by its type. For non-regular routes ("tourism", "post", etc) a "scope" tag is useful.

2. A "service" ("public_transport:type") tag must used for stops too. It will allow to show the stops for a different transit types on the different zoom and filter its. It is very important and for tourist, factory and post routes. The stops for this types of the routes can be filtered by the render or navigation application. A support of the "service" tag for the stops is realized in the CustomizePublicTransportStop plug-in for JOSM.

3. For a routes ("route" and "maser_route" tags) i can propose a "vehicle" tag. This non-mandatory tag is useful for a navigation applications for showing the picture of the vehicle for the user. It can have a values "tram", “trolleybus”, "full_size_bus", "minibus", "midibus", "coach", "electric_train", "commuter_train", "passenger_train", etc or few such values by comma.

Also a shared taxi route is not a bus route. This is a separated type of the transit but not type of the bus purpose.

1- I understand your point, but the problem is that service is used for many things and gives rise to confusion, besides its use in the train scheme has not been formally approved and does not even have its own wiki. --AgusQui (talk) 14:12, 18 September 2018 (UTC)
I like the idea to use public_transport:type=* (or service=*) for the stops, too. That is really something we need. But I also agree that using service=* would overload the many different values and meanings of this key, so we might need another (like public_transport:type or whatever). --Lukas458 (talk) 20:57, 14 April 2020 (UTC)

Voting and implementation

Are there any efforts to vote and implement this proposal? It was introduced almost three years ago, there was some debate but no final decision, apparently.

I have included some lines of the public transport system in the Metropolitan Region of Rio de Janeiro and some of the suggestions here would be really useful for some routes.

--Guilherme B Alves (talk) 23:11, 26 April 2020 (UTC)

Since this proposals exists to document the scheme, you are totally free to use it for now. Although I must say I don't welcome public_transport:type=*, and exclusive=* looks like duplicating access=*. service_period=* may be able to be described in the more general opening_hours=* using the comment syntax (eg opening_hours=07:00-10:00 "peak only", or opening_hours="peak only" when period is unknown or not yet specified) if needed. That's what I would note. -- Kovposch (talk) 12:58, 27 April 2020 (UTC)
I don't really like exclusive=* too. Maybe it would make sense to use access=private instead for such cases? I my eyes it would fit, because access=private means "access only with certain exclusive permission". Default (and no need to tag) would then, of course, be access=yes--Lukas458 (talk) 19:12, 2 May 2020 (UTC)


It's a pity that the proposal is currently inactive. I think there's really a lot of potential in it.--Lukas458 (talk) 16:33, 28 March 2023 (UTC)

On-demand share-taxis

In Germany, we often have taxis called "share-taxis" which act as a bus, with scheduled times and fixed stops, but the routes are serviced on-demand only. So you have to call about 30 minutes before and tell when you want to take it and especially where to enter and where to exit. Only these stops are served then. The stops are fixed, but only those are served which were reservated before. It is called a "share-taxi" because if some people want to use the same scheduled taxi service, but independent from each other, then the taxi "collects" the people at the reservated points and they "share" the taxi (is that the definition of "share_taxi=*"? I don't know). But how to combine public_transport:type=share_taxi and public_transport:type=on_demand then? Would it be purpose to get several values used? --Lukas458 (talk) 19:29, 2 May 2020 (UTC)

The answer would be don't use public_transport:type=* - it is pretty much a not-nice key. It would be possible to combine different, more specific keys. However I must ask this first: Isn't share-taxi itsef somewhat "on demand" already? Since there could be many varieties of share-taxi, it may be better to tag the form of on-demand service. "On-demand" is already pretty vague. -- Kovposch (talk) 10:52, 3 May 2020 (UTC)
Yes, I believe "share-taxi" is really a service which is on-demand only. As said, the vehicle is a motorcar-taxi (maybe we need a tag for saying this then) and the service is scheduled times + scheduled stops, but reservation is necessary for using it. These are the three things which would have to be tagged. "On demand" is certainly too vague, because in other cases there might be also services like "just a call and then get the service whenever you want", without scheduled times. --Lukas458 (talk) 19:04, 3 May 2020 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Differentiation_for_routes_of_public_transport&oldid=2513388"