SSARP: Easily Create Species- and Speciation- Area Relationships Using Web Databases

[kmartinet]

Date accepted: 2025-09-17

Submitting Author Name: Kristen Martinet
Submitting Author Github Handle: @kmartinet
Repository: https://github.com/kmartinet/ssarp
Version submitted: 0.2.0
Submission type: Standard
Editor: @jhollist
Reviewers: @txm676, @joelnitta

Archive: TBD
Version accepted: TBD
Language: en

---

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

Package: ssarp
Type: Package
Title: SSARP (Species-/Speciation-Area Relationship Projector)
Description: Create Species- and Speciation-Area Relationships for any taxa.
Authors@R: person("Kristen", "Martinet", email = "kmartinet@outlook.com", role = c("aut", "cre"))
Maintainer: Kristen Martinet <kmartinet@outlook.com>
Version: 0.2.0
URL: https://github.com/kmartinet/ssarp, https://kmartinet.github.io/ssarp/
BugReports: https://github.com/kmartinet/ssarp/issues
Imports: 
  ape,
  checkmate,
  cli,
  Dict,
  dplyr,
  epm,
  httr,
  mapdata,
  maps,
  rgbif,
  segmented,
  stringi,
  tidyr
LazyData: true
Encoding: UTF-8
License: GPL (>=2)
RoxygenNote: 7.3.2
Roxygen: list(markdown = TRUE)
VignetteBuilder: knitr
Depends: 
    R (>= 4.3.0)
Suggests: 
    testthat (>= 3.0.0),
    rmarkdown,
    knitr (>= 1.46)
Config/testthat/edition: 3

Scope

• Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):

  • data retrieval
  • data extraction
  • data munging
  • data deposition
  • data validation and testing
  • workflow automation
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • field and lab reproducibility tools
  • database software bindings
  • geospatial data
  • text analysis

• Explain how and why the package falls under these categories (briefly, 1-2 sentences):

The SSARP R package provides a smooth workflow for obtaining occurrence records for taxa of interest from GBIF (through the use of rgbif utilities), associating GPS points with appropriate landmasses, getting the area of those landmasses, calculating speciation rates, and creating species- and speciation-area relationships.

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

SSARP's target audience includes researchers who want to create species- and speciation-area relationships in order to visualize trends in biodiversity across island (or island-like) systems globally. Species- and speciation-area relationships are useful for determining whether biodiversity is distributed in an unusual way in a given island system (e.g., species richness decreasing as islands get larger instead of increasing). An unusual trend in these relationships may be indicative of habitat loss or a negative impact of non-native species.

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

No other R packages provide the workflow that SSARP provides, but there are other R packages that provide some of the functionality. The sars package fits several models for species-area relationships. The CoordinateCleaner package provides a robust suite of methods to clean occurrence record data (e.g., filtering out invalid GPS locations).

• (If applicable) Does your package comply with our guidance around Ethics, Data Privacy and Human Subjects Research?

Not applicable

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

Not applicable

• Explain reasons for any pkgcheck items which your package is unable to pass.

Not applicable

Technical checks

Confirm each of the following by checking the box.

• I have read the rOpenSci packaging guide.
• I have read the author guide and I expect to maintain this package for at least 2 years or to find a replacement.

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, created with roxygen2.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, including reporting of test coverage.

Publication options

• Do you intend for this package to go on CRAN?

• Do you intend for this package to go on Bioconductor?

• Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

• 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 (see MEE's Policy on Publishing Code)
• (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no guarantee that your manuscript will be within MEE scope.)
• (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
• (Please do not submit your package separately to Methods in Ecology and Evolution)

Code of conduct

• I agree to abide by rOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

[ropensci-review-bot]

Thanks for submitting to rOpenSci, our editors and @ropensci-review-bot will reply soon. Type @ropensci-review-bot help for help.

[ropensci-review-bot]

🚀

Editor check started

👋

[kmartinet]

@ropensci-review-bot check package

[ropensci-review-bot]

Thanks, about to send the query.

[ropensci-review-bot]

🚀

Editor check started

👋

[ropensci-review-bot]

Checks for SSARP (v0.2.0)

git hash: a48aab43

• ✔️ Package name is available
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 94.5%.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.
• 👀 Function names are duplicated in other packages

(Checks marked with 👀 may be optionally addressed.)

Package License: GPL (>=2)

---

1. Package Dependencies

Details of Package Dependency Usage (click to open)

The table below tallies all function calls to all packages ('ncalls'), both internal (r-base + recommended, along with the package itself), and external (imported and suggested packages). 'NA' values indicate packages to which no identified calls to R functions could be found. Note that these results are generated by an automated code-tagging system which may not be entirely accurate.

type	package	ncalls
imports	ape	NA
imports	checkmate	NA
imports	cli	NA
imports	Dict	NA
imports	dplyr	NA
imports	epm	NA
imports	httr	NA
imports	mapdata	NA
imports	maps	NA
imports	rgbif	NA
imports	segmented	NA
imports	stringi	NA
imports	tidyr	NA
suggests	testthat	NA
suggests	rmarkdown	NA
suggests	knitr	NA
linking_to	NA	NA

Click below for tallies of functions used in each package. Locations of each call within this package may be generated locally by running 's <- pkgstats::pkgstats(<path/to/repo>)', and examining the 'external_calls' table.

NOTE: No imported packages appear to have associated function calls; please ensure with author that these 'Imports' are listed appropriately.

---

2. Statistical Properties

This package features some noteworthy statistical properties which may need to be clarified by a handling editor prior to progressing.

Details of statistical properties (click to open)

The package has:

• code in R (100% in 17 files) and
• 1 authors
• 2 vignettes
• 1 internal data file
• 13 imported packages
• 15 exported functions (median 21 lines of code)
• no non-exported function in R (median lines of code)

---

Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages
The following terminology is used:

• loc = "Lines of Code"
• fn = "function"
• exp/not_exp = exported / not exported

All parameters are explained as tooltips in the locally-rendered HTML version of this report generated by the checks_to_markdown() function

The final measure (fn_call_network_size) is the total number of calls between functions (in R), or more abstract relationships between code objects in other languages. Values are flagged as "noteworthy" when they lie in the upper or lower 5th percentile.

measure	value	percentile	noteworthy
files_R	17	75.0
files_vignettes	2	81.7
files_tests	16	92.8
loc_R	458	43.0
loc_vignettes	89	20.8
loc_tests	374	65.0
num_vignettes	2	85.4
data_size_total	354772	89.7
data_size_median	354772	96.1	TRUE
n_fns_r	15	21.9
n_fns_r_exported	15	58.4
n_fns_r_not_exported	0	0.0	TRUE
n_fns_per_file_r	1	1.9	TRUE
num_params_per_fn	2	26.7
loc_per_fn_r	21	62.2
loc_per_fn_r_exp	21	48.6
rel_whitespace_R	31	59.8
rel_whitespace_vignettes	71	44.1
rel_whitespace_tests	32	73.0
doclines_per_fn_exp	29	31.2
fn_call_network_size	0	0.0	TRUE

---

2a. Network visualisation

Click to see the interactive network visualisation of calls between objects in package

---

3. goodpractice and other checks

Details of goodpractice checks (click to open)

3a. Continuous Integration Badges

GitHub Workflow Results

id	name	conclusion	sha	run_number	date
13313423351	pages build and deployment	success	56721f	19	2025-02-13
13313385891	pkgcheck	success	a48aab	10	2025-02-13
13313385892	pkgdown.yaml	success	a48aab	23	2025-02-13
13313385894	R-CMD-check.yaml	success	a48aab	18	2025-02-13
13313385912	test-coverage.yaml	success	a48aab	12	2025-02-13

---

3b. goodpractice results

R CMD check with rcmdcheck

R CMD check generated the following check_fail:

1. no_import_package_as_a_whole

Test coverage with covr

Package coverage: 94.46

Cyclocomplexity with cyclocomp

The following functions have cyclocomplexity >= 15:

function	cyclocomplexity
findAreas	48
findLand	23
speciationMS	15

Static code analyses with lintr

lintr found no issues with this package!

---

4. Other Checks

Details of other checks (click to open)

✖️ The following 2 function names are duplicated in other packages:

• • getData from astrochron, AutoDeskR, benford.analysis, carat, datapack, EdSurvey, FMM, fPortfolio, kit, mcr, microsamplingDesign, nlme, NUCOMBog, ocd, ProfoundData, RAdwords, RAMClustR, raster, rosetta, rpact, rrcov, sampleVADIR, sBIC, semEff, simr, tabshiftr, TIMP, ufs
• • getSources from madrat, tm

---

Package Versions

package	version
pkgstats	0.2.0.48
pkgcheck	0.1.2.107

---

Editor-in-Chief Instructions:

This package is in top shape and may be passed on to a handling editor

[maurolepore]

Dear @kmartinet thanks for your submission. I'll discuss it with the editorial board. I'll be back in a few days.

For the record I leave a first quick preliminary check so that I can inform the other editors what I see. If we take it, the handling editor may do more complete checks.

Quick preliminary checks:

• Documentation: The package has sufficient documentation available online (README, pkgdown docs) to allow for an assessment of functionality and scope without installing the package. In particular,

  • Is the case for the package well made?

    The case is not made explicitely, but it's implicit form it's goal and the multiple
    processes it automates. It would be nice to see the case for the package
    at the very top of README, following the goal.

  • Is the reference index page clear (grouped by topic if necessary)?

    The functions are not grouped.
    Function names could be more consistent in letter-case and verb-noun structure.

  • Are vignettes readable, sufficiently detailed and not just perfunctory?

    README shows no example.
    The vignettes seem meaningful but show no code output.
    The few helpfiles I explored randomly show no code output.

• Fit: The package meets criteria for fit and overlap.

  TBD

• Installation instructions: Are installation instructions clear enough for human users?

  I see some spatial dependencies that may be hard to install. On my laptop:

  ✖ Failed to build terra 1.8-21 (1.6s)                                  
  

• Tests: If the package has some interactivity / HTTP / plot production etc. are the tests using state-of-the-art tooling?

  From README I expect to interact with an API but in my quick check I haven't seen HTTP tests or dependencies.

  • Contributing information: Is the documentation for contribution clear enough e.g. tokens for tests, playgrounds?

    I don't see instructions to connect to extarnal resources. No token needed?

• License: The package has a CRAN or OSI accepted license.

• Project management: Are the issue and PR trackers in a good shape, e.g. are there outstanding bugs, is it clear when feature requests are meant to be tackled?

  ---

Editor comments

• R/f.R alligns with tests/testthat/test-f. :-)
• I see some style issues. Consider https://style.tidyverse.org/ and https://styler.r-lib.org/
• The code I've seen shows no output. Does it all run?
• At least some calls to expect_error() are inspecific (pick any error).
• I see a few tests for messages. Are they easy to suppress (e.g. in tests)?

[kmartinet]

Hi @maurolepore , thanks so much for your preliminary check! Looking forward to hearing back!

[maurolepore]

@kmartinet you're very welcome. I already advertised the package among editors and I'm still waiting for someone to become available.

If you're available and want to make some progress, then you may start by addressing the issues that take the least effort and make the biggest difference in helping a reviewer understand the package as quickly as possible.

The most obvious place is README. Adding a reproducible example and showing output can help a reviewer understand what the package actually does even before they try to install it.

Another good investment of your time might be on installation. Spatial dependencies can be tricky to install. If you help the reviewers hit the ground running, then the limited time they have can be spent in the kind of feedback that would benefit the package the most.

[kmartinet]

Hi @maurolepore , thanks so much for the guidance! I have more explicitly written the case for the package at the top of the README and added a reproducible example for creating a species-area relationship (SAR). Additionally, the SAR vignette now includes more in-depth discussion about the structure of the objects created by each step of the workflow.

I also re-worked the "speciationDR" function to remove SSARP's dependency on the epm package, which was the only reason why terra was originally part of SSARP's installation.

[kmartinet]

Hi @maurolepore ! I just wanted to check in and ask if my submission is still in the stage where you're waiting for an editor to become available?

Also, I was wondering if you could please elaborate on one of your points above that the helpfiles show no code output? Would it be appropriate to add a comment after each line in the Examples section for each function to describe what the output should be? Or am I misunderstanding your suggestion? Thanks so much!

[maurolepore]

@kmartinet thanks for the reminder. I re-announced the package to our editors and I hope someone responds soon.

Sorry for being vague about the status. Other editors agree that the package is in scope and also that most of the minor issues I noted should be addressed before engaging reviewers. So great you've worked on them.

RE showing output, I meant that it would be useful to see not just the code but also the output that the code produces.

Eg the code '1 + 1' outputs '2'. Last time I checked I saw '1 + 1' but not '2'.

In other words, the source code should be in README.Rmd (not README.md) and rendered to generate README.md automatically. With this approach you never edit README.md manually.

Does that make sense?

[kmartinet]

Thanks so much, @maurolepore !

I've edited my README workflow to match your specifications. The example in the README now shows the first 5 lines of each dataframe that is created in each step of the SSARP workflow, along with a brief description for each output.