From what I can tell, this is rather a design choice than a bug. All optimization software I'm aware of usually ingest a matrix of travel times (e.g. from the table plugin) and sometimes other indicators such as distance, but the optimization objective always rely on travel time.

I agree there is some kind of discrepancy here, as when using routability in the profile, weights come into play and the routing and trip optimization objective are slightly different. But I tend to see weights rather as an internal routing-specific parameter that you don't really want exposed at the optimization level.

As rate(weight) should take priority over speed(duration)

My guess is that on the contrary most end users would go for the clockwise route, because it's twice as fast. In fact, if you provide the other option and the user spots the difference, I think you'd have quite a hard time trying to explain why you didn't provide the fastest option in the first place.

Beside the white-board/theoretical example, do you have any real-life example where this is a problem?

@jcoupey

I agree that optimization objective always rely on travel time. On the other hand, we need to take users' preferences into account and there are some preferences that go against duration. I guess that's why there's weight along with duration.

As for me, I use weight to model a trade-off between duration and toll, leaving duration for a real duration. By doing so I can tune the trade-off without affecting a resulting duration. However, trip api using duration for waypoint ordering makes it hard to take full control of the api results.

I admit that the example above was quite extreme. Here I present a simplified version of a real-life example that I've encountered.

                     C                                  D

-----------||-------------------||--------------------------
|                                                          |
|   A                            B                         |
|                                                          |
--------------------||--------------------------------------

Assume we can access a rectangle area only through gates and there is a toll. By setting roundtrip=false, source=A, destination=D, I expect trip api to return A->B->C->D as there's no need to pay a toll. But current implementation yields A->C->B->D which we have to pay a toll and I cannot alter the result without changing real duration.

It seems that the case holds when weight which does not affect duration is added and detour takes quite long (or when there's no detour).

This PR seems to be stale. Is it still relevant?