Precision of GeoHash must be larger than zero!

[Keith Turner]

Working on an android app where the user can pan/zoom a map. The geofire query is updated with the new radius and center as needed. I'm getting a "Precision of GeoHash must be larger than zero!" exception, which only seems to occur when the map approaches a latitude close to 90 or -90. For an example, the following line
geoQuery = geoFire.queryAtLocation(new GeoLocation(88, -70), 100);
causes
java.lang.IllegalArgumentException: Precision of GeoHash must be larger than zero!
at com.firebase.geofire.core.GeoHash.<init>(GeoHash.java:29)
at com.firebase.geofire.core.GeoHashQuery.queriesAtLocation(GeoHashQuery.java:82)
at com.firebase.geofire.GeoQuery.setupQueries(GeoQuery.java:229)
at com.firebase.geofire.GeoQuery.addGeoQueryEventListener(GeoQuery.java:330)

Any idea why this is happening and a fix/workaround?

Thanks
Keith

[Steffen Frost]

You are close to the north pole, and your 100km radius probably crosses the north pole.  Perhaps geoQuery barfs up on that. -s

[Keith Turner]

Yea, I figured the poles have something to do with it since the only time it has happened is when I get near the north or south pole. But, I'd expect a geoquery that includes a pole is a valid use case. E.g., give me all data within 50km of the north pole. Not necessarily a common one, but a valid one.

Keith

[Jonny Dimond]

The way geo hashing works, there are some singularities around the poles :( The queries will also become very inefficient (covering much more than the desired radius) around the poles. This is because the relations between the actual distance of a degree latitude and a degree longitude become highly warped as the latitude approaches 90 degrees. If you require high precision around the poles, you need to transform the coordinates so the poles lie at different points (e.g. at the equator). However, you will always have 2 poles at which geo hashing breaks down...

Jonny

[Keith Turner]

It's not that I need high precision at the poles, I'd just like to keep geofire from throwing an exception if a user pans the map towards a pole. Avoiding the poles may be an acceptable solution (if something has to be avoided, the poles are probably a good candidate). Is there a way to determine what area near the poles needs to be avoided? Does that factor in the query inefficiency that you mentioned - that as you approach the poles, the area included in the query gets much larger than intended?

Thanks
Keith

[Jonny Dimond]

That's a fair point. We will consider adding something in the future (maybe just a function that returns whether it's a valid query). The way to determine whether a query is valid is to check whether the shortest distance from the query center to either pole is larger (by a margin that depends somewhat on rounding errors, I would say factor 2 should error on the safe side) than the radius. Geo hashing will use the maximum delta of latitude and longitude degrees at the current point converted from meters. So close to the poles the maximum longitude delta will approach 360 degrees longitude at which point the query will include the entire globe. There is a bunch of tricky math involved to calculate exactly what range is covered (take a look at the source code if you are interested), so it's difficult to give exact numbers here. Anything smaller than ~80 degrees latitude with a radius less than ~100miles should be fine regarding the region covered.

As a hacky workaround you can catch the exception and show the user an error in that case, however the query might end up covering the entire globe.

[Keith Turner]

I've set the map so that the center point cannot go above 60 degrees latitude. That should put it just over 3,300km from the pole. For the radius, I'm using the distance between the center and a corner of the map, with a maximum of 2,000km. If I zoom the map to increase radius, I still get the geohash exception. The most recent exception happened with a radius of 1,543km and map center of 59.99999999999998, -83.42086201645216. This falls within the 2x safety factor you mentioned. Any further comments on this or is it still behaving as you expected?

[Jonny Dimond]

I think I was off with the safety factor of 2. What happens internally in the library is that it will need to determine how big the delta in longitude can be at a given radius. The math for circles get's complicated so it just estimates it with a bounding box. If you look at the delta in longitude of a distance of 2000km at 2000km north of 60 degrees latitude that results in a huge value (up there each degree longitude only covers a tiny distance). The end result is that the query includes the entire longitude range which, because of how geo hashes work, has to include in the entire latitude range too. The GeoFire queries don't really work for huge radii as the approximations it uses only work for smaller scales and not near the poles. I'd recommend keeping the radii small enough to not get into these extreme cases.

[Keith Turner]

Is there any way to get this radius restriction documented? In our situation, it's a potentially very large limitation as we're showing data on a per country level - so our maps cover a large geographic area. I have some ideas to work around the issue, but without knowing what radius/latitude relationship is supported by geofire, I don't know if those areas are worth pursuing.

Thanks
Keith

[Jonny Dimond]

Hi Keith,

I added a task to document this behavior to the backlog. FWIW - I'd go ahead an study the source code to determine whether your scenario is possible here or whether your workarounds work (specifically GeoHashQuery.java and it's method queriesAtLocation). You can also refer to the Geohash Wikipedia page to see how geohashing works. Finally at country level GeoFire might not be the ideal solution. You might be better off just dividing your data set into discrete sets that you query using country codes, continents or something else.

Jonny