logo separator

[mkgmap-dev] option link-pois-to-ways information

From Ticker Berkin rwb-mkgmap at jagit.co.uk on Thu Feb 17 12:39:09 GMT 2022

Hi Gerd

These cases happen in retail/business/industry/leisure/holiday parks
and similar.

Typical problems are:
a) Being routed through because there was no tagging to suggest that
this isn't permissible or even possible.
b) Routing choosing the wrong way to get into the area.
c) Valid walking ways inhibited by either bad tagging or incorrect
logic in inc/access

When I encounter a problem, I look at the tagging to see why it has
happened, and, if blatantly wrong, fix it.

Mostly, however, I don't want to change access rules on clusters of
roads (mostly service) that I know nothing about concerning rights of
way, etc.

I then see if I can fix or enhance inc/access to handle the scenario
better for next time.

There is no perfect solution but, doing a lot of walking and driving to
obscure places I am less frequently faced with wrong routing decisions.

Ticker

On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> with examples I meant links to OSM ways.
> 
> My current understanding is that these OSM ways may need different
> tagging.
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 17. Februar 2022 10:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
> 
> 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 at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at 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
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




More information about the mkgmap-dev mailing list