-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add function to exclude data from GPS jamming polygons #122
Comments
Right now, the GPS jamming polygons are giving trouble with st_intersects. As a workaround, the current implementation uses sf_use_s2(FALSE) to get around this (see r-spatial/sf#1902). Actually, I hadn't yet read this closely, and seems like it has the potential to solve the errors, though it may be resolving them automatically by turning the 3D polygons into planar. The call to cleanData takes in an optional sf object, jamMask, at the moment to ease implementation. It may be moved to the package data. The current implementation is awaiting testing before a pull request is to be made. |
I'm really not that worried about 3D vs. non-3D polygons in this case, since we're dealing with a pretty small area of the globe and the polygons don't need to be ultra-specific (I'd be more worried about roost polygons, for instance, than these). So feel free to use whatever workaround you deem necessary. Good call on waiting for testing to see about moving the mask to the package data vs. not. |
Remember to make this its own separate function instead of having it included in cleanData. |
See Marta's email for the polygons: subject line is "Polygons to filter out the GPS jamming". Polygons to use are called "GPS_jamming_2.kml".
I'm on the fence about whether the polygons should actually be stored in the package itself as internal data and referenced from a function, or whether the user should pass in the polygons to what will otherwise be a straightforward wrapper of
st_intersects()
with the various intermediate steps taken care of. Play around with this and see what you think.Remember: for this function, you'll need to either 1) include a check to make sure the data object that gets passed in is already an sf object suitable for intersecting with the polygons, or 2) include code in the function itself to accept either a data frame or an sf object and, if needed, convert the data frame to sf with the suitable crs. Either way, please make sure to document this carefully so it's clear to the user what needs to happen.
The text was updated successfully, but these errors were encountered: