I felt that it wasn’t necessary to also create roles like permanent_stop with the main reason being that this request_stop is supposed to be treated more like a micro mapping thing when someone really likes detail in bus routes. When you normally map a bus route you just automatically add stop and platform and if you want to add further detail you then use request_stop.
I wanted to just have a distinction of 2 types of stops, as shown on the screenshot below
You have the full dots and the hollow dots to symbolize permanent and request stops. In my mind, the app should have support for two states instead of three, where one of them would probably have to be a duplicate of another.
If the data consumer would update and use the data available today, all stops would be shown as full dots but is that really a bad thing? By using OSM public transport you probably already know that there might be some inaccuracies and you should look if there is a sign on the stop or if it’s shown on the screen in the bus that your stop is on demand. Not introducing a new role makes relations with new roles be less broken to current data consumers.
You can mark that the request stops are included by adding check_date=* with the date after the proposal has been approved.
I agree with the proposal in general, since currently there is no documented way to tag request stops in such a system where the same stop can be a regular or a request stop for different lines.
However, I strongly disagree with the statement that “request stop=yes should be possibly deprecated”. Still, in many (most?) transit systems, stopping on a request only is a property affecting all of the lines serviced. So, deprecating the tag would mean for such systems that extra care is needed every single time when adding or changing a relation of a route to not forget to mark every request stop as a request stop. All without providing any added value (and with a need for an initial re-tagging). I believe both tagging methods can be considered valid simultaneously, with only one used for each transit system, depending on its rules.
I guess that’s fair as some railway halts are often request stops for all trains and it is shown that way on schemes (example of signifying that via triangle symbol below)
My point is that data consumers should get the information about request stops from the role (like on the bus route screenshot from earlier) and for making stuff like this scheme above you would use the tag.
They most likely fetch the data from the stop node itself anyway (in addition to the data from the relation), e.g. to get the stop’s name, so checking the request_stop key while at it is a very minor issue.
A stop with a role request_stop and a stop with request_stop=yes and a role stop could be treated the same for the purpose of a line diagram.
The stop-on-request routes I’m familiar with travel through urban areas, so there are other people around who might be doing other things. I don’t think we have a fixed policy about how to hail a bus around here. The bus operator uses social cues and common sense to figure out whether you want to board. They come to a brief stop and dash off if you don’t react to them. If you’re using a wheelchair or otherwise look like you need assistance, the good ones will err on the side of caution and ask. It probably also depends if the bus is running on time or needs to hurry toward its next time point.
Yes. Once the driver is sure the person does not wish to enter, they will move on. Sometimes they know this before opening the doors, often they open the doors, wait to see nobody entering, then close the doors and go.
The reason for this is: It is to guarantee disabled people to use the bus. When you do not see well, you do not know if it is your bus from the distance so you cannot wave. If you are weak and you cannot stand long, you remain seated until the bus is right there. You also can be weak and have bad vision.
Hi, this proposal is pretty much aligned with a previous question of mine:
Here in Spain, especially in rural areas, bus operators may designate some stops as on-demand. This means that any potential user getting on or off at that stop needs to make a phone call, send an email, etc., to the bus operator some hours in advance (with instructions printed on the timetable, the bus operator’s website, etc.). For reference, I’ll repost the image from the post linked above:
Would the proposal include a role for the ways that are part of the detour to an on-demand/request stop? If so, what would that be? Would the stops in a bus route that is entirely on demand also have the request stop role?
Wow, that’s an interesting case. I’d say it’s outside the scope of this proposal and the ATYL solution would be to add on_demand to each of the road segments of the detour and if the way you get to the detour is via phone call, I’d use stop_on_demand (which has a couple uses) to signify it’s not like a typical request stop. If you have to just press the button to access the detour, then I think request_stop_exit_only would be appropriate.
In general, demand responsive transport (dial-a-ride) is probably best modeled as something other than a traditional bus route, even if it generally follows a route corridor. But this reminds me that some fixed bus routes have request stops that force them on a detour when the passenger requests it (while on board, not by calling ahead). @Baloo_Uriza has written extensively about these situations in Oklahoma on the mailing lists and might know of other edge cases to consider. I suppose the PTv2 schema would technically require a separate route for every possible permutation of detours, joined by a route_master relation…
Personally all these request_* and *_on_demand show the limit of the single role in the data model, similar to tag semicolon multival, and lack of areas. Eg an arbitary westbound_express_lanes on a route=road , with all 4 *bound_*_lanes combinations for the local-express system. This may be lower in priority.
How about eg stop;request_stop / stop;request_stop=yes / stop @ (request_stop) / stop @ (request_stop=yes / etc ?
I really don’t see a point in that, especially if the word ‘stop’ would have to be repeated. I also really don’t like having semicolons where it’s not necessary because one could switch the order of items which is annoying for overpass queries or taginfo checking. Even more with that conditional syntax, you’d need to change the way roles are understood, at least in PT relations. I think that the idea I suggested with underscores works fine though it could be also done with colons. And with how relation roles look in JOSM, they should probably be as short as possible.
I definitely agree that roles in the data model are too limiting, but introducing conditional syntax will probably severely limit uptake of this tagging scheme.
Since you mention road route directions: at one point, there were proposals to stuff multiple aspects into roles, like forward;north;unsigned. Instead, we ended up largely standardizing on separate relations that could be tagged individually with cardinal directions and signedness.
We already have this problem to some extent. A single physical stop can be called something different by each of the lines or operators that serve it. Sometimes this results in duplicating the stop node. However, I’d rather not duplicate every major bus stop around here and add scores of variant route relations just because nighttime service operates on a request stop model.
Indeed I forgot to list out stop:request_stop as an option. If you don’t like repeating “stop”. *:request_stop could be renamed to eg *:on_request to follow *:on_demand ?
Is there any difference between supporting request_* / *_on_demand , vs * @ (*request*) / * @ (on_demand) though? Without implementing the syntax yet, an application could still use the same hardcoded/enumerated role == "stop_exit_only @ (request_stop)" as role == "request_stop_exit_only" equality evaluation behind.
I have looked at that post before, without considering it much. Not route= , but I did think about making copies of the =stop_area to associate =bus_stop and route=bus for tagging request_stop=yes , names, etc in context. So the =stop_area would simply be added to the route=bus as alongside stop , using another role.
Still, I don’t see a point. In this proposal I recognize the saying “the simpler the better” and the option I proposed requires the least characters so it is the easiest to add in not only JOSM but also iD, Level0 and other editors.
If you want to change the approach with PT roles, I suggest you start a discussion about rethinking stop_exit_only, etc. in a new thread but for now, request_stop has the highest chance of getting approved.
I personally don’t want to vote on having all the possible combinations of request_* and *_on_demand request_* still breaks the pattern of stop_* and platform_* variants. So it could at least be *_on_request , as the “request stop” term doesn’t mean request_* type of _stop originally, and request_platform is a weird construct.
Let me complicate this with another situation: On a group of bus stops, there can be a different dedicated position for wheelchairs to board and disembark. It can be used by all routes stopping at those stops. Should it be *request*=bus_stop + wheelchair=designated , or something else?
The latter shouldn’t be used unless it’s an actual on demand stop which also fulfills the criteria of on_demand=yes. This, however, is outside the scope of this proposal.
I wanted to make it this way, so with combinations like request_stop_exit_only, there’s no stop_on_request_exit_only vs stop_exit_only_on_request, like I expressed the concern with using semicolons. It’s also a lot easier to see that a stop is on request by just looking at the beginning opposed to the end and it’s a lot easier to add in JOSM by just pressing ‘r’ (and I guess it’s easier in every editor because it requires 3 less characters :) ).
I see only two coexisting “modifiers” for stops and those are entry_only or exit_only (it can’t be both at once) & request. That’s why it could use the space before and after.
But if we were to consider on demand stops, the syntax could be on_demand_stop_exit_only, in one of the combinations. So the two pairs of modifiers are entry_only/exit_only and request/on_demand, one written before and one after stop/platform.
I agree that it might sound weird but it’s needed for consistency, and OSM tags don’t always have to make perfect sense, like leisure=pitch + sport=chess for chess tables.
Anytime something applies to all lines at that stop, it should be tagged at that stops because roles have limitations and tags are more often processed than roles.
The exception is what can be different between lines should remain always specified as roles even though some stops may be treated the same by all lines in order to make a consistent scheme for data consumers.
If the bus only stops when there’s a button or the person waiting at the stop signalises it, it should be a request_stop.
I counted entry only and exit only as one because they can’t be used together.
Basically, it could be represented by such a table, where you build a role by picking one option from each column and merge them by using an underscore.
First modifier
Stop type
Second modifier
request
stop
entry_only
on_demand
platform
exit_only
But this is just for fun since on_demand_* is outside the scope of the proposal.
