<div dir="ltr"><div><div><div><div><div><div><div><div><div>thanks for the clarification.<br><br></div>Well in my opinion the algo should treat it as close as similar as possible to normal tags.<br><br></div>x=* {set mkgmap:set_semi_connected_type=*} <br></div>as above without [] ---> applies to all objects that follow. also okay if due to the special way it applies simply to all objects no matter if before or after<br><br></div>x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue with_actions]<br></div>same as above<br><br></div>x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue]<br></div>only apply to the object created<br><br>x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class]<br>only apply to the object created<br><br><br></div>The problem is simply that we don't have enough routable types - so many styles use an invisible routable line overlaid with the visible line of the road/street - so both should be removed. Or take a bridge - if you decide to not show the road for that semi_connected_bridge - you may also want to not show the bridge.</div><div>I don't need this for fully non routable lines - but manybe other people see sense in also applying the semi_connected or unconnected tags to fully non routable objects. <br></div><div><br></div><div>E.g. stairs - maybe someone does not want them to be routable in his map - but only show them if they are connected to a routable way. Right now that's not possible. Same maybe for ferry lines, gondolas or public transport platforms.<br></div><div><br></div>And yes - if it were possible to use it as a standard tag instaed of the special tag - even better. I thought that was not possible due to the way the tag works. Right now it definitely is a bit confusing as it's more or less the only tag that works differently.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 September 2017 at 08:11, 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>
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.<br>
If I got you right you also want that the overlaying non-routable line is removed when it has mkgmap:set_semi_connected_<wbr>type=none ?<br>
<br>
What should happen if the style adds the same OSM way multiple times as routable line, sometimes with mkgmap:set_semi_connected_<wbr>type=none , sometimes without?<br>
Or with different values for the tag mkgmap:set_semi_connected_<wbr>type?<br>
What would be the meaning of mkgmap:set_semi_connected_<wbr>type=0x10806 for such an overlay line?<br>
<br>
Sounds too complex for me.<br>
<br>
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.<br>
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.<br>
I think we should not use the special tags mkgmap:set_semi_connected_type or mkgmap:set_unconnected_type for this.<br>
Do you agree?<br>
<span class=""><br>
Gerd<br>
______________________________<wbr>__________<br>
Von: Gerd Petermann<br>
</span>Gesendet: Montag, 18. September 2017 06:47:12<br>
<div class="HOEnZb"><div class="h5">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>
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.<br>
I'll try catch this special case with a new patch.<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 23:19:27<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>
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>
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>
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.<br>
<br>
<br>
Addendum:<br>
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>
<br>
<br>
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>
<br>
<br>
On 17 September 2017 at 22:56, 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>
I think you wanted to use continue with_actions ?<br>
Besides that the special tags have no effect on the overlay lines .<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><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>
Gesendet: Sonntag, 17. September 2017 22:13<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>
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>
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>><mailto:<a href="mailto:GPetermann_muenchen@hotmail.com">G<wbr>Petermann_muenchen@hotmail.com</a><wbr><mailto:<a href="mailto:GPetermann_muenchen@hotmail.com">GPetermann_muenchen@<wbr>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>
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>><mailto:<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk">mkgmap-dev-bounces@<wbr>lists.mkgmap.org.uk</a><mailto:<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk">mkg<wbr>map-dev-bounces@lists.mkgmap.<wbr>org.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>><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.<wbr>com</a><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@<wbr>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>><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.<wbr>com</a><mailto:<a href="mailto:extremecarver@gmail.com">extremecarver@<wbr>gmail.com</a>>><mailto:<a href="mailto:extremecarver@gmail.com">extremecarv<wbr>er@gmail.com</a><mailto:<a href="mailto:extremecarver@gmail.com">extremecar<wbr>ver@gmail.com</a>><mailto:<a href="mailto:extremecarver@gmail.com">extremec<wbr>arver@gmail.com</a><mailto:<a href="mailto:extremecarver@gmail.com">extreme<wbr>carver@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>
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>>><mailto:<a href="mailto:extremecarver@gmail.com">extremecarv<wbr>er@gmail.com</a><mailto:<a href="mailto:extremecarver@gmail.com">extremecar<wbr>ver@gmail.com</a>><mailto:<a href="mailto:extremecarver@gmail.com">extremec<wbr>arver@gmail.com</a><mailto:<a href="mailto:extremecarver@gmail.com">extreme<wbr>carver@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>
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><mailto:<a href="mailto:osm@pinns.co.uk">osm@pinns.co.uk</a><<wbr>mailto:<a href="mailto:osm@pinns.co.uk">osm@pinns.co.uk</a>><<wbr>mailto:<a href="mailto:osm@pinns.co.uk">osm@pinns.co.uk</a><mailto:<a href="mailto:osm@pinns.co.uk"><wbr>osm@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>><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>>><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>><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>
<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>><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>
<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><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>