Support for pushing notifications based on geograhic position

[sanzor]

Hello i have the following problem and i wanted to know how could this be solved using rethinkdb's API.

We have N clients who update their geographic position in a RethinkDB table.
There is a constant Range R lets say R=1km.

For any given client C how can we push notifications when any of the other N-1 clients has moved to a location that is in the circle defined by C as the origin and the range R ?

Example:

Clients: [C1,C2,C3] with coordinates [(Lat1,lng1),(Lat2,lng2),(Lat3,lng3)] .
At T0 : C1 has no one in the range of 1KM to be notified
At T1 : C2 has moved to (Lat2*,lng2*) and now this position is in the circle with the origin in C1 and range R.
where T are different points in time.

Therefore at T1 : C1 has to get notified of C2.

Can this be achieved using the Geospatial library ? Furthermore can this be applied to all N clients ?

P.S The Range is constant for ALL N clients and it does not change at any point in time.

So if the range is 1km then all clients will be notified when someone is in 1km proximity.It does not vary per client ,nor does it change its value.

[nha]

RethinkDB certainly has some geographic support, have you seen the following links (in particular how to intersect)?

• https://www.rethinkdb.com/docs/geo-support/javascript/
• https://rethinkdb.com/blog/1.15-release/

The geo-support is exactly what I use for https://geodb.io/index.html - however I can tell that there is quite a bit of plumbing to make it work in addition to what RethinkDB offers out of the box.

[srh]

Geographic change feeds do exist.

In a conversation on the Discord channel it was established that the best way to accomplish his goals was point changefeeds on secondary index whose primary key was a rounding of the coordinates to the appropriate precision -- basically creating a layer of tiles, the secondary index key being a specific tile identifier.

The reason for this is that point change feeds scale well, and range-based change feeds, including geographic index change feeds, do not scale well past 10K listeners (depending on write workload) because all writes pay the cost of updating the feed for the entire table. (The reason for this is that the implementation does not use any interval data structure to save costs, and it is an area which is technically possible to have improved.)

The reason why turning coordinates into a tile identifier (e.g. computing [floor(x / tile_width), floor(y / tile_width)]) worked for this use case is that range R was a constant (or approximately constant, bounded above and below by constants C1 and C2 such that C2/C1 was not too big). If R was arbitrarily large or small then things get more pathological. Point-change-feed workarounds that use multiple levels of tiles and tile identifiers could work if C2/C1 is kind of big but not too big, but you do increase write workload for each level. A sufficiently high ratio of C2/C1 would require better geographic change feed support to be used in the database engine itself.