Document comparison with SDMTools::PatchStats

[jsta]

I am considering porting some code using SDMTools::PatchStats to landscapemetrics::calculate_metrics(what = "patch") but I am having some difficulty comparing their outputs. Would some documentation comparing the two be welcome? If so, does it make sense to document in the README, vignette, or function docs?

[marcosci]

If I remember correctly SDMTools does not convert the results to hectar and so on, as FRAGSTATS and we do - do you mean that with difficulties?

Otherwise: We should probably make this vignette a bit more broad:

https://r-spatialecology.github.io/landscapemetrics/articles/articles/comparing_fragstats_landscapemetrics.html

... and include SDMTools there 👍

[jsta]

Hmm, I hadn't considered a units mismatch.

[mhesselbarth]

I remeber checking (just very quickly) some results with SDMTools and think everythink looked ok, with exception of the units mismatch (which sometimes leads to a propagation). Maybe we should have a closer look if something else may be a problem (@marcosci).

[marcosci]

Yup, the vignette needs an update anyway 👍

[jsta]

Here is my comparison attempt: https://gist.github.com/jsta/bd791f2c5e2609775bf9b322abb27c01

[marcosci]

Hi @jsta,

I just included a section about SDMTools here in this vignette:

https://r-spatialecology.github.io/landscapemetrics/articles/articles/comparing_tools.html#comparison-with-sdmtools

I changed your code a bit to show how you would get the same results with SDMTools as with landscapemetrics/FRAGSTATS. The metrics you were after would rather be calculated with ClassStats in SDMTools, or? If something is missing or I am wrong, please say so and I will change it/make it clearer.

[jsta]

Right about ClassStats I was trying to keep the comparison as simple as possible. I plan to do some more digging and consider a PR against that vignette if that's alright.

[marcosci]

Sure :) Thanks!

[jsta]

I updated my gist with a more direct ClassStats comparison. All the metrics look good except the core metrics (and prop.like.adjacencies/ lsm_c_pladj). Got any ideas? I don't get better results adjusting directions, consider_boundary, or edge_depth.

[marcosci]

PLADJ should be fine, the result from landscapemetrics is correct (or at least the same as you get from FRAGSTATS).

There are datasets with the true values (calculated from FRAGSTATS, landscapemetrics::fragstsats_class_landscape for your example) in the package, we tested against them during the development:

fragstats_class_landscape_value <- dplyr::select(fragstats_class_landscape,
                                              TYPE, PLADJ)
names(fragstats_class_landscape_value) <- c("class", "value")
landscapemetrics_class_landscape_value <- lsm_c_pladj(landscape)
comparison <- dplyr::full_join(x = fragstats_class_landscape_value,
                            y = landscapemetrics_class_landscape_value,
                            by = "class",
                            suffix = c(".fs", ".lsm"))

You can find more here:

https://github.com/r-spatialecology/landscapemetrics/blob/master/tests/testthat/test_fragstats.R

We disabled that because FRAGSTATS has only a precision of 4 digits, so we ended up with a lot of rounding and the test itself did not make that much sense anymore.

There are slight differences between the definition of core areas in our case and FRAGSTATS, we count edge cells (and therefore always have 1, 2, 3, 4 cells as edge depth) and FRAGSTSATS looks at cell centroids for the core area and measures the distance between cell centroids. The results differ only after some digits, at least during our testing. We have that on the agenda, so that they perfectly match with fragstats:

#15

[marcosci]

@jsta If you find something knew, let me know and we reopen here 👍

[jsta]

I settled on finding that FRAGSTATS and SDMTools core metrics do not match but I'm not sure why.

[marcosci]

So, without the chance at looking at the code from FRAGSTATS, I assume the difference comes from the definition of edge.

SDMTools does the same basically the same as we do:

https://github.com/jjvanderwal/SDMTools/blob/2eee12d07557e2b22cd31a302c92ddb820eb4859/src/patchstats.c

(The landscapemetrics::show_cores functions is a good way to look at that).

We played around a little and found out that we get the same results for the core metrics if we treat the raster as points (where the cell center becomes the point). If you then specify edge depths and measure distances, you get the same result as in FRAGSTATS.

[mhesselbarth]

I guess that FRAGSTATS actually somehow measures distances to the edge and therefore the area of a cell can be only partly core area. Contrastingly, we define the edge-distance rather as "rows of cells" away from the edge. Therefore, a cell can be either completely core or completely edge.