The easiest way to note any behavioural curiosities or to request any new features is by opening a github issue.
If you'd like to contribute changes to osmdata
, we use the GitHub
flow for proposing,
submitting, reviewing, and accepting changes. If you haven't done this before,
there's a nice overview of git here, as well
as best practices for submitting pull requests
here.
The osmdata
coding style diverges somewhat from this commonly used R style
guide, primarily in the following two ways,
both of which improve code readability: (1) All curly braces are vertically
aligned:
this <- function ()
{
x <- 1
}
and not
this <- function(){
x <- 1
}
and (2) Also highlighted in that code is the additional whitespace which
permeates osmdata
code. Words of text are separated by whitespace, and so
code words should be too:
this <- function1 (function2 (x))
and not
this <- function1(function2(x))
with the natural result that one ends up writing
this <- function ()
with a space between function
and ()
. That's it.
You can use precommit::use_precommit()
to enforce this style with git commit
hooks as defined in .pre-commit-config.yaml
. The first commit can be slow
because the hooks have to be compiled and installed. To commit ignoring hooks,
git commit --no-verify
, or shortened version, git commit -n
.
To refresh the README.md
file after modifying README.Rmd
, use:
devtools::build_readme(output_format="md_document")
When updating the package dependencies in DESCRIPTION
or other metadata,
refresh codemeta.json
:
codemetar::write_codemeta()
We want to encourage a warm, welcoming, and safe environment for contributing to this project. See the code of conduct for more information.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.