Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grammatical suggestions for the paper #20

Closed
lheagy opened this issue Apr 3, 2019 · 3 comments
Closed

Grammatical suggestions for the paper #20

lheagy opened this issue Apr 3, 2019 · 3 comments

Comments

@lheagy
Copy link

lheagy commented Apr 3, 2019

Just a couple grammatical suggestions for the paper in
openjournals/joss-reviews#1221. Please adopt what you think fits and leave those that don't.

Introduction

Despite this, researchers often use them as proxies for neighborhoods since they come with readily available data and the techniques for estimating population values for overlapping but incongruent areas, such as a shapefile of neighborhood boundaries for a city, are less accessible.

This statement is fairly long, and it isn't entirely clear to me what the "are less accessible" is referring to. Would you mind trying to clarify this?

Unlike interpolation techniques, like inverse distance weighted interpolation, that are appropriate for point data, areal weighted interpolation is designed specifically for working with already aggregated data to some set of polygon spatial features

"like" is fairly informal for academic writing. Does "such as" or similar work?

The estimation process vary based on whether data are spatially extensive

Should be "varies" (or "estimation processes vary")

a census tract with a large park in it, for example, or a neighborhood that has a significant commercial area alongside residential housing

The grammar is a bit off here. How about: "for example, a census tract with a large park or a neighborhood that has a significant commercial area alongside residential housing would violate this assumption."

The areal R package

We also aim to provide additional functionality in comparison to the one existing approach found in the sf package [@pebesma2018simple], the st_interpolate_aw() function, while providing support for modern data management (e.g. tidyverse) and spatial data (e.g. sf) frameworks.

I think this can be lightly re-worded to be more clear: e.g.
"We also aim to provide additional functionality that is not currently available in existing approaches found in the sf package [@pebesma2018simple], for example the st_interpolate_aw() function, while providing support for modern data management (e.g. tidyverse) and spatial data (e.g. sf) frameworks."

allow for friction-less, iterative interpolation of both spatially extensive (e.g., count) and intensive (e.g., ratio) data, and

"frictionless" (no dash is needed)

@lheagy
Copy link
Author

lheagy commented Apr 3, 2019

There are also a few missing doi's in the references

@chris-prener
Copy link
Owner

Thanks @lheagy - will get back with changes this weekend.

@chris-prener
Copy link
Owner

All changes have been made and committed to the master branch @lheagy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants