Data / routing issue - Vancouver, BC ferries
Greetings all, I have been lurking on this list for several years now and first want to congratulate all for such a fantastic project. Very, very nicely done! But I have run into an issue with the maps I create of British Columbia and am unable to determine whether it is a data or mkgmap issue. The problem is that ferries coming out of the Tsawwassen ferry terminal to/from Vancouver island do not get routed. For example finding a route from Kamloops (BC interior) to Victoria, the route on my Nuvi 255 shows a 1400 km diversion north to the coastal town of Bella Coola, then a ferry to Port Hardy on the north end of the island, then south to Victoria. This routing is suggested whether I use maps I've generated myself or ones downloaded from garmin.openstreetmap.nl. It is interesting, however, that other routing engines (GraphHopper, OSRM and Mapzen) route over the ferries as expected... Kamloops direct to the Tsawwassen terminal, then ferry to the island. I question, however, whether the ferry routes are mapped properly as just west of the Tsawwassen terminal is a node where all routes join and branch http://openstreetmap.org/node/660826272 . A similar node exists east of the Swartz Bay terminal on Vancouver Island - 323308217. The wiki documentation for tag route=ferry states in part "The ferry route must not branch in the water, so it must always be drawn to the ferry dock. This is important for routing to work correctly." So when the wiki says that it is important for routing... whose routing? Clearly this is not a requirement for these other engines, but is it the case for us? If we need data in the form as that described in the wiki, then I will contact the Talk-CA list and see if there is someone local who can fix it... i.e., recreate it as per the wiki standard. Otherwise, if the wiki is outdated and the data are acceptable, then could there be a problem here, or could I just need an adjustment to something in my args list? Thanks in advance, Samuel Longiaru Kamloops, BC Canada
Hi Samuel, quick question: do you use http://download.geofabrik.de/north-america/canada/british-columbia-latest.os... as input for splitter? Maybe other files as well? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Dienstag, 13. Juni 2017 07:39:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries Greetings all, I have been lurking on this list for several years now and first want to congratulate all for such a fantastic project. Very, very nicely done! But I have run into an issue with the maps I create of British Columbia and am unable to determine whether it is a data or mkgmap issue. The problem is that ferries coming out of the Tsawwassen ferry terminal to/from Vancouver island do not get routed. For example finding a route from Kamloops (BC interior) to Victoria, the route on my Nuvi 255 shows a 1400 km diversion north to the coastal town of Bella Coola, then a ferry to Port Hardy on the north end of the island, then south to Victoria. This routing is suggested whether I use maps I've generated myself or ones downloaded from garmin.openstreetmap.nl. It is interesting, however, that other routing engines (GraphHopper, OSRM and Mapzen) route over the ferries as expected... Kamloops direct to the Tsawwassen terminal, then ferry to the island. I question, however, whether the ferry routes are mapped properly as just west of the Tsawwassen terminal is a node where all routes join and branch http://openstreetmap.org/node/660826272 . A similar node exists east of the Swartz Bay terminal on Vancouver Island - 323308217. The wiki documentation for tag route=ferry states in part "The ferry route must not branch in the water, so it must always be drawn to the ferry dock. This is important for routing to work correctly." So when the wiki says that it is important for routing... whose routing? Clearly this is not a requirement for these other engines, but is it the case for us? If we need data in the form as that described in the wiki, then I will contact the Talk-CA list and see if there is someone local who can fix it... i.e., recreate it as per the wiki standard. Otherwise, if the wiki is outdated and the data are acceptable, then could there be a problem here, or could I just need an adjustment to something in my args list? Thanks in advance, Samuel Longiaru Kamloops, BC Canada _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Quick thought - this caught me out with ferries - have you requested "No Toll Roads" in routing. In openStreetMap, some ferry routes explicitly say toll=yes/no and some don't bother saying anything, and I think the default style then doesn't mark it as toll - but I think it would be better if it did. Ticker On Tue, 2017-06-13 at 06:20 +0000, Gerd Petermann wrote:
Hi Samuel,
quick question: do you use http://download.geofabrik.de/north-america /canada/british-columbia-latest.osm.pbf as input for splitter? Maybe other files as well?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Dienstag, 13. Juni 2017 07:39:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries
Greetings all,
I have been lurking on this list for several years now and first want to congratulate all for such a fantastic project. Very, very nicely done!
But I have run into an issue with the maps I create of British Columbia and am unable to determine whether it is a data or mkgmap issue. The problem is that ferries coming out of the Tsawwassen ferry terminal to/from Vancouver island do not get routed. For example finding a route from Kamloops (BC interior) to Victoria, the route on my Nuvi 255 shows a 1400 km diversion north to the coastal town of Bella Coola, then a ferry to Port Hardy on the north end of the island, then south to Victoria. This routing is suggested whether I use maps I've generated myself or ones downloaded from garmin.openstreetmap.nl. It is interesting, however, that other routing engines (GraphHopper, OSRM and Mapzen) route over the ferries as expected... Kamloops direct to the Tsawwassen terminal, then ferry to the island.
I question, however, whether the ferry routes are mapped properly as just west of the Tsawwassen terminal is a node where all routes join and branch http://openstreetmap.org/node/660826272 . A similar node exists east of the Swartz Bay terminal on Vancouver Island - 323308217. The wiki documentation for tag route=ferry states in part "The ferry route must not branch in the water, so it must always be drawn to the ferry dock. This is important for routing to work correctly." So when the wiki says that it is important for routing... whose routing? Clearly this is not a requirement for these other engines, but is it the case for us?
If we need data in the form as that described in the wiki, then I will contact the Talk-CA list and see if there is someone local who can fix it... i.e., recreate it as per the wiki standard. Otherwise, if the wiki is outdated and the data are acceptable, then could there be a problem here, or could I just need an adjustment to something in my args list?
Thanks in advance,
Samuel Longiaru
Kamloops, BC Canada
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Samuel, i think the problem come from roads on harbors, which are defined as highway=service, like this one: http://www.openstreetmap.org/way/155877170 This kind of roads are used as last resort for routing algorithm, especially for long distance routes. I see, that some of these roads has been changed recently to highway=trunk_link, this could help a lot, see: http://www.openstreetmap.org/way/51790198 -- Best regards, Andrzej
Thanks for getting back... 1) --keep-complete in splitter - yes. I figured with the long routes and few nodes that this could be a possible point of failure so I made sure to add it. 2) iWowik sent a PM suggesting that some of the important tags were incorrect and/or missing and he was addressing some of them. One suggestion of his was to use Key:ferry to help maintain connectivity to the roads. Wiki states "With route <http://wiki.openstreetmap.org/wiki/Key:route>=ferry <http://wiki.openstreetmap.org/wiki/Tag:route%3Dferry>, this tag can take the highway <http://wiki.openstreetmap.org/wiki/Key:highway>=* classification of the roads it connects, like a bridge." So the service / trunk_link issue Andrzej noted is very interesting. If not given, what road classification does the routing engine see for the ferry? 3) I made sure to untick the Toll Road avoidance thinking this may be an issue as well, but no change. OK... so it looks like there may be several issues at work here. I didn't realize that ferries were such a can of worms both from a mapping and a routing perspective. I expect that this service road issue is a common problem with ferry mapping. Also, given the impact that ferries can have on travel distance and time, unless explicitly avoided, perhaps ferries should always be given a pretty high priority in routing? They're more than just a stretch of 30km/hr highway. Thanks for looking into this! Sam
Hi Sam, ferries get class 3 for routing, which is high. They should be easily used in routing when allowed in GPS. If the problem really is low routing class of service roads, then I see 2 solutions: Convince OSM mappers to add more tags for "highway=service". This could be for example "service=ferry". Or add any other indication, that these roads carry important traffic, for example include roads in a relation. Then this could be processed by mkgmap. Second solution would be to try to catch the problem by mkgmap. I think there are more similar cases, where 2 important roads are connected by a link or roundabout with significantly lower routing class. Mkgmap could include following algorithm: Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4. -- Best regards, Andrzej
Hi Andrzej, I like the simplicity of the tag idea, but implementation I'm sure would be rather spotty. Adding the logic to mkgmap would make more sense I think as it would be immediately and universally applicable. As you say, there may be even more cases beyond the ferry setting where such logic could be applied, and if not accommodated by mkgmap, would need to be re-tagged in OSM. On 17-06-14 05:17 AM, Andrzej Popowski wrote:
Hi Sam,
ferries get class 3 for routing, which is high. They should be easily used in routing when allowed in GPS.
If the problem really is low routing class of service roads, then I see 2 solutions:
Convince OSM mappers to add more tags for "highway=service". This could be for example "service=ferry". Or add any other indication, that these roads carry important traffic, for example include roads in a relation. Then this could be processed by mkgmap.
Second solution would be to try to catch the problem by mkgmap. I think there are more similar cases, where 2 important roads are connected by a link or roundabout with significantly lower routing class. Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4.
Hi, I do not yet believe that the service roads are causing this. I saw +1000<tel:+1000>km detours when reverting a much shorter route. I cannot test it during the next weeks Ciao Gerd ---- Samuel Longiaru schrieb ---- Hi Andrzej, I like the simplicity of the tag idea, but implementation I'm sure would be rather spotty. Adding the logic to mkgmap would make more sense I think as it would be immediately and universally applicable. As you say, there may be even more cases beyond the ferry setting where such logic could be applied, and if not accommodated by mkgmap, would need to be re-tagged in OSM. On 17-06-14 05:17 AM, Andrzej Popowski wrote:
Hi Sam,
ferries get class 3 for routing, which is high. They should be easily used in routing when allowed in GPS.
If the problem really is low routing class of service roads, then I see 2 solutions:
Convince OSM mappers to add more tags for "highway=service". This could be for example "service=ferry". Or add any other indication, that these roads carry important traffic, for example include roads in a relation. Then this could be processed by mkgmap.
Second solution would be to try to catch the problem by mkgmap. I think there are more similar cases, where 2 important roads are connected by a link or roundabout with significantly lower routing class. Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, I think this problem still exists. I downloaded british-columbia-latest.osm.pbf and tried again today. Some routes changed, but overall ferry routing in this area is a mess. I think one reason is that the ferry lines are split, so that many lines connect somewhere in the ocean, e.g. here: https://www.openstreetmap.org/node/323308217 This alone should not be a problem, but some of the ways ending at this node have refs and others do not. In fact all ways going south from this point have the same tags, none has a ref tag. Another problem might be that those ways are connected with rather sharp angles. The road merger doesn't seem to be able to connect the parts. I don't know why the ferry lines are split, but I would say this is very uncommon and probably also wrong because it somehow means that you have to jump from one ferry to another in the open sea. So, I think the problem here is in the data. Comments? Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 14. Juni 2017 18:30:40 An: Development list for mkgmap Betreff: AW: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries Hi, I do not yet believe that the service roads are causing this. I saw +1000<tel:+1000>km detours when reverting a much shorter route. I cannot test it during the next weeks Ciao Gerd ---- Samuel Longiaru schrieb ---- Hi Andrzej, I like the simplicity of the tag idea, but implementation I'm sure would be rather spotty. Adding the logic to mkgmap would make more sense I think as it would be immediately and universally applicable. As you say, there may be even more cases beyond the ferry setting where such logic could be applied, and if not accommodated by mkgmap, would need to be re-tagged in OSM. On 17-06-14 05:17 AM, Andrzej Popowski wrote:
Hi Sam,
ferries get class 3 for routing, which is high. They should be easily used in routing when allowed in GPS.
If the problem really is low routing class of service roads, then I see 2 solutions:
Convince OSM mappers to add more tags for "highway=service". This could be for example "service=ferry". Or add any other indication, that these roads carry important traffic, for example include roads in a relation. Then this could be processed by mkgmap.
Second solution would be to try to catch the problem by mkgmap. I think there are more similar cases, where 2 important roads are connected by a link or roundabout with significantly lower routing class. Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, Thanks for looking into this again. The only reason I can think for this mapping technique is to make the piers at the ferry terminal independent of the ferry routes themselves. I don't know that terminal well enough to know whether certain routes only use certain piers, but independence is assured in theory if all the ferry routes join at one place just offshore. That in-the-water splitting is not in keeping with the wiki however, and it is perhaps on that basis that I could appeal on Talk-CA to see if someone can clean up the Tsawwassen and Swartz Bay terminal areas in some logical way. While ultimately, we would be asking for a fix to accommodate a routing engine, in this case, mapping for an engine is precisely the reason given in the wiki for not allowing such splitting. Your comment about jumping ship is pretty funny, but in fact may be relevant in that it could provide a routing that does not exist normally. For example, going through the Tsawwassen splitting point, one could construct a Duke Point - Mayne Island route, that in fact does not exist, according to the BC Ferry website. Thanks again, Sam On 17-07-29 12:44 AM, Gerd Petermann wrote:
Hi,
I think this problem still exists. I downloaded british-columbia-latest.osm.pbf and tried again today. Some routes changed, but overall ferry routing in this area is a mess. I think one reason is that the ferry lines are split, so that many lines connect somewhere in the ocean, e.g. here: https://www.openstreetmap.org/node/323308217 This alone should not be a problem, but some of the ways ending at this node have refs and others do not. In fact all ways going south from this point have the same tags, none has a ref tag. Another problem might be that those ways are connected with rather sharp angles. The road merger doesn't seem to be able to connect the parts.
I don't know why the ferry lines are split, but I would say this is very uncommon and probably also wrong because it somehow means that you have to jump from one ferry to another in the open sea.
So, I think the problem here is in the data. Comments?
Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 14. Juni 2017 18:30:40 An: Development list for mkgmap Betreff: AW: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries
Hi, I do not yet believe that the service roads are causing this. I saw +1000<tel:+1000>km detours when reverting a much shorter route. I cannot test it during the next weeks Ciao Gerd
---- Samuel Longiaru schrieb ----
Hi Andrzej,
I like the simplicity of the tag idea, but implementation I'm sure would be rather spotty. Adding the logic to mkgmap would make more sense I think as it would be immediately and universally applicable. As you say, there may be even more cases beyond the ferry setting where such logic could be applied, and if not accommodated by mkgmap, would need to be re-tagged in OSM.
On 17-06-14 05:17 AM, Andrzej Popowski wrote:
Hi Sam,
ferries get class 3 for routing, which is high. They should be easily used in routing when allowed in GPS.
If the problem really is low routing class of service roads, then I see 2 solutions:
Convince OSM mappers to add more tags for "highway=service". This could be for example "service=ferry". Or add any other indication, that these roads carry important traffic, for example include roads in a relation. Then this could be processed by mkgmap.
Second solution would be to try to catch the problem by mkgmap. I think there are more similar cases, where 2 important roads are connected by a link or roundabout with significantly lower routing class. Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I just tried to code a simple check in mkgmap to report ferry routes which are not connected to a routable way which is not a ferry route. I think the check works but reports many false positives for those areas where a ferry route ends in an area which is not included in the file downloaded from geofabrik. It would be possible to improve that check by adding code to read the polygon used by geofabrik, but maybe it would be better to add such a check in one of the QA tools. Comments? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Samstag, 29. Juli 2017 23:46:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries Hi Gerd, Thanks for looking into this again. The only reason I can think for this mapping technique is to make the piers at the ferry terminal independent of the ferry routes themselves. I don't know that terminal well enough to know whether certain routes only use certain piers, but independence is assured in theory if all the ferry routes join at one place just offshore. That in-the-water splitting is not in keeping with the wiki however, and it is perhaps on that basis that I could appeal on Talk-CA to see if someone can clean up the Tsawwassen and Swartz Bay terminal areas in some logical way. While ultimately, we would be asking for a fix to accommodate a routing engine, in this case, mapping for an engine is precisely the reason given in the wiki for not allowing such splitting. Your comment about jumping ship is pretty funny, but in fact may be relevant in that it could provide a routing that does not exist normally. For example, going through the Tsawwassen splitting point, one could construct a Duke Point - Mayne Island route, that in fact does not exist, according to the BC Ferry website. Thanks again, Sam On 17-07-29 12:44 AM, Gerd Petermann wrote:
Hi,
I think this problem still exists. I downloaded british-columbia-latest.osm.pbf and tried again today. Some routes changed, but overall ferry routing in this area is a mess. I think one reason is that the ferry lines are split, so that many lines connect somewhere in the ocean, e.g. here: https://www.openstreetmap.org/node/323308217 This alone should not be a problem, but some of the ways ending at this node have refs and others do not. In fact all ways going south from this point have the same tags, none has a ref tag. Another problem might be that those ways are connected with rather sharp angles. The road merger doesn't seem to be able to connect the parts.
I don't know why the ferry lines are split, but I would say this is very uncommon and probably also wrong because it somehow means that you have to jump from one ferry to another in the open sea.
So, I think the problem here is in the data. Comments?
Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 14. Juni 2017 18:30:40 An: Development list for mkgmap Betreff: AW: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries
Hi, I do not yet believe that the service roads are causing this. I saw +1000<tel:+1000>km detours when reverting a much shorter route. I cannot test it during the next weeks Ciao Gerd
---- Samuel Longiaru schrieb ----
Hi Andrzej,
I like the simplicity of the tag idea, but implementation I'm sure would be rather spotty. Adding the logic to mkgmap would make more sense I think as it would be immediately and universally applicable. As you say, there may be even more cases beyond the ferry setting where such logic could be applied, and if not accommodated by mkgmap, would need to be re-tagged in OSM.
On 17-06-14 05:17 AM, Andrzej Popowski wrote:
Hi Sam,
ferries get class 3 for routing, which is high. They should be easily used in routing when allowed in GPS.
If the problem really is low routing class of service roads, then I see 2 solutions:
Convince OSM mappers to add more tags for "highway=service". This could be for example "service=ferry". Or add any other indication, that these roads carry important traffic, for example include roads in a relation. Then this could be processed by mkgmap.
Second solution would be to try to catch the problem by mkgmap. I think there are more similar cases, where 2 important roads are connected by a link or roundabout with significantly lower routing class. Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, popej wrote
Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4.
This would not always help. See for example hw=service way 50330706 https://www.openstreetmap.org/way/50330706 One has to crawl through several service ways to find out that the ferry is connected with the hw=secondary way 475872377 https://www.openstreetmap.org/way/475872377 I see no easy way to implement an algo which would find out that this hw=secondary is the one that "delivers" the wanted road class. I fear this kind of mapping happens quite often. I would expect that the Garmin routing algo is aware of this when it comes to ferry lines, but did not yet test it. Gerd -- View this message in context: http://gis.19327.n8.nabble.com/Data-routing-issue-Vancouver-BC-ferries-tp589... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi all, I think the Garmin routing algo is probably too stupid when it comes to ferries. If I got that right the algo tries to get and stay(!) on major roads until it gets close to the target. This seems to be true for car and bicycle routing (faster or shorter also doesn't seem to matter) If such a route is found it is preferred to a much shorter ferry connection which involves a switch to class-0-roads, no matter how long it is, even if thes longer route also contains one or more ferry lines. So, if you select start and end point of your route close to the ferry terminals you are probably routed via the ferry. If your start is somewhere out of town so that you use a major road to get to the ferry terminal the ferry is probably not used. Many ferries in OSM are not connected to major roads, sometimes there are hw=residential or hw=unclassified and of course hw=service between the ferry line and the next major road, so I also don't see how mkgmap could "correct" this without risking unpredictable routing near ferry terminals. The only work around that I found so far is to select the ferry route as a part of the route, but this of course also means that you have to know that this ferry exits. Gerd Gerd Petermann wrote
Hi Andrzej, popej wrote
Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4. This would not always help. See for example hw=service way 50330706 https://www.openstreetmap.org/way/50330706
One has to crawl through several service ways to find out that the ferry is connected with the hw=secondary way 475872377 https://www.openstreetmap.org/way/475872377
I see no easy way to implement an algo which would find out that this hw=secondary is the one that "delivers" the wanted road class. I fear this kind of mapping happens quite often.
I would expect that the Garmin routing algo is aware of this when it comes to ferry lines, but did not yet test it.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/Data-routing-issue-Vancouver-BC-ferries-tp589... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Greetings, Just wanted to report that I have today downloaded a Lambertus map and tested my original routing from Kamloops to a random street address in Victoria and see that it is now routing properly via the Tsawwassen-Swartz Bay ferry. It is also now routing properly to several other locations on the mainland that I was previously having trouble with. I had a quick look at the data and don't see any recent changes - particularly the ferries from Tsawwassen and from Swartz Bay still join at a single node offshore - but things seems to be routing properly on my Nuvi now. Just speculating that some of the more recent changes (such as Andrzej's routing patch r3979?) or elsewhere might have had a positive impact on this problem. Excellent! Sam On 17-08-06 12:12 AM, Gerd Petermann wrote:
Hi all,
I think the Garmin routing algo is probably too stupid when it comes to ferries. If I got that right the algo tries to get and stay(!) on major roads until it gets close to the target. This seems to be true for car and bicycle routing (faster or shorter also doesn't seem to matter) If such a route is found it is preferred to a much shorter ferry connection which involves a switch to class-0-roads, no matter how long it is, even if thes longer route also contains one or more ferry lines.
So, if you select start and end point of your route close to the ferry terminals you are probably routed via the ferry. If your start is somewhere out of town so that you use a major road to get to the ferry terminal the ferry is probably not used.
Many ferries in OSM are not connected to major roads, sometimes there are hw=residential or hw=unclassified and of course hw=service between the ferry line and the next major road, so I also don't see how mkgmap could "correct" this without risking unpredictable routing near ferry terminals.
The only work around that I found so far is to select the ferry route as a part of the route, but this of course also means that you have to know that this ferry exits.
Gerd
Gerd Petermann wrote
Hi Andrzej, popej wrote
Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4. This would not always help. See for example hw=service way 50330706 https://www.openstreetmap.org/way/50330706
One has to crawl through several service ways to find out that the ferry is connected with the hw=secondary way 475872377 https://www.openstreetmap.org/way/475872377
I see no easy way to implement an algo which would find out that this hw=secondary is the one that "delivers" the wanted road class. I fear this kind of mapping happens quite often.
I would expect that the Garmin routing algo is aware of this when it comes to ferry lines, but did not yet test it.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/Data-routing-issue-Vancouver-BC-ferries-tp589... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Samuel, did you try to revert the good routes? When I tried that I always saw very different routes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Samstag, 19. August 2017 20:13:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries Greetings, Just wanted to report that I have today downloaded a Lambertus map and tested my original routing from Kamloops to a random street address in Victoria and see that it is now routing properly via the Tsawwassen-Swartz Bay ferry. It is also now routing properly to several other locations on the mainland that I was previously having trouble with. I had a quick look at the data and don't see any recent changes - particularly the ferries from Tsawwassen and from Swartz Bay still join at a single node offshore - but things seems to be routing properly on my Nuvi now. Just speculating that some of the more recent changes (such as Andrzej's routing patch r3979?) or elsewhere might have had a positive impact on this problem. Excellent! Sam On 17-08-06 12:12 AM, Gerd Petermann wrote:
Hi all,
I think the Garmin routing algo is probably too stupid when it comes to ferries. If I got that right the algo tries to get and stay(!) on major roads until it gets close to the target. This seems to be true for car and bicycle routing (faster or shorter also doesn't seem to matter) If such a route is found it is preferred to a much shorter ferry connection which involves a switch to class-0-roads, no matter how long it is, even if thes longer route also contains one or more ferry lines.
So, if you select start and end point of your route close to the ferry terminals you are probably routed via the ferry. If your start is somewhere out of town so that you use a major road to get to the ferry terminal the ferry is probably not used.
Many ferries in OSM are not connected to major roads, sometimes there are hw=residential or hw=unclassified and of course hw=service between the ferry line and the next major road, so I also don't see how mkgmap could "correct" this without risking unpredictable routing near ferry terminals.
The only work around that I found so far is to select the ferry route as a part of the route, but this of course also means that you have to know that this ferry exits.
Gerd
Gerd Petermann wrote
Hi Andrzej, popej wrote
Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4. This would not always help. See for example hw=service way 50330706 https://www.openstreetmap.org/way/50330706
One has to crawl through several service ways to find out that the ferry is connected with the hw=secondary way 475872377 https://www.openstreetmap.org/way/475872377
I see no easy way to implement an algo which would find out that this hw=secondary is the one that "delivers" the wanted road class. I fear this kind of mapping happens quite often.
I would expect that the Garmin routing algo is aware of this when it comes to ferry lines, but did not yet test it.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/Data-routing-issue-Vancouver-BC-ferries-tp589... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
OK... just tried going from Victoria back to Kamloops and you're correct, it yields a crazy route of 1875 km going way up to the northern tip of the island, then back down, then down into the US and southeastern Washington, then back, then finally off towards Kamloops ... not taking the Swartz Bay - Tsawwassen ferry at all. Grrr... Some progress however! As long as you never want to get home. Sam On 17-08-19 11:20 AM, Gerd Petermann wrote:
Hi Samuel,
did you try to revert the good routes? When I tried that I always saw very different routes.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Samstag, 19. August 2017 20:13:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries
Greetings,
Just wanted to report that I have today downloaded a Lambertus map and tested my original routing from Kamloops to a random street address in Victoria and see that it is now routing properly via the Tsawwassen-Swartz Bay ferry. It is also now routing properly to several other locations on the mainland that I was previously having trouble with.
I had a quick look at the data and don't see any recent changes - particularly the ferries from Tsawwassen and from Swartz Bay still join at a single node offshore - but things seems to be routing properly on my Nuvi now.
Just speculating that some of the more recent changes (such as Andrzej's routing patch r3979?) or elsewhere might have had a positive impact on this problem.
Excellent!
Sam
On 17-08-06 12:12 AM, Gerd Petermann wrote:
Hi all,
I think the Garmin routing algo is probably too stupid when it comes to ferries. If I got that right the algo tries to get and stay(!) on major roads until it gets close to the target. This seems to be true for car and bicycle routing (faster or shorter also doesn't seem to matter) If such a route is found it is preferred to a much shorter ferry connection which involves a switch to class-0-roads, no matter how long it is, even if thes longer route also contains one or more ferry lines.
So, if you select start and end point of your route close to the ferry terminals you are probably routed via the ferry. If your start is somewhere out of town so that you use a major road to get to the ferry terminal the ferry is probably not used.
Many ferries in OSM are not connected to major roads, sometimes there are hw=residential or hw=unclassified and of course hw=service between the ferry line and the next major road, so I also don't see how mkgmap could "correct" this without risking unpredictable routing near ferry terminals.
The only work around that I found so far is to select the ferry route as a part of the route, but this of course also means that you have to know that this ferry exits.
Gerd
Gerd Petermann wrote
Hi Andrzej, popej wrote
Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4. This would not always help. See for example hw=service way 50330706 https://www.openstreetmap.org/way/50330706
One has to crawl through several service ways to find out that the ferry is connected with the hw=secondary way 475872377 https://www.openstreetmap.org/way/475872377
I see no easy way to implement an algo which would find out that this hw=secondary is the one that "delivers" the wanted road class. I fear this kind of mapping happens quite often.
I would expect that the Garmin routing algo is aware of this when it comes to ferry lines, but did not yet test it.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/Data-routing-issue-Vancouver-BC-ferries-tp589... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Samuel, I really think that someone has to fix the OSM data in this case. The next JOSM release will complain about the existing data, see also https://josm.openstreetmap.de/ticket/15097 Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Samstag, 19. August 2017 21:21:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries OK... just tried going from Victoria back to Kamloops and you're correct, it yields a crazy route of 1875 km going way up to the northern tip of the island, then back down, then down into the US and southeastern Washington, then back, then finally off towards Kamloops ... not taking the Swartz Bay - Tsawwassen ferry at all. Grrr... Some progress however! As long as you never want to get home. Sam On 17-08-19 11:20 AM, Gerd Petermann wrote:
Hi Samuel,
did you try to revert the good routes? When I tried that I always saw very different routes.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Samuel Longiaru <longiaru@shaw.ca> Gesendet: Samstag, 19. August 2017 20:13:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Data / routing issue - Vancouver, BC ferries
Greetings,
Just wanted to report that I have today downloaded a Lambertus map and tested my original routing from Kamloops to a random street address in Victoria and see that it is now routing properly via the Tsawwassen-Swartz Bay ferry. It is also now routing properly to several other locations on the mainland that I was previously having trouble with.
I had a quick look at the data and don't see any recent changes - particularly the ferries from Tsawwassen and from Swartz Bay still join at a single node offshore - but things seems to be routing properly on my Nuvi now.
Just speculating that some of the more recent changes (such as Andrzej's routing patch r3979?) or elsewhere might have had a positive impact on this problem.
Excellent!
Sam
On 17-08-06 12:12 AM, Gerd Petermann wrote:
Hi all,
I think the Garmin routing algo is probably too stupid when it comes to ferries. If I got that right the algo tries to get and stay(!) on major roads until it gets close to the target. This seems to be true for car and bicycle routing (faster or shorter also doesn't seem to matter) If such a route is found it is preferred to a much shorter ferry connection which involves a switch to class-0-roads, no matter how long it is, even if thes longer route also contains one or more ferry lines.
So, if you select start and end point of your route close to the ferry terminals you are probably routed via the ferry. If your start is somewhere out of town so that you use a major road to get to the ferry terminal the ferry is probably not used.
Many ferries in OSM are not connected to major roads, sometimes there are hw=residential or hw=unclassified and of course hw=service between the ferry line and the next major road, so I also don't see how mkgmap could "correct" this without risking unpredictable routing near ferry terminals.
The only work around that I found so far is to select the ferry route as a part of the route, but this of course also means that you have to know that this ferry exits.
Gerd
Gerd Petermann wrote
Hi Andrzej, popej wrote
Mkgmap could include following algorithm:
Find all suspicious objects, like highway links, roundabouts, service roads connected to a ferry and analyze other roads connected to this object. If any of these other roads get road_class 3 or 4, then increase road_class of processed object accordingly to 3 or 4. This would not always help. See for example hw=service way 50330706 https://www.openstreetmap.org/way/50330706
One has to crawl through several service ways to find out that the ferry is connected with the hw=secondary way 475872377 https://www.openstreetmap.org/way/475872377
I see no easy way to implement an algo which would find out that this hw=secondary is the one that "delivers" the wanted road class. I fear this kind of mapping happens quite often.
I would expect that the Garmin routing algo is aware of this when it comes to ferry lines, but did not yet test it.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/Data-routing-issue-Vancouver-BC-ferries-tp589... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Andrzej Popowski -
Gerd Petermann -
Gerd Petermann
-
Samuel Longiaru -
Ticker Berkin