Re: [mkgmap-dev] option link-pois-to-ways information
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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
Re: [mkgmap-dev] option link-pois-to-ways information
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 im Auftrag von Ticker
Berkin
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 +, 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
> &
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 +, 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 lis
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 &g
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
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
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Eric,
the dead-end-check is performed if the corresponding option --report-dead-end
is given
It is done after(!) the style rules were processed and the road network is
known.
A dead-end is a place on a oneway road where you can either no go back from or
not come to
with a vehicle.
No idea how this is related to your service roads problem.
Gerd
Von: mkgmap-dev im Auftrag von
ankeric@gmail.com
Gesendet: Mittwoch, 16. Februar 2022 11:57
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd,
Question ("On Topic" or "Off Topic"):
Has mkgmap (Internal tags) an option to "Set mkgmap:dead-end = true"?
I do read:
mkgmap:dead-end-check Set to false to disable the dead-end-check for a
specific way report-dead-ends
But: what is "dead-end-check"?
I would like to have this option:
highway=service | highway=track & mkgmap:dead-end = true {set access=private}
(Do not ignore a dead-end mountain valley, f.i.)
(OsmAnd can handle "access=private". Garmin cannot, but I can manually ignore)
I do use:
bicycle=destination { set highway=service; set bicycle=yes; set
mkgmap:throughroute=no }
But I don't use:
"mkgmap:throughroute=no" for navigation. So: useless???
Because I don't know how to...
BTW, FWIW:
In the Netherlands "they" have set {access=private} on ALL "highway=service"
"service=driveway" (oké, only in my region).
Making Address navigation by Garmin impossible.
AnkEric
-Original Message-
From: mkgmap-dev On Behalf Of Gerd
Petermann
Sent: woensdag 16 februari 2022 10:25
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Ticker,
reg. routing problems in Basecamp: Maybe you hit the problem described for
--max-routing-island-len?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 15. Februar 2022 17:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
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.
&
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd I've been testing with all the routing-island options set to -1 and the small road network has 2 connections to the wider network, so I don't think it is related. If the destination in the small network is only accessible by (joined, I think, but not tested) roads with throughroute=no, then it uses them rather than the footpath. If there is no footpath, so the only access to the destination (on a throughRoute) is via a throughRoute=no, it resorts to straigh-line routine All above is Basecamp. Mapsource overrides throughRoute=no instead of car=no Ticker On Wed, 2022-02-16 at 09:25 +, Gerd Petermann wrote: > Hi Ticker, > > reg. routing problems in Basecamp: Maybe you hit the problem > described for --max-routing-island-len? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 15. Februar 2022 17:41 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] option link-pois-to-ways information > > 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. > > > > Tic
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd,
Question ("On Topic" or "Off Topic"):
Has mkgmap (Internal tags) an option to "Set mkgmap:dead-end = true"?
I do read:
mkgmap:dead-end-check Set to false to disable the dead-end-check for a
specific way report-dead-ends
But: what is "dead-end-check"?
I would like to have this option:
highway=service | highway=track & mkgmap:dead-end = true {set access=private}
(Do not ignore a dead-end mountain valley, f.i.)
(OsmAnd can handle "access=private". Garmin cannot, but I can manually ignore)
I do use:
bicycle=destination { set highway=service; set bicycle=yes; set
mkgmap:throughroute=no }
But I don't use:
"mkgmap:throughroute=no" for navigation. So: useless???
Because I don't know how to...
BTW, FWIW:
In the Netherlands "they" have set {access=private} on ALL "highway=service"
"service=driveway" (oké, only in my region).
Making Address navigation by Garmin impossible.
AnkEric
-Original Message-
From: mkgmap-dev On Behalf Of Gerd
Petermann
Sent: woensdag 16 februari 2022 10:25
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Ticker,
reg. routing problems in Basecamp: Maybe you hit the problem described for
--max-routing-island-len?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 15. Februar 2022 17:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
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
>
>
>
> ___
Re: [mkgmap-dev] option link-pois-to-ways information
Hi Ticker, reg. routing problems in Basecamp: Maybe you hit the problem described for --max-routing-island-len? Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 15. Februar 2022 17:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information 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 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 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 https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] option link-pois-to-ways information
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] 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
Re: [mkgmap-dev] Option "link pois to ways"
Hi Dave, The routing is done by Garmin software, so we don't know all details. The (old) img format doesn't have much room for details. The road-speed and road-class are probably the most important values, besides the access restrictions. The Garmin algo also calculates angles at crossings and doesn't like to make sharp turns when in car mode. For long distance routing in car mode the algo prefers to get on a major road and use that as long as possible. So, in short, a bunch of traffic signals may reduce the avg. speed, but my understanding is that this depends much more on the time of the day (rush hour) . I also don't like the idea that the device routes me through rather small roads to avoid a crossing with traffic signals. I know such a place in my neighbourhood and the "clever" route is used by many cars, even though it goes through a tempo 30 zone and across bumpers. Gerd Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Dave Swarthout <daveswarth...@gmail.com> Gesendet: Montag, 22. Februar 2016 00:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Option "link pois to ways" So, the number of traffic_signals encountered on one route vs another route isn't even a factor in mkgmp routing? I have been adding traffic_signals to my workload for the past year in hopes it would improve routing accuracy. How then does routing get calculated? On my Garmin there is a choice for "fastest" vs. "shortest" routes. Usually this choice doesn't make much difference in the overall time involved for a traverse along a route and I always assumed it was because here in Thailand so few of our highways have maxspeed tags. How are these two routing choices handled by makgmap? Sorry for the extra questions but I am curious to know these things. Cheers, Dave On Mon, Feb 22, 2016 at 12:23 AM, Jakob Mühldorfer <m...@jmuehldorfer.de<mailto:m...@jmuehldorfer.de>> wrote: Oh, allright. Maybe if you have time some day, you could look into it again. I think there are some use cases. One example where the OSRM traffic light penalty for example seems to have chosen the clever way around the traffic light: https://www.openstreetmap.org/directions?engine=osrm_car=51.05581%2C13.72190%3B51.05522%2C13.71881#map=19/51.05541/13.72034 Regards Jakob Am 21.02.2016 um 18:19 schrieb Gerd Petermann: Hi Jakob, I think this cannot be done with rules, it requires new java code. I thought about this a while ago and stoped because I doubted that this would improve routing. Gerd Von: mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Jakob Mühldorfer <m...@jmuehldorfer.de<mailto:m...@jmuehldorfer.de>> Gesendet: Sonntag, 21. Februar 2016 17:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Option "link pois to ways" Hi Gerd, this would be the best solution I think. So far I found a rule that lowers the speed for the complete road with the traffic light, do you have one that splits it and adds a lower speed only on a part, like you said? Thanks Jakob Am 21.02.2016 um 17:57 schrieb Gerd Petermann: Hi Jakob, the current code ignores nodes with highway=traffic_signals. If I got you right you want to split a road maybe 30 m before the node with highway=traffic_signals and 30 after and set a lower road-speed value for that 60m part? Gerd Von: mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Jakob Mühldorfer <m...@jmuehldorfer.de<mailto:m...@jmuehldorfer.de>> Gesendet: Sonntag, 21. Februar 2016 17:31 An: Development list for mkgmap Betreff: [mkgmap-dev] Option "link pois to ways" Hi, one more question I was not able to figure out from documentation or source. When the option "link pois to ways" is used, does it automatically process traffic signals in a way that adds a time penalty for routing through them in the map data. Thanks for help on that Jakob ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk&g
Re: [mkgmap-dev] Option "link pois to ways"
So, the number of traffic_signals encountered on one route vs another route isn't even a factor in mkgmp routing? I have been adding traffic_signals to my workload for the past year in hopes it would improve routing accuracy. How then does routing get calculated? On my Garmin there is a choice for "fastest" vs. "shortest" routes. Usually this choice doesn't make much difference in the overall time involved for a traverse along a route and I always assumed it was because here in Thailand so few of our highways have maxspeed tags. How are these two routing choices handled by makgmap? Sorry for the extra questions but I am curious to know these things. Cheers, Dave On Mon, Feb 22, 2016 at 12:23 AM, Jakob Mühldorfer <m...@jmuehldorfer.de> wrote: > Oh, allright. > Maybe if you have time some day, you could look into it again. I think > there are some use cases. > One example where the OSRM traffic light penalty for example seems to have > chosen the clever way around the traffic light: > > https://www.openstreetmap.org/directions?engine=osrm_car=51.05581%2C13.72190%3B51.05522%2C13.71881#map=19/51.05541/13.72034 > > Regards > Jakob > > > Am 21.02.2016 um 18:19 schrieb Gerd Petermann: > >> Hi Jakob, >> >> I think this cannot be done with rules, it requires new java code. >> I thought about this a while ago and stoped because I doubted that this >> would improve routing. >> >> Gerd >> >> >> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer < >> m...@jmuehldorfer.de> >> Gesendet: Sonntag, 21. Februar 2016 17:59 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] Option "link pois to ways" >> >> Hi Gerd, >> >> this would be the best solution I think. >> So far I found a rule that lowers the speed for the complete road with >> the traffic light, do you have one that splits it and adds a lower speed >> only on a part, like you said? >> >> Thanks >> Jakob >> >> Am 21.02.2016 um 17:57 schrieb Gerd Petermann: >> >>> Hi Jakob, >>> >>> the current code ignores nodes with highway=traffic_signals. >>> If I got you right you want to split a road maybe 30 m before the node >>> with >>> highway=traffic_signals and 30 after and set a lower road-speed value >>> for that 60m part? >>> >>> Gerd >>> >>> >>> >>> >>> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk < >>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer >>> <m...@jmuehldorfer.de> >>> Gesendet: Sonntag, 21. Februar 2016 17:31 >>> An: Development list for mkgmap >>> Betreff: [mkgmap-dev] Option "link pois to ways" >>> >>> Hi, >>> >>> one more question I was not able to figure out from documentation or >>> source. >>> When the option "link pois to ways" is used, does it automatically >>> process traffic signals in a way that adds a time penalty for routing >>> through them in the map data. >>> >>> Thanks for help on that >>> Jakob >>> ___ >>> mkgmap-dev mailing list >>> mkgmap-dev@lists.mkgmap.org.uk >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> ___ >>> mkgmap-dev mailing list >>> mkgmap-dev@lists.mkgmap.org.uk >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option "link pois to ways"
Hi Jakob, the current code ignores nodes with highway=traffic_signals. If I got you right you want to split a road maybe 30 m before the node with highway=traffic_signals and 30 after and set a lower road-speed value for that 60m part? Gerd Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer <m...@jmuehldorfer.de> Gesendet: Sonntag, 21. Februar 2016 17:31 An: Development list for mkgmap Betreff: [mkgmap-dev] Option "link pois to ways" Hi, one more question I was not able to figure out from documentation or source. When the option "link pois to ways" is used, does it automatically process traffic signals in a way that adds a time penalty for routing through them in the map data. Thanks for help on that Jakob ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Option "link pois to ways"
Hi, one more question I was not able to figure out from documentation or source. When the option "link pois to ways" is used, does it automatically process traffic signals in a way that adds a time penalty for routing through them in the map data. Thanks for help on that Jakob ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
