Geofire query doesn't work in android

[lexayon]

I'm trying to make an Android application that uses Firebase. To save the location I do the following:

geoFire.setLocation(documentReference.getId(), new GeoLocation(latitude, longitude));
Where documentReference.getId () is the ID saved previously. And to do the want with the radio do the following:

    final GeoQuery geoQuery = geoFire.
                    queryAtLocation(new GeoLocation(usuario.getLatitude(), usuario.getLongitude()), radius);
            geoQuery.addGeoQueryEventListener(new GeoQueryEventListener() {
                @Override
                public void onKeyEntered(String key, GeoLocation location) {
                    System.out.println(String.format("Key %s entered the search area at [%f,%f]", key, location.latitude, location.longitude));
                }

I do not understand why it does not recover what I'm saving, if I'm sure the distance is less than what I put on the radio. Any ideas? I am completely new with Firebase and with GeoFire.

In the Firebase rules I have put this:

    {
      "rules": {
        ".read": "auth != null",
        ".write": "auth != null",
        "geofire": {
          ".read": "true",
            ".indexOn": ["g"]
          }
        } 
    }

If I look for the location with geofire through the key, it returns it correctly

[vanniktech]

Have you checked out the CompletionListener parameter and see if you get anything useful from that?

[diblaze]

I have encountered this bug too. I have an item set 100m from the center, but the GeoQuery will not get this item unless the search radius is set to something awfully huge like 8000km!
The code below works with the radius set to 8000km.
geoQuery = geoFire.queryAtLocation(new GeoLocation(58.540825, 17.072655), 8000);
The code below does NOT work with the radius set to 1km. Even though the item is 100m away from inital center.
geoQuery = geoFire.queryAtLocation(new GeoLocation(58.540825, 17.072655), 1);

This is how my database is set up.

EDIT: Apparently there is a similar issue on the JS version of GeoFire - issue.
However ever the Java version is only functional with huge radiuses like 8000+km...

[vanniktech]

Can we be sure the Geohash is calculated properly on both sides (client + backend) ?

[diblaze]

This what the debugging shows when putting in a query for:
geoQuery = geoFire.queryAtLocation(new GeoLocation(58.540825, 17.072655), 8000);

Just a wild guess as it is very late in the night at the moment for me, but in the second picture it looks like we are trying to order by child "g", but will it actually go into each UID and order by G? Because is it not currently trying to order by "g" even though it does not have access to "g" because it is nested into each UID that exists in "userLocations".

[diblaze]

I may be wrong here, but it seems maybe something is wrong with the GeoHash that gets created when the radius is set to a lower number.
For the code below, the query search for a startValue of 'u6h' and endValue of 'u6n'. This will not find the GeoHash in the database which starts with 't69', if I am not mistaken.
geoQuery = geoFire.queryAtLocation(new GeoLocation(58.540825, 17.072655), 100);

I have no idea on how to move forward from now on... @vanniktech does this look familiar to you?

[vanniktech]

It does not but it sounds like my assumption from the first place is correct.

Can we be sure the Geohash is calculated properly on both sides (client + backend) ?

We could calculate the Geohash and then see whether one of the parties (client or backend) calculates this wrong or whether this might be wrong in your database from an import of the initial data. There are also unit tests for calculating those hashes.

[samtstern]

I just tried adding this test to the GeoQueryTest class and it still passes:

    @Test
    public void keyEnteredSmallRadius() throws InterruptedException {
        double centerLat = 58.540825;
        double centerLong = 17.072655;

        GeoFire geoFire = newTestGeoFire();
        setLoc(geoFire, "0", centerLat, centerLong, true);
        setLoc(geoFire, "1", centerLat + 0.005, centerLong, true);

        GeoQuery query = geoFire.queryAtLocation(new GeoLocation(centerLat, centerLong), 1);

        GeoQueryEventTestListener testListener = new GeoQueryEventTestListener();
        query.addGeoQueryEventListener(testListener);

        waitForGeoFireReady(geoFire);

        Set<String> events = new HashSet<String>();
        events.add(GeoQueryEventTestListener.keyEntered("0", centerLat, centerLong));
        events.add(GeoQueryEventTestListener.keyEntered("1", centerLat + 0.005, centerLong));

        testListener.expectEvents(events);

        query.removeAllListeners();
    }

This is as expected:

So while we still need to figure out what's going on, I don't think there's a fundamental issue in the distance calculations here.

[diblaze]

I solved the problem by creating a new Android Virtual Device. The Nexus 5 AVD was not sending the GPS data correctly for some reason, moving the decimal point for the latitude and longitude randomly. At quick glances the values seem good, however, upon later inspection I found it did not send the correct values every time. This is weird because I was restarting the device and every time I got the same longitude and latitudes but the decimal was moved.

This was a weird problem... Sending this to the folks at Google because there seems to be a bug with GPS data from the emulator for some AVDs.

If somebody has this issue, I would recommend looking at the longitude and latitude you are entering into the setLocation method. They could be wrong. If they are wrong, create a new AVD and try it.

[samtstern]

@diblaze so would you say we can close this issue? And thanks for following up!

[diblaze]

Yes, this issue is closable. Hopefully, the solution works for @lexayon and future coders who stumble upon this issue.

Thanks for the help!

[samtstern]

Closing this issue. @lexayon if you have more evidence that something more is going on I am happy to re-open it.

[vanniktech]

Let's add this unit test case to our test suite to make sure we won't regress?

[samtstern]

The existing test case is almost exactly the same, I just wanted to prove that it would also pass with the specific lat/long pair in this issue.

…

On Thu, Dec 7, 2017, 11:35 PM Niklas Baudy ***@***.***> wrote: Let's add this unit test case to our test suite to make sure we won't regress? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#84 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIEw6k7NmP1M7F13YGOcBJ22ekYxzLsmks5s-ObLgaJpZM4Qg_m1> .

[vanniktech]

Alright that works. Thanks :)

[joardar-aditya]

@diblaze @vanniktech Problem yet not solved! Similar problem persists in Android

[joardar-aditya]

@samedson