lsm_c_te() does not pass directions to rcpp_get_coocurrence_matrix_single(), affecting Total Edge calculation

[sekiajisekisaba]

The lsm_c_te() function includes a directions argument (either 4 or 8), which is expected to influence the Total Edge (TE) calculation by defining the neighborhood structure.

However, upon inspecting the source code, it appears that this argument is not passed to rcpp_get_coocurrence_matrix_single() within lsm_c_te_calc(). Instead, the value is hardcoded as 4, regardless of the user input.
(around line 135 in lsm_c_te.R)

neighbor_matrix <- rcpp_get_coocurrence_matrix_single(
  landscape_labeled,
  directions = as.matrix(4),  # <- hardcoded
  single_class = -999
)

As a result, specifying directions = 8 in lsm_c_te() seems to have no effect on the TE output, even though lsm_c_te() sets directions = 8 as the default. This may lead to a discrepancy between the expected behavior and the actual implementation.

The function should dynamically use the directions argument provided by the user, for example:

neighbor_matrix <- rcpp_get_coocurrence_matrix_single(
  landscape_labeled,
  directions = as.matrix(directions),
  single_class = -999
)

This would ensure that TE and related metrics (such as Edge Density) accurately reflect the intended neighborhood configuration.

Question
It’s possible that I may be misunderstanding the intended behavior, but I wanted to ask:

1. Is the hardcoded directions = 4 an intentional design decision?
2. Or should the function reflect the directions argument passed to lsm_c_te()?
3. I would appreciate any clarification on whether this is expected behavior or a potential oversight.

Thank you very much for your work on this excellent package!

[Nowosad]

Thanks for opening the issue and providing all of the details, @sekiajisekisaba

I have a strange feeling that we (landscapemetrics developers) discussed that in the past, but I do not remember any conclusions.

@mhesselbarth -- do you have any memory of our discussions or can you answer the stated questions?

[mhesselbarth]

I was thinking about this the last days as well. I have the same feeling that there was a reason to keep this fixed in this case but currently also can't remember. Maybe something with the general edge definition?

[bitbacchus]

It makes sense to have it fixed because we are dealing with rasters.

Consider this 3x3 pixel landscape:

lsm_c_te only considers the pixels left-right and above-below, and calculates a total edge of four. The diagonal pixels don´t have common edges. Or do I miss something?

But I agree with @sekiajisekisaba that lsm_c_te (and all other edge metrics) should not have a directions argument.

[mhesselbarth]

I think that's it yes!

[Nowosad]

👍🏻 @bitbacchus

@sekiajisekisaba do you have any improvement suggestions we could do?

[sekiajisekisaba]

Thank you all for the thoughtful discussion and explanations!

I now better understand the rationale for keeping the directions argument fixed at 4 in lsm_c_te(), especially in the context of raster structure and edge adjacency. @bitbacchus’s explanation helped clarify that diagonal pixels do not share edges, making the 4-directional approach more consistent for calculating Total Edge (TE).

One important point is that lsm_c_te() calculates edges based on the boundaries of raster cells. Under this definition, diagonal neighbors do not contribute to edge length, which supports the decision to use a 4-directional neighborhood.

If possible, it might be helpful to either remove the directions argument from lsm_c_te() or add a note in the documentation explaining why it is fixed at 4 and how this relates to the edge definition. I believe this could help avoid confusion for users.

Thank you again for maintaining such a great package and for being open to feedback!

[mhesselbarth]

I will try to find some time to look at this and if it doesn't break anything, I would probably remove the argument