Levels of walking and cycling decrease in Tresham

[Robinlovelace]

This isn't good, reported by Amy from HE:

Suggested solution:

• Take the scenario offline as it's worse than useless at the moment
• Diagnose the cause and implement a fix in the codebase

[natesheehan]

I believe it's this section of code in the scenarios_streamlined.r file that is causing the issue.

routes_walk_save = routes_walk %>% 
 dplyr::filter(distance <= 10000 & trimode_base > 0) %>%
 mutate(
 # pwalk_base = walk_base / trimode_base,
 pwalk_godutch = case_when(	
 distance <= 2000 ~ pwalk_base + 0.3, # 30% shift walking for routes >2km
 distance <= 2500 ~ pwalk_base + 0.2, # 20% shift walking for routes >2.5km
 distance <= 3000 ~ pwalk_base + 0.1, # 10% shift walking for routes >3km
 distance <= 6000 ~ pwalk_base + 0.05, # 5% shift walking for routes 3-6km	
 TRUE ~ pwalk_base),
 walk_godutch = pwalk_godutch * trimode_base
 )

The Tresham site has a pretty low active travel uptake, with only one walking route coming through stplanr and the distance of the route is 9897.3. So the goactive scenario is not being calculated.

@Robinlovelace whats your thoughts on a fix? Should I add something like to catch this edge case?

routes_walk_save = routes_walk %>% 
 dplyr::filter(distance <= 10000 & trimode_base > 0) %>%
 mutate(
 # pwalk_base = walk_base / trimode_base,
 pwalk_godutch = case_when(	
 distance <= 2000 ~ pwalk_base + 0.3, # 30% shift walking for routes >2km
 distance <= 2500 ~ pwalk_base + 0.2, # 20% shift walking for routes >2.5km
 distance <= 3000 ~ pwalk_base + 0.1, # 10% shift walking for routes >3km
 distance <= 6000 ~ pwalk_base + 0.05, # 5% shift walking for routes 3-6km	
 distance <= 10000 ~ pwalk_base + 0.025, # 2.5% shift walking for routes 6-10km
 TRUE ~ pwalk_base),
 walk_godutch = pwalk_godutch * trimode_base
 )

[Robinlovelace]

Many thanks for this @natesheehan and good to see it's offline for now. I think your suggestion of adding an increase for 6-10 km routes is good but wondering how realistic that is. Ideally the Go Active scenario should completely disallow walking and cycling levels to drop, with a worse case scenario being cycling_go_active = cycling_baseline and same for walking.

[natesheehan]

Agreed - a 6-10km walking commute feels a tad unrealiestic, can we use census data to understand the max distance people walk for work?

[Robinlovelace]

Agreed - a 6-10km walking commute feels a tad unrealiestic, can we use census data to understand the max distance people walk for work?

Better option: use the NTS, Census is unreliable for this kind of thing I think.

[natesheehan]

Sounds good , I'll dive into the nts data this eve and see what solutions can be implemented

[natesheehan]

@Robinlovelace OK, so the NTS data documents that the average trip length (all modes) is 6.8 miles (10.9435 km) (1)

With regards to mode-specific, the data is coming back weighted (2)- is there a way for us to translate this back to kms/miles?

[Robinlovelace]

I think there are tables that give the n. trips by different distance bands here: https://www.gov.uk/government/statistical-data-sets/nts03-modal-comparisons

Furthermore analysing raw NTS data is an option but that requires an academic license and time...

[natesheehan]

Ah, thanks! Looks like the data validates our assumptions, the number of trips falls to zero when > 5 miles (~8km), and even still, the number of trips between 2-5 miles is only 4% of total trips.

Maybe we could edit the routes_walk_save to cater up to 8km, and then if greater than 8km walking_go_active = walking_baseline ?

[Robinlovelace]

Needs some more thought. Priority for ActDev I think is #176, you up for taking a look at that and seeing if we can rebuild the scenario.json files with the new and I think improved version of abstr?

[natesheehan]

Should we close this issue @Robinlovelace and create a separate issue for the go_active uptake edge case?

[Robinlovelace]

Happy to keep it open as it's still an issue and we can track the solution to the general problem with respect to this specific case.