Marco Certelli wrote:
No Dermod, it doesn't solve the issue.
In fact the Mark's patch just make in a clean way (in the IMG only) what I did
before in a dirty way (in the OSM data): mark's patch surrounds the barrier
with a couple of ways that has the access=no/foot=yes/bicycle=yes restrictions
(exactly as if they were footways in OSM) but without touching OSM data.
I also do not see a solution for the routes starting/ending in the 2 short ways around
the bollard: The problem is that garmin GPS checks the access only when it
"enters" a way. If you are already into the forbidden way (becouse you start a
route from within the way) the fact that the way is unaccessible is not checked by garmin.
I guess the only way to reduce the issue is to make the 2 ways as short as
possible (maybe 10 meters might be enough) just to reduce the probability to
start/end within them. After all, the precision of the GPS cannot tell you on
which real side of the bollard you are if you actually are very close to the
barrier.
Ciao
I'm not sure of the issue here.
Are you saying that for (say) car routing, if the user starts on a
footpath, then it's not calculated correctly?.
You could say "so what?" If the user asks for a route from a location
that they shouldn't have access to (eg: car on "foot=yes, car=no"
footpath), then ignore that local restriction (as Garmin would from not
entering the way ) and just route out as normal.
If the request is illogical, does it make sense to apply too much logic
to the answer?
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
