rdefra package

[cvitolo]

Summary

• What does this package do? (explain in 50 words or less):
  The rdefra package retrieves air pollution data and metadata from the Air Information Resource (UK-AIR) of the Department for Environment, Food and Rural Affairs in the United Kingdom. UK-AIR does not provide a public API for programmatic access to data, therefore this package scrapes the HTML pages to get relevant information.
• Paste the full DESCRIPTION file inside a code block below:

Package: rdefra
Type: Package
Title: Interact with the UK AIR Pollution Database from DEFRA
Version: 0.2.0
Date: 2016-08-03
Author: Claudia Vitolo [aut, cre], Andrew Russell [aut], Allan Tucker [aut]
Maintainer: Claudia Vitolo <cvitolodev@gmail.com>
URL: https://github.com/kehraProject/r_rdefra
BugReports: https://github.com/kehraProject/r_rdefra/issues
Description: Get data from DEFRA's UK-AIR website. It basically scraps the HTML content.
Depends: R (>= 2.10)
Imports: RCurl, XML, plyr
Suggests: testthat
LazyData: true
Encoding: UTF-8
License: GPL-3
Repository: CRAN
RoxygenNote: 5.0.1

• URL for the package (the development repository, not a stylized html page):
  https://github.com/kehraProject/r_rdefra
• Who is the target audience?
  Scientists and researchers interested in air pollution data and epidemiologists.
• Are there other R packages that accomplish the same thing? If so, what is different about yours?
  The openair package (https://github.com/davidcarslaw/openair) accomplishes similar things but relies on a local and compressed copy of the data on servers at King's College (UK), periodically updated. I have used the openair package myself in the past and it is an excellent package (for data retrieval and visualisation) but I had troubles with King's College servers down time.
  The rdefra package, instead, retrieves the information directly from the original source with the advantage that users always get the most complete information at any time. This package also integrates a function to retrieve missing coordinates from the standard metadata.

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 with Travis CI and/or another service.

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 contains a paper.md with a high-level description.
  • The package is deposited in a long-term repository with the DOI:
    http://dx.doi.org/10.5281/zenodo.59851

Detail

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

R CMD check succeeds. There were no ERRORs, WARNINGs or NOTEs.

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

[sckott]

Editor checks:

• Fit: The package meets or criteria fit and overlap
• Automated tests:
• 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)?

---

@cvitolo Thanks for your submission! Two things before I get reviewers:

• you do have a tests directory, but AFAICT they don't test the functions in the package. Can you add at least a few tests that test the functionality of the exported functions?
• You did check that you have a vignette, but the vignette is in the parent directory, so not included with the package. Please move the vignette dir into the package itself

Reviewers: @masalmon @haozhu233
Due date: 2016-08-30

[cvitolo]

Hi Scott,

Many thanks for looking at my package.
I have made the changes you mentioned below.

Kind regards,
Claudia

On 9 August 2016 at 00:00, Scott Chamberlain notifications@github.com
wrote:

Editor checks:

• Fit: The package meets or criteria fit http://policies.md#fit
  and overlap http://policies.md#fit
• Automated tests: Package has some tests, but none test actual
  functions in the package
• 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)?

---

@cvitolo https://github.com/cvitolo Thanks for your submission! Two
things before I get reviewers:

• you do have a tests directory, but AFAICT they don't test the
  functions in the package. Can you add at least a few tests that test the
  functionality of the exported functions?
• You did check that you have a vignette, but the vignette is in the
  parent directory, so not included with the package. Please move the
  vignette dir into the package itself

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#68 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEhdr_Yr8Z4DZl1v_MCx0pnWRw5ooOSMks5qd6bvgaJpZM4JfPSk
.

[sckott]

thanks @cvitolo - reviewer assigned - seeking one more

[maelle]

@cvitolo I have a first question, why do you use a sub-directory for the package itself in the repository? I'm not saying it's wrong, I'm just wondering. :-)

[cvitolo]

@masalmon I use a sub-directory for the package so that, in the parent folder, I can have the package itself and also add all the work (e.g. experiments, presentations, demos, tutorials, posters, papers, etc.) related to the package. I could move everything to the package folder and add the additional files to .Rbuildignore but I personally prefer to leave the package folder as clean as possible. It is just a personal preference, but I'm happy to adapt to best practises if needed.

[maelle]

@cvitolo Ok thank you for your quick answer. :-)

I see some commented code such as

  # library(RCurl)
  # library(XML)
  # uka_id <- "UKA00399"
  # uka_id <- "UKA15910"

or

 # library(RCurl)
  # library(XML)
  # library(plyr)
  # site_id <- "ABD"
  # years <- 1972:2014

  # Site with list of flat files
  # rootURL <- "http://uk-air.defra.gov.uk/data/flat_files?"
  # myURL <- paste(rootURL, "site_id=", site_id, sep = "")
  # download html
  # html <- getURL(myURL, followlocation = TRUE)
  # parse html
  # doc = htmlParse(html, asText=TRUE)
  # hrefs <- xpathSApply(doc, '//*[@id="center-2col"]', xmlGetAttr, 'href')
  # Otherwise
  # html <- paste(readLines(myURL), collapse="\n")
  # library(stringr)
  # matched <- str_match_all(html, "<a href=\"(.*?)\"")

Why is it commented? If it's not useful any longer, maybe you could delete it?