Round vs Truncate when converting UTM -> MGRS

[jbree]

TL;DR - I think mgrs is rounding a value that should be truncated.

I was testing some sample data against other LL -> MGRS converters online and noticed they are behaving differently at the 5th digit of precision.

An example of this is 36.2361322, -115.0820944.

The converter at earthpoint.us gives MGRS 11SPA 72349 11844, but your forward function gives 11SPA 72349 11845 (spaces added for clarity). The UTM is listed as "11S 672349.27mE 4011844.97mN".

It appears that your tool is rounding the UTM values before converting to MGRS, whereas I believe it should be truncating/flooring. My understanding of this is definitely that of a layperson, so please correct me if I'm wrong.

The section "Truncate, don't round" of the Wikipedia MGRS article has more information about this.

[calvinmetcalf]

this is one of those places it would help to get a second opinion as we don't necessarily know if earthpoint.us is doing it correctly

[jbree]

I'm not sure if there's an accepted, authoritative source of test inputs and outputs, or a converter that is "blessed" by some authority for being accurate.

Here are a few examples of other converters which show behavior that differs from your mgrs output in the way I have described:

• http://geographiclib.sourceforge.net/cgi-bin/GeoConvert

• http://legallandconverter.com/p50.html

• http://www.movable-type.co.uk/scripts/latlong-utm-mgrs.html

[calvinmetcalf]

yeah I know there isn't any canonical authority hence I just try to do a 'vote' of different libraries

[jbree]

Yeah, for sure. Whether you change it or not, thanks for your consideration and speedy response.

[noberasco]

According to this: https://en.wikipedia.org/wiki/Military_Grid_Reference_System the values should be truncated, not rounded. The rationale behind this is

When changing precision levels, it is important to truncate rather than round the easting and northing values to ensure the more precise polygon will remain within the boundaries of the less precise polygon.

[mrmattson]

Having worked with MGRS a lot, truncation is the correct answer. The reference from Wikipedia by @noberasco gives a clear explanation on why to truncate. Since it's Wikipedia, @calvinmetcalf is right to want a source for the decision. Since MGRS is a DoD coordinate system and the NGA is the DoD's geospatial authority, the NGA is the authority on MGRS. A Google search of mgrs truncate site:nga.mil will pull up articles mentioning truncation, but nothing that clearly settles the issue. However, if we look at the source code for GEOTRANS, we will see how the NGA implements their MGRS manipulations.

GEOTRANS is the NGA's "DoD coordinate conversion and datum transformation software." In the makeMGRSString() function of GEOTRANS 3.7 (the latest version published), we get the answer on lines 332 and 337. We can see where a value called precision is used to create a value called divisor. Divisor is then used to move the decimal point left the needed amount. Finally, the result is truncated by casting it from a double float to a long integer.

Thank you for all your great work on this library!

[DanielJDufour]

Hi, all. A new maintainer here. Thanks for the informative discussion :-) I'll add truncation to my list of tasks. Also open to pull requests :-)

[DanielJDufour]

Hi, all. It appears that NGA changed things with their new release of GEOTRANS, version 3.8. Basically, they are now using the center of the box instead of the bottom left when calculating the lat/long. Please see this PR, which provides more context https://github.com/proj4js/mgrs/pull/60 and here's a link to NGA: https://earth-info.nga.mil/GandG/update/index.php?action=home.

Also, if you find it useful, here's a link to a docker repo that includes a re-run of the Spreadsheet Tests for GEOTRANS: https://hub.docker.com/repository/docker/geodesy/geotrans.

Happy to discuss further. Please comment or open a new issue if there's more to discuss on this topic. Thanks again.