Fairly obvious indeed: Lat/long are not coordinates on a plane, but on a sphere. In short, the closer you get to the poles, the shorter the distance between two points on the same... I want to say longitude.
... and besides, what are the units in? If lat/long are in degrees, then ... never mind.
We had an interesting case of a complete inability to undertstand the problem domain here once, where we had to implement a currency converter. The specific exchange rate you were to use depended on whether you were buying or selling the currency. But the clown implementing it thought that the conversion factor (from e.g. Euros to Dollars) to sell e.g. the Euros was the reciprocal of the conversion factor (from the same e.g. Euros to Dollars) to buy the Euros. Looked at me completely blankly when I questioned him, and asked him why he had not sought out the specification before starting the job.
Back when I did web-dev, I had to implement the redesign of some pages which could calculate the distance from the visitor's location (if permitted) to a branch location specified by latitude and longitude. Luckily for me, I was supposed to re-implement the existing functionality on the shiny new design, not implement properly working functionality.
I never actually thought about whether we were doing this or not. Turns out we are doing it properly though since anyone who actually wants to get there is going to be starting from within the UK and almost certainly within a few miles, the difference is probably not very significant. Especially not compared to the difference between our as-the-crow-flies calculation and the actual distance by road which the potential customer will care about.
Wow. As others have mentioned, the real WTF is not using some form of ellipsoid-based algorithm. Flat-earth Pythag equations are going to be very wrong in many circumstances. Haversine is a fine approximation of reality for things not needing a huge degree of accuracy. If this app is simply telling users how far they are from a weather station, haversine will be good enough (you'll be within tens of meters of reality in most cases). If you need more accuracy - there are (ever) more complex algorithms that take into account the true(r) non-spheroidal nature of the earth.
@ray10k You might want to say longitude, but if you do, you'll be wrong.
Two points five degrees (of latitude) apart on the same longitude (e.g. 3°03′30″E) will be (subject to questions of the Earth being not-really-a-true-ellipsoid) be the same distance apart. You should say "same latitude", since lines of latitude have the same number of degrees of longitude on them, but progressively fewer miles as you go north.
@CarrieVS In the UK, the error of magnitude of the east/west component by using Pythag instead of Haversine (etc.) is in excess of 40%. (That is, the calculated distance is more than 40% bigger than the true distance, in the strictly east/west direction.)
Addendum 2016-12-06 08:17:
That is, the points on the same longitude - separated by 5 degrees of latitude - will be the same distance apart no matter where they are.
That's bigger than I had guessed, but our distances were very often shorter than the road distance by at least that proportion. In fact an over-estimate of 40% would probably have improved the accuracy at least as often as not.
Dunning-Kruger effect, I think. Who-ever wrote the Pythagoras solution wasn't merely ignorant of how to calculate distances on a round Earth, they were ignorant of their own ignorance. Maybe the lesson to take is that you should always learn more about the problem domain, even if you think you know it.
@Steve_The_Cynic and @CarrieVS , if your co-ordinates are latitude and longitude then indeed naively calculating the Pythagorean distance between them will be a big overestimate. If however they are British National Grid co-ordinates then the Pythagorean distance will be pretty accurate. Provided the input co-ordinates are accurate - taking a GPS latitude and longitude and naively converting that to national grid will be in error of tens of metres because GPS and national grid use different shapes for the Earth implying different lat-long co-ordinates for the same point.
As someone who works with GPS and similar things every day, I can tell you that if you hear the term "Geoid Undulation" while at work, you are about to have a very bad day.
However, I don't really view this as a true WTF. The programmer thought he saw the problem, and just didn't know a lot about... the earth, or physics, or cartography, or geometry...
Honestly, I could see a LOT of people making that same mistake, and in fact I am pretty sure that people around my work have in the past. We all spent so much of our childhoods working in nice flat coordinate systems that it is really annoying to realize that the universe so often doesn't work that way.
Computing accurate distances on an ellipsoid's surface is quite hard:
A few years ago I tried to convert lan/lat-coordinates to x/y/z-cartesian ones and back. I was unable to find a non-iterative solution. Anyway, the geometric approximation converged quickly and seemed to be stable.
The main problem is, that lan/lat-values denote the surface's normal angle, rather than an angle measured from some cutting plane.
Depending on what accuracy you have to achieve, the haversine formula is definitively out of discussion.
This one should yield better results: https://en.wikipedia.org/wiki/Vincenty%27s_formulae
Nevertheless: the code shown in the article just hurts the area in my brain that has to handle basic math.
That's true, this would definitely be easy to catch in testing, if you have a strong test suite of any kind. And this would likely be caught by any other engineer who looked at it. However, if no one was looking closely, and no one was was testing cases that were terribly close to the poles (most likely everyone was in North America anyway)
I will accept that TRWTF is that no one looked at the code closely enough to catch this before it got into production, or that someone trusted this person enough to have them implement a core/important part of a system without them knowing at all what they were doing.
Finish of the first paragraph:
(most likely everyone was in NA anyway) then it likely would produce results at least somewhat close to the actual results. As long as you stay within one continent (that isn't Asia) you aren't going to get results more than a couple of miles off, and if you're just considering distance to the nearest NWS system, a couple of miles most likely doesn't make a huge difference.
How 'bout it's wrong because it's just that: wrong. I know nothing about properly calculating that distance, but the featured formula is showing details about only one end of the 2-point line, which just can't be enough to calculate that distance. The result of that formula probably doesn't have any meaning whatsoever.
That formula works if all the values are local, but if you're looking world wide, there are MANY problems. The biggest I can see is that lat/long values can be negative, but this treats them all as positive so points on opposite sides of the planet would be calculated as right next to each other.
Put this in the same category as time calculations. It ain't easy! Things get even more complex when you want to calculate intersecting lines on the surface of the earth. Two "straight" lines can even intersect TWICE if you have them in the right place. A program I worked on (Airplane navigation) needed to know if something intersected or not. My first test was using simple squares based on Lon & Lat. I figured if this intersected (the common case was that it didn't) I would take the high road and calculate the true place using all sorts of spherical and the like coordinates. If not, then skip it. I made the assumption that the lines didn't intersect twice which for the most part was OK in the cases I was getting around to.
The bigger problems happen when you go from geocentric coordinates (measuring from the center of the earth) to/from geodesic coordinates (down "points" to the center of the earth, and oblate spheroid things). Gets plenty confusing when you go from one place to another and things change. Ain't GPS wonderful??!!!
Even a bunch of CERN physicists got this wrong. Remember the excited atatements about neutrinos travelling faster than light? Quickly retracted after a high school student pointed out neutrinos tend to iust dig through earth instead of taking the surface roads... :-)
Note - Don't say "North America" when you mean "USA". Assuming the lower 48 is flat versus on a spheroid surface may not give you must deviation, but when you head north it really matters. Because in Canada it varies pretty significantly. Maybe not much when you're just going along the 49th parallel, but once you headed north a few hundred kilometers the error becomes big (and well, given the territory extends to the North Pole...).
Um, this isn't even remotely correct, degrees do not convert to miles that way, and you are on a sphere, not a plane. A degree of latitude is a constant number of miles, but a degree of longitude is 25,000/360 only at the equator. You have to use a bit fancier formula to do real distances on a sphere and convert degrees to distance..
@Smartass The calculation uses latitude difference (latdiff) and longitude difference (londiff). So both endpoints are used.
@Herby On a sphere, two "straight lines" always intersect twice (if you continue them long enough). That's because the analog of a straight line (shortest path) on a sphere is a great circle (circle with the same center and radius as the sphere), and any two of those intersect at antipodal points.
I worked with some severely WTFy software (it's worth a post in its own right, when I can repress the memories enough) that was written by a software company in Canada, and made a lot of assumptions based on those southerly latitudes. Anywhere in the UK, everything was really weirdly squashed. In Scotland the distortion was so severe that maps were drawn trapezoidally, and looked like sat nav "head up" maps.
The international date line doesn't strictly follow the 180° meridian. There are detours in the Bering strait (so the line goes between Siberia and Alaska), eastward around the Kiribati (to avoid the IDL crossing the country) and eastward around some islands belonging to New Zealand (same reason). The problem with wrapping would occur across the meridian, regardless of where the IDL is (fortunately, there isn't much land around it). Also, if londiff is more than 180°, it should be replaced by 360° - londiff to avoid going the long way around.
At the wholesale level, the forward and reverse conversion rates are so close that, for many purposes, clients can and do use the reciprocal of the "buy" rate as the "sell" rate, or the reciprocal of the "sell" rate as the "buy" rate, or the "mid" rate as either the buy or sell rate.
I supplied treasury software for several years, and although our software supported buy, sell and mid rates, virtually all of our clients used only one rate.
(All clients always use the reciprocal of the transaction rate for some reports and projections, but that's a different requirement)
(most likely everyone was in North America anyway)
Non-sequitur. Some parts of North America are as far north as the UK, which was already mentioned as having 40% difference from a flat-Earther's calculation. Some parts of North America are even farther north, making the programmer a suitable target for a poleish joke.
For the UK or any similar-sized country, you can get results within one part in a thousand by converting from lat/long to Universal Transverse Mercator (or the Ordnance Survey GB projection for the UK), obtaining results in projected metres, then using Pythagoras on that. It's effectively the equivalent of measuring with a ruler on a topographic map.
When working for a defense contractor in the US I once had this argument with my boss for several days. She was insistent that her formula was right. I never could quite convince her, but she did finally give in and let me use my own formula in calculating the distance. What's worse, we were testing the validity of a missile defense system and this formula was being used to test the size and shape of the 'error ellipse' (ie, area in which there was a xx% chance of the missile hitting). They'd been using the Euclidean formula for testing for over 3 years. :(