Open question reg. new nearby-poi options
Hi all, some days ago I expressed my concerns that the new option might have a bad influence on routing or the dead-end check. I was mistaken, there was and is no effect on routing or the results of the dead-end checks because the option only effects the POI, which is a different data structure. Sorry for the confusion. Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
*Garmin:* GPSMAP 60, Etrex Vista HCx: declutter is an option. Extrex 30, GPSMAP 64: declutter is not an option, not anymore! Garmin: "our customers prefer simple!" I don't! And now mkgmap is expected to resolve: + . Garmin Search: Garmin Outdoor is the only GPS I know (in my possession) not capable of searching for a POI along the upcoming route: fuel, bench, picnic_table, pub, restaurant, swimming area. Garmin Search (@Gerd: "POI search is much more important for me. The rendering is of less importance.") is not always appropriate/sufficient. Driving south I will search for a POI in direction south. Never make a U-turn for a picnic_table, which would be a detour (2x distance). Garmin Search will show direction (SW/S/SE/...), but it's not self-evident which of found POI's are okay (for me). And even more important: the most nearby POI might be on the other side of the river. Navigation might be a huge detour by the next or previous bridge. Or uphill 12% (or more). What's nearby? Or "just" routing impossible? Therefore: visual search on the map! Garmin Rendering: Garmin Outdoor is the only GPS I know (in my possession) not capable of selecting which category of POI I want to see now on the Map. Declutter by category! Show only selected category! Garmin Outdoor GPS is still ignoring bicycle. Bicycle_parking is to be found in: "Auto Services", "Wrecker Service" (my suggested and accepted solution long time ago to openfietsmap as to render picnic_table, which is also: "Auto Services"). Supermarket? Grocery.....! *How to Declutter?* *1. Decide what you want to declutter.* I don't render barrier=bollard on Hiking or Car Map. On bicycle Map it's "most prominent". IMO: do not use nearby-poi-rules for wildcards. Never, ever. Unless you prefer to create a BAD Map. *2. Decide where you want to declutter.* In a city declutter is more important (shop, shop, shop, more shops) than in outside area, where a couple of benches and/or picnic-tables are the only POI's in the area. Anke (key user, navigator): "Are you serious? You want to declutter benches? Useless and nonsense!" *3. Decide how to declutter:* - OR: {delete POI} - OR: Do not delete, do render, but make label invisible: Font style = No label (invisible). Selecting a POI (or hover over) will still show the name (it's still there). - OR: Do not delete, but make POI invisible (transparent). POI is still searchable. If above options don't help: ask Mike and Gerd (mkgmap) to help. To decide: if declutter for a POI (not showing all) is okay (for you) than ask yourself: should this POI be Rendered at all? IMO: it's All or Nothing. Declutter distance is bird's eye view distance. Sometimes routing distance is far more than bird's eye view distance. U-turn, across the river, other side of this wall/fence, parallel cycleway/path or down below in the mountain gap. Both locations are having a POI, rendered might be (!) only one. If I'm unlucky I will miss a bollard. If I'm very unlucky this implies "3 months of liquid food" (and a bill of the dentist). Count of POI is – sometimes – very relevant. During weekend or when travelling in a group I'm not interested in one bench, or one picnic_table. I want more. After declutter I only can see on the Map: there is at least one POI there, perhaps more, perhaps not. Where to declutter? My test version (using declutter): if (natural=tree) then is_in(landuse,residential,in)=false [0x6618 resolution 24] is_in(landuse,grass,in)=true [0x6618 resolution 24] is_in(natural,grassland,in)=true [0x6618 resolution 24] is_in(tourism,camp_site,in)=true [0x6618 resolution 24] is_in(leisure,park,in)=true [0x6618 resolution 24] species=* [0x6618 resolution 24] So: I don't want to see trees inside residential area (too many trees and cluttering is more evident) unless natural, campsite, park or unless "species" is specified. In a "pinetum" (conifers park) I don't want any decluttering. Each tree is a natural piece of art! So my RFC would be: Make Nearby_poi a function (might be called by style file) and not, or not only, an args option. Effect on Routing (navigation)? Some POI need to be, is preferred to be avoided. Bollard is a warning. Warning should be for all bollards, not only for some. Again: nearby might be a completely different path/route. [bicycle=dismount] is a lifesaving warning! I will render a huge [bicycle=dismount] POI on every highway=steps (steps are hard to see on the GPS map) and I don't like any of those to be decluttered. Never! Germany: bridge + step_count=2, incline=up (but dark forest) over Spree. Elbe: step_count=6 (?), incline=down. In BaseCamp routing I created a detour, on the ground Anke did not understand the detour... GPS saved us! Other avoidances not to be decluttered: waterway=ford. Path crossing a waterway without a bridge is routable. My assumption will be: waterway=ditch. I can step over. A "ford" is different from a ditch (or OSM missing bridge). I Render all possible "challenges" as unpaved. I need to confirm (by setting a viapoint) I do want this route navigation. Some POI's will be a "routing block". Several years ago in mkgmap routable = yes/no only applies to highways. But then mkgmap improvement (!): barrier=gate + access=no/private, bicycle=no will also be considered to be a showstopper. In residential area's sometimes motorcar through route is blocked by a [barrier=bollard] or [barrier=block]. More typical: blocked by highway=path/cycleway segment, but not always. Mkgmap routing: highway=residential (default access) + barrier=bollard, implies (or explicitly): motorcar=no! During construction period routing is blocked by a fence or gate or... And again: [barrier=*] + [access=no] on POI. OSM does not always set the highway to [access=no] as well. (Also: I don't always do so). My suggestion: Function: IS_ON_HIGHWAY = true/false (or return 0 (false) and 1,2,3,4,5 for highway type). Do not declutter if POI IS_ON_HIGHWAY(POI) = true. I did some testing on declutter nearby POI (trees). Test case: 7x [natural=tree] in a row (80 meters). Row is not perfectly straight. Distance (average) = 13.5 meter, but not always exact same distance. "x" = tree is rendered. "-" = tree is not rendered. 0x6618/unnamed:1 --> x x x x x x x 0x6618/unnamed:11 --> x x x x x x x 0x6618/unnamed:12 --> - x x x x x x 0x6618/unnamed:13 --> - x - x x x x 0x6618/unnamed:14 --> - x - x - x x 0x6618/unnamed:15 --> - - x - - x - 0x6618/unnamed:25 --> - - x - - x - 0x6618/unnamed:30 --> - - - - x - - 0x6618/unnamed:45 --> - - - - x - - 0x6618/unnamed:46 --> - - - - - - - Error: if distance is too large (46 meters on a 80 meters row) than zero trees are rendered. Gerd already warned: even 30 might be "too much of a distance"! I expected: First, or Middle or Last to be always rendered. In a park having 40 trees, distance:80 --> 2 trees left (which is oke and nice!). My Use Case (4): Duplicate "main feature tags" is "just a special case" (btw, this is mkgmap default style!), but not unique. In my own city I have mapped 2x [amenity=bicycle_parking]. 1st is underground, large building 2nd is on the roof of 1st building, 50% size of the underground building. No POI, so: area2poi. On my own Map: both POI's are in collision for 50%! In JOSM: both POI's are on very different locations (since building size is different). I don't understand. Attached is: "Collision_bicycle_parking_POI.osm". Please look at JOSM rendering when selecting the area (is oke). On my mkgmap map two POI's are 50% overlapping. Collision_bicycle_parking_POI.osm <http://gis.19327.n8.nabble.com/file/t344065/Collision_bicycle_parking_POI.osm> My "conclusion": POI-collision might be a better use case. Move one of the collision POI's down for (number of POI-pixels-size) + (x=gap size). IMO, not hindered by any know-how. Use declutter only for (IMO): [natural=tree], [tourism=hotel], [amenity=restaurant], [amenity=shop] (or [amenity=*]) (and 10 or more I did overlook). But even then: "Hotel Post" is a hotel and also a restaurant. Both having the same (one and only) name. How to prevent declutter of the restaurant or hotel? Only option (IMO): declutter if and only if 1x POI is node and 2nd POI is area2poi (or line2poi). -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Eric, Maybe the subject was misleading. Can you give an example that shows an influence of the --nearby-poi-* options on routing or the dead-end-check? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm@gmail.com> Gesendet: Donnerstag, 7. Mai 2020 12:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Open question reg. new nearby-poi options *Garmin:* GPSMAP 60, Etrex Vista HCx: declutter is an option. Extrex 30, GPSMAP 64: declutter is not an option, not anymore! Garmin: "our customers prefer simple!" I don't! And now mkgmap is expected to resolve: + . Garmin Search: Garmin Outdoor is the only GPS I know (in my possession) not capable of searching for a POI along the upcoming route: fuel, bench, picnic_table, pub, restaurant, swimming area. Garmin Search (@Gerd: "POI search is much more important for me. The rendering is of less importance.") is not always appropriate/sufficient. Driving south I will search for a POI in direction south. Never make a U-turn for a picnic_table, which would be a detour (2x distance). Garmin Search will show direction (SW/S/SE/...), but it's not self-evident which of found POI's are okay (for me). And even more important: the most nearby POI might be on the other side of the river. Navigation might be a huge detour by the next or previous bridge. Or uphill 12% (or more). What's nearby? Or "just" routing impossible? Therefore: visual search on the map! Garmin Rendering: Garmin Outdoor is the only GPS I know (in my possession) not capable of selecting which category of POI I want to see now on the Map. Declutter by category! Show only selected category! Garmin Outdoor GPS is still ignoring bicycle. Bicycle_parking is to be found in: "Auto Services", "Wrecker Service" (my suggested and accepted solution long time ago to openfietsmap as to render picnic_table, which is also: "Auto Services"). Supermarket? Grocery.....! *How to Declutter?* *1. Decide what you want to declutter.* I don't render barrier=bollard on Hiking or Car Map. On bicycle Map it's "most prominent". IMO: do not use nearby-poi-rules for wildcards. Never, ever. Unless you prefer to create a BAD Map. *2. Decide where you want to declutter.* In a city declutter is more important (shop, shop, shop, more shops) than in outside area, where a couple of benches and/or picnic-tables are the only POI's in the area. Anke (key user, navigator): "Are you serious? You want to declutter benches? Useless and nonsense!" *3. Decide how to declutter:* - OR: {delete POI} - OR: Do not delete, do render, but make label invisible: Font style = No label (invisible). Selecting a POI (or hover over) will still show the name (it's still there). - OR: Do not delete, but make POI invisible (transparent). POI is still searchable. If above options don't help: ask Mike and Gerd (mkgmap) to help. To decide: if declutter for a POI (not showing all) is okay (for you) than ask yourself: should this POI be Rendered at all? IMO: it's All or Nothing. Declutter distance is bird's eye view distance. Sometimes routing distance is far more than bird's eye view distance. U-turn, across the river, other side of this wall/fence, parallel cycleway/path or down below in the mountain gap. Both locations are having a POI, rendered might be (!) only one. If I'm unlucky I will miss a bollard. If I'm very unlucky this implies "3 months of liquid food" (and a bill of the dentist). Count of POI is – sometimes – very relevant. During weekend or when travelling in a group I'm not interested in one bench, or one picnic_table. I want more. After declutter I only can see on the Map: there is at least one POI there, perhaps more, perhaps not. Where to declutter? My test version (using declutter): if (natural=tree) then is_in(landuse,residential,in)=false [0x6618 resolution 24] is_in(landuse,grass,in)=true [0x6618 resolution 24] is_in(natural,grassland,in)=true [0x6618 resolution 24] is_in(tourism,camp_site,in)=true [0x6618 resolution 24] is_in(leisure,park,in)=true [0x6618 resolution 24] species=* [0x6618 resolution 24] So: I don't want to see trees inside residential area (too many trees and cluttering is more evident) unless natural, campsite, park or unless "species" is specified. In a "pinetum" (conifers park) I don't want any decluttering. Each tree is a natural piece of art! So my RFC would be: Make Nearby_poi a function (might be called by style file) and not, or not only, an args option. Effect on Routing (navigation)? Some POI need to be, is preferred to be avoided. Bollard is a warning. Warning should be for all bollards, not only for some. Again: nearby might be a completely different path/route. [bicycle=dismount] is a lifesaving warning! I will render a huge [bicycle=dismount] POI on every highway=steps (steps are hard to see on the GPS map) and I don't like any of those to be decluttered. Never! Germany: bridge + step_count=2, incline=up (but dark forest) over Spree. Elbe: step_count=6 (?), incline=down. In BaseCamp routing I created a detour, on the ground Anke did not understand the detour... GPS saved us! Other avoidances not to be decluttered: waterway=ford. Path crossing a waterway without a bridge is routable. My assumption will be: waterway=ditch. I can step over. A "ford" is different from a ditch (or OSM missing bridge). I Render all possible "challenges" as unpaved. I need to confirm (by setting a viapoint) I do want this route navigation. Some POI's will be a "routing block". Several years ago in mkgmap routable = yes/no only applies to highways. But then mkgmap improvement (!): barrier=gate + access=no/private, bicycle=no will also be considered to be a showstopper. In residential area's sometimes motorcar through route is blocked by a [barrier=bollard] or [barrier=block]. More typical: blocked by highway=path/cycleway segment, but not always. Mkgmap routing: highway=residential (default access) + barrier=bollard, implies (or explicitly): motorcar=no! During construction period routing is blocked by a fence or gate or... And again: [barrier=*] + [access=no] on POI. OSM does not always set the highway to [access=no] as well. (Also: I don't always do so). My suggestion: Function: IS_ON_HIGHWAY = true/false (or return 0 (false) and 1,2,3,4,5 for highway type). Do not declutter if POI IS_ON_HIGHWAY(POI) = true. I did some testing on declutter nearby POI (trees). Test case: 7x [natural=tree] in a row (80 meters). Row is not perfectly straight. Distance (average) = 13.5 meter, but not always exact same distance. "x" = tree is rendered. "-" = tree is not rendered. 0x6618/unnamed:1 --> x x x x x x x 0x6618/unnamed:11 --> x x x x x x x 0x6618/unnamed:12 --> - x x x x x x 0x6618/unnamed:13 --> - x - x x x x 0x6618/unnamed:14 --> - x - x - x x 0x6618/unnamed:15 --> - - x - - x - 0x6618/unnamed:25 --> - - x - - x - 0x6618/unnamed:30 --> - - - - x - - 0x6618/unnamed:45 --> - - - - x - - 0x6618/unnamed:46 --> - - - - - - - Error: if distance is too large (46 meters on a 80 meters row) than zero trees are rendered. Gerd already warned: even 30 might be "too much of a distance"! I expected: First, or Middle or Last to be always rendered. In a park having 40 trees, distance:80 --> 2 trees left (which is oke and nice!). My Use Case (4): Duplicate "main feature tags" is "just a special case" (btw, this is mkgmap default style!), but not unique. In my own city I have mapped 2x [amenity=bicycle_parking]. 1st is underground, large building 2nd is on the roof of 1st building, 50% size of the underground building. No POI, so: area2poi. On my own Map: both POI's are in collision for 50%! In JOSM: both POI's are on very different locations (since building size is different). I don't understand. Attached is: "Collision_bicycle_parking_POI.osm". Please look at JOSM rendering when selecting the area (is oke). On my mkgmap map two POI's are 50% overlapping. Collision_bicycle_parking_POI.osm <http://gis.19327.n8.nabble.com/file/t344065/Collision_bicycle_parking_POI.osm> My "conclusion": POI-collision might be a better use case. Move one of the collision POI's down for (number of POI-pixels-size) + (x=gap size). IMO, not hindered by any know-how. Use declutter only for (IMO): [natural=tree], [tourism=hotel], [amenity=restaurant], [amenity=shop] (or [amenity=*]) (and 10 or more I did overlook). But even then: "Hotel Post" is a hotel and also a restaurant. Both having the same (one and only) name. How to prevent declutter of the restaurant or hotel? Only option (IMO): declutter if and only if 1x POI is node and 2nd POI is area2poi (or line2poi). -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Eric: "No I cannot..., not within one hour..." Anke: "yes, you can..." Attached: "residential_bollard_bollard_service_motorcar_no.osm" South to north: [highway=residential] > parking_garage > bollard > (cross cycleway) > bollard > [highway=service] If one of the bollards is removed by nearby-poi (11.63 meter distance) then access restriction is also removed. No access restriction on highways (residential/service). Nice example, Anke, because of the two POI barriers "near by". Also, see: Mapillary. What I don't know (but you do): does poi style file processing effects line style file processing? Which is processed first? But IMO: a POI (and a POI only) might set access for a highway, even if highway is having default access. And mkgmap will respect to POI-barrier-access (new option, since several years). In text this example was also somewhere hidden in my first reply. My first reply does not reply to any subject. Should I have created a new topic: "nearby-poi discussion"? Eric (AnkEric) residential_bollard_bollard_service_motorcar_no.osm <http://gis.19327.n8.nabble.com/file/t344065/residential_bollard_bollard_service_motorcar_no.osm> -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Eric, I don't understand. Both bollards in your example are ignored because the ways have the same restrictions as the bollards. Besides that the example is poor as the roads north of the bollard also don't allow car traffic. I've used default style and options --route --link-pois-to-ways . Anyway, your style may treat barrier=bollard different, so to make sure I removed the tag motor_vehicle=no from way 790197214 and tried again. Now I found the expected restrictions in the NOD data. Next I tried with --nearby-poi-rules=0x3200:20 and found no changes in NOD data. The barrier POI is removed, but not the corresponding routing restriction. So, unless your Garmin navi interprets the POI itself as a routing restriction there really should be no effect on routing. Reg. all your other problems: Please declutter your post first and decide which problems have to be solved by Garmin. For each remaining problem, create one post , attach an example file with the problem and describe the problem and what's wrong with the results of r4491 (or later) with something like I expected to find ... but got ... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm@gmail.com> Gesendet: Donnerstag, 7. Mai 2020 13:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Open question reg. new nearby-poi options Eric: "No I cannot..., not within one hour..." Anke: "yes, you can..." Attached: "residential_bollard_bollard_service_motorcar_no.osm" South to north: [highway=residential] > parking_garage > bollard > (cross cycleway) > bollard > [highway=service] If one of the bollards is removed by nearby-poi (11.63 meter distance) then access restriction is also removed. No access restriction on highways (residential/service). Nice example, Anke, because of the two POI barriers "near by". Also, see: Mapillary. What I don't know (but you do): does poi style file processing effects line style file processing? Which is processed first? But IMO: a POI (and a POI only) might set access for a highway, even if highway is having default access. And mkgmap will respect to POI-barrier-access (new option, since several years). In text this example was also somewhere hidden in my first reply. My first reply does not reply to any subject. Should I have created a new topic: "nearby-poi discussion"? Eric (AnkEric) residential_bollard_bollard_service_motorcar_no.osm <http://gis.19327.n8.nabble.com/file/t344065/residential_bollard_bollard_service_motorcar_no.osm> -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I missed the [motor_vehicle=no] on the residential (south way only). My example should haven been without any access tags on the highways. Just: [highway=residential] + [barrier=bollard] in the middle. But you have "removed the tag motor_vehicle=no from way" Oké, so: your test is okay! IF: - NODE: [barrier=bollard] + [motor_vehicle=no] THEN: - nearby-poi-rules THEN: - NODE: [motor_vehicle=no] So: only [barrier=bollard] was deleted from node? So not all tags {deletealltags} are deleted, only the POI tag?!! Oké than routing - restriction (!) - is not effected by nearby-poi-rules. Agreed. But this also implies name=* is left on node (if name is set). How will Map render a node having name only? Osmose and JOSM regards this as warning: "missing tag - incomplete object: only name". Also (but OT): The barrier rendered is a - visual - justification for GPS refusing to Route over this highway. If the barrier is missing (not rendered by nearby-poi-rules) than I might assume this is an "Unconnected ways" error and I can go there by ignoring GPS. I won't understand why routing is not possible. So "visual navigation" might be effected by nearby-poi-rules. Walking the dog over a cattle grid is another example.
So, unless your Garmin navi interprets the POI itself as a routing restriction there really should be no effect on routing. Unless I'm very mistaken: mkgmap was updated several years ago as to "interprets the POI itself as a routing restriction" (Instruction by openfietsmap). My navi is innocent.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Eric, the link-pois-to-ways option works like this: 1) Before (!) style processing all nodes with a highway=* or barrier=* tag are marked as special nodes when they are also referenced by a way. They are Points Of Interest, but in a very different way. The ways which reference the special node also store this information as well. 2) After style processing the special nodes are checked again regarding the access tags. This happens even when the points file doesn't generate a map object. If the style generates a map object this is also called a POI, but that POI is stored in a different data structure and the removal has no influence on the processing of the special node. A barrier=* node that is not connected to any way can still be redererd as a POI. I already wrote that I consider it a bad idea to remove POI from the map when they represent a routing restriction. When Mike posted the first patch I thought about an experience on a cycle tour where a search for the next hotel only showed various similar entries for a bunch of tourism=guest_house all located in a small area, probably a camp_site. I had to scroll down two pages to find something else. So, that would be my first candidate to try this option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm@gmail.com> Gesendet: Donnerstag, 7. Mai 2020 15:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Open question reg. new nearby-poi options I missed the [motor_vehicle=no] on the residential (south way only). My example should haven been without any access tags on the highways. Just: [highway=residential] + [barrier=bollard] in the middle. But you have "removed the tag motor_vehicle=no from way" Oké, so: your test is okay! IF: - NODE: [barrier=bollard] + [motor_vehicle=no] THEN: - nearby-poi-rules THEN: - NODE: [motor_vehicle=no] So: only [barrier=bollard] was deleted from node? So not all tags {deletealltags} are deleted, only the POI tag?!! Oké than routing - restriction (!) - is not effected by nearby-poi-rules. Agreed. But this also implies name=* is left on node (if name is set). How will Map render a node having name only? Osmose and JOSM regards this as warning: "missing tag - incomplete object: only name". Also (but OT): The barrier rendered is a - visual - justification for GPS refusing to Route over this highway. If the barrier is missing (not rendered by nearby-poi-rules) than I might assume this is an "Unconnected ways" error and I can go there by ignoring GPS. I won't understand why routing is not possible. So "visual navigation" might be effected by nearby-poi-rules. Walking the dog over a cattle grid is another example.
So, unless your Garmin navi interprets the POI itself as a routing restriction there really should be no effect on routing. Unless I'm very mistaken: mkgmap was updated several years ago as to "interprets the POI itself as a routing restriction" (Instruction by openfietsmap). My navi is innocent.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
AnkEric -
Gerd Petermann