[mkgmap-dev] [PATCH v1] Rework of inc/access

Fri Apr 18 10:24:24 BST 2014

Hi WanMil,

did not try it, but my understanding is that it should select the detour
because the target is not on the road  1 - 2.

Gerd

> Date: Fri, 18 Apr 2014 11:20:02 +0200
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] [PATCH v1] Rework of inc/access
> 
> Hi Gerd,
> 
> > Hi WanMil,
> >
> > besides the error reported by Stéphane here are my 50 cents after a first
> > compare
> > with the unpatched default style:
> >
> > I am not sure, but I think tags like
> > vehicle=private, motor_vehicle=private etc.
> > should not set
> > mkgmap:emergency=no
> >
> > My interpretation regarding routing is that
> > it is equivalent with xxx=destination,
> > so it should set the no-throughroute bit.
> >
> > Reason:
> > If one wants to visit someone living at a private way, we can assume that
> > he is allowed to go there. On the other hand, a route restriction
> > like a no_left_turn might be ignored if the road in the img file
> > doesn't allow any vehicle.
> >
> > The problem : We have only one no-troughroute bit for each road segment, so
> > a way with highway=*, access=private, bicycle=yes,  foot=yes
> > has to be added as two roads, one with acces for all vehicles except bike
> > and no-throughroute=true,
> > the other with full access for bikes and pedestrian.
> > This can't be done in the finalize rules, right?
> 
>  From my point of view duplication of ways should be done only if there 
> is a very hard reason for it.
> I don't see the case here. Private ways are private and should not be 
> used by anyone. Emergency vehicles should not use it anyhow. In case the 
> private way is the target Garmin will ignore the access bits (as far as 
> I know) and will route over the non accessible way.
> 
> Anyhow I think I haven't fully understood what the throughroute bit means.
> 
> Having the following road network:
> S
> |
> 1=======2====T==3
> |               |
> |               |
> 4---------------5
> 
> S = starting point
> T = target point
> <number> = start/end point of a road segment
> |- = usual road (nothroughroute bit not set)
> = = road with nothroughroute bit set
> 
> How does Garmin route?
> Does it choose the direct way over the two nothroughroute ways (S-1-2-T)?
> Or does it choose the detour (S-1-4-5-3-T) because it does not route 
> over adjacent ways with the nothroughroute bit set?
> 
> WanMil
> 
> >
> > Gerd
> > Gerd
> >
> >
> >
> > WanMil wrote
> >> Hi,
> >>
> >> attached is a reworked inc/access file.
> >>
> >> It now uses a 1:1 assignment between OSM tag and mkgmap access tag:
> >> foot=*       { set mkgmap:foot='${foot}' }
> >> bicycle=*    { set mkgmap:bicycle='${bicycle}' }
> >> motorcar=*   { set mkgmap:car='${motorcar}' }
> >> goods=*      { set mkgmap:delivery='${goods}' }
> >> hgv=*        { set mkgmap:truck='${hgv}' }
> >> bus=*        { set mkgmap:bus='${bus}' }
> >> taxi=*       { set mkgmap:taxi='${taxi}' }
> >> emergency=*  { set mkgmap:emergency='${emergency}' }
> >>
> >>
> >> motorcycle is no longer used. There is no clean solution when motorcycle
> >> != motorcar. The default style supports motorcars. Users that want to
> >> use the cards especially for motorcycling should modify their inc/access
> >> file appropriately.
> >>
> >> delivery is no longer used. It is not an access key. The wiki notes:
> >> The key delivery is mostly used with the value yes to indicate that the
> >> restaurant offers delivery of your meal.
> >>
> >> More access keys are used. They are taken into account obeying the rules
> >> of vehicle subclasses (set motorcar=no if motor_vehicle=no or vehicle=no
> >> etc.).
> >>
> >> The old rule
> >> highway=path { add foot=yes; add access=no }
> >> did not work for the way [highway=path; access=no]. This way should not
> >> be used by foot anyway but the rule above errorneously allowed foot.
> >> This is fixed now.
> >>
> >> carpool handling is now disabled. It does not work (as far as I know) so
> >> the rules are not useful.
> >>
> >> Many thanks to Mario Hantschke who worked out some problems of the old
> >> access file and provided some good ideas for the new rules.
> >>
> >> Please check the new rules. If you are unhappy with some assignements
> >> please post an tagging example of a way and how you think the access
> >> rules should be assigned.
> >>
> >> Have fun!
> >> WanMil
> >>
> >> _______________________________________________
> >> mkgmap-dev mailing list
> >
> >> mkgmap-dev at .org
> >
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >> access (3K)
> >> &lt;http://gis.19327.n5.nabble.com/attachment/5803532/0/access&gt;
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-Rework-of-inc-access-tp5803532p5803542.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140418/88b0750d/attachment-0001.html>