handling of boundary object for buffering method

[dcarver1]

Currently the boundary object is a world admin layer.
It's not huge but it might be the besting thing being passing to all the clusters.
also I'm not 100% sure how the crop function is going to treat admin boundaries. I'm assuming this layer it to remove any ocean area, but we don't want two objects for one buffer that is in USA and CAN.

Options.

1. test this if we have a species that has buffers that are crossing boarders.
2. dissolve the object so that it is effectively a landmass layer rather then a admin layer.
3. run a intersection with the a buffered bounding box on the point objects and select admins that intersect. Then dissolve the specific admin features and use that layer for the coast line buffer.

I like option 3 because is seems the most generic (though given the project scope I don't think that is such a primary concern) and it would allow a file size reducing the spatial feature that is being packed up and distributed across all the clusters.

• note option three would put some of the workflow outside of the primary wrapper function.

@akoontz11 Let me know yours thoughts here

[akoontz11]

Thanks @dcarver1. I don't totally understand the nature of the problem (likely because I'm less familiar with these shapefiles); I've tried to outline my questions below.

1. What's the functional issue with the boundary object being an admin layer (versus, say, a landmass layer)? Your explanation suggests this leads to 2 different objects being used when a buffer crosses a country border; will this impact the area calculations (due to the crop function)?
2. For Option 3: could this problem be addressed by simply referring to a different shapefile being read in (rather than what's currently being used)? I'm utilizing this shapefile because it's what's referenced in conservation gap analysis repository (from Emily Bruns; see here). But if a different layer would prevent this problem, I have no issue with changing the file.

I initially don't have a preference for any of the options you listed, but I may once I get a better handle on the problem. Thanks again!

[dcarver1]

@akoontz11

responses

1. Mostly just want to avoid any internal political boundaries. We don't want to count buffered area over water, so cropping to landmass makes sense. But because countries are all different rows in the spatail admin object if you crop a buffer area at the boarder of USA/MEX I think you will get a two object. One buffer area from US, One buffer areas to MEX. That would change the area calculations and introduce another object which might cause some weirdness in the reporting steps after the fact... (a guess)

2. Yes, different input data should work, but stills requires passing a Global shapefile to all the different distributed envs.

note these are closer to aesthetic changes as we're not having the boundary issue(1) with current species and we are running the process alot so efficency(2) is not a huge concern. They are still interesting enough to me that I wan't to write up a solution, but I'm saying all this out load because I don't want to get caught chasing shiny minnows when the big fish is still out there.

Ok, sooo I just wrote up two functions to do what I was thinking is the best route. check them out on the fork.
one just grabs a reference layer via an api, a consistency thing.
The other filters and dissolves that layer based on the relation to the occurrence data.
This would occur before the establishment of the disruptive environments. The result is a nice small vect file that limited to the countries of interest based on a maximum buffer extent. We could do something similar with the ecoregions as well

[akoontz11]

Thanks @dcarver1 --I checked these out post-holidays and I think the broad strokes make sense. Some questions just for my understanding:

1. The grabWorldAdmin function just downloads the country border data (for instance, the .shp and .prj files, etc.) if it's not already present on the user's directory, correct?
2. Because it includes the points that have been randomly sampled (wildPoints), the prepWorldAdmin function needs to be included in the "innermost" functions for the geographic resampling, right? I'm not familiar with the |> operator, but I think I nevertheless understand the gist of the function...

Thanks again!

[dcarver1]

@akoontz11

1. Yes, just a helper, I found myself having to download the file for a second time so just wrote it up. Doesn't need to be part of the individual soecies workflow.
2. I think this is ok outside of the wrapper. The wildPoints object is read in from the csv of occurrence. My impression was that this was the full set, so any sub sample would contain no more then is present here. Let me know if that holds true.

• Also note, this whole function was made for a problem I don't believe we actually have yet. I still think it's a good thing but I wouldn't call it a necessary thing.

the |> operator is a base R version of the %>%. Very similar functionality event that you need to need to include the "()" at the end of function calls where with the previous pipe operator you do not. We can swtich it all back to %>% for consistency, just need to do a find and replace. let me know

data |> select("column") |> pull()
vs
data %>% select("column") %>% pull

[akoontz11]

@dcarver1

Thanks; I misunderstood the main argument of the prepWorldAdmin function. Yes, wildPoints should be the full set.

No need to switch the |> operators right now, I would actually prefer to keep things in base R as much as possible. In any case, it's low priority.

[akoontz11]

@dcarver1

I'm encountering an issue with prepWorldAdmin, and figured I'd use this thread to describe it. This occurs when I try to use this function for the QULO coordinates (example here). This generates the following warning:

Warning message:
[SpatVector from sf] empty SpatVector 

The resulting world admin layer (world_poly_clip) has an extent of 0, which leads to the resampling functions to crash.

After digging, the problematic lines appear to be here. The uniqueLocs object is NA when using the coordinates for QULO...but, with QUAC, this value is USA. I can't really figure out why the behavior is different between the different sets of coordinates.

Let me know if you can't replicate this behavior with the QULO coordinates, or if you have any ideas on the issue.

[dcarver1]

@akoontz11

Hmmm, I just took a look and I don't have an immediate suggestion.

Few things.

Passing the point object to the Terra::Extract functions works... Passing the convex hull or buffered convex hull does not.

For the time being I'd recommend just commenting out line 62 and relying on the full world admin object generated in line 60 for the analysis.

The start of this whole issue was built around a bit of an optimization concern, so skipping it in this case should not effect the behavoir/results.

I'll report back when I figure out the issue in the prepWorldAdmin function

[akoontz11]

@dcarver1 thanks--sounds good. I can skip over this function for now.

[dcarver1]

@akoontz11
Just pushed a new branch with a rework of the function.
There was a project issue with the buffered bbox object not retaining CRS information.
I address this, and change the spatial relationship function from extract to intersect. I think this is a more intuitive approach.

Do want to test with PICO as that dataset might cross the US/CA boarder with was the whole use case for building out this functionality.

Lobota ran clear ~25 minute run.