District-to-district transit flows

[yueshuaing]

This issue is open to discuss/explain the issue noticed in BayAreaMetro/tm2py#174 comments:

item3: acceptance-other.twb/6 - Transit District: The acceptance-transit summaries show that we are low on transit. So why are the simulated outcomes so much higher than observed on this sheet? Please check the calculations.

This is because the simulated flow in this tab is calculated as OD demand × number of boardings × share of in-vehicle time. The results can be much higher than OD demand, because for some OD pairs, the number of boardings are greater than once.

tm2py-utils/tm2py_utils/summary/acceptance/simulated.py

Lines 1497 to 1509 in 3871f75

	# Calculate technology-specific flows using formula:
	# tech_flow = total_flow * boards * tech_ivt / total_ivt
	# This allocates trips to technologies based on their share of in-vehicle time
	for tech in self.canonical.transit_technology_abbreviation_dict.keys():
	column_name = f"simulated_{tech.lower()}_flow"
	summary_pldf = summary_pldf.with_columns(
	(
	pl.col("simulated_flow")
	* pl.col("boards")
	* pl.col("{}".format(tech.lower()))
	/ pl.col("ivt")
	).alias(column_name)
	)

[DavidOry]

Thanks @yueshuaing. So do we just need to remove the boardings from the above equation?

[yueshuaing]

Thanks @yueshuaing. So do we just need to remove the boardings from the above equation?

Yeah..it looks like including boardings in the formula isn’t correct. And the way it joins demand with skim data also seems off.

Here’s how the transit flow is currently computed:

• OD demand is joined to the five category path skims, so each OD pair appears five times. For example, in the screenshot between zone 4734 and 625, the AM demand is 2, number of boardings is 2, each skim row holds the technology-specific IVTs (loc, exp, ltr, etc.)
• The technology-specific flow is then calculated as OD demand × boardings × (tech IVT / total IVT), for example, the loc flow of WLK_TRN_WLK is 2*2*19.4/35 = 2.2
• In the Tableau workbook, total transit flow is the sum of the technology-specific flows. In the screenshot below, the sum becomes 2*2*5=20, but the actual OD demand is 2.

[lmz]

Hi @yueshuaing -
I think there are a lot of problems with the Acceptance Criteria transit code. I posted this in Asana but I realize you don't nec have access.

I think the problems are bigger than just this formula:

As I've gone through this process in more detail, I'm finding a lot of inconsistencies and undocumented nuances that are confusing and also, will cause buggy results.

However, I don't think it's worth resolving them for the 2015 Acceptance Criteria, because we need to work on moving forward to 2023 Acceptance Criteria, so we will pause on moving this forward and focus on [Do a "2023" Run](https://app.asana.com/1/11860278793487/project/1199982433633229/task/1210908558160451), and then come back to this.

When we do come back to this, we'll want to do understand the following and update:

• Where's the documentation for the crosswalks? (e.g. transit-standard-2015-to-survey-crosswalk-v2.csv or other files in crosswalks)
  • How are these generated?
  • What keys are unique?
  • What summaries will be route-by-direction versus just route? For rail, it looks like summaries are just by operator. But for buses, it looks inconsistent to me (by operator): sometimes route direction is included and other times not
• In the acceptance criteria code, all pandas merge() calls should include the validate keyword, so that we're checking that we're not accidentally assuming one-to-one merges but really doing many-to-many merges which could accidentally create additional survey or simulated boardings that don't exist. It's also useful to include the indicator keyword to verify failed joins are as expected.