[mkgmap-dev] Turn Restrictions using three ways - design guide for OSM mappers?

Fri Oct 11 08:10:19 BST 2019

Hi blc,

mkgmap checks restriction relations for obvious formal errors like missing "from" ways or a "via" node that is not at the end of the way. If the relation is formally correct mkgmap tries to translate it as good as possible.
Nothing in OSM is directly supported by the Garmin IMG format, they are completely different and that's the reason for the tool mkgmap.
So, if you think that turn restrictions with "via"-ways are more likely wrong than right I may add an option to ignore them completely.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von blc <blc at mail.vanade.com>
Gesendet: Freitag, 11. Oktober 2019 08:35
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Turn Restrictions using three ways - design guide for OSM mappers?

On Wed, 9 Oct 2019, Gerd Petermann wrote:

> I still think both restrictions are probably not correctly mapped, but
> that's a different story now.

Thanks, this is what I wanted to know, if the original mapper made a
mistake or not - I'm concerned because of the apparent handling
discrepancy between different tools.  But what I didn't know before this
is that the Garmin doesn't directly support the only-X construct.  This
changes my opinion about this.

> I try to find a way to add the additional restrictiions to the IMG file.

No worries, I just wanted to make sure that if anyone fixes OSM data due
to a warning in mkgmap that it is a real violation of methodology (like a
restriction relation that was missing members/less than 3 members), not
because of a Garmin limitation of some sort.

I see that there was a code change proposal, I wish I could run it but I
don't have the capability to do so at this time.  However from the
programmer side of me I'm a bit concerned about handling changing only-X
-> multiple no-Y's because of potential errors in mapping causing a huge
bloat of erroneous restrictions.  At this point I wouldn't touch the
multiple via ways (relation having two or more vias ways) even though it
is also "supported" by OSM data, not sure if it should be handled, as it
may be an error.  I've also seen some fairly complex interchanges that
have these via-as-way and hope that the code does the right thing every
time.  I'd probably only limit this to one way-via only-X restrictions if
anything - if there is any uncertainty on how to handle this, just leave
it the way it was!

Thanks for helping me understand this better, I didn't expect any code
edits, especially if the Garmin doesn't support these directly.
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev