Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

st_as_sfc.SpatialPoints relatively slow #2060

Closed
bart1 opened this issue Dec 14, 2022 · 2 comments
Closed

st_as_sfc.SpatialPoints relatively slow #2060

bart1 opened this issue Dec 14, 2022 · 2 comments

Comments

@bart1
Copy link
Contributor

bart1 commented Dec 14, 2022

It seems this function is relatively slow compared to creating a sf object from a data.frame. It takes about 6 seconds to convert 300000 points. The conversion through a data frame is considerably faster. I think this could be easily resolved by using points_cpp here:

sf/R/sp.R

Line 94 in 4f550e5

lst = lapply(seq_len(nrow(cc)), function(x) st_point(cc[x,]))
. I don't seem to be able to label this issue as an enhancement but it is very much meant like that and not a bug. If desirable I can create a pull request.

require(sf)
#> Loading required package: sf
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1; sf_use_s2() is TRUE
require(sp)
#> Loading required package: sp


a<-SpatialPoints(cbind(runif(300000),runif(300000)), proj4string =CRS( "+proj=longlat"))
bench::mark(st_as_sfc(a),
st_as_sfc(st_as_sf(as.data.frame(a), coords = 1:2, crs=st_crs(a))))[,1:3]
#> Warning: Some expressions had a GC in every iteration; so filtering is disabled.
#> # A tibble: 2 × 3
#>   expression                                                                min
#>   <bch:expr>                                                           <bch:tm>
#> 1 st_as_sfc(a)                                                            5.61s
#> 2 st_as_sfc(st_as_sf(as.data.frame(a), coords = 1:2, crs = st_crs(a)))  173.8ms
#> # … with 1 more variable: median <bch:tm>

Created on 2022-12-14 with reprex v2.0.2

@edzer
Copy link
Member

edzer commented Dec 14, 2022

A (tested) PR would be great; as you can see #2059 has an alternative approach to this (making sfc_POINT much more like a SpatialPoint), but it's currently unclear whether we want to merge that.

@bart1
Copy link
Contributor Author

bart1 commented Dec 15, 2022

I'll keep an eye out for #2059 and submit an pull request depending on what happens there

@edzer edzer closed this as completed Mar 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants