Replies: 2 comments
|
I ended up buffering the target features by 2 * the average edge length of the hexagons given the resolution I was working at. Doubling may have been a bit excessive, but I wanted to err on the side of having too many covering hexagons versus not enough. Then I ran a spatial intersection and dropped any hexagons that didn't actually intersect the target features. Reference for average edge lengths here. |
0 replies
|
Uber actually merged "support for full containment and overlapping modes in polygonToCellsExperimental" (PR: uber/h3#796), back in November, but I'm still waiting for a release so I can include it in my bindings. I believe that will help with this specific use-case. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello friends!
I'm trying to use h3-pg to generate resolution-8 hexagons that fully cover U.S. states and territories. This is what my first attempt looked like using
h3_polygon_to_cells():Rather than covering the polygons, this seems to be intersecting hexagon centroids with the target geometries. (I think I just had the wrong understanding of how the function works.)
I'm wondering if this community can suggest a way to find the set of hexagons that...
ST_Extent)I ask this question so specifically because I tried using
ST_Extentbut it generates millions of non-intersecting artifacts, and the intersect + drop operation to remove them has been running for over 12 hours on my machine 😂 (even with a spatial index).It is potentially better to buffer the polygons rather than taking their extent? If so, how can I determine what buffer distance is guaranteed to cover the polygons for a given H3 resolution?
Thank you all in advance for any advice on this!
All reactions