Hi Felix, I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines .
Gerd ________________________________________ Von: mkgmap-dev <[email protected]> im Auftrag von Felix Hartmann <[email protected]> Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something. Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: same result. even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24] leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye. Felix On 17 September 2017 at 19:52, Gerd Petermann <[email protected]<mailto:[email protected]>> wrote: Hi Felix, just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch. Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Felix, I see the same result for b) and c) despite that one uses 0x01 and the other 0x13. Gerd ________________________________________ Von: mkgmap-dev <[email protected]<mailto:[email protected]>> im Auftrag von Felix Hartmann <[email protected]<mailto:[email protected]>> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list [email protected]<mailto:[email protected]> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
