<div dir="ltr"><div><div><div>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. <br><br></div>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). <br></div>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.</div><div><br></div><div><br></div><div>Addendum:</div><div>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? <br></div><div><br></div><div><br></div><div>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.<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 September 2017 at 22:56, Gerd Petermann <span dir="ltr"><<a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Felix,<br>
<br>
I think you wanted to use continue with_actions ?<br>
Besides that the special tags have no effect on the overlay lines .<br>
<span class=""><br>
Gerd<br>
______________________________<wbr>__________<br>
Von: mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk">mkgmap-dev-bounces@lists.<wbr>mkgmap.org.uk</a>> im Auftrag von Felix Hartmann <<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a>><br>
</span>Gesendet: Sonntag, 17. September 2017 22:13<br>
<span class="">An: Development list for mkgmap<br>
Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only<br>
<br>
</span><span class="">Hi Gerd,<br>
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!<br>
My testfile an the following lines file:<br>
<br>
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_<wbr>type=none; set mkgmap:set_unconnected_type=<wbr>none}<br>
service=driveway {set mkgmap:set_unconnected_type=<wbr>none} [0x13 road_class=0 road_speed=0 resolution 24 continue]<br>
service=driveway [0x1040c resolution 24]<br>
<br>
leads to:<br>
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).<br>
So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored.<br>
And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something.<br>
<br>
<br>
Changing the lines file to:<br>
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_<wbr>type=none; set mkgmap:set_unconnected_type=<wbr>none}<br>
service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue]<br>
service=driveway [0x1040c resolution 24]<br>
<br>
leads to:<br>
same result.<br>
<br>
even this:<br>
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_<wbr>type=none; set mkgmap:set_unconnected_type=<wbr>none}<br>
service=driveway {set mkgmap:set_unconnected_type=<wbr>none} [0x13 road_class=0 road_speed=0 resolution 24 continue]<br>
service=driveway {set mkgmap:set_unconnected_type=<wbr>none} [0x1040c resolution 24]<br>
<br>
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.<br>
<br>
Felix<br>
<br>
</span><span class="">On 17 September 2017 at 19:52, Gerd Petermann <<a href="mailto:GPetermann_muenchen@hotmail.com">GPetermann_muenchen@hotmail.<wbr>com</a><mailto:<a href="mailto:GPetermann_muenchen@hotmail.com">GPetermann_<wbr>muenchen@hotmail.com</a>>> wrote:<br>
Hi Felix,<br>
<br>
just in case it is not yet obvious:<br>
Some ways in your test data have highway=path but no service=driveway.<br>
Your rules don't add a road for it, so you probably don't get what you expect from the patch.<br>
<br>
Gerd<br>
______________________________<wbr>__________<br>
Von: Gerd Petermann<br>
Gesendet: Sonntag, 17. September 2017 19:39:02<br>
An: Development list for mkgmap<br>
Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only<br>
<br>
Hi Felix,<br>
<br>
I see the same result for b) and c) despite that one uses 0x01 and the other 0x13.<br>
<br>
Gerd<br>
______________________________<wbr>__________<br>
</span>Von: mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk">mkgmap-dev-bounces@lists.<wbr>mkgmap.org.uk</a><mailto:<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk">mkgmap-<wbr>dev-bounces@lists.mkgmap.org.<wbr>uk</a>>> im Auftrag von Felix Hartmann <<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><<wbr>mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><wbr>>><br>
<span class="">Gesendet: Sonntag, 17. September 2017 18:40:14<br>
An: Development list for mkgmap<br>
Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only<br>
<br>
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.<br>
<br>
<br>
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<br>
highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'}<br>
(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.<br>
<br>
</span><span class="">On 17 September 2017 at 18:26, Felix Hartmann <<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><<wbr>mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><wbr>><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.<wbr>com</a><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@<wbr>gmail.com</a>>>> wrote:<br>
b) did not work when I tried it. I have a test file here (very simple):<br>
<a href="https://openmtbmap.org/wp-content/images/debug/driveways.osm" rel="noreferrer" target="_blank">https://openmtbmap.org/wp-<wbr>content/images/debug/<wbr>driveways.osm</a><br>
<br>
<br>
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.<br>
<br>
</span><span class="">On 17 September 2017 at 18:14, Felix Hartmann <<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><<wbr>mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a><wbr>><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.<wbr>com</a><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@<wbr>gmail.com</a>>>> wrote:<br>
I've seen a couple - but yes - according to taginfo it's really little,<br>
<a href="https://taginfo.openstreetmap.org/tags/service=driveway" rel="noreferrer" target="_blank">https://taginfo.openstreetmap.<wbr>org/tags/service=driveway</a><br>
(most are highway=service, then residential and others are really really little).<br>
<br>
<br>
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).<br>
All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.<br>
<br>
<br>
Another possibility would be if it could be added to the finalize section instead. So have in finalize section<br>
( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_<wbr>type=none; set mkgmap:set_unconnected_type=<wbr>none}<br>
which would then overrule rules given higher up.<br>
(I did not try if this will work already - but I guess not).<br>
<br>
</span><span class="">On 17 September 2017 at 17:33, nwillink <<a href="mailto:osm@pinns.co.uk">osm@pinns.co.uk</a><mailto:<a href="mailto:osm@pinns.co.uk">osm@<wbr>pinns.co.uk</a>><mailto:<a href="mailto:osm@pinns.co.uk">osm@pinns.<wbr>co.uk</a><mailto:<a href="mailto:osm@pinns.co.uk">osm@pinns.co.uk</a>>><wbr>> wrote:<br>
Hi Gerd<br>
<br>
In the UK , frequently public footpaths are linked to someone's driveway - I<br>
have to say it's often quite 'daunting' to walk up someone's drive in order<br>
to continue along a public footpath.<br>
<br>
r<br>
<br>
Nick<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html" rel="noreferrer" target="_blank">http://gis.19327.n8.nabble.<wbr>com/Mkgmap-Development-<wbr>f5324443.html</a><br>
______________________________<wbr>_________________<br>
mkgmap-dev mailing list<br>
</span><a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><wbr><mailto:<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.<wbr>mkgmap.org.uk</a>><mailto:<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-<wbr>dev@lists.mkgmap.org.uk</a><<wbr>mailto:<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.<wbr>mkgmap.org.uk</a>>><br>
<div class="HOEnZb"><div class="h5"><a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
<br>
<br>
<br>
--<br>
Felix Hartman - Openmtbmap.org & VeloMap.org<br>
Schusterbergweg 32/8<br>
6020 Innsbruck<br>
Austria - Österreich<br>
<br>
<br>
<br>
--<br>
Felix Hartman - Openmtbmap.org & VeloMap.org<br>
Schusterbergweg 32/8<br>
6020 Innsbruck<br>
Austria - Österreich<br>
<br>
<br>
<br>
--<br>
Felix Hartman - Openmtbmap.org & VeloMap.org<br>
Schusterbergweg 32/8<br>
6020 Innsbruck<br>
Austria - Österreich<br>
______________________________<wbr>_________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><wbr><mailto:<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.<wbr>mkgmap.org.uk</a>><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
<br>
<br>
<br>
--<br>
Felix Hartman - Openmtbmap.org & VeloMap.org<br>
Schusterbergweg 32/8<br>
6020 Innsbruck<br>
Austria - Österreich<br>
______________________________<wbr>_________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div>Schusterbergweg 32/8<br></div><div>6020 Innsbruck<br></div></div>Austria - Österreich</div></div></div></div>
</div>