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
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
Hi Ticker, reg. routing problems in Basecamp: Maybe you hit the problem described for --max-routing-island-len? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Gerd Petermann Sent: woensdag 16 februari 2022 10:25 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von ankeric.osm@gmail.com <ankeric.osm@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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Gerd Petermann Sent: woensdag 16 februari 2022 10:25 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
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 +0000, 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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
Hi Ticker, I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing. Please give me some examples for highways where this would help. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information Hi Gerd Attached a patch to create 2 mkgmap: variables when --link-pois-to-ways operates. mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination} If you are happy with this I'll update the Style Manual. Ticker On Tue, 2022-02-15 at 16:41 +0000, 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 +0000, 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
Hi Gerd My problem is relating to car routing and highway=service where no explicit access is specified, For driveways I set access=private. For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier. Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem. My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no Ticker On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois-to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
Hi Ticker, with examples I meant links to OSM ways. My current understanding is that these OSM ways may need different tagging. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information Hi Gerd My problem is relating to car routing and highway=service where no explicit access is specified, For driveways I set access=private. For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier. Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem. My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no Ticker On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois-to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd These cases happen in retail/business/industry/leisure/holiday parks and similar. Typical problems are: a) Being routed through because there was no tagging to suggest that this isn't permissible or even possible. b) Routing choosing the wrong way to get into the area. c) Valid walking ways inhibited by either bad tagging or incorrect logic in inc/access When I encounter a problem, I look at the tagging to see why it has happened, and, if blatantly wrong, fix it. Mostly, however, I don't want to change access rules on clusters of roads (mostly service) that I know nothing about concerning rights of way, etc. I then see if I can fix or enhance inc/access to handle the scenario better for next time. There is no perfect solution but, doing a lot of walking and driving to obscure places I am less frequently faced with wrong routing decisions. Ticker On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
Hi Ticker,
with examples I meant links to OSM ways.
My current understanding is that these OSM ways may need different tagging.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
My problem is relating to car routing and highway=service where no explicit access is specified,
For driveways I set access=private.
For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier.
Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem.
My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no
Ticker
On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois-to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, so really not a single real world OSM example for me? Anyway, my concern about this is that you combine it with the option that possibly creates a route restriction or causes a split of the way and I don't see how this is related. Let's see if anybody else wants this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 13:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information Hi Gerd These cases happen in retail/business/industry/leisure/holiday parks and similar. Typical problems are: a) Being routed through because there was no tagging to suggest that this isn't permissible or even possible. b) Routing choosing the wrong way to get into the area. c) Valid walking ways inhibited by either bad tagging or incorrect logic in inc/access When I encounter a problem, I look at the tagging to see why it has happened, and, if blatantly wrong, fix it. Mostly, however, I don't want to change access rules on clusters of roads (mostly service) that I know nothing about concerning rights of way, etc. I then see if I can fix or enhance inc/access to handle the scenario better for next time. There is no perfect solution but, doing a lot of walking and driving to obscure places I am less frequently faced with wrong routing decisions. Ticker On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
Hi Ticker,
with examples I meant links to OSM ways.
My current understanding is that these OSM ways may need different tagging.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
My problem is relating to car routing and highway=service where no explicit access is specified,
For driveways I set access=private.
For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier.
Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem.
My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no
Ticker
On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois-to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +0000, Gerd Petermann wrote:
Hi Ticker,
so really not a single real world OSM example for me?
Anyway, my concern about this is that you combine it with the option that possibly creates a route restriction or causes a split of the way and I don't see how this is related.
Let's see if anybody else wants this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 13:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
These cases happen in retail/business/industry/leisure/holiday parks and similar.
Typical problems are: a) Being routed through because there was no tagging to suggest that this isn't permissible or even possible. b) Routing choosing the wrong way to get into the area. c) Valid walking ways inhibited by either bad tagging or incorrect logic in inc/access
When I encounter a problem, I look at the tagging to see why it has happened, and, if blatantly wrong, fix it.
Mostly, however, I don't want to change access rules on clusters of roads (mostly service) that I know nothing about concerning rights of way, etc.
I then see if I can fix or enhance inc/access to handle the scenario better for next time.
There is no perfect solution but, doing a lot of walking and driving to obscure places I am less frequently faced with wrong routing decisions.
Ticker
On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
Hi Ticker,
with examples I meant links to OSM ways.
My current understanding is that these OSM ways may need different tagging.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
My problem is relating to car routing and highway=service where no explicit access is specified,
For driveways I set access=private.
For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier.
Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem.
My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no
Ticker
On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois- to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Judging by the lack of posts and changes relating to precise access handling and its effects on routeing, I doubt if there will be anyone else who says they need this. The proposed mkgmap:poi-{highway,barrier} variables are much more use than mkgmap:way-has-pois, which isn't used by any of the styles provided by mkgmap. My version of inc/access[_country] handles the more subtle features of OSM access and maps them onto Garmin in an accurate manner. However there isn't one solutions for service roads where access hasn't been specified; sometimes through-routeing should be prevented, sometimes not. There isn't a reliable method to decide, but POI barriers on the road are a good hint. If your concern is efficiency, I can probably improve the hook logic so that it is better than before while still implementing the new variables. If you don't like the names I can change them. Ticker On Thu, 2022-02-17 at 13:48 +0000, Gerd Petermann wrote:
Hi Ticker,
so really not a single real world OSM example for me?
Anyway, my concern about this is that you combine it with the option that possibly creates a route restriction or causes a split of the way and I don't see how this is related.
Let's see if anybody else wants this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 13:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
These cases happen in retail/business/industry/leisure/holiday parks and similar.
Typical problems are: a) Being routed through because there was no tagging to suggest that this isn't permissible or even possible. b) Routing choosing the wrong way to get into the area. c) Valid walking ways inhibited by either bad tagging or incorrect logic in inc/access
When I encounter a problem, I look at the tagging to see why it has happened, and, if blatantly wrong, fix it.
Mostly, however, I don't want to change access rules on clusters of roads (mostly service) that I know nothing about concerning rights of way, etc.
I then see if I can fix or enhance inc/access to handle the scenario better for next time.
There is no perfect solution but, doing a lot of walking and driving to obscure places I am less frequently faced with wrong routing decisions.
Ticker
On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
Hi Ticker,
with examples I meant links to OSM ways.
My current understanding is that these OSM ways may need different tagging.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
My problem is relating to car routing and highway=service where no explicit access is specified,
For driveways I set access=private.
For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier.
Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem.
My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no
Ticker
On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois- to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, the special tag mkgmap:way-has-pois was never meant to be used by the style, it could have been another bit flag in class Way as it was for internal use. I wasn't happy to document it in the first place as it is of no use for style authors. My concern is that these tags are really confusing for those who don't understand the logic behind them. We have so many internal tags and the current style manual sometimes fails to make clear if those tags are set by mkgmap before the style is used or read by mkgmap after the style is used. Besides that the problem that you want to solve seems quite special. Since you have no examples I may not understand what problem it is but my current understanding is that you had some mistagged OSM ways which happened to have a barrier node which probably also missed proper access tags. Adding a special rule for those is likely to cause trouble somewhere else. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 21. Februar 2022 09:57 An: mkgmap development Betreff: Re: [mkgmap-dev] option link-pois-to-ways information Hi Gerd Judging by the lack of posts and changes relating to precise access handling and its effects on routeing, I doubt if there will be anyone else who says they need this. The proposed mkgmap:poi-{highway,barrier} variables are much more use than mkgmap:way-has-pois, which isn't used by any of the styles provided by mkgmap. My version of inc/access[_country] handles the more subtle features of OSM access and maps them onto Garmin in an accurate manner. However there isn't one solutions for service roads where access hasn't been specified; sometimes through-routeing should be prevented, sometimes not. There isn't a reliable method to decide, but POI barriers on the road are a good hint. If your concern is efficiency, I can probably improve the hook logic so that it is better than before while still implementing the new variables. If you don't like the names I can change them. Ticker On Thu, 2022-02-17 at 13:48 +0000, Gerd Petermann wrote:
Hi Ticker,
so really not a single real world OSM example for me?
Anyway, my concern about this is that you combine it with the option that possibly creates a route restriction or causes a split of the way and I don't see how this is related.
Let's see if anybody else wants this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 13:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
These cases happen in retail/business/industry/leisure/holiday parks and similar.
Typical problems are: a) Being routed through because there was no tagging to suggest that this isn't permissible or even possible. b) Routing choosing the wrong way to get into the area. c) Valid walking ways inhibited by either bad tagging or incorrect logic in inc/access
When I encounter a problem, I look at the tagging to see why it has happened, and, if blatantly wrong, fix it.
Mostly, however, I don't want to change access rules on clusters of roads (mostly service) that I know nothing about concerning rights of way, etc.
I then see if I can fix or enhance inc/access to handle the scenario better for next time.
There is no perfect solution but, doing a lot of walking and driving to obscure places I am less frequently faced with wrong routing decisions.
Ticker
On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
Hi Ticker,
with examples I meant links to OSM ways.
My current understanding is that these OSM ways may need different tagging.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
My problem is relating to car routing and highway=service where no explicit access is specified,
For driveways I set access=private.
For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier.
Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem.
My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no
Ticker
On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link-pois- to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd The new variable will be of use (certainly to me) and I'll document them in the style guide as clearly as possible. The problem I'm trying to solve might seem special, but I make heavy use of routing and, when driving or walking somewhere, the device instructions call for the impossible or ridiculous, I look at the reasons why it happened at that location and fix it. I don't want the same thing to happen in locations I haven't been to yet, so, if the scenario is plausibly common I might need to look for other hints to guide the access decisions. Most problems have been handled by getting the subtleties correct in access[_country]. Some by fixing the tagging. This leaves, as a significant problem, clusters of service roads where the mappers don't know the precise access rights and so don't commit to these in OSM. They might, however, mark barriers etc that can be seen from the aerial photography. Ticker On Mon, 2022-02-21 at 09:16 +0000, Gerd Petermann wrote:
Hi Ticker,
the special tag mkgmap:way-has-pois was never meant to be used by the style, it could have been another bit flag in class Way as it was for internal use. I wasn't happy to document it in the first place as it is of no use for style authors.
My concern is that these tags are really confusing for those who don't understand the logic behind them. We have so many internal tags and the current style manual sometimes fails to make clear if those tags are set by mkgmap before the style is used or read by mkgmap after the style is used.
Besides that the problem that you want to solve seems quite special. Since you have no examples I may not understand what problem it is but my current understanding is that you had some mistagged OSM ways which happened to have a barrier node which probably also missed proper access tags. Adding a special rule for those is likely to cause trouble somewhere else.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 21. Februar 2022 09:57 An: mkgmap development Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Judging by the lack of posts and changes relating to precise access handling and its effects on routeing, I doubt if there will be anyone else who says they need this.
The proposed mkgmap:poi-{highway,barrier} variables are much more use than mkgmap:way-has-pois, which isn't used by any of the styles provided by mkgmap.
My version of inc/access[_country] handles the more subtle features of OSM access and maps them onto Garmin in an accurate manner.
However there isn't one solutions for service roads where access hasn't been specified; sometimes through-routeing should be prevented, sometimes not. There isn't a reliable method to decide, but POI barriers on the road are a good hint.
If your concern is efficiency, I can probably improve the hook logic so that it is better than before while still implementing the new variables. If you don't like the names I can change them.
Ticker
On Thu, 2022-02-17 at 13:48 +0000, Gerd Petermann wrote:
Hi Ticker,
so really not a single real world OSM example for me?
Anyway, my concern about this is that you combine it with the option that possibly creates a route restriction or causes a split of the way and I don't see how this is related.
Let's see if anybody else wants this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 13:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
These cases happen in retail/business/industry/leisure/holiday parks and similar.
Typical problems are: a) Being routed through because there was no tagging to suggest that this isn't permissible or even possible. b) Routing choosing the wrong way to get into the area. c) Valid walking ways inhibited by either bad tagging or incorrect logic in inc/access
When I encounter a problem, I look at the tagging to see why it has happened, and, if blatantly wrong, fix it.
Mostly, however, I don't want to change access rules on clusters of roads (mostly service) that I know nothing about concerning rights of way, etc.
I then see if I can fix or enhance inc/access to handle the scenario better for next time.
There is no perfect solution but, doing a lot of walking and driving to obscure places I am less frequently faced with wrong routing decisions.
Ticker
On Thu, 2022-02-17 at 10:11 +0000, Gerd Petermann wrote:
Hi Ticker,
with examples I meant links to OSM ways.
My current understanding is that these OSM ways may need different tagging.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 17. Februar 2022 10:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
My problem is relating to car routing and highway=service where no explicit access is specified,
For driveways I set access=private.
For others, it is debatable as to what to do: 1/ Nothing. This can allow routing through somewhere entirely inappropriate. 2/ Always set access=destination. This will stop through routing that could be allowed/efficient. 3/ only set access=destination if there seems to be a barrier.
Any of these can still lead to the problem with new Garmin routing algo using a footpath, but 2/ makes it more likely to happen. Where the destination is truly in the service area it is easy to check the last steps of the chosen route to detect this problem.
My later logic transforms the access into combinations of mkgmap:foot/car/...=yes/no mkgmap:throughroute=yes/no
Ticker
On Thu, 2022-02-17 at 08:28 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't see a problem with the patch, but I also don't see how it solves a problem with wrong routing.
Please give me some examples for highways where this would help.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 16. Februar 2022 17:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
Hi Gerd
Attached a patch to create 2 mkgmap: variables when --link- pois- to- ways operates.
mkgmap:poi-barrier is a list of the distinct POI barrier= tags on the way, so it will have values like: mkgmap:poi-barrier=gate;bollard
mkgmap:poi-highway is similar but a list of the highway= tags, eg: mkgmap:poi-highway=mini_roundabout;crossing
These can be tested eg: highway=service & access!=* & mkgmap:poi-barrier=* & mkgmap:poi-barrier~".*(yes|barrier|gate|bollard|block).*" {set access=destination}
If you are happy with this I'll update the Style Manual.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
ankeric.osm＠gmail.com -
Gerd Petermann -
Ticker Berkin