makeEOO polygon has area 0 if presences in straight line

[AMBarbosa]

When there's only one pixel with presence, both AOO and EOO are correctly computed as the area of that pixel. However, when there are two presence pixels, or more pixels but in a straight line, AOO is correctly calculated as the sum of the areas of those pixels, but the EOO is calculated as zero. This is because the EOO polygon surrounds the entire presence pixel when there's only one, but connects only the centroids of the presence pixels when there's more than one. This provides inconsistent results, which are smaller than they should be when there's more than one presence pixel, and especially when these presences form a straight line. Here's some reproducible code:

par(mfrow = c(1, 2))

r1 <- raster(nrows=10, ncols=10, xmn=0, xmx=10, crs = crs.UTM55S, ext = extent(0, 6100, 0, 8700))
r1[2, 3] <- 1
plot(r1, legend = FALSE)  # 1 pixel
EOO.polygon1 <- makeEOO(r1)
plot(EOO.polygon1, add = TRUE)  # polygon around the single presence pixel
getArea(r1)  # 0.5307
getAreaEOO(EOO.polygon1)  # 0.5307 - ok

r2 <- r1
r2[2, 5] <- 1
plot(r2, legend = FALSE)  # 2 pixels
EOO.polygon2 <- makeEOO(r2)
plot(EOO.polygon2, add = TRUE)  # a line, not a polygon!
getArea(r2)  # 1.0614 - ok
getAreaEOO(EOO.polygon2)  # 0 - wrong

To get consistent and more accurate results (and avoid getting EOO < AOO, which doesn't make sense), maybe makeEOO should always draw the minimum convex polygon around the polygonized pixels with presence, rather than their central coordinates?

[calvinkflee]

I'm not quite sure how this can be "fixed", because a line technically should have an area of 0. If anything, I'm inclined to say that the single point giving an area is "wrong", as that should also have no area.

I guess one way of fixing this behaviour is to create a buffer around the points when the points are generated from a raster layer?

Will look into adding this buffer.

[calvinkflee]

With the updated use of terra::convHull, the point now also gives 0, which is the "correct" answer. Will now see about adding the buffer.

[AMBarbosa]

The IUCN guidelines seem to indicate that the EOO should be computed around the presence sites, not buffers (which would require a subjective decision on the buffer size). But they also say that when EOO < AOO, then EOO should be coerced to be equal to the AOO. So, I think the "official" fix would be to just add if (EOO < AOO) EOO = AOO.

However, I do think this is incorrect and underestimates the actual EOO when presences are in a straight line but not adjacent. I was actually thinking about publishing a short note proposing a change in the IUCN guidelines, to compute the EOO around the 2x2 km presence pixels / polygons instead of their central points. Unfortunately I'm severely short on time for this...

Cheers!

[calvinkflee]

Rather than adding an arbitrary buffer, I'm thinking more on the lines of the fact that occurrence points technically have zero area themselves (they're points).

Focusing only on the geometry side of things, I have now updated makeEOO. Previously, if a raster is used as the input object, we took the centroid of the pixels and then created EOOs based on the centroids. Now, rather than only using the centroids, the function will now create a buffer roughly the size of the original pixel (actually it's a circle with radius = half of the shorter side of the pixel), which will then be used as the basis for creating the EOO.

This will NOT be done if the original input is already in point format, because there is no "correct" buffer size as this requires a subjective decision as state above.

Overall, this should have minimal effect on results.