Serious Bug in MongoDB Geospatial distance calculation

One of my favourite small details about PostGIS is the way that the documentation includes visual representations of what various query operators achieve. Here are some examples for ST_Buffer:

https://postgis.net/docs/ST_Buffer.html#idm15238

It looks like a bug specifically in the Go driver and has already been reported: GODRIVER-2429

I always use ublock origin but I disabled it to see what it looked like.

We. You weren't kidding. Every few lines was an ad. It was absolutely impossible to read.

I want to give the author the benefit of the doubt here. If he had actually seen what it looks like, I cannot believe he would keep it that way. He surely has ads turned off for himself to avoid being flagged as clicking on his own ads.

Running uBlockOrigin in default deny all javascript and I got to read the article with zero ads.

AdGuard on iOS eliminates that trash for me. (I wish I could do uBlock Origin!)

Yes, whatever it was advertising soon became something I hated. Do even advertisers think this is a good idea?

thanks for the ticket Matt.

Confirmed not a bug in MongoDB or the Go Driver.

Not OP: sounds like a good advice to me.

Virtually every geospatial format uses longitude latitude order. WKT, WKB, GeoJSON, KML, Shapefiles, FlatGeobuf, Geobuf, you name it. Your data in PostGIS? Longitude, Latitude. Google Earth? Same.

If you're storing data in a standardized format, odds are it's longitude, latitude. If your starting guess is the opposite, you will almost always be wrong.

Anyone with a basic math or science background is intimately familiar with (x, y) coordinate ordering on a cartesian plane, where the horizontal component comes before the vertical. From that perspective (Long, Lat) is the only obvious ordering; and geospatial software has used it by convention for decades. There are thousands of different projections and spatial reference systems and they all use X, Y ordering. Why would you create a special case just for one?

Now you could make the case that Longitude and Latitude are NOT cartesian coordinates and thus not beholden to the x,y convention. Fair point, but we still encode it as a pair of coordinates as if it were a 2D reference system (technically the Platte Carre projection) like any other. Switching the coordinate order feels like a strange hill to die on - again, why a special case?

In any case, it's wildly inaccurate to place the blame on GeoJSON which was just following the widely held, and mathematically consistent, convention.

GeoJSON made the correct decision because it conforms with ISO 19125, just like every other data format for the last couple decades. Same reason PostGIS is in Lon/Lat order. Virtually all geospatial data that exists is formatted this way. If you are not sufficiently familiar with geospatial data to know this, then you probably shouldn't be assuming the order.

It behooves the new user to learn the industry standards and conventions instead of inventing their own.

It's exactly what people with GIS experience expects. It's X, Y ordering. See also: WKT. The problem is GeoJSON is often used by folks with no other geospatial experience and lat, lon is colloquially the more common ordering.

But that's all about casual use. If someone's job is to write geospatial code for a database driver, it's a bare minimum to expect they'd pay attention to making this work right. Also to have a test suite to verify it's working right.

(When I write code I always put in a little check on inputs to display a very clear error message if it sees a "latitude" outside the range [-90, 90]. Won't catch all bad data but sure can help.)

The world is used to x,y for coordinates which sets the convention.

I am trying to understand the rationale behind this. Is there some industry or region where Long, Lat is the customary way of representing a location? I have never seen that before.