GSODR: Global Surface Summary Daily Weather Data in R

[adamhsparks]

Summary

• What does this package do? (explain in 50 words or less):
  The GSODR package offers an R interface for downloading Global Surface
  Summary of the Day weather data files from the United States National Climatic
  Data Center, applies rules for cleaning and parses them into files useful for
  researchers.
• Paste the full DESCRIPTION file inside a code block below:

Package: GSODR
Type: Package
Title: Global Summary Daily Weather Data in R
Version: 0.3
Date: 2016-10-16
Authors@R: c(person("Adam", "Sparks", role = c("aut", "cre"),
    email = "adamhsparks@gmail.com"),
    person("Tomislav", "Hengl", role = "aut",
    email = "tom.hengl@isric.org"),
    person("Andrew", "Nelson", role = "aut",
    email = "dr.andy.nelson@gmail.com"))
Maintainer: Adam Sparks <adamhsparks@gmail.com>
URL: https://github.com/adamhsparks/GSODR
BugReports: https://github.com/adamhsparks/GSODR/issues
Description:  The GSODR package offers automated downloading, parsing, cleaning
    and converting of Global Surface Summary of the Day (GSOD) weather data from
    the from the USA National Climatic Data Center (NCDC) into Comma Separated
    Values (CSV) or Geopackage (GPKG) files. The get_GSOD() function retrieves
    data from the NCDC's public FTP site and reformats it from United States
    Customary System (USCS) units to International System of Units (SI).
    Stations are individually checked for number of missing days as defined by
    the user to help ensure data quality. Stations files with too many missing
    observations are omitted from the final file. Only stations with valid
    reported latitude and longitude values are permitted in the final derived
    data set. A list of values for 200 metre buffered elevation data, derived
    from the CGIAR-CSI SRTM hole-filled 90 metre data set (Jarvis et al. 2008)
    are included for stations between -60 and 60 degrees latitude with valid
    latitude and longitude values. File output is returned as a comma-separated
    values (CSV) or GeoPackage (GPKG) file written to a local disk in a location
    selected by the user, which summarises each year by station. Additional
    useful variables, saturation vapour pressure (es), actual vapour pressure (ea)
    and relative humidity are calculated from the original data and included in
    the final data set. The resulting files can be as larger than 500mb
    depending on the user's stringency for missing data and geographic area of
    interest. Be sure to have sufficient RAM and disk space as well as a
    reasonably fast Internet connection to use this package to perform this
    operation for a global data set over many years. However, for much smaller
    and more manageable data sets, an individual country of interest may be
    selected as well as only stations falling between -60 and 60 degrees
    latitude for agroclimatology work or individual stations if the station ID
    is known. The resulting files include station data (e.g., station name,
    country, latitude, longitude, elevation) for use in a geographic
    information system (GIS). The function was largely based on T. Hengl's
    'getGSOD.R' script, available from
    <http://spatial-analyst.net/book/system/files/getGSOD.R> with enhancements
    to be cross-platform, more efficient with computing resources and more
    flexible. For information on the original data from NCDC, please see the
    GSOD readme.txt file available from,
    <http://www1.ncdc.noaa.gov/pub/data/gsod/readme.txt>.
Depends:
    R (>= 3.2.0)
License: GPL (>= 3)
Imports:
    data.table,
    doParallel,
    foreach,
    iterators,
    parallel,
    RCurl,
    readr,
    rgdal,
    sp,
    stats,
    utils
Suggests:
    chillR,
    dplyr,
    plotKML,
    spacetime,
    ggalt,
    ggplot2,
    knitr,
    lubridate,
    rgeos,
    rmarkdown,
    testthat,
    tibble,
    tidyr
RoxygenNote: 5.0.1
Encoding: UTF-8
NeedsCompilation: no
Repository: CRAN
LazyData: TRUE
ByteCompile: TRUE
VignetteBuilder: knitr

• URL for the package (the development repository, not a stylized html page):
  https://github.com/adamhsparks/GSODR
• Who is the target audience?
  Researchers who use daily weather data. Most individuals I've encountered so far
  are crop or plant disease modellers, hydrological modellers, etc. However,
  I'm there that there are others that I'm just unaware of due to my work-sphere.
• Are there other R packages that accomplish the same thing? If so, what is different about yours?
  gsod: obtain daily weather data" from Jacob Van Etten, 2013
  This package was written for a instructional course and has not been submitted
  to CRAN or updated in some time. It does offer the same corrected elevation that
  GSODR offers, however the station list is not updated from the NCDC server,
  meaning that the station list provided with this package is over two years old.
  It is part of a crop modelling course, not designed to only download and clean
  GSOD data. GSODR also offers different types of file outputs, Geopackage or
  comma-separated values (CSV).
  GSODTools: R functions to select, download, and process GSOD data
  This package is well written and maintained on GitHub only. The package is not
  available on CRAN at this date, either. It offers many of the same functions as
  GSODR. However, it does not automatically convert the values to International
  System of Units (SI), which GSODR does. It also does not offer the corrected
  elevation values that GSODR offers. Florian indicated that this project was
  not top priority during the completion of his PhD but was happy to consider
  working together in the future.
  rnoaa: R interface to many NOAA data APIs
  This package offers an interface to several of NOAA's weather data sets. However,
  GSOD is not among the data sets that are available through this package.

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

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:
• 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:
  Scott Chamberlain, https://github.com/sckott
  Brooke Anderson, https://github.com/geanders
  Florian Detsch, https://github.com/fdetsch
  Jeff Hansen, https://github.com/jeffreyhanson

[adamhsparks]

@sckott, I've found a bug that I need to fix.

Not sure how it's crept in. I will report back when it's corrected.

[adamhsparks]

Well that was embarrassing. It's all fixed now, @sckott.

Glad I checked the package build again this morning.

[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 @adamhsparks - no worries about eth bug

Will be seeking reviewers, but in the meantime: I ran goodpractice::gp() on your package. Here are the results, which it may be helpful to get started with before review (you can run it yourself and dig into the results more):

It is good practice to

  ✖ write unit tests for all functions, and all package code
    in general. At least some lines are not covered in this package.

    R/get_GSOD.R:230:NA
    R/get_GSOD.R:231:NA
    R/get_GSOD.R:234:NA
    R/get_GSOD.R:235:NA
    R/get_GSOD.R:238:NA
    ... and 359 more lines

  ✖ 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.
  ✖ 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/get_GSOD.R:283:1
    R/get_GSOD.R:284:1
    R/get_GSOD.R:287:1
    R/get_GSOD.R:306:1
    R/get_GSOD.R:456:1
    ... and 9 more lines

• The vignette takes a loooooooooong time to run. Please do figure out a way to make it run much more quickly.
• TheDescription field in the DESCRIPTION file is too detailed. Please make it more concise.

---

Reviewers: @jeffreyhanson @deniederhut
Due date: 2016-11-08

[adamhsparks]

Thanks for the valuable feedback. This is exactly the type of suggestions I was looking for here.

I'll get as much of this done as I can shortly.

[adamhsparks]

I've updated the DESCRIPTION file in the package and here in this issue as suggested.

[adamhsparks]

Vignette builds faster now, as suggested as well.

[adamhsparks]

Tomislav Hengl has contributed to the package and is now an author. I'll be merging his commits as I have time. However, I'll be on travel this week. So it may take me a while to address this.

[sckott]

Thanks for the updates @adamhsparks - seeking reviewers