I’d like to hear if anyone else has solved this problem. I have a possible solution. Do you think the additional complexity plus oplog is better than the poll/diff?
I could store zones for locations, and defined some granularity parameter: R = 1 mile, for example:
On inserting newDoc with location field, check if the location is within R of an existing zone. If so, newDoc.zone = existingZone Else, create a new zone with center newDoc.location, and set newDoc.zone = newZone.
In the publish function, the app will first static-query the zones around the user’s location, results in an array. Then use the result array to publish all docs within those zones. Use the added/changed/removed to compute the distance to the user on the fly in the publish function, since the user’s coords are an argument. The user can now sort by distance, from a live query which is oplog-enabled.
Is the additional complexity here (query to get zones, plus a zone collection) worth the oplog enabled? Another downside, perhaps the most obvious, is the discretization of the locational data, based on R. To be honest, this is not a problem in my app.
@slava This related to our discussion on geoQueries. This is the solution I thought of. Based on your experience, would it be preferable to query my collection for elements $in an array, versus querying for elements $geoWithin a point? (taking into account that oplog is disabled for latter)
The above method will allow to get locational data using the oplog, however it sacrifices fine-grained results for coarse-grained results.
For my usecase I will be subscribing with quite zoomed in map.
Is there option to define square around that center point, like points A, B and than just looking for documents with coordinates higher than point A and lower than point B ?
For now I am not sure how to convert km radius to lat/long
latlng are angles, so you can calculate the arc length which is the dist on
ground.
you can don’t need to use the strict curvilinear geometry as you stated
that you are dealing with very zoomed in map where typical distance <<
radius earth. so arc is essentially straight.
I’m not sure what you mean by the square thing. in the idea I propose, it
wouldn’t really matter if we used circular or polygonal regions, save for
one being faster to compute.
