|
How should I input, for example, a bus route that takes a slightly different route evenings and weekends than it does during the working day? It doesn't seem right to enter the whole route twice as two variants just for a small variation at one point on a long route that is otherwise the same. Is it acceptable to have the route split into two alternatives part-way along? I can't find any suitable 'role' to indicate a split like this. |
|
No, the correct way is to create a new, complete route for the variant used in weekends, and group all of the variants under a "route_master" relation. Bus Route relations should ideally never be "branched" or "broken" - no guesses should be made by (already very complex) routing software regarding the "branch" that should be taken on a route. See route_master documentation in the OSM wiki for more information. 1
Branched bus routes are seen in our neighbourhood. In fact, branched routes cause problems not only in OSM-also cause problems in the route master of the bus operator. I have not tagged that branched route, because I know they will have removed the branching in the foreseeable future.
(21 Sep '13, 08:56)
erkinalp
|
|
You will get lots of people telling you to create a new relation for every single variant. This is impractical, certainly on every bus route/network/company in the UK that I've ever used. I would dearly like some way of including branches in a given relation. The notion that it would confuse routing software is specious. Do people seriously expect any routing software, however good, to accommodate all the weird anomalies that even a simple UK bus route exhibits ? How on earth would routing software present to the user instuctions such as "get a 61 bus from here, except if it's between 1100 and 1300, when the 61A runs this route, in which case, you have to get it from THAT stop over THERE. Whichever one you get, make sure it stops on XXX road (some don't). If it didn't stop on XXX road, continue until YYY, where you can probably pick up a 61C going the other way, and recirculate" My suggested solution is to present the "normal" route (whatever that is) with one relation per direction, along with a relation containing disjointed exceptions to that route. I want to get across to potential users that "some buses come this way; some don't. Those that terminate early (unpredictable) will turn-off route, stop THERE instead, and perhaps continue as a different route.". It is a fact of UK bus usage that getting TO certain specific stops is rather unpredictable, as is boarding at a specific stop. My "normal" route would, in general, contain only those stops that are reasonably predictable. However, I don't want to disenfranchise certain groups of travelers, for whom the exceptions are the very ones that they want. E.g., if a particular trip serves a particular housing estate (but most don't), I don't want any map rendering to imply that it is "never served". In other words, my "exceptions" relation would do nothing for routing, but would simply overlay the "dotted" lines on any rendering of the map. Maybe in the future someone will propose (and get approved) some kind of route_variant relation type, somehow relating some part of an existing route (maybe through a "via" role) with another relation that describes another variant part of the route, or some other related structure. But as of NOW, there is no "official" way to map bus route variants except mapping each variant, no matter how many there are (even if dozens).
(14 Nov '13, 09:27)
MCPicoli
|
