Hi Gerd
The new variable will be of use (certainly to me) and I'll document
them in the style guide as clearly as possible.
The problem I'm trying to solve might seem special, but I make heavy
use of routing and, when driving or walking somewhere, the device
instructions call for the impossible or ridiculous, I look at the
reasons why it happened at that location and fix it. I don't want the
same thing to happen in locations I haven't been to yet, so, if the
scenario is plausibly common I might need to look for other hints to
guide the access decisions.
Most problems have been handled by getting the subtleties correct in
access[_country]. Some by fixing the tagging. This leaves, as a
significant problem, clusters of service roads where the mappers don't
know the precise access rights and so don't commit to these in OSM.
They might, however, mark barriers etc that can be seen from the aerial
photography.
Ticker
On Mon, 2022-02-21 at 09:16 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> the special tag mkgmap:way-has-pois was never meant to be used by the
> style,
> it could have been another bit flag in class Way as it was for
> internal use.
> I wasn't happy to document it in the first place as it is of no use
> for style authors.
>
> My concern is that these tags are really confusing for those who
> don't understand
> the logic behind them. We have so many internal tags and the current
> style manual
> sometimes fails to make clear if those tags are set by mkgmap before
> the style
> is used or read by mkgmap after the style is used.
>
> Besides that the problem that you want to solve seems quite special.
> Since you
> have no examples I may not understand what problem it is but my
> current
> understanding is that you had some mistagged OSM ways which happened
> to have
> a barrier node which probably also missed proper access tags.
> Adding a special rule for those is likely to cause trouble somewhere
> else.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Montag, 21. Februar 2022 09:57
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
>
> 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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@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-boun...@lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkg...@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-boun...@lists.mkgmap.org.uk> im
> > > > Auftrag
> > > > von Ticker Berkin <rwb-mkg...@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@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> >
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
