Open vronizor opened 2 years ago
Shouldn't you use a planar CRS (eg 2263)? It looks like the difference is even greater then.
result = bench::mark(
check = FALSE, iterations = 10, time_unit = "s",
geos.dt(),
sf_4326(),
sf_2263()
)
result[, 1:6]
expression min median `itr/sec` mem_alloc `gc/sec`
1 geos.dt() 4.80 5.05 0.199 3.79MB 2.79
2 sf_4326() 2.62 2.79 0.351 6.61MB 0.351
3 sf_2263() 0.709 0.730 1.31 5.47MB 1.31
I'm also not sure that {sf}
and {geos}
work exactly the same way. geos_intersects_matrix()
expects STRTree
as the second argument and it takes the most time to convert to this type, but @paleolimbot will explain it best.
system.time(trips.dt2 <- as_geos_strtree(trips.dt[, o_geom]))
#> user system elapsed
#> 4.88 0.02 4.89
system.time(geos_intersects_matrix(zones.dt[, geom], trips.dt2))
#> user system elapsed
#> 0.14 0.00 0.14
Thanks for this!
I'm 99% certain that the difference is because of how accumulating potentially matching features (based on bbox) is implemented (in sf it's std::vector
and here I over-allocate an intermediary buffer that's way too big and I should just use std::vector
).
As per @paleolimbot 's suggestion, here is a reprex of a benchmark comparing spatial intersects with
sf
vsgeos
.st_intersects
does seem faster thangeos_intersects_matrix()
at the moment.Created on 2022-02-15 by the reprex package (v2.0.1)