osmdata package

[mpadge]

Summary

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

Download OpenStreetMap (OSM) data and convert to native R objects defined by sf or sp packages. OSM datasets are extracted from the overpass API and processed with efficient C++ routines.

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

Package: osmdata
Version: 0.0.0
Authors@R: c(
    person("Mark", "Padgham", email="mark.padgham@email.com", role=c("aut", "cre")),
    person("Bob", "Rudis", role="aut"),
    person("Robin", "Lovelace", role="aut"), 
    person("Maëlle", "Salmon", role="aut"),
    person("Andrew", "Smith", role="ctb"),
    person("Marcin", "Kalicinski", role=c("ctb", "cph"),
        comment="Author of included RapidXML code"),
    person("Finkelstein", "Noam", role=c("ctb","cph"),
        comment="Author of included stub.R code"),
    person ("Bartnik", "Lukasz", role=c("ctb","cph"),
        comment="Author of included stub.R code"))
Maintainer: Mark Padgham <mark.padgham@email.com>
Title: Download OpenStreetMap Data with the Overpass API
Description: Extraction of OpenStreetMap (OSM) data as 'sf' or 'sp' objects.
    OSM data are extracted from the overpass API and processed with very fast
    C++ routines for return to R.
Depends:
    R (>= 3.2.4)
License: GPL-3 + file LICENSE
SystemRequirements: C++11
NeedsCompilation: yes
LazyData: true
Imports:
    curl,
    httr,
    lubridate,
    methods,
    Rcpp (>= 0.12.4),
    rvest,
    jsonlite,
    sp,
    utils,
    xml2
Suggests:
    devtools,
    knitr,
    microbenchmark,
    rmarkdown,
    roxygen2,
    sf,
    testthat
LinkingTo: Rcpp
URL: https://github.com/osmdatar/osmdata
BugReports: https://github.com/osmdatar/osmdata/issues
Encoding: UTF-8
RoxygenNote: 6.0.1
VignetteBuilder: knitr

• URL for the package (the development repository, not a stylized html page):

https://github.com/osmdatar/osmdata

• Who is the target audience?

Anyone interested in geospatial analysis and visualisation, especially geographers, urban and transport modellers and planners.

• Are there other R packages that accomplish the same thing? If so, what is different about yours?

The package is similar to GDAL through the interface provided by sf, yet produces fundamentally different results, as briefly described in the main vignette, and detailed at length in a second vignette. osmdata also reproduces much functionality available in the CRAN package osmar, yet does so enormously faster (like at least thousands of times faster!) and with a more intuitive user interface. The package also imports data faster than sf. osmar only returns data defined by a bounding box, while the osmdata interface to the overpass API allows highly customised and specific queries to be constructed (see examples in main vignette). osmdata is also designed to complement the ropensci package osmplotr, and the latter package will be modified immediately following CRAN acceptance of osmdata.

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)

NOTE: As per the JOSS guidelines, the package will be submitted to a long-term repo subsequent to the review process

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:

  • Jochen Topf / joto - Main developer of osmcode and author of libosmium
  • Edzer Pebesma / edzer - Developer of the R packages sp and sf

[mpadge]

One further comment prior to review: The goodpractice output about <- instead of = and also about sapply() mostly arise from fragments of sf code which are copied verbatim to ensure absolute consistency with sf functionality. I do not intend to modify these fragments (except to reflect changes in sf itself). Other than this, sapply()is only used in sapply (x, is.null)-type statements, to which the goodpractice remarks do not apply.

[karthik]

Looking for reviewers. Will update thread when I do.

[karthik]

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

Thank you for your submission! Out of curiosity, can you speak to how this relates to functionality from the Openstreetmap package in terms of overlap?

While I seek reviewers I want to bring your attention to a few checks that were reuturned by goodpractice. I have noted your comments about the notes around code copied over from sf (so I've removed those). There is no urgency to address them before the review, but it would be good to fix during.

• Here are outputs from automated testing using goodpractice::gp(). I'd also recommend using devtools::spell_check() to examine documentation.

── GP osmdata ───────────────────────────────────────────────

It is good practice to

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

    R/features.R:24:NA
    R/features.R:55:NA
    R/opq.R:75:NA
    R/opq.R:76:NA
    R/osm-extract.R:55:NA
    ... and 275 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

    tests/testthat/test-extract.R:74:1
    tests/testthat/test-extract.R:84:1
    tests/testthat/test-extract.R:121:1
    tests/testthat/test-extract.R:171:1
    tests/testthat/test-osmdata.R:21:1
    ... and 15 more lines

 

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

[mpadge]

Thanks Karthik!

In response to your Q, OpenStreetMap simply produces raster layers representing OSM data, and is a purely graphical thing; osmdata returns the actual data, and is not a graphical thing at all. I see no real relationship between them.

As for the goodpractice results:

• This is a package which can not be fully covered in tests, but is actually > 90% in total, and will increase slightly beyond that
• The import warning is for sp, and can't be avoided because the /src code needs an [[Rcpp::Depends(sp)]], requiring the whole package to be imported even though it's not actually required in the R code at all.
• Long lines are only for tests, and are all for long strings containing warning/error messages being tested. Can be eliminated by reducing indentation within each test block, but believe me, that makes the tests much harder to read, not easier. They are also almost all only 81 or 82 characters. I would strongly prefer not to change these, if that's acceptable.

[noamross]

FYI, while we don't strictly enforce line limits, putting #nolint after a long message line or URL in code suppresses linting that line and gives me peace of mind and clean gp() results. A .lintr file is useful for excluding files in some cases (such as auto-generated Rcpp code), but of course easily abused ;)

[karthik]

@mpadge Perfect, your responses make sense to me.
@noamross Thanks for those useful tips! 💯