[SERVER-27248] Provide a way to Calculate Centroid and Radius of Geo Records Created: 01/Dec/16 Updated: 06/Dec/22 Resolved: 07/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Geo |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Lorne Schachter | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Incomplete | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query
|
||||
| Participants: | |||||
| Description |
|
Consider the following use case:
It certainly seems like geoNear is the right solution for computing the distance on the last step so they can center their output, but there doesn't seem to be an easy way to do the centroid computation external to the pipeline and pass the resultant values into the geoNear call. Would it be feasible to remove that restriiction on geoNear so that it could be placed anywhere within an aggregation pipeline? |
| Comments |
| Comment by Asya Kamsky [ 07/Aug/18 ] | ||||||
|
It's not clear exactly what the feature would be, so closing as incomplete.
| ||||||
| Comment by Asya Kamsky [ 22/Dec/16 ] | ||||||
|
I don't believe moving $geoNear later in the pipeline would be sufficient, as it takes a center point, it does not provide or calculate one. I'm going to convert this ticket to a request for enhancement to allow such a calculation. Meanwhile, if the geometry of the points in question is flat (rather than spherical) you can approximate such a calculation by figuring out mix/max and average of X and Y coordinates. If the aggregation pipeline selects a subset of documents, do the following, assuming the documents output have coordinates "loc.x" and "loc.y"?:
| ||||||
| Comment by Lorne Schachter [ 22/Dec/16 ] | ||||||
|
Asya, So, is there no way to (easily) address this use case? It doesn't seem that unreasonable and you can certainly imagine lots of applications that might want to do the same thing. Lorne | ||||||
| Comment by Asya Kamsky [ 22/Dec/16 ] | ||||||
|
I believe it's required to be first because it must be able to use a 2dsphere index. | ||||||
| Comment by Lorne Schachter [ 20/Dec/16 ] | ||||||
|
Asya, That's my understanding of how $geoNear works. Lorne | ||||||
| Comment by Asya Kamsky [ 20/Dec/16 ] | ||||||
|
I see, both geoNear stage and $match with $nearSphere require fixed maxDistance - the issue is just that $match returns matching documents as they are, and $geoNear injects a new field showing actual distance, is that right? | ||||||
| Comment by Lorne Schachter [ 12/Dec/16 ] | ||||||
|
Charles, I think that's exactly the use case they have - find nearest n and display. Lorne On Mon, Dec 12, 2016 at 3:35 PM, Charlie Swanson (JIRA) <jira@mongodb.org> – | ||||||
| Comment by Charlie Swanson [ 12/Dec/16 ] | ||||||
|
asya I will admit I am not experienced with geo queries, but it sounds like the desired radius for the $nearSphere is unknown. I could imagine something like "find the closest grocery stores", where maybe there needs to be some $lookup or $redact or something to check if a user is allowed to see a grocery store (I don't know why that would be the case, but for something other than grocery stores it might make sense), then a useful display of your results would need to know how far to zoom the map. If I'm in Manhattan I would want to zoom closer than if I were in say Kansas where the grocery stores are likely farther apart. Does that make sense? | ||||||
| Comment by Asya Kamsky [ 08/Dec/16 ] | ||||||
|
Couldn't you use $match with $nearSphere in later stage? |