I created a proposal to mark stops on demand via a role for specific public transport relations instead of tagging the whole stop object that makes it apply to all relations.
Please discuss this proposal on its wiki talk page.
3 Likes
This would be solving a real problem. I can think of some stops locally that we’d have to duplicate just to be able to represent this information.
That said, I’m a little wary of an approach that relies on roles because of the potential for conflict with other tagging schemes. The proposal mentions request_stop_entry_only as a possible combination – how many other potential combinations are there, and would any existing consumers of stop_entry_only be impacted by replacing that role with request_stop_entry_only in some cases?
request_stop_entry_only
request_stop_exit_only
request_platform_entry_only
request_platform_exit_only
I guess they would need to code in support for the new roles but there’s barely any software supporting either roles in the first place.
1 Like
In Austria almost every bus stop is a request stop. If noone presses the stop button inside the bus, and noone is waiting at the stop, the bus will continue driving. I guess this is not different in most countries. If this proposal gets approved, it would make all bus routes wrong.
On trams and trains though, there is an obligation to stop even if noone has pressed the stop button (if there are some) or is waiting.
As exception, we have some (few) request stops on trams and trains.
Lets hear about other countries. Maybe the proposal should be excluding bus routes?
4 Likes
That’s what I figure too, but I’d suggest investigating that further and contacting the developers of any consumers you do find, as a courtesy.
1 Like
Some other things to mention:
The reason why I chose to use request_stop instead of stop_on_demand or stop_on_request, etc. is because it’s then a lot easier to just key in ‘r’ in JOSM which will autofill the rest of the role compared to the extra ‘s’ then ‘→’ then ‘_’ and ‘o’. It’s also what the Wikipedia page is titled as Request stop - Wikipedia.
Buses which have all stops on demand could have a new tag like stop_on_demand=only on the relation, or have request_stop=yes on all stop nodes or just have request_stop and request_platform on all members since it honestly is even easier to add than stop and platform.
In Poland you usually just have normal stops. Either way, someone that uses a data consumer which understands these roles would see the stop display as normal which if they live in that area for a long time they know that they still must almost always press the button and a tourist should always be weary that the app might not show that all stops are request stops.
What I’m saying it’s that it’s not a big deal. You already have incorrect information if you don’t have request_stop=yes on all stops.
This isn’t really a key detail – it’s more of a micromapping thing.
Also just now I’m thinking that you could import the information about request stops from GTFS and GTFS to OSM applications could also update.
There are two different forms of requests at stops:
- passenger exiting the bus/train, by pressing a button or telling the driver
- passenger entering the bus/train. I have seen buttons at the train station, but most of the time it is done by handwaving to the approaching bus. I have seen this concept in the UK, but I dont know of they still do it, because it excludes blind and visually impaired people from using the bus.
Are both forms covered by the proposal? Could it be clarified who has to request, the passenger inside or outside the vehicle?
Of course both forms are covered as one is for get on and the other for getting off the vehicle. If only one of them is available, request_stop_exit_only or another variation should be used.
It seems like this could the a use for request_stop=* – maybe request_stop=button or something similar could be utilized.
That’s clever, but I don’t really think we should choose tags based on that sort of ergonomics. Not everyone uses JOSM, types raw tags, uses a QWERTY or QWERTZ keyboard, types with their left hand while mousing with their right hand, touch-types on a physical keyboard, etc.
A better reason to call it request_stop is for consistency with the existing request_stop=yes tag, which refers to a kind of stop.
In the U.S., stop-on-request policies are common but not ubiquitous. You can find them on:
- Entire bus systems serving rural areas
- Local bus routes in urban areas
- Distant stops served by urban bus systems
- Nighttime bus service in urban areas, as a safety measure
- Entire light rail systems to improve efficiency and mitigate poor transit planning
- Certain unpopular stops along major rail lines
So far, in my city, we’ve been focused on indicating request stops along light rail, but we could start tagging local bus routes with request_stop=yes. Some bus stops are served by both local routes, which only stop on request, and express routes, which generally will stop at any time point even unrequested.
2 Likes
Well, on Austria you dont (almost never) have to request a stop if entering. If you sit at the bus stop bench doing nothing, the bus will stop.
But if, at the very same stop, you sit inside the bus doing nothing, the bus will not stop.
Is this a half-request stop? Wouldn’t it be good to make this difference mappable?
1 Like
You’re right, I forgot about that but that’s how it also is in Croatia.
The way I see it is that it just depends on the system in the country so in some you need to wave and in others you just have to be present at the stop but it’s still counted as a request stop.
I feel like if the stop has a shelter and a bench and more than one bus lines operate the stop and there would be a person on the bench that doesn’t look like they plan on getting in the bus, then the bus might not stop, but that’s just a guess.
To summarize, I’d still call that a request stop where the passenger requests for the bus to stop simply by being present at the stop.
2 Likes
Request stop is the standard term in British English.
Most stops are request stops unless they are the end of the route.
2 Likes
Now we have to decide for whom we intend the tagging.
- the bus/tram driver: Do I have to stop even if I think nobody wants to enter or exit?
- the passengers: Do I habe to do something to make the bus/tram stop, to then enter/exit?
I believe it should be number 2.
If you say being there is already a request, there is absolutely no info for the entering passenger if they have to do something (wave, press button) or not (just be there).
Therefore I suggest making this proposal only about a request to exit the vehicle. This would be way easier to understand and to map.
If there were a button, it could be a property of the bus stop node (as you said before) so this info can still be mapped.
Lauding the initiative as now my “hail_and_ride” (ATYL) role and tag on bus stops and positions get constant flagging at each edit).
(And there is no other way than waving a hand to get a bus to stop… most all in town have a “Fermata a richiesta” (stop on request) sticker on there even when it’s served by only 1 line (people use the shelters/benches not only for bus transport needs, they also just take a rest, hide from the sun, or as is popular in Strada Parco, go read a book in the outdoors in extreme quite since the Trolley buses are the only vehicles allowed on there (and that bus must be pantagraph connected as the bus company had their license suspended for the line as it was running non-trolley buses up and down)
Getting on-off distinctions don’t exist here. Push a button in the bus or wave when your bus approaches. And most all buses have 3 doors. Back/front in, centre out.
I believe this is dependent on local convention whether you have to wave or simply be present. A button could exist which could be signified with request_stop=button on the stop but it only works if the line has that stop marked as a request stop. If another line has that stop marked as a permanent stop, the button is probably not needed, right?
This makes me think that request_stop=* could be repurposed into a tag that shows what method is required for the line, that has the stop “tagged” (“roled”?) as request_stop, to halt (as a passenger waiting on the stop). So the available values would be =present (other suggestions: =be_present, =stand), =wave and =button. But once again, I feel like only =button should be a value because I don’t think that, in one country, there’s both request stops where you have to be present and where you have to wait. Unless that applies to even more local conventions like municipalities so in that case I guess all 3 values could be utilized.
It must also be about entering the vehicle because not all lines will have a stop be a request stop.
The tag request_stop=present/wave/button could be used to add further information about how you enter the vehicle but it would only apply when the stop has the request_platform role.
1 Like
I saw a similar system in Turkey and I thought that the right way to tag it wouldn’t be with the hail_and_ride role on each element but with a tag (like hail_and_ride=yes or =only) on the relation itself. Then for the stops you’d either have the typical stop and platform or you put request_stop and request_platform on each stop in the case that there are some singular big stops that are permanent stops.
Out of curiosity, and probably not relevant to tagging, but does this mean that on stops that serve multiple lines, buses stop only to find that the person sitting at the stop is going to a different destination and they have stopped for no reason?
In most cities I know where you are expected to hail the bus, there might be some chance that the driver stops if you stand up and look vaguely like you intend to board, especially if all buses follow the same route after that stop. But I would definitely not expect them to stop if you remain seated. Even if only one route serves the stop, you might just be waiting for somebody.
3 Likes
I think the request status of a stop may be a feature of a route. The same stop may be by request on route A, but a compulsory stop on route B.
I feel the proposal should be more explicit about what it means for the existing platform and stop roles.
Currently these roles say nothing about whether the stops are request stops or not. If specific roles are defined for request stops, does that mean the “simple” tags implicitly refer to permanent stops? Or do they continue to be “neutral” - which would give no way to directly indicate that a stop is not a request stop?
2 Likes