[SERVER-3054] Assertion failure bmin <= bmax db/geo/2d.cpp 356 Created: 06/May/11  Updated: 12/Jul/16  Resolved: 06/May/11

Status: Closed
Project: Core Server
Component/s: Geo
Affects Version/s: 1.8.0-rc2
Fix Version/s: 1.9.1

Type: Bug Priority: Major - P3
Reporter: Andrey Filyanin Assignee: Greg Studer
Resolution: Done Votes: 0
Labels: geoNear
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux tos-13 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 19:00:26 UTC 2011 i686 GNU/Linux
Notebook Compaq 6910p


Operating System: Linux
Participants:

 Description   

> use EagleEye
> db.POI.insert({"reporter" : [

{"imsi" : "hardcoded", "date" : "123"}

], "location" : { "loc" :

{"long" : 48.35421, "lat" : 135.85171}

, "course" : 0, "name" : "[GAI Post 20km/h] 13 ( )", "type" : "GIBDD"}})
> db.POI.ensureIndex()
> db.runCommand(

{"geoNear": "POI", "near" : [48.483132, 135.257178], "spherical" : "true", "maxDistance" : 0.22/6378}

)
{
"ns" : "EagleEye.POI",
"near" : "1101110000001000001011101101110001010011001000111001",
"errmsg" : "exception: assertion db/geo/2d.cpp:356",
"code" : 0,
"ok" : 0
}



 Comments   
Comment by Greg Studer [ 12/May/11 ]

The first field found in the bson object will always be considered longitude, and the second field latitude - the name is completely ignored. This also holds for arrays - first is always longitude, second is latitude. Certain languages (I'm not sure if perl is one) use unordered hashes, which may be your problem here as the iteration order of keys is undefined - but BSON documents always have an ordering.

The documentation mentions this in caveat #1, but you are right, it should be emphasized.

Comment by Andrey Filyanin [ 12/May/11 ]

I found a cause of my headache.
I am using perl driver, and after inserting a document into collection, for some reason, the order of fields

{long=47, lat=55}

is changing in mongoDB. So when i look up this document through mongo console I see something like

{lat=55, long=47}

. This is why geo-finding features don`t work. There is no any word about correct order of fields "long" and "lat" in documentation, and it is very confusing. Is this meaningful order correct for named fields?

Comment by Greg Studer [ 11/May/11 ]

You're using the command correctly, but the distance you are using is too small. For maxDistance, you need to divide the distance you want by the radius of the earth (in the same units). Your points are about 47 km apart, so you need to have a maxDistance of 47(km)/6378(km). See http://www.movable-type.co.uk/scripts/latlong.html .

Another (very very approximate! ) way of doing this would be to convert degree distance directly into radians by multiplying by pi/180 - see http://www.mongodb.org/display/DOCS/Geospatial+Indexing#comment-134517736

Comment by Andrey Filyanin [ 10/May/11 ]

Ok, I change longitude and latitude, but geoNear give me nothing as result, I could be wrong, but in "near" parameter we should use order [longitude, latitude]?

> use EagleEye
> db.POI.insert({"reporter" : [

{"imsi" : "hardcoded", "date" : "123"}

], "location" : { "loc" :

{"long" : 135.85171, "lat" : 48.35421}

, "course" : 0, "name" : "[GAI Post 20km/h] 13 ( )", "type" : "GIBDD"}})
> db.POI.ensureIndex()
> db.runCommand(

{"geoNear": "POI", "near" : [135.257178, 48.483132], "spherical" : "true", "maxDistance" : 0.22/6378}

)

{
"ns" : "EagleEye.POI",
"near" : "1110110000000100000111011110110010100011000100110110",
"results" : [ ],
"stats" :

{ "time" : 0, "btreelocs" : 0, "nscanned" : 0, "objectsLoaded" : 0, "avgDistance" : NaN, "maxDistance" : -1 }

,
"ok" : 1
}

Comment by Andrey Filyanin [ 10/May/11 ]

Yes! You are right, my mistake. I was using latitude coordinates instead of longitude and vice versa.
Thank you very much for your answer.

Comment by Greg Studer [ 06/May/11 ]

problem is that your latitude is outside the valid bounds (-90, 90), which causes this weird error pre-1.9. See SERVER-2980 for the fix for better error messages in 1.9.1.

Generated at Thu Feb 08 03:01:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.