Giters

ropensci / software-review

rOpenSci Software Peer Review.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

NLMR

marcosci opened this issue · comments

commented

Summary

  • What does this package do? (explain in 50 words or less):

    • Provides neutral landscape models and utility functions to work with and extend them. NLMR uses raster as its geospatial framework and can therefore easily be used in landscape analysis to test against the influence of landscape patterns and serve as a basis for spatial simulation modeling.

  • Paste the full DESCRIPTION file inside a code block below:

Package: NLMR
Type: Package
Title: Simulating Neutral Landscape Models
Version: 0.2
Authors@R: c(person("Marco", "Sciaini", email = "sciaini.marco@gmail.com", role = c("aut", "cre")), 
    person("Matthias", "Fritsch", email = "matthias.fritsch@forst.uni-goettingen.de", role =  c("aut")),
    person("Craig", "Simpkins", email = "simpkinscraig063@gmail.com", role =  c("aut")),
    person("Cédric", "Scherer", email = "cedricphilippscherer@gmail.com", role =  c("ctb"), comment = "Implemented nlm_neigh"))
Description: Provides neutral landscape models 
    (Gardner et al. 1987 <doi:10.1007/BF02275262>,
    With 1997 <doi:10.1046/j.1523-1739.1997.96210.x>) that can easily extend in 
    existing landscape analyses. Neutral landscape models range from "hard" 
    neutral models (completely random distibuted), to "soft" neutral models (definable spatial characteristics) and 
    generate landscape patterns that are independent of ecological processes.
    Thus, these patterns can be used as null models in landscape ecology. 'NLMR' 
    combines a large number of algorithms from other published software for simulating neutral landscapes (Saura & 
    Martínez 2000   <doi:10.1023/A:1008107902848>, Etherington et
    al. 2015 <doi:10.1111/2041-210X.12308>) and
    includes utility functions to classify and combine the multiple landscapes. The 
    simulation results are obtained in a geospatial data format (raster* objects 
    from the 'raster' package) and can, therefore, be used 
    in any sort of raster data operation that is performed with standard 
    observation data.                                                                                                  
License: GPL-3
Copyright: file inst/COPYRIGHTS
Encoding: UTF-8
LazyData: true
ByteCompile: true
Depends:
    R (>= 3.1.0)
RoxygenNote: 6.0.1
Imports:
    checkmate,
    dismo,
    dplyr,
    ggplot2,
    igraph,
    magrittr,
    purrr,
    RandomFields,
    raster,
    rasterVis,
    sp,
    spatstat,
    stats,
    tibble,
    viridis,
    extrafont
URL: https://marcosci.github.io/NLMR/
BugReports: https://github.com/marcosci/NLMR/issues/
Suggests:
    testthat,
    covr,
    knitr,
    rmarkdown,
    lintr
VignetteBuilder:
    knitr

  • URL for the package (the development repository, not a stylized html page):

  • Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):

    • geospatial data, because the package simulates land use patterns in a geospatial format.
    • Exploratory data analysis, because the package can be used as a very fundamental null hypothesis in any analysis that formulate questions around the influence of landscape pattern on processes (e.g. ecological, social processes),

  •   Who is the target audience and what are scientific applications of this package?  

    • Target audience: Mainly ecologists, since neutral landscape models are a well-established method in their field. But the package itself can be used by a broad audience, as it is convenient way to quickly prototype spatial simulation models.
    • Scientific applications: Formulating null hypotheses in a landscape analysis, test and develop landscape metrics, gradient analysis of the influence of landscape patterns on ecological processes, starting point for spatial simulations, such as agent-based models.

  • Are there other R packages that accomplish the same thing? If so, how does
    yours differ or meet our criteria for best-in-category?

    • There was ecomodtools, which could simulate a small fraction of the neutral landscape models in NLMR. But it is not under active development anymore and does not compile under newer R versions.

  •   If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

Requirements

Confirm each of the following by checking the box. This package:

  • does not violate the Terms of Service of any service it interacts with.
  • has a CRAN and OSI accepted license.
  • contains a README with instructions for installing the development version.
  • includes documentation with examples for all functions.
  • contains a vignette with examples of its essential functions and uses.
  • has a test suite.
  • has continuous integration, including reporting of test coverage, using services such as Travis CI, Coveralls and/or CodeCov.
  • I agree to abide by ROpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Publication options

  • Do you intend for this package to go on CRAN? (it already is)
  • Do you wish to automatically submit to the Journal of Open Source Software? If so:
    • The package has an obvious research application according to JOSS's definition.
    • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
    • The package is deposited in a long-term repository with the DOI:
    • (Do not submit your package separately to JOSS)
  • Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:
    • The package is novel and will be of interest to the broad readership of the journal.
    • The manuscript describing the package is no longer than 3000 words.
    • You intend to archive the code for the package in a long-term repository which meets the requirements of the journal.
    • (Please do not submit your package separately to Methods in Ecology and Evolution)

Detail

  • Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

    • No errors/warnings

  • Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

  • If this is a resubmission following rejection, please explain the change in circumstances:

  • If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

commented

Hi Folks,

was quite unsure about the fit of our package into the rOpenSci world - but we would love to get your review and platform.

Best wishes,
Marco

commented

thanks for your submission @marcosci we've been discussing and will get back to you asap

commented

Editor checks:

  • [x ] Fit: The package meets criteria for fit and overlap
  • [ x] Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
  • [ x] License: The package has a CRAN or OSI accepted license
  • [ x] Repository: The repository link resolves correctly
  • Archive (JOSS only, may be post-review): The repository DOI resolves correctly
  • Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

Editor comments

Thanks for your submission @marcosci! I'm currently looking for reviewers. I have these comments/questions:

  • goodpractice::gp() returned "♥ Ahh! Rad package! Keep up the tiptop work!" which I had to pass on. 😉

  • the copyright file is for a font, where is this font used?

  • please add this badge to the repo README

Reviewers: @laurajanegraham @jhollist
Due date: 2018-02-21

commented

Hey @maelle and @sckott,

thanks a lot for the effort :)

The font is used in the theme function (theme_nlm) and can be imported via
util_import_roboto_condensed.

Which badge? :) There seems to be something missing in your reply.

commented

Oops indeed! 🙀 [![](https://badges.ropensci.org/188_status.svg)](https://github.com/ropensci/onboarding/issues/188)

commented

@laurajanegraham @jhollist thanks for accepting to review this package! 😺

Your review is due on 2018-02-21.

Please find here our reviewing guide and the review template.

commented

@laurajanegraham @jhollist just a friendly reminder that your reviews are due on 2018-02-21 😸

commented

Starting to look at it now! I do have a question. Next week is crazy for me as it is school vacation week. OK for a 7-10 day extension?

commented

@jhollist ok, thanks for the update! March the 1st?

commented
commented
commented

Thanks a lot @laurajanegraham! 😃

commented

@marcosci the branch that's stable for review is the master branch right? I see recent activity in the repo. 😉

commented

Yup :) But develop should also be stable, master contains only the CRAN versions :)

commented

Ok, so which one should the reviewers review?

Can you confirm you're not undertaking any big changes in the package at the moment?

Thank you for your quick answer! 😃

commented

master makes more sense maybe, yes.
We plan to integrate the ecomodtools package and I am in contact with the author - but there is no schedule for that yet :)

commented

OK thanks.

If a big change is planned now, it might make sense to put the review on hold real quick, but as you say it's a plan for the future then that's fine.

commented

I think this is rather something for the next couple of months, so the review should not be affected.

commented

Hi @maelle . It's taking me a little bit longer to do this review than I anticipate. I don't have too much left to do, but would you mind if I get it to you by Friday instead please due to other commitments? Thanks!

commented

No problem, thanks for your work & this update!

commented

Package Review

Hi @maelle and @marcosci, here is my review. I really like this package, and reviewing it has given me a good opportunity to get to know the features in more depth, so thanks both :)

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement ofneed clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 8

Review Comments

The package authors have provided a much needed collection of neutral landscape models for the R platform. I was pleased to see that it was not just a repackaging of the Python nlmpy package, but also provides additional neutral landscape models as well as some utility functions for visualising these landscapes. In terms of statement of need; the README provides a good explanation of the need for the package, but I would also add that it allows users to create NLMs within a self-contained, reproducible framework.

The code is mostly compact, efficient and follows the standards for rOpenSci packages. I have some concerns around the unit tests: the tests check that the output is of the correct form (class, size etc.), but do not go for edge cases, or try to break the functions. I have noted below some specific cases where functions either broke or did not work as expected.

One way in which I would suggest for improvement of the package would be to improve the documentation. It is mostly good, but the amount of information on the functions is variable. I have commented where I think specific functions could do with more documentation below. I do, however, see this as more of a long term thing, rather than something I'd expect to be improved as part of this review process.

The package name is sensible. It is, however, not in lower case as recommended by the packaging guide. The functions and variables all follow rOpenSci guidelines.

Functionality

Below I have outlined some issues I found with some of the functions. I think most of these are pretty easy fixes with the exception of nlm_fBm: I'm not entirely sure that this is fixable, unless I've misunderstood one of the arguments to the underlying RandomFields function, and without being able to include the full range of values, I think it may be better to remove this function.

metric_area: This function will only give the values of either one class, or all classes. For example:

library(NLMR)
x <- nlm_random(100, 100)
y <- c(0.5, 0.25, 0.25)
z <- util_classify(x, y)

metric_area(z, c(1,2))
## Error in `$<-.data.frame`(`*tmp*`, "class", value = c(1, 2)): replacement has 2 rows, data has 3

The problem is in the if(length(poi) == 1) statement. This is not necessary. Any input could be evaluated by the code inside of the if part. Additionally this outputs a dataframe for Proportion_Area, and not a tibble, as stated in the documentation.

nlm_curds & nlm_wheys:

  • No checkmate tests at the beginning.

  • There is borrowed code between these two. It might make sense to combine them (with a wheys T/F option), or to use the nlm_curds function inside nlm_wheys instead of repeating the code.

  • These seem quite different in the way they are written to the other functions. Primarily in that the others all specify nrow, ncol, resolution, whereas these specify extent. Is it possible to harmonise these?

nlm_edgegradient: The call to nlm_planargradient (L66) is misspecified. It should be
gradient_raster <- nlm_planargradient(ncol, nrow, direction = direction)

or

gradient_raster <- nlm_planargradient(ncol, nrow, resolution, direction)

or change the order of the arguments to nlm_planargradient

nlm_fbm:

  • Add in checkmate::assert_true(fract_dim > 0).
  • The code checks that fract_dim is < 2, but the help file states that this parameter is including 2 - fract_dim = numeric in (0, 2]
  • Values of fract_dim between ~1.56 and ~1.99 generate an error. This is caused by the RandomFields::RFsimulate function.
fBm_raster  <- nlm_fBm(ncol = 20, nrow = 30, fract_dim = 1.9)
## Error in rfInit(model = list("Simulate", setseed = eval(parse(text = "quote(set.seed(seed=seed))")), : searching a simulation method for 'RMfbm':  Running out of list of methods. Are the RFoptions() too restrictive?
##  You get (more) internal information if you set RFoptions(cPrintlevel=3) before running your code.

  • In the details for this function, you state Implementation of this method is limited to landscapes with extents less than 90 by 90 cells., I would recommend also putting in an assert_true statement to this effect.

  • If this function is run with a random seed, it holds onto it until a new seed is set. This can be fixed by removing the if (!is.null(user_seed)) statement. The default user_seed = NULL will set the seed back to NA.

nlm_fBm(ncol = 20, nrow = 30, fract_dim = 1, user_seed = 30)
## NOTE: simulation is performed with fixed random seed 30.
## Set 'RFoptions(seed=NA)' to make the seed arbitrary.

## class       : RasterLayer 
## dimensions  : 30, 20, 600  (nrow, ncol, ncell)
## resolution  : 1, 1  (x, y)
## extent      : 0, 20, 0, 30  (xmin, xmax, ymin, ymax)
## coord. ref. : NA 
## data source : in memory
## names       : layer 
## values      : 0, 1  (min, max)

nlm_fBm(ncol = 20, nrow = 30, fract_dim = 1)
## NOTE: simulation is performed with fixed random seed 30.
## Set 'RFoptions(seed=NA)' to make the seed arbitrary.

## class       : RasterLayer 
## dimensions  : 30, 20, 600  (nrow, ncol, ncell)
## resolution  : 1, 1  (x, y)
## extent      : 0, 20, 0, 30  (xmin, xmax, ymin, ymax)
## coord. ref. : NA 
## data source : in memory
## names       : layer 
## values      : 0, 1  (min, max)

nlm_gaussianfield:

  • See above issues with setting the random seed in nlm_fBm

  • Setting the mean value of the field doesn't work because of the line pred_raster <- pred_raster - raster::cellStats(pred_raster, "min"). Is there a purpose for this line of code? Removing this produces Gaussian random field surfaces with the given mean.

  • Add lower = 0 to the checks for resolution, mag_var and nug

  • Some additions to the documentation could improve the usability of this function. I would recommend further explanation of what each of the variance parameters do, in a way that the implications for the generated surface can be interpreted. My understanding of these are that:

    • mag_var sets the variation of the broad landscape
    • nug sets the variation within the scale of autocorr_range: low nug values will produce a highly spatially autocorrelated surface and high nug values a rougher surface.

  • Missing a reference, which would be useful for users to get a better understanding of how this function works.

nlm_mosaicfield:

  • The collect stage overwrites the first step, need to change the for loop on line 91 to for (i in 2:n) (can also remove the i <- 2 from line 86)

  • In addition, so more information about how these work, and when you would use them would be useful.

nlm_mpd:

  • Generally really clearly explained - more detail on what effect changing rand_dev has on the end landscape would be useful. From some experimenting, it looks like it just changes the overall variance of the landscape.

nlm_neigh:

  • Additional checks: set lower and upper values in the assert_numeric statement for p_neigh and p_empty; check neighborhood contains the accepted values; check proportions sums to 1.

  • Note on the last one - it's important because if proportions do not sum to 1, then the remaining cells are assigned to class 0, meaning that proportions = c(0.1, 0.1, 0.1) would result in a landscape with 80% class 0 and 10% the other two.

  • Because the categories are integers, it doesn't make sense to rescale the raster for this function. I would suggest defaulting to FALSE or getting rid of the option altogether.

  • rev(proportions) on line 91 means that the proportions are assigned to the categories backwards. e.g. nlm_neigh(ncol = 50, nrow = 50, p_neigh = 0.5, p_empty = 0.5, categories = 2, proportions = c(0.75, 0.25)) will result in a landscape where 25% is assigned to 0 and 75% to 1. This could be confusing when the proportions are closer.

nlm_polylands:

  • I wonder if this would be simpler split into two functions for each of the options. I understand the thinking behind keeping them as one, but as there are no shared outputs, and few shared parameters, they may make more sense separately.

  • Some more information about what each of the parameters does here would be useful. For example, parameter R for option 2 is described as the interaction radius. I assumed this was related to the size of the landscape, so put in a value of 3 (so assuming that cells within a distance of 3 cells from each other are interacting). This causes the function to hang. It's the spatstat::rStrauss(200, gamma = g, R = R) that is doing this, and I found that it wouldn't run for me for a value of R > 0.1 (using g = 0.5).

  • like with nlm_neigh, rescale doesn't make sense here.

nlm_randomcluster:

  • The neighbourhood input is an integer here, whereas it was method names in nlm_neigh. It would be helpful to unify this (and the spelling of neighbourhood - one US, one British English). My preference would be the numbers, because I always forget the names and it's less to type!

nlm_randomrectangularcluster:

  • Should there also be a test that minl < maxl?

util_calc_boundaries and util_w2cp:
should these be exported, or are they meant to be internal functions?

util_facetplot: is it possible to add a nrow or ncol option into here to control how the facet is laid out?

commented

@laurajanegraham thanks a lot for your excellent review! 👌 👏

@marcosci you can keep the name of the package now that it's on CRAN, not a strict rule on our part. :-) you can wait for the second review before responding if you prefer!

commented

thanks @laurajanegraham for your effort - really appreciate it 👍
didn't find anything that should not be fixable in my head - will wait for Jeff and then go through your code and test comments.

and your definitely right - the documentation needs improvement ... we're on it. 🚶

commented
commented

Here is my review! In short, I like the package and hope to find some uses for it. I also have review envy. Really nice job on your review, @laurajanegraham !!!

Any questions, let me know.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing:
~ 8 hours

Review Comments

General Comments

The NLMR package provides a suite of functions to simulate neutral landscapes with multiple algorithms plus a set of utility functions for working with the resulting raster objects. As a landscape ecologist who cut his teeth when many of these neutral landscapes were being developed, seeing them implemented as an R package was exciting. Their implementation in NLMR is nice and the functions are straightforward to use. There are a few improvements that need to be made. When those are done I feel this will be a very nice addition to the rOpenSci suite of packages. That it is in my home field is a really nice added bonus. In short, very nice work. Now I need to find a reason to dig back into neutral landscape models!

Package Review Checklist

Few notes on the Package Review checklist above. I did not check off Vignettes, Community guidelines and Packaging guidelines. Details on each:

  • Vignettes: There are a number of vignettes and not all are finished and it appears the primary utilitiy for some of them is to populate sections the project website. Having these unfinished vignettes on CRAN and as part of the installed package should be avoided. I would like to see just the "getstarted" vignette, and, when completed, the "background" vignette. I am not sure if this will solve the issue, but perhaps adding the vignettes you don't want pushed to CRAN to .Rbuildignore will allow you to build the package for submission but still use those vignettes for the website. Just a guess on my part that this will work.
    • Also, in "getstarted", I'd drop the raster section. It is useful, but beyond scope of this vignette.
  • Community guidelines: Main issue here was lack of a CONTRIBUTING or details about contributing in the README. For an example look at, https://github.com/ropensci/scrubr/blob/master/CONTRIBUTING.md
  • Packaging guidelines: Seem to have most of these done, but a few things still need to be taken care of (e.g. add in the ropensci review badge). Make sure you adhere to the guidelines at https://github.com/ropensci/onboarding/blob/master/packaging_guide.md. One big one here is the package name. I know it is already on CRAN as NLMR, but changing to nlmr would adhere to the guidelines and could be accomplished if you make some changes to the scope of the package. Details on this I have provided below under "Package Scope." I'll defer to rOpenSci editors on importance of the lower case package names.

Specific Thoughts

See below for some more specific suggestions.

Package Scope

Some general thoughts and suggestions on the overal scope of the package. I personally am a fan of trying to keep packages as streamlined as possible. NLMR currently has two main types of functions, the nlm_ functions an the util_ functions. I could easily see these being split into to separate functions. If you do this it could faciliate re-naming the package (see above on NLMR vs nlmr) and creating a new "utilities" package. This works, I think, because it would make maintaing the pacakges easier, and would also get more exposure to some of the utlity functions which seem a bit more general purpose for rasters and not just neutral landscapes. Additionally, in issue 10 you suggest landscape metrics as a possible enhancement. I personally think incorporating that into NLMR would be a mistake since those types of functions have utility well beyond applications geared towards neutral landscapes. Many of the traditional "FRAGSTATS" type metrics already do exists in the `SDMTools' package, but that hasn't seen any updates in ~4 years. As such, developing a standalone landscape metrics package is, I believe, an excellent idea. In any event, I would encourage (and likely contribute to) a R landscape metrics package, but strongly believe that be done on its own and not incorportated into another pacakge.

Dependencies

Somewhat following on my discussion of scope are the number of dependencies that NLMR currently has. I prefer to keep my packages as light as possible and rely on base R whenever possible. I would like to see some thinning of the dependencies on this. For example, you import magrittr. While, I love magrittr in analysis workflows I avoid its use in packages as it is an unnecessary dependency and, in my experience, can make de-bugging a bit challenging. Look for opportunities like this to drop some of the packages you import.

Future-proofing

It is an exciting time to be working on spatial data in R, but also challenging becuase the underlying packages supporting spatial data in R are in a bit of flux. Currently, NLMR relies on raster and sp, which are the traditional spatial pacakges. However, with the release of sf, the development of stars, and discussions about the future of raster you will need to be actively thinking about how to make sure that NLMR stays relevant and incorporates the new directions for spatial data in R. And as I am writing this, I had the idea that this would be a good opportunity to split up the pacakge (e.g. see Package Scope). New and more streamlined packages could be developed that also build off of the newer and tidier set of spatial packages.

Misc

A few miscellaneous thoughts:

  • On documenting the function arguments: I have not seen the [numerical], [Raster* object] kind of formatting before. Part of me likes it (i.e. it is precise) but another part doesn't as it is different that most R function documentation. I'd defer to rOpenSci guidance on this.
  • Most of your functions are standardized with arguments for number of rows, columns, extent, rescaling, etc. (i.e. real-world coordinates). I didn't see these for the curd and whey functions. Is it possible to have those use the same set of common arguments? In short, whenever possible, try to make the arguments, and their order, common.
  • util_import_roboto_condensed is this necessary? For a package like this it makes more sense to stick with defaults on this so that extra dependencies and functions like this aren't needed.
  • Two things on metric_area
    • instead of a list, I'd have this return a data frame with four columns: count, total_area, proportion, and class. If you keep as a list change name of column in $Porportion_Area from count to proportion.
    • Maybe have this as another util_ function.
commented

thanks @jhollist - I like your thoughts, nice complement to Laura's comments :-)

Will tackle both reviews in the next days and report here.

commented

Thanks a ton @jhollist, what a good review! 😃

Nice plan @marcosci! 😉

commented

Aw thanks @jhollist . I like the suggestion of narrowing the package scope and splitting into two packages. The util functions definitely are useful beyond just NLMs.

I would also be interested in contributing to a standalone landscape metrics package, should this happen.

commented

Added two small things related to metric_area to my review above... Slipped through the cracks first time around.

commented

A few notes:

  • It's fine to keep the name all uppercase since it's on CRAN but if you go forward with the splitting changing it to lowercase might be best. By the way if you split the package, the one that'd still be a good fit for onboarding is the non-metrics one. Recently we had another submission where the package ended up being split during review, see Miles' comment. If you go forward with splitting, then it might be good to have a chat with MEE editors, since I imagine you'd try to submit a manuscript about two packages born from this review, of which only one would have been transferred. 🤔

  • Regarding vignettes that are not on CRAN as inspiration you could have a look at what usethis does. There's an article about setup that's on the pkgdown website but not as vignette. https://github.com/r-lib/usethis

Thanks again to both reviewers, and nice work until now @marcosci!

commented

Response to reviews

@laurajanegraham and @jhollist - thanks again for your reviews

We decided to follow the recommendations of Laura and Jeff to split the package. This leaves us with:

  • nlmr
    • nlmr is now a trimmed down version of NLMR, only containing the algorithms to simulate neutral landscape models. Hence, the (direct) dependencies are quite small.
  • landscapetools
    • Here we gathered all the utility functions and visualization functions from NLMR. There is no package to facilitate the workflow in the context of landscape analysis, so there should be potential for growth.
  • landscapemetrics
    • Since there wasn't much implemented in NLMR yet, it is still pretty empty. But Laura said that she would be interested in working on it with us and Jeff will be our mascot - looking forward to it :)

@maelle, you said:

By the way if you split the package, the one that'd still be a good fit for onboarding is the non-metrics one.

... my gut feeling says that only the nlmr package is now of interest and not the combination of landscapetools and nlmr (however this combination may look like - meta package, second onboarding issue, ...)? If I am mistaken, I will provide comments on the reviewers' remarks on the utility functions. Otherwise, I will focus for now on nlmr.

responses to @laurajanegraham comments

nlm_curds & nlm_wheys:

We combined both functions. You get the wheyed pattern now by providing the argument wheyes (#16). Since you recursively subdivide the landscape into smaller and smaller blocks, I can not think of an efficient way to implement this whole specifically controlling for nrow and ncol.

nlm_edgegradient:

We did that here #17.

nlm_fbm:

Values of fract_dim between ~1.56 and ~1.99 should work now if you set the RandomFields option
to sloppy. You can do that now via the nlm_fBm function - we are not quite sure why you have to do
this, but we contacted the maintainer of RandomFields and as soon as we know more, we will implement it.
At least the functions produce now valid patterns for the whole range of fract_dim.
We also implemented the rest of your comments, see
#18.

nlm_gaussianfield

Made all perfect sense, we implemented everything you said
#19.

nlm_mosaicfield

We fixed the issue with the loop - #20.

nlm_neigh

Again, we changed everything as you recommended :) #22

nlm_polylands

We changed the name of this function, splitted it and got rid of nlm_randomelement.
nlm_randomelement and nlm_polylands both rely on the simulation of point pattern processes
and a spatial interpolation of these patterns.
Since we use the well-established spatstat package to simulate the point patterns, we do not need
nlm_randomelement as a direct copy of its NLMpy equivalent and can combine the first option of
nlm_polylands and nlm_randomelement.

The two new functions are: nlm_mosaictess (a unified version of option 1 on
nlm_polylands and nlm_randomelement) and nlm_mosaicgibbs.

In nlm_mosaicgibbs we changed the function to control the hardcore process that
creates the spatial point pattern, it should be faster now and takes fewer arguments
to control the output.

All that should be in #23.

nlm_randomcluster

We had a look at that function again and completely changed it after your comments.
Again, it was a direct copy as it is done in NLMpy - but the implementation in NLMpy is
actually not the algorithm they cited as reference.

It is now a direct implementation of the random cluster algorithm by Saura et al. (2000),
and you can control for all the parameters they state in their publication.

See our changes in #33.

nlm_randomrectangularcluster

Check: #25

Documentation

We did some pieces here and there and Craig is currently going through that again. Hope that is fine with you? :)

responses to @jhollist comments

Vignettes

We had a look on the way usethis is doing that (thanks @maelle for the hint),
and for now only the getstarted vignette is part of the package. The rest is only
visible on the homepage.

Craig is currently working on the vignettes and documentation to make it a bit more verbose,
but we already got rid of the raster section.

Community guidelines

Check: #28

Package Scope

As stated at the beginning, by splitting the package the scope of them should
be rather streamlined now.

Future proofing

We changed every function that used sp functions to sf, there is no direct dependency on sp anymore.
However, I see no point at the moment to use stars. As far as I know, the future of the raster package
is still rather vague - the last thing I have read was that 2D raster should find a unified home in raster as a single raster class and more dimensional raster should find their home in stars. If I am mistaken here, or you see a way to use stars here please let me know.

commented

First, I'd be honored to be the mascot!!! If time allows, would be happy to more than that too.

Second, very happy with the response and direction this is taking. Two thumbs up on everything and as far as my review is concerned, nlmr is good to go.

Again, really nice job. Makes me happy to see landscape ecology getting better representation in R!

commented

Response to reviews regarding the utility functions

With respect to the comments on slack yesterday, this issue is supposed to cover
now both nlmr and landscapetools.

Again, you can find landscapetools here:

https://github.com/marcosci/landscapetools

responses to @laurajanegraham comments

util_calc_boundaries and util_w2cp

Both of the functions are only internal ones, for the reclassification function.
I can't see any direct use of them - if I am mistaken, we can certainly make
them public.

util_facetplot

You can now specify the number of rows and cols, see #26.

responses to @jhollist comments

util_import_roboto_condensed
is this necessary?

I see some value in providing a font with better kerning pairs and geometrics numbers
(compared to the default font ggplot uses). If the dependency on extrafont is not worth it
in your opinion, we can definitely cut that.

... did I miss anything regarding the utility functions?

General

As discussed on twitter, I included both of you in the respective description of the
packages - thanks a lot again :)
And the mascot comment was just a joke - we would definitely benefit from your input Jeff :)

commented
commented

All looking great @marcosci!

commented

Thanks a lot for your work @marcosci and thanks @jhollist & @laurajanegraham for very productive reviews! 🎊

A few last comments from me:

  • In all three repos, I think it'd make sense to comment a bit on all of them, maybe in a "See also" section.
  • Add the pkgdown link to DESCRIPTION, see http://enpiar.com/2017/11/21/getting-down-with-pkgdown/ "if you already have a URL there (say, to your package’s GitHub repository), you can add a second URL to your pkgdown site, separated by a comma"
  • In the pkgdown website (of landscapetools in particular) you might want to make the grouping of functions in reference more useful. See https://github.com/dirkschumacher/ompr for an example

Now here is the list of things you have to do before I close this issue 😉

  • [] Transfer the repos to the rOpenSci organization under "Settings" in your repo. I have invited you to two teams that should allow you to do so. You'll be made admin once you do.
  • [] Add the review badge to landscapetools repo too.
  • [] Fix any links in badges for CI and coverage to point to the ropensci URL

Welcome aboard! We'd also love a blog post about your package, either a short-form intro to it (https://ropensci.org/tech-notes/) or long-form post with more narrative about its development. ((https://ropensci.org/blog/). If you are, @stefaniebutland will be in touch about content and timing.

commented

Yeah 🙌

@maelle comments

In all three repos, I think it'd make sense to comment a bit on all of them, maybe in a "See also" section.

You mean crossreferencing nlmr and landscapetools in the readmes of the packages? :)

Add the pkgdown link to DESCRIPTION, see http://enpiar.com/2017/11/21/getting-down-with-pkgdown/ "if you already have a URL there (say, to your package’s GitHub repository), you can add a second URL to your pkgdown site, separated by a comma"

Done.

In the pkgdown website (of landscapetools in particular) you might want to make the grouping of functions in reference more useful. See https://github.com/dirkschumacher/ompr for an example

Done.

@maelle list of things

  • Transfer the repos to the rOpenSci organization under "Settings" in your repo. I have invited you to two teams that should allow you to do so. You'll be made admin once you do.
    • Was a bit too ambitious and happy there - transferred nlmr before changing the repo description (changing marcosci to ropensci). Could you change that for me ? Sorry. 🙇
  • Add the review badge to landscapetools repo too.
  • Fix any links in badges for CI and coverage to point to the ropensci URL

And we would be more than happy to write a blog post 😄

commented

Thanks!

Yes I meant cross-referencing with a short blurb explaining how they relate to each other.

I've now made you an admin of both repositories (so you can access the repo description again for instance) and will activate them on Appveyor.

commented

Appveyor badges

  • [![Build status](https://ci.appveyor.com/api/projects/status/djw840fitcvolbxg?svg=true)](https://ci.appveyor.com/project/ropensci/nlmr)

  • [![Build status](https://ci.appveyor.com/api/projects/status/aehfkxfb5r4vjlm9?svg=true)](https://ci.appveyor.com/project/ropensci/landscapetools)

Closing this since the blog post discussion can still happen once it's closed. :-)

commented

I forgot two points @marcosci 🙈

commented

I am here to serve 😜 all done.

commented

😂 thx a ton!

commented

Glad to hear you're interested it writing a post @marcosci. Here are some technical and editorial guidelines: https://github.com/ropensci/roweb2#contributing-a-blog-post

We ask that you submit a draft via pull request at least one week before the planned publication date. At this point I have posts scheduled through April so perhaps best for you to suggest a deadline by which you would like to submit a draft.

commented

Hi @stefaniebutland and thanks :-) Would the last couple of days in April be fine to hand in the draft for the blog post?

commented

Yes @marcosci end of April for a draft is good. Tentative publication date is Tues May 8 so latest to submit draft is May 1st. Thanks!