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

rewrite code avoiding using sp and rworldmap #110

Closed
damianooldoni opened this issue Dec 20, 2023 · 6 comments · Fixed by #111
Closed

rewrite code avoiding using sp and rworldmap #110

damianooldoni opened this issue Dec 20, 2023 · 6 comments · Fixed by #111
Assignees

Comments

@damianooldoni
Copy link
Collaborator

@SanderDevisscher: the climate function is using sp package. rworldmap is also used, which relies on sp.

It's time to move to sf. In this way we don't need to use packages rgeos and rgdal which are archived since October 2023 and not more available. See failures of GitHub actions. This is not only important for the authomatic checks of this package, but as you are authomatising the indicators workflow, using the trias package in your GitHub Actions will fail.

@SanderDevisscher
Copy link
Contributor

I'll look into it

@damianooldoni damianooldoni mentioned this issue Dec 20, 2023
3 tasks
@soriadelva soriadelva self-assigned this Mar 1, 2024
@SanderDevisscher
Copy link
Contributor

@soriadelva will look into this under my supervision.

@damianooldoni
Copy link
Collaborator Author

Thanks for the update. I have added her just now to trias as member.

@soriadelva
Copy link
Collaborator

soriadelva commented Mar 7, 2024

@damianooldoni, the RDA data files currently provide the climate data as SpatialPolygonsDataFrame and Sander and me were wondering if it could be useful to recode them as sf objects?

@damianooldoni
Copy link
Collaborator Author

👋 @soriadelva!
Making geojson files of them means that they are not anymore available as internal data (R objects). That means that the user will have to load them every time he/she needs. Notice also that they are structured objects:

> class(observed)
[1] "list"
> names(observed)
[1] "1901-1925" "1926-1950" "1951-1975" "1976-2000" "1980-2016"

> class(future)
[1] "list"
> names(future)
[1] "2001-2025-A1FI" "2026-2050-A1FI" "2051-2075-A1FI" "2076-2100-A1FI" "2071-2100_Beck"

> class(legends)
[1] "list"
> names(legends)
[1] "KG_A1FI" "KG_Beck"

So, saving them as geojson would mean we will have 10 geojson file (5 from futures, 5 from legends). And what to do with legends? Will we save them as two csv files? They are two data.frames.

It will make everything quite complex for everybody, I think.

I would just convert future and observed to two lists of sf:

library(sf)
library(purrr)
observed_sf <- purrr::map(observed, function(x) sf::st_as_sf(x))
future_sf <- purrr::map(future, function(x) sf::st_as_sf(x))

and then overwriting the .rda files.

@soriadelva
Copy link
Collaborator

@damianooldoni thanks for the reply! I'll convert them to two lists of sf.

soriadelva added a commit that referenced this issue Mar 8, 2024
#110

Function converted to work on sf package instead of sp package. World maps imported via package rnaturalworld instead of rworldwap. Possible issue: this package may consider continents a little differently (e.g., Greenland is not a part of Europe while in rworldmap it was considered a part of Europe)
@soriadelva soriadelva linked a pull request Mar 8, 2024 that will close this issue
soriadelva added a commit that referenced this issue Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants