[SERVER-12504] Read access to internal GeoHash values Created: 28/Jan/14  Updated: 28/Dec/23

Status: Backlog
Project: Core Server
Component/s: Geo, Querying
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor - P4
Reporter: Jerome Delamarche Assignee: Backlog - Query Integration
Resolution: Unresolved Votes: 5
Labels: qi-geo
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Assigned Teams:
Query Integration
Backwards Compatibility: Fully Compatible
Participants:
Case:

 Description   

I have to manage 1 million geo-points localized all over the earth.
For performance reason, I need to group the points which are in the same "cells". I have implemented an algorithm wich computes for each point, its geohash value, so that it is quite easy, using the aggregate framework and functions like $substr, to group and count the points which are in the same cell.

But the documentation says Mongo already computes geoHash values from geo points given as [lon, lat].

It would be nice if this internally computed geoHash value could be returned (as a readonly attribute ?) with the documents.



 Comments   
Comment by Tom Hollander [ 19/Dec/18 ]

Yes this would be very useful for Charts to create geo heatmaps and geo clusters.

Comment by Will MacHugh [ 18/Dec/18 ]

We also have an application with millions of points of data that need to be processed with a geohash. I believe that MongoDB is working on a charting application that will include some maps. It would seem like a natural thing that they would want to rely on internal MongoDB data instead of pushing people to add an additional hash to each record. 

Comment by Jerome Delamarche [ 28/Jan/14 ]

It seems it does not work on v2.4.9. Anyway, since it is not supported, this kind of trick would not be used for production.
Since "2d" indexes are faster than "2dsphere" indexes, I would be nice to have this "feature" work with "2d" indexes...

Comment by Daniel Pasette (Inactive) [ 28/Jan/14 ]

I believe this actually works (not really intentionally, so not a good idea to have any application depend on it). see: SERVER-8592

Generated at Thu Feb 08 03:28:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.