[mkgmap-dev] Data / routing issue - Vancouver, BC ferries

Sat Jul 29 22:46:12 BST 2017

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 at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev