In fairness, assuming the earth is a sphere is rarely a problem. A typical “closest to me” algo is will have a ton more UX error due to differences between travel time and as the crow flies travel time. Frankly I agree with the article in the sense I have implemented decent solutions with MySQL just using a bit of math to filter to a reasonable lat,long span and then ordering with the haversine formula.

You don’t need PostGis to find the nearest McDonald’s closest to an IP address of every visitor. A degree of lat is 69 miles, and a degree of long is easy to calculate based on the lat, but you may need an extra case if you want to be correct for the tiny number of people that live near the antimeredian line.

I wonder if people run toward PostGis just because they don’t know to google haversine or the spherical law of cosines.

That being said, I have often come up with decent hacks that solve a customer problems but biting the bullet and adopting Postgres may have been ultimately better. I wish PostGis was a skill I have, but in a pinch the law of cosines is quite passable.

The thing is, it starts with find me the closest point. And then, in the next meeting, management wants to know which are in a specific area. And this case is about points contains by a polygon.

I'll gleefully counter-argue some run toward PostGis just because they don't like NIH syndrome ^^

> I wonder if people run toward PostGis just because they don’t know to google haversine or the spherical law of cosines.

Even if they do know how, it looks like running PostGis is an easier way to achieve the desired outcome.

...if there was only one common datetime library, and it pulled in 800 MB of dependencies. In that case, I might default to using unix timestamps, too, despite the edge cases.