Ideas around 32-bit H3 indexes

[rustyconover]

I really like the H3 library and I'm thinking of integrating it into my application.

The databases I'm looking at using prefer values to be 32 bits or shorter in precision for range indexes. Specifically I'm thinking about the RTree extension to SQLite to index a range of H3 index values.

Is there a recommended way to truncate a H3 index to a fixed bit width resolution?

[nrabinowitz]

The recommended storage/data interchange approach is to use hexidecimal strings - this is the most portable representation of an H3 index, and generally a good idea if you're using H3 indexes across different components or services.

I'm not certain you'd get a lot of value out of a range index, as H3 indexes are not strictly in order (see this StackOverflow question. But if you really wanted to, you could devise a non-standard 32-bit truncated version. The structure of the index is outlined in the docs - you could use:

• 4 bits to indicate the cell resolution 0-15,
• 7 bits to indicate the base cell 0-121, and
• 3 bits to indicate each subsequent digit 0-6 from resolution 1 up to res 7

4 + 7 + 3 * 7 = 32 (math!), so you could technically store an index of known mode and resolution 7 or coarser in 32 bits, then rehydrate it to a full 64-bit index for later use. But TBH this is a bit of a thought experiment, and I can't really recommend it unless there's a very strong reason - among other things, the rehydration cost might overweigh any other perf gains you'd see.

[nrabinowitz]

Closing, as this is more appropriate as a StackOverflow question than a GH issue (primarily for bugs and feature requests)

[rustyconover]

@nrabinowitz Thank you for your reply. You did a great job answering my question.

You're absolutely right that range indexing may not be the most optimal to due to the index values not being numerically ordered. The same problem exists even with Morton encoded values.

3 bits to indicate each subsequent digit 0-6 from resolution 1 up to res 7

I've read that sentence often in the docs often. It might be made more clear to state that for resolution 1, the first 18 bits are used 3 bits for each digit, then each resolution level beyond 1 utilizes an additional three bits. Is my understanding incorrect?

Also if every index value is the same resolution, you can drop the first four bits. So it hypothetically resolution 8 able to be achieved in 32 bits.