stplanr

[Robinlovelace]

• 1. What does this package do? (explain in 50 words or less)
     This package brings together a number of tools that enable transport modelling and planning and R, with an emphasis on analyses needed for sustainability (e.g. planning new bicycle paths).
• 2. Paste the full DESCRIPTION file inside a code block (bounded by ``` on either end).

Package: stplanr
Type: Package
Title: Sustainable Transport Planning with R
Version: 0.0.1.1
Date: 2015-10-18
Authors@R: c(
    person("Robin", "Lovelace", email = "rob00x@gmail.com", role = c("aut", "cre")),
    person("Richard", "Ellison", role = c("aut"), comment = "Author of various functions"),
    person("Barry", "Rowlingson", role = c("aut"), comment = "Author of overline"),
    person("Nick", "Bearman", role = c("aut"), comment = "Co-author of gclip")
    )
Description: Functionality and data access tools for transport planning, including origin-destination analysis, route allocation and modelling travel patterns.
License: MIT + file LICENSE
BugReports: https://github.com/robinlovelace/stplanr/issues
LazyData: yes
Depends:
    sp, R (>= 3.0)
Imports:
    jsonlite,
    maptools,
    raster,
    rgdal,
    rgeos,
    dplyr,
    RgoogleMaps,
    openxlsx,
    leaflet,
    httr
Suggests:
    testthat,
    knitr,
    tmap
VignetteBuilder: knitr
URL: https://github.com/Robinlovelace/stplanr

• 3. URL for the package (the development repository, not a stylized html page)
     https://github.com/Robinlovelace/stplanr
• 4. What data source(s) does it work with (if applicable)?
     Example data on route allocation and travel flows (included - more planned), geographical boundaries, transport networks, example travel survey data (to be added subsequently)
• 5. Who is the target audience?
     Transport researchers and modellers from academic, public and private sectors. University students studying transport geography, transport modelling and related disciplines.
• 6. Check the box next to each policy below, confirming that you agree. These are mandatory.
• The repository has continuous integration with Travis and/or another service
• The package contains a vignette
• The package contains a reasonably complete readme with devtools install instructions
• The package contains unit tests
• 7. Do you agree to follow the rOpenSci packaging guidelines? These aren't mandatory, but we strongly suggest you follow them. If you disagree with anything, please explain.
• Are there any packages that your package depends on that are not on CRAN?
• Do you intend for this package to go on CRAN?
• Does the package have a CRAN accepted license?
• Did devtools::check() produce any errors or warnings? If so paste them below.
• 1. Please add explanations below for any exceptions to the above:
     This is work in progress and I am learning how to build R packages as I progress. These issues will be fixed, probably during a course on R package development I will attend.
• 9. If this is a resubmission following rejection, please explain the change in cirucmstances.

[sckott]

hi @Robinlovelace - Thanks for your submission.

Did you mean to check off some of those things? E.g., you checked that you have continuous integration, but you don't, and that you have tests, but at least we don't see any.

Can you correct the information above?

[Robinlovelace]

@sckott I need to learn more about 'continuous integration' and tests. I'm attending a 3 day course on R package development in May. Proposal: I close this issue for now and re-open once I know more about those things and have had more feedback about the package in general. And I'll reduce the number of check() warnings! Sound good? Any advice appreciated. The tool is already being used for real-world applications and I'm sure it will be useful, once it's a little more polished.

[sckott]

@Robinlovelace Up to you if you want to close the issue and open a new one later.

Where are users expected to get data for use in functions from your package? If data is publicly available (e.g., via web APIs, or even just ftp), we can help build in some functions to provide data access.

I'm attending a 3 day course on R package development in May.

cool, sounds good!

The R CMD CHECK warnings aren't a huge deal - we can help with those. Bigger issues are:

• fit for ropensci - if there is data access functionality in your package (discussed above), it would be a better fit for us
• vignettes/help for users: this is pretty crucial - we want it to be easy for users to figure out how to use a package
• tests - tests are pretty crucial to make sure any functionality of the package doesn't break when something is changed

[karthik]

@Robinlovelace Just wanted to mentioned that we can also help with some of these issues. If you tag one of us in your repo, we can help with CI, testing and other CHECK issues. And as we go along we can add this to our knowledgebase (on the wiki for this repo) so that others in the future can benefit (and also streamline the process).

[sckott]

@Robinlovelace let's leave this issue open for now. I added the holding tag to indicate that we're in a holding pattern for now, and we can remove again once we are moving forward with a review. Okay with you?

[Robinlovelace]

Sound great @sckott. More detailed responses coming soon, but YES this package enables access to new open source data and YES it will be very well documented with vignettes etc. Check out my work on osmar, which is kind-of an introductory vignette to the package: https://github.com/Robinlovelace/osm-tutorial/blob/master/osm.pdf The reason I want to be affiliated with ropensci is that actively encourages such clear reproducibility, communication and empowerment through technology. Based on the supportive feedback holding sounds like the ideal solution for now.

[sckott]

@Robinlovelace Okay, sounds good. So this package already does data acquisition? Or it will? Do you mind if I uncheck boxes that aren't complete yet?

[Robinlovelace]

@sckott yes. gLines2CyclePath harvests data from the CycleStreet.net routing API. We plan to add interfaces to other routing APIs. Here are a couple of examples of the kind of data it pulls in, of a couple of routes in Manchester and a few thousand OD flows in Coventry:

[Robinlovelace]

Don't mind at all if you uncheck uncompleted boxes, please do.

[sckott]

@Robinlovelace Cool - nice example! Boxed unchecked.

[Robinlovelace]

@sckott OK, I'm down to only 3 warnings from 7.

Any ideas how to remove the remaining 3?

Also check the updated README:
https://github.com/Robinlovelace/stplanr

What else do I need in there for this to be 'ropensci compliant'?
Thanks for the support, more to come.

[sckott]

WARNING '::' or ':::' import not declared from: ‘sp’ 'library' or 'require' call not declared from: ‘sp’

• Looks like you are using the sp package but you didn't put it into your DESCRIPTION file to load
• Looking at your NAMESPACE file, I'd suggest not using exportPattern("^[[:alpha:]]+") and instead using roxygen @export to explicitly declare what functions you want exported to users, and which not exported - also, using @import tags (e.g., @import sp) will put the appropriate entry in your NAMESPACE file for packages to import

Namespaces in Imports field not imported from: ‘dplyr’ ‘RCurl’ ‘rgdal’ ‘rgeos’ All declared Imports should be used.

• See above comment. Some of these packages are in your DESCRIPTION file, but some are not. R check found that you either A) use one of those packages in yours but it's not imported (in the DESCRIPTION and NAMESPACE files), or B) you don't use one of those packages in your package, but it's listed to import

WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems.

• Hard to say what's wrong here, other than that something with Rd files.

WARNING '::' or ':::' import not declared from: ‘sp’ 'library' or 'require' call not declared from: ‘sp’

• You need to add sp to package imports

[sckott]

Also, I'm getting a bunch more warnings locally running check on your package. Do you not get these?

* using R version 3.1.3 (2015-03-09)
* using platform: x86_64-apple-darwin13.4.0 (64-bit)
* using session charset: UTF-8
* checking for file ‘stplanr/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘stplanr’ version ‘0.0.0.9005’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘stplanr’ can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... NOTE
License components which are templates and need '+ file LICENSE':
  MIT
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking dependencies in R code ... WARNING
'::' or ':::' import not declared from: ‘sp’
'library' or 'require' call not declared from: ‘sp’
'library' or 'require' call to ‘sp’ in package code.
  Please use :: or requireNamespace() instead.
  See section 'Suggested packages' in the 'Writing R Extensions' manual.
Namespace in Imports field not imported from: ‘dplyr’
  All declared Imports should be used.
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... NOTE
disab_recat: no visible binding for global variable ‘b’
gFlow2line: no visible global function definition for ‘Line’
gFlow2line: no visible global function definition for ‘proj4string<-’
gFlow2line: no visible global function definition for ‘proj4string’
gLines2CyclePath: no visible global function definition for ‘Lines’
gLines2CyclePath: no visible global function definition for ‘Line’
gLines2CyclePath: no visible global function definition for
  ‘SpatialLines’
gLines2CyclePath: no visible global function definition for
  ‘proj4string<-’
gLines2CyclePath: no visible global function definition for ‘CRS’
gOverline: no visible global function definition for ‘over’
gOverline: no visible global function definition for
  ‘SpatialLinesDataFrame’
islines: no visible global function definition for ‘gIntersection’
lineLabels: no visible global function definition for ‘coordinates’
lineLabels: no visible global function definition for ‘gCentroid’
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... WARNING
Missing link or links in documentation object 'islines.Rd':
  ‘gOverline()’

See section 'Cross-references' in the 'Writing R Extensions' manual.

* checking for missing documentation entries ... WARNING
Undocumented code objects:
  ‘lineLabels’
All user-level objects in a package should have documentation entries.
See chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... WARNING
Undocumented arguments in documentation object 'gOverline'
  ‘fun’

Undocumented arguments in documentation object 'gSection'
  ‘sl’

Undocumented arguments in documentation object 'islines'
  ‘g1’ ‘g2’

Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... WARNING
'::' or ':::' import not declared from: ‘sp’
'library' or 'require' call not declared from: ‘sp’
* checking contents of ‘data’ directory ... OK
* checking data for non-ASCII characters ... OK
* checking data for ASCII and uncompressed saves ... OK
* checking examples ... ERROR
Running examples in ‘stplanr-Ex.R’ failed
The error most likely occurred in:

> ### Name: gOverline
> ### Title: Convert series of overlapping lines into a route network
> ### Aliases: gOverline
>
> ### ** Examples
>
> data(routes_fast)
> rnet <- gOverline(sldf = routes_fast[1:7,], attr = "length")
Error in gOverline(sldf = routes_fast

[Robinlovelace]

@sckott Yes, it's because I just added gOverline() and related functions which have caused additional warnings - there's been a lot of interest in the package of late and I expect more such functions, created by additional authors, to be added soon. Will debug based on your suggestions.