Using Haversine to calculate distance and bearing
A Google search to find a formula to calculate the distance between two (lat, lon) points turned up this excellent writeup. May be useful for guessing which GPS position records from my camera are worth using to create GPS tracks…
Brian Lane July 13, 2013 20:12
If they’re really close together you can fake it and ignore the curvature. Now I’m having flashbacks to the lat/long code I wrote on a TI DSP. Luckily I don’t remember the details, but I think it involved lookup tables.
Michael K Johnson July 13, 2013 20:19
My first quick hack while exploring the data was the cartesian distance but I’m looking at points north of the Arctic circle so it starts to matter… :-)
H. Peter Anvin July 13, 2013 21:08
That is assuming a spherical Earth?
Michael K Johnson July 13, 2013 21:16
Relative to the GPS error in this non-WAAS device, the errors from assuming a spherical earth are lost in the noise, especially with respect to calculating a distance that I will use as a heuristic.
That said, see http://www.movable-type.co.uk/scripts/latlong-vincenty.html if you want to be very accurate with regard to a theoretical ellipsoid, which obviously is not a perfect description of the earth’s surface either.
Arjan van de Ven July 13, 2013 21:17
there’s also a formula correcting for that.
but for the purpose of calculating Mph and then thresholding that … it really doesn’t matter.
H. Peter Anvin July 14, 2013 01:17
On distance scales of less than ~1000 km I doubt it matters.
Curtis Olson July 15, 2013 12:35
I think for very small areas of few 100 meters, you can do some simple angle/distance math using an approximate cartesian space. Just remember that horizontal distance needs to be scaled by cos(lat). 1 degree of latitude = 60 nautical miles. 1 degree of longitude = 60 nm * cos(lat_radians).
If you google the “aviation formulary” web site, they have a ton of good stuff, including pseudocode for spherical world formulas. Given a location and a distance and heading, what is the new location. Or the inverse: given two locations, what is the distance/heading between them.
If you want to get really crazy, FlightGear has an implementation of wgs84 oblate ellipsoid math to do this same thing. It’s in C, but should be portable to javascript with a bit of grunt work. Over a distance of 10’s or 100’s of miles, you can see differences of tenths of a degree heading and many meters between the spherical vs. wgs84 formulations. For some applications, those errors are negligible, but if you are steering a 747 from Los Angeles to London and are trying to optimize your fuel usage (or trying to point a directional antenna, etc.) those differences might be important.
Michael K Johnson July 15, 2013 13:22
Thanks for the pointer to the aviation formulary. I’m actually working in Python, so the source language doesn’t matter much. Spherical earth is good enough for my purposes right now and avoids iterative numerical methods. I have data points hundreds of kilometers apart north of the arctic circle.
Time for the “Round Earth Society” that denies the oblate elipsoid shape and goes on expeditions to prove that the earth is really spherical? ;-)
Curtis Olson July 15, 2013 13:52
The flat earth model still works well for many purposes. It’s a simplification of course. But even the wgs84 model is a simplification and actual elevations (or distances to the center of the earth) can be off by 10’s of meters with the wgs84 model. But wgs84 projection is what real world gps’s use so if youi want the best correlation between a gps and your own code, that’s a good way to go. But gps’s can be off by 10’s of meters too so the ultimate quest for truth is a quest for an absolute reference and perfectly correct sensors. The reality is that our best case scenario is to try to show that everything lines up and is in self agreement. Truth is highly elusive (out side of politics where everyone knows the answer to every question!)
Imported from Google+ — content and formatting may not be reliable