Compare absolute and relative crash change - Githubissues

bicyclingplus / atp-bc-tool-analysis

Analyzing inputs/outputs from the CTC Active Transportation Benefits/Costs tool, to identify and investigate potential issues (analysis notebooks only - input/output data is not included)

0 stars 0 forks source link

Compare absolute and relative crash change #3

Open mRaffill opened 1 year ago

mRaffill commented 1 year ago

Currently, relative "before crashes per 1000 volume" and "after crashes per 1000 volume" are calculated, but the crash change still uses absolute (not per volume) crashes. We are considering displaying relative crash change in the tool instead to capture the change in "risk" (I think?). So to test this:

[x] calculate a new version of crash change based on the relative before/after crashes
[x] verify if this makes most of the projects have a negative (decrease) crash change/graph the new crash change against existing crash change

mRaffill commented 1 year ago

(I already made this change, just making the issue to keep track of the status)

This change was completed in 9a229c88ef9bfc5a3a0922810518580a3a2b9f9b

The relative crash change does make most of the results negative, except for a few projects (which I should look into later)!

mRaffill commented 1 year ago

Next steps

[ ] Check which projects are positive and try to figure out why - is it expected behavior?

mRaffill commented 1 year ago

Just realized I actually subtracted in the wrong order! It should be after crashes - before crashes, not before crashes - after crashes!! So actually a majority of the projects have a positive change (increase) in crashes, even with relative change.

This may just be because of the inconsistency between the model-based NC and user-inputted EC (since I believe a majority of projects do have user-inputted crashes)

mRaffill commented 1 year ago

Retry this with the results of the new crash equations:

For only model crashes, is it still all positive
For only user crashes (using the new equation) is it still all positive

mRaffill commented 12 months ago

So new To-Do list:

[x] Calculate the total crash change with the new equation (for both model and user-input)
[x] Calculate the relative crash change with the new equation (for both model and user-input)
[x] Check if they are then mostly negative

mRaffill commented 12 months ago

Look into increases in volume vs decrease in crashes
- make a new column separately calculating the VIF "volume increase factor" for each project, and compare this to the CRF.
- Multiply VIF and CRF and see when it causes an increase in crashes and when it causes a decrease in crashes Basically, see if all of these increases in crashes (even with the new NC equations, see the graphs in that file) are caused by an increase in volume? (it may be just be enough to look at the relative crash rates)

mRaffill commented 11 months ago

Just realized I actually subtracted in the wrong order! It should be after crashes - before crashes, not before crashes - after crashes!! So actually a majority of the projects have a positive change (increase) in crashes, even with relative change.

With the correct order, the graph of the current relative crash change actually looks like this (just a reflection of the previous graph - everything is actually positive!):

mRaffill commented 11 months ago

After using the crash equations where new crashes are calculated directly from existing crashes, in 138e0f5ad5b197631800785a59f9b687c471dec5, the relative crash change is (almost) all negative as expected!

model only relative crashes	user-input only relative crashes

mRaffill commented 11 months ago

(I am pretty sure the few positive instances are projects with a CRF >= 1, based on these graphs showing that before and after crashes are basically equal in these cases, but I should definitely look into this in more detail)

For projects with crash change > 0: