If you're interested in polygons, lines, etc; more physically accurate (and completely implemented) distance queries, spatial joins, aggregation, 3D and surveyor-annotated data, set-theoretic operations ... PostGIS is far and away the way to go. It's far more mature and debugged than any of the NoSQL geospatial stuff I've seen, not only WRT correctness but also performance.
As a point of reference: There's a growing legion of geographers who do all their vector work in SQL using PostGIS.
All that said, for some applications, being tied to the relational model is a deal breaker. Just know that in terms of capability and maturity on the geospatial front, you'll be trading off a Cadillac for a partially assembled rocket sled.
> We don't currently handle wrapping at the poles or at the transition from -180° to +180° longitude, however we detect when a search would wrap and raise an error.
generalized grumble
Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard.
(It's a nice opportunity to publicly show off a specialty/core competency and brush up a bit on C++ a the same time. I'm not that easily provoked into action by internet commentary! ;) )
But, looking at the source, I think I will be probably a Bad Contributor and end up with a gigantic pull request and a (mostly) full re-implementation...
Do you mean you think they don't know how to do it?
As I followed the roadmap on this specific point, it looks more like an incremental development to me: they first used rectangular coordinates in 1.6, then a spherical model in 1.7 etc.
It allows to bring a more lightweight solution quickly to people that need it (like me), then to evolve based on the feedback etc.
For example: If they were truly using a "spherical model", then one would not expect to have queries fail at the poles & dateline, would you?
At least it is documented and fails hard with an error rather than giving wrong results, so a developer can quickly figure out the weak spots --- though I bet a lot of people would prefer the wrong results to queries that cause exceptions in their systems.
> Do you mean you think they don't know how to do it?
I think it has more to do with the absurdly low bar they've set for themselves to check the "geospatial" box than it does with competence.
Your mileage may vary as they say: I used the GIS since 1.6 and it was very helpful for me in this form already :)
Analogy: It's like seeing "ACID compliance!" on a feature list, then finding buried in the documentation that is only the case for single-document transactions in unordered collections on a single machine only.
The new feature might be useful to some but including it on a feature list without disclaimer is misleading.
Really curious: are you using mongo currently? Or browsing the docs?