Open mojodna opened 6 years ago
π Agreed, we can include flattenEach
from @turf/meta
when using the search
method.
By splitting the MultiPolygon
This shouldn't be applied to the initial loading of the FeatureCollection since MultiPolygon is treated as a single feature and not multiple features.
@mojodna If you feel like doing a PR, I can definitely help review it π
we can include flattenEach from @turf/meta when using the search method.
Can you elaborate a bit on this? It sounds like I can simplify the second block of code βοΈ by using that in the absence of a patch to search
.
This shouldn't be applied to the initial loading of the FeatureCollection since MultiPolygon is treated as a single feature and not multiple features.
Yup, that makes sense. I was realizing after I opened this issue that a side-effect is that the features that come out of the index aren't necessarily the ones expected.
I will try to find time to do a PR (π for the review offer), but I'm not sure I'll have time before disappearing again.
Sounds like a plan! π
I was thinking about this a bit more; I think the bulk of the performance improvement I'm seeing is actually related to intersecting against Polygon
s rather than MultiPolygon
s w/ martinez
. In other words, reducing the number of candidates is less helpful than considerations outside of this module's scope.
I'm using martinez to intersect features w/ candidates from rbush in order to do strict intersections:
COUNTRY_INDEX
is Natural Earth admin 0 boundaries, many of which areMultiPolygon
s that include territories. As a result, the bboxes produced for the USA, Canada, and Russia cover much of the world. By splitting theMultiPolygon
s into multiplePolygon
features, I get a substantial speed-up because fewer indexed features match:Doing this automatically within geojson-rbush seems like it would provide a transparent speed-up for those using
MultiPolygon
s.