afsc-gap-products / gap_products

This repository supports code used to create tables in the GAP_PRODUCTS Oracle schema. These tables include the master production tables, tables shared with AKFIN, and tables publicly shared on FOSS.
https://afsc-gap-products.github.io/gap_products/
Creative Commons Zero v1.0 Universal
5 stars 5 forks source link

EBS Standard and EBS Standard + NW agecomps in the same table #29

Closed zoyafuso-NOAA closed 3 months ago

zoyafuso-NOAA commented 4 months ago

@Duane-Stevenson-NOAA @Ned-Laman-NOAA @EmilyMarkowitz-NOAA (looping AKFIN folks in too @MattCallahan-NOAA @jeanlee-akfin)

We can’t escape the whole EBS Standard vs EBS Standard + NW business in our consolidated age table structure (GAP_PRODUCTS.AGECOMP) so I wanted to formalize that discussion into an issue here. Currently, the GAP_PRODUCTS.AGECOMP EBS values are from the EBS Standard + NW region. The EBS Standard region agecomps are omitted in this table currently. Users should in the meantime use this vignette in the gapindex package to create agecomps for the EBS Standard region.

Age-length keys are created globally, so age comps values for any given stratum will be different depending on the survey footprint. For example, the agecomp for female Age 5 ATF in Stratum 10 in 2021 will be different in the EBS Standard area versus the EBS Standard + NW. When we consolidate all regions into one GAP_PRODUCTS.AGECOMP table, we can’t distinguish these two records in this example because they both will have SURVEY_DEFINITION_ID = 98, YEAR = 2021, SPECIES_CODE = 10110, STRATUM 10, SEX = 2, AGE = 5.

So what do we do about this? Here are some ideas 1) Maia’s suggestion was to add another field to GAP_PRODUCTS.AGECOMP called something like “SURVEY_FOOTPRINT” and in that field we can distinguish “EBS STANDARD” vs “EBS STANDARD PLUS NW”, and also (redundantly) “GOA”, “AI”, “BSS”, “NBS” for the other records. 2) Provide a separate table like AGECOMP_EBS_STANDARD. I want to refrain from this because the whole point of GAP_PRODUCTS is consolidation. 3) Or, if we don’t need to support stratum-level Bering Sea agecomps anymore, then there is no issue here…fat chance but it’s hard to figure out data needs sometimes.

EmilyMarkowitz-NOAA commented 4 months ago

I vote for option 1 - I think it makes the most sense. I would name the column "AREA_ID_FOOTPRINT" or similar, because we should use an AREAID (e.g., 99902) in that column. SURVEY* seems to suggest that we should put a SURVEY_DEFINITON_ID in.

zoyafuso-NOAA commented 3 months ago

The latest production run (March 2024) includes this AREA_ID_FOOTPRINT field for testing. Hope that will be a good resolution. Closing this issue for now.