Vehicle times

[mpadge]

Vehicle times

[mpadge]

Time Penalties for Congestion

Improving vehicle speed estimates using street network centrality (2016) with pdf here. They simply estimate centrality, and then use a linear regression against estimates of vehicular speeds, but don't publish any of the coefficients. They nevertheless show one interesting, and potentially relevant, result in Fig 7, relating speed estimates to both network closeness and betweenness centality. On secondary or tertiary roads, speeds decrease with increases in both centrality and closeness, but on residential or lower category roads, speed increases with increasing centrality. This could nevertheless reflect some kind of rural effect towards the network periphery, and need not suggest any general pattern.

The results of that figure alone might be sufficient to inform a general heuristic, although that would also need to be scaled by overall city size. That shows speeds along 50km/hr segments decreasing to underr 20km/hr along the most central edges, although closeness appears to have an even greater influence than centrality alone (where closeness is measured as the inverse of the sum of distances to all other nodes, and edge closeness is just averaged from measures at each pair of terminal nodes).

[mpadge]

One likely viable approach: Get data from https://movement.uber.com/ and use that to calibrate scales between centrality and their estimates. That should give a rough idea of the most appropriate scaling of centrality values. Then use that to extract best linear coefficient for as many cities as possible, and relate that linear coefficient to city sizes to provide a final heuristic way to estimate general travel times from centrality.

[FlxPo]

I did not test this, but here is one idea I had to get better time estimates when using dodgr, coupled with a mobility model of a given region : "load" the network edges iteratively with dodgr_flows_aggregate, and adjust the speeds on the edges according to some capacity - speed function.

This approach is used in "Predicting commuter flows in spatial networks using a radiation model based on temporal ranges" (https://www.nature.com/articles/ncomms6347), with a rather simple function : speed is set to zero when the flow is above some capacity threshold.

[mpadge]

Thanks for the link @FlxPo. Interestingly, their best estimate of travel times gives a correlation coefficient of 0.639, or 0.752 with the switch-off capacity limitation you describe. I set up a separate repo to perform calibration experiments against the Uber movement data. Straight-up m4ra::m4ra_times_single_mode() values give a correlation with observed (uber movement) values of 0.720, which is pretty similar. Any modification to account for network centality only reduces that correlation.

This leads to the conclusion that perhaps the only empirically-justifiable modification which can be implemented is an overall modification of the scale of m4ra travel time estimates to scales represented in empirical data. However, empirical travel times are generally much faster than the m4ra estimates, by a factor of 2-3 times. That's likely because m4ra times rely on the weighting profiles taken from routino, which have maximum speeds well below likely actual speeds, such as 25km/hr on residential, 40 on tertiary, 55 on secondary, and 65 on primary. Actual maximum speeds are obviously well above that.

Need to modify the algorithm to account for the actual maximum speeds given in OSM data, and use those to override the values in the weighting profile. That may in turn affect relationships with observed values such that effects of centrality are different / observable ...?

[mpadge]

Ah, the sample data i've been working with for Brussels, Belgium are the centre of the city only, and just exclude the enormous motorway ring around the city centre. So the m4ra times can't reflect routing along the motorways. I'll repeat the calibration in another city...

[mpadge]

Calibration procedure for vehicular travel times documented in separate repository https://github.com/UrbanAnalyst/ttcalib

[mpadge]

The procedure for this is now stable and sufficiently documented in the ttcalib repo linked above. That ultimately indicates that centrality makes very little difference at all, so is not even worth considering, but that traffic lights are the singularly most important factor. Instead of the routine defaults of traffic lights = 8 seconds and turn penalty = 7.5 seconds, that calibration exercise suggests an optimal traffic light penalty of 16 seconds, and a turn penalty of only 1 second.

The most important thing here for inter-city comparisons is to have standardised values. These particular value can easily be refined through re-application to other areas at any later stage, but are sufficiently empirically justifiable to proceed for now on that basis.