@andybeet @kimberly-bastille
I lean towards mirroring the documentation in ecodata, since that's the data source. Along those lines, I'd also lean towards keeping the name the same (epu_sf). But I don't feel that strongly and would support changes, if you'd like to make some.

+1 to using the documentation from ecodata and pointing to tech doc.

For the naming, I don't think strata is the best since that really applies to survey files, and EPUs used survey inputs but are not used in the survey statistics that make those strata areas necessary. Maybe for this package, it is best to use the full name (Ecological_Production_Units).

so the CRS for this file uses "old-style crs object detected; please recreate object with a recent sf::st_crs()"

eg: +proj=longlat +lat_0=40 +lon_0=-77+x_0=0 +y_0=0 +datum=NAD83 +no_defs +ellps=GRS80 +towgs84=0,0,0

Should this be converted?

Also is it worth also adding centroid values (X,Y) as additional fields? These are present in other shapefiles (i think i may have added them as part of the conversion script for other shapefiles. These XY fields are often used when adding labels to polygons?

I forgot I had ignored that warning. I converted the raster::crs to the sf::st_crs in commit 4006a1b.

I support adding the centroid values but I was not sure how to do that.

Thanks for this awesome product!

I had one further thought on EPU documentation:

Some of our state of the ecosystem indicators use the spatial definition in this current dataset, but others are now using a NEFSC bottom trawl survey strata-based EPU definition.

This may not need to be a separate dataset if the documentation here includes a description of which survey strata map to which EPUs:

MAB <- c(1010:1080, 1100:1120, 1600:1750, 3010:3450, 3470, 3500, 3510)
GB <- c(1090, 1130:1210, 1230, 1250, 3460, 3480, 3490, 3520:3550)
GOM <- c(1220, 1240, 1260:1290, 1360:1400, 3560:3830)
SS <- c(1300:1352, 3840:3990)

Then everyone could use the same mapping.