'Zoom level 3': Represent movement in the disaggregated desire lines in A/B Street scenario

[Robinlovelace]

I think this would involve:

• Converting the .geojson format to the schema shared
• Add departure times
• Other steps?

Data here as geojson: https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/desire_lines_disag.geojson

It has integer counts by mode for cycling, walking and driving. Just needs to be converted into the .json format as per #29 suspect it will be quicker for you to do that than me.

[Robinlovelace]

Heads-up @dabreegster this is for you - hope the data format is good. Tried to 'assign' you but I realised you weren't in the repo, just sent an invite. Cannot wait to see what the Go Dutch scenario looks like in A/B Street!

[Robinlovelace]

(Note: the numbers in there are not intended to be realistic, although they do show a shift to walking and cycling, they're just there for vis purposes for now.)

[dabreegster]

The format looks good! In A/B Street-speak, I'll convert this into two different scenarios, a "baseline" and "go Dutch." A single scenario is fixed, deterministic input about everything, including mode.

I'll create one person for each of the counts, having them take one trip in the morning from the development to the remote destination at a random time between 7-10am, then return 5-7pm, same mode both ways.

[Robinlovelace]

One person per trip sounds good. These approximate real commute patterns so setting off in the morning (e.g. with a normal distribution of arrival around 9am) could be good, but just getting them moving along those trajectories will be great to see!

[dabreegster]

Got something started, but few issues.

• Some of the desire lines go outside the study area. Should we snap to a border intersection in that case?

• The baseline and go dutch scenario are unrelated. This is maybe intentional. If we wanted to represent "person 40" in both scenarios as having the same origin/destination but a different mode choice, I need to think through how to structure that.

• Minor: A/B Street's importer pipeline does ad-hoc dependency management to download data and run different tasks in the right order. It's increasingly difficult to interpret logs, see what parts of the full import of all cities is taking the longest, etc.

• Minor: I need to investigate less verbose ways of interacting with the geojson crate

[Robinlovelace]

Great you've made a start @dabreegster, quickfire answers to your questions:

Some of the desire lines go outside the study area. Should we snap to a border intersection in that case?

I think @joeytalbot updated the case study area: https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/great-kneighton-study-area.geojson I do think there is great merit in showing flows that go to a border intersection though, opening the door to larger OD datasets (I think all of the flows are in that updated area though).

The baseline and go dutch scenario are unrelated. This is maybe intentional. If we wanted to represent "person 40" in both scenarios as having the same origin/destination but a different mode choice, I need to think through how to structure that.

Not intentional, just a result of this quickfire solution (in fact if you've any ideas on refactoring let me know, could do a quick screenshare/brainstorm later this evening): https://github.com/ITSLeeds/od/blob/master/R/aggregate.R#L73-L93. For now I'm happy for them to be disconnected, see that as a known bug in the input data, noted here: #32 (comment)

No comment on the other points, sounds like it's a good use case for testing the import code.

[Robinlovelace]

Heads-up @dabreegster the data at https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/desire_lines_disag.geojson is now updated and should now show the same number of people leaving buildings in both scenarios. Sorry for the slightly arbitrary column names btw, any advice on naming conventions/schemas welcome!

[dabreegster]

Thanks for the quick responses! I'm getting back to work now, should have the scenarios imported in abst by your morning.

[dabreegster]

@joeytalbot: https://github.com/cyipt/actdev/blob/main/data-small/study_area_trumpington-test.geojson and https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/great-kneighton-study-area.geojson are the same currently -- is this deliberate? Should we have a study area covering all of https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/desire_lines_disag.geojson at minimum?

In the meantime, I'll add snapping to borders.

[dabreegster]

The two scenarios are now imported on native (haven't deployed to web yet). After starting them, nothing will happen till 7am. The population layer (hotkey l then x) shows everyone start in the new site (snapped to residential buildings that're already in OSM there):

The workplaces are spread out, with 76 somewhere off-map:

The distribution of people to individual buildings seems pretty unrealistic, with ~20 people assigned to https://www.openstreetmap.org/way/531067370. That could be an artifact of how the disaggregation works (looking at the R code now) or this area not having the proposed new buildings in OSM.

The baseline scenario has 212 cancelled trips that failed to simulate, most due to routing issues caused by how the area is imported. I'll look into resolving some of those next.

[joeytalbot]

@joeytalbot: https://github.com/cyipt/actdev/blob/main/data-small/study_area_trumpington-test.geojson and https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/great-kneighton-study-area.geojson are the same currently -- is this deliberate? Should we have a study area covering all of https://github.com/cyipt/actdev/blob/main/data-small/great-kneighton/desire_lines_disag.geojson at minimum?

In the meantime, I'll add snapping to borders.

Well noticed @dabreegster. I renamed the test file so we can have standardised names for each study area. I might as well delete the test file now.

Only desire lines that lay within the study area were selected, but that was before the desire lines were disaggregated, so yes it would be a good idea to expand the study area now to encompass the full disaggregated set of of desire lines. But the other thing is that there are also large numbers of desire lines to more distant destinations outside the study area. If these could eventually be shown, snapping to borders of the study area, it would improve the visualisation by giving a complete picture of the movements that take place - of course, a high proportion of the journeys to more distant destinations will be by car.

[joeytalbot]

@Robinlovelace how are the disaggregated destinations chosen? Currently in Cambridge we have lots of journeys to a small audi dealership next to a park and ride site, but none to the large Biomedical Campus which is a major employment hub.

[joeytalbot]

[mvl22]

For the Cambridge study site, major employment sites in the area are:

• Biomedical Campus (hospital, with Uni/commercial research) [as shown above]: https://www.openstreetmap.org/#map=16/52.1768/0.1389
• University of Cambridge:
  • All around the city centre: https://www.openstreetmap.org/#map=16/52.2037/0.1261
  • West Cambridge site: https://www.openstreetmap.org/#map=16/52.2113/0.0915
• Science Park: https://www.openstreetmap.org/#map=15/52.2337/0.1528
• Airport site: https://www.openstreetmap.org/#map=16/52.2110/0.1790
• Shopping centres:
  • City Centre: https://www.openstreetmap.org/#map=16/52.2037/0.1261
  • Grafton Centre: https://www.openstreetmap.org/#map=18/52.20640/0.13254
• Big Pharma in South Cambridgeshire: https://www.openstreetmap.org/#map=13/52.1034/0.1759

[Robinlovelace]

Hi guys, yes the destinations are very much a first pass based on Rust code shared by @dabreegster and implemented in this script (note it's in the tests folder to denote that it's still in testing mode): https://github.com/cyipt/actdev/blob/main/code/tests/disaggregate.R

Can you reproduce the results @joeytalbot ? Suggested changes to that welcome, perhaps based on updated OSM tags.

[Robinlovelace]

The data has been generated not for realism but to demonstrate the ability to go from OD data generated in R into AB Street. For improvements to the data (not the structure, which is on topic here) I suggest creating a new issue. Also see #34 which is essential a report of a bug in the data (but not the structure of the data). Important to keep issues modular, specific and actionable.

[dabreegster]

We're done with this now / we switched to generating the scenarios from R instead. The notes about picking destinations more realistically remain relevant, but we can find them in this issue later if needed.

[Robinlovelace]

👍