forked from slu-openGIS/postmastr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.Rmd
56 lines (41 loc) · 4.94 KB
/
index.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
---
output: github_document
---
```{r setup, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>",
fig.path = "man/figures/index-",
out.width = "100%"
)
```
# postmastr <img src="man/figures/logo.png" align="right" />
[](https://www.tidyverse.org/lifecycle/#maturing)
[](https://travis-ci.org/slu-openGIS/postmastr)
[](https://ci.appveyor.com/project/chris-prener/postmastr)
[](https://codecov.io/github/slu-openGIS/postmastr?branch=master)
[](https://cran.r-project.org/package=postmastr)
The goal of `postmastr` is to provide consistent, tidy parsing of street address data. The package is currently oriented towards American street addresses, e.g. "123 East Main Street". It contains functions for both standardizing address elements (e.g. converting street names like "Second" to "2nd" or converting "AV" to "Ave") and for parsing out intput strings into separate variables for each input element.
## Seeking Beta Testers
We've at a point where all major functionality except for the ability to work with unit types and numbers is ready for testing. If you work with American street addresses regularly and have the time to take the package for a spin, we'd love feedback before we submit to CRAN. We want to make sure the workflow works, and can handle whatever addresses we throw at it. Also, `postmastr` is only set-up for American street addresses right now but the functions have been built for expansion. If you work with international street addresses and want to contribute, please [open a feature request issue](https://github.com/slu-openGIS/postmastr/issues/new/choose) and introduce yourself!
### Recent Breaking Changes
As of March 27, 2019, There is now a workflow for parsing intersections build into `pm_parse`. There are two breaking changes to be aware of:
* `pm_identify()` is no longer part of `pm_parse()`, and therefore must be run ahead of time by the end user
* `pm_prep()` now has a required `type` parameter that should either be `"street"` or `"intersection"`
* there have been changes to the arguments for `pm_replace()`, `pm_rebuild()`, and `pm_parse()` as well
The intersection workflow is very similar to the street address workflow except that intersections must be prepared with `pm_intersect_longer()`, than parsed, then put back together with `pm_intersect_wider()` before replacing and rebuilding. The intersection workflow supports both short (i.e. `Main St at First Ave`) and long (i.e. `Main St at First Ave, St. Louis MO 63110`) forms.
## Motivation
Street addresses can be notoriously difficult to work with. In the United States, the U.S. Postal Service has [standards for their composition](https://pe.usps.com/text/pub28/welcome.htm). There is so much variety, however, that anticipating all of the possible permutations of addresses is a significant task. When the inaccuracy of human data entry is added, the challenge of parsing addresses becomes monumental. The goal of `postmastr` is to provide a uniform workflow for parsing street address data that allows for sufficient flexibility.
This flexibility is provided in two ways. First, we utilize "dictionaries" for a number of the key functions that allow users to provide vectors of data to base parsing on. This enables `postmastr` to parse potential misspellings and colloquial terms that are hard (or impossible) to predict. Second, not all aspects of the workflow are mandatory - if street address data do not contain postal codes, states, or cities, for example, those functions can be skipped.
## Installation
`postmastr` is not available from CRAN yet. In the meantime, you can install the development version of `postmastr` from Github with `remotes`:
```{r gh-installation, eval = FALSE}
# install.packages("remotes")
remotes::install_github("slu-openGIS/postmastr")
```
## Resources
The main [Get started](articles/postmastr.html) article has a full example of the `postmastr` workflow.
## Expansion
The `postmastr` functions all contain a `locale` argument that is only enabled for American (i.e. `locale = "us"`) addresses. Assistance with expanding `postmastr` functionality to other countries would be most welcome. If you work with street address data in another country and would like to contribute to `postmastr` by extending its functionality, please [open a feature request issue](https://github.com/slu-openGIS/postmastr/issues/new/choose) and introduce yourself!
## Code of Conduct
Please note that this project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.html). By participating in this project you agree to abide by its terms.