Can oisst be projected to the same grid and formatted the same as the bccm data?

[ecophilina]

It would be useful if there was a version of the oisst monthly data (or a conversion function to create one) that matched the format of the bccm variables. Despite overlapping in time and space, it's not obvious at the moment how one could get them into matching formats.

Currently oisst_month is:

Simple feature collection with 476375 features and 7 fields
Geometry type: POINT
Dimension:     XY
Bounding box:  xmin: -138.625 ymin: 46.625 xmax: -123.125 ymax: 54.625
Geodetic CRS:  WGS 84
# A tibble: 476,375 × 8
    year month   sst sst_sd sst_n start_date end_date  
 * <dbl> <dbl> <dbl>  <dbl> <int> <date>     <date>    
 1  1981     9  16.4  0.830    30 1981-09-01 1981-09-30
 2  1981    10  14.3  0.838    31 1981-10-01 1981-10-31

while the bccm_surface_temperature() object is:

Simple feature collection with 40580 features and 324 fields
Geometry type: POLYGON
Dimension:     XY
Bounding box:  xmin: 164671.6 ymin: 163875 xmax: 1097612 ymax: 1103653
Projected CRS: NAD83 / BC Albers
# A tibble: 40,580 × 325
   `1993_1` `1993_2` `1993_3` `1993_4` `1993_5` `1993_6`
 *    <dbl>    <dbl>    <dbl>    <dbl>    <dbl>    <dbl>
 1     5.28     5.35     5.56     6.78     9.34     11.8
 2     5.26     5.32     5.54     6.76     9.34     11.9

[cgrandin]

Looks like conversion from NAD83 to WGS84 which will be possible (they are almost idenical anyway)

Look here: https://r-spatial.github.io/sf/reference/st_transform.html

The CRS for WGS84 is 4326 which is what's in this function I wrote for plotting the hake overview map, you can use ggplot to plot these sf objects:

https://github.com/pacific-hake/hake-assessment/blob/4e588434b2a3a909a9ec8f4d16c4969280c7ad7d/R/plot-map.R#L111

sf also has functions to transform POINT to and from POLYGON data sets

[andrew-edwards]

Thanks Philina, I hadn't realised these were different. I can probably figure out a function for this, based on some of the conversions from Travis that I've been adapting for the new HOTSSea Salish Sea model. I'm away next week and might not have time this week, but will try.

[schckngs]

@ecophilina For clarity, you mean you are looking for the same data format (long vs wide, with time as columns) rather than matching the same spatial resolution/pixel extents? You can project to BC Albers (epsg 3005) or back to epsg 4326, and to rearrange the OISST data it's likely a good use for tidyr::pivot_wider()

[ecophilina]

I have functions written that extract averages for certain spatial areas from the bccm data and I would like to be able to use the same functions with oisst data. I'm assuming some kind of interpolation step would be required to get the resolutions from the point data to match the polygon grid that bccm uses?

So no, I think I do want the same spatial resolution/pixel extents as the BCCM data that is stored with the package. I realize that the original data for both differ in resolution.

Ultimately, I need to be able to project all variables to identical grids---usually as averages (though min, max, sd are also potentially useful) for polygon cells (which often later get defined by their centroid coordinates).

[andrew-edwards]

Can't you use what's in the OISST vignette? https://htmlpreview.github.io/?https://github.com/pbs-assess/pacea/blob/main/vignettes/oisst.html Sounds like what you want is already in there with functions.

[ecophilina]

For today, I can probably modify something from there. But it means writing a whole new function, because I need the output to match the output for the ones I wrote for the bccm data. Since, long-term I will need projected grids that are in identical formates for all variables to be used in spatial models. Converting it first to match the bccm gridded data would save a step.

[andrew-edwards]

I think is the way to do it (Philina, following our chat) - Kelsey did it properly for the depth data: https://github.com/pbs-assess/pacea/blob/687267f223009de25f0726aae9bbee111b3669d6/data-raw/depth/depth.R#L35

@schckngs - thanks for the pivot_wider() tip; worked like a charm!

[goldford]

If the data types match (iosst is poly instead of pts) it might be enough to resolve @ecophilina's issue? Not necessarily a common grid needed.

[andrew-edwards]

I've done this in a new vignette oisst_to_grid26.Rmd but haven't pushed it as it's not really a vignette (it was easier to adapt an existing vignette). Sent Philina the .rds file, which is good for now. Could be worth trying to write those calculations as a function, which will help with #62 (or just mean that users can map OISST to any grid, and we just keep saving the values as we have been, on the original grid they come on).

[andrew-edwards]

I had actually pushed the .Rmd, just on the dev-andy branch.