Test of updated 2014 5-year crosswalk method - ran employment subgrou…

[jwalsh28]

…ps for places

This fixes the issue of losing PUMAs from the years prior to 2012 in the 5-year ACS sample for 2014. Tested on the place subgroup file for employment. Edits were made around the crosswalk section to match on to new crosswalk period "2k" and then consolidate back into one crosswalk indicator.

If this test is confirmed successful there is one other metrics that need to be updated:

• Opportunities for income

[malcalakovalski]

Took a close look at the crosswalk changes and the employment test. The approach looks right to me: assigning crosswalk_period from multyear instead of the file year is what IPUMS recommends for the mixed-vintage 5-year samples, and the 2k crosswalk setup (GeoCorr 2018, 2010 pop weights, 2014 geographies) is consistent with how the 2012 one was built.

A few things to fix before this merges though:

1. The filter(afact > 0) step in the county QMD gets thrown away. It assigns the filtered data to puma_county20/10/2k, but the next chunk re-assigns those same objects from the unfiltered data. The committed crosswalk_puma_to_county.csv has 62 rows with afact == 0. The place QMD chains the filter into one pipeline so county should do the same.

2. alaska_split rows end up with crosswalk_period = NA. crosswalk_period is assigned in clean_cw(), but alaska_split is bound in afterward, so Chugach (02-063) and Copper River (02-066) never match a join. Each bind needs its own period label. Worth double checking the afact split for the 2k copy too, since the ratio came from the 2012 PUMA boundaries.

3. Renaming "pre-2022" to "2012"/"2k" breaks more than opportunities for income. Employment, income, preschool, college prep, digital access, housing value, and housing affordability all still filter or join on crosswalk_period == "pre-2022", and so does check_crosswalk_geoids_present.R. These are left joins, so they fail silently with NAs. We should either update all of them in this tranche or hold the regenerated CSVs until they're ready.

4. The raw 2k GeoCorr files aren't committed, so I couldn't re-run these QMDs.

For when this gets applied to the other metrics: the "2k" to "2012" recode only covers the pre-2022 case, so a 2022 or 2023 run would produce two rows per place-year. And multyear is NA in 1-year samples, so the county files will need something like coalesce(multyear, year).

Also a typo: the county QMD's "Read data" paragraph says "Place" where it should say "County".

[jwalsh28]

@malcalakovalski Back to you!

Two things:

1. I checked the Alaska 2k to 2012 Puma difference. There was a very slight change (under 5 percent of the population shifted PUMAs). It would be most accurate to try to account for this but I honestly was not sure how to do it. Let me know if you have thoughts.

2. I don't quite understand your last point. I don't think the post-2022 needed to change? And for 1-year update I think we can just use year inn the crosswalk but please double-check that.

[malcalakovalski]

The Alaska and afact fixes look good. Confirmed in the regenerated CSV: no more zero-afact rows, and Chugach and Copper River now carry the right period labels.

On the Alaska split ratio, I'd leave it as is. You're right that it touches very few observations and I agree it's not worth the work. It only touches Chugach (~7k) and Copper River (~2.6k), both already quality 3, so a sub-5% shift between them won't move any metric. Getting it exact would mean pulling a 2000 PUMA GeoCorr crosswalk and re-deriving the ratio, which is a lot of work for ~10k people in the lowest-quality bucket of data. A short comment noting the 2k split reuses the 2012 ratio is plenty!

On my last point, let me explain it better: The consolidation step only collapses "2k" into "2012". The 2022+ 5-year files mix 2012-vintage and 2020-vintage PUMAs the same way the 2014 file mixes 2000 and 2012, so once the multyear method is used for those years each file will carry
both a "2012" and a "2022" label, produce two rows per place, and trip the 486-row check. It won't show up here since you're only re-rendering 2014, but it will the first time someone runs a 2022+ file this way. It would be a good idea to be proactive and generalize now instead of addressing it later.

One more thing worth sorting before this merges: the regenerated crosswalk CSVs rename the period values from "pre-2022" to "2012"/"2k", and those files are shared by every metric. The others (income, preschool, college prep, and so on) still filter on the old "pre 2022" label, so the first time any of them is rendered against the new crosswalk it'll quietly match nothing for the pre-2022 years. We could update those metrics here or in a quick follow-up PR, whichever you prefer, I'd just want to avoid the new crosswalk files landing on the tranche ahead of the code that reads them.

Last thing, agreed on using year for the 1-year updates. No vintage mixing inside a single year, and multyear isn't populated in 1-year extracts anyway, so year is exactly right.

[jwalsh28]

@malcalakovalski updated for your comments.

First I added a comment in the generate puma to county code that notes the logic on using 2012 PUMA to county ratios for the 2k Alaska split. I feel confident we are right that this has no meaningful impact on the metrics.

I finally am with you on the consolidation point for the crosswalk and it actually led to catching a bigger issue. See this link - IPUMS makes changes to 5-year data that include both pre and post-2022 multyears such that the PUMAs area all adjusted for 2022. It actually did not make sense to include more nuanced crosswalk periods for these 5-year periods. See my solution, I believe this handles it now.

Agreed this is going to break other codes but I think the solution is to accept this and then in a subsequent PR update all codes impacted. Next step will be to create a list of all files that reference these crosswalks.

[malcalakovalski]

Thanks for addressing my comments @jwalsh28. This is very close! I confirmed the IPUMS behavior on that thread: from the 2023 5-year (and re-released 2022 5-year) all records are coded to 2020-vintage PUMAs, so using the 2022 crosswalk for everything at params$year >= 2022 is right. Good catch!

One small blocker though: the new chunk won't render. It builds county_list from puma_county_crosswalk (never read in this place file), stops assigning crosswalk_period to acs_clean so the join below fails, and uses filter(crosswalk_period = ...) with a single =. Might have been pasted from elsewhere? The 2014 file hits it too. What you want is just:

  if (params$year >= 2022) {
    acs_clean <- acs_clean %>% mutate(crosswalk_period = "2022")
  } else {
    acs_clean <- acs_clean %>% mutate(crosswalk_period = if_else(multyear < 2012, "2k", "2012"))
  }

[malcalakovalski]

All looks good! The quality check doc is super helpful