Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Apr 9, 2014 · 6 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Apr 9, 2014

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 10, 2014

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 10, 2014

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 10, 2014

Thomas Darimont commented

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

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 15, 2014

Thomas Darimont commented

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

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 16, 2014

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 17, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.