[mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only

Sun Sep 17 22:19:27 BST 2017

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 <
GPetermann_muenchen at hotmail.com> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> 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 <
> GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen at hotmail.com>>
> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-
> dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> 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 <extremecarver at gmail.com<
> mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>> 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 <extremecarver at gmail.com<
> mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>> 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 <osm at pinns.co.uk<mailto:osm@
> pinns.co.uk><mailto:osm at pinns.co.uk<mailto:osm at pinns.co.uk>>> 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
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.
> mkgmap.org.uk>>
> 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
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> 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
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170917/2f2caad0/attachment-0001.html>