how to pass extra parameters

[stefanocudini]

in reference to this code, I see that vroom supports passing extra parameters to ORS directions
https://github.com/VROOM-Project/vroom/blob/fed2ca8b52b687cddabdf9ca77582af54953ec6f/src/routing/ors_wrapper.cpp#L42

I would like to make sure that the directions requests made by vroom to get the path geometry also include the restrictions parameters
I'm using vroom through vroom-express

How can I include these extra arguments in the request sent to vroom-express?
Is this thing supported at the moment from the api?

[nilsnolde]

Currently that's not possible. Which makes sense since vroom can't take into account any restrictions when generating matrices (since neither OSRM nor ORS support custom-weighted matrices). And it wouldn't be too wise to base the output path on other weights/restrictions than the optimization used. And if the input to the optimization was a custom matrix which indeed was generated with those weights, then you can generate a route from the locations of the vroom-express response with a normal directions request to ORS/OSRM.

That being said, if I ever get to it, I'd like to include Valhalla which comes with dynamic matrix requests. So, the latest then it becomes an important question. Also ORS started working in that direction recently thanks to @HendrikLeuschner (#385).

But then I guess in the first place this is rather an issue for vroom, right @jcoupey? Maybe we can keep it open here until that happens?

[jcoupey]

vroom supports passing extra parameters to ORS directions

Not exactly, there are indeed parameters passed to the routing query, but they are hard-coded and defined in the ORS wrapper constructor. To add to @nilsnolde answer, the sole purpose of those parameters is to make sure we get consistent travel time estimates between matrix and route requests. And I wouldn't recommend changing that either as then you may end up with routes that were considered valid based on the matrix, but become invalid with additional restrictions (e.g. arriving too late for a given job).

For now, the easiest way to deal with restrictions would be to do it "the OSRM way", i.e. move the decisions to the routing profile work, prior to generating precomputed routing data (as suggested back in VROOM-Project/vroom#310 (comment)). Not flexible, but then you'll get everything you need taken into account for optimization, both in matrix and route requests.

[jcoupey]

But then I guess in the first place this is rather an issue for vroom

Yes we'd have to pass extra arguments from the vroom command-line to both matrix and route requests. As you said, this does not make sense right now as it's supported by neither wrappers. Let's keep this open here for reference.

[stefanocudini]

But then I guess in the first place this is rather an issue for vroom

Yes we'd have to pass extra arguments from the vroom command-line to both matrix and route requests. As you said, this does not make sense right now as it's supported by neither wrappers. Let's keep this open here for reference.

yes thank you, I wrote this issue because maybe having a vroom-express that supports additional parameters would be useful in other cases.

in reference to the warnings of @nilsnolde
I had expected the inconsistency of the solutions that this approach could bring.
I was trying to find a temporary solution, even if not perfect, until the ORS matrix supports the profile parameters. Probably for my case study the timing problems should not emerge in relevant way.
unfortunately I can't completely change the router engine in my environment with Valhalla for now.

however I wrote a simple http proxy (in nodejs) that gets in the middle between VROOM and ORS so that I can append parameters of requests sent by VROOM to ORS, for various reasons I also use this to logging exchanges between services