search

uber / h3-js

h3-js provides a JavaScript version of H3, a hexagon-based geospatial indexing system.
https://uber.github.io/h3
Apache License 2.0
873 stars 79 forks source link

Incorrect result from polygonToCells for bigger screen/ higher dimensions #180

Closed himanshupareek closed 1 year ago

himanshupareek commented 1 year ago

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/

image

Received H3Cells:

Screenshot of Kepler:

image

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

nrabinowitz commented 1 year ago

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 commented 1 year ago

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

himanshupareek commented 1 year ago

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

indus commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@nrabinowitz thanks for that explanation.