NearQuery - Inconsistent distance returned by MongoDB 2.6 and MongoDB 2.4 [DATAMONGO-906]

[spring-projects-issues]

Titi Wangsa opened DATAMONGO-906 and commented

From the MongoDB documentation:
http://docs.mongodb.org/manual/reference/command/geoNear/

near : { type : "Point" , coordinates: [ <coordinates> ] } ,

this returns consistently returns the distance in meters (mongodb 2.4 and 2.6)

However, the behavior of Spring Data MongoDB is not consistent
NearQuery.java:364

dbObject.put("near", point.asList());

the JSON will be:

near : [ <coordinates> ] ,

instead of

near : { type : "Point" , coordinates: [ <coordinates> ] } ,

The form:

near : [ <coordinates> ] ,

will return "radian" for MongoDB 2.4
will return "meter" for MongoDB 2.6

whereas this form:

near : { type : "Point" , coordinates: [ <coordinates> ] } ,

will return "meter" for MongoDB 2.4
will return "meter" for MongoDB 2.6

here are the mongodb commands that I ran to verify this

MongoDB shell version: 2.4.10
connecting to: test
> db.runCommand({ dropIndexes: "location", index: "*" })
{ "ok" : 0, "errmsg" : "ns not found" }
> db.location.drop();
false
> db.location.save({"_id":1, "position" : [-74.044628, 40.689182]})
> db.location.save({"_id":2, "position" : [-74.041243, 40.700309]})
> db.location.ensureIndex( {position: "2dsphere"} )
> db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis
0.00006597925143243118
> db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis
420.8222635611893
>

MongoDB shell version: 2.6.0
connecting to: test
> db.runCommand({ dropIndexes: "location", index: "*" })
{ "ok" : 0, "errmsg" : "ns not found" }
> db.location.drop();
false
> db.location.save({"_id":1, "position" : [-74.044628, 40.689182]})
WriteResult({ "nMatched" : 0, "nUpserted" : 1, "nModified" : 0, "_id" : 1 })
> db.location.save({"_id":2, "position" : [-74.041243, 40.700309]})
WriteResult({ "nMatched" : 0, "nUpserted" : 1, "nModified" : 0, "_id" : 2 })
> db.location.ensureIndex( {position: "2dsphere"} )
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 1,
        "numIndexesAfter" : 2,
        "ok" : 1
}
> db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis
420.8260281020651
> db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis
420.8260281020651

Problem is, if we simply replace

near : [ <coordinates> ] , 

to

near : { type : "Point" , coordinates: [ <coordinates> ] } ,

this will break existing MongoDB 2.4 applications

My suggestion is to change it to

near : { type : "Point" , coordinates: [ <coordinates> ] } ,

AND handle "distanceMultiplier"

something like
		if (metric != null) {
			dbObject.put("distanceMultiplier", metric.getMultiplier());
		}

to

if (metric != null) {
     dbObject.put("distanceMultiplier", METER_TO_RADIAN * metric.getMultiplier());
} else {
     dbObject.put("distanceMultiplier", METER_TO_RADIAN);
}

the only drawback to this is, the default value is inconsistent with MongoDB's default value.

Options:
Option 1. Do nothing.
Impact: Applications what worked with MongoDB 2.4 will get different distance result with MongoDB is upgraded to MongoDB 2.6

Option 2: Alter the code and use "meter" as default.
Impact: Will cause existing applications on MongoDB 2.4 to fail.

Option 3: Alter the code to consistently return "radian" no matter the version.
Impact: Existing applications on MongoDB 2.4 will work just fine.
MongoDB 2.6 users might feel weird as the "distance" without specifying the "distanceMultiplier" is not what they might initially expect.

---

Affects: 1.4.1 (Codd SR1)

Backported to: 1.3.5 (Babbage SR4)

[spring-projects-issues]

Thomas Darimont commented

Hello Titi,

thanks for reporting this - is this changed behaviour documented somewhere in the mongodb docs?
http://docs.mongodb.org/manual/release-notes/2.6-compatibility/#geospatial-changes
doesn't mention this.

Cheers,
Thomas

[spring-projects-issues]

Thomas Darimont commented

Actually, to me this looks like an inconsistency / bug in mongodb 2.6.0 itself.
Since the documentation states in (http://docs.mongodb.org/manual/reference/operator/query/near/#op._S_near) that a legacy point would be handled with a radians metric:

The optional $maxDistance operator limits a $near query to return only those documents that fall within a maximum distance of a point. If you query for a GeoJSON point, specify $maxDistance in meters. 

-> If you query for legacy coordinate pairs, specify $maxDistance in radians.

[spring-projects-issues]

Thomas Darimont commented

I created https://jira.mongodb.org/browse/SERVER-13540 to discuss this with the MongoDB devs

[spring-projects-issues]

Thomas Darimont commented

Small update: The mongodb server team confirmed this as a bug - waiting for a solution

[spring-projects-issues]

Thomas Darimont commented

This is fixed in the master of mongodb/mongo Server and backported to the 2.6 branch so it should be available with the next 2.6.x version of mongodb

[spring-projects-issues]

Thomas Darimont commented

Resolved as Work as Design.

This is a MongoDb issue that has already been fixed by the MognoDb team.
See the attached MongoDb JIRA issue for details