[Patch] "Measurement window" shows wrong area, somewhat inaccurate length

[AM909]

1. Open the "measurement window" (Alt-M by default). Draw a way. Note the length shown in the status bar before double-clicking to end the way. The distance shown in the "Measured values" dialog will be slightly different. I've been careful not to move the mouse when ending the way.

2. The Angle field in the "Measured values" window always shows 0, no matter what I do. How is this supposed to work? It would definitely be a useful feature when trying to draw from public records of survey, etc.

[law_ence.dev@…]

I also am baffled by the present behaviour of the Measurement plugin. I remember it being very
useful in the past, although lacking in documentation.

I was wondering about taking compass bearings along streets where the gps signal is noisy & inaccurate. For that I need to know something about the relation with magnetic north and the
coordinate systems. I assume that a line of fixed lat is aligned with "geographic" north in some sense.

But while the plugin is apparently non functional, I can't explore any of that.

[anonymous]

1: measurment plugin uses a slightly different type of calculations. There may be differences. Also note that measurement display complete way length, where core displays only last segment.

2: Angle field shows direction angle between two points. I changed it now, so that it also shows direction of last way segment.

In [o21307].

[AM909]

The angle change is appreciated, and works as expected in r3329.

I believe the incorrect distances to be an issue (though minor), so I am re-opening the ticket. Perhaps I will tackle it as my first attempt to contribute.

Summary: For the case of points in the Mid-North-Atlantic, the distance shown on the status bar while drawing is short by about 0.2%, and that shown in the measurement dialog is short by about 0.36%.

For a short distance test case (~ 1km), the bearings shown in both places are accurate.

For a long distance test case (~1000km), the measurement dialog bearings remain correct, but the angles shown on the status bar are southerly by about 7% of a quadrant (~6 degrees).

Details:

Shorter distance case:

The attached file (3.osm) contains the two points:
A: 53.40878, -44.23407 (53.40878035066326 , -44.234072673356200)
B: 53.41160, -44.22063 (53.41159994226244 , -44.220633935207296)

and a way connecting them. The first set of coords (5 decimal places) is that shown in JOSM and the second set (14 decimal places) is what is in the .OSM files.

When I drew the way, the status bar said the length was 945.4m and the angle was 70.6 degrees. According to the following 2 calculators*, which agree within the 4 decimal places (7 digits of precision) available from NGS, the status bar reads short by 0.19%.

The forward angle on the status bar is accurate to within its one decimal of precision. Drawing in reverse from B to A, the status bar angle was 250.6 degrees - also accurate.

The measurement dialog says it is 943.71m @ 70.6 degrees. If you reverse the way, it shows -109.4 (250.6) degrees. According to the following 2 calculators*, which agree within the 4 decimal places (7 digits of precision) available from NGS, the measurement dialog reads short by 0.36%. While not huge, this is not insignificant, either.

The bearings in the measurement dialog are accurate within its one decimal place of precision.

Using only 5 decimal places on input yields a distance of ~947.25m, with slightly greater errors.

*Calculators:

Using 14 decimals,
Output from ​http://www.ngs.noaa.gov/cgi-bin/Inv_Fwd/inverse2.prl is:

Ellipsoid : GRS80 / WGS84 (NAD83)
Equatorial axis, a = 6378137.0000
Polar axis, b = 6356752.3141
Inverse flattening, 1/f = 298.25722210088

First Station : A

LAT = 53 24 31.60926 North
LON = 44 14 2.66162 West

Second Station : B

LAT = 53 24 41.75979 North
LON = 44 13 14.28217 West

Forward azimuth FAZ = 70 38 46.6181 From North (equals 70.6462828 degrees)
Back azimuth BAZ = 250 39 25.4631 From North (equals 250.6570731 degrees)
Ellipsoidal distance S = 947.1592 m

---

Using 14 decimals,
Output from ​http://geographiclib.sourceforge.net/cgi-bin/Geod?type=i&input=53.40878035066326+-44.234072673356200+53.41159994226244+-44.220633935207296&format=g&azi2=f&prec=9&option=Submit is:

lat1 lon1 faz1 = 53.40878035066326 -44.23407267335620 70.64628279764801
lat2 lon2 faz2 = 53.41159994226244 -44.22063393520730 70.65707307636650
s12 (m) = 947.159211363

---

Using 5 decimals,
Output from ​http://www.ngs.noaa.gov/cgi-bin/Inv_Fwd/inverse2.prl is:

First Station : A

LAT = 53 24 31.60800 North
LON = 44 14 2.65200 West

Second Station : B

LAT = 53 24 41.76000 North
LON = 44 13 14.26800 West

Forward azimuth FAZ = 70 38 43.3318 From North (equals 70.6453699 degrees)
Back azimuth BAZ = 250 39 22.1805 From North (equals 250.6561613 degrees)
Ellipsoidal distance S = 947.2534 m

---

Using 5 decimals,
Output from ​http://geographiclib.sourceforge.net/cgi-bin/Geod?type=i&input=53.40878+-44.23407+53.41160+-44.22063&format=g&azi2=f&prec=9&option=Submit is:

lat1 lon1 faz1 = 53.40878000000000 -44.23407000000000 70.64536994650915
lat2 lon2 faz2 = 53.41160000000000 -44.22063000000000 70.65616123837705
s12 (m) = 947.253446171

Longer distance case:

The attached file (4.osm) contains the two points:
A: 53.41255, -44.27505 (53.412548607143364 , -44.275050912749240)
B: 53.63361, -29.29145 (56.633608669901130 , -29.291452471136267)

and a way connecting them. The first set of coords (5 decimal places) is that shown in JOSM and the second set (15 decimal places) is what is in the .OSM files.

When I drew the way, the status bar said the length was 1018.6km and the angle was 69.4 degrees. When drawing in the reverse direction, the angle is 249.4 degrees. According to the following 2 calculators, which agree within the 4 decimal places (7 digits of precision) available from NGS, the status bar reads short by 0.20%.

The forward angle on the status bar is too high (southerly) by 6.6% of a quadrant. The reverse angle is too low (southerly) by 7.0% of a quadrant.

The measurement dialog says it is 1016843.11m @ 63.4 degrees. If you reverse the way, it shows -104.3 (255.7) degrees. According to the following 2 calculators, which agree within the 4 decimal places (7 digits of precision) available from NGS, the measurement dialog reads short by 0.37%. While not huge, this is not insignificant, either.

The bearings in the measurement dialog are accurate within its one decimal place of precision.

Calculators:

Using 15 decimals,
Output from ​http://www.ngs.noaa.gov/cgi-bin/Inv_Fwd/inverse2.prl is:

First Station : A

LAT = 53 24 45.17499 North
LON = 44 16 30.18329 West

Second Station : B

LAT = 56 38 0.99121 North
LON = 29 17 29.22890 West

Forward azimuth FAZ = 63 26 32.6216 From North (equals 63.4423949 degrees)
Back azimuth BAZ = 255 44 51.2649 From North (equals 255.7475936 degrees)
Ellipsoidal distance S = 1020637.8807 m

---

Using 15 decimals,
Output from ​http://geographiclib.sourceforge.net/cgi-bin/Geod?type=i&input=53.412548607143364+-44.275050912749240+56.633608669901130+-29.291452471136267&format=g&azi2=f&prec=9&option=Submit is:

lat1 lon1 faz1 = 53.41254860714336 -44.27505091274924 63.44239488008289
lat2 lon2 faz2 = 56.63360866990113 -29.29145247113627 75.74757356943519
s12 (m) = 1020637.880719388

[bastiK]

Interesting analysis. Considering that JOSM does not offer a way to get the exact distance for a segment (no snap to node for measurement plugin), isn't it quite accurate?

I guess the ellipsoid model isn't perfect either, you can always go one step further.

Anyway, for measurement plugin we should have the ambition to use the standard formula in geo science (whatever that would be).

[AM909]

Tested in r3329:

Another related issue is that the Selection Area is very wrong, becoming worse at higher latitudes.

At around 34 deg latitude, if you draw a square, closed way that is 40m on a side, it shows an area of ~1162sq m, not the correct 1600sq m (28% short).

If you copy and then paste that way at about 70 deg latitude, the sides become 16.5m in length (according to Selection Length / 4), and the area shown is 150sq m, not the correct ~273sq m (45% short).

If you copy and then paste that way at about 0 deg latitude, the sides become 48.3m in length (according to Selection Length / 4), and the area shown is correctly ~2330sq m.

I'm changing the priority back to major. This is an important tool when comparing against land records.

[bastiK]

Strange...

Paste & Copy is in projected coordinates, so I guess the growing in size when pasting to the equator is expected.

Btw., what about the patches you promised? ;)

[AM909]

To be clear - the cut/paste changing size is less serious an issue, though I guess it could be considered wrong too. The major issue is the mis-calc of the area, given the lengths of the sides.

[Preferred]

The accuracy of the area calculation seemed to be a major problem for the measurement plugin so I took a stab at improving it. I have been testing this change locally and while it will not be 100% accurate because of shape of the earth, I have found that it is very close to other online tools that do area calculations using lat and lon without adding complexity to the calculation. This problem seems to be the same issue as #7340 and is also part of issue #6872.

[Don-vip]

Ticket #7340 has been marked as a duplicate of this ticket.

[Don-vip]

Thanks for the patch !
Fixed in [o29578].