News for hackers. Stuff that matters.
Re:More precise elevation data for GraphHopper routing engine by sarnu on Thursday March 26, 2026 @08:32AM (#47529655)
Yes, agree. Some services (e.g. komoot) apparently have good data, or can work around it. Others are struggling with lack of precision in the DEM data. As much as I like the tweakability of BRouter, the tracks generated never give realistic elevation info.
Re:More precise elevation data for GraphHopper routing engine by jeffbee on Thursday March 26, 2026 @10:01AM (#47530578)
Garmin and Strava must be sitting on a gold mine of practical DEM data based on ride and hike records. They have huge databases from mobile devices recording GPS position, speed, and pressure.
Re:More precise elevation data for GraphHopper routing engine by sarnu on Thursday March 26, 2026 @11:28AM (#47531711)
My guess is that analyzing the recorded activities is what komoot did to get useful elevation data.
Re:More precise elevation data for GraphHopper routing engine by qwhelan on Thursday March 26, 2026 @12:38PM (#47532641)
Yet it's unclear to what extent they actually use them - on freeway adjacent bike paths that have different gradients than the adjacent freeway (typically steeper), it's very clear Garmin is using data referencing the freeway.
Re:More precise elevation data for GraphHopper routing engine by jeffbee on Thursday March 26, 2026 @01:08PM (#47532972)
They must be doing something that integrates user-contributed data because one quirk of their course planner[1] is an out-and-back plan along the same course will have non-coincident elevation profiles, even along trails where it can't be explained by switching sides of the road.

1: And their planner, in general, is garbage. I usually take the output file and run it through an AI system to fix it so it doesn't try to cue me to pointlessly switch to the other side of a major road and ride on the sidewalk.

Re:More precise elevation data for GraphHopper routing engine by GorbachevyChase on Thursday March 26, 2026 @07:44PM (#47537312)
If they’re sourcing some of their information from GPS data, the vertical precision for elevation is pretty poor, even if you’re using professional equipment. I’ve been being off a foot or tube is perfectly normal. You really need to use survey monumentation as controls. Also many states known invest in a statewide light R elevation program. It’s really too bad because they are so useful for planning and design.
Re:More precise elevation data for GraphHopper routing engine by qwhelan on Friday March 27, 2026 @05:47PM (#47548745)
Yeah, it's understandable that the real world is messy and user-sourced data can be very suspect.

The case I'm thinking of is the eastern end of SR-520 over Lake Washington in the Seattle area. It has hundreds/low thousands of bicycle crossings/day (so surely dozens of Garmin users/day), the background is a dammed freshwater lake with a well known elevation, and clear view of the sky. Yet the elevation data is garbage somehow.

It doesn't really matter for planning purposes as any alternative has such a huge delta but it does signal that user data isn't being utilized to refine their data set even on high volume segments.