Skip to content

Commit

Permalink
Merge pull request #1057 from tibbles-and-tribbles/patch-36
Browse files Browse the repository at this point in the history
Update 07-reproj.Rmd
  • Loading branch information
Robinlovelace authored Jan 30, 2024
2 parents 562a3c0 + 239d698 commit 635bd02
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion 07-reproj.Rmd
Original file line number Diff line number Diff line change
Expand Up @@ -376,7 +376,7 @@ tmap_arrange(tm1, tm2, tm3, nrow = 1)
It is clear from Figure \@ref(fig:crs-buf) that buffers based on `s2` and properly projected CRSs are not 'squashed', meaning that every part of the buffer boundary is equidistant to London.
The results that are generated from lon/lat CRSs when `s2` is *not* used, either because the input lacks a CRS or because `sf_use_s2()` is turned off, are heavily distorted, with the result elongated in the north-south axis, highlighting the dangers of using algorithms that assume projected data on lon/lat inputs (as GEOS does).
The results generated using S2 are also distorted, however, although less dramatically.
Both buffer boundaries in Figure \@ref(fig:crs-buf) (left) are jagged, although this may only be apparent or relevant when for the thick boundary representing a buffer created with the `s2` argument `max_cells` set to 100.
Both buffer boundaries in Figure \@ref(fig:crs-buf) (left) are jagged, although this may only be apparent or relevant for the thick boundary representing a buffer created with the `s2` argument `max_cells` set to 100.
<!--toDo:rl-->
<!--jn: maybe it is worth to emphasize that the differences are due to the use of S2 vs GEOS-->
<!--jn: you mention S2 a lot in this section, but not GEOS...-->
Expand Down

0 comments on commit 635bd02

Please sign in to comment.