Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Submitted
Created by Mitchell Horning
Created on Dec 19, 2025

MongoDB missing support for GeoJSON-compliant indexing+intersection queries

What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

We are building a geospatial application that uses GeoJSON natively. We need to query MongoDB for a list of GeoJSON objects that intersect with a given GeoJSON object.

Currently, there is no way to correctly search for intersecting polygons in MongoDB. This is because the 2dsphere index and accompanying $geoIntersects operator assume that lines in a geometry are geodesics, and not Cartesian lines.

According to RFC 7946 (The GeoJSON Format), this assumption is nonstandard:

A line between two positions is a straight Cartesian line, the
shortest line between those two points in the coordinate reference
system (see Section 4).

In other words, every point on a line that does not cross the
antimeridian between a point (lon0, lat0) and (lon1, lat1) can be
calculated as

F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)

with t being a real number greater than or equal to 0 and smaller
than or equal to 1. Note that this line may markedly differ from the
geodesic path along the curved surface of the reference ellipsoid.

For example, here is a valid GeoJSON Polygon that MongoDB incorrectly computes as self-intersecting:

{
"coordinates": [
[
[
0,
1
],
[
-58,
-1
],
[
-4.54223633,
0.170578
],
[
-4.0852582,
0.07405947
],
[
-7,
0.11650848
],
[
-4.0540907,
0.06747657
],
[
1,
-1
],
[
0.5,
0
],
[
1,
0
],
[
0.4963324,
0.00733519
],
[
0,
1
]
]
],
"type": "Polygon"
}

What would you like to see happen?

Describe the desired outcome or enhancement.

An alternative index and operator that check for planar intersections would be ideal, since it will allow users to conform to the GeoJSON specification, while maintaining backwards compatibility.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

It is currently impossible for us to implement our features using MongoDB due to the above issue, despite MongoDB nominally having GeoJSON support.

What steps, if any, are you taking today to manage this problem?

We have to caveat to our users that our intersection logic is not trustworthy. It is unclear if there is a provably correct way to capture all possibly intersecting objects in the database, then filter the list to actually intersecting geometries in the application. If there is no timeline to remedy this on MongoDB, we will likely migrate to a database that supports GeoJSON.