-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement] Paging for geo.nearby #16
Comments
@nicolas-raoul Unfortunately there is no way to do paging as you describe in a very performant way, even when using the native interface. :( You will have to do some form of sorting by distance within a given radius, and then cache it for further paging. Because this module uses redis, we're limited by the algorithm Redis uses which is centered around geohashes. We're also limited because Redis does not do combinations of queries (ie. we can't subtract one query from the other, like in SQL). In dealing with this situation: Cache sorted results for each query in a Redis ZsetThis is the only way I can think of making it work for you. You'd have to do the implementation, but here are some ideas: Other DB solutionsThere are other DB solutions (ArcGIS, postGIS etc) which may solve your problem (while introducing more) Use a UI pattern that groups by distance rangeA common UI pattern you can use (which I've seen well used) is grouping results by distance. Results sorted by distance: I don't want to speak to the users of your app, but usually the nearest are the most relevant anyway. You'll still need to filter out previous smaller areas for each larger query. But I guess what I'm saying here is to manage user expectations, sometimes design solves the problem :D Hope this helps! |
For this, I was thinking about how to implement paging, I think is the final use PGSQL to complete detailed paging |
My app shows a list of nearby ATMs.
At first only the 20 closest ATMs are shown in the list (see screenshot below). When the user scrolls, more ATMs are loaded from node-georedis. As the user scrolls more and more, they get further and further ATMs.
An ideal geographic database would return ATMs in concentric rings, allowing an
offset
parameter in the request, and keeping a kind of cache internally so that subsequent requests do not cost more and more CPU/memory.If would be great if node-georedis could provide this paging. Meanwhile, if you have any tricks for dealing with this kind of situation I would be glad to hear about them :-) Cheers!
The text was updated successfully, but these errors were encountered: