On Mon, 26 Nov 2018 at 11:43, Sigurjón Gísli Rúnarsson <[email protected]> wrote: > I have had some recent feedback regarding my changes to the ferry route paths > in Sydney Harbour in August this year. I basically changed the mapping from > single way approach to relation approach. The main reason for this change > was so that the ferry route paths could be used for routing purposes, to > reflect what is actually happening on the “ground” with these ferry route > services. > The feedback I received from the OSM user is that these ferry routes should > be mapped back to single way approach as having ways intersecting/branching > between terminals/wharves should not be allowed. Rather, there should only be > a single way between wharves. At the moment some routing engines take turns > in the middle of the harbour (example – now fixed in database) which I agree > is not ideal. I have tried to map the ways to avoid this as much as possible. > > I feel that I’m following the wiki > https://wiki.openstreetmap.org/wiki/Tag:route=ferry with the relation > approach. At the time that I made the changes, I got only minimal (all > positive) feedback regarding my approach to this. But I can also understand > the reasoning behind why the single way approach is preferred, as it looks > better from a cartographic point of view on the standard OSM map tiles and > gives a good overview of the ferry routes. > > Unfortunately mapping with the single way approach does not give options for > accurate routing based on the way the actual ferry services operate.
I'm in favour of using ferry route relations in Sydney Harbour, it allows us to capture the full range of ferry services (including private and public services) which share the same "ways" without the issues from overlapping ways. As you've pointed out this is well documented at https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry It seems the branching of ways in the open water that results from mapping ferry routes as relations is causing issues like https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=-33.8711%2C151.2621%3B-33.7997%2C151.2857#map=14/-33.8421/151.2726 which is not a path that you can actually take. I want to point out that railways have the same issue, where there are switches like at https://www.openstreetmap.org/way/143758897 a routing engine which doesn't account for route relations will happily take that switch even though there may be no public transport routes which take it (it might only be there for non-scheduled services). Ultimately a routing engine is only going to get so far without taking into account the route relations and service timetable, so I don't think that zigzag is a deal breaker. > The idea was brought forward to apply custom tagging to the “new” ways that > have been mapped based on the relation approach. These custom tags (i.e. > route=[custom tag]) could then be used in conjunction with single way > approach ways for routing based on services. You're suggestion of using route=ferry_services on the way actually makes sense and would fix the routing issue. On the other hand I see the routing taking branches when route relations exist as a routing engine issue, and something that could be addressed there. I think that's probably a better solution, as the tagging remains the same, as moving to route=ferry_services is a big breaking change that would be hard to push through as a global tagging standard. While we're talking about ferries, https://www.openstreetmap.org/way/201884898 has to be my favourite ferry route in OSM: "route=ferry + description=Row yourself using supplied boats". _______________________________________________ Talk-au mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-au
