Skip to content
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

Open
ppKrauss opened this issue Oct 17, 2018 · 1 comment
Open

Add base32 is possible #4

ppKrauss opened this issue Oct 17, 2018 · 1 comment

Comments

@ppKrauss
Copy link

ppKrauss commented Oct 17, 2018

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.

@gus-maurizio
Copy link

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants