1

  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?

lurning too koad
  • 2,698
  • 1
  • 17
  • 47

1 Answers1

1

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.
nrabinowitz
  • 55,314
  • 10
  • 149
  • 165
  • I really appreciate the caveats and thoroughness. For some clarity: should be fine or definitely would be fine? If all I ever do is get 1 k-ring around an index—which would always be on land as all pentagons are in water—I will always produce 7 indexes, correct? And no matter what resolution that k-ring is in, pentagons will always be in water, right? Beyond that, I care about nothing else. – lurning too koad Feb 29 '20 at 17:40
  • I said “should” because the use case wasn’t totally clear. Yes, you should be okay, though at coarser resolutions the pentagons will overlap land area. A k-ring of 1 will always return 7 indexes unless the origin is a pentagon. Ideally your code would still handle the pentagon case, you just won’t hit it often (maybe ever). – nrabinowitz Feb 29 '20 at 17:48
  • And finally, just as an aside, I assume the H3 library is relatively committed to? S2 appears to be completely abandoned (based on the repo on Github, anyway). Even if H3 stops growing, the existing code will always do the job for me, but it's nice to know what's going on behind the curtain. Is H3 expected to continue growing? – lurning too koad Feb 29 '20 at 17:57
  • 1
    There’s a team of ppl both inside and outside of Uber actively working on the next major version :). That said, I’d expect that we won’t be adding major new features within the library itself, which we consider largely feature complete. – nrabinowitz Feb 29 '20 at 18:00
  • I'm sure I speak on behalf of A LOT of programmers when I say how much I appreciate people like you and those working on H3. None of what I do would be possible without you and them, so MANY THANKS! – lurning too koad Feb 29 '20 at 18:02
  • Aw :). Thank you! – nrabinowitz Feb 29 '20 at 18:06