Closed portalsio closed 9 years ago
+1
Hey guys, while I agree this would be a cool feature to add, it does not fit nicely into the way Firebase works and would require an entire re-architecting of this library. Firebase only allows one-dimensional queries while this feature would require a two-dimensional (latitudinal and longitudinal) query, so this is really not very straightforward. I won't dwell on that too much (unless, of course, you want more details).
Despite that, I think there are some solid workarounds. For one, you could start your query radius small and gradually grow your query radius until you have N number of points in it. This works because we won't re-fire the onKeyEntered
event for those points which are already within your query. And this should really not be that expensive of an operation.
The other solution is to just do a query over a location that you think has at least N points in it (you'd have to most likely guess at this depending on what your data looks like), and then grab all the points within that query. If there are less than N points, you'd have to increase your radius size. If there are more than N points, you can just use the distances from the center we provide in the onKeyEntered
callbacks and sort the list of points client-side. While you may end up pulling down more data than you need, this should still be fairly performant assuming you choose a reasonable starting query radius and don't have a ridiculously large number of points.
There may even be more creative ways to do this, but it's late on a Friday and I'm not at 100%. I'm closing this issue since this is not a feature that we will be implementing given the current way that Firebase works, but please don't take that as a dig towards the idea. Maybe in the future Firebase will support a way to do this very efficiently. In the meantime, using one of the suggested workarounds is your best bet. Good luck!
I also think we should be able to query locations sorted by distance so we can get the closest geolocations results. The proposed workarounds are not easy to implement.
please re-open this issue, this new feature request would be a great enhancement to the repo
Hey there, thanks for the feedback. Unfortunately, this kind of feature is not possible to do in a performant way with the way the existing library stores the data. I'm also not really sure how we could do this efficiently unless Firebase itself supported these kinds of geo queries. I'd rather only keep issues open if they are actually actionable. I realize the workarounds I suggested are non-ideal, but they are possible.
Hi jwngr, the below approach you suggested is pretty neat. I wonder if we can eliminate any expense that is left by performing the operation on the Firebase server which will then return the keys?
"For one, you could start your query radius small and gradually grow your query radius until you have N number of points in it. This works because we won't re-fire the onKeyEntered event for those points which are already within your query. And this should really not be that expensive of an operation."
The Firebase server has no knowledge of geolocation queries (which is why this library ultimately exists). So, performing this kind of operation on the Firebase servers would require new features for the Firebase server. That team is well aware of this feature request but we have no news to share on when richer querying will be available.
I guess with the new Functions we could limit the results "server-side" right?
@jwngr How to do the gradually grow your query radius
without re-fire key_entered
?
Let say I want to query within 5km and I don't want to query all the things within 5km at initial. Instead query km by km.
Senario,
Query 0km - 1km, if user scroll down query 1km - 2km, 2km - 3km and max is 5km. Is that what you mean?
Right now geofire enables me to find points within a certain radius. I think a query like "find the 10 points that are cosest to me" could also be useful.