few improvement suggestions

[nilsnolde]

through a valhalla discussion I realized this repo exists. just wanted to leave a few thoughts here as we just implemented live traffic with tomtom in valhalla and maybe this helps a little:

• valhalla_build_extract already builds the traffic.tar for you with the -t flag, based on the routing tiles, you don't have to build it yourself: https://github.com/valhalla/valhalla/blob/2e5db62fa7d2ae9775d5209b10d02eac1541ee02/scripts/valhalla_build_extract#L45
• no need to restart the service if traffic updates. in fact that's destroys all caches and is very detrimental to valhalla's performance. instead you'd update the same traffic tar valhalla is mmap'ing byte-by-byte. all live traffic stuff is declared volatile so will be picked up dynamically as values change within the tar
• actually the most accurate thing to do is to use both live & historical speeds (for close to "now" departures). live traffic only has "priority" right at the origin and a time-decaying function takes care of blending in historical speeds (if available, or other speed sources). after one hour (currently) only historical speeds are taken into account. which speed source is tried depends mostly on your date_time.type settings. the GetSpeed function takes a little while to fully understand, also with respect to what's being used depending on data availability and date_time settings, but it's worth it:)
• matrix doesn't support live traffic (or any time info)

[alinmindroc]

Thanks for the info! This is some really useful stuff.

valhalla_build_extract already builds the traffic.tar

Yep, that's for sure the way to go in a production setup. Is there also some kind of tool / helper to update the the traffic.tar skeleton too?

no need to restart the service if traffic updates

For some reason, I noticed that the live updates weren't picked up if the traffic archive wasn't updated at least once before starting the service. Anyway, the restart was needed only once, and subsequent updates are picked up correctly. I still didn't find the cause for this.

[alinmindroc]

matrix doesn't support live traffic (or any time info)

So no predicted traffic neither? Then, it's only supported for the route and isochrone endpoints, right?

Edit: just did a test and I can see that sources_to_targets returns different values for distance and time when date_time is requested:

curl http://localhost:8002/sources_to_targets --data '{"sources":[{"lat":59.431,"lon":24.759}], "targets":[{"lat":59.43,"lon":24.784}],"costing":"auto","directions_options":{"units":"kilometers"}}' | jq

vs

curl http://localhost:8002/sources_to_targets --data '{"sources":[{"lat":59.431,"lon":24.759}], "targets":[{"lat":59.43,"lon":24.784}],"costing":"auto","directions_options":{"units":"kilometers"},"date_time":{"type":0}}' | jq

[nilsnolde]

Is there also some kind of tool / helper to update the the traffic.tar skeleton too?

you mean updating it with the actual speeds when you have new traffic data? no, there isn't, you'll have to do that yourself. the way I do it is mmap'ing a tar skeleton (only 0 bytes) in private write mode (i.e. changes only happen in this process and are not written back to the file), then loop through the updated edges, only updating those bytes with mmap that need updating. if just toying around that can be the tar valhalla sees as well, i.e. on the same machine, in which case you'd not do private mode but public and write your changes to the tar at some point. in a production setup that's more complicated, as you can imagine.

So no predicted traffic neither?

nope, unfortunately not. the matrix algos don't track time, see e.g. https://github.com/gis-ops/valhalla/blob/master/src/thor/timedistancematrix.cc#L518 (just one example, every matrix algo, the cost & timedistance one behaves the same with timeinfo). I didn't track the code properly but what you're seeing might be constrained flow speed which is present if you use predicted speed, see here https://github.com/gis-ops/valhalla/blob/master/valhalla/baldr/graphtile.h#L625. that's smth I guess, but also not necessarily accurate since valhalla has no way of knowing if your passed time is during the day or night (in which case you'd want freeflow speed, but it'll never get down there bcs the flow_mask defaults to kConstrainedFlowMask). actually this sounds like a minor bug maybe? would have to look into it more.

honestly though, valhalla matrix is meeh. it's awesome that it's almost as flexible as route & isochrone (with the only exception being time tracking), smth you hardly get with any other foss routing engine. but it's pretty slow and consumes crazy amounts of RAM when used "improperly" (meaning too many locations over a too huge area). the RAM part could for sure be improved, but the performance not so much. it's the old trade-off flexibility vs time.

hope that helps a little. we're always welcoming new contributors btw:) now and then we meet up to discuss PRs but people are welcome to join in. I used to keep a schedule on that here but that's gone pretty stale since there was no interest from anyone but me and kevin. so we just meet up when we feel like it. I'd revive that though if there was genuine interest by others.