You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering if we might consider having a way to apply a custom sort function for a node's children (sorted on insert/split/etc.) to help with ordering intersection points later on. Maybe this could be some kind of custom insert strategy or some hook where we could specify how nodes should be ordered?
I'd basically like to find all intersections (e.g., locate_in_envelope_intersecting) and iterate through them in a specific order. Right now I collect all the intersections into a temporary SmallVec/Vec sort that. It would be better if leaf nodes were already partially sorted, so that sort would be faster (e.g., many repeated calls to locate_in_envelope_intersecting would benefit from having sorted children stored on the nodes).
One place this would be useful is when checking for 2D geometry collisions, where it would be beneficial to iterate through the nodes with the largest area first for fine-grained intersection testing. The idea would be that I could test largest nodes first and exit early if there's a collision. The other nodes would still be loaded from the rtree but not tested.
I could also see it being useful to sort by custom priority/depth/elevation/etc. for some other use cases.
The text was updated successfully, but these errors were encountered:
I was wondering if we might consider having a way to apply a custom sort function for a node's children (sorted on insert/split/etc.) to help with ordering intersection points later on. Maybe this could be some kind of custom insert strategy or some hook where we could specify how nodes should be ordered?
I'd basically like to find all intersections (e.g.,
locate_in_envelope_intersecting
) and iterate through them in a specific order. Right now I collect all the intersections into a temporarySmallVec
/Vec
sort that. It would be better if leaf nodes were already partially sorted, so that sort would be faster (e.g., many repeated calls tolocate_in_envelope_intersecting
would benefit from having sorted children stored on the nodes).One place this would be useful is when checking for 2D geometry collisions, where it would be beneficial to iterate through the nodes with the largest area first for fine-grained intersection testing. The idea would be that I could test largest nodes first and exit early if there's a collision. The other nodes would still be loaded from the rtree but not tested.
I could also see it being useful to sort by custom priority/depth/elevation/etc. for some other use cases.
The text was updated successfully, but these errors were encountered: