Iss414

[malcalakovalski]

Mobility metric pull request template

Please include the following points in your PR:

1. A link to the issue that this PR relates to. You can bring up a list of suggested issues and pull requests within the repository by typing Update racial diversity data for 2023, consider confidence intervals, and backfill years #414 .

2. A description of the content in this pull request.

• What was changed?
  • Added 2016 and 2023 data. Since the ACS codes for race/ethnicity population changed for these years, I added a function that uses year specific ACS codes instead.
  • Added crosswalk for 2016 and 2018 data in the places file
  • Added testing on final files
• What should the reviewer be focusing on?
  • Focus on whether the crosswalks in the place file seem correct
  • Recommendations on how to consolidate both files or reduce redundancies (there's a significant amount of code overlap in both files)
  • Check whether 2014 could be added (I couldn't find codes for non-hispanic other alone or non-hispanic two or more races, but a double check would be great)
  • There are some missing places in the places file, detailed below
• Is there a logical order to review the files in?
  • I recommend starting with the county level script which is simpler and then turning to the place level script

3. Detail on any issues or flags that the metric reviewer/data-team should be aware of.

The following 12 places are missing from the places level metric file:

    year state_name  place_name        
   <dbl> <chr>       <chr>             
 1  2016 California  Jurupa Valley city
 2  2016 Georgia     Macon-Bibb County 
 3  2018 California  Jurupa Valley city
 4  2018 Georgia     Macon-Bibb County 
 5  2018 Georgia     South Fulton city 
 6  2023 Connecticut Bridgeport city   
 7  2023 Connecticut Danbury city      
 8  2023 Connecticut Hartford city     
 9  2023 Connecticut New Haven city    
10  2023 Connecticut Norwalk city      
11  2023 Connecticut Stamford city     
12  2023 Connecticut Waterbury city    

[wcurrangroome]

This all looks great. I've only reviewed the county code so far, but I don't believe I had any comments about logic errors--purely style suggestions and opportunities to reorganize content, along with a couple minor things for reproducibility (making sure folders exist in a freshly-cloned repo).

Two high-level comments:

• I checked quickly--it'd be worth double-checking--but I believe the codes for the needed variables are consistent over time (including in 2014) for the detailed tables. I would consider using the appropriate detailed table, rather than the data profile table, to both make this more robust for future updates and to reduce the amount of variable code- variable name - data year crosswalking. I would also consider shifting to library(tidycensus) if you go this route, which IMO has a much cleaner interface for ACS data.
• I haven't significantly reviewed the city-level script, but I agree that this seems ripe for consolidation. I'd consider specifying a variable at the top of the file called geography, and using that to control any differential logic between county-level and place-level analyses. Then you could have a single script, with the great majority of the code encompassing workflows that apply to both geographic levels. This comes with some associated downsides (code's a bit more complex, and the combined script is longer than either of the two stand-alone scripts), but I'd argue it's well worth it. It's by no means perfect, but an example of that approach is here: https://github.com/UI-Research/mobility-from-poverty/blob/f0d79cf3ec3785c4602f94f02b35d6be44cadfaf/02_housing/ratio_housing_affordable_available.qmd.

[wcurrangroome]

This intro/overview is excellent.

[wcurrangroome]

Suggested change

	## 2021 ACS 5-Year Estimates
	## ACS 5-Year Estimates

[wcurrangroome]

Suggested change

	We pull all of the race/ethnicity counts for 2021 using `library(censusapi)`. **Note:** This will require a [Census API key](https://api.census.gov/data/key_signup.html). Add the key to `census_api_key-template.R` and then delete then delete "template". It is sourced above.
	We pull all of the race/ethnicity counts using `library(censusapi)`. **Note:** This will require a [Census API key](https://api.census.gov/data/key_signup.html). Add the key to `census_api_key-template.R` and then delete then delete "template". It is sourced above.

[wcurrangroome]

Can you wrap this in logic that checks if the data's already available locally, and only if not queries the API?

[wcurrangroome]

I might be missing something obvious, but the detailed table codes are consistent over time (including for 2014, I believe)--perhaps use those instead? Table B03002.

I'd also consider using library(tidycensus) if we're working with 5-year ACS estimates--it'll just afford a simpler/cleaner workflow than library(censusapi), though understand if it's not worth the hassle of switching.

[wcurrangroome]

Nice

[wcurrangroome]

across()

[wcurrangroome]

My de-rigeur comment about not naming over objects; prefer tracts2 = tracts1 %>% mutate(...)

[wcurrangroome]

What does this do? / can you negative-select columns more concisely, if that's the goal?

[wcurrangroome]

This makes sense in isolation, but I'm not sure why we suppress based on counts here but then don't suppress based on CVs in the subsequent section. Or, perhaps more consistently, why we don't uniformly suppress based on CV, which should address most/all of the observations with very small counts. (I know that's the guidance, but wonder if it makes sense to check about suppressing above a certain CV threshold?)