Bad indexation using h3Line about h3-js

[dfellis]

I believe h3Line draws from the centerpoint of the h3Indexes that your own points are located in (as it does its work in an IJ coordinate space). I can't see the other points in your screenshot, but the one I do see if very off-center in the hexagon it is located in.

This effect is minimized the smaller the resolution, but it would still be there.

Also, while I don't think this is important at the zoom level this polygon is at, the hexagons are tracing the polygons via greater circle arcs on a sphere, while you're showing a mercator projection map, so places very far to the north or south will have projection distortion that causes the h3line to appear curved on mercator projections at long distances.

[nrabinowitz]

This is expected behavior. h3Line gives a grid-based path from the origin to the destination; the only guarantees it offers are:

• The path will be the shortest grid distance (i.e. the fewest number of cells)
• Each cell in the sequence will be a neighbor of the previous cell
• No cell in the sequence will be the neighbor of both of the two previous cells (i.e. no "bunching")

It's not expected to align exactly with either a Cartesian line or a great arc, and as in this example the corresponding polyline may not be covered. If you need to cover the polyline "perfectly" (polyline completely covered, no cells that don't intersect the line), the best option is probably:

• Create a set of H3 indexes
• Sample down the line, getting the H3 index for each sample. You could use h3.edgeLength as a possible basis for sampling.
• Take kRing(sampleIndex, 1) and add that to the set. That's effectively buffering the sample by one cell.
• Test each cell in the set for line intersection.

You may be able to use h3Line instead of sampling (should be fine for relatively short polylines, where the difference between Cartesian and spherical geometry is negligible), but you need the buffering and intersection check to ensure that you're including cells with only a small amount of intersection.

FWIW this is very similar to the new approach to the polyfill algorithm, and it might eventually be something we'd add to the core library.