Episode 9 updated by replacing calls to raster and rgdal packages

[albhasan]

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

[github-actions]

Thank you!

Thank you for your pull request 😃

🤖 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:

• 🎯 correct output
• 🖼️ correct figures
• ❓ new warnings
• ‼️ new errors

Rendered Changes

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

The following changes were observed in the rendered markdown documents:

 09-vector-when-data-dont-line-up-crs.md | 229 ++++++++++++--------------------
 md5sum.txt                              |   2 +-
 2 files changed, 83 insertions(+), 148 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.

⏱️ Updated at 2023-03-18 19:11:45 +0000

[drakeasberry]

Thanks for your continued work on this transition. In this episode, the changes have included the following code piped onto the st_read() functions:

%>% st_zm()

I am unclear on what this is adding as the outputs with and without this code appear to be identical. Could you shed some light on why this needs to be included?

[albhasan]

sf::st_zm() removes the Z & M coordinates from sf geometries, leaving them flat (only X & Y). Mixturing flat and XYZM geometries throws errors in some parts of episode 9 (at least in my machine, Fedora 37, R 4.2.2, sf 1.0-10 & terra 1.7-18). To avoid this situation, we could remove ZM coordinates in the original shapefiles (outside of R) or use the sf::st_zm() function just before of the offending operations. However, I believe the lesson's code would be more resilent if we just remove ZM as soon as we load the data. In the end, none of the operations in this lesson require neither Z nor M coordinates.