Update the mean earth radius number

[sakisdog]

Based on http://en.wikipedia.org/wiki/Earth_radius and some Google Maps distance calculations i think this change produces more accurate results.

[mikalhart]

I see @ress997 comment that the suggest new value is accepted by the Japan Meteorological Agency. Are there any other thoughts out there? Has anyone encountered problems with the old value? I'd love just a bit more evidence that a change is for the better and won't hurt anyone.

[sakisdog]

I don't think that there is a problem between small distances with the old value. But in calculation between long distances there is a big difference. I created a small example between 2 places (London and Edinburgh). Using Google Maps measure tool i found that the result of 6371009 value is the same as Google's. Also based on this International Union of Geodesy and Geophysics (IUGG) and International Earth Rotation and Reference Systems Service (IERS) use 6371008.7714 (6371009 with rounding) as mean eath radius.

[robertlipe]

I won't put this in a PR and I won't sell you on the code, but I've had an open-source project with a many hundreds of million users (it's used in some very popular programs) for almost twenty five years that has served some demanding (some scientifically intense and some just cranky) users and we've put more than a little effort into this topic. If you want to crib the code, it's GPL. We'd appreciate credit, of course but it's not like anyone can copyright math. (yet) Lots of really big nerds have studied this topic for a very long time and I'm happy to share our findings.

Great Circle distance: https://github.com/GPSBabel/gpsbabel/blob/master/grtcirc.cc

As an example of the kind of fields we serve, we updated our collection of Datums from authoritative Geodesic sources specfically for Great Britan '36 (yes, as in 1936) just a few days ago. The tables for Datums are in https://github.com/GPSBabel/gpsbabel/blob/master/jeeps/gpsdatum.h (and .cc) and the actual math to convert to and from anything is at https://github.com/GPSBabel/gpsbabel/blob/master/jeeps/gpsmath.cc (and .h)

We have some related code in src/core/nvector that lets us compute such things with disregard about crossing hemisphere borders and at the poles. We dont' use nvectors everywhere we could.

We recently found a case that had one too many digits that had been wrong since we imported the code from Jeeps back in 2002 or something. It could have resulted in very specific combinations being off many meters. No body had noticed. Big numeric constants are big and after a while, they look the same.

I won't take sides on this PR, but if you're looking for good numbers that usually won't be shouted down that work well for most data for most of the planet in the electronic age and is what will be used by most of the consumer-grade GPS receivers you're likely to see, "Do What WGS-84 does" is generally good advice. For that reason, we use an earth radius of 6378137.0 every place we don't have to split finer hairs.

The volumetric average (the 1008 number you chose) tends to overstate the value of the data at the poles, but if that works for you, I certainly won't start the "change my mind" meme here in your house. :-) We find the majority of the data out there is in WGS84, so that's what we go with and why.

Anyway, there may be some useful code in there (or up in the NMEA parsers or in some other places) that's useful to you. Borrow respectfully. Or ignore my intrusion completely.

Carry on!

P.S. "Google" uses different values for different tasks. Google is a big place with lots of projects. Notably, Earth uses oblate spherical Perspective "projection" (not really a projection) math with EPSG 3857 though it actually recalculates it every time the camera stops moving and Maps uses Mercator with EPSG 4326, IIRC. This may have changed since I last had the view inside this sausage factory. The "right" value depends deeply on what you're doing with it, how much you care about continents moving around, how much you care about surface of the earth dynamically popping and syncing, using old map data you can't control, etc. If you're a hiker and want to make it back to base camp, you can't blame continental motion for being late, but tools like Earth Engine and ArcGIS will let you control all this stuff in ridiculous detail.

After I've spent a few days listening to real carto nerds intensely yammering on about this stuff, it's enough to make me wish the Flat Earthers were right and we could just use pythagorean everywhere. :-)

P.S. Whatever you do, I prepare backing it with some spreadsheets to let you easily compare decisions and some unit tests and runtime and static asserts to be sure that things like not accidentally internally converting some intermediate computation in 32-bit integer space where you may overflow or something. I get the impression your code is often use en embedded land where floating point (floats vs. doubles) may be emulated in software so there are temptations to try to shove things into integer space where people on 64-bit desktops may not even think about it.