What problem do the distortion verteces solve ? Why are they there/necessary ? Better/more clear explanation desired...

[SkybuckFlying]

Introduction:

UBER H3 pentagons/hexagons/polygons sometimes have 5,6,7,8,9,10 verteces, so they can be weird. These additional verteces are called "distortion" verteces.

The UBER H3 library seems to inject them across/on top of edges as illustrated/described by a few postings, examples are:

https://stackoverflow.com/questions/60727617/how-many-possible-h3-geoboundary-vertex-configurations-are-there
https://observablehq.com/@nrabinowitz/h3-index-inspector#85080013fffffff
https://observablehq.com/@nrabinowitz/h3-index-inspector#85080003fffffff%0A%0A
https://observablehq.com/@nrabinowitz/h3-index-inspector#cell-428

Also other github uber-h3 issues:

#755 (comment)
#760

The explanation given for the distortion vertices from the first link is:

"At odd resolutions, cell edges that cross an edge of the icosahedron will have additional distortion vertices added to account for the change in projection plane (at even resolutions, the cells are aligned with the icosahedron edges and do not require this)." by nrabinowitz on Mar 17, 2020 at 20:17

I don't quite understand this explanation, I don't understand projection plane entirely, or maybe I do a little bit.

I thought I saw more documentation about this somewhere, I think it mentioned that it also effects to coordinate system ? Though I am not sure, maybe I imagined it.

So here is the deal/questions:

1. Why are these distortion verteces necessary ?

2. What problem do they solve ?

3. What would happen if they are left out ?
   3.1 Would it cause coordinate issues ?
   3.2 or indexing issues ? For example Lattitude Longitude to Index or visa versa ? Or H3 coordinate to something else or vice versa ? Could it happen that it ends up on the wrong polygon or index or something like that ? Could it give wrong coordinates ?

4. Might it be possible to leave out these distortion verteces for algorithms that might be effected by it ?

5. Maybe modify the UBER-H3 implemention to make distortion verteces optional ? Maybe not all applications require these distortion verteces and could do without it ?

Some more clearification on this, plus maybe examples of what would go wrong without these distortion vertices would be much appreciated !

[dfellis]

Why are these distortion vertices necessary?

H3 projects the world onto an icosahedron, and then each icosahedron face is assigned a set of hexagons and pentagons, where only 4 of the hexagons are fully contained by the icosahedron face, 3 of the hexagons are split in half and shared with the icosahedron triangle face it borders on a side with, and 3 pentagons split into 5 pieces and shared with the icosahedron triangle faces that borders each of the triangle's vertices.

The places where hexagons / pentagons cross the icosahedron boundary are where distortion vertices are inserted. Where they intersect with an icosahedron edge is determined primarily by whether or not the particular resolution is in a "Class II" or "Class III" orientation, which H3 alternates between by resolution in order to pack 7 hexagons within a single parent.

Class III hexagons and pentagons have more distortion vertices on the edges than Class II, in general, because they are less aligned with the icosahedron face geometry.

What problem do they solve?

H3 projects the earth from a near-perfect sphere to an icosahedron, AKA a D20 die.

So there will always be distortion. The projection mechanism H3 uses is the gnomonic projection system.

As you can see, this gets very distorted far away from the origin (in this image the axial north pole), but is relatively distortion free in the center.

But if each icosahedron face has a separate gnomonic projection centered on its own face's center, you get a map that has very low distortion. The so-called "Dymaxion projection"

This is what H3 uses to minimize the distortion to the map -- but that distortion is not zero.

You can think of a hexagon crossing the boundary to be two hexagons of the same area but stretched in different directions being cut in half and then each half glued together, as you can see in the hexagon just off the coast of Norway that I have hand-edited with the line it's crossing.

What would happen if they are left out?

Depending on your use-case, nothing at all, or misreading of the data.

If you're just trying to visualize the hexagons on a map and you have a pretty dense set of them, leaving them out will speed things up and generally not be perceptible. That's what deck.gl does when you turn highPrecision off

But when you index data, these distortion vertices are used as part of the containment of the point -- not because it's doing a point-in-poly operation with them, but because if the point falls on one side of the icosahedron versus the other, it will get a gnomonic projection with one origin versus another, and so the containment for the shared hexagon will warp with the projection change.

If you plot the hexagon and all of the points you have indexed with it and leave out the distortion vertices, you may see some of the points fall outside of the hexagon, or may see points that appear to belong inside of the hexagon to not be present. At a large enough level, that "point" may be an entire building, so these distortion vertices also matter more with the lower resolution H3 cells.

Might it be possible to leave out these distortion vertices for algorithms that might be effected by it?

That already exists. cellToVertexes returns only the 5 or 6 "primary" vertices without the distortion vertices as you can see here when I feed in the distorted cell I showed earlier.

But this produces "vertex IDs", not lat, lng coordinates, so you also need to pass those IDs to vertexToLatLng to get the coordinates you want.

This is not the main path because it is less accurate, but it's already there, so I don't think H3 needs to be modified to support a less-accurate version.