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

Mon Sep 18 12:28:53 BST 2017

thanks for the clarification.

Well in my opinion the algo should treat it as close as similar as possible
to normal tags.

x=* {set mkgmap:set_semi_connected_type=*}
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

x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue
with_actions]
same as above

x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue]
only apply to the object created

x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class]
only apply to the object created

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.
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.

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.

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.

On 18 September 2017 at 08:11, Gerd Petermann <
GPetermann_muenchen at hotmail.com> wrote:

> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> 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 <
> GPetermann_muenchen at hotmail.com<mailto: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<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 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
> ><mailto:GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen@
> 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><mailto:mkgmap-dev-bounces@
> 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><mailto: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>><mailto:extremecarver at gmail.com<mailto:extremecar
> ver at gmail.com><mailto:extremecarver at gmail.com<mailto:extreme
> carver 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>><mailto:extremecarver at gmail.com<mailto:extremecar
> ver at gmail.com><mailto:extremecarver at gmail.com<mailto:extreme
> carver 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>><mailto:
> osm at pinns.co.uk<mailto:osm at 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>><mailto: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
> ><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
> _______________________________________________
> 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/20170918/f52e214f/attachment-0001.html>