Open nrabinowitz opened 5 years ago
I asked the previously linked question, though this time I'm looking for another use case for this feature. I want to create (static, non-moving) geofences and test if a moving location (position coordinate) is inside a one of the fences.
This requires to create an index for cells which might also wrap around the 180 degree mark. Can you suggest a workaround without this bboxFill implemented?
bboxFill
as described here shouldn't be necessary for anything - it's just an optimization on top of polyfill
.
For your use case, which is basically an optimized point-in-polygon check, you can:
polyfill
to get the set of hexes for each geofence. This should be fine unless your geofences themselves have an arc > 180 degrees (i.e. the geofence covers more than half the world in longitude).h3Index : polygon
mapping somewhere. A key-value store (e.g. Redis) is nice for this. You'll need to use a resolution fine enough so that you don't care about the margin of error around the polygon edges.Does that fit your use case?
Filling a bounding box with hexagons currently requires
polyfill
, which does an additional point-in-poly check that shouldn't be necessary for bounding boxes. If the use case is common enough, we ought to be able to provide abboxFill
function that would be faster for just filling bboxes. The case that's come up a few times here is getting all of the H3 indexes within a map viewport.Additionally,
bboxFill
could handle bounding boxes wider than 180 degrees longitude, a current restriction ofpolyfill
, because we'd have an explicit east/west signal.