uber
polyfill fails when longitude points exceed 180 degrees
I have seen this issue alluded to in several places now, but couldn't find a specific ticket for it (so here it is).
When the bounding points passed into the polyfill function exceed 180 degrees on the longitude, the returned indexes are invalid.
To be clear, is the issue:
- You have a small polygon that crosses the antimeridian with points outside the
-180 - 180range, or - You have a polygon with edges > 180 degrees of longitude, which may or may not cross the antimeridian?
...the returned indexes are invalid.
Do you mean actually invalid (they're not valid indexes in the grid, and don't pass h3IsValid), or just not what you were expecting for output?
If you could include the polygon you're using and what output you expect, that would be helpful. Note that polyfill explicitly does not support the second case here - we disallow arcs > 180 degrees, treating them as wrapping the other way around the globe.
Its the second case where my lat/lon dataset might look like this:
[{45, -100}, {90, 0}, {45, 100}, {-45, 100}, {-90, 0}, {-45, -100}]
I would expect the response to be the H3 Indexes "inside" the shape - which is currently not the case.
As I said above - I have seen it mentioned that this does not work when the longitude points exceed 180 degrees (and I can understand why that may be the case), but as it stands its not working as advertised in the docs: https://uber.github.io/h3/#/documentation/api-reference/regions - hence this report here (if only to help the next person who hits the problem).
Looks like we need to update the docs to reflect the implementation - I thought the 180 degree constraint was in the docs :(.
The challenge here is that we have to either disallow arcs > 180 degrees or require that input follow a specific winding order. We chose the former, but it's worth discussion in the next major version.
What is the current workaround for this issue?
The best workaround I'm aware of is to divide your input polygon into multiple sub-polygons by longitude, and fill each one separately.
In my experience, imposing a winding order is pretty common. Here is a description of why it's the recommended default in GeoJSON - https://macwright.com/2015/03/23/geojson-second-bite.html#winding
Granted, the discussion presents the advantages in terms of calculating polygon areas and not as a solution to the 180 degree meridian problem. But as a data point for you to consider, when I encountered the issue in this thread, my first assumption was that I had the winding order wrong in my polygon.
Thanks for your work on this library.
