Hiking time: inform user on Number of points

[davidoesch]

Situation Several issues (#3492 #3743 #4083 #4044 and many more) do affect a correct profile/hiking time estimated from a user perspective. this is related to the fact, that only 200 samples are taken between user set waypoints ..if distance becomes to big... profiles do not show min/max values correctly and hiking time is faulty: due to undersampling . First guess: A good result is : user sets every km a sample point: so the sampling distance is 5m , a best result would be every 500m a user set waypoint. Bad results above 3km distance between sampling point

Task

1. show user position of waypoints in profile
2. inform user on sampling rate
3. encourage user to add more waypoints based on sampling rate/distance

Action

• [ ] show user added waypoints in profile (see mock up below)

• [ ] show info with samling distance (see mock up below)

• [ ] based on resulting sampling distance, encourage user to add more waypoints/issue warning (see mock up below)

• [ ] optional: show sample points in the profile graph

• [ ] optional: show only non-smoothed 3djs graph

• [ ] optional: based on sampling distance don't show profile/hikingtime or make it red / more transparent etc..

Result: user is aware of the accuracy based on waypoints provided

@danduk82 :pls revert the nasty hack which overrides the user provided waypoints positions before

[procrastinatio]

The main goal of the profile service was never to give accurate height information, but to provide a profile which looked nice while protecting the valuable DTM data. In my opinion, the profile service should only attribute height to sent points, not doing some black magic in simplifying the profile or adding additional points to the existing one. Now you may

• Set two points some 200km apart and get back a "wrong" profile.
• Digitalize more than 200 points, which is going to be simplified and returned. You may loose some digitalized points of importance (peak for instance)
• Height may be quite wrong, e.g Finsteraarhorn is 4274 (map) and 4271.6 (height service), much more if you miss the peak even by a few meters

From the service point of view, I think it is better to make one 1000 points requests instead of 5 requests of 200 points.

[oterral]

+1 for doing more requests than a big one

[procrastinatio]

If you more marginally reliable data for hiking time, use not smoothed data (see https://github.com/geoadmin/service-alti/pull/34)

[procrastinatio]

Whatever you do, it is wrong against Wanderland reference time Same formula, exact same point (but slightly different altitudes), very different cumulative altitude gain and loss, resulting in very different hiking time (red ones are hiking time +/- 5% of wanderland)

https://s.geo.admin.ch/7adb816059

By the way, what is an accurate time? With every year passing, I have the impression that official time on hiking shield are slower and slower.

[davidoesch]

The official time is the one provided by email. Maria did use it for the dev.

... And you are getting more fit 😝

[davidoesch]

ping @danduk82 we need to have a road map here... IMHo can only be solved with snapping to hiking tracks and precalculate hiking time , store in vector. extract it from there

[davidoesch]

This one is on hold: First we need to fix: A) https://github.com/geoadmin/service-alti/issues/43 then B) https://github.com/geoadmin/mf-geoadmin3/issues/4944

Then we need top determine the max length of profile when using B) , also for imported KML independent of vertex waypoints of drawing but do a correct resampling

If B) threshold is met: display only smoothed curve but for all paramters calculated just show "profile to long" --- or use the chmobil approach: tho show full length using multiple calls of alti service