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

Sun Sep 17 21:13:31 BST 2017

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> 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> im Auftrag von
> Felix Hartmann <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>> 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>> 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>> 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>
> 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
> 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/9e128ced/attachment-0001.html>