Disaggregation code leaves us with very few desire lines

[joeytalbot]

The new disaggregation code in scenarios-streamlined.R is not doing what it should.

Here are fast cycle routes for Allerton Bywater with disaggregate_desire_lines set to FALSE. This does not use the new code. I am showing the object that would be saved as routes-fast.geojson

[joeytalbot]

Here is the same with disaggregate_desire_lines set to TRUE. This is the default now but is clearly not what we want.

[Robinlovelace]

The purpose of the disagregation code is to increase not decrease the number of desire lines. Looking at the commits I don't think this data has been pushed but in any case it suggests something is wrong in Allerton Bywater. Clearly it works in some sites, notably Poundbury as documented in #108. Are you up for doing a bit of detective work to help identify the cause of the issue Joey? Good next step on that could be to try to re-generate the seemingly working results for Poundbury.

[Robinlovelace]

Are you sure this is an issue? These are the desire lines generated by the 'disag code' that I see:

Source: https://github.com/cyipt/actdev/blob/main/data-small/allerton-bywater/desire-lines-many.geojson

Closing for now. Not sure what has happened but guess you may need to install the latest version of the od package for the code to work. Please double check, try to reproduce the issue and let me know if you can @joeytalbot.

And these are the resulting routes:

[joeytalbot]

I have already installed the latest version of od() using remotes::install_github("itsleeds/od")

I am simply running the following code - taken directly from build.R, and it gives the result for Allerton Bywater that I showed you earlier.

library(sf)
library(stplanr)
max_length = 20000 # maximum length of desire lines in m
household_size = 2.3 # mean UK household size at 2011 census
min_flow_routes = 10 # threshold above which OD pairs are included
region_buffer_dist = 2000
large_area_buffer = 500
sites = sf::read_sf("data-small/all-sites.geojson")
source("code/build-setup.R") # national data

set.seed(2021) # reproducibility
site_names_to_build = "allerton-bywater"

data_dir = "data-small" # for test sites
disaggregate_desire_lines = TRUE
for(site_name in site_names_to_build) {
  message("Building for ", site_name)
  suppressMessages({
    suppressWarnings({
      source("code/scenarios-streamlined.R")
    })
  })
}

[joeytalbot]

routes_test = read_sf("data-small/allerton-bywater/routes-fast.geojson")
mapview(routes_test)

[joeytalbot]

Even in the maps you showed there is something strange going on. For example, the desire lines to Kippax have disappeared.

I don't think we need to do this disaggregation at all.

[Robinlovelace]

One to chat about? Give me a call if you're around this morning, heading out ~10:00.

[joeytalbot]

https://actdev.cyipt.bike/poundbury/routenetwork/#11.47/50.7691/-2.3985

The routes shown for Poundbury are also very misleading. This is not an improvement for Poundbury.

[joeytalbot]

Poundbury without disaggregation:

[joeytalbot]

Poundbury with disaggregation:

[Robinlovelace]

Good catch @joeytalbot. The issue was that synthetic buildings didn't have unique ids so it was routing many origins to a single random destination. Fixed in the commit above I think, results looking better for Poundbury:

[Robinlovelace]

Rebuilding and checking for lcid.

[Robinlovelace]

Looking good:

Next up Allerton Bywater.

[Robinlovelace]

Where the bug is very clear from the web app: https://actdev.cyipt.bike/allerton-bywater/routenetwork/#11.02/53.7598/-1.3789

[Robinlovelace]

A co-benefit of disagregation I've just realised: the greater diversity of destinations means fewer blanks in the clockboard data. Heads-up @joeytalbot on that one. Making good progress, very grateful for your beady eyes on this.

[Robinlovelace]

After the fix we have a much better and more realistic distribution of destinations:

[Robinlovelace]