Precision (decimal positions) in displayed distance

[AntonioLagoD]

Is your feature request related to a problem? Please describe.

Hello. I noticed in the track details screen distance is displayed with one decimal position until 20 km and as integer above 20 km. See the image.

Describe the solution you'd like

Maybe it is posible to increase the precision above 20 km or include an option in the menu 'configuration -> units'.

Describe alternatives you've considered

Give a reason why someone else should spend time on that request

Maybe in long routes this issue does not matter, but in short routes (walking or cycling) several hundreds of meters can make a big difference in some terrains.

Additional context

[mitxel-m]

I would appreciate it too. Now, both 21.60 Km and 22.40 Km are shown as 22 Km, but there is 800m difference.

The other part comes in the logs and summaries, which shows a mix of distance rounding, which looks strange to me, and in a few cases can lead to inconsistent results

For now, distances are shown like this	range	shown as	example
0-1 Km	m	376 m
1-10 Km	Km rounded to 2 decimals	1.45 Km
10-20 Km	Km rounded to 1 decimal	15.6 Km
> 20 Km	Km rounded to integer	22 Km

* The same applies for mi / ft

I know this has been discussed before, and I understand that some people want to see long distances rounded, but since the term 'long distance' is a very personal measure depending on your activity, I also think it would be useful to have an option in the units configuration UI to choose how to show them.

However it's not that easy, because at the same time that I want to see distances in km with two decimals I also like to see distances below 1 km in m without decimals.

That said, it will be difficult to please everyone. Maybe, to satisfy most people, it could be managed in the units configuration UI in one of these ways:

1. A simple check button : [ ] Show distances above 1 [ Km | mi | nm ] with two decimal digits. (off by default). ( distances below 1 km will be shown in m / ft)

2. A numerical value box:
   Show distances above ____ [ Km | mi | nm ] rounded.
   ( actual behaviour) (20 by default) ( distances below 1 km will be shown in m / ft)

3. A combination of the two above: Radio buttons to choose one + numerical value in the second one to customize it.

( ... just an initial approach)

[mitxel-m]

Sorry I realized that the second option would cover most cases, and is probably the one that would require the least code modifications.

How it would work: If you set the value to 200 , it would use these ranges

range	shown as	example
0-1 Km	m	376 m
1-100 Km	Km rounded to 2 decimals	31.45 Km
100-200 Km	Km rounded to 1 decimal	154.6 Km
> 200 Km	Km rounded to integer	220 Km

In the code would be necessary to replace where the ranges are defined

actual range	new range
< 1	< 1
from 1 to 10	from 1 to value/2
from 10 to 20	from value/2 to value
> 20	> value

In the gui add an option to set the value and save it in the config file/reg Show distances above ____ [ Km | mi | nm ] rounded.

[kiozen]

You guys are aware that we deal with consumer grade GPS devices? We have errors in the meter range. I can give you 6 digits precision and you can take the numbers for the lottery. But you won't get any meaningful distance out of them.

[frankystone]

For tracks from devices you are right. But what about the distance during planning a track/route? Or is this also vague?

I think rounding to one decimal would be sufficient.

[mitxel-m]

Of course, I am aware that our devices are not accurate, and I do not expect much from them. And I am also aware that measurements on the map are projected distances and not real distances, but that is not the issue.

This is more a question of how QMS shows the data, and concerns various scenarios:

Planning a route I want to compare two alternatives, both are shown by QMS as 22Km. However one is 21,6 Km and the other 22,4 and there is 800m difference. The key point is not whether 800m is too much or too little, but I want to know which is the shortest one and now I can't see that.

Another place where this calls my attention is in the log summaries, or in the ruler tool which sometimes shows inconsistent results. You might not consider it a bug if you know how the rounding is done, but at first glance this doesn't look right to anyone.

That is why my proposal is to add this option in the gui, so that each user can choose from which value to apply the rounding.

In practice it would allow to keep the current behaviour if you want, and also to control when is shown with 2, 1, or no decimal digit.

I have reviewed the code and not many changes would be needed, just add in the units configuration gui a box where the user sets the desired value (the current one would be 20). And save that value in the configuration. let's call it roundLimit.

Then modify some lines to apply that value as an operator instead of fixed values.

At CUnitMetric.cpp:

A similar change ( a few lines lines) should be done at CUnitImperial.cpp, CUnitNautic.cpp, and CUnitAvitation.cpp

I think it would be a very flexible option that would make everybody happy, and it respects the current idea that depending on the distance more or less decimals are shown, but letting the user decide the point where the roundLimit is placed.

I would like to make a PR, but for now I don't know how to do the step of saving the roundLimit value for later use, and I have very limited konwledge on this.

[kiozen]

I can plan 2 roughly identical routes with 20km something and just by moving the intermediate points slightly I can make the one longer than the other and vice versa. And recording the very same route with a GPS will give me a third distance. Can you tell me which one is accurate if we have, let's say 20.4km 20.1km and 20.9km for those three 'lines'?

The example in the ruler is a bug. The sum has to be formed by the rounded components.

As usual I am not in favor of creating a configuration monster. Most users are already unable to do the minimum configuration required. Adding more does not help.

The internal parameters should have good values for the purpose. Each point you either acquire by a GPS or estimate from a map has several meters of uncertainty. Unless you really have access to maps precise in the sub-meter range. But in that case you do not want to use QMS anyways. The current limits are rough estimates from experience. Routes/tracks in the range 10-20km differ already by a kilometer. Therefore 20km is beyond good or evil.

[mitxel-m]

I agree fundamentally that adding more digits does not make our devices more accurate. But there are other aspects and needs that I would like to discuss in a constructive way:

.... Can you tell me which one is correct if we have, say, 20.4 km, 20.1 km and 20.9 km for those three "lines"?

The point is that I want to see these differences so I can decide for myself. Hiding the differences also hides the inaccuracy of our devices, and I prefer to know about it.

The example of the ruler is a mistake. The sum has to be made up of the rounded components.

But doing that could lead to bigger cumulative error on the Total for certain cases. I think it is better now. It is only necessary to remember that numbers are rounded above a certain value.

As always I am not in favour of creating a configuration monster. Most users are already incapable of doing the minimum configuration required. Adding more does not help.

I agree.

Internal parameters should have good values for the purpose. Every point you acquire with a GPS or estimate from a map has several metres of uncertainty. Unless you really have access to accurate maps in the sub-metre range. ....

There is no need to use maps in the sub-meter range. On a 1:50.000 paper map I can measure with a millimetre ruler with an accuracy of 50m (1mm=50m). Let's go to summit A, from I can see summits B and C. I can measure that AB= 21,60 Km and AC=22,45 Km. Even without a ruler, with the cord that holds the compass I can check that the distance AC is greater than AB, and also by taking a distance with the cord and porting it to the map grid I can measure those distances in a very acceptable way.

However, although the distances AB and AC differ by about 850 m, in QMS with the ruler I have to accept that both are shown equal as 22 km, and this is a bit frustrating for me.

The practice:

I would like to propose an alternative that gives more flexibility to the actual mode. This is to add a box in the units configuration that allows the user to set from which value the rounding of distances will be done for metric and imperial units.

This is how it looks

I have compiled and it is running fine for me, so I will do a PR.

Please give it a try. I think it wll be useful for a lot of users, and it will not interfere with the actual mode.

The basic points:

• For users who are already happy with the current behaviour everything remains the same by default.
• No configuration is necessary. Novice users don't have to do any extra work.
• It respects the current concept (which I like) that the larger the distance the less decimal digits are displayed.
• Interested users can specify from which value the rounding is done, so they can control for which distances will be shown 2, 1 or no decimal digits,according to their purposes of use.
• It applies to metric and imperial units. Aviation and Nautical miles remain unrounded.