D12 would prefer "Santa Ana" to "Irvine"

[edasmalchi]

I met with OCTA and D12 about speedmaps and HQTA back on Dec 5, and Louisa at D12 mentioned that "D12 - Irvine" should be "D12 - Santa Ana".

District 12 is located at:

1750 E. 4th Street
Santa Ana CA 92705

I think we should align with what they prefer.

dim_county_geography actually has "Orange County" as the district name, it seems like changing that to "Santa Ana" would be the broadest fix. edit: I see that they use "Orange County" in some of their branding too, so I could also reach out and see if that would be acceptable.

Meanwhile, this dict is where "Irvine" is coming from, a smaller fix would be to rename it there and the change should at least be reflected in our analysis portfolio...

@tiffanychu90 @evansiroky thoughts?

data-analyses/_shared_utils/shared_utils/schedule_rt_utils.py

Lines 16 to 23 in de9b753

	RENAME_DISTRICT_DICT = {
	"Marysville / Sacramento": "Marysville", # D3
	"Bay Area / Oakland": "Oakland", # D4
	"San Luis Obispo / Santa Barbara": "San Luis Obispo", # D5
	"Fresno / Bakersfield": "Fresno", # D6
	"San Bernardino / Riverside": "San Bernardino", # D8
	"Orange County": "Irvine", # D12
	}

[evansiroky]

Naming things is hard! I'm going off of this page: https://dot.ca.gov/caltrans-near-me.

I also went ahead and renamed what we had in Airtable for D7 from "Los Angeles" to "Los Angeles / Ventura".

[edasmalchi]

Makes sense. I wonder if we're renaming things in shared_utils to avoid slashes... But it seems like we can get off of "Irvine" one way or another

[tiffanychu90]

Oh, the renaming to Irvine is simply because the other months populated it with Irvine before. I needed to see if switching to the new mart_transitdatabase table going to be ok. I checked the month I made the switch against previous months to make sure operators were categorically moving from one district to another, and the value being Irvine vs Santa Ana made it harder to me to check.

I'm not opposed to anything changing names. I think updating shared_utils data dictionary to include all the old values and map them to new values is the cleanest and easiest thing. It's the easiest to tack onto as a step within schedule_rt_utils for analysts to benefit from and decrease the amount of updates needed.

I mainly kept the names the same because these are things that need to be worked through. Updating the names without handling these could break many analysts'stuff!

• all portfolio/sites/*yml - all the table of contents reflect old names. definitely rerunning TOC at point of portfolio deployment.
• any products using multiple dates - GTFS digest, open data
  • open data fills in missing operators for [current_month] with [last_observed_month], and this step is where differing values for D12 / D7, etc affects. checking that in the published data, the same name for D12 is published, regardless of which date was used to plug in gaps.
  • GTFS digest has time-series data, so any difference in table of content values could have downstream impacts. If D12 is selected for a notebook and multiple D12 names are shown, that would need to be handled.
• upstream steps where caltrans_district appears should be either rerun or dictionary used in shared_utils to map any old values to what we want to display (using a dictionary to map old values to new values seems easier to handle).
  • This is the only script I use.

[edasmalchi]

Thanks Tiffany! Yep it was definitely Irvine in the old tables. I'm running January open data today and with the transit priority work don't have time to go down the list, but I'll plan to do so for February.