r5r v0.5.0 - Isochrones and Topography

[mvpsaraiva]

The new development version of r5r is available on the dev branch, and can be installed with:

utils::remove.packages('r5r')
devtools::install_github("ipeaGIT/r5r", subdir = "r-package", ref = "dev")

A gist demonstrating the new features can be found here.

The new version has two main features:

Isochrones

The new isochrones() function of r5r uses the IsochroneFeature and WebMercatorGridPointSet classes from R⁵ to quickly build isochrones. The function returns the isochrones as spatial sf objects.

Topography

Although R5 doesn't have native functionality to account for slope in walking/cycling, it can use custom generalised costs introduced in a pre-processing step, as described in R5 issue #47. I've introduced a similar pre-processing step in setup_r5 to weight street edges by their slope, if a DEM raster file is found in the data_path. Weights are calculated similarly to OpenTripPlanner. for walking, I use Tobler's hiking function, following the discussion on OTP's issue #2579. For cycling, I use the slopeSpeedCoefficient function from OTP's ElevationUtils.java.

Those are not intrusive changes to R5, as they just use the walk and bike time multipliers of the Edge class. Technically, we can even allow the user to provide custom weighting functions, to fit the package to different use cases.

[mvpsaraiva]

Here, a few examples showing the effect of slope on the isochrones. On top, the isochrones were calculated with topography, while the isochrones in the bottom were calculated on flat terrain. The effect is subtle, but it can be noticed in some areas.

[rafapereirabr]

Hi @ansoncfit, @abyrd and @mattwigway.

@mvpsaraiva has implemented this temporary solution to consider elevation within r5r. Nonetheless, we recognized the ideal scenario would be to a have a solution implemented upstream in R5. If you think the approach we adopted in r5r could be somehow adapted and incoporated into R5, we (i.e. @mvpsaraiva) would be glad to contibute with that.

[rafapereirabr]

For the record, this paper by Flüge et al (2019) used GPS data with aprox. 50,000 single cycling trips to estimate the effects of elevation on cycling speed. "In the models, speed on a network link is described as a function of several characteristics of the infrastructure and topology, and differs by user segments such as gender, trip purpose and type of bicycle".

Here is how Pajares et al (2021) incorporated this info in GOAT, their new tool for accessibility analysis:

"The results of the study from (Flügel et al., 2019) were used to generate a relationship between the slope and a normalized impedance factor presented in Fig. 9. For street links longer than 10 m, sloped profiles were calculated in intervals of 10 m and the calculated impedance factors were aggregated by the weighted length of the subsegments per link. The elevation points for the street segments were computed using the inverse distance weighting method commonly known in geography and the European digital elevation model with the spatial resolution of 25 m (Table 4)."

[rafapereirabr]

We'll continue the discussion of a temporary solution to elevation on issue #171 .

[rafapereirabr]

We'll continue the discussion of an isochrone function in issue #123. Close this issue for now