Respect access=destination

[DennisOSRM]

Feature request: Don't route through streets with access=destination tag set, if start and/or target do not lie on them.

[DrVanScott]

... where 'street' may be a chain of accordingly tagged ways.

[DennisOSRM]

Yes, single segments, multiple segments, chained/unchained. You name it ;-)

[DrVanScott]

|   | a |   |   |
| x | b | i | h |
|   | c |   | g |
|   | d | e | f |

With ways

ab <access=dest>
bcd <access=dest>
defghibx

When i route from d to a: use bcd,ab or defghibx, ab?

ab,bcd is chained according to <access=dest>. But it may be unchained according to

[emiltin]

i think it should use bcd,ab. you're starting at d, which is on bcd, so you're allowed to move on bcd. you're ending on a, which is on ab, so no problem moving on a.

i'm not sure there's any need to consider strings of ways.

[DrVanScott]

you're starting at d, which is on bcd, so you're allowed to move on bcd.

maybe i have to be more clear: think of d being part of an crossing. Then 'd' is that crossing and therefore i would not say "i am allready on bcd"... This situation is a bit ambigous for me...

you're ending on a, which is on ab, so no problem moving on a

i agree.

[emiltin]

ways are defined by the nodes they pass. so i'm not sure i follow you - how is d not on the way bcd?

[DrVanScott]

|   | c |   |
| m | d | e |
|   | n |   |

Ways:
dc
de
dn
dm

Being on point d does not mean to be on one of these ways. Otherwise it would mean to be on all 4 ways at the same time.

Starting a route at point d should be ok, even if 'dc' is 'private'. The state of a way only affects if you are going through that way. It does not matter if you only 'touch' a single point of it. I am talking about way attributes. Node attributes are different (e.g. bollard).

Now look at the scenario in my previous post: ab,bcd is one street in terms of the access state. So one can argue that it is ok to move through bcd to go to 'a' because it's all the same street. (ab,bcd could be 'primary' while xbi is 'secondary'). chained way segments

But the context could be different: Assume xbi is primary and both bcd and ab are secondary. In this situation i would say there are two different zones. If the target is within one of them it is ok to go there, but it is not ok to go through the other.

[DennisOSRM]

Good news! I have already a prototype of this feature running on my machine.

[emiltin]

nice! remember you can use branches here on github if you like to show experimental stuff and discuss it

[drummer83]

Hi!
I just wanted to check for the status of the acces=destination tag. There are two more issues regarding this topic:
#178
#181

I'm just curious when these tags (especially the vehicle=destination tags for me) will be supported for routing. As you said you have a prototype running already I'm hoping for the best...

I love the speed of OSRM, please never stop working on it!
Thanks and regards,
drummer

[DennisOSRM]

Work is still not yet finished for this feature as there are some special cases which need special treatment. The feature will be merged into the master branch once it is more mature.

[pa5cal]

I used Dennis' hack in line 316-317 in
https://github.com/DennisOSRM/Project-OSRM/blob/master/Contractor/EdgeBasedGraphFactory.cpp
to "fix" this issue for me. Surely not perfect, but it works :) thx

[derTobsch]

This Feature would be great! 👍 We used a version which @pa5cal made for as at synyx with the fix in it. But i would be very good if this would be a real feature in osrm :)

[frodrigo]

The hack is still available somewhere ?

[pa5cal]

@frodrigo the hack was to modify the mentioned EdgeBasedGraphFactory.cpp in line 316-317 with:

if(!edgeData1.isAccessRestricted 
&& 
edgeData2.isAccessRestricted)
 {

    distance
+=
10*1200;


}

[marcioaguiar]

Hi, @DennisOSRM

Can we document the special cases so we can come up with a proper solution?

Thanks!

[danpat]

@marcioaguiar The proper solution is to implement #77, which would allows us to put arbitrary penalties on access=destination without modifying ETA values. There are a bunch of other related use cases that this feature will be helpful for.

[marcioaguiar]

Great! Thanks for the feedback, @danpat

[derTobsch]

Now in version 5.1.0 ? :-/ It feels like this is one of the most missing feature...maybe we can support you to get this done faster? We really need this feature.

[danpat]

@derTobsch A patch that implements #77 would make this possible 😄

[emiltin]

would you accept such a patch? it will increase ram usage

[danpat]

@emiltin Maybe someone will come up with a clever way to do it that doesn't use extra memory :-)

But seriously, if someone writes the patch, we can certainly make it a compile-time option, so it has no effect unless it's enabled.

[yuryleb]

Still routing through vehicle=destination 😟

[daniel-j-h]

Yes, OSRM does not respect the destination access in the default profiles and on the demo server see

osrm-backend/profiles/car.lua

Line 32 in e0a1a43

'destination'

You're free to adapt the profile and run your own server if you want to avoid routing over it.

Check out this pull request for how we will handle it in the future.

[danpat]

Now that #77 is closed, we can finally tackle this.

We can now update the car.lua. As an initial hit-list, I suggest:

• allow snapping to currently removed roads (access=hov), but discourage routing though
• penalize routing through alleys (highway=living_street)
• penalize routing through service roads (highway=service)
• allow routing onto access=destination roads

Ideally these would be implemented as penalties on turns accessing these types of ways, but our turn_function does not yet have the metadata required.

We can, however, add weight to these road types, which will have a similar effect (it may fall down in some circumstances when weights are high and coordinates are dropped near edges of weighted areas).

I'd like to include this with 5.6.0 as the major rollout feature.

[emiltin]

hope you get a chance to consider merging #3615 (factoring out common profile code to helper file) before working on using the weights to avoid access=destination.