$maxDistance appears to require degrees rather than radians

[rps]

Changed documentation to reflect degree requirement for accurate querying of geographic coordinate data. Also changed index documentation to reflect that multiple indexes of a given 2d type can be made.

[tychoish]

Thanks for this contribution.

I'm following up with the people who do work on the geospatial capability in MongoDB, although as far as I know we return all distances in radians, although I may be missing a fact. Given that, I'm a bit confused where you observed this behavior? Do you have an example query or illustrative data points that might help me/us understand what's going here?

Thanks,
sam

[rps]

Hi Sam,

I've created a test case below.

Consider a collection 'test' with the following:
{ "_id" : ObjectId("528bf49b5aa6e559c6b56ba5"), "lonlat" : [ 30.2453, 51.3007 ] }
{ "_id" : ObjectId("528bf4a75aa6e559c6b56ba6"), "lonlat" : [ 30.1637, 51.283 ] }
{ "_id" : ObjectId("528bf4b45aa6e559c6b56ba7"), "lonlat" : [ 30.0821, 51.2652 ] }

The top and bottom point are separated from the middle point by ~5.72-5.77 miles. In my queries below I use 6 miles, as these coordinates lack some precision.

Were I to use radians, my query might look like this:

db.test.find({'lonlat': { $near: [30.0821, 51.2652], $maxDistance: 0.00303106845 }})
where maxDistance is in radians (6mi/3959mi)

The result should have both the input and middle point, but only contains the input point (the same result as if maxDistance = 0)

Multiplying the radian value (6/3959) by (180/pi) converts it to degrees. My query in degrees:

db.test.find({'lonlat': { $near: [30.0821, 51.2652], $maxDistance: 0.08683371484 }})
results in a correct set containing the middle point.

I have encountered this issue using a data set with significantly more precision and am happy to send over with queries as well.

[tychoish]

Just to confirm, you're using a 2d index and not a 2dsphere index?

[rps]

Correct.

db.test.getIndexes()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"ns" : "somedb.test",
"name" : "id"
},
{
"v" : 1,
"key" : {
"lonlat" : "2d"
},
"ns" : "somedb.test",
"name" : "lonlat_2d"
}
]

[tychoish]

I believe that the issue your observing is that 2d sphere in conjunction with the $near operator returns results using planar geometry, and the resulting calculation error explains the limited response set. To correct for this problem you can use a 2dsphere index which uses spherical geometry to calculate distance for points on the sphere. If you're already using 2d indexes you may want the $nearSphere query operator for use with 2d indexes, which attempts to use spherical geometry despite the planar nature of the index.

I was able to confirm that $nearSphere produces the expected result on your existing data set. The following documents might help clarify the issue

• http://docs.mongodb.org/master/reference/operator/query/nearSphere/
• http://docs.mongodb.org/master/tutorial/query-a-2dsphere-index/

How does this affect the observed behavior on your data?

[rps]

For unrelated reasons, I ultimately used a geoNear operator with maxDistance in meters, which does not face the same problem.

That said, I submitted the pull request because I believe that the $near operator requires the use of degrees rather than radians. This is important for those who, for whatever reason, are using 2d indexing rather than 2d sphere. The documentation specifically mentions support for this: 'The $near operator requires a geospatial index: ... a 2d index for legacy coordinate pairs.'

To avoid future confusion, I think it's important for the documentation to note that using maxDistance with $near with legacy coordinate pairs on a 2d index requires an input of degrees rather than radians.

[tychoish]

I've confirmed that maxDistance does in fact return using radians as designed with the engineer responsible for geospatial queries and indexes. I think that the geoNear commands provides a more intuitive interface for the kind of query that you're trying to implement.

Sorry for the confusion, and thanks for your work on this.

Cheers,
sam