NLMR

[marcosci]

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):

  • https://github.com/marcosci/NLMR

• 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:

[marcosci]

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

[sckott]

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

[maelle]

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

[marcosci]

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.

[maelle]

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

[maelle]

@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.

[maelle]

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

[jhollist]

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?

[maelle]

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

[jhollist]

Perfect and thank you.

…

On Feb 16, 2018 11:35 AM, "Maëlle Salmon" ***@***.***> wrote: @jhollist <https://github.com/jhollist> ok, thanks for the update! March the 1st? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFL8SyqLmwOuTY6ufoDmLMZA4r31u6a4ks5tVa46gaJpZM4RrS2f> .

[laurajanegraham]

Hi, Thanks for the reminder. I have put time aside Monday and Tuesday to get this review done. Cheers, Laura On 16 Feb 2018 16:51, "Jeffrey W Hollister" <notifications@github.com> wrote:

…

Perfect and thank you. On Feb 16, 2018 11:35 AM, "Maëlle Salmon" ***@***.***> wrote: > @jhollist <https://github.com/jhollist> ok, thanks for the update! March > the 1st? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#188 issuecomment-366287026>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ AFL8SyqLmwOuTY6ufoDmLMZA4r31u6a4ks5tVa46gaJpZM4RrS2f> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFFAxGeEQEKLGiUlcp5583hUVTfLdVq-ks5tVbICgaJpZM4RrS2f> .

[maelle]

Thanks a lot @laurajanegraham! 😃

[maelle]

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

[marcosci]

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

[maelle]

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! 😃

[marcosci]

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 :)

[maelle]

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.

[marcosci]

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

[laurajanegraham]

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!

[maelle]

No problem, thanks for your work & this update!

[laurajanegraham]

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?

---

[maelle]

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!

[marcosci]

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.

[jhollist]

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!

[marcosci]

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 :)

[jhollist]

A joke I appreciated! Also probably to most likely level of involvement I can promise. I am begrudgingly well entrenched in mid-career and as such time to work on things I want to is a rare commodity. And again, nice job on these packages. I'll include a mention in a talk I am working on for US-IALE.

…

On Thu, Mar 22, 2018 at 6:00 AM, Marco Sciaini ***@***.***> wrote: 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 <https://github.com/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 <ropensci/NLMR#26>. responses to @jhollist <https://github.com/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 :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFL8S6VbHkX_ly9FwR2lcsbvpbODWHf7ks5tg3YhgaJpZM4RrS2f> .

-- Jeff W. Hollister email: jeff.w.hollister@gmail.com cell: 401 556 4087

[laurajanegraham]

All looking great @marcosci!

[maelle]

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.

[marcosci]

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 😄

[maelle]

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.

[maelle]

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. :-)

[maelle]

I forgot two points @marcosci 🙈

• In your .github dir can you also add a CONTRIBUTING.md and a PR template, see https://github.com/ropensci/dotgithubfiles/ for examples

• We're starting to roll out software metadata files to all rOpenSci packages via the Codemeta initiative, see https://github.com/ropensci/codemetar/#codemetar for how to include it in your package, after installing the package - should be easy as running codemetar::write_codemeta() in the root of your package.

[marcosci]

I am here to serve 😜 all done.

[maelle]

😂 thx a ton!

[stefaniebutland]

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.

[marcosci]

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

[stefaniebutland]

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!