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

Fix for issue - https://github.com/Robinlovelace/geocompr/issues/740 #742

Merged
merged 2 commits into from Feb 10, 2022

Conversation

jimr1603
Copy link
Contributor

@jimr1603 jimr1603 commented Feb 1, 2022

The 3 functions were not loaded, since raster library was not loaded. Prefixing these with raster:: tells bookdown to link to the documentation for these functions.

If I find more of these I'll flag them as this Issue.

The 3 functions were not loaded, since raster library was not loaded. Prefixing these with `raster::` tells bookdown to link to the documentation for these funcitons.
@Robinlovelace
Copy link
Collaborator

OK after chatting with @jimr1603 in person going to tweak then merge.

@@ -734,7 +734,7 @@ The **terra** package supports raster objects in R.
Like its predecessor **raster** (created by the same developer, Robert Hijmans), it provides an extensive set of functions to create, read, export, manipulate and process raster datasets.
**terra**'s functionality is largely the same as the more mature **raster** package, but there are some differences: **terra** functions are usually more computationally efficient than **raster** equivalents.
<!-- todo: add evidence (RL 2021-11) -->
On the other hand, the **raster** class system is popular and used by many other packages; as with **sf** and **sp**, the good news is you can seamlessly translate between the two types of object to ensure backwards compatibility with older scripts and packages, for example, with the functions `raster()`, `stack()`, or `brick()` (see the previous chapter for more on the evolution of R packages for working with geographic data).
On the other hand, the **raster** class system is popular and used by many other packages; as with **sf** and **sp**, the good news is you can seamlessly translate between the two types of object to ensure backwards compatibility with older scripts and packages, for example, with the functions `raster::raster()`, `raster::stack()`, or `raster::brick()` (see the previous chapter for more on the evolution of R packages for working with geographic data).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the following could be better for consistency:

On the other hand, the **raster** class system is popular and used by many other packages; as with **sf** and **sp**, the good news is you can seamlessly translate between the two types of object to ensure backwards compatibility with older scripts and packages, for example, with the functions [`raster()`](link_to_raster_docs) ...

Thoughts @Nowosad ?

@Robinlovelace Robinlovelace merged commit 9b8ce85 into geocompx:main Feb 10, 2022
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

Successfully merging this pull request may close these issues.

None yet

2 participants