Add bidirectional edge mode

[nrabinowitz]

It occurred to me that it would be trivial to add a bidirectional edge mode (I would have preferred "directed" and "undirected", but we already have "unidirectional"), just by taking the unidirectional edge of the lower H3 index in a given pair of cells. I don't have use cases in mind yet, but it seems like a useful primitive, and it's simple to implement on top of the unidirectional functions.

If we had a more efficient version of getH3UnidirectionalEdgeBoundary this might allow an even simpler optimization for h3SetToLinkedGeo than vertex mode.

[dfellis]

Yep! Making the smaller index the first one is a good solution. Validating these bidirectional edges should also mark an inverted form as invalid.

A more efficient uni/bidirectional edge also would need to understand icosahedron face IJK rotations to determine the proper direction number when dealing with hexagons on the "edge" (which will depend on the res 0 parent owning icosahedron, not the icosahedron it is physically on).

Given those complexities I am not convinced a more efficient algorithm would be significantly more efficient.

[nrabinowitz]

Given those complexities I am not convinced a more efficient algorithm would be significantly more efficient.

True, but I'm actually more concerned about correctness. I don't think the current geoAlmostEqual approach will hold up at fine resolutions, where neighboring vertices falsely appear equal, or possibly at coarse resolutions, esp. near pentagons, where distortion might push vertices further apart than the threshold.

I don't actually think bidirectional edges will work in h3SetToLinkedGeo, because I would have trouble walking the graph if it wasn't keyed to the vertices - the optimization I have in mind probably still requires vertex mode. But it still seems like it's probably worth adding nonetheless.

[nrabinowitz]

This would now be called edge