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

Mon Sep 18 18:49:52 BST 2017

Hi Felix,

1) the tag mkgmap:set_semi_connected_type is only special because it starts
with the mkgmap: prefix, within the style processing it is treated like any
other tag. The tag is first evaluated by mkgmap after all
elements where processed by the style.
2) I agree that the new function doesn't work well for a style that creates
multiple lines for a single
OSM way. I also think that this is the case with
mkgmap:set_unconnected_type. 
3) You suggested to implement the new tag similar to
mkgmap:set_unconnected_type, but
it seems you never used it?

It is easy to change the code so that it removes an overlay line when there
is no routable line for the same OSM way. I have already coded this on my
system. I can change the code to check if also the
overlay line has a special tag, I just don't like the idea that
mkgmap:set_unconnected_type or 
mkgmap:set_semi_connected_type should be used for this.

Gerd

Felix Hartmann-2 wrote
> 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@

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

> > im Auftrag von
>> Felix Hartmann <

> extremecarver@

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

> <mailto:

> GPetermann_muenchen@

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

> <mailto:mkgmap-
> > 

> dev-bounces at .org

>>> im Auftrag von Felix Hartmann <
>> 

> extremecarver@

> <mailto:

> extremecarver@

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

> <mailto:

> GPetermann_muenchen@

> > ><mailto:

> GPetermann_muenchen@

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

> <mailto:mkgmap-
> > 

> dev-bounces at .org

>><mailto:mkgmap-dev-bounces@
> > lists.mkgmap.org.uk<mailto:

> mkgmap-dev-bounces at .org

> >>> im
>> Auftrag von Felix Hartmann <

> extremecarver@

> <mailto:
> > 

> extremecarver@

>><mailto:

> extremecarver@

> <mailto:
> > 

> extremecarver@

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

> <
> > mailto:

> extremecarver@

>><mailto:

> extremecarver@

> <mailto:
> > 

> extremecarver@

>>><mailto:

> extremecarver@

> <mailto:extremecar
> > 

> ver@

>><mailto:

> extremecarver@

> <mailto:extreme
> > 

> carver@

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

> <
> > mailto:

> extremecarver@

>><mailto:

> extremecarver@

> <mailto:
> > 

> extremecarver@

>>><mailto:

> extremecarver@

> <mailto:extremecar
> > 

> ver@

>><mailto:

> extremecarver@

> <mailto:extreme
> > 

> carver@

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

> <mailto:osm@
> > pinns.co.uk><mailto:

> osm at .co

> <mailto:

> osm at .co

> >>
> <mailto:
>>
>  

> osm at .co

> <mailto:

> osm at .co

> ><mailto:

> osm at .co

> <mailto:
> > 

> osm at .co

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

> <mailto:

> mkgmap-dev at .org

> > ><mailto:

> mkgmap-dev at .org

> <mailto:mkgmap-dev at lists.
> > mkgmap.org.uk>><mailto:

> mkgmap-dev at .org

> <mailto:
> > 

> mkgmap-dev at .org

>><mailto:

> mkgmap-dev at .org

> <
> > mailto:

> mkgmap-dev at .org

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

> <mailto:

> mkgmap-dev at .org

> > ><mailto:

> mkgmap-dev at .org

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

> <mailto:

> mkgmap-dev at .org

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

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

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html