Use weight instead of duration for trip api

[ijleesw]

Issue

In the above case, Trip API returns a clockwise route for a roundabout trip instead of a counter-clockwise route.
As rate(weight) should take priority over speed(duration), this looks like a bug.
Fixed this by changing ManyToManySearch to return a weight matrix along with duration/distance matrices and using the matrix in TablePlugin::HandleRequest.

Below is data I used to test my code.

$ cat rectangle.osm
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="none">
  <bounds minlon="127.11664666" minlat="37.38013706" maxlon="127.12157070" maxlat="37.38390685" />
  <node id="1" lon="127.11967395" lat="37.38390685" />
  <node id="2" lon="127.12157070" lat="37.38217534" />
  <node id="3" lon="127.11851713" lat="37.38013706" />
  <node id="4" lon="127.11664666" lat="37.38172113" />
  <way id="101">
    <nd ref="1" />
    <nd ref="2" />
  </way>
  <way id="102">
    <nd ref="2" />
    <nd ref="3" />
  </way>
  <way id="103">
    <nd ref="3" />
    <nd ref="4" />
  </way>
  <way id="104">
    <nd ref="4" />
    <nd ref="1" />
  </way>
</osm>

$ cat trip.lua
api_version = 4

function setup()
    return {
        properties = {
            weight_name = 'test',
        }
    }
end

function process_way(profile, way, result, data)
    result.forward_mode = mode.driving
    result.forward_speed = 10
    result.forward_rate = 5

    result.backward_mode = mode.driving
    result.backward_speed = 5
    result.backward_rate = 10
end

return {
    setup = setup,
    process_way = process_way,
}

$ curl 'http://localhost:5000/trip/v1/driving/127.11967395,37.38390685;127.12157070,37.38217534;127.11851713,37.38013706;127.11664666,37.38172113?roundtrip=true&source=first'

Tasklist

• CHANGELOG.md entry (How to write a changelog entry)
• update relevant Wiki pages
• add tests (see testing documentation
• review
• adjust for comments
• cherry pick to release branch

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

[jcoupey]

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?

[ijleesw]

@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).

[github-actions]

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