[SERVER-4572] Geospatial index cannot be used in $and criteria of a query? Created: 28/Dec/11  Updated: 11/Jul/16  Resolved: 18/Dec/13

Status: Closed
Project: Core Server
Component/s: Geo, Querying
Affects Version/s: 2.0.2
Fix Version/s: 2.5.5

Type: Question Priority: Major - P3
Reporter: Mark Sievers Assignee: hari.khalsa@10gen.com
Resolution: Done Votes: 17
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File SERVER-4572.js    
Issue Links:
Depends
depends on SERVER-3071 Index Intersection Closed
Participants:

 Description   

Question posted on mongodb-user here http://groups.google.com/group/mongodb-user/browse_thread/thread/41173a4a2c62f0be

Quick synopsis is I'm getting this error back from the shell

Wed Dec 28 12:39:01 uncaught exception: error {
"$err" : "can't find special index: 2d for: { $and:[ { geometry.centroid:

{ $near: [ -37.817532, 144.967148 ],$maxDistance: 5.0 }

},

{ identity.type_name: \"airport\" }

] }",
"code" : 13038

when using $near on a geospatial index in an $and query. Pulling the $near outside the $and gets the expected behavior.

I can't see any caveats in the docs on geospatial queries or $and that indicates any restrictions here.



 Comments   
Comment by Tobias Gassmann [ 18/Oct/13 ]

Using $geoWithin with $centerSphere will do the job without throwing an error. But the index will not be used after all. The underlying problem of this bug is that queries return a BasicCursor although a S2Cursor on the geospatial-index could have been used. Thus performance degrades dramatically as collections grow.

Comment by olivier stevens [ 18/Oct/13 ]

I have got the same Issue. I finally use $geoWithin with $centerSphere that does the job for me.
http://docs.mongodb.org/manual/reference/operator/query/centerSphere/

Comment by Tobias Gassmann [ 03/Sep/13 ]

A similar problem occurs when querying against a compound 2dsphere-index using $and. The index can obviously not be found and a BasicCursor is created. $and-queries using the implicit way (separated by ',') are executed correctly with a S2Cursor. (version 2.4.6)

Comment by pan shangbin [ 11/Jul/13 ]

I have the same problem. I just want to find one document with the condition
{$and:[{coordinates:{$nearSphere:[ 121.0, 32.0 ],$maxDistance: 0.00015678896}},

{"_id" : ObjectId("51c27ab3fb06280efea5c654")}

]}
but I only get
"$err" : "can't find any special indices: 2d (needs index), 2dsphere (needs index), for: { $and: [ { coordinates:

{ $nearSphere: [ 121.0, 32.0 ], $maxDistance: 0.00015678896 }

},

{ _id: ObjectId('51c27ab3fb06280efea5c654') }

] }",
"code" : 13038
so would you tell me when to fix it? and in whitch version?

Comment by Daniel Pasette (Inactive) [ 26/Jun/13 ]

We plan for SERVER-3071 to provide for this use case.

Comment by Jacek Z?owocki [ 24/Jun/13 ]

I'm so stuck with this one.. My case is very simple, yet this issue is critical and prevents me from using MongoDB in this project at all.

Just to say it simple: I've got documents storing lines (LineString GeoJSON objects) using 2dsphere index. Eg.:

{'name': 'Example 1', 'coordinates': [ [40,5], [41,5], [42,6], [43,7], [44,8] ]}
{'name': 'Example 2', 'coordinates': [ [40,5], [41,5], [42,4], [42,3], [43,2] ]}

I need to get all the documents, containing lines that run near two (or more) specified points: [40,5], [43,7]. The correct way to do that would be:

db.collection.find({$and: [
  {coordinates: {$near: {
    $geometry: {
      type: "Point",
      coordinates: [40,5]
    }, 
    $maxDistance: 100}
  }},
  {coordinates: {$near: {
    $geometry: {
      type: "Point",
      coordinates: [43,7]
    }, 
    $maxDistance: 100}
  }}
]})

It's still impossible in version 2.4.
Let us know if there are plans to make it work in the nearest future, please..

Comment by Nelson LEVERT [ 21/May/13 ]

Hello Guys,

I'm having the same problem in my project "can't find special index: 2d for":

{"$and": [
   {"gps": {"$within": {"$centerSphere": [
      [
         45.465469172797974,
         6.892060661315917
      ],
      0.0012556898446083817
   ]}}},
   {"houses": {"$elemMatch": {"$and": [
      {"capacity": {
         "$gte": 1,
         "$lte": 2
      }},
      {"tarifs": {"$elemMatch": {"$and": [
         {"startDate": {"$gte": {"$date": "2013-05-17T22:00:00.000Z"}}},
         {"price": {
            "$gte": 4532,
            "$lte": 5000
         }}
      ]}}}
   ]}}}
]}

Any update on this issue ?

Comment by Arvind Srinivasan [ 22/Jan/13 ]

I just verified that this is broken on 2.2.2 as well. Please fix this!

Comment by Arvind Srinivasan [ 06/Nov/12 ]

I'm experiencing the same issue. Here are the details:

Moped::Errors::QueryFailure (The operation: #<Moped::Protocol::Query
@length=224
@request_id=2
@response_to=0
@op_code=2004
@flags=[]
@full_collection_name="splash_development.activities"
@skip=0
@limit=0
@selector={"$query"=>{"$and"=>[{}, {"actor.l"=>{"$near"=>[47.6268588, -122.32129250000003], "$maxDistance"=>0.4499640028797696}}]}, "$orderby"=>{"created_at"=>-1}}
@fields=

{"receivers"=>0}

>
failed with error 13038: "can't find special index: 2d for: { $and: [ {}, { actor.l:

{ $near: [ 47.6268588, -122.3212925 ], $maxDistance: 0.4499640028797696 }

} ] }"

Here is how I have defined index:

index(

{ 'actor.l' => "2d"}

,

{min: -200, max: 200, background: true, sparse: true}

)

I'm using Mongoid 3.0 and MongoDB 2.0.4

Comment by raxit sheth [ 05/Nov/12 ]

@Dan

Can you help me with this query, i have tried putting $near out and $and inside, but not working

Ref : http://groups.google.com/group/mongodb-user/browse_thread/thread/beaa1f32434c9e38

Raxit

Comment by raxit sheth [ 05/Nov/12 ]

Is there any fix avail in non-production-ready version?

as geoquery can only have one index field, and $and not working it is creating too much restrictions and great if any workaround is avail earliest!

Comment by Adam Kusmierz [ 05/Sep/12 ]

$or doesn't work as well

Comment by William Zola [ 01/Aug/12 ]

Attached reproducible test case.

Comment by Marc Weil [ 14/Feb/12 ]

I am having this problem too. It's especially problematic given that I'm using an ODM in Ruby to perform these queries, and I'd love to not have to introduce special cases into all my code to get around this.

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