[SERVER-838] geo should support arrays of locations Created: 28/Mar/10  Updated: 06/Apr/23  Resolved: 28/Mar/11

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: 1.9.0

Type: Improvement Priority: Major - P3
Reporter: Eliot Horowitz (Inactive) Assignee: Greg Studer
Resolution: Done Votes: 37
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:

 Comments   
Comment by Eliot Horowitz (Inactive) [ 29/May/11 ]

1.9.0 is out - but 2.0 is schedule for the end of june.

Comment by Derek Hardy [ 29/May/11 ]

What a numpty! Thanks Eliot.

All tested and works a treat.

I really need this feature, do you know when 1.9.0 will be released?

Derek

Comment by Eliot Horowitz (Inactive) [ 28/May/11 ]

You defined the index backwards, should be :

{ "ratings.loc" : "2d" }
Comment by Derek Hardy [ 28/May/11 ]

Hi, I'm trying to get this to work on 1.9.0.

I have an object structured as follows

wine

{ .. ratings [ { .. loc [y,x] .. }

,

{ .. loc [y,x] .. }

]
..
}

And I'm trying to search using

db.wine.find({ "ratings.loc" :

{ $near: [ 52.688366 , 1.3829304] }

});

I've created the index using db.wine.ensureIndex(

{"2d": "ratings.loc"}

);

But it doesn't work in v1.9.0, can anybody confirm geospatial queries do support arrays of locations in v1.9.0?

Thanks

Derek

Comment by Scott Hernandez (Inactive) [ 06/Apr/11 ]

This is available in the developer release download : http://mongodb.org/downloads

You can start testing now

Comment by Christian Tonhäuser [ 06/Apr/11 ]

This ticket says it's fixed in 1.9.0.
If you click on that, you'll be taken to a page showing you all unresolved tickets pending for 1.9.0.
Once those are solved, I bet there'll be a download then.

Comment by chaitrali agashe [ 06/Apr/11 ]

Where can we get the mongodb version that supports this? The latest version available at mongodb.org is 1.8.

Comment by Greg Studer [ 28/Mar/11 ]

Indexing of multiple nested locations now supported.

within queries return unique objects, near queries return objects in order of distance and may return duplicate documents to maintain distance ordering. For example, given document A with locations [[1, 1], [3, 3]] and document B with locations [[2, 2], [4, 4]]:

$within : $box : [[0, 0],[5, 5]] returns [A, B]
$near : [0, 0] returns [A, B, A, B]
$near : [0, 0], limit : 3 returns [A, B, A]

Comment by auto [ 28/Mar/11 ]

Author:

{u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}

Message: allow multiple locations to be nested in different subdocuments SERVER-838
https://github.com/mongodb/mongo/commit/f45587a30a9537398c01d2a666f7e3f72cd26948

Comment by Greg Studer [ 28/Mar/11 ]

Arrays of locations are now supported, further work planned for locations embedded in multiple parts of the document.

Note that multiple results for the same object can be returned for geoNear queries (which is the correct behavior, as there will be multiple distances) and near/within queries (which should probably be changed to return unique objects).

Comment by auto [ 28/Mar/11 ]

Author:

{u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}

Message: support for indexing arrays of locations SERVER-838
https://github.com/mongodb/mongo/commit/8ebc664e3c23f0aeda109b32d068e445e77f0bff

Comment by Adam [ 16/Jan/11 ]

I was sad to see this pushed back to 1.9. I also have a need for indexed arrays of locations, but I side-stepped the issue in the mean time by duplicating my top-level objects per location and storing a non-indexed 'locations' array alongside the indexed 'location' field. It's not as efficient or convenient (or maintainable... et c.) but it works for me. E.g., if you have a document (id=1) with 3 locations (A, B, and C), split it into the following and index 'location.loc':

{
_id:'1_A',
actual_id: 1,
location:

{ name: 'location A', loc: [10,10] }

,
locations: [

{ name: 'location A', loc: [10,10] }

,

{ name: 'location B', loc: [20,10] }

,

{ name: 'location C', loc: [10,20] }

]
},
{
_id:'1_B',
actual_id: 1,
location:

{ name: 'location B', loc: [20,10] }

,
locations: [
...
]
},
{
_id:'1_C',
actual_id: 1,
location:

{ name: 'location C', loc: [10,20] }

,
locations: [
...
]
}

When querying you can filter out dupes via 'actual_id'.

Maybe this will help someone else out.

Comment by Ian Dees [ 16/Jan/11 ]

Is there any way to bump this up in the priority a little bit? This is holding up quite a bit of my development and experimentation with Mongo for OpenStreetMap. (I'd be happy to submit patches if pointed in the right direction...)

Comment by Matthew Ford [ 05/Dec/10 ]

We too are facing this issue, we have our address (lat/long) in an embedded document and need to do a geo search on the embedded document.

Comment by Jesse Clark [ 10/Nov/10 ]

If this doesn't get fixed in the next release, it would at least be nice if trying to add a 2d index to an unsupported type would return an error or if at very least the documentation clearly spelled out what was and wasn't supported. This would have saved me several frustrating hours of work.

Here is our case:

{
_id:1,
"locations" : [
{
"_id" : "4c5af230d3d2294edf001c12",
"facility" :

{ "_id" : "4c5af230d3d2294edf001c11", "latlng" : [ 33.6117113, -86.6560709 ] }

},
{
"_id" : "4c5af230d3d2294edf001c12",
"facility" :

{ "_id" : "4c5af230d3d2294edf001c11", "latlng" : [ 33.6117113, -86.6560709 ] }

},
]
}

Comment by Ardic [ 22/Oct/10 ]

Hi, just remember the source of the problem described in MongoDB-user
http://groups.google.com/group/mongodb-user/browse_thread/thread/2a7a1ecd7848361b/1f614df7efaf91c0#1f614df7efaf91c0
to take this into account when solving this functionality, thanks.

Comment by Doug Hudson [ 07/Oct/10 ]

My case:

> db.test2d.save({addresses: [

{name: "home", location: [40.0,-75.0]}

,

{name: "work", location: [40.1,-75.1]}

]})
> db.test2d.ensureIndex(

{"addresses.location": "2d"}

)

Comment by Doug Hudson [ 07/Oct/10 ]

This feature is incredibly important to us too. An entity having multiple addresses is a pretty standard pattern, and being unable to index on such documents is a major obstacle.

Comment by Joshua Paine [ 22/Jul/10 ]

Josh French's use case is the same as mine, though I have street address information in my locs, e.g.:

{ _id:1, location:[

{ address1:'123 foo', city:'Foo', loc:[5,5] }

,

{ address1:'123 bar', city:'Bar, loc:[5,5] }

]}

...ensureIndex(

{'location.loc','2d'}

)

In my app the geo queries are only used in relatively uncommon fallback cases and for which 0 results is often plausible, so I didn't realize it wasn't actually working anymore when I changed my 'schema' to reflect the possibility of more than one location per object.

Comment by Eliot Horowitz (Inactive) [ 29/Jun/10 ]
{ _id : 1 , locations : [ [ 10 , 10 ] , [ 20 , 20 ] ] }
Comment by Josh French [ 24/Jun/10 ]

Eliot indicated over on the mailing list that a test case would be useful. Here's the schema I was using before I realized this feature isn't supported yet:

db.t.save( { _id : 1 , a : { locs : [

{ loc : [5 , 5] }

,

{ loc : [100 , 100] }

] } } );
db.t.save( { _id : 2 , a : { locs : [

{ loc : [6 , 6] }

,

{ loc : [101 , 102] }

] } } );
db.t.save( { _id : 3 , a : { locs : [

{ loc : [7 , 7] }

,

{ loc : [102 , 102] }

] } } );

db.t.ensureIndex(

{ "a.locs.loc" : "2d" }

);

Comment by Ahmad [ 21/Jun/10 ]

This feature is very important. Furthermore, it encourages embedding documents.

Generated at Thu Feb 08 02:55:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.