[PATCH] Access destination tag

Hi, my garmin routed me again through a residential area on a road that is tagged as destination only. I think the "destination" check was lost during the last rework of the access code. Has anybody played with the RoadNetwork.DELIVERY field until know ? To me it looks like this might solve the problem. If the access is totally blocked to a area the routing gets very strange. If I want to go into this area I get routed via a unpaved road which is also blocked. If I set the RoadNetwork.DELIVERY field the routing gets more useful. My patch is attached ... Thanks Berni. Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 284) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -502,6 +502,12 @@ noAccess[accessSelector[i]] = true; } log.info(vehicleClass[i] + " is not allowed in " + highwayType + " " + way.getName()); + + if(deliveryAllowed(access)) + { + log.info(vehicleClass[i] + " delivery allowed " + highwayType + " " + way.getName()); + noAccess[RoadNetwork.DELIVERY] = true; + } } else if(accessExplicitlyAllowed(access)) { if(accessSelector[i] == RoadNetwork.NO_MAX) { @@ -800,4 +806,11 @@ val.equalsIgnoreCase("private") || val.equalsIgnoreCase("destination")); } + + public boolean deliveryAllowed(String val) { + if (val == null) + return false; + + return (val.equalsIgnoreCase("destination")); + } }

Hi Bernhard,
my garmin routed me again through a residential area on a road that is tagged as destination only. I think the "destination" check was lost during the last rework of the access code.
Sorry, I should have said something. I don't think that, by default, "destination" should bar access to a route because the route may become unusable for everyone. Bad news if you are trying to route to your home in that area. So as an alternative, if you do want to stop routing through ways that are designated "destination", how about adding something like this to your lines style file? access=destination { set access=no } hgv=destination { set hgv=no } motorcar=destination { set motorcar=no } motorcycle=destination { set motorcycle=no } psv=destination { set psv=no }
Has anybody played with the RoadNetwork.DELIVERY field until know ? To me it looks like this might solve the problem. If the access is totally blocked to a area the routing gets very strange. If I want to go into this area I get routed via a unpaved road which is also blocked. If I set the RoadNetwork.DELIVERY field the routing gets more useful.
Looking at the comments in RoadDef.java, it's not obvious what those bits do.
My patch is attached ...
It didn't apply to the current trunk, anyway. Cheers, Mark

On Mar 1, 2009, at 14:55, Bernhard Heibler wrote:
my garmin routed me again through a residential area on a road that is tagged as destination only. I think the "destination" check was lost during the last rework of the access code.
Has anybody played with the RoadNetwork.DELIVERY field until know ? To me it looks like this might solve the problem. If the access is totally blocked to a area the routing gets very strange. If I want to go into this area I get routed via a unpaved road which is also blocked. If I set the RoadNetwork.DELIVERY field the routing gets more useful.
That's quite interesting! In my experiments, the access flags for "delivery" and "emergency" didn't behave like the other six, so if "delivery" is actually "destination", that'd be great. For the record, calling these fields DELIVERY and EMERGENCY has to do with the cGPSmapper documentation: The RouteParams field ends in 8 bit flags which are named according to the vehicle types. We're assuming these 8 fields actually correspond to one byte in the IMG. This may be off, or the cGPSmapper may be inaccurate. But having flags "no delivery" or "no emergency vehicles" on a road doesn't make too much sense. Cheers Robert

Hi Robert,
That's quite interesting! In my experiments, the access flags for "delivery" and "emergency" didn't behave like the other six, so if "delivery" is actually "destination", that'd be great.
Yes, it would be great but do we actually know if the garmin is capable of avoiding routing into an area if the destination is not within that area? At this time, I can't picture how the gps could work it out. It would have to make nets of connected ways that all have that attribute to be able to route into that area - it seems to be (potentially) very complicated.
For the record, calling these fields DELIVERY and EMERGENCY has to do with the cGPSmapper documentation: The RouteParams field ends in 8 bit flags which are named according to the vehicle types. We're assuming these 8 fields actually correspond to one byte in the IMG. This may be off, or the cGPSmapper may be inaccurate.
But having flags "no delivery" or "no emergency vehicles" on a road doesn't make too much sense.
No, but having a flag "delivery allowed" or "emergency allowed" does - imagine a pedestrian area that doesn't allow normal traffic but does allow delivery vehicles and could be used by emergency vehicles. Such areas exist, I have seen them. More thinking required... Cheers, Mark

Mark Burton schrieb:
Hi Robert,
That's quite interesting! In my experiments, the access flags for "delivery" and "emergency" didn't behave like the other six, so if "delivery" is actually "destination", that'd be great.
I very well could imagine, this is the missing bit for 'destination'
Yes, it would be great but do we actually know if the garmin is capable of avoiding routing into an area if the destination is not within that area?
At this time, I can't picture how the gps could work it out. It would have to make nets of connected ways that all have that attribute to be able to route into that area - it seems to be (potentially) very complicated.
I think the bit could mean 'dont use this street unless you must'. As the routing algortihm works from both sides, the following would be possible: If search is starting at such a road, it could take such roads as long it finds the first road without this flag. From there on it is not allowed to enter a road with delivery only. So there is no complex routing network. The only case which must be excluded in this scenario would be an 'isle' of free roads inside other roads only usable for delivery.
For the record, calling these fields DELIVERY and EMERGENCY has to do with the cGPSmapper documentation: The RouteParams field ends in 8 bit flags which are named according to the vehicle types. We're assuming these 8 fields actually correspond to one byte in the IMG. This may be off, or the cGPSmapper may be inaccurate.
But having flags "no delivery" or "no emergency vehicles" on a road doesn't make too much sense.
No, but having a flag "delivery allowed" or "emergency allowed" does - imagine a pedestrian area that doesn't allow normal traffic but does allow delivery vehicles and could be used by emergency vehicles. Such areas exist, I have seen them.
Would in this case 'delivery allowed' not mean the same as 'destination'? In normal case you are not allowed to use the road by car. If you want to deliver something, then your destination is in this road (or area) and you are allowed to use it.

Hi Johann,
That's quite interesting! In my experiments, the access flags for "delivery" and "emergency" didn't behave like the other six, so if "delivery" is actually "destination", that'd be great.
I very well could imagine, this is the missing bit for 'destination'
Yes, it would be great but do we actually know if the garmin is capable of avoiding routing into an area if the destination is not within that area?
At this time, I can't picture how the gps could work it out. It would have to make nets of connected ways that all have that attribute to be able to route into that area - it seems to be (potentially) very complicated.
I think the bit could mean 'dont use this street unless you must'. As the routing algortihm works from both sides, the following would be possible: If search is starting at such a road, it could take such roads as long it finds the first road without this flag. From there on it is not allowed to enter a road with delivery only. So there is no complex routing network.
The only case which must be excluded in this scenario would be an 'isle' of free roads inside other roads only usable for delivery.
I find it hard to believe the gps does all that.
For the record, calling these fields DELIVERY and EMERGENCY has to do with the cGPSmapper documentation: The RouteParams field ends in 8 bit flags which are named according to the vehicle types. We're assuming these 8 fields actually correspond to one byte in the IMG. This may be off, or the cGPSmapper may be inaccurate.
But having flags "no delivery" or "no emergency vehicles" on a road doesn't make too much sense.
No, but having a flag "delivery allowed" or "emergency allowed" does - imagine a pedestrian area that doesn't allow normal traffic but does allow delivery vehicles and could be used by emergency vehicles. Such areas exist, I have seen them.
Would in this case 'delivery allowed' not mean the same as 'destination'?
No - if I live inside an area that is only reachable by ways marked by "destination" then I want to be able to route in/out of the area whether I am driving a delivery van or riding my bicycle! Surely the problem here is that the OSM data can specify an attribute of a way ("destination") that is, perhaps, not supported by the gps units. It may be supported, but we don't know at this time for sure. It certainly would be useful to understand how the delivery and emergency bits function. Cheers, Mark
participants (4)
-
Bernhard Heibler
-
Johann Gail
-
Mark Burton
-
Robert Vollmert