Hi Gerd My problem is relating to car routing and highway=service where no explicit access is specified, For driveways I set access=private. For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier. Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem. My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no Ticker On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois-to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker