Measure - Bearing Accuracy

[chughes-lincoln]

It looks like the logic for how Bearing is calculated has changed between 3.10 and the current beta (perhaps with https://github.com/geomoose/gm3/pull/799).

See screenshot of the demo using the 1km grid:

The bearings should be 45 degrees, not 54. I tested a similar grid on my site, and the bearings are correct on 3.10.

[theduckylittle]

Did a little digging in, this is a projection issue...

• The map is displaying 3857 (all these are EPSG code references...)
• GM3.10 stored measure distances as 3857 then reprojected to UTM for Measurement.
• GM3.11 stores distances as 4326. UTM is used for length but now 4326 instead of 3857 is being used for the bearing calculation. Arguably, that is the "true" bearing, but this is a difference in behavior between versions.

[elil]

I think bearing in UTM (or some other local grid) is appropriate. Same as distance. The "usual suspects" like 4326 and 3857 can all cause problems (unless the underlying library is already doing tricks to account for this- see also PostGIS geography, https://postgis.net/docs/manual-3.3/using_postgis_dbmanagement.html#PostGIS_Geography).

Selection of UTM zone (or some other local grid) being appropriate is mostly true for "local" work which I think most GeoMoose sites are aimed at. If making a site for worldwide great circle distances and bearings, then a different approach is probably needed (see again PostGIS geography data type and functions, https://postgis.net/docs/manual-3.3/using_postgis_dbmanagement.html#PostGIS_GeographyVSGeometry)

4326 "bearings" are mostly a function of latitude. See this correct example in Quito (on behalf of the 0 degrees latitude):

A 100 by 100 meter right triangle with 45 degree angles (within the limits of my hand drawing) matches what we expect from geometry.

Likewise a high latitude example being very incorrect:

Does OpenLayers do some underlying tricks for 3857 bearings? If so that could be considered, otherwise, UTM (or some other local grid) is appropriate for bearings on the "local" scale (city, county, state; breaks down by continent). For convenience, I'm ignoring the convergence angle since I think that starts to get to a level of complexity beyond most GeoMoose site configurations and uses).

[klassenjs]

It must not actually be doing the math in 4326 proper (spherical), but doing the math using 4326 coordinates but as a rectilinear coordinate system. Then the aspect ratio gets more squished the further from the equator.

But, either way, in the demo area, Grid North (UTM15), True North, and Magnetic North are all effectively the same (just luck of where the magnetic pole is and that the demo area is about central in the UTM zone).

https://mdd.sharedgeo.org/mdd-gen?date=2019.0&lat=44.55&lon=-93.15&zone=15&of=png&width=150&height=180&submit=Generate+MDD

So, I think there are two issues here:

1. Defining what we mean by North. My guess is True North is what we should be using. Using UTM grid north can be noticeably off from True North (2-3° at zone edges in CONUS), is somewhat arbitrary, (and doesn't even make sense over the poles eg. EPSG:3413). Magnetic north moves around all the time and requires updated model data so probably isn't something we want to deal with.
2. Applying rectilinear math on a spherical coordinate system

[elil]

Magnetic north- this is worse than spherical triangles, I agree, magnetic north isn't something we want to deal with.

Using UTM (or any other local grid) adopts grid north which typically matches true north near the central meridian (see also other types of projections). This means it matches in that area and then is off a systematic amount in other areas towards the edges (like @klassenjs says a convergence angle of 2-3 degrees plus and minus at each edge of the grid is to be expected). I think that this is fine and applying the convergence angle is up to the user if they want to (or they default to grid bearings). I think that we should adopt grid north as our north, complete with the limitations that come with this choice. This also appears to be our previous behavior.

Yes, it is true that the existing math is not showing geodetic bearings (that perhaps would have worked correctly) but rather some (inappropriate) rectilinear math with spherical coordinates. I don't think that we want to go full geodetic or wander into spherical triangles. Going full geodetic could be an option in the future (and increasingly so as proj advances). I think that this should be a separate future development (if we want to pursue it).

[klassenjs]

If we go with grid north, and we are dynamically picking a grid other than the displayed map projection, I think we need to at least state which grid we are using. (Although, this is really just another symptom of "everything is 3857" not being good enough.)

[elil]

Stating the grid could be useful. That level of detail may be more appropriate in the documentation rather than the UI. Hopefully configurable to include or not and subtle. You won't hear me cheering for 3857.

[elil]

Another approach of leaving the convergence angle to the user would be to have a user input field on the measure line tool like

Rotation: -2.4

and then we apply that to all the bearings results. That lets the user either use default local grid north or determine the convergence angle and apply it. This would add complexity to the tool (at least on the user side, it would leave a do nothing, accept zero -or some other configured default, and use the results path). If going this route, configuring a default rotation would be really helpful since in many cases the admin can "determine the convergence angle" and the user might not be able to readily do that.

[klassenjs]

If the user or admin is specifying the convergence angle, they will need to know from which grid the angle is measured. This implies that either the admin sets the grid, or if GeoMoose guesses, it tells the user/admin.

(And this is all ignoring areas near the poles where 3857 and UTM completely fall apart, but that isn't a new problem.)

[elil]

Good point. It would otherwise take a little bit to figure it out.

(that 3857 pole headache will be hanging around for another few decades.)

[theduckylittle]

Updated code piggy backs on the UTM code used for length calculation. We could bring in geographiclib but this latest change will fix the difference between 3.10/3.11 and also ensure the line math is all in a consistent projection.

[chughes-lincoln]

Fixed by https://github.com/geomoose/gm3/pull/837