Mountain slope/elevation not taken into account properly

[Yogurt4]

🐞 routing report

Routing engine

• [X] OsmAnd's in-app offline routing
• [ ] Any online routing provider (YOURS, openrouteservice, OSRM, etc.)

Routing Profile

Pedestrian, "Use of elevation data" is enabled.

Start and end points

Velika Previja - Bobotov Kuk

Actual and expected routes

The routing is OK - as there is no other way to the peak. However, OsmAnd tells this is 420 metres and it will take 17 minutes. In reality:

Is this a regression?

🌍 Your Environment

OsmAnd Version:

OsmAnd 4.2.7

Device and Android/iOS version:

Redmi 8 Android 10 QKQ1.191014.001 MIUI Global 12.5.2

Maps used (online or offline):

• [X] Offline maps offered within the OsmAnd app for download. Montenegro 1 July 2022, Montenegro elevation map (online, cached), Montenegro elevation contours
• [ ] Online (tile / raster) maps

Anything else relevant?

In mountains, track length (2D horizontal projection) is much less than the length of the actual path. Here, the elevation of the starting saddle is 2346 m, elevation of the peak is 2523 m => gain = 177 m. The last 50 m is quite steep (T4 on the SAC scale), secured by steel cables.

So if there's a significant elevation to be climbed, the distance may be increased (Pythagorean theorem) and the walking speed may be decreased to climbing/crawling speed.

[sonora]

2 effects here:

1. Pythagoras: Forget it. The effect for 1000m horizontal projection climbing 177m is about 15 extra meters, negligible. Even for a climbing route of 420m gping up 177m the effect woulde be just 35m. So if OsmAnd tells you the route is just 420m but reality says 1000m, the root cause must be the map dara.
2. For the extra time required to climb we take Naismith's rule. Of course, Naismith is a hiking approximation, not rock climbing (you mention "steel cables"). But gives good results and is a battery-friendly algorithm. ;)

[Yogurt4]

OK. The map data itself is 2D. If you have a vertical ladder, the OSM route will be 0 metres - even though it has a certain (non-zero) length. One can add an incline tag to the way - but that value can be also calculated from the elevations.

By steel cables I haven't implied it is a via ferrata or climbing route. They are there only for safety, something to hold on to, like if there's high winds, ice, or rain.

I was just trying to find some explanations, not to solve the problem I've experienced.

[sonora]

Can you share the start and end location of the route? I'll be happy to take a look.

Just to be sure: You are saying that OsmAnd calculates the correct route, but claims it is only 420m in length, while in reality it is 1000m, right?

[TheSnoozer]

Start and end points

Velika Previja - Bobotov Kuk

(mentioned by the author of the ticket)

[Yogurt4]

Just as TheSnoozer wrote, the start/end locations are in the original ticket. You'll find both places on the map. With coordinates: 43.12676, 19.03636 -> 43.12813, 19.03477

As for the difference in distance, I know OSM data may be simplified, missing a lot of small turns. I haven't measured the length of the OSM way object. Having a shorter distance in OSM may be a reason for a shorter trip time.

But I have problems with the numbers in OsmAnd itself. If we have a 420 m path with 170 m of elevation (an average incline of 40%), is 1.5 km/h a realistic speed? I know nothing of Naismith's.

[TheSnoozer]

Issue is related to https://github.com/osmandapp/OsmAnd/issues/10830, perhaps this could even be considered a duplicate

[sonora]

Ok, thanks! Here's how it looks:

1. The OSM way is in deed only 474m long (paths paths https://www.openstreetmap.org/way/69042193 and https://www.openstreetmap.org/way/715019400 ).
2. The link you had included points to the corresponding OSRM (Foot) route, which calculates as 474m (8 minutes). OSRM considers no elevation change, hence the return trip is also estimated at 8 minutes). (Screenshot 1)
3. Side note about Pythagoras: If the route climbs 177m, you can estimate its actual length in 3D space to be of the order of 506m, so the difference is not decisive, even for this above-average steep trail. The world is not "3D-enough" for Pythagoras to make a real difference for hiking or biking tours. ;) )
4. OsmAnd routing can take the elevation change into account, then estimating 17minutes up (screenshot 1), while only 11 minutes down. This is done using Naismith's rule (20 additional minutes for every 400m ascent), which works remarkably well for most situations. If the route on hand is unusually steep, it may underestimate a bit. Judging from photos, this could be the case here, but I doubt it explains the factor of 2 you are looking for. I rather think:
5. Either the ways on OSM are really simplifid considerably, i.e. missing lots of small turns an switchbacks. This is a possibility, but the satellite imagery does not necessarily indicate that...
6. Or: The 101 hiking tour goes from Žabljak to Šarban and says "via Bobotov kuk". I believe that, as stupid as this may sound, the sign may mean to indicate the entire "detour", i.e. the way in and back out to the T-junction? Looking at the sign again, I believe that the Skrcki Pogled pass is situated right on the ridgeline at 2440m elevation, righly where my marker is placed in Screenshot 3. By inspection this really looks only about 200m away from the T-junction. Same for the trail's end at Bobotov kuk,it looks like 500m, not 1000m.

In any case, I cannot find anything OsmAnd could do better here, it really seems and issue with the underlying data, or with what the sign means to say..maybe it's overly cautious due to the terrain encountered. In any case, a great tour, thanks for the experience! ;).

[Yogurt4]

Hi sonora, It all sounds reasonable. Thank you for your time.

Unfortunately I didn't have my RTK receiver with me I usually carry for hiking. But I'll try to add turns to OSM, and split the way into smaller parts and tag them more detailed by my photos.