CoordinateCleaner

[azizka]

Summary

• What does this package do? (explain in 50 words or less):
  Identify problematic records in large databases of biological and palaeontological collections, to improve data quality for analyses in biogeography, ecology and conservation.

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

Package: CoordinateCleaner
Type: Package
Title: Automated Cleaning of Occurrence Records from Biological Collections
Version: 1.1-0
Date: 2018-04-08
Authors@R: c(person(given = "Alexander", family = "Zizka", email = "alexander.zizka@bioenv.gu.se",
                    role = c("aut", "cre")),
             person(given = "Daniele", family = "Silvestro", role = c("ctb")))
Description: Automated cleaning of geographic species occurrence records by automated flagging of problems common to biodiversity data from biological collections. Includes automated tests to easily flag (and exclude) records assigned to country or province centroid, the open ocean, the headquarters of the Global Biodiversity Information Facility, urban areas or the location of biodiversity institutions (museums, zoos, botanical gardens, universities). Furthermore identifies per species outlier coordinates, zero coordinates, identical latitude/longitude and invalid coordinates. Also implements an algorithm to identify data sets with a significant proportion of rounded coordinates. Especially suited for large data sets. See <https://github.com/azizka/CoordinateCleaner/wiki> for more details and tutorials.
License: GPL-3
Depends: R (>= 3.0.0), sp
Imports: geosphere, ggplot2, methods, raster, rgeos, rnaturalearth, stats
LazyData: true
RoxygenNote: 6.0.1
Suggests: testthat, covr

• URL for the package (the development repository, not a stylized html page):
  https://github.com/azizka/CoordinateCleaner

• 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 deals with improving data quality of occurrence records of biological specimens
• reproducible research, because the package replaces potentially badly documented ad-hoc decisions from GUI GIS with clearly defined functions
• data munging, becasue the packages processes commonly used geospatial data (geographic coordinates)

•   Who is the target audience and what are scientific applications of this package?
  Anybody using geographic coordinates from biological collections on a large scale, thus mostly researchers in biogeography, (maco-)ecology, evolutionary biology and conservation practitioners

• Are there other R packages that accomplish the same thing? If so, how does
  yours differ or meet our criteria for best-in-category?
  Yes, scrubr, see this pre-submission enquiry: Pre-submission inquiry: CoordinateCleaner #199

•   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.
  Pre-submission inquiry: CoordinateCleaner #199, @sckott

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. The vignette is not part of the package. There are extensive tutorials (https://github.com/azizka/CoordinateCleaner/tree/master/Tutorials) and a wiki (https://github.com/azizka/CoordinateCleaner/wiki) on github
• 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 is on CRAN already https://cran.r-project.org/web/packages/CoordinateCleaner/index.html
• 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 (see MEE's Policy on Publishing Code)
  • (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no gaurantee that your manuscript willl 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)
    The manuscript is already submitted to MEE. It had to be submitted before April 1st.

Detail

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

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

• NEWS file - there is one now, but only started with the latest version.
• Package name: Unfortunately, the name contains capital letters (CoordinateCleaner), but it is on CRAN already.
• Function naming: Functions for individual tests are snake_case and pipe compatible, wrapper function around all tests are CamelCase.
• Documentation: not built with roxygen.

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

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

SaraVarela, sckott

[maelle]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• 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 @azizka! 😁 Initial checks revealed a few issues that you should solve before I assign reviewers. Do not hesitate to ask any question you might have!

• Your package doesn't use roxygen2 yet for documentation. Our packaging guide says we strongly encourage it but we'd actually like to start enforcing it, partly to help future contributors. To convert your existing documentation to roxygen2 documentation you can use the Rd2roxygen package. When using roxygen2 you won't have to updated NAMESPACE by hand.

• What is the licence on extra_gazeetters? Could these files live in a separate data package? (question, not request for change)

• Why have the tar.gz and zip of your package in the repo especially since you already make them available via the use of GitHub releases?

• Here is goodpractice::gp() output with comments.

It is good practice to

  ? write unit tests for all functions, and all package
    code in general. 62% of code lines are covered by test cases.

    R/cc_cap.R:18:NA
    R/cc_cap.R:19:NA
    R/cc_cap.R:29:NA
    R/cc_cen.R:19:NA
    R/cc_cen.R:21:NA
    ... and 580 more lines
    

You do not need to reach 100% code coverage but you can increase it a bit.

  ? not use "Depends" in DESCRIPTION, as it can cause
    name clashes, and poor interaction with other packages. Use
    "Imports" instead.

Feel free to ignore this if you need the sp Depends. By the way, is there any reason why you don't use the more modern sf? (question, not request for change)

  ? omit "Date" in DESCRIPTION. It is not required and it
    gets invalid quite often. A build date will be added to the
    package when you perform `R CMD build` on it.

Please remove Date from there.

  ? add a "URL" field to DESCRIPTION. It helps users find
    information about your package online. If your package does not
    have a homepage, add an URL to GitHub, or the CRAN package
    package page.
  ? add a "BugReports" field to DESCRIPTION, and point it
    to a bug tracker. Many online code hosting services provide bug
    trackers for free, https://github.com, https://gitlab.com, etc.
    

Make it easy to find your GitHub repo by adding these links.

  ? avoid long code lines, it is bad for readability.
    Also, many people prefer editor windows that are about 80
    characters wide. Try make your lines shorter than 80 characters

    R\cc_cap.R:1:1
    R\cc_cap.R:24:1
    R\cc_cen.R:1:1
    R\cc_coun.R:1:1
    R\cc_coun.R:17:1
    ... and 210 more lines
    

Maybe styler can help with this.

  ? avoid sapply(), it is not type safe. It might return
    a vector, or a list, depending on the input data. Consider
    using vapply() instead.

    R\WritePyRate.R:88:68

Please change sapply in favor of vapply here.

  ? not import packages as a whole, as this can cause
    name clashes between the imported packages. Instead, import
    only the specific functions you need.
    

See this part of Hadley Wickham's R package book

  ? not use exportPattern in NAMESPACE. It can lead to
    exporting functions unintendedly. Instead, export functions
    that constitute the external API of your package.

When using roxygen2 syntax you'll use the export tag before each function to be exported.

  ? fix this R CMD check NOTE: Note: found 1 marked
    Latin-1 string

Not sure what this means actually.

  ? fix this R CMD check NOTE: Found the following hidden
    files and directories: .travis.yml These were most likely
    included in error. See section 'Package structure' in the
    'Writing R Extensions' manual.

Please put such files and folders in .Rbuildignore.

Please update this thread once you've done the changes, or as soon as you have a question!

---

Reviewers: @isteves @Pakillo
Due date: 2018-06-07

[maelle]

@azizka do you have any question or comment? ☺

[azizka]

Hi @maelle sounds all good, thanks. I am working to include most of your suggestions. I'll defend my PhD next week, so little slow working on the package at the moment, but will tackle this full on afterwards.

[maelle]

Oh good luck with your defence!

[maelle]

@azizka I hope your defence went well! I'm taking the risk to say congrats! 🎊

Did you have time to work on the package a bit?

[azizka]

@maelle yes, it worked out fine, thanks for congratulations and your patience! I am back to work this week, working on the package now.

[maelle]

🎊 Grattis! 🎊

and cool!

[azizka]

Hi @maelle,

Please find below replies to your comments. I hope you find everything covered, please let me know what else I can do. Thanks again for the patience :-).

Note: the most recent version is working, I’ll updated the badges as soon as the problems with travis are solved (travis-ci/travis-build#1382)

Replies:

Your package doesn't use roxygen2 yet for documentation

Done - Migrated documentation and namespace generation to roxygen2

What is the licence on extra_gazeetters? Could these files live in a separate data package?

The extra gazetteers are open source, they could live in a separate data package, but I am not sure that this is necessary/useful since they have very specialized applicability.

Why have the tar.gz and zip of your package in the repo especially since you already make them available via the use of GitHub releases?

Done - Removed the .tar.gz and zip

You do not need to reach 100% code coverage but you can increase it a bit.

It is at 74% now

Feel free to ignore this if you need the sp Depends. By the way, is there any reason why you don't use the more modern sf? (question, not request for change)

Done - moved sp from ‘Depends’ to ‘Imports’. Yes, sf would be great since its faster and tidy, but unfortunately some of the dependencies do not yet support sf formats (e.g. raster, geosphere).

Please remove Date from there

Done - Removed the date from the description file

Make it easy to find your GitHub repo by adding these links.

Done - Added the urls to the description file

Avoid long code lines, it is bad for readability.

Done – cut at 80

Please change sapply in favor of vapply here

Done

not import packages as a whole, instead, import only the specific functions you need

Done

When using roxygen2 syntax you'll use the export tag before each function to be exported.

Done – switched to roxygen2

fix this R CMD check NOTE: Note: found 1 marked, Latin-1 string

I could not reproduce this note, do you have additional information on the operating system and check settings, etc? I suspect it might be related to a non-ASCII character in one of the datasets in the package, but I am not entirely sure either.

Please put such files and folders in .Rbuildignore.

Done, the .travis.yml is part of .Rbuildignore now

[maelle]

@azizka thanks for all your work! Am going to assign reviewers in a bit. Two last comments before the reviews:

• could you please add a code of conduct to your repo? cf our guidelines

• could you please respond to the two issues opened in your repo? If these are bugs, please solve them before the reviews and update this thread. :-)

[maelle]

👋 @isteves @Pakillo! Thanks for accepting to review this package! Your reviews are due 2018-06-07 but @Pakillo I've already noted that yours might be late (@azizka the reviewers of your package were lined up a while ago 😉)

Here is our reviewer template and our reviewer guide.