Metrics and run inventory: domain and expectation of `alias` column relative to script usage
Opened this issue · 1 comments
This is a question related to the data stored in the lightweight PBA50Plus_model_run_inventory.csv.
The file has an alias column containing information on the type of run, with the canonical forms being EIR, DBP, NP or more verbose forms.
On the script side, the field is used in a number of different ways depending on the specific indicator. The question is first, whether the presence of polluted literals (e.g. No Project v9 instead of No Project) is an issue, and second, if the adjustment is just to use a separate column in the run inventory to carry the additional information.
for the connected indicators in the transit_service_area_share() function, the flavor of the run type is used to match with the relevant transit service area classification (areas are different for plan and no project scenarios).
for the affordable set of indicators, a number of literal tests are done to check for No Project status - having strings like No Project v1 could potentially lead to unintended consequences, with the absence of a No Project match runs being invariably classified as DBP, which could affect metrics. Many of these are found in the at_risk_housing_preserve_share() or housing_cost_share_of_income().
In the lowinc_homeownership_share() function, a separate function is used to parse DBP or NP, to get the appropriate homeownership measure.