Data / routing issue - Vancouver, BC ferries

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Data / routing issue - Vancouver, BC ferries

Samuel Longiaru
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
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 <[hidden email]> im Auftrag von Samuel Longiaru <[hidden email]>
Gesendet: Dienstag, 13. Juni 2017 07:39:37
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Ticker Berkin
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 <[hidden email]> im Auftrag
> von Samuel Longiaru <[hidden email]>
> Gesendet: Dienstag, 13. Juni 2017 07:39:37
> An: [hidden email]
> 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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

popej
In reply to this post by Samuel Longiaru
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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Samuel Longiaru
In reply to this post by Samuel Longiaru

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=ferry, this tag can take the 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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

popej
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



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Samuel Longiaru
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
Hi,
I do not yet believe that the service roads are causing this. I saw <a href="tel:&#43;1000"> +1000km 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
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 <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Samuel Longiaru
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 <[hidden email]>
> 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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
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 <[hidden email]> im Auftrag von Samuel Longiaru <[hidden email]>
Gesendet: Samstag, 29. Juli 2017 23:46:12
An: [hidden email]
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 <[hidden email]>
> 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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
In reply to this post by popej
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
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
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
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Samuel Longiaru
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-tp5897857p5900357.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
Hi Samuel,

did you try to revert the good routes? When I tried that I always saw very different routes.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Samuel Longiaru <[hidden email]>
Gesendet: Samstag, 19. August 2017 20:13:04
An: [hidden email]
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-tp5897857p5900357.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Samuel Longiaru
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 <[hidden email]> im Auftrag von Samuel Longiaru <[hidden email]>
> Gesendet: Samstag, 19. August 2017 20:13:04
> An: [hidden email]
> 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-tp5897857p5900357.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> [hidden email]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Data / routing issue - Vancouver, BC ferries

Gerd Petermann
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 <[hidden email]> im Auftrag von Samuel Longiaru <[hidden email]>
Gesendet: Samstag, 19. August 2017 21:21:57
An: [hidden email]
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 <[hidden email]> im Auftrag von Samuel Longiaru <[hidden email]>
> Gesendet: Samstag, 19. August 2017 20:13:04
> An: [hidden email]
> 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-tp5897857p5900357.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> [hidden email]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev