[osrm profile] Adjust weight with a function of node/way distance

[iedmrc]

Hi

I want to adjust the weight of a node/way according to a function tied to its distance. I thought I can manipulate weight by manipulating forward_rate and backward_rate here: https://github.com/Project-OSRM/osrm-backend/blob/15f0ca8ddaa35c5b4d93c25afa72e81e1fb40c3e/profiles/lib/way_handlers.lua#L591 But I'm not sure how to get the distance of the node/way. How can I achieve this?

Thanks!

[danpat]

OSRM will multiply the *_rate by the length once the function is complete.

[iedmrc]

Thanks for answer!

But I couldn't get the point. I need to write something e.g. :

result.forward_rate = result.forward_rate*length_of_the_node_or_way

Just I don't know how to get length_of_the_node_or_way .

[danpat]

OSRM doesn't give the way length to the way_function - we didn't do that because ways in the OSM data can be split arbitrarily, even if the properties don't change. This means the length passed into the way_function wouldn't be as trustworthy as you'd think - it wouldn't guarantee to actually be the length of the feature you think you care about.

For example, let's say I'm afraid of bridges - I want to penalize crossing bridges with the square (n^2) of their length, so that I'm kinda OK to cross small bridges, but long bridges are avoided strongly.

If the length was available to the way_function, then you'd think you could do:

result.forward_rate = 1/(length*length)

But the problem is that the way_function is called for each way, not the whole bridge - the bridge may be split into several ways (e.g. speed limit changes, or other property changes that require way splitting, or just OSM editor preference for whatever reason). So the final calculated speed across the bridge will not be biased by length^2, but rather by the length of however the ways happen to be split up.

How are you expecting the length to work for your use-case?

[iedmrc]

You explained very well! Thanks.

Actually, we are routing by using VROOM and want to prevent a vehicle to go far away. For now, to accomplish this, we are trying to slow down the speed of the vehicles. Do you have any suggestions regarding this?

[danpat]

@iedmrc Can you describe a bit more what you mean by "prevent a vehicle from going far away"? Far away from what?

[iedmrc]

That means, we want to increase the cost of distant jobs hence vroom mostly (but not always) routes the vehicles to their closest job firstly.

[jcoupey]

increase the cost of distant jobs

That does not sound totally like a pure routing requirement, as a "distant job" is related to some reference, maybe a depot or vehicle location.

Depending on your use-case, you might be able to toy around with job priorities on the optimization level.

[iedmrc]

Hi @jcoupey , it's nice to see you here :)

By saying "distant job", I mean, distant to their (vehicle's) current position on the map. Yes, you are right about priorities but we wondered what can we do at OSRM level to deliver that need. Actually, more or less, it's a research and we were looking for alternative solutions to compare.

[jcoupey]

Hi @iedmrc :-)

distant to their (vehicle's) current position

Yes, that was my point: I don't really see how you could adjust weights on the routing level with a moving reference. The weights are baked into the OSRM data after extraction, while you'd like to adjust them depending on the start point at query time.

[iedmrc]

Yeah, but think about that, if we'd increased the values of costs matrix (for a minute, let's assume VROOM gets distance matrix rather than duration matrix as cost matrix) according to the quantity of each entry of the matrix, VROOM would choose the closest job as first, mostly. And we could do this by adding such a middleware between VROOM and OSRM that applies an exponential function to each entry of the cost matrix before the matrix reaches to VROOM. That is one case. We want to find another way to apply this idea at the OSRM level. And by using OSRM profiles, we could increase the cost of distance with an exponential function. We have several methods/ideas like this and want to collect more to compare all of them to find the best matching for our case. This one might be worst but still, we want to test/simulate and observe the results :)

[jcoupey]

VROOM would choose the closest job as first, mostly

I'm not sure I get precisely what you mean here. It could be:

1. you want to have the closest jobs included first in a route that also serves some further jobs later on
2. you want to have the closest jobs included in the routes by all means, while others can be unassigned

In the later case, this is already a natural tendency for the optimization results (closest jobs are cheapest to include), and besides that is precisely what jobs priority are for in VROOM.

If this turns into a discussion on adjusting costs/inputs for optimization, maybe we should switch to the VROOM repo. ;-)

[iedmrc]

If this turns into a discussion on adjusting costs/inputs for optimization, maybe we should switch to the VROOM repo. ;-)

Totally right. Comments until now give us intuition about the idea. Let us discuss in our team and if we need further help, I'm going to create an issue on VROOM and would appreciate your help!

[SiarheiFedartsou]

Stale.