Hi Felix, sorry, was too fast. The algo counts each OSM way only once, so I think regarding the routable ways it works fine. The algo is simply not used for non-routable ines. If I got you right you also want that the overlaying non-routable line is removed when it has mkgmap:set_semi_connected_type=none ?
What should happen if the style adds the same OSM way multiple times as routable line, sometimes with mkgmap:set_semi_connected_type=none , sometimes without? Or with different values for the tag mkgmap:set_semi_connected_type? What would be the meaning of mkgmap:set_semi_connected_type=0x10806 for such an overlay line? Sounds too complex for me. I think we need a different logic here. My understanding is that you only want the non-routable overlay line(s) if at least one routable line was created for the same OSM way. So, we need a method to tell mkgmap that a given non-routable line should be ignored if no routable way line exists for the same OSM way. I think we should not use the special tags mkgmap:set_semi_connected_type or mkgmap:set_unconnected_type for this. Do you agree? Gerd ________________________________________ Von: Gerd Petermann Gesendet: Montag, 18. September 2017 06:47:12 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, yes, you are right, when you create two or more routable lines from the same OSM way the algo counts them as connected on each point. I'll try catch this special case with a new patch. Gerd ________________________________________ Von: mkgmap-dev <[email protected]> im Auftrag von Felix Hartmann <[email protected]> Gesendet: Sonntag, 17. September 2017 23:19:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect. The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the intended behavior right now. Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line? In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways. On 17 September 2017 at 22:56, Gerd Petermann <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>> im Auftrag von Felix Hartmann <[email protected]<mailto:[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]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>> im Auftrag von Felix Hartmann <[email protected]<mailto:[email protected]><mailto:[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]>><mailto:[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]>><mailto:[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]>><mailto:[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]>><mailto:[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]><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 _______________________________________________ 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
