From Icosahedron to Base Cells.
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 6.5k
- Forks
- 627
- Avg merge
- 3d 21h
- Merged PRs (30d)
- 6
Description
What I find weird about Uber H3 is how it starts with 122 base cells, 110 of which are hexagons and 12 of which are pentagons.
Then the documentation mentions it's based on "icosahedron" which has 12 vertices and 20 triangles.
Now what I understand so far is that each of these vertices is surrounded by a pentagon which would mean 12 pentagons x 5 triangles = 60 triangles.
However these pentagons would probably not fit onto the sphere, not sure though.
Then Uber H3 states base cells 110 hexagons and 12 pentagons, so the number of triangles here would be: 110x6 + 12x5 =
660 + 60 = 720 triangles.
Trying to reason back to 20 triangles, where each triangle could be subdivided into 4 triangles would give:
720 / 4 = 180 first pass
or when can also use a different approach to figure out how many triangles the original 20 need to be split up into:
720/20 = 36
The second one was my initial reasoning.
Dividing 36 by 4 again would give 9.
And then one is stuck with 9 triangles, which cannot be divided by 4 anymore, so that would be weird.
Trying 180 next:
180/4 = 45
Again one gets stuck.
So it's hard to understand how the icosahedron triangles are turned into pentagons and hexagon cells and also how these are ultimately covered by triangles. (Plus uber h3 does some extra, it apperently rotates them as well by 19.x something degrees).
Anyway failing to reconstruct it myself/the idea time for some googling:
https://stackoverflow.com/questions/42069420/hexagonal-tilling-of-hemi-sphere/42093868#42093868
which also leads to here:
https://stackoverflow.com/questions/42069420/hexagonal-tilling-of-hemi-sphere/42093868#42093868
So the first link has a somewhat surprising solution, I don't quite understand it yet, I have seen it in Uber H3 videos or papers from others where instead of subdividing the triangle into perfect other triangles, it more or less creates some kind of lines inside of the triangle.
I think this is what Uber H3 is doing.
However on the math part, how does uber h3 go from 12 vertices + 20 triangles for icosahedron to 122 base cells ?
How many vertices does the resolution 0 contain ?
There are some formulas here:
https://h3geo.org/docs/core-library/restable
But they seem to start after the distribution has already taken place,. and it starts from resolution 0/base cells.
What is undocumented is how it gets from a icosahedron to the base cells.
I think this would be helpfull to understand Uber H3 better, especially when having to verify verteces on the sphere.
I also wonder if the rotating per resolution that Uber H3 does is necessary, or if a non-rotated version would also be interesting and if it's possible.
It might be easier to understand if it's not rotated. Perhaps if possible an option can be build into Uber H3 so that it doesn't rotate (?)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the H3 core-library resolution table and the existing documentation on icosahedron mapping and base cells, then review the linked Stack Overflow material. Done means documenting how the icosahedron leads to the 122 base cells, what resolution 0 contains, and whether per-resolution rotation is necessary or optional.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100