Closed lrholmes closed 9 years ago
I found that this issue was caused by not having a geohash property, only a coordinates array. This could be worth mentioning in the Readme? I had no clue about the geohash previously, but converting the lat/lng to a geohash and storing that makes it work as expected.
I found that this issue was caused by not having a geohash property, only a coordinates array.
I'm not quite sure what you mean by this. The geohashing should be transparent to a user of the GeoFire library since it all happens behind the scenes with GeoFire.set()
. Can you please explain?
Sorry, probably should have explained my use-case a bit more clearly. I'm currently working on a web-version of an iOS app that uses GeoFire. For development we set up a new test Firebase to use.
We probably went about it in an unorthodox way, by recreating the live Firebase's structure ourselves. To try and explain, here's how we're pushing to the Firebase:
usersRef.push({
message: message,
uid: userID,
date: currentTime,
from: userName,
g: geohash, // this was not here when I opened the issue
l: {
0: currLat,
1: currLng
}
});
This method generates a key by itself, so GeoFire.set()
didn't really look equivalent, especially with all of the extra parameters we're storing.
Anyway, when we came to using GeoFire, I could only get results if the radius was some crazy high value, which sparked a bit of confusion for me (as outlined in the OP) because GeoFire was outputting the distance as very small.
After being confused for a while I decided to test with the live Firebase and it worked just fine. Upon comparing the two Firebases, I saw the problem.
It turns out that there was a g
value set in our Firebase, but it was simply 'g'. Schoolboy error, obviously, because that actually does translate to a real location, probably 1197km away, and I think it was done because the actual purpose of g
was unknown.
Now the coordinates are converted to a geohash, it's assigned to g
and the whole thing works very well.
Sorry for having opened up the issue, as obviously it was a mistake on my end, however it would have been a lot clearer what went wrong if there was some more comprehensive documentation that went over how the whole thing works. The only way I found out that there was such a thing as a geohash was by digging into the iOS version where references to "geohash" are made.
Hopefully this clears everything up! Thanks!
Cool, thanks for the writeup. We don't include information about geohashes in the README since 99% of devs don't even need to know they exist under the hood. Re-creating the underlying GeoFire structure is possible but not recommended as it can change in the future (and has changed in the past). We typically recommend that you store all the extra data in a separate node with the same keys as used in GeoFire. It requires an extra lookup but brings a lot of benefits. I talk about this strategy in issue https://github.com/firebase/geofire-js/issues/40.
I know that this issue is old and long closed, but this issues still stands for me even though my geohashes are being automatically stored. Any other reason why my radius has to be ridiculously high before my geoQuery will return results?
Hey there, please open up a new issue and fill out the issue template with a repro of your issue. Without that, it's hard to guess what is going wrong.
Same issue here
My Geofire query only returns something if the radius is set to a seemingly arbitrary 1197 or above. Any less and nothing will be returned. When the data is returned and I log the distances, they are all less than 1, so this doesn't make any sense to me.
Any ideas for why this is occurring?
Code:
Thanks! Lawrence