Agenda

[marcosci]

If you still plan to be on board, I invited both of you to a slack channel @ ropensci - I started there to discuss a naming scheme :)

[marcosci]

So, we thought to give it a try with the following naming scheme:

landscapemetric classmetric patch_metric

... where metric would most likely be the same abbreviation that FRAGSTATS uses.

[jhollist]

Couple of thoughts:

1. do we want to name using a prefix? Something common for all functions?

   • lm_xxx_xxx?
   • lnd_xxx_xxx?
   • lndmet_xxx_xxx?

2. The names could get pretty long... if we use both a package level prefix and the landscape prefix. Not sure I have a solution, but once we decide should keep that in mind.

3. Do we need separate functions for landscape class and patch? Lot of the underlying code would be similar for each metric, no? Could have a single function for each metric and could just specify in the output the landscape, class, etc.

[Nowosad]

@jhollist How about the lsm_ prefix?

I would also prefer the `lsm_xxx(input_raster, type = "landscape") convention. However, my silly question is - do all of the possible functions have all type levels?

[marcosci]

As probably being the person here with the least coding experience:

If anything else seems off (name of the package, concept at all, ...) - just point it out. Nothing is set in stone or has emotional value :stuck_out_tongue:

I am fine with either (lm_ or lsm_, don't have a preference there (a verb would be nice, but we couldn't come up with one). @Nowosad Not all, but a bunch of them have all types. But with your option, that would not make any difference?

[mhesselbarth]

Many metrics at higher levels (e.g. landscape) are just the sum, mean, sd, ... of the metrics at lower level (i.e. class). But then again, there are also metrics not present at all levels (e.g. the diversity metrics make only sense at landscape level).

Maybe that is a argument against just one function with different options for the levels. I think it could get a bit confusing cause the functions would have different possible levels as options.

[mhesselbarth]

I had a look at the metrics again. There are actually quite a few that make only sense at one or two scales.

Therefore, I think it makes more sense to implement them as separate functions for each scale (maybe lm_clss_xxx, lsm_lndscp_xxx or something similar). Doing it like this, the user could just browse easily all metrics available at the scale.

And at the end, we could just write an overall wrapper around all functions and allow to specify the scale there (e.g. lm_all(x, scale = ' landscape').

[laurajanegraham]

Hi all, apologies for the delayed response - was a public holiday in the UK yesterday and I was enjoying time in my garden :)

I think that it makes sense to have a prefix for each of patch / class / landscape; my understanding is that they are fairly different between these levels.

In terms of an overall prefix. I think it definitely makes sense to do so as long as the functions don't get too long. I would lean towards lsm_, and definitely away from lm_ due to linear model in base R.

How are you assigning metrics to people? I have code for a couple of the suggested so should I just assign to myself?

[mhesselbarth]

There are two open issues, where you can just assign yourself to metrics (and tick them if they are done).

P.S. If you already have existing code for a metric somebody else is already assigned to, but it's not ticked 'done' yet, just change the name of responsible person :)

[Nowosad]

Important question - what is expected class and structure of the outputs? Is it (1) a simple vector, (2) named vector, (3) data.frame/tibble, (4) something else? If it is a tibble - what are the columns?

I think that all the functions should be type-stable, e.g. always return the same class and structure..

[marcosci]

I would argue for a tibble - it's one dependency more, but it should be the most convenient way to have a type-stable return. With higher dimensional raster (timeseries etc.) vector/named vector become quite hard to connect to the input data, or?

[jhollist]

Couple of thoughts:

Naming

• prefix: lsm for prefix. lm could cause confusion for people thinking it has something to do with linear models.
• for landscape, class, or patch, I do really like the idea of having those because it allows easy searching of functions. I would propose, l, c, or p to keep function names short.
• function names would look like: lsm_l_pd or lsm_p_frac
• verbs would be nice, but not necessary IMO as I can't think of anything obvious other than calc or calculate or something like that.

Output class I also vote for a data frame or tibble. Design decisions would be the same and we could deal with an additional dependency at later date if we decide tibble is best. Also, I am a big fan of a long form table, as it is very flexible. Something like:

id	scale	metric	value
1	patch	area	10
2	patch	patch density	4.5

Input data type What is the expected input data type? Raster? Polys? Either? Without having though about this much, I'd argue for a fairly prescribed input data format for the functions and build some helper functions that would convert to this input.

[mhesselbarth]

Naming Agreed

Output I also think a tibble is the best idea, mainly because of the possibility to deal with higher dimensional raster as input (each row is a raster layer). However, we also need to agree if and how to name the columns. I would suggest always returning the values in the column named as the metrics. For the class level output there would be a column with the class and another column with the layer:

layer	class	pland
1	0	40
1	0.5	20
1	1	40

For the landscape level the class-column would not be necessary (or a dummy variable?)

Input I would suggest a raster object as the standard input. I think most people wanting to calculate the metrics have the data in that format (correct me if I'm wrong, though)

[Nowosad]

Naming I think it is set now.

Output I prefer Jeff's idea. A long-form table is extremely powerful, but also ease working with many outputs. For example, it would be possible to calculate many metrics using purrr::map() and bind them together. How about

layer	level	id	metric	value
1	landscape	NA	total edge	50
2	patch	1	area	10

There is also a question of the metrics names. Are we going to use full names ("total edge") or the fragstat names (TE)?

Input I agree - we should stick to one input format - raster. At least for now.

[mhesselbarth]

Naming
In order to keep everything short, I would suggest using the FRAGSTATS abbreviations and just refer to the manual

Output I like the output format

[laurajanegraham]

Naming This all sounds great. In terms of metrics names, I would suggest the FRAGSTATS abbreviations for the function names and the full names for the table.

Input Agree that single input type of raster makes sense. Helper function for getting from polygon to raster might be useful because it requires a couple of steps. I know that in the past I've done some landscape metrics on UK Priority Habitats and they tend to be polygons rather than rasters. I do agree that 90% of the time people will be using rasters though, so it wouldn't make sense to bulk out the function to include code to test for polygons and convert to raster (which was my initial thought).

Output I like it. Very helpful for including in a tidy analysis workflow.

[marcosci]

So it's settled, just to summarize:

Naming

We will have the general style of :

lsm_x_xxx

, where the first x indicates which scale (landscape, class or patch) the metric covers and xxx is the abbreviation from fragstats.

Output

Jakubs suggestion is the winner:

layer	level	id	metric	value
1	landscape	NA	total edge	50
2	patch	1	area	10

Input

I am also in favor for having a raster as our standard input class, borrowing functions from raster/sf for coercing the class is maybe not necessary, as you need them to load your spatial data.

[marcosci]

And another short question:

I think Jakub put Landscape Metrics For Categorical Map Patterns as a title in the description - I had a chat with Kimberly With (the metrics we proposed here are a selection she promotes in a forthcoming book) and she made a case for including surface metrics (https://www.fs.fed.us/rm/pubs_other/rmrs_2009_mcgarigal_k001.pdf).

Is this something you would be happy with if it gets implemented here, or out of scope and different package?

[kawith]

Greetings! I'm coming to the discussion a few days late, but in case it helps with organizing metrics by organizational scale (patch, class, landscape), I've attached a table from the landscape pattern analysis chapter of my textbook that summarizes this:
Table 4.3.pdf

I can also upload the section of the chapter that deals with landscape metrics; I'd love it if we could at least include those mentioned in the textbook (a subset of metrics found in Fragstats). Fragstats calculates many, many more metrics, but most of these end up being highly intercorrelated and thus redundant. Still, if the goal is to replicate the functionality of Fragstats in the R environment, then providing those additional metrics would ensure that the package does everything Fragstats can do (and maybe more!).

The surface metrics might warrant a different package...they have parallels with the landscape metrics, but involve a very different approach (i.e., not involving patch based or categorical map patterns) and thus would benefit from being separated out. Plus, those interested in using surface metrics for other (non-ecological) applications might have trouble locating the package if these are buried within a package called "landscape metrics"

[kawith]

I wasn't sure where best to post this, but here is that section of the landscape analysis chapter dealing with landscape metrics (sans figures and additional tables). This is intended to provide a basic introduction to landscape metrics, particularly those available in Fragstats (since that is the most commonly used landscape analysis package at the moment).

Chapter 4_Landscape Metrics.pdf

[mhesselbarth]

Output

Marco and I just discussed and we both agreed that it would be nice to include the class as a additional column in the output. The table would look the following:

layer	level	class	id	metric	value
1	patch	1	1	total area	25
1	patch	1	2	total area	12
1	patch	2	3	total area	8

The id would be NA on class level and class and id would be NA on landscape level. Adding the class on patch level makes it much easier to track which patch is wich and to summarize results of patch level to higher levels.

[marcosci]

Vignette As we have to write a vignette at some point about our choice of metrics and what they measure - is it OK @kawith if we reference your book chapter there? :relaxed:

Output A very strong argument for the class column is:

If we have the same metric on multiple scales (patch -> landscape) we can use the class column to group and derive the class metrics from the function that calculates the patch metric. Like so:

https://github.com/marcosci/landscapemetrics/blob/master/R/lsm_c_enn_mn.R

[kawith]

Yes, I think it would be okay to cite the chapter at this stage, since the book has been scheduled for publication (January 2019).

[jhollist]

Again I have been mostly absent from all the activity, but including the class column in the output is a must, I think.

[Nowosad]

Quick question: What's function name is better - calculate_metrics() or lsm_calculate_metrics()?

[jhollist]

How about lsm_calculate()?

On Sat, Jun 9, 2018, 11:52 AM Jakub Nowosad notifications@github.com wrote:

Quick question: What's function name is better - calculate_metrics() or lsm_calculate_metrics()?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcosci/landscapemetrics/issues/2#issuecomment-395979316, or mute the thread https://github.com/notifications/unsubscribe-auth/AFL8S5lUK8eFs3WImwGhmAS7h0yiKRlPks5t6-9MgaJpZM4SYBX5 .

[marcosci]

I second Jeff's suggestion :)

Jeffrey W Hollister notifications@github.com schrieb am Sa., 9. Juni 2018, 17:54:

How about lsm_calculate()?

On Sat, Jun 9, 2018, 11:52 AM Jakub Nowosad notifications@github.com wrote:

Quick question: What's function name is better - calculate_metrics() or lsm_calculate_metrics()?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/marcosci/landscapemetrics/issues/2#issuecomment-395979316 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AFL8S5lUK8eFs3WImwGhmAS7h0yiKRlPks5t6-9MgaJpZM4SYBX5

.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/marcosci/landscapemetrics/issues/2#issuecomment-395979422, or mute the thread https://github.com/notifications/unsubscribe-auth/AKXHvm_XTdwn8r78YsTT37c6lj7zXSBRks5t6--6gaJpZM4SYBX5 .

[Nowosad]

Done - https://github.com/marcosci/landscapemetrics/commit/d9487719077f7a885ccfbb43cb05b546f94a3594

[marcosci]

Hi all,

so - I think everything looks reasonably good now and my plan would be to submit to CRAN in the near future.

The package itself looks okay at the moment:

https://win-builder.r-project.org/P7j8J6zA5P1R/00check.log https://builder.r-hub.io/status/landscapemetrics_0.1.0.tar.gz-a1642f38a3d54196bf82fdd3df280e36

... and in the next few days Max and I would only polish the vignettes and write more tests. We are lacking some metrics (see vignette) but I would push that to future-us to implement - there are already quite a lot of them included for the first release.

Is there anything you are missing, want to change or have any concern with?

Cheers, Marco

[laurajanegraham]

Hi @marcosci,

This is all looking great :) I'm sorry I've not had much time to contribute to this. Is there anything I can do to be helpful in the lead up to submitting to CRAN? I'll absolutely have a look over and make suggestions when I get change (in the next week or so), but if there is anything specific that I can do please let me know.

Laura

[jhollist]

I have the same comment as @laurajanegraham. I'm happy to take a pass through the vignettes.

[marcosci]

No worries :-)

I think that a huge benefit of the package would be a clearer documentation as competitors - maybe if you find something there? Or you have the feeling that some examples on the homepage are missing.

Thanks @jhollist :-)

[jhollist]

Oh, and FANTASTIC job on this.

As of now I am planning on attending USIALE this year. If anyone else is going, perhaps we could organize a workshop? I, of course, will need to get some hands on time with the package.

[laurajanegraham]

Great, shall focus on documentation when I look over it.

@jhollist Workshop at USIALE sounds like a great plan. I'd really like to go, but need to work out whether it's going to be possible. UK-IALE seems to not be happening this year, but the World congress is in Europe next year (Italy), so we could aim for a workshop there too perhaps? I'll keep an eye out for the calls.

[jhollist]

Italy would be great, but my chances of making that are likely near 0 😞

But we could all collaborate on development of workshop materials and then we could each present the workshop at the meeting we can attend?

[marcosci]

we just opened a new github organization for landscape ecology and moved the package there - should make admin stuff of the github part easier (if you have a nice package that fits in the context (looking at you, grainchanger :stuck_out_tongue: would be cool to have a central place for such packages in this thing).

i would close this issue here now - you all have write access, so if you stumble upon something in the future, feel free to change :-)

[laurajanegraham]

I have some time to have a look over the package this afternoon - is it still worth doing, or have you started the CRAN submission process already?

I was thinking grainchanger might fit nicely into this group of packages. The paper outlining the method is currently in review. The package itself needs improving - it's currently based on the raster focal function, but that is incredibly slow, so I'm trying to speed it up by linking to github.com/ahhz/raster. Sadly my C++ skills are terrible, so it's taking a while.

[mhesselbarth]

Sorry, but we just submitted it to CRAN this morning...Hope this is ok for you!

[laurajanegraham]

No problem, I'm sorry I didn't get around to it. I did think you may have already submitted from some stuff I saw on twitter. Good luck and fingers crossed all goes well!

[Nowosad]

@laurajanegraham, please still take a look at the package today. Your opinions/ideas can be used for the next CRAN release.

[laurajanegraham]

Okay, I shall do.

[marcosci]

Sure thing :-) Your input is more than welcome :)

And drop me a mail regarding grainchanger - I really like the idea and if you like I can have a look at it :)

[laurajanegraham]

Great! Shall send you a mail - I have some questions about integrating existing c++ code into an r package that you may be able to help with...