stats19

[Robinlovelace]

Summary

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

The goal of stats19 is to make it easy to work with road crash data. Specifically it enables access to and processing of the UK’s official road traffic casualty database, which is called STATS19.

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

Package: stats19
Title: Work with open road traffic casualty data from Great Britain
Version: 0.1.0.9000
Authors@R: c(
    person("Robin", "Lovelace", email = "rob00x@gmail.com", role = c("aut", "cre"),
    comment = c(ORCID = "0000-0001-5679-6536")),
    person("Malcolm", "Morgan", email = "m.morgan1@leeds.ac.uk", role = c("aut")),
    person("Layik", "Hama", email = "layik.hama@gmail.com", role = c("aut"))
  )
Description: Tools to help process and analysie the UK road collision data also known as Stats19.
Depends: R (>= 3.5.0)
License: GPL-3
Encoding: UTF-8
LazyData: true
Imports: 
    sf,
    foreign,
    readr,
    dplyr,
    lubridate,
    readxl
Suggests: 
    knitr,
    rmarkdown,
    testthat
VignetteBuilder: knitr
RoxygenNote: 6.1.1

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

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

• data retrieval: downloads and formats publicly available road safety data that is difficult (impossible for most people) to use effectively without

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

Academic, industry and public sector researchers investigating road safety, specifically people wanting to perform natural experimental studies to find out how best to make the transport system safer. It will also be of interest for people interested in large point-on-network data for methodological applications.

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

Previous packages/code-bases:

• code in the bikeR repo underlying an academic paper on collisions involving cyclists
• functions in stplanr for downloading Stats19 data
• updated functions related to the CyIPT project

but this package takes the best of the preceding packages and adds new features including:

• automated and reproducible data formatting code based on DfT's official guidelines (before labels were hard-coded)

• continuous integration

• integration with sf (the stplanr implementation used sp)

• inclusion of much more data (back to 1974 and until 2017, previous work only covered 1985:2015)

•   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?
• 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 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)

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:

• Currently the style uses = assignment, which differs from the recommended style

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

[sckott]

thanks for your submission @Robinlovelace We are discussing now and will get back to you soon

[Robinlovelace]

Great. It's in active development as you'll see. We have code to make all those millions of crash points sf data frames, we've just not pushed it. @layik has done great work refactoring the download functions so it makes it much easier to access this important dataset. Looking forward to hearing back from you and thanks for the update.

[Robinlovelace]

Heads-up @sckott format_sf() is now in there and the package now has a proper vignette. Are there any other things we should add at this stage for peer review? Thanks.

[sckott]

will dig into it today, i'll let you know

[sckott]

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 @Robinlovelace !

Here's the output from goodpractice. No need to address these now, it's info for reviewers to use to get started.

── GP stats19 ─────────────
It is good practice to

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

    R/dl_stats19.R:82:NA
    R/dl_stats19.R:83:NA
    R/format.R:55:NA
    R/format.R:106:NA
    R/format.R:157:NA
    ... and 12 more lines

  ✖ 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.
  ✖ use '<-' for assignment instead of '='. '<-' is the standard, and R users and developers are used it and it is easier to read your code for them if
    you use '<-'.

    R/dl_stats19.R:28:12
    R/dl_stats19.R:30:9
    R/dl_stats19.R:31:16
    R/dl_stats19.R:32:11
    R/dl_stats19.R:34:18
    ... and 204 more lines

  ✖ 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/dl_stats19.R:28:1
    R/dl_stats19.R:104:1
    R/dl_stats19.R:105:1
    R/format.R:42:1
    R/format.R:98:1
    ... and 14 more lines

  ✖ 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/format.R:257:20

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...), 1:NROW(...) and 1:NCOL(...) expressions. They are error prone and result 1:0 if the expression on
    the right hand side is zero. Use seq_len() or seq_along() instead.

    R/format.R:247:11

  ✖ fix this R CMD check NOTE: Namespaces in Imports field not imported from: ‘dplyr’ ‘foreign’ ‘lubridate’ All declared Imports should be used.

Seeking reviewers now 🕐

---

Reviewers:

• @adamhsparks due date: 2019-01-02
• @daranzolin due date: 2019-01-02

[Robinlovelace]

Thanks @sckott. I'd seen goodpractice but never used it - that is very useful. After a few commits stats19 is improved. Latest results:

── GP stats19 ───────────────────────────────────────────────────────────────────────────

It is good practice to

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

    R/dl_stats19.R:85:NA
    R/dl_stats19.R:86:NA
    R/format.R:43:NA
    R/format.R:88:NA
    R/format.R:133:NA
    ... and 12 more lines

  ✖ use '<-' for assignment instead of '='. '<-' is the standard, and
    R users and developers are used it and it is easier to read your code for
    them if you use '<-'.

    R/dl_stats19.R:28:12
    R/dl_stats19.R:33:9
    R/dl_stats19.R:34:16
    R/dl_stats19.R:35:11
    R/dl_stats19.R:37:18
    ... and 203 more lines