Search code examples
h3

For imprecise geoquerying with H3, can we consider pentagons equal to hexagons?

  1. If we use the kRing(H3Index origin, int k, H3Index* out) function to get surrounding hexagons, and we're going to refine the results on the client (i.e. haversine), we never have to worry about pentagons, do we? Because, AFAIK, pentagons have H3 indexes also and are, for all intents and purposes, treated just like hexagons, correct?

  2. It is the hexRange(H3Index origin, int k, H3Index* out) function that cares about pentagons, correct?

Solution

  • For some intents and purposes, yes, pentagons are simply hexagons with one axial dimension removed. They have a normal H3 index representation, will work correctly with most functions that take H3 cells as input, and should be fine in the case you describe. The main considerations are:

    • They only have 5 neighbors, so any code assuming six neighbors may be incorrect
    • They return 5 vertices from h3ToGeoBoundary, or 10 vertices for odd resolutions (to account for distortion at the icosahedron edges)
    • They have approximately 5/6 the area of the smallest hexagon cells.
    • If you encounter a pentagon when running kRing, you can no longer make any assumptions about the shape of the returned set - e.g. you may have fewer cells in a different arrangement than you would if you only encounter hexagons.
    • Some functions (hexRange, hexRing, and a few others) will fail with an error code if they encounter a pentagon. hexRange in particular is a fast kRing algorithm, which kRing uses under the hood, falling back to a slow-but-correct algo if a pentagon is encountered. You should only use hexRange if performance is very important and you're willing to handle failures. Functions that do not handle pentagons are generally clearly specified in the docs.