Implementation of OPTRAM algorithm to derive soil moisture from remote sensing imagery

[micha-silver]

Submitting Author Name: Micha Silver Submitting Author Github Handle: @micha-silver Other Package Authors Github handles: (comma separated, delete if none) @github_handle1, @github_handle2 Repository: https://gitlab.com/rsl-bidr/roptram Version submitted: 0.0.1.000 Submission type: Standard Editor: @adamhsparks Reviewers: @harryeslick, @obrl-soil

Archive: TBD Version accepted: TBD Language: en

---

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

Package: rOPTRAM
Title: Derive soil moisture using the OPTRAM algorithm
Version: 0.0.1.000
Authors@R: c(
  person("Micha", "Silver", , "[email protected]", role = c("aut", "cre"),
           comment = c(ORCID = "0000-0002-1128-1325")),
  person("Arnon", "Karnieli", , "[email protected]", role = c("ctb", "fnd"),
          comment = c(ORCID = "0000-0001-8065-9793"))
  )
Description: The OPtical TRapezoid Model (OPTRAM) derives soil moisture
  based on the linear relation between a vegetation index
  and Land Surface Temperature (LST). The Short Wave Infra-red (SWIR) band
  is used as a proxy for LST. See:
  Sadeghi, M., Babaeian, E., Tuller, M., Jones, S.B., 2017.
  The optical trapezoid model:
  A novel approach to remote sensing of soil moisture 
  applied to Sentinel-2 and Landsat-8 observations.
  Remote Sensing of Environment 198, 52–68,
  https://doi.org/10.1016/j.rse.2017.05.041 .
License: GPL (>= 3) + file LICENSE
URL: https://gitlab.com/rsl-bidr/roptram.git
BugReports: https://gitlab.com/rsl-bidr/
Encoding: UTF-8
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.2.3
Depends:
  R (>= 4.1.0)
Imports:
    dplyr,
    ggplot2,
    sf,
    terra,
    tools,
    utils
Suggests:
    geojsonio,
    geojsonlint,
    stats,
    sen2r (> 1.5.0),
    testthat (>= 3.0.0),
    xml2
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.):

  • [x] data retrieval
  • [x] 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
  • [x] geospatial data
  • [ ] text analysis

• Explain how and why the package falls under these categories (briefly, 1-2 sentences): This package includes acquiring satellite imagery, and preparing spatially explicit soil moisture raster grids.

• Who is the target audience and what are scientific applications of this package? Researchers in ecology, agriculture, sustainability. Agricultural management of grazing lands, reforestration.

• 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

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

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

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

Technical checks

Confirm each of the following by checking the box.

• [x] I have read the rOpenSci packaging guide.
• [x] 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:

• [x] does not violate the Terms of Service of any service it interacts with.
• [x] has a CRAN and OSI accepted license.
• [x] contains a README with instructions for installing the development version.
• [x] includes documentation with examples for all functions, created with roxygen2.
• [x] contains a vignette with examples of its essential functions and uses.
• [x] has a test suite.
• [x] 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?

• [x] 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

• [x] 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]

Error (500). The editorcheck service is currently unavailable

[maelle]

@ropensci-review-bot check package

[ropensci-review-bot]

Thanks, about to send the query.

[ropensci-review-bot]

Error (500). The editorcheck service is currently unavailable

[maelle]

@micha-silver thanks for your submission! We'll fix this glitch in our system next week.

[micha-silver]

Hi @maelle : It's good to hear from you. I'll look forward to getting the review underway next week.

[noamross]

Thanks @micha-silver for your submission. As Maëlle has noted our automatic package checker has a glitch, one that we think is a GitLab-related edge case. (We have fewer - totally fine! - submissions from GitLab so the system has had less stress-testing against it).

In the meantime, I've determined that your package is in-scope. From an initial manual check of the repository I note a few important things that that will be required before proceeding to assign an editor and reviewers. It may be worth moving ahead on these while we get the automatic checks going:

• We require that all packages have at least on vignette (https://devguide.ropensci.org/building.html#documentation)
• We also require a CONTRIBUTING.md or similar file to provide guidance to potential package reviewers (https://devguide.ropensci.org/collaboration.html?q=contributing.md#contributing-guide)
• We require testing against the current (release), last (oldrel), and development (devel) versions of R, as well as across linux, macos, and windows platforms (usually just on release). We also require coverage reporting of testing. Based on your .gitlab-ci.yml file, I think you are only testing on release. (https://devguide.ropensci.org/ci.html)

[maelle]

@ropensci-review-bot check package

[ropensci-review-bot]

Thanks, about to send the query.

[ropensci-review-bot]

:rocket:

Editor check started

:wave:

[ropensci-review-bot]

Checks for rOPTRAM (v0.0.1.000)

git hash: dd810f2f

• :heavy_check_mark: Package name is available
• :heavy_check_mark: has a 'codemeta.json' file.
• :heavy_check_mark: has a 'contributing' file.
• :heavy_check_mark: uses 'roxygen2'.
• :heavy_check_mark: 'DESCRIPTION' has a URL field.
• :heavy_check_mark: 'DESCRIPTION' has a BugReports field.
• :heavy_check_mark: Package has at least one HTML vignette
• :heavy_multiplication_x: These functions do not have examples: [aoi_to_name, check_aoi, check_scihub_access].
• :heavy_multiplication_x: Package has no continuous integration checks.
• :heavy_multiplication_x: Package coverage failed
• :heavy_multiplication_x: R CMD check process failed with message: 'Build process failed'.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL (>= 3) + file LICENSE

---

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
internal	base	125
internal	rOPTRAM	20
internal	datasets	1
imports	terra	25
imports	utils	7
imports	dplyr	3
imports	sf	1
imports	ggplot2	NA
imports	tools	NA
suggests	xml2	17
suggests	stats	8
suggests	sen2r	1
suggests	geojsonio	NA
suggests	testthat	NA
suggests	knitr	NA
suggests	rmarkdown	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.

base

file.path (16), lapply (15), c (13), basename (7), paste (7), strsplit (6), unlist (6), data.frame (5), list.files (5), as.data.frame (4), dir (4), nrow (4), grepl (3), sample (3), as.Date (2), do.call (2), length (2), rbind (2), split (2), t (2), as.character (1), dirname (1), gsub (1), log2 (1), max (1), min (1), package_version (1), paste0 (1), path.expand (1), row.names (1), suppressWarnings (1), Sys.which (1), system.file (1), T (1), try (1)

terra

rast (10), as.data.frame (6), writeRaster (4), ext (3), crs (1), project (1)

rOPTRAM

calculate_str (6), calculate_vi (5), aoi_to_name (3), check_scihub_access (2), optram_wetdry_coefficients (2), check_aoi (1), optram_calculate_str (1)

xml2

read_xml (5), xml_find_first (5), xml_text (5), xml_contents (1), xml_find_all (1)

stats

lm (3), quantile (3), offset (1), step (1)

utils

data (3), vi (3), packageVersion (1)

dplyr

full_join (3)

datasets

iris (1)

sen2r

check_gcloud (1)

sf

st_read (1)

NOTE: Some imported packages appear to have no 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 13 files) and
• 1 authors
• 1 vignette
• no internal data file
• 6 imported packages
• 15 exported functions (median 42 lines of code)
• 21 non-exported functions in R (median 20 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	13	68.2
files_vignettes	2	85.7
files_tests	11	91.7
loc_R	759	60.2
loc_vignettes	142	37.0
loc_tests	206	55.5
num_vignettes	1	64.8
n_fns_r	36	45.9
n_fns_r_exported	15	58.5
n_fns_r_not_exported	21	42.1
n_fns_per_file_r	2	32.7
num_params_per_fn	4	54.6
loc_per_fn_r	30	76.5
loc_per_fn_r_exp	42	74.5
loc_per_fn_r_not_exp	20	63.0
rel_whitespace_R	15	56.6
rel_whitespace_vignettes	23	25.0
rel_whitespace_tests	16	47.0
doclines_per_fn_exp	26	25.3
doclines_per_fn_not_exp	0	0.0	TRUE
fn_call_network_size	20	46.4

---

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)

---

3b. goodpractice results

R CMD check with rcmdcheck

R CMD check generated the following error:

1. Error in proc$get_built_file() : Build process failed

R CMD check generated the following check_fail:

1. no_import_package_as_a_whole

Test coverage with covr

ERROR: Test Coverage Failed

Cyclocomplexity with cyclocomp

Error : Build failed, unknown error, standard output:

• checking for file ‘roptram/DESCRIPTION’ ... OK
• preparing ‘rOPTRAM’:
• checking DESCRIPTION meta-information ... OK
• installing the package to build vignettes -----------------------------------
• installing source package ‘rOPTRAM’ ... ** using staged installation ** R ** inst ** byte-compile and prepare package for lazy loading Error in library(hexSticker) : there is no package called ‘hexSticker’ Error: unable to load R code in package ‘rOPTRAM’ Execution halted ERROR: lazy loading failed for package ‘rOPTRAM’
• removing ‘/tmp/RtmpcVV09j/Rinst1adf150625cf/rOPTRAM’ ----------------------------------- ERROR: package installation failed

Static code analyses with lintr

lintr found the following 67 potential issues:

message	number of times
Avoid 1:length(...) expressions, use seq_len.	2
Avoid library() and require() calls in packages	4
Lines should not be more than 80 characters.	59
Use <-, not =, for assignment.	2

---

Package Versions

package	version
pkgstats	0.1.3.9
pkgcheck	0.1.2.10

---

Editor-in-Chief Instructions:

Processing may not proceed until the items marked with :heavy_multiplication_x: have been resolved.

[micha-silver]

Thanks:

* We require that all packages have at least on vignette (https://devguide.ropensci.org/building.html#documentation)

I've written and added an appropriate vignette.

* We also require a CONTRIBUTING.md or similar file to provide guidance to potential package reviewers (https://devguide.ropensci.org/collaboration.html?q=contributing.md#contributing-guide)

Added CONTRIBUTING.md (in docs subdir)

* We require testing against the current (release), last (oldrel), and development (devel) versions of R, as well as across linux, macos, and windows platforms (usually just on release).  We also require coverage reporting of testing.  Based on your [.gitlab-ci.yml file](https://gitlab.com/rsl-bidr/roptram/-/blob/main/.gitlab-ci.yml), I think you are only testing on `release`. (https://devguide.ropensci.org/ci.html)

Yes, I have only one CI so far. I'll start preparing tests for additional releases and OS.

[noamross]

Thanks, @micha-silver. Now that we have automated checks, I also see that the repo doesn't show the test coverage (though you may be measuring this locally as I see you have a .covrignore file). Since reviewers may be less familiar with navigation in GitLab, please put badges in your readme to point us to the CI build logs and coverage outputs once those are set up.

[micha-silver]

Correct, I'm running covr locally.

My coverage is not good, (about 48%) and I'd like some advice here: I have three main functions that pull down multiple Sentinel 2 or Landsat imagery tiles, over a time span.

• The wrapper function: optram()
• optram_acquire_s2()
• optram_landsat

Even if I do a test that limits the time span to one day, it would be > 1GB download for each of these functions. I think that such a big download should not be done in a test. How can I work around this?

[noamross]

This is a common challenge we see. There are several complementary strategies one can take:

• Write mock tests that test that the functions work with pre-cached data or outputs: https://books.ropensci.org/http-testing/mocking.html
• Cache data required for testing in the package, or in another public location from which fetching is faster or more accessible. (Such as attached to the GitHub repository as a release, or in a Zenodo record). Pre-process if needed or possible to reduce size.
• Break up the functions into components that require downloading and those that don't, and write separate tests to cover the latter.
• Make tests conditional so they don't need to be run all the time, such as making them conditional on setting an environment variable ROPTRAM_ALL_TESTS=1. This would normally be turned off on CI and thus lower coverage would be reported, but that's OK. The test-running procedure should be explained in CONTRIBUTING.md and reviewers will be able to consider it.

[micha-silver]

@noamross : I'm considering migrating the rOPTRAM repo from gitlab to github. I think I'll be able to configure the CI tests more easily on github (lots more examples...). And since most ROpenSci projects are on github, the review process might also be smoother. Shall I go ahead with this? Anything I need to be aware of??

Regarding your explanation above about testing functions with large downloads, I'd like to go with the 4th option, setting a condition, and skipping those tests (with explanation in CONTRIBUTING).

Thanks, Micha

[noamross]

@micha-silver No problem for us if you move to GitHub, though we are happy to do the process either way. We might have to make a tweak so the bot knows that the repository is in a new location, so let us know when you switch.

[micha-silver]

Hi: I've made progress with the rOPTRAM package:

1. Added examples to all functions
2. CI tests are now integrated.
3. covr::package_coverage() now shows:

r$> covr::package_coverage()
rOPTRAM Coverage: 75.49%
R/optram_acquire_s2.R: 17.86%
R/utilities.R: 85.29%
R/optram_wetdry_coefficients.R: 95.10%
R/optram_ndvi_str.R: 95.12%
R/optram_calculate_str.R: 95.45%
R/optram_soilmoisture.R: 100.00%

(TODO: Still needs to be improved. I've added one addition testthat function to test downloading in the optram_acquire_s2.R function by limiting the timespan so that only one sentinel tile is downloaded. But that function still has low coverage. )

5. I run tests on 5 platforms: Windows release, Windows oldrel, Windows devel, MacOS, and Ubuntu. The gitlab-ci.yml performs these tests by sending to rhub. Here's the summary currently:

                  platform errors warnings notes
       ubuntu-gcc-devel      0        0     0
 windows-x86_64-release      0        0     0
  windows-x86_64-oldrel      0        0     0
   windows-x86_64-devel      0        0     0
          macos_release      0        0    11

[1] "2023-11-26 11:21:16.729992  - Check completed"

Here are links to the results: for Ubuntu: for Win release: release for Win devel: for Win oldrel: for Mac macbuilds:

Not sure how long these artifacts are kept on rhub. But the full artifact on gitlab is available: artifacts on gitlab

What's next? Best regards, Micha

[micha-silver]

Following up: On my local machine I get good coverage:

r$> cvr <- covr::package_coverage()

r$> cvr
rOPTRAM Coverage: 92.70%
R/utilities.R: 85.29%
R/optram_acquire_s2.R: 90.59%
R/optram_wetdry_coefficients.R: 95.10%
R/optram_ndvi_str.R: 95.12%
R/optram_calculate_str.R: 95.45%
R/optram_soilmoisture.R: 100.00%

The explanation: The optram_acquire_s2() function relies on Google Cloud CLI to download Sentinel images. I have that SDK installed locally, but I have not seen any way to install non-interactively, on a rocker image. There seems to be no work around to get access authentication to Google services, and the gsutil utility setup in a CI machine. I tried to copy my Google access token into a CI variable, and use that, but there is no way to get gsutil setup automatically to recognize a username and token. So when I run covr in gitlab-ci it skips the whole download procedure, and shows lower coverage.

[noamross]

Hi @micha-silver, thanks for moving a ahead on this. It's good you got to 75% coverage without the gsutil dependency! I note that https://cloud.google.com/sdk/docs/downloads-interactive#silent to have some guidance for installing on CI services. I'd make good-faith effort with that, but if it is not possible a full description in the install section of the README as well as CONTRIBUTING for those running tests will be sufficient. I note this is one thing that we might ask reviewers to comment on in the next stage - would another dependency be a simpler way to fetch the images?

[micha-silver]

@noamross I appreciate your encouraging words.

Two comments

1. The link you suggested to an automated install of the Gcloud CLI works fine. The problem is that after installing you still need to be authenticated. And that, AFAIK, requires an interactive step: Google forces you to go to a certain website, put in credentials and get the OAuth token on your machine. I tried to put a valid token into a gitlab CI variable, then somehow use that to manually recreate the local auth directory (in a docker image) that gcloud requires - no success here :-(. Even if we could find some work around, it would surely be very fragile.
2. As to a simpler way to fetch the imagery: Indeed Copernicus now (since Oct 2023) offers several new options for downloading - many more than when I began this package. We have recruited another contributor who will help me to weed thru these various options, and implement the best, smoothest ones. If you agree, I'd like to present the package in its current state for review, then add the additional image acquisition capabilities in a future version.

[noamross]

It should be fine to present the package in its current state. Let me re-run checks.

[noamross]

@ropensci-review-bot check package

[ropensci-review-bot]

Thanks, about to send the query.

[ropensci-review-bot]

:rocket:

Editor check started

:wave:

[ropensci-review-bot]

Checks for rOPTRAM (v0.0.1.000)

git hash: b54b2c5f

• :heavy_check_mark: Package name is available
• :heavy_check_mark: has a 'codemeta.json' file.
• :heavy_check_mark: has a 'contributing' file.
• :heavy_check_mark: uses 'roxygen2'.
• :heavy_check_mark: 'DESCRIPTION' has a URL field.
• :heavy_check_mark: 'DESCRIPTION' has a BugReports field.
• :heavy_check_mark: Package has at least one HTML vignette
• :heavy_check_mark: All functions have examples.
• :heavy_multiplication_x: Package has no continuous integration checks.
• :heavy_multiplication_x: Package coverage is 74.4% (should be at least 75%).
• :heavy_check_mark: R CMD check found no errors.
• :heavy_check_mark: R CMD check found no warnings.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL (>= 3) + file LICENSE

---

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
internal	base	120
internal	rOPTRAM	19
imports	terra	38
imports	sf	5
imports	utils	4
imports	dplyr	3
imports	ggplot2	NA
imports	tools	NA
suggests	xml2	13
suggests	stats	9
suggests	sen2r	1
suggests	geojsonio	NA
suggests	lwgeom	NA
suggests	knitr	NA
suggests	rmarkdown	NA
suggests	testthat	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.

base

lapply (15), c (14), file.path (14), basename (7), paste (7), strsplit (6), unlist (6), data.frame (5), list.files (5), nrow (4), dir (3), sample (3), as.Date (2), do.call (2), drop (2), grepl (2), length (2), rbind (2), split (2), t (2), as.character (1), dirname (1), gsub (1), log (1), log2 (1), max (1), min (1), package_version (1), paste0 (1), row.names (1), suppressWarnings (1), Sys.getenv (1), T (1), try (1), tryCatch (1)

terra

as.data.frame (16), rast (12), writeRaster (4), ext (3), crs (1), mean (1), project (1)

rOPTRAM

calculate_str (6), calculate_vi (5), aoi_to_name (3), optram_wetdry_coefficients (2), check_aoi (1), check_scihub_access (1), optram_calculate_str (1)

xml2

read_xml (5), xml_text (5), xml_contents (1), xml_find_all (1), xml_find_first (1)

stats

lm (3), quantile (3), offset (1), proj (1), step (1)

sf

st_read (3), st_zm (2)

utils

data (3), packageVersion (1)

dplyr

full_join (3)

sen2r

check_gcloud (1)

NOTE: Some imported packages appear to have no 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 11 files) and
• 1 authors
• 1 vignette
• no internal data file
• 6 imported packages
• 15 exported functions (median 32 lines of code)
• 15 non-exported functions in R (median 40 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	11	62.6
files_vignettes	2	85.7
files_tests	10	90.7
loc_R	761	60.3
loc_vignettes	157	40.5
loc_tests	253	60.4
num_vignettes	1	64.8
n_fns_r	30	40.1
n_fns_r_exported	15	58.5
n_fns_r_not_exported	15	32.7
n_fns_per_file_r	2	25.6
num_params_per_fn	5	69.6
loc_per_fn_r	37	83.0
loc_per_fn_r_exp	32	65.2
loc_per_fn_r_not_exp	40	86.1
rel_whitespace_R	14	55.1
rel_whitespace_vignettes	30	36.6
rel_whitespace_tests	16	52.0
doclines_per_fn_exp	33	38.5
doclines_per_fn_not_exp	0	0.0	TRUE
fn_call_network_size	18	44.2

---

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)

---

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

Cyclocomplexity with cyclocomp

The following functions have cyclocomplexity >= 15:

function	cyclocomplexity
optram_safe	29
optram_landsat	20

Static code analyses with lintr

lintr found the following 17 potential issues:

message	number of times
Avoid changing the working directory, or restore it in on.exit	1
Lines should not be more than 80 characters.	15
Use <-, not =, for assignment.	1

---

Package Versions

package	version
pkgstats	0.1.3.9
pkgcheck	0.1.2.11

---

Editor-in-Chief Instructions:

Processing may not proceed until the items marked with :heavy_multiplication_x: have been resolved.

[micha-silver]

I have improved the coverage of optram_acquire_s2() by moving the actual download code to a separate file, and entering that new file into .covrignore.

CI tests are, if I understand correctly, implemented in the .gitlab-ci.yml file. In that file I put a rule to run the pipeline manually (to avoid firing off a check at every minor commit). Is that sufficient to fill the requirement for "✖️ Package has no continuous integration checks."?

I also fixed the lintr comments.

[noamross]

Thanks, for the CI the reason for failure is that we don't yet have a standard way to detect it on GitLab. We'll work on that in the future, both detection and some guidance on how to signal it for non-GitHub users. In the meantime, I'm assigning an editor to get this going!

[noamross]

@ropensci-review-bot assign @adamhsparks as editor