rspatial / terra

R package for spatial data handling https://rspatial.github.io/terra/reference/terra-package.html
GNU General Public License v3.0
528 stars 87 forks source link

SpatRaster created from SpatExtent has unexpected extent #1519

Open johnbaums opened 1 month ago

johnbaums commented 1 month ago

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 ``` r 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 #> #> ────────────────────────────────────────────────────────────────────────────── ```
rhijmans commented 3 weeks ago

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.

johnbaums commented 3 weeks ago

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.