polygonToCells: validity of polygons about h3

[michaelbrichko]

although there is a sense\value in result of some simple invalid polygons I've tested, my concern is of undefined behavior

[nrabinowitz]

It's a good point. In general, the H3 library has erred on the side of less validation, unless invalid input is easy to identify or dangerous from a perspective of memory access/security/etc. The principle here is that our job is to be fast, and the user may or may not desire validation instead of speed. As a result, many of the H3 functions have a garbage in, garbage out approach, and to avoid this the caller needs to perform their own validation as appropriate.

This applies for polygonToCells. Our output tends to be reasonable for unreasonable shapes (interiors are usually filled, following an even-odd fill rule, holes are removed, regardless of self-intersection), but we can't guarantee that the output in these cases matches your expectations, and to your point we do not guarantee that it will be stable from version to version. If you want to disallow these shapes, you'll need to pre-filter them before sending them to polygonToCells.

[michaelbrichko]

Thank you! Perhaps the validity checks can be an optional flag in "polygonToCells" arguments.... The reason for this would be internal pointInPlygon check (inside polygonToCells) that may perceive polygon differently than the outside world, in terms of edges (planar\geodesics), precicion, borders inclusion ....