Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
crs handling in combine_list_of_sf #46
How should we handle CRS in
I wanted to think through some options for dealing with this and discuss them in this issue. I have confirmed that even if edits made on a project leaflet map the edits are converted back to
The two viable options I see are:
I favour the latter as you should never be allowed to combine features with different projection (the result will be meaningless), though I see the convenience of the former.
pinging @edzer for thoughts on this one.
Here is my issue with
I feel like there has been discussion on
Jul 18, 2017
referenced this issue
Dec 7, 2017
Writing in a year after the last comment on this issue -- for starters, thanks for all the work on this package! I use it often.
I found this issue a few months back and it solved a major headache for me. I've been unable to find an officially-supported solution to the basic problem of a bind_rows() style rbind-ing of a list of sf objects. All of the issues above look to be closed with references to an underlying issue with dplyr, roughly a year back. I now use mapedit's internal function for this a lot -- a quick search of my private repos this morning yielded >500 instances of calls to mapedit:::combine_list_of_sf() in lieu of a purrr::reduce(list_of_sf, sf:::rbind.sf) call. In case y'all think it's helpful, here or in related packages, here's my reasoning and a broad use-case where it's been helpful.
I've moved to using mapedit's internal function over reduce/rbind.sf for speed reasons -- if I understand correctly, reduce/rbind.sf takes elements 1 and 2 to create an intermediate sf dataframe A; then dataframe A is rbind-ed to element 3 to create intermediate sf df B; and so on, such that there are (for N list elements) a total of N-1 intermediate list objects and therefore N-1 copy in memory operations. I see a noticeable speed drop on polygon dataframes over about 200 rows.
The generic use-case -- I very frequently (>100 times/day?) need to split / map / combine sf objects, primarily for reasons of access speed. For instance: I have all 11 million US Census blocks from tigris, saved to disk by county, and need to readRDS or read_sf those files in arbitrary subsets. (For instance -- pick a focal county, find neighbors, load block geometries only for that subset of counties.) I would do something like list_of_county_files %>% map(read_sf) %>% mapedit:::combine_list_of_sf(), sometimes with intermediate operations.
From my perspective, that would be great! After reading the issue history in
The other feature from
@edzer if you think it's worth considering this for
Yes, worth considering:
Happy to see an issue on sf, possibly followed by a PR.
referenced this issue
Jul 15, 2018
My comment / @edzer 's followup has been summarized over on
(This isn't my issue to close and looks like some other discussion was open, so I'll just say thanks all for engaging on this!)