multimodal routing engine in backend

[stefanocudini]

hi @jcoupey

I was wondering if there are any case study of using vroom with multimodal routing engines.

vroom now does not natively support engines like OpenTripPlanner (excellent multimodal engine) but I think the integration it shouldn't be complex

in your opinion, are there some logical problems with of meaningless results, or is it simply not useful?

for example, I a problem that solves the movement of masses of people through a set of different public transports in many places

[jcoupey]

VROOM is routing-agnostic in the sense that it only uses the results (travel times between points) provided by whatever underlying routing engine is called. You can even bypass the routing altogether with the bring-your-own-matrix feature. At the optimization level, we don't really care how the routing happens: what profile, single or multi-modal etc.

We currently only have support for OSRM and Openrouteservice simply because no one bothered to write wrappers for other options. But there is no limitation related to integrating a multi-modal routing engine as long as it can:

• compute a matrix of travel times (this happens prior to optimization)
• retrieve global indicators for each route once they're computed (distance, duration, geometry)

I don't know OpenTripPlanner very well, but my guess is that it is not designed to compute travel time matrices very fast, so I'd expect the matrix part to be a bottleneck in term of computing time.

In order to see if a direct integration is possible, the first step would be to make sure OpenTripPlanner offers a convenient way to compute travel time matrices. Do you have any input on this?

[stefanocudini]

no it was just my reasoning on how a multimodal routing could influence the optimization choices of a VRP problem. An example is a route with many changes in the middle should have a higher cost

[jcoupey]

An example is a route with many changes in the middle should have a higher cost

Then the waiting time occurring upon those changes would simply be backed into the travel time costs computed by the routing layer.

On the technical side, writing a new wrapper is not a huge task because we already have all the pieces together: it mostly comes down to adjusting how the requests are performed and the responses parsed. If you (or anyone else) is interested in giving it a try, just let me know so I can provide some pointers.

[jcoupey]

@stefanocudini do you think you'd have need/time to work on OpenTripPlanner integration? In that case, I'm happy to flag this issue as a feature request. If this was more like a generic question, then probably we can close it now?

[stefanocudini]

maybe in a few months I may have the opportunity to work on this but unfortunately not now my life is a bit complicated. you can close it now, in the future I will remind you of this if anything..

thanks for your kindness