allow node_function() to add penalty to a segment

[MichalPP]

(probably a documentation issue), is it possible to penalize crossing based on the type of way we cross?

eg. in foot profile, I want to avoid crossing highway=primary but allow to cross easily highway=residential.

I know that we do not need to cross one OSM way, so the highway tag on the left and right can be different.

[emiltin]

duplicate of #96?

[MichalPP]

well, 96 is two weeks younger than 77 :)

i'll try some osmosis preproccessing and see if it's any good.

[MichalPP]

maybe a stupid question, how do I add a penalty in the node_function()? something like

if node.id == 1234 then result.duration = result.duration +10; end

does not seem to work.

[daniel-j-h]

You can't in the node function. The node callback handles nodes only. Specifically this means all it can set are the traffic_lights and barrier boolean properties.

https://github.com/Project-OSRM/osrm-backend/blob/master/src/extractor/scripting_environment_lua.cpp#L287-L291

A good resource on profiles is #3842

[MichalPP]

should I write a feature request on allowing for arbitrary weight/duration change in the node_function() ?

[daniel-j-h]

The concept of a weight / duration does not make sense for nodes, only for ways / segments.

If you check the first two schemas in the following image: in the first one we have OSM ways. The second one has durations for segments.

What you can do is e.g. provide a segment_function and penalize a segment based on the from / to OSM ids, see the segment function's result type.

[MichalPP]

I am thinking of these scenarios for foot profile:

crossing a major road where the highway=crossing node does not have to be a start or end node of a segment (the highway=trunk it crosses is unroutable for pedestrians so it's in the middle)

crossing a barrier=stile should give some penalty and a navigation text like "now cross a stile" (similar are ford=yes, barrier=cattle_grid, barrier=kerb for bicycle, or toll on a node for cars). all of these are usually in the middle of a segment/edge (I hope segment_function() works on edges).

but as you've said, turn penalties are a different issue (like penalize left turn from a multi lane road by bicycle)

semi-duplicates were #534 #527

[MichalPP]

another examples are traffic_calming for car profile (add extra time and weight; though it would be nice to know if it's on a road with maxspeed 50 or 20km/h, the latter would invoke a smaller penalty), barrier=cycle_barrier (forces cyclists to slow down, so some penalty), ladder for hiking on a node (extra time for climbing).

[danpat]

@MichalPP The way this would need to be modelled is to use these nodes types as nodes in the edge-based graph. Basically, passing a barrier=cycle_barrier would become a "straight turn". We already have logic to suppress announcing instructions for these, if necessary.

We currently special-case this for traffic lights, but the mechanism can probably be improved and made more generic.

For simple cases, like a barrier along a single way, this should work fine.

For more complex cases, like barrier nodes where multiple ways meet, it's more complicated - which of the maneuvers should get the penalty? All of them? Some of them? 4-way traffic lights/stop signs are an example of this already.

[MichalPP]

@danpat I was thinking of just adding extra duration/weight to a segment if it has a special node. I didn't want to split edges (but I have no idea of the internal structures of OSRM)

[danpat]

Unfortunately, because of how we need to support updates for traffic data, any node that adds a penalty will cause a split. We really only support traffic lights right now, but they cause splits here:

https://github.com/Project-OSRM/osrm-backend/blob/master/src/extractor/graph_compressor.cpp#L118-L120

If we don't split, then we won't know to add a penalty during the generation of the turn graph (the last graph shape in the image a couple of comments back).

We could add the penalty to the edge immediately before or after the node, but again, this would get lost during updates with traffic data (not always applicable, but we can't just break this feature). In order for it to stick around, it has to form part of the turn graph (aka the edge-based-graph), which means there needs to be a turning maneuver generated there, even if it's a no-op.

[MichalPP]

@danpat after looking at the traffic, maybe it should define not new speed but rather some multiplication constant the alter the old speed (which would keep things like elevation profile speeds; I wanted to make some adjustments to foot/ski profile, but calculating the speeds is really expensive).

still not sure why traffic_calming should split an edge.

or, is it possible to have a list of osm_ids of nodes in each edge? with special nodes first and last.

[danpat]

@MichalPP OSRM models the road network as a "turn graph" (a.k.a the "edge-based graph"). Every "edge" that's routable inside OSRM consists of:

1. The speed along each segment multiplied by its length
2. Plus, the cost of making a turn.

The fourth graph in the diagram above shows a rough approximation of the edge-based-graph.

In order to include penalties for nodes in this model, the only way to add weight to an edge is to simulate it with a "turn" - turns don't always emit an instruction, but they are the way we need to add penalties in this model. This is why edges need to be split.

We're kind of dancing around the issue - can you describe the exact problem you're trying to solve? You've mentioned ski/foot profiles - can you describe your problem in more detail?

[MichalPP]

let's have an example of [traffic_calming=bump](https://wiki.openstreetmap.org/wiki/Key:traffic_calming) in the middle of a way/segment/edge.

In the segment_function() I already drastically modify duration and weight based on elevation/quietness of the road/closeness of a park. Given the complexity of calculating edge weight/duration, I don't see any reason to split edges because of the traffic calming.

To have good penalty for traffic calming, I would need to know speed on the segment and then calculate time needed for the slowdown (eg for a hump, the penalty would be zero if speed is 10km/h, but 20s if speed is 30km/h).

overall, my whole point is valid only under assumptions

• less segments => faster segment_function() computation
• less segments => less osrm-routed memory needed

if they are not valid, consider my argument invalid...

[github-actions]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.