[SERVER-3347] Option for not only closest distance but also closest location in $geoNear, potentially $near Created: 29/Jun/11 Updated: 28/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Geo, Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | Backlog - Query Integration |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | qi-geo | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query Integration
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
There's no way currently to distinguish, in a multi-location document, the nearest location which generated the result. |
| Comments |
| Comment by Greg Studer [ 06/Sep/11 ] |
|
This would require some significant changes to the way in which we return keys in the geo code - so on hold for now. |
| Comment by Leo Lou [ 27/Aug/11 ] |
|
It would be nice if we can retrieve the index of embedded document, in additional to the distance, and location. |
| Comment by Greg Studer [ 22/Aug/11 ] |
|
Because there isn't currently a standard annotate-doc-with-info codepath in mongodb until the aggregation framework is added, only limited support can be added for this in 2.0. However, |
| Comment by tony kerz [ 30/Jun/11 ] |
|
a couple of comments to consider when you start to think about a solution for this: (1) run/geoNear v. find/near syntax i need to preface this with the following context: although i'm a relatively new mongo user, i'm tremendously impressed with it's capability and potential, and have the utmost admiration for it's designers/developers, so these are just some nice-to-have usability comments that i think might enhance the experience. from what i can gather, to get sort of meta-data about a geo search (e.g. distance), we need to use the "run command" type syntax which delivers a response in a single document vs. the cursor type response delivered by "find" type syntax. these access styles end up manifesting differently enough in both command line and java driver syntax, that run/geoNear becomes trickier to understand and use than find/near. it would be nice if the syntax could be more consistent such that you could "find" a set of "result" objects that where kind of like the elements contained in the "results" field of the document returned by the "run command" syntax. something maybe like: db.collectionOfDocsWithArrayOfGeoLocations.geoFind({geoLocations: {$near: [x,y]}, food-type: "chinese"}) or maybe even: db.collectionOfDocsWithArrayOfGeoLocations.metaFind({geoLocations: {$near: [x,y]}, food-type: "chinese"}) if there are other scenarios where it could be useful to obtain "meta" information about queries such as other (non-geo) indexes used, etc: (2) "meta" information about which geo location mongo hit on now that you support multiple 2d indexes per collection, a hit could occur on either a "singleton" 2d index or an array 2d index, so both field/index name and potentially array index become interesting to the caller. it seems like sibling fields to "distance" on the run/geoNear result object would be a natural place to deliver information about which geo location mongo hit on for that document, for instance: distance: 0.12, (3) multiple hits on same document i believe the current implementation returns the same document multiple times if mongo finds multiple hits. another option for this would be to return the multi-hit document only once and include multiple "hit meta" objects in the result. so instead of single field/distance or field/distance/index per hit, return one of those tuples or triples for each hit in an array with a single copy of the document { , , {field: "alternateAddresses.loc", distance: 0.45, index: 5} ], |