rspatial
SpatRaster created from SpatExtent has unexpected extent
I am creating a SpatRaster from a SpatExtent, with the latitudinal and longitudinal ranges being exact multiples of the resolution. I expect the reported extent of the generated SpatRaster to be identical to the intended extent, but this is not always the case:
library(terra)
#> terra 1.7.79
e <- c(111.975, 154.025, -44.025, -9.975)
r <- rast(ext(e), res = 0.05)
ext(e)
#> SpatExtent : 111.975, 154.025, -44.025, -9.975 (xmin, xmax, ymin, ymax)
ext(r)
#> SpatExtent : 111.975, 154.025, -44.025, -9.97499999999999 (xmin, xmax, ymin, ymax)
ext(e) == ext(r)
#> [1] TRUE
as.vector(ext(e)) == as.vector(ext(r))
#> xmin xmax ymin ymax
#> TRUE TRUE TRUE FALSE
Created on 2024-05-27 with reprex v2.0.2
Session info
sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#> setting value
#> version R version 4.3.2 (2023-10-31)
#> os macOS Ventura 13.6.6
#> system x86_64, darwin20
#> ui X11
#> language (EN)
#> collate en_US.UTF-8
#> ctype en_US.UTF-8
#> tz Australia/Melbourne
#> date 2024-05-27
#> pandoc 2.14.2 @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#> package * version date (UTC) lib source
#> cli 3.6.2 2023-12-11 [1] CRAN (R 4.3.0)
#> codetools 0.2-19 2023-02-01 [1] CRAN (R 4.3.2)
#> digest 0.6.35 2024-03-11 [1] CRAN (R 4.3.2)
#> evaluate 0.23 2023-11-01 [1] CRAN (R 4.3.0)
#> fastmap 1.2.0 2024-05-15 [1] CRAN (R 4.3.3)
#> fs 1.6.4 2024-04-25 [1] CRAN (R 4.3.2)
#> glue 1.7.0 2024-01-09 [1] CRAN (R 4.3.0)
#> htmltools 0.5.8.1 2024-04-04 [1] CRAN (R 4.3.2)
#> knitr 1.45 2023-10-30 [1] CRAN (R 4.3.0)
#> lifecycle 1.0.4 2023-11-07 [1] CRAN (R 4.3.0)
#> magrittr 2.0.3 2022-03-30 [1] CRAN (R 4.3.0)
#> purrr 1.0.2 2023-08-10 [1] CRAN (R 4.3.0)
#> R.cache 0.16.0 2022-07-21 [1] CRAN (R 4.3.0)
#> R.methodsS3 1.8.2 2022-06-13 [1] CRAN (R 4.3.0)
#> R.oo 1.26.0 2024-01-24 [1] CRAN (R 4.3.2)
#> R.utils 2.12.3 2023-11-18 [1] CRAN (R 4.3.0)
#> Rcpp 1.0.12 2024-01-09 [1] CRAN (R 4.3.0)
#> reprex 2.0.2 2022-08-17 [1] CRAN (R 4.3.0)
#> rlang 1.1.3 2024-01-10 [1] CRAN (R 4.3.0)
#> rmarkdown 2.26 2024-03-05 [1] CRAN (R 4.3.2)
#> sessioninfo 1.2.2 2021-12-06 [1] CRAN (R 4.3.0)
#> styler 1.10.2 2023-08-29 [1] CRAN (R 4.3.0)
#> terra * 1.7-79 2024-05-27 [1] Github (rspatial/terra@fe50dec)
#> vctrs 0.6.5 2023-12-01 [1] RSPM (R 4.3.0)
#> withr 3.0.0 2024-01-16 [1] CRAN (R 4.3.0)
#> xfun 0.44 2024-05-15 [1] CRAN (R 4.3.3)
#> yaml 2.3.8 2023-12-11 [1] CRAN (R 4.3.0)
#>
#> [1] /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────
When you create a raster with an extent and a resolution, the extent has to be recomputed to assure that it contains entire cells. What happens is equivalent to
r <- rast(ext(e), res = 0.05)
ymax <- e[3] + nrow(r) * res(r)[1]
Because the computer can only approximate real numbers, there is a (very) small change in the value:
ymax
#[1] -9.975
print(ymax, digits=20)
#[1] -9.9749999999999872102
# compare with the value you specified
print(e[4], digits=20)
#[1] -9.9749999999999996447
I suppose the code could check for such very small variations and, when detected, use the specified value instead.
Thanks for the explanation @rhijmans - that makes sense.
Handling it in the way you suggest might be nice, but I understand it's probably a low priority. Feel free to close if you don't think it's worthwhile.
I made a small change such that you now get
as.vector(ext(e)) == as.vector(ext(r))
#xmin xmax ymin ymax
#TRUE TRUE TRUE TRUE