Lesson 2 updated by replacing calls to raster and rgdal packages.

[albhasan]

Lesson 2 updated by replacing calls to raster and rgdal packages with calls to terra package. #368 #363

[github-actions[bot]]

Thank you!

Thank you for your pull request :smiley:

:robot: This automated message can help you check the rendered files in your submission for clarity. If you have any questions, please feel free to open an issue in {sandpaper}.

If you have files that automatically render output (e.g. R Markdown), then you should check for the following:

• :dart: correct output
• :framed_picture: correct figures
• :question: new warnings
• :bangbang: new errors

Rendered Changes

:mag: Inspect the changes: https://github.com/datacarpentry/r-raster-vector-geospatial/compare/md-outputs..md-outputs-PR-385

The following changes were observed in the rendered markdown documents:

 02-raster-plot.md                                  |  89 ++-
 config.yaml (new)                                  |  95 +++
 ...lot-rendered-challenge-hillshade-layering-1.png | Bin 180764 -> 180774 bytes
 ...lot-rendered-challenge-hillshade-layering-2.png | Bin 129870 -> 129827 bytes
 ...02-raster-plot-rendered-overlay-hillshade-1.png | Bin 217588 -> 217602 bytes
 fig/02-raster-plot-rendered-raster-hillshade-1.png | Bin 129627 -> 129981 bytes
 md5sum.txt                                         |   2 +-
 renv.lock (new)                                    | 810 +++++++++++++++++++++
 8 files changed, 957 insertions(+), 39 deletions(-)

What does this mean?

If you have source files that require output and figures to be generated (e.g. R Markdown), then it is important to make sure the generated figures and output are reproducible. This output provides a way for you to inspect the output in a diff-friendly manner so that it's easy to see the changes that occur due to new software versions or randomisation.

:stopwatch: Updated at 2023-02-25 18:37:27 +0000

[jebyrnes]

Any thought to using tidyterra so we can just use geom_spatraster()?

[albhasan]

@jebyrnes Thanks for the suggestion. tidyterra would allows us to avoid the calls to as.data.frame at the cost of a new package dependency. This package is already in CRAN and it seems sound at github regading tests, code quality and code coverage.

What worries me is the potential future changes to the interfaces of both terra and tidyterra which would require us to update the lessons. Besides, tidyterra latest version is 0.3 and isn't listed as part of the tidyverse, so I'm not sure of its interface maturity.

My personal opinion is, for now, to keep updating the lesson according to issues #368 and #363 and discuss improvements to the lessons using a different set of issues and pull requests. However, I'm open to hear the recommendations of other contributors.

[mikemahoney218]

Speaking purely for myself (member of @datacarpentry/curriculum-advisors-geospatial , but I'm not at all speaking for the group, and adding a new package doesn't need our approval anyway), I'd also vote to not add a tidyterra dependency. This isn't a knock on tidyterra -- I know some people who like the package a lot! -- but I think it would be best to keep our lessons focused on the core spatial libraries in R for both maintainability reasons but also to not overwhelm learners by presenting multiple ways of doing the same tasks.

[jebyrnes]

Fair! Now if we could only convince the ggplot2 team to put in a geom_spatraster like they did with geom_sf..... or have geom_raster() recognize spatraster objects!