R5 routing

[joeytalbot]

Using library(r5r) we can get some very rapid routing. I will test the timing of this compared to OSRM. However the quality of the routing does seem to be a bit questionable. Here are some examples where the routing is using paths that don't seem to be suitable to motor vehicles, and routes that are clearly not the fastest. OSRM doesn't give these routes.

Clearly a diversion:

Not a road:

Not a road:

[joeytalbot]

Another strange thing is that the routes object created seems to contain several identical rows:

[Robinlovelace]

Interesting. Worth opening an issue with a reproducible example on the r5r issue tracker? The developers should have a good idea of how to overcome some of these issues which I agree are not what I'd expect. Great sanity checking. Outcome: not always sane!

[mem48]

I've seen similar problems with r5r. I've been updating opentripplanner to support OTP 2.2 I've also been making improvements to routing speed, so would be intresting to compare speed and quality.

[mem48]

OTP also supports UK specific routing profiles that are missing in r5r

[Robinlovelace]

This is really useful info. Let's go with OTP for now is my current thinking. Latest version on GitHub good to go @mem48 ? Greetings from UK to US based on time of your message!

[mem48]

I've just committed a fix which should mean all the check are now passing using both OTP 1.5 and 2.2 https://github.com/ropensci/opentripplanner/actions/runs/3807186624 which I take as a good sign, but I haven't done many manual checks with v2.2. OTP has changed a bunch of things need manual checking to ensure they are being interpreted correctly https://docs.opentripplanner.org/en/v2.2.0/OTP2-MigrationGuide/ .

The speed improvements I've made in the R package should benefit both OTP 1.5 and 2.2. I don't believe 2.2 has many intrinsic speed improvements except for transit routing, so if your not interested in that you could use the GitHub version today with OTP 1.5 and I'd expect it to work and be stable.

I’ve changed the way multicore routing works in the package. It now uses libcurl asynchronous requests rather than running multiple R workers. This means that you can run at 1.25x the number of cores on your machine (the max OTP will accept) but I’ve set the default at 1.25x – 1 which seems more reliable.

[mem48]

Arrg, one test failed on one setup

I don't think this will affect you as it is the otp_stop function and the problem is OTP closed without saying goodbye

[Robinlovelace]

Don't worry too much about all those tests. Looking forward to giving it a spin!

[mem48]

Ahh I've just spotted a bug, where the from/to IDs are not matchec correctly. I'll try to fix

[Robinlovelace]

OK thanks for the update. Keep me posted, I plan to set up a Docker image for Scotland.

[mem48]

No bug, I was being an idiot

[mem48]

I've pushed some more speed improvements to opentripplanner now getting 120 routes/second on my 4/8 core laptop with the Isle of Wight test data.

@joeytalbot I would be intrested to hear how that compares to your experience with r5r and OSRM

[Robinlovelace]

I've pushed some more speed improvements to opentripplanner now getting 120 routes/second on my 4/8 core laptop with the Isle of Wight test data.

Impressive.

[joeytalbot]

The cause of r5 routes that don't follow roads (as in the images above) might be related to the OSM dataset, which is generated as follows:

wyca_match = osmextract::oe_match(place = "tyne and wear")
osmextract::oe_download(file_url = wyca_match$url, download_directory = "data_r5")
r5r_core = r5r::setup_r5(data_path = "data_r5")
mode = c("CAR")

As well as routes following tracks not suitable for driving, r5 gives other unrealistic car routes. Maybe it isn't accounting for speed limits? See image below for an unlikely route on residential roads.

OTP is probably a better option for routing.

[joeytalbot]

I've pushed some more speed improvements to opentripplanner now getting 120 routes/second on my 4/8 core laptop with the Isle of Wight test data.

@joeytalbot I would be intrested to hear how that compares to your experience with r5r and OSRM

@mem48 in terms of timing, r5 gives around 3800 routes per second on my desktop. But 14% of routes failed, and there were quality issues as you can see from the images I've posted here.

[joeytalbot]

OSRM only did around 8 routes per second

[mem48]

Intresting that OTP is in an intresting middle ground. I don't think r5 is designed for individual routes, so the may be taking algorithmic shortcuts to favour speed over accuracy. The kinds of errors it is making probably only increase total journey time by a few %. So for making TTMs or accessibility stats don't matter. But for PCT style route networks matter a lot.

I'm glad opentripplanner is much faster than osmr it suggests I've not wasted my time trying to speed up my code.

Also as far as I'm aware opentripplanner has the best support for terrain as you can return detailed elevation profiles. I don't think r5 really supports terrain.

[mem48]

V0.5 is now on cran so should be stable and working

[joeytalbot]

Yes OTP should be really useful! I'm trying to get it working now. Getting the correct version of Java seems awkward. For the desktop I've asked IT support to install Java 8. For the atumscott Rstudioserver instance @Robinlovelace , Java 11 seems to be installed, but the OTP version on ropensci/opentripplanner wants Java 8.

[Robinlovelace]

OSRM only did around 8 routes per second

Probably because that's using the web instance. On localhost will be faster.