brouter
brouter copied to clipboard
abrensch
Use of Sonny's LiDAR Digital Terrain Models within Europe
As far as I know Brouter uses internal elevation data which is followed for calculating routes. They are also used to calculate elevation sums on 3rd-party apps like Locus if there are no additional elevation files intalled. See for example https://help.locusmap.eu/topic/31440-lidar-digital-terrain-models-dtm-as-zip-possible#comment-126930
So maybe you wanna try "Sonny's LiDAR Digital Terrain Models" at https://sonny.4lima.de/ as an alternative within Europe?
The accuracy and resolution of its models' elevations compared to satellite-based surveys like ASTER, ALOS, COPERNICUS or SRTM is significantly better. Especially in wooded areas, steep rocky terrain or narrow valleys. Even if BRouter just uses the 3"-version for space saving reasons. File format (.hgt) and file size stays the same.
Hi Sonny,
yes updating the eleavation model is definitely on the agenda. It's not space savings that prevented updating to 1'' srtm data so far. It's just that I could not prove a significant effect on the results. Switching to lidar also requires some QA to look for edge effects. But I'm sure it will be an improvement.
Thanx for providing the aggregated data, really helpful.
@abrensch It seems you have some ideas for testing the data. Great. I have already prepared an update, but it will take some days for preparation.
My home lap contains a 5 km long monotonous ascend in a valley, which does highlight the limitations of the SRTM data:
I generated segments using Sonny's 3asec DTM for germany and a (slow) routing instance is available at https://brouter.knid.net/
@quaelnix Can you share this route and generate a plot which also includes the lidar data?
The barometer data was obtained from the average of 10 trips (5 in each direction) along the route:
It's not space savings that prevented updating to 1'' srtm data so far. It's just that I could not prove a significant effect on the results.
Unless I've done something wrong, this seems to apply to the LiDAR data as well, which honestly surprises me a bit.
I'm sure it will be an improvement.
It seems like a huge improvement (and it also greatly improves the accuracy of travel time estimation):
@abrensch, I've been using the LiDAR elevation data extensively over the past few weeks, and I have to say it's amazing.
However, depending on what elevation data we use, this seems to require different thresholds: https://github.com/abrensch/brouter/blob/ef73d468c057fc72208b5a32756ce73cda92c780/brouter-core/src/main/java/btools/router/RoutingEngine.java#L840-L845 5 m instead of 10 m apparently does the trick for the LiDAR data.
My winter commute along two rivers with several bridges and many underpasses:
@rkflx, I'm having a hard time finding even one place where the LIDAR data (1asec) fails.