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
After some more looking into this, using the same approach as used in erase doesn't seem possible.
For erase/difference, the first input layer is conceptually looped row per row and for each row and typically many small (or large) geometries need to be subtracted from each element it in one operation, especially for large geometries. In this case there is a "hook" in the sql statement to tile the large geometry once for each row which than speeds up the many subtracts that need to be done.
For intersection this is slightly different: the inner join leads to the intersection having to be calculated individually between each row of the first layer and the 2nd layer... so there is no obvious central point to tile large geometries once to be able to speedup the many subsequent intersections.
Maybe it is possible virtually creating this using a WITH table first or something like that... to be tested.
Optimised version can be used in several operations:
intersection
,split
,...Similar to the improvement implemented in erase: #329, #330
The text was updated successfully, but these errors were encountered: