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/

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

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.

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

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

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

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

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?

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

thanks for the ticket Matt.

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.

Confirmed not a bug in MongoDB or the Go Driver.

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

Not OP: sounds like a good advice to me.

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.

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.

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

I guess there is really no "obvious" ordering, it all depends on your past experience. Named data structures are a way around it, but coordinates represented as tuples/lists/arrays seems cursed to repeat this mistake.

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.

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

Geospatial is pervasively Lon/Lat and has been the standard for decades across virtually every software system. GeoJSON is in the correct order, same order as every other common industry format for geospatial. There are similar conventions for polygon winding order, whether a polygon is closed or not, etc which new users frequently ignore.

To someone that works with geospatial data, this is like asserting that RGB is the wrong order for specifying color, ignoring that approximately everyone in industry has been using this ordering convention for a very long time.

It is usually not the end applications that get it backwards, it's usually a library somewhere in the toolchain that bites you where the author wrote code before learning there are conventions for these things.

OpenCV uses BGR.

It also uses y first indexing

Heh, I did not know that.

Can you give an example of one geospatial library or program that uses lat, lon? I can't think of any because they all use lon, lat.

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.

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

> 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

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