search

kaijagahm / vultureUtils

Utility functions for working with vulture data
Other
4 stars 0 forks source link

Add function to exclude data from GPS jamming polygons #122

Closed kaijagahm closed 6 months ago

kaijagahm commented 6 months ago

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.

ryannguyen6392 commented 6 months ago

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 https://github.com/r-spatial/sf/issues/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.

kaijagahm commented 6 months ago

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.

kaijagahm commented 6 months ago

Remember to make this its own separate function instead of having it included in cleanData.