ben/brouter
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

Import brouter website as markdown

Browse source
This commit is contained in:
Manuel Fuhr 2021-11-30 19:12:41 +01:00
parent c6bdf1709c
commit 0b9ea9b4c0
10 changed files with 687 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/features/elevation.md Normal file
View file

@ -0,0 +1,24 @@
## Elevation algorithm
Elevation awareness is the most important issue in bike routing if not routing
in a flat country. But in most routing software, elevation is either not handled
at all or in a way that is not really useful.
Even worse, most tools do not even report on elevation in a useful manner. The
far-too-high *total climbs* usually reported do not only accumulate real, small
height-variations that are averaged-out by the bikers momentum - they accumulate
also noise and grid-interpolation errors from the elevation data source.
For most regions, BRouter uses elevation data from the [Shuttle Radar Topography
Mission (SRTM)](http://srtm.usgs.gov/), precisely the hole-filled Version 4.1
Data provided by [srtm.csi.cgiar.org](http://srtm.csi.cgiar.org/), which is the
data that is displayed e.g. in Google Earth and which is used in most
elevation-enabled routing tools. However, the routing algorithm is able to
extract the information on real ascends and descends and ignores the noise.
For latitudes above 60 degree in northern Europe, BRouter uses Lidar data, that
were [compiled and resampled by Sonny](https://data.opendataportal.at/dataset/dtm-europe)
On the reporting side, BRouter uses a similar concept to compute the *filtered
ascend*, which is the ascend without the noise and the small hills and which
turned out to be a valid concept to estimate the real elevation penalty.