I'll try and explain in a bit more detail then, to demonstrate why you think there might be inaccuracies.
There are 4 positions we are talking about here:
- XYZ(1) = Player position (this is at the players origin point, which is their feet).
- XYZ(2) = Camera position (this is at the players eyes, in their head).
- XYZ(3) = Marker position
- XYZ(4) = GLTD look at position.
GLTD is the most accurate way of determining position. It calculates the distance between XYZ(2) and XYZ(4) in 3D space. The resulting value is the exact distance between where your view point is, and what you're looking at. Lets assume that the resulting value of this calculation is 224.999999354131. Because having floating point numbers on the HUD looks bad and is unnecessary, the resulting value is truncated down to 224. This is the value you're seeing in the pictures above.
On the other hand, the range value shown on the map view is calculated completely differently. For starters, it uses different start and end positions - XYZ(1) and XYZ(3). Secondly, it also only calculates in 2D space, the Y value (height) is ignored. You will notice this inaccuracy if there was large elevation differences between the player position and the marker position (in the pictures above, there is very little). This is intentional, because of mortars (they have a separate parameter for elevation, which when used correctly, will solve this issue).
So, the range value is now the distance between XZ(1) and XZ(3). Lets say that this resulting value is 225.0000000654132. This is rounded to the nearest 50, which is of course 250, and is the value you're seeing in the pictures above.
Also, to re-iterate my previous post, the range value on the map view is rounded to the nearest 50. So when it says 250, the real range is between [225-275) (between 225.0000000000 and 274.9999999999). It is not a different calculation that some are assuming, it is not rounded down like 299 = 250, or rounded up like 201 = 250. It's the nearest 50.
Does this make sense now? There may be perceived inaccuracies, but really, it's completely separate calculations using completely separate positional values. I hope that helps.