-
Notifications
You must be signed in to change notification settings - Fork 4
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
Better tokens suggestion #11
Comments
Hi, an interesting idea. I’m not sure I see how shifting right will let you drop chars from the output token though, as the issue that prevents blind truncation is the trailing 1 bit that needs to be placed correctly. Without updating the trailing bit position, IIRC you end up with either invalid cell IDs or incorrect ‘parents’. See comments about trailing but here: https://docs.s2cell.aliddell.com/en/stable/s2_concepts.html#cell-id However, I think there may be some adaptation of this idea that could work. I haven’t figured it out, but it’d require converting a cell ID to a non-standard ‘truncatable cell ID’. You may also want to discuss this with the proper upstream S2 owners, rather than this derivative repo. |
The use of "hierarchical hexadecimals" with space-filling curves was illustrated here, selecting base 16h. To produce hierarchical S2 tokens, it is a two-step procedure:
The step1 is more than a bit-shift when dealing with a leaf cell, we need to transform (truncate) leafs to the level 29: Remember that in real life we never use less than 1 m², because it is GPS error, map error, etc. The step2 is not a direct 64bits positive integer conversion, I suggest to convert it into a bit-string. The trailing 1 bit is a "cut here for a bit-string representation". |
Would you be able to put together demo code of converting a cell ID to a truncatable string token using this method? I think I see now where you are heading, but this is also best addressed to the S2 mailing list since any different token spec would need wider discussion: https://groups.google.com/g/s2geometry-io?pli=1 |
Hi @aaliddell, good work! s2cell is a good project to test new efficient geocodes. This issue is a concept-proof suggestion.
As you say at s2-tokens,
Well, it's a "one bit problem", let's fix this bit! All the cell ID, except face prefix, is a good hiearchical code: each 2 bits (so base4 number) represents a hierarchical level... I think we can fix it by answering "Do we need all 32 bits for all applications?"
There are some application for the level30 bit? it is a cell of ~8 mm of side (0.008 m!)... Let's check a real life application, as addresses: the uncertainty ranges from 3 meters (urban areas) to 15 meters (rural areas), as illustrated below.
... So we can discard a bit! We can do a bitwise operation of rotate right in the 32 bits integer representation, interpretating it as a adding a 0-bit to the face, resulting in 4 bits instead 3 bits as face identifier.
Using your level-1 example,
00101100...000
, after rotate will be00010110...000
. Your level29 example,001011101...00100
, will be0001011101...0010
.We can encode/decode this cell ID representation (the "hierarchical token" - htk) to original token (otk) using rotate:
What do you think?
The text was updated successfully, but these errors were encountered: