Closed thomcom closed 1 year ago
I would say this is true of all of our existing polygon APIs. e.g. polygon_bounding_boxes. Remind me again why Arrow needs n+1 storage for n items?
It stores the final "end position", instead of letting the user assume that it is "length of data buffer offsets refer to minus the size of the final offset". This makes it so that special logic is not required for the end segment when iterating, but that's as much as I can guess why.
This is closed by #973
Closed by #973
Is this a new feature, an improvement, or a change to existing functionality?
Improvement
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem you would like to solve.
point_in_polygon
was written beforeGeoArrow
. It's offset buffers are only lengthn
for a Feature withn
geometries, butGeoArrow
has the tailn+1
offset. We need to updatepoint_in_polygon
to matchGeoArrow.
Describe any alternatives you have considered
No response
Additional context
No response