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-boun...@lists.mkgmap.org.uk> im Auftrag von blc <b...@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 email@example.com http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list firstname.lastname@example.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev