<div dir="ltr"><div>Hi Gerd,<br></div><div>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 <b>continue </b>following this statement!<br></div><div>My testfile an the following lines file:<br></div><div><br></div><div>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}<br>service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue]<br>service=driveway [0x1040c resolution 24]</div><div><br></div><div>leads to:</div><div>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></div><div>So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored.</div><div>And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something.</div><div><br></div><div><br></div><div>Changing the lines file to:</div><div>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}<br>service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue]<br>service=driveway [0x1040c resolution 24]</div><div><br></div><div>leads to:</div><div>same result.</div><div><br></div><div>even this:</div><div>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}<br>service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue]<br>service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24]</div><div><br></div><div>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></div><div><br></div><div>Felix<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 September 2017 at 19:52, 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>
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>
<span class="">An: Development list for mkgmap<br>
</span>Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only<br>
<div class="HOEnZb"><div class="h5"><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>
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>
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>
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>>> 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>
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>>> 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>
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>>> 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>
<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>
<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><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>