Serious Bug in MongoDB Geospatial distance calculation

[Mister_Snuggles]

Assuming that the bug doesn't get fixed and you decide to switch technologies, PostgreSQL+PostGIS[0] is worth considering. Switching will also open up other GIS tools for your use, like QGIS[1], which may be useful.

I'm using PostgresSQL+PostGIS with QGIS as the front-end for a personal project and it's been fantastic.

[0] https://postgis.net/

[1] https://qgis.org/en/site/

[jka]

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

[rozza]

The post got updated:

> Final Edit: False Alarm

>

> It’s not MongoDB, It’s not the MongoDB Go driver, it’s something I did.

> I was especially careful to double and triple check Long and Lat and still something went wrong.

[Joel_Mckay]

This may look odd on first contact, but it is clearly documented: https://www.mongodb.com/docs/manual/geospatial-queries/

MongoDB uses libbson which should clearly preserve the type in the queries. If the client library wrapper goofs the syntax it is not related to the server core.

Try looking at the raw record in the db shell... ;-)

[threeseed]

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

[cxcorp]

Wow, there's an ad after literally two lines of text. Absolutely unreadable.

[lokedhs]

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.

[pwg]

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

[AuthorizedCust]

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

[beardyw]

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

[matt_d_123]

Great to hear it's not actually a bug in the MongoDB Go Driver, but it sounds like we could improve the MongoDB geospatial data documentation to reduce confusion about the expected coordinate order. I created a proposal to improve the docs: https://jira.mongodb.org/browse/DOCS-15351

[jd_mongodb]

thanks for the ticket Matt.

[throwaway-jim]

It is bug on the mongodb Go driver. I have been using mongodb geospatial queries in nodejs; that too in production, this definitely scared me.

[rozza]

Confirmed not a bug in MongoDB or the Go Driver.

[zeckalpha]

As a workaround, can you maintain double the set of points, the real point and a shadow point, using the shadow points for distance?

[lavishlibra0810]

Not OP: sounds like a good advice to me.

[fredley]

GeoJSON decision to use Long, Lat instead of Lat, Long partly to blame here. It's not what any new user expects. I suspect there are plenty of other bugs lurking out there due to people making the same mistake.

[tmcw]

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.

[perrygeo]

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.

[jandrewrogers]

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.

[NelsonMinar]

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.)

[rozza]

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

[FL410]

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.