Hi, I’ve been mapping bus routes in my area recently. Some of them cover small settlements and, for routes to make sense from the financial side, are relegated to on-demand routes and stops.
The tagging is simple and well-documented when the entire route is on-demand. For the case of request stops on regular (i.e., not on-demand) routes, these stops can be on the route or not and thus need a detour. How should the request stops and detours be mapped? Note that a single route can have more than one request stop with their respective detours.
My second question concerns both on-demand routes and regular routes with on-demand stops. I’m unaware of how it works in other countries, but in Spain, the stop request procedure in these intercity routes is to make a phone call or email the bus operator some hours before the expedition. Is it worth it, or is there any way to include this information (phone number, email address, x hours in advance) in the route or the on-demand bus stop?
P.S.: a slight variation of this message was sent in the talk-transit mailing list but got no conclusive answer, so I wanted to draw attention to this issue and hopefully reach a consensus.
Currently you have to make a new =route for every variation. This is understandably impractical for the number of possible combinations when there are multiple on-demand stop. It would be easier to have more roles (similar to excursion etc in =foot and =bicycle ), but they still need to be inserted in between, meaning it will break existing tools before being supported. Still, this doesn’t violating the principle of creating new =route for variations, because new =route would still be created when these on-demand detour stops are only served in different time periods.
How about reservation= + reservation:*= ? You have to request in advance. It’s not an immediate request_stop= where you can signal the vehicle to stop.
This approach means one route for the regular route, and additional routes with on-demand=yes for every on-demand stop, right? This would create heavy duplicity in my opinion, because they only differ in the detour, or in the case the on-demand stop is on the regular route but the bus doesn’t stop unless requested beforehand (which is silly and I can’t recall any example right now) only in that stop.
reservation seems like a good solution, would it be placed in the stop node or in the route relation? If a reservation is received, the bus driver is notified and they will detour and stop there; so if you need to get off there, you let the driver know when you’re buying the ticket.
I was only describing the standard practice in general at first. I don’t find creating a =route for all combinations of detour stops ideal for your situation either. Ideally, an easier methods to relate the roads as eg on_demand , and stops as stop_on_demand , but the roads will mess up with the routing order at this moment. They need to be proposed and supported by software.
reservation= should be added to the =bus_stop at first. Adding to the =route causes confusion on whether all seats are reserved, and all other regular stops need to reserve as well.
The examples linked have no roads related. This seem to suggest they are entirely on-demand, with no fixed route traveled. Machine translation agrees for “trajet non pré-définis”. So on_demand= on the =route alone doesn’t describe how it works satisfactorily. Re: [Talk-transit] On-demand bus stops
On a minor note, on_demand= is documented above an unclear by_night= , making them seem dubious Tag:route=bus - OpenStreetMap Wiki contact:*= doesn’t specify whether it’s for general questions, or something more important. They may be misunderstood as mistakes of operator:phone= . The demand phone number or email may further be different from that for general inquiry. This makes me prefer a more specific reservation:*=
