You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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().
@lmz : I got around this by just adding a variant row to the data inventory, so we don't need to parse the (increasingly) verbose alias name to determine whether it is a DBP or NP run.
I don't think this has any adverse consequences to other uses.
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 ofNo 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).bayarea_urbansim/scripts/metrics/metrics_connected.py
Line 85 in 76dd7f7
for the affordable set of indicators, a number of literal tests are done to check for
No Project
status - having strings likeNo Project v1
could potentially lead to unintended consequences, with the absence of aNo Project
match runs being invariably classified as DBP, which could affect metrics. Many of these are found in theat_risk_housing_preserve_share()
orhousing_cost_share_of_income()
.bayarea_urbansim/scripts/metrics/metrics_affordable.py
Line 178 in 76dd7f7
bayarea_urbansim/scripts/metrics/metrics_affordable.py
Line 401 in 76dd7f7
bayarea_urbansim/scripts/metrics/metrics_affordable.py
Line 460 in 76dd7f7
bayarea_urbansim/scripts/metrics/metrics_affordable.py
Line 565 in 76dd7f7
In the
lowinc_homeownership_share()
function, a separate function is used to parseDBP
orNP
, to get the appropriate homeownership measure.bayarea_urbansim/scripts/metrics/metrics_diverse.py
Line 403 in 76dd7f7
The text was updated successfully, but these errors were encountered: