Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd I don't have a record of when I was last faced with a route through the type of area I mentioned, only to find it was not possible. Given it has happened to me a few times, I'd say there is a very high probability that there are many similar instances. To stop this happening again I used mkgmap:way-has-pois, possibly being some form of barrier, to inhibit through-routing. However this caused the problem I encountered last week where eTrex 30/BaseCamp will use a footpath to access the area instead of the road. I can give you the real example for this. mkgmap:way-has-pois is far too crude a test which is why I've implemented the mkgmap:poi-barrier and mkgmap:poi-highway lists of the actual POI types on the way. There is no perfect solution, but the new variable are an improvement. Ticker On Thu, 2022-02-17 at 13:48 +, 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 im Auftrag > von Ticker Berkin > 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 +, 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 im Auftrag > > von Ticker Berkin > > 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 +, 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 im > > > Auftrag > > > von Ticker Berkin > > > 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).*"
Re: [mkgmap-dev] option link-pois-to-ways information
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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
Re: [mkgmap-dev] option link-pois-to-ways information
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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
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 +, 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 im Auftrag
> von Ticker Berkin
> 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
Re: [mkgmap-dev] option link-pois-to-ways information
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 im Auftrag von Ticker
Berkin
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
On Tue, 2022-02-15 at 16:41 +, Ticker Berkin wrote:
> Hi Gerd
>
> highway=street_lamp was just an example of a POI that can get linked
> to
> a WAY that can be ignored. There are others that are valid OSM
> tagging
> that are irrelevant to the highway behaviour.
>
> Actually, regardless of --link-pois-to-ways, there is a problem in
> the
> scenario where there is typical road system linked to a small road
> system by just a road with mkgmap:throughroute=no and a footway.
> BaseCamp and the eTrex 30x really will route over the footway to get
> into the small road system. MapSource and, I think, the eTrex HCx
> will
> use the road.
>
> I realise that this set-up seems unlikely, but can happen if there is
> an inconsistency in the tagging of roads in the small system that
> results in one not having mkgmap:throughroute=no that is joined to
> the
> footway. My example happened in a business park.
>
> My style makes this problem more likely to happen, while also trying
> to
> fix it, by not setting mkgmap:throughroute=no unless there seems to
> be
> a good reason for it. Good reasons are when there is a barrier on a
> service road. This is the test I want to improve.
>
> Ticker
>
> On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > if you find highway=street_lamp nodes on highway=* ways those are
> > errors and should be fixed in OSM.
> > Street lamps are normally mapped along the road, not on the road.
> >
> > Maybe you meant highway=traffic_signals?
> >
> > Besides that Basecamp should never route a car over a footway. That
> > sounds like an error in the map data produced by mkgmap
> > or maybe you used wrong routing settings. Please let me know how to
> > reproduce.
> >
> > No idea if your proposed change would improve routing, but feel
> > free
> > to experiment with that.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Dienstag, 15. Februar 2022 13:37
> > An: mkgmap development
> > Betreff: [mkgmap-dev] option link-pois-to-ways information
> >
> > Hi all
> >
> > To improve routing, I'd like to get information about the POIS that
> > are
> > being linked to a WAY that can be used as part of the style/lines
> > processing.
> >
> > The problem I'm trying to solve is to restrict car routing through
> > some
> > types of very low level roads (eg service) when there is a barrier.
> > Setting mkgmap:throughroute=no on these works nicely with MapSource
> > and
> > older devices but BaseCamp and newer devices will happily route
> > over
> > a
> > footpath to avoid a throughroute=no section.
> >
> > At the moment, with --link-pois-to-ways, if the POI has a barrier
> > or
> > highway tag, mkgmap:way-has-pois is set true. This can be tested by
> > lines, inc/access etc, but there is no way to find out if it is a
> > significant barrier or something like highway=street_lamp.
> >
> > points processing can set mkgmap: access & road_speed/class
> > variables
> > that are handled by inbuild code after lines processing to imposes
> > more
> > restrictions on the way and/or reduces speed/class; this is no use
> > for
> > what I want to do.
> >
> > Possibilities are:
> > 1/ have options to say which POI tag/value combinations cause
> >link-pois-to-ways
> > 2/ set new variables on the way, eg
> > mkgmap:barrier_tags/highway_tags,
> >which are a list of distinct POI highway/barrier tag values.
> >
> > 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
>
