Ferry lines in the Stockholm Archipelago has a need of that
When entering a ferry you need to tell your destination so the ferry will stop there…
On busses you can easily signal with a button that it will stop or not….
cc: @miscosm
My dislike with how unwieldy it is aside (though it’s also the only reasonable option because request stops are part of the route definition and the limitation with OSM relations), I think this should also consider routes as a whole.
As the proposal is right now, it assumes request stops are the exception than the norm which gets annoying very fast to modify routes where request stops are the default modus operandi to the point where it’s easier to mark the whole route as working with requests and otherwise mark mandatory/fixed stops (e.g. major interchanges, points of overtaking) than the other way around.
I understand this and I suggested earlier to use something like request_stops=only. Though there is also the option to just spam ‘r’ on every stop and JOSM it will autocomplete it. Either way, that’s up to you and outside the scope of this proposal but you could also make a separate proposal for an alternative which could be a tag for PT relations to signify that all stops are request stops. But maybe it would work better for data consumers to have hollow dots on each stop except for the first and last ones.
As the proposal is right now, it assumes request stops are the exception than the norm which gets annoying very fast to modify routes where request stops are the default modus operandi to the point where it’s easier to mark the whole route as working with requests and otherwise mark mandatory/fixed stops (e.g. major interchanges, points of overtaking) than the other way around.
+1, almost all stops are request stops in German and Italian public bus transport with the exception of longer distance travel (may vary) and the terminus stops.
When you map public transport, how do you do it? Do you think it would be easy to add appropriate roles by simply clicking ‘r’ and JOSM autocompleting it? Or would it be better to just use a dedicated tag on the relation?
Funny, saw a bus ‘stop’ the other day and it said “does not stop between Pescara and Giulianova”, which is about 40km assuming the shortest/quickest route.
Is this actually an issue? It would seem to be the simple, workable, and in a way, given this is actually a defining property of the stop, correct solution to the issue.
Being a bit contrarian, but that is still better than the schemes being proposed.
Could you explain how, if it’s not for the same reasons as mentioned already?
We use this solution locally for exceptional cases. There are only a handful of bus stops that go by different names per line or operator, so duplicating the bus stop is a reasonable tradeoff. However, I’d be wary of duplicating many more bus stops that serve as a time point for one line but not another. It could add a degree of confusion about how the user would transfer between lines. I guess stop group relations mitigate that to some extent though.
As to one feature, one OSM element, outside of it likely being the most violated rule in OSM, I’m just saying colocation doesn’t make something the “same”, aka a non-request stop is not the same as a request stop.
the “one feature one OpenStreetMap element”-rule is almost never a guidance, because what a “feature” is in OpenStreetMap is defined by tags. In the real world there are no “features”, but in our tag definitions we can always define the tags in a way that we describe different aspects, we can even have a point and a way for the same real world thing at the same time if we simply say one is the “center” and the other is the “area” of the thing (for example).
Another common scheme to refer several times to the same thing is by having “properties”, tags that indicate (indirectly, i.e. without their geometry) other things, like “has a toilet”, “has a sidewalk”, “has a trash bin”, “has a bench”, “offers shelter”, “has an atm”, “offers pressurized air”, “is in a tunnel”, “is on a bridge”, etc.
Duplicating bus stops is perhaps a minor sin, but for what it’s worth, we also have light rail stations that technically operate as request stops for some lines but not others. If I start duplicating the stations and stop positions along the railways, it starts getting a bit more pedantic.
By the way, although I think an entirely on-demand route should be represented differently than a fixed route, there are cases of individual stops on a fixed route requiring you to call ahead. Courtesy of @aweech in Slack, this bus route in Concord, New Hampshire, has an optional stop at a state government office. You alight there by asking the operator on board, but you board there by calling ahead, because it’s a bit out of the way. As things stand, we’d map it as a separate route variant within the route master relation, perhaps with something like opening_hours=by_appointment, and put request_stop=yes on the bus stop. Unfortunately I can’t think of a more intuitive way to explain when the variant would come into use.
Did think about =bus_stop + request_stop=yes + wheelchair=designated , but the difference with =bus_stop + request_stop=yes is that there would be 2 pairs of them in the route=bus having basically the same name= and other attributes. So I thought the wheelchairs one should have a different role, instead of both having stop and platform somewhat misleadingly.
Is that treated as a different stop? Can you show where it is and how it operates?
I know that it doesn’t work all the time, but having two highway=bus_stop nodes half a meter apart is not good mapping, especially if there aren’t multiple poles with one for every operator.
Depends on your definition. There are many situations, but it can indeed be quite far apart. 天富總站 | 香港巴士大典 | Fandom (this one is outside the main area on the access road, and not sheltered, so different highway=platform islands and road sections to speak of)
I’m afraid you’ve misjudged the amount of work your proposal entails.
Here in Belgium, all stops are on request, whether by pressing a button while on the bus or by signaling to the driver while waiting at the stop. Judging by the reactions, it seems this is the case in quite a few countries.
If I follow your suggestion, just for one of the three operators in Belgium, there are more than 6000 route relations and 194000 roles to modify for 0 added value.
Yes, I read that you suggest doing this via automatic editing… but is the program written? It’s not that simple to do…
On the other hand, your proposal is incomplete. There are two kinds (at least) of “on request” stops:
The difference is significant and this leads to a multiplication of roles.
Perhaps a less labor intensive suggestion:
I have no idea where you read that because I have never said that.
To answer the rest of your post, everything has already been mentioned in this thread and so I recommend you read it or at least from post 19 to post 42.
Whatever the questions are, you should clarify them in the proposal, if you need to ask a voter to read 20 comments with hundreds of words. Your proposal text now is shorter than most comments here, showing the complexities and confusions that needs to be untied.
