Serious Bug in MongoDB Geospatial distance calculation

https://blog.icod.de/2022/05/19/serious-bug-in-mongodb-geospatial-distance-calculation/

by mtmail • 4 years ago

66 36 4 years ago

blog.icod.de

zeckalpha• 4 years ago

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• 4 years ago

Not OP: sounds like a good advice to me.

cxcorp• 4 years ago

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

pwg• 4 years ago

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

beardyw• 4 years ago

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

AuthorizedCust• 4 years ago

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

lokedhs• 4 years ago

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.

fredley2• 4 years ago

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.

FL410• 4 years ago

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.

leeoniya• 4 years ago

3 months ago: https://news.ycombinator.com/item?id=30228981

xioxox• 4 years ago

Astronomy usually writes coordinates in this order, for example: Right ascension [RA], declination [Dec] in the equatorial coordinate system (corresponding to Long, Lat), or Galactic sky coordinates l (Galactic longitude) and b (Galactic latitude).

sampo• 4 years ago

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?

Historically, cartography was Lat,Long (1). Then software developers took over, and their natural mode of thinking inherits from thinking in x,y coordinates in 2d-graphics on the computer screen, so Long,Lat started to dominate in software. And now software dominates everything.

Here's a take on the history: http://docs.geotools.org/latest/userguide/library/referencin...

(1) This is from 1983, but the Lat,Long practice is much older https://en.wikipedia.org/wiki/ISO_6709

rozza3• 4 years ago

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

fredley2• 4 years ago

In a cartesian plane yes. However for geospatial it's Lat/Long everywhere except in GeoJSON it seems.

jandrewrogers3• 4 years ago

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• 4 years ago

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

tmcw• 4 years ago

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.

perrygeo2• 4 years ago

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.

dekhn2• 4 years ago

I work with plenty of systems that put y first. Like opencv. Of the Geo software I've used about 30% of them put lat first. It's one of the things I most commonly spent debugging

Joel_Mckay• 4 years ago

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• 4 years ago

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

mushi• 4 years ago

there seems to be no details in the report - without seeing code can't be sure if it's a bug in the driver or the application code ...

Mister_Snuggles• 4 years ago

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• 4 years ago

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

throwaway-jim• 4 years ago

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.

rozza3• 4 years ago

Confirmed not a bug in MongoDB or the Go Driver.

rozza3• 4 years ago

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.

matt_d_123• 4 years ago

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• 4 years ago

thanks for the ticket Matt.

Serious Bug in MongoDB Geospatial distance calculation

Related Stories