cellToBoundary sometimes returns structures with numVerts set to 7 instead of 6 ??? depending on resolution.

[Skybuck Flying]

Sometimes cellToBoundary returns a structure with numVerts set to something higher than 6, it seems to be 7.

This is especially noticeable on higher resolutions, like 1 and 2.

These "special" cells seem to form a star across the globe and such.

Why is this ? Is this a bug ? This is causing some visualization issues for me...

I show two screenshot examples at bottom of post. Second screenshot shows what happens if my code tries to visualize the cells with 7 vertices instead of 6. (Current visualization code computes mid point on edge and draws lines from center to midpoint, the white lines, the gray lines are the cell borders, the black lines are incorrect...)

(* * @struct CellBoundary
  @brief cell boundary in latitude/longitude
*)
CellBoundary = record
	/// number of vertices
	numVerts: Integer;
	/// vertices in ccw order
	verts: array [0 .. 9] of LatLng;
end;

	cellToBoundary
	(
		H3Index(vH3Index),
		@vCellBoundary
	);

Resolution 3 example, ignoring cell boundaries with 7 vertices:

Resolution 1 example: trying to draw cells with 7 vertices with standard code, leads to troubles:

[Skybuck Flying]

The issues seems to be much more severe, according to this thread:

https://stackoverflow.com/questions/60727617/how-many-possible-h3-geoboundary-vertex-configurations-are-there

Original Question:
"

When getting the vertices of an H3 cell using H3toGeoBoundary, how many possible vertex configurations can the GeoBoundary struct produce? I count four:

6 vertices: regular hexagon
5 vertices: regular pentagon
7 vertices: irregular hexagon (https://observablehq.com/@nrabinowitz/h3-index-inspector#85080013fffffff)
10 vertices: irregular pentagon (https://observablehq.com/@nrabinowitz/h3-index-inspector#85080003fffffff%0A%0A)

Is this list exhaustive or can other configurations exist? Would it also ever produce 0?
"

Reply to Question:
"
Your list is missing the 8 vertices case. Rather than using the generic term "irregular", it's more accurate to consider extra distortion vertices: 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). With that explanation, the list looks like this:

5 vertices: even-resolution pentagon cell ([8408001ffffffff](https://observablehq.com/@nrabinowitz/h3-index-inspector#8408001ffffffff))
6 vertices: standard hexagon cell ([85283473fffffff](https://observablehq.com/@nrabinowitz/h3-index-inspector#85283473fffffff))
7 vertices: hexagon cell with an icosahedron edge crossing one vertex and one edge ([85080013fffffff](https://observablehq.com/@nrabinowitz/h3-index-inspector#85080013fffffff))
8 vertices: hexagon cell with an icosahedron edge crossing two edges ([850802a3fffffff](https://observablehq.com/@nrabinowitz/h3-index-inspector#850802a3fffffff))
10 vertices: odd-resolution pentagon cell ([85080003fffffff](https://observablehq.com/@nrabinowitz/h3-index-inspector#85080003fffffff))

Note that we still use "pentagon" and "hexagon" to describe these cells, because that's still topologically correct (a pentagon always has 5 neighbors, a hexagon always has 6).
"

This should have been explained in the documentation of Uber H3, so I would have know about it, before using Uber H3...

So far for me it hasn't caused major issues, but now it has... I can imagine this might drive other users crazy and believing they might have some bugs in their own code.

Anyway...

How are these special cells supposed to be visualized ?! and how are they suppose to look like ?!?

Apperently they look like normal hexagons and normal pentagons, but just have some secret extra little verteces among their edges ?!

Because that is what my black lines seem to indicate ?!

Is this really necessary, these extra verteces ?! It seems to be a very minor minor minor issue so far ?! and might be causing more trouble then it's worth it ????????????????????????????????

[Skybuck Flying]

After implementing this color function it's starting to shine some more light on the situation, see screenshot below, showing the strange/secret/hidden verteces (sort of, the mid points are computed between them):

function MakeColorBasedOnNumberOfVerteces( ParaNumberOfVerteces : integer ) : TColorVec;
begin
case ParaNumberOfVerteces of
0 : result := MakeCellColor( 10, 10, 10 );
1 : result := MakeCellColor( 20, 20, 20 );
2 : result := MakeCellColor( 30, 30, 30 );
3 : result := MakeCellColor( 40, 40, 40 );
4 : result := MakeCellColor( 50, 50, 50 );
5 : result := MakeCellColor( 60, 60, 60 );
6 : result := MakeCellColor( 255, 255, 255 );
7 : result := MakeCellColor( 0, 0, 255 );
8 : result := MakeCellColor( 0, 0, 128 );
9 : result := MakeCellColor( 0, 255, 0 );
10 : result := MakeCellColor( 0, 128, 0 );
else
result := MakeCellColor( 255, 0, 0 );
end;
end;

[Skybuck Flying]

Resolution 2 behaves weird:

Some cells have 8 center to center lines huh ? but they still show up white huh ?!? I am confused...

[Skybuck Flying]

I am trying to make sense of the above picture. My program was performing a second loop, and re-draw all cells twice, but that doesn't matter much... with loop disabled and edge colors being visualized and making the edges smaller/bigger/whatever to see them individually, the result is as follows.

I don't quite understand why there appear multiple center lines, it's weird...

Again resolution 2, same zoom in...

[Skybuck Flying]

The double white lines, might be explained by the CrossTrackDistance function, ignore center to midpoint or something and instead going from mid point to mid point or something... strange...

At least this visualization now colors the center lines too..

Coloring code is:

function MakeColorForEdgeNumber( ParaEdgeNumber : integer ) : TColorVec;
begin
case ParaEdgeNumber of
0 : result := MakeCellColor( 255, 0, 0 );
1 : result := MakeCellColor( 0, 255, 0 );
2 : result := MakeCellColor( 0, 0, 255 );
3 : result := MakeCellColor( 255, 255, 0 );
4 : result := MakeCellColor( 0, 255, 255 );
5 : result := MakeCellColor( 255, 0, 255 );
6 : result := MakeCellColor( 255, 255, 255 );
7 : result := MakeCellColor( 128, 128, 128 );
8 : result := MakeCellColor( 64, 64, 64 );
9 : result := MakeCellColor( 32, 32, 32 );
else
result := MakeCellColor( 2, 2, 2 );
end;
end;

[Nick Rabinowitz]

I agree that we need more prominent documentation for this. You can see the explanation here: #755 (comment)