-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add base32 is possible #4
Comments
The internal INT representation is a 64 bit integer. you can treat this as 2 32-bit unsigned integers. Will that be a good solution? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, it is a suggestion. The main geocodes, like Geohash, use something between base16 and base36 to compress, because for humans and use in resilient protocols we can use alphanumeric codes (no extra-symbols) with case insensitive letters. PlusCode e.g. uses base20, in this range. And the most useful are the base32 variants... Is important to show (here without patents, this is the merit of the open work!) how to offer Hilbert indexation of base32.
As 32×32=1024, we have an exact representation for each two base32 digits. In the Hilbert hierarchical grid terms, it is a "level L5" or "level L+5". So one digit is "L+2.5" (level L+3 minus a half)... It can be represented as "degenerated grid" merging pairs of cells:
The reindexation is necessary only when identifing the cells of the grid, and it is easy, for each cell x, of an index x starting with zero, there are a merged cell i=floor(x).
It is only a problem of spatial interpretation (grid interface construction when need), the base32 geocode existense is independent of a visual grid interface.
The text was updated successfully, but these errors were encountered: