-- Leo's gemini proxy
-- Connecting to gemini.circumlunar.space:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
I had a lot more thoughts about H3 that I wanted to explore, but I had a hard time putting them into words. So instead here are just some images of other ways that a hierarchical hex grid could be structured.
Here's an example of how these images are composed. The large blue hex shows one hierarchical level of resolution and the smaller gray hex is one level hierarchical level below the blue hex. The size of the gray hex will vary depending on the hex layout.
One of the suggested ways to use H3 is to use hexes of different resolutions to fill space efficiently. For example, if you have a shape that looks like California, you can fill most of it with a few very large hexes, then fill in around the edges with some smaller hexes, and fill in more edges with even smaller hexes, and so on until you've filled as much of the shape as you want.
The piece that I felt was missing from this suggestion is what to do with the little edge bits that don't line up across different resolutions. If you have two adjacent hexes of one resolution, and you "break down" only one of those hexes into smaller hexes, then some of the smaller hexes overlap with the larger hex next to them. And there are some areas that aren't covered by hexes in either resolution.
The example image below doesn't make this entirely clear, but I'm not going to redo the images now. Imagine that the blue hex has been removed and replaced with the gray hexes. Imagine that there are additional blue hexes adjacent to the one in the image. Some areas would be covered by both gray and blue, and some areas would be covered by neither.
To phrase the situation in a different way, if you look at the hierarchical path of "parent" hexes for a point, there are some areas where the parents will change depending on the grid resolution.
So, I guess my interest was whether there was a different layout where the "limbo" regions could be handled more formally. In the H3 layout, they are oddly shaped leftovers. I thought it might be possible to make them more regular— like half a hex instead of a tiny sliver—and then define those areas in a formal way depending on the resolution of the surrounding hexes.
I didn't come up with any satisfying answers, but I made a few different hex layouts.
I noticed three reliable ways to make a hex layout. There might be more. I'm defining them in terms of what happens at the center point of the parent hex.
Center — The center point of the parent hex is identical to the center point of a child hex.
Edge — The center point of the parent hex is in the middle of an edge of two child hexes.
Corner — The center point of the parent hex is at the corner of three child hexes.
I tried a few different scaling ratios. In H3, each hex is split into seven hexes at each lower resolution, so you could call this a 7:1 ratio. I found working ratios at 3:1, 4:1 and 9:1. I failed to find working patterns at 2:1. I didn't explore any other ratios.
At each of these ratios where I found any patterns, I was able to find a Center, Edge and Corner configuration.
The only 3:1 patterns I could find require a ±30° rotation at each resolution. This is aesthetically unsatisfying for me, but despite this I think that the 3:1 corner-based pattern is one of the appealing systems because of its simplicity and relatively small "limbo" area.
4:1 patterns have a data-packing appeal. Each smaller resolution requires two bits of data to identify all the hexes in an area. For example, if you start with 4 hexes (2^2 hexes), the next resolution would have 16 hexes (2^4), then 2^6, 2^8 and so on. So if you are using a binary addressing scheme, you can use exactly two more bits for each level of resolution, with no unused values.
H3, in contrast, uses three bits per resolution level. The 000 value (or 111? I forget which) is unused for addressing, so the data takes up about 14% more bits than it "needs" to. This isn't a big deal, but it's still interesting.
I'm not really interested in 9:1 patterns. They have poor data-packing efficiency and the patterns don't appeal to me. But I found them, so here they are.
The center-based patterns feel the most intuitive across multiple levels of resolution. The center of any parent hex shares a center point with one hex at each smaller resolution, so it acts as a kind of anchor point.
The H3 hierarchy is, of course, a center-based pattern, so it shares this property.
An early thought was that the 4:1 center-based pattern could work well: one hex surrounded by 6 half-hexes. It feels easy to define, and this exactly fills a parent hex, with no gaps or overlaps.
The complication is that each of those half hexes is technically one full hex if you look at more than just one parent hex. So which parent does each hex belong to? Is there any way to assign an address that preserves the split nature of these hexes? I didn't find any solution that I was satisfied with. For the images above, I placed the full hexes in locations that allowed the pattern to tile properly. This allows a technical solution: just like H3, some areas of a parent hex are within its child hexes and some aren't. That's the solution I was trying to avoid, though, so I'm not satisfied with it.
Edge-based patterns have mirror symmetries at 90° angles. When I tried fitting these patterns into a triangle—like the panels on a icosahedral globe projection—the edges were kind of a mess. Maybe these patterns would work better with a cubic globe projection or a flat map.
For the same reason, I think, these might work better for the rectangular grids that I wrote about in the previous entry.
I don't have any particular comments about corner-based patterns. They lack the "anchor" of center-based patterns, which is a big detriment, I think.
Despite this, the 3:1 corner-based pattern has a minimalist simplicity that I might revisit sometime.
I was kind of hoping to define a whole system, analogous to H3, but with some variations, just to see what it might be like. But I've run out of motivation at this point, so I'm dropping it here.
emptyhallway
2021-10-30
-- Response ended
-- Page fetched on Thu May 2 10:21:25 2024
