[SERVER-43314] open location code support Created: 13/Sep/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Geo, Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Lukas Strassel | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
Hello, I think 2) is not solvable in a way satisfying our performance needs. While we can use `$geoNear` we cannot limit the results with `maxDistance` as each point might have a different radius. So we calculate the distance via geonear and then start sorting out entries in the next stage. While: might be solutions to that problem i'm wondering if it would make sense to also support open-location-codes as https://github.com/google/open-location-code they are simple string representations and ~imperfect circles(+-3m) are perfectly fine for a lot of application needs. |
| Comments |
| Comment by Danny Hatcher (Inactive) [ 16/Sep/19 ] |
|
Thank you for the suggestion. I'll forward it to our Query team for consideration. |