organicmaps/organicmaps

Fork 18

[core] Fix track length calculation to take into account the ascend/descend #9883

New issue

Open

opened 2024-12-17 15:19:31 +00:00 by kirylkaveryn · 8 comments

kirylkaveryn commented

2024-12-17 15:19:31 +00:00

Member

The current method 655cf0f174/geometry/mercator.cpp (L50)
is only calculates a projection between points and does not consider the ascend/descend.
The true length for the track distances should be the sqrt(projection ^ 2 + ascend ^ 2)

The general difference will not be very big but sensitive:

Track	projection	real length
Track 1	2146 m	2152 m
Track 2	6991 m	7005 m
Track 3	10 002 m	10 111 m
Track 4	6991 m	7005 m
Track 5	8158 m	8182 m
Track 6	15 635 m	15 760 m

The current method https://github.com/organicmaps/organicmaps/blob/655cf0f174ed78e4163bc160e85cb19289a00a72/geometry/mercator.cpp#L50 is only calculates a projection between points and does not consider the ascend/descend. The _true_ length for the **track distances** should be the `sqrt(projection ^ 2 + ascend ^ 2)` The general difference will not be very big but sensitive: | **Track** | **projection** | **real length** | |-----------------|----------------------|----------------------| | Track 1 | 2146 m | 2152 m | | Track 2 | 6991 m | 7005 m | | Track 3 | 10 002 m | 10 111 m | | Track 4 | 6991 m | 7005 m | | Track 5 | 8158 m | 8182 m | | Track 6 | 15 635 m | 15 760 m |

kirylkaveryn commented

2024-12-17 15:19:32 +00:00

Author

Member

assigned to @kirylkaveryn

assigned to `@kirylkaveryn`

kirylkaveryn commented

2024-12-17 15:34:27 +00:00

Author

Member

mentioned in merge request !9884

pastk commented

2024-12-17 17:15:42 +00:00

Member

Taking it into account for tracks and routes seems fine and logical.
However is it a common/standard way? I don't really know. Anyone?

Altering the base DistanceOnEarth() which is used everywhere - probably not a good idea.

Taking it into account for tracks and routes seems fine and logical. However is it a common/standard way? I don't really know. Anyone? Altering the base `DistanceOnEarth()` which is used everywhere - probably not a good idea.

kirylkaveryn commented

2024-12-17 17:40:26 +00:00

Author

Member

Altering the base DistanceOnEarth() which is used everywhere - probably not a good idea.

Right! I updated the issue description that it is only about the track distance calculations.
I created a new method only for the calculation distances between two PointWithAltitude
#9884

> Altering the base `DistanceOnEarth()` which is used everywhere - probably not a good idea. Right! I updated the issue description that it is only about the track distance calculations. I created a new method only for the calculation distances between two `PointWithAltitude` https://git.omaps.dev/organicmaps/organicmaps/pulls/9884

RobfromVI commented

2024-12-17 20:35:09 +00:00

(Migrated from github.com)

I think GPS derived altitudes are somewhat inaccurate in general.

Please check how true are the recorded altitudes before introducing this change.

I have found in the past that recorded GPS tracks displayed with altitude tend to have much bigger variation in altitude than what actually ocurred, with sometime significant ups and downs showing for a track recorded nearly flat. This would resut in very erroneous distance calculations maybe bigger error than if calculated flat. I think GPS derived altitudes are somewhat inaccurate in general. Please check how true are the recorded altitudes before introducing this change.

muralito commented

2024-12-18 02:26:38 +00:00

(Migrated from github.com)

Luckily for us the error does not propagate to velocity, (not really by luck but because the algorithm to calculate it)
The same could be true when using the elevation for distance calculation, because is the error does not grow, as the algorithm is using the difference in elevation from two adjacent positions (so I suppose that if the positions are near enough, the error cancels itself).

Maybe some volunteers can test it, contributing with readings in level 0 and in the top levels of a building with known height...

So, is not only what you have found or perceived, it is what happens with GPS receivers in navigators, but that probably does not impact this PR.

@kirylkaveryn : is this method used when the distance is large? did you validate the method when the distance between positions is large? the curvature of the Earth can invalidate your algorithm...

I don't remember the source because i read it several years ago, but I'm almost sure that GPS navigators are optimized for precision in x-y axis (position on the "ground" and not z axis (altitude), and the error in the z-axis can be several times larger than the other axis, so if the altitudes are derived from these tracks this can happen. In the position usually you can expect error to be under 10 m, but in the z axis there can be errors of 50 or 100 meters or even larger. The GPS z axis information is limited by design when used in civil mode, and also when the x-y-z coordinates derived from the satellite positions, are translated to position and altitude, this z is approximated to the ellipsoid in that position, which is another source for error in altitude. Luckily for us the error does not propagate to velocity, (not really by luck but because the algorithm to calculate it) The same could be true when using the elevation for distance calculation, because is the error does not grow, as the algorithm is using the difference in elevation from two adjacent positions (so I suppose that if the positions are near enough, the error cancels itself). Maybe some volunteers can test it, contributing with readings in level 0 and in the top levels of a building with known height... So, is not only what you have found or perceived, it is what happens with GPS receivers in navigators, but that probably does not impact this PR. ` @kirylkaveryn` : is this method used when the distance is large? did you validate the method when the distance between positions is large? the curvature of the Earth can invalidate your algorithm...

RobfromVI commented

2024-12-18 03:32:44 +00:00

(Migrated from github.com)

Our recorded tracks appear to use points about 13m apart horizontally, so it would not take much up and down error to greatly increase the calculated travel distance.

May I suggest an option to show plan-distance alternatively for comparison if this is implemented??

Our recorded tracks appear to use points about 13m apart horizontally, so it would not take much up and down error to greatly increase the calculated travel distance. May I suggest an option to show plan-distance alternatively for comparison if this is implemented??

kirylkaveryn commented

2024-12-18 08:31:23 +00:00

Author

Member