Shape distortion while using compact about h3-js

[nrabinowitz]

I think there's some confusion here about the nature of compact. The compact algorithm is essentially a data compression algorithm - it represents the compacted set in a compressed form, and can be used for efficient data storage/transfer of large areas, some lookup algorithms, etc. But the cells in the compacted set do not cover the area of the uncompacted set, as your image shows, because of the imperfect hierarchical containment of a hexagon-based grid system.

Whether and how this matters depends on your use case. If you want to see the exact area covered by the compacted set, you need to uncompact it, so compact is not a good optimization for display. But it can be very useful for data transfer, reducing memory consumption, and some lookup operations.

[dfellis]

There is another way to look at it :) We could consider only the Resolution 15 hexagons "true hexagons" and then Resolution 14 is collections of 7 hexagons packed together to looked approximately like the hexagon we render/present, and Resolution 13 is then 49 resolution 15 hexagons packed together, etc.

This perspective will produce perfectly contiguous compacted sets, but the boundaries of the hexagons above Resolution 15 are not truly hexagonal, but fractal approximations of hexagons.

This perspective is not actually supported by H3 at this time, since it's esoteric and confusing, and I can't think of any valid reason why you'd want it, except if you don't care about the shape of the hexagon and just want hexagon-ish shapes that perfectly subdivided like S2 cells perfectly subdivide. The only niche I can think of that would desire this is something that still wants k-ring style quasi-circular fast lookup, singular class of neighbors (all neighbors being equidistant from each other as measured by their centerpoints), and perfect subdivision for rapidly and accurately re-indexing between resolutions when some density threshold is reached.

But anyone needing those qualities can simply index always at res 15 and then simply truncate the lower bits to the desired resolution.

With respect to the visualization above, though, I would recommend uncompacting the set before displaying it, or mapping each hexagon via h3ToChildren to the minimum size and then h3SetToMultiPolygon to get GeoJSON in the fractally-hexagonal shapes mentioned above and then rendering those if keeping the "compactness" of the data present in the visualization is desired.

[mikecolonna]

Thanks @nrabinowitz @dfellis! Your insights have been very helpful. For our use case, we're going to move forward with using an uncompacted set of hexagons at resolution 10 for now, so as to minimize eng lift and ensure the entire area is covered. If this turns out not to be sufficient, we'll investigate higher resolutions and use compact as a way to compress these hexes across our pipelines.