[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:
Related
Assigned Teams:
Query
Participants:

 Description   

Consider the following use case:

We are developing a new feature for our system that revolves displaying documents from the database on a map. We need to filter the documents by various criteria (not location) and then display the matching documents on a map.

In order to choose the center and zoom level of the map, we need the centroid of the returned records, and the radius that would contain them. Is there a way to retrieve that information using aggregation framework, or do I need to pull all records from MongoDB and do the calculation on our end?

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 ]

lorne.schachter

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"?:

... {earlier pipeline}, 
    {$group:{_id:null, maxX:{$max:"$loc.x"}, minX:{$min:"$loc.x"}, maxY:{$max:"$loc.y"},minY:{$min:"$loc.y"} }}, <other fields if they need them>},
    {addFields:{center:{
          x:{$divide:[{$add:["$maxX","$minX"]}, 2]},
          y:{$divide:[{$add:["$maxY","$minY"]}, 2]}
    }}}

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>


Lorne Schachter
Technical Services Engineer
MongoDB
lorne.schachter@mongodb.com
Deploy in the cloud with MongoDB Atlas, our new service that gets you up
and running in minutes. Learn more here <https://www.mongodb.com/cloud>!​

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?

Generated at Thu Feb 08 04:14:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.