Incorrect result from polygonToCells for bigger screen/ higher dimensions

[himanshupareek]

Hi team,

For bigger screens (4k resolutions -> 2560 px), this method polygonToCells is responding with wrong H3 Cells ( We are just getting bounding box as input and converting that into polygon and passing within this method to get the H3 Cells).
While we are expecting the data for Europe, Africa, Middle East etc, it is responding with opposite area's H3 Cells (North America, Japan, China etc..)

This issue starts from the resolution 2105 px. Before that till 2104 px everything works as expected.

Requested Bounding box:

15.203087,-109.629878,72.791223,110.448247 (Lat/lng)
-109.629878,15.203087,110.448247,72.791223 (Lng/Lat)

Bounding box representation on third party site - http://bboxfinder.com/

Received H3Cells:

Screenshot of Kepler:

Please let us know if you can help us on this issue. Its a bit urgent!! Thanks.

[nrabinowitz]

This isn't related to screen resolution, but to the width of the bounding box. If your polygon has an edge that crosses more than 180 degrees of longitude, we use the smaller interpretation (the alternative was to require a particular winding order, which is tricky because there isn't one standard).

To work around this limitation, break large bounding boxes horizontally into two separate boxes with less than 180-degree widths.

[himanshupareek]

Thanks @nrabinowitz , I will check and will confirm here, if that works for me, thanks.

[himanshupareek]

The suggested solution worked, so I am closing this ticket. Thanks @nrabinowitz for quick support.

[indus]

the alternative was to require a particular winding order, which is tricky because there isn't one standard

Are you refering to GeoJSON? Because rfc7946:

Polygon
A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise.

I think at least when isGeoJSON is set to true polygonToCells should not use an interpretation.

[nrabinowitz]

the alternative was to require a particular winding order, which is tricky because there isn't one standard

Are you refering to GeoJSON? Because rfc7946:

Polygon
A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise.

I think at least when isGeoJSON is set to true polygonToCells should not use an interpretation.

No, I'm referring to geospatial formats in general - see e.g. the discussion here. ESRI Shapefiles and other formats use clockwise order for external rings.

The choice about winding order enforcement is made in the core H3 library, not h3-js, and the core library has no idea of GeoJSON or other formats as input - it specifies an input shape with lat,lng coordinate order and no predefined winding order. The h3-js library, and the Python bindings, offer some GeoJSON support specifically to allow input in lng,lat order (still passed to the core lib as lat,lng), but the isGeoJSON flag in the bindings isn't going to affect core library processing.

[indus]

@nrabinowitz thanks for that explanation.