polygonToCells: validity of polygons

[michaelbrichko]

Hi,
It seems that the function accepts invalid polygons, for example X-shape (edges cross one another) and inner rings cross outer ring. I would expect for the function to return error and not produce results. Is this behavior on purpose? Can this behavior change in future? Is there a support for such checks or should I perform such checks separately?

Tested on version 3.x.
Thank you!

[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 ....