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

Fri Apr 18 10:20:02 BST 2014

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
>