Coverage_fraction gives total cell coverage > 1

[amarbler]

Hi,

I just found an unexpected outcome using the function coverage_fraction:

library(exactextractr)
library(raster)
library(sf)

shp = sf::st_as_sf(rbind(raster::getData("GADM", country = "CAN", level = 0), raster::getData("GADM", country = "GRL", level = 0)))
rast= raster(res = 1, crs = crs(shp))
cvg = sum(exactextractr::coverage_fraction(rast, shp)%>%raster::stack())
max(getValues(cvg))
[1] 1.000007

sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 10 (buster)

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] sf_0.9-8            raster_3.4-8        sp_1.4-5
[4] exactextractr_0.6.0

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.6         magrittr_2.0.1     units_0.7-1        tidyselect_1.1.0
 [5] lattice_0.20-41    R6_2.5.0           rlang_0.4.10       fansi_0.4.2
 [9] dplyr_1.0.4        tools_3.5.2        rgdal_1.5-23       grid_3.5.2
[13] utf8_1.1.4         KernSmooth_2.23-18 e1071_1.7-6        DBI_1.1.1
[17] ellipsis_0.3.1     class_7.3-18       assertthat_0.2.1   tibble_3.1.0
[21] lifecycle_1.0.0    crayon_1.4.1       purrr_0.3.4        vctrs_0.3.6
[25] codetools_0.2-18   glue_1.4.2         proxy_0.4-25       pillar_1.5.0
[29] compiler_3.5.2     generics_0.1.0     classInt_0.4-3     pkgconfig_2.0.3

If I understand the documentation correctly this should actually never happen, right?

[dbaston]

Thanks for the report.

You can see a total coverage fraction > 1 when two input polygons overlap within a grid cell, causing some area to be counted in the coverage fraction of both polygons. I wouldn't expect this for GADM.

More likely, you're just seeing some floating point noise the addition of two coverage fractions that are calculated as single-precision floating point numbers. exactextractr uses single-precision numbers for coverage fractions to save memory, but I've wondered if there should be an option to use full double precision.

Does this result cause a problem for you?

[amarbler]

Ok, thanks that makes sense. It's probably just floating point noise. If there would be an option available preventing this, that would be nice. But it's not a big problem for me, because it's always a very very small number for one of the coverage fractions, so I simply set it to 0.