fix: preserve orientation properties of hilbert curve #7 #9
Conversation
|
Awesome, I'll give it a try tomorrow morning 👍 |
|
Works great for me! |
src/lib.rs
Outdated
| @@ -113,8 +114,7 @@ where | |||
|
|
|||
| let coor_bits = (core::mem::size_of::<T>() * 8) as u32; | |||
| let useless_bits = (x | y).leading_zeros() & !1; | |||
| let useful_bits = coor_bits - useless_bits; | |||
| let order = useful_bits; | |||
| let order = (coor_bits - useless_bits) as u8 + (order & 1); | |||
There was a problem hiding this comment.
Perhaps reword this as lowest_order? It won't be obvious unless reading our discussion that you are optimizing here by figuring out the lowest order that will produce the correct Hlibert curve.
Perhaps even in the README this could be explained? I think this is a motivating factor for someone to use your crate. For example:
let h = xy2h(3, 4, 63)
Saves a ton of computation!
If you're sorting GPS telemetry from all the phones in New Zealand, your lowest order will be similar to the specified order, thereby taking longer to compute the Hilbert location.
z25 x32924236 y21009587 h780201608115701
But... if you want a Hilbert location in Alaska at a High zoom, it should be just as fast as the location at a lower zoom.
z25 x2193040 y7118510 h27434051735036
A more extreme example:
z25 x5 y1 h56
Not fully ready to merge.
Update docs and double check implementation before merging