Origin, destination, OD-level summaries

[robinlovelace-ate]

Currently when od2net calculates the routes, all info except for segment level info is thrown away.

It is often useful to have summary information summarised at different levels, key levels being:

• Origin-level summaries: e.g. how many trips are calculated as being made by bike under the GovTargetPCT scenario per origin zone?
• Destination-level summaries, e.g. how many bike trips are there arriving at each destination under the GovTargetPCT scenario?
• OD level summary statistics, these could be summaries of all routes from all subpoints within each zone to each destnation

A simple example of this kind of summary statistic can be found in the PCT which provides an estimate of the number of people who would cycle to each school based on the distances and hilliness of routes from each zone to each school, as shown below:

Source: https://www.pct.bike/m/?r=north-yorkshire

[robinlovelace-ate]

A solution that comes to mind: supply an od.csv file alongside output.geosjon in the output folder, containing the same number of rows as the input OD dataset (if there is one), with columns including count and length on each type of segment (e.g. by LTS and highway type). Then users can simply aggregate per origin or destination at their leisure. Similar to #35 but this is about providing OD level data rather that origins and destinations at the link level.

[dabreegster]

All of this sounds good, just a few clarifying questions:

It sounds like counts broken down by specific subpoints is not needed, just at the zone-based OD level (except in the case of named points as origins/destinations) -- right?

The GovTargetPCT and other uptake functions return a number between 0 and 1. By count, you just mean the sum of these probabilities, right?

on each type of segment (e.g. by LTS and highway type)

Breaking down by LTS makes sense, but breaking down by OSM highway type feels a bit harder to understand. A highway primary with a well-segregated, wide cycleway that's tagged directly on the primary road wouldn't be distinguishable. I could supply both, but I think if the definition of LTS used is robust, then that output will be more useful.

[Robinlovelace]

It sounds like counts broken down by specific subpoints is not needed, just at the zone-based OD level (except in the case of named points as origins/destinations) -- right?

Correct.

[Robinlovelace]

The GovTargetPCT and other uptake functions return a number between 0 and 1. By count, you just mean the sum of these probabilities, right?

The sum of these probabilities multiplied by the count supplied in the od data. For example, imagine an OD pair with 10 pupils traveling form Zone A to School 1. The average value returned by GovTargetPCT for 3 subpoints happens to be 0.3 (0.2, 0.3, 0.4). In this case the value would be sum(10/3 * (1:3)/10):

sum(10/3 * (2:4)/10)
#> [1] 3

^{Created on 2024-10-22 with reprex v2.1.0}

[Robinlovelace]

Breaking down by LTS makes sense, but breaking down by OSM highway type feels a bit harder to understand. A highway primary with a well-segregated, wide cycleway that's tagged directly on the primary road wouldn't be distinguishable. I could supply both

I agree LTS would make more sense. But what about cases where the user is not using LTS or has a different use case?

Key thing here is configurability and being able to set which summary stats are returned per OD pair, there might be someone who wants to count the number or length of x OSM tags for their particular use case that we cannot foresee is my thinking, if that makes sense?

[Robinlovelace]

LTS would be be ace as a starter for 10 though so 👍 to that.

[dabreegster]

If you sync past this latest commit, you should now get output/od.csv when your config uses BetweenZones or ZoneToPoint. The example output for the York example:

origin,destination,count,not_allowed_distance,lts1_distance,lts2_distance,lts3_distance,lts4_distance
south,poppleton,499,0,0,1114494.8095443342,0,4396925.514903933
north,poppleton,199,0,0,2788044.8982491572,0,2055971.232630357
south,corndogs,800,0,0,4883372.3414757475,0,788611.2984383369
north,corndogs,600,0,0,3339806.483995541,0,528530.4786694986
center,corndogs,300,0,0,285088.827342031,0,142092.28488102253
center,poppleton,100,0,0,879663.8545549216,0,981706.8467566475

Distance is in meters. Let me know if this is enough to unblock you, thanks!

[Robinlovelace]

Fantastic, thanks Dustin, and perfect timing for my planned ATE work tomorrow.

[Robinlovelace]

Quickfire follow-up Dustin, what about this summary e.g. for Go Dutch:

how many trips are calculated as being made by bike under the GovTargetPCT scenario per origin zone?

Should there be a count_scenario when there are scenarios.

[Robinlovelace]

Unless those values in the count column above are the scenario counts (I haven't checked).

[dabreegster]

Ah sorry, the column name may be unclear. count is the summed values from the uptake function configured. The example table I pasted is made from examples/york/config.json, which sets "uptake": "Identity", so that is just a simple count of trips. If you configure go dutch, then count will represent that summed uptake.

[Robinlovelace]

Perfect, thanks for clarification. Job done on this issue I think so closing. Can test and provide any further comments here or in another issue if anything else pops up. Impressive.