Expose icosahedron faces, base cell mapping, and IJK orientation?

[dfellis]

I've been thinking a lot about the various corner cases (no pun intended) the various algos have run into with pentagons where the triangles corners meet.

I think it would be a useful debugging tool (and a useful teaching aide, as well) if the 20 icosahedron faces could be exposed from the API with their coordinates and orientations (perhaps the orientation implicit from the coordinates, first pair being the furthest in the I direction, next furthest in the J, last furthest in the K?).

It would make it easier to see what coordinate orientation changes are required to transition "through" a pentagon and how there are a few different rules depending on which icosahedron you're transitioning from (since as I recall, 5 of the faces have all of their I directions meet at the same point near the north pole, another 5 have the I directions meet at the same point near the south pole, and an equatorial-like ring of 10 triangles have alternating orientations for the I direction, leading to 2 or three sets of icosahedron points when grouped by which orientations for each face are "pointed at" that point.

Functions like that could help with figuring out the h3Line issue, for instance (perhaps this only occurs at some pentagons and not others, and these things could help us figure out why), and could also help out with the occasional bugs that have cropped up across edges in the shared hexagons (should they have two icosahedron face parents)?

Its unclear to me if the H3Index should have a new mode to declare them (perhaps? h3ToParent on a base cell could return a value that way).

Something I've been thinking about since I feel half or more of the issues with the algos hitting pentagons is due to it not being clear in our minds how the coordinate orientations are being changed.

[isaacbrodsky]

I think it would be a useful debugging tool (and a useful teaching aide, as well) if the 20 icosahedron faces could be exposed from the API with their coordinates and orientations ...

I agree this would be useful as a debugging, development, and teaching tool. I'm unsure of the purpose of exposing it as part of the "public API", since it seems it would not be useful to application developers.

Its unclear to me if the H3Index should have a new mode to declare them (perhaps? h3ToParent on a base cell could return a value that way).

This seems like trying to fit this into an unrelated structure/function because that structure/function already exists.

Something I've been thinking about since I feel half or more of the issues with the algos hitting pentagons is due to it not being clear in our minds how the coordinate orientations are being changed.

I agree orientation changes are one of the trickier parts we have to handle, I would also note that the deleted subsequence in the pentagon cells has come up quite a bit (and appears to be related to odd behavior with h3Line.)

[dfellis]

I think it would be a useful debugging tool (and a useful teaching aide, as well) if the 20 icosahedron faces could be exposed from the API with their coordinates and orientations ...

I agree this would be useful as a debugging, development, and teaching tool. I'm unsure of the purpose of exposing it as part of the "public API", since it seems it would not be useful to application developers.

I think there could be some benefits for users that really care about the potential distortions. Because of the Gnomonic projection centered on each icosahedron face the distortions are greatest near the corners of each face and so knowing where on each face a particular hexagon is located can help with analysis that does want to keep data density analyses perfectly uniform.

It's true that the orientation doesn't matter from that perspective, which is why I proposed that part can just be implied by the geofence point order.

Its unclear to me if the H3Index should have a new mode to declare them (perhaps? h3ToParent on a base cell could return a value that way).

This seems like trying to fit this into an unrelated structure/function because that structure/function already exists.

I'm not entirely convinced it's unrelated: Each hexagon ID is an identifier for a uniformly-divided region of the planet. The icosahedron faces meet that definition. They are not hexagons, but we already bent the rule on that with the 12 pentagons per resolution also having "hexagon IDs."

Something I've been thinking about since I feel half or more of the issues with the algos hitting pentagons is due to it not being clear in our minds how the coordinate orientations are being changed.

I agree orientation changes are one of the trickier parts we have to handle, I would also note that the deleted subsequence in the pentagon cells has come up quite a bit (and appears to be related to odd behavior with h3Line.)

That's also true, and I bet it's interrelated with the orientation changes -- the deleted subsequence requires going into a different direction than usual, but those new directions also have multiple "answers" on how the IJK coordinates get rotated depending on which pentagon you're talking about due to the differences between the "polar" and "equatorial" pentagons.

[nrabinowitz]

My $0.02 here:

• I don't mind exposing the icosahedron vertices, though it might be just as easy to do so with static data in KML (already in the repo) and GeoJSON (I have this and could add), and/or other formats.

• I'm really not a fan of extending h3ToParent to support icosahedron faces - this would be a major version change, and having a new mode seems like overkill, since that mode could only have 20 valid values and the number of modes available are limited. Better to simply add h3ToFace, returning an integer index.

[helloniuniu]

I suggest adding Face Numbers to the H3Index to reduce rotation and overage code.