Talk:Proposed features/Differentiation for routes of public transport
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 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 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.
- public_transport:type=* looks nice.
- However, I'd suggest to use public_transport:service=* instead of public_transport:service_period=*, and use the same syntax as for opening_hours.
- 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.
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.
- 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)
More precise tagging
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)
- school = only if this is a line dedicated to students transportation
- school = yes if this is a classical public transport line, with additional stops at the school on the morning and the evening. Example : http://www.transdev-idf.com/image/375736475/raw/ligne_mobicaps_4.jpg
- 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 :
- on_demand = only : the full line in on_demand. For instance the Resago line R61 in Amiens : https://lut.im/aDWqGDXw6M/4tWnDWK0gpcU6zr7.png
- on_demand = yes : you only have to phone if you want to go from or to some stops. For instance the Flexo line F8 in Amiens : https://lut.im/uLCYsE0XC6/1uzZYH9JUXLNBQ2P.png
- In this case, it would be:
- R61: type=route_master + public_transport:type=on_demand with two type=routes (optionally with public_transport:type=on_demand too) for the two directions
- F8: type=route_master with two type=routes for the parts that aren't on demand and two type=routes + public_transport:type=on_demand for the parts that are on demand
- 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)
- 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)
- on_demand = partial / only
- Why not adding a few more examples (Mobicaps 4, R61 and F8) in your example section ?
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)
- 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)
- 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:
- public_transport:type=car (misleading anyway, because only applies to trains and I would rename)
- public_transport:type=car_shuttle (misleading anyway, because only applies to trains)
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.
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)
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.