Differentiation after conversion to Radians?

[SethArchambault]

I see that a bunch of articles online that seem to prefer getting the difference between degrees and then converting to radians.

Looks like the function int his repo gets the the difference of lng and lat after converting to radians. This produces slightly different results.

  const aLng = toRad(a.lng)
  const bLng = toRad(b.lng)
  console.log('h1 diff', bLng - aLng)

  const lngDeltaR = toRad(p2.lng - p1.lng)
  console.log('h2 diff', lngDeltaR)

Was this intentional here? I have zero background in this kind of math, but was noticing the difference when using your formula instead of another, so interested to hear your position on this!

Thanks!

Sources: https://community.esri.com/t5/coordinate-reference-systems-blog/distance-on-a-sphere-the-haversine-formula/ba-p/902128 http://www.movable-type.co.uk/scripts/latlong.html?from=%2048.9642200,-122.0368100&to=48.965496,-122.072989

Ah I also see an old commit where it used to be done other way: https://github.com/dcousens/haversine-distance/blob/v1.0.0/index.js

Then it was changed to the way it is currently here: https://github.com/dcousens/haversine-distance/commit/e34e79350720edfb86f0f6fd3f0bc982c1f17f0d

(Also switching from atan2, to asin in that commit)

[dcousens]

@SethArchambault interesting question!

The changes in https://github.com/dcousens/haversine-distance/commit/e34e79350720edfb86f0f6fd3f0bc982c1f17f0d were from a small exercise I made for myself in understanding the underlying math and rewriting the implementation from scratch in a way that reduced the total number of toRad function calls.

I am interested in what different results you received, as at most we should be talking about something less than epsilon error (0.0001 in this instance).

[SethArchambault]

I was looking at the distance between two points that were less than 2 miles from each other, and yes the difference was very very small. Maybe some 6-8 decimals points down.. Not sure if this difference becomes more noticeable using this formula over larger distances though.. I may do some tests..

[SethArchambault]

K looks like its at the 8 decimal point mark and doesn't get worse than that with very large distances in my tests, where A is the method I currently use, and B is this repo's (main difference is the order of getting the difference, but also A uses arctan2 instead of asin):

A 65.41646141709302 B 65.41646141763209

A 7192.576993332597 B 7192.576993334185

A 3467303.9170632474 B 3467303.9170632497

A 8540719.046316031 B 8540719.046316028

[dcousens]

@SethArchambault rather than debating implementations, do we have any reference vectors we can lean towards? I'm thinking with accuracy down to 12+ decimal places.

I haven't the time to verify the math at this moment, but if there is a reference vector I can adjust towards maybe any changes will be easier to justify.