add elevation aware bicycle routing profile

[boewing]

Issue

This PR solves the problem that the default bicycle profile does not incorporate elevation data. Hence, durations uphill are the same as downhill. In order to achieve proper elevation awareness, every user has to customize the lua files. This is error prone, as seen in Issue 5496. This PR adds better default bicycle profiles with elevation awareness.

The offered solution allows to integrate raster data for bicycle routing easily. It is based on the existing bicycle profile.

Please read our documentation on release and version management. If your PR is still work in progress please attach the relevant label.

Tasklist

• [x] update Changelog
• [ ] update relevant Wiki pages I would add an entry to Integrating-third-party-raster-data saying that a complete example file can be found here (the new lua file of this PR)
• [ ] add tests (see testing documentation
• [ ] review
• [ ] adjust for comments
• [ ] cherry pick to release branch

Requirements / Relations

No requirements. It works from master

[SiarheiFedartsou]

@mjjbell I am not very familiar with bicycle profile, but this PR looks interesting. WDYT? We could probably polish it and finally merge.

Just trying to clean up old PRs we have.

[mjjbell]

It's probably better suited for https://github.com/Project-OSRM/osrm-profiles-contrib

[SiarheiFedartsou]

It's probably better suited for https://github.com/Project-OSRM/osrm-profiles-contrib

Hm, I have idea that we probably should even merge this into existing bicycle.lua profile to optionally use elevation data if it is provided. Motivation: elevation is really important for cyclists and it would be great to take it into account by default. WDYT?

[mjjbell]

This is an example of using the existing raster data support, it's not specific to bicycle routing.

I'm not sure I see the value in changing the default bicycle profile to support this particular third-party data set (and committing to maintain it, tests, etc), unless we're planning to provide elevation data by default?

[boewing]

@mjjbell, the benefit would be the simple physical model to adapt travel time by slope rather than a fixed time in the default bicycle profile. And the default rasterbot profile has a division-by-zero-error for slopes >20% uphill, so it cannot be used right away.

I could adapt my profile to make it work with and without rasterdata. What do you think?

[SiarheiFedartsou]

This is an example of using the existing raster data support, it's not specific to bicycle routing.

I am not sure. As I understand it is the same bicycle.lua we currently have, but with elevation data used.

I'm not sure I see the value in changing the default bicycle profile to support this particular third-party data set

I see this as changing bicycle profile to support any third-party elevation dataset(but not particular one) if it is in format we already support. Do you see problems here? As I understand format we currently support is quite common in industry to represent such kind of data and users can just use anything from for example OpenTopology.

unless we're planning to provide elevation data by default?

I would just extend existing bicycle.lua a bit to allow people to just provide elevation data in some way(e.g. in environment variable as it is done now) and it would automatically start using it.

I could adapt my profile to make it work with and without rasterdata. What do you think?

Is it possible to just extend existing bicycle.lua to work as it works now without elevation data, but if user provided elevation data in format we support then start using it? At glance it is: new elevation_aware_bicycle.lua seems to be very similar on existing bicycle.lua.

[SiarheiFedartsou]

But anyway probably at least worth modifying documentation with up to date instructions on how to use raster data to enrich bicycle profile with elevation data(and yes we can simply put this profile to https://github.com/Project-OSRM/osrm-profiles-contrib). My only point is that it seems to be not a big deal to add some code to bicycle.lua to support this out of box. I.e. the same as now people download data from osm.org and use osrm-extract they can download also some data from OpenTopology(or from anywhere else) and do something like:

docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-extract --elevation-data elevation_data_in_format_we_currently_support.asc -p /opt/bicycle.lua /data/berlin-latest.osm.pbf 

Of course it is definitely possible to do the same on current version of OSRM via a bit of customization of existing profile, but this way seems to be a bit easier.

[boewing]

@SiarheiFedartsou I like your idea to simply make bicycle.lua accept rasterdata optionally. I can do that and refresh my PR to make this possible. Is this a doable way for you @mjjbell ?

[mjjbell]

My only point is that it seems to be not a big deal to add some code to bicycle.lua to support this out of box. I.e. the same as now people download data from osm.org and use osrm-extract they can download also some data from OpenTopology(or from anywhere else)

Right, but OSRM is built for OSM data, so it is committed to making it work with that dataset. My point was if we want to make elevation via raster data work out of the box as the default case, then we need to be sure that this additional dataset is well supported in the codebase.

Improving the docs, improving the slope modelling and making it easier to load raster data in the bike profile all sound like good additions, so if that's the plan then :+1:

[SiarheiFedartsou]

Improving the docs, improving the slope modelling and making it easier to load raster data in the bike profile all sound like good additions, so if that's the plan then

Exactly, that's the plan and agree with all your other points :+1:

[DennisOSRM]

closing stale PR. Reopen if still relevant.