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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
access (3K)
<http://gis.19327.n5.nabble.com/attachment/5803532/0/access>
--
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@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
