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

Mon Sep 18 19:14:28 BST 2017

Hi Gerd,

2. yes it's the case for both tags.
3. I'm fine with another name - maybe mkgmap:set_semi_connected_line=none
and mkgmap:set_unconnected_line=none?
Well I actually already went through my style and added
mkgmap:set_semi_connected_type=none - I'm just missing the overlays also
being removed as explained to fully use it. I actually had not noticed that
mkgmap:set_unconnected_type=none did not remove all the lines that I
intended to be removed by it because I never properly checked it using a
test file - and there are not many unconnected ways in real OSM data (while
there are far more semi_connected lines/ways). Actually I think it should
be semiconnected as we alo use unconnected and not un_connected (even
though it is two words in proper spelling).

On 18 September 2017 at 19:49, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> 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
> _______________________________________________
> 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/f6a83920/attachment-0001.html>