Base16 Support?

[andrewserff]

I have a datasource that uses geohashes encoded with Base16 and I'm trying to figure out how to use your library with that data. I have tried to decode using GeoHash.fromGeohashString() but it appears it's assuming the GeoHash is Base32, so it's incorrect. Is there a way to use your library with Base16 geohashes?

[kungfoo]

Can you point me in the right direction of the datasource and the flavour of base16 they are using? If that is universally used and usefil, we could add an overload of the method that takes a format spec and you could use that one like so: `fromGeohashString(EncodedAs.BASE16)`

…

On Thu, May 14, 2020, 17:29 Andrew Serff ***@***.***> wrote: I have a datasource that uses geohashes encoded with Base16 and I'm trying to figure out how to use your library with that data. I have tried to decode using GeoHash.fromGeohashString() but it appears it's assuming the GeoHash is Base32, so it's incorrect. Is there a way to use your library with Base16 geohashes? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#44>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKAKG2KMOJU3ZPHNJ6FJTRRQE4ZANCNFSM4NAZKGWQ> .

[andrewserff]

Unfortunately, the datasource isn't public. I can try to get you more information if you can expand on what you mean by flavor of base16. Do you need to know what characters are used or something else? It is highly used in the environment I'm working in. Your example would work great. Even if there was just a way to convert from Base16 to Base32 that would be helpful. Let me know what other info you would need or how I can help.

[vinerich]

If by base16 u mean hex maybe this is something for you: https://stackoverflow.com/questions/44654895/convert-hexadecimal-string-to-base32-in-java

[kungfoo]

yeah, the question is whether it also uses some special characters easy for human reading as geohash base32 does.

…

On Wed, May 20, 2020, 15:10 vinerich ***@***.***> wrote: If by base16 u mean hex maybe this is something for you: https://stackoverflow.com/questions/44654895/convert-hexadecimal-string-to-base32-in-java — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKAKDDUKLNTOY6F5CDWTTRSPJFFANCNFSM4NAZKGWQ> .

[andrewserff]

The character set is:

Decimal: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Base 16: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,  a,  b,  c,  d,  e,  f

Latitude Range is [-180, 180]
Longitude Range is [-180, 180]
4 bits of precision per iteration.

I actually tried the hex conversion to base32 and it didn't seem to work. I can try it again as it does seem like that should work. In any case, I think it would be good for this library to support more than just Base32. Base16 and base64 are out there, so it would be nice to have one library to use for any geohash you find.

[vinerich]

Could you supply a base16/hex encoded GeoHash and the corresponding Latitude and Longitude?

As I see this it should be fairly trivial to implement but still somebody needs to have the time: https://stackoverflow.com/questions/49136896/geohash-16-how-to

[andrewserff]

Sure, I choose a spot in Denver:
Lat/Lon: [39.739138, -104.986936]
And here are the GeoHashes to 12 digits of precision:
Base 16 GeoHash: 4b72322e9a6c
Base 32 GeoHash: 9xj64fqc704x

I tried the Base16 (Hex) conversion to Base32 again and got: JNZDELU2NQ====== so that doesn't work...

[vinerich]

Yeah I forgot that geohash base32 differs in its alphabet from the RFC base32 so probably this is better suited in the library.
Is it a problem that the geohash differs in precision when the digits of the hashes have the same precision?
12 digits base16 -> 48 bits geohash
12 digits base32 -> 60 bits geohash
12 digits base64 -> 72 bits geohash

Possible we should switch to the desired geohash precision instead of character precision then.

[vinerich]

I thought about it and it really shouldn't be the problem to integrate it. I would also volunteer to do it. Hopefully will be done somewhere next week.
Idk when it will be merged and released tho.

Last thing to note is that it would break some existing functionality again since atm the method-names are just withCharacterPrecision,fromGeohashString, geoHashStringWithCharacterPrecision, etc..
Need to change that structure to support multiple string encodings.

[kungfoo]

@vinerich We can provide overloads of the methods that take an EncodedAs value, which can be BASE32 or BASE16/HEX and then those methods can do what they need to. Then default to BASE32 whenever no value is supplied. This way this API change would be backwards compatible. The toString() method would probably also require some brushing up, depending on what flavour of encoding is chosen.

[vinerich]

Yeah that's better. Thanks for the hint.
Will see when I have the time.