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

Mon Feb 21 08:57:23 GMT 2022

Hi Gerd

Judging by the lack of posts and changes relating to precise access
handling and its effects on routeing, I doubt if there will be anyone
else who says they need this.

The proposed mkgmap:poi-{highway,barrier} variables are much more use
than mkgmap:way-has-pois, which isn't used by any of the styles
provided by mkgmap.

My version of inc/access[_country] handles the more subtle features of
OSM access and maps them onto Garmin in an accurate manner.

However there isn't one solutions for service roads where access hasn't
been specified; sometimes through-routeing should be prevented,
sometimes not. There isn't a reliable method to decide, but POI
barriers on the road are a good hint.

If your concern is efficiency, I can probably improve the hook logic so
that it is better than before while still implementing the new
variables. If you don't like the names I can change them.

Ticker

On Thu, 2022-02-17 at 13:48 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> so really not a single real world OSM example for me?
> 
> Anyway, my concern about this is that you combine it with the option
> that possibly creates a route restriction or
> causes a split of the way and I don't see how this is related.
> 
> Let's see if anybody else wants this.
> 
> 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 13:39
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
> 
> 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
> 
> 
> _______________________________________________
> 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