Intrazonal Logsums for Bike Model

[americalexander]

The Java bike model implementation has several implementation details that are not really used, leading to source code that isn't straightforward to interpret. However, we've come to the conclusion that the procedure for calculating the intrazonal logsums can be fundamentally reduced to this: take the maximum logsum to any other destination zone and, if it's a nonnegative number, double it; otherwise, halve it. Additionally, the intrazonal distance is calculated as half the distance of the lowest-distance destination (i.e., the nearest neighbor). The Java source code and model documentation provide no justification for or reasoning behind this approach.

@jfdman has pointed out that this logsum approach has weaknesses because of nonlinearity (I'll leave it for him to elaborate on this). A proposed alternative approach is to instead calculate the logsum for intrazonals as follows: take the intrazonal distance (calculated as described above) and apply only one distance term of the utility expression. However, this faces the drawback of requiring assumptions about the roadway facility attributes (bike class, cycle track, bike boulevard, and arterial) to select the appropriate coefficient from a set of eight options. The below table shows the options and their coefficients at present:

Description	Coefficient
Distance without bike lanes	-0.858
Distance on class I bike lanes	-0.348
Distance on class II bike lanes	-0.544
Distance on class III bike lanes	-0.858
Distance on arterial without bike lanes	-1.05
Distance on cycle track class II bike lanes	-0.424
Distance on boulevard class III bike routes	-0.343
Distance wrong way -- no lanes in direction of travel and no bike lane means wrong way	-3.445

One possibility for the rationale behind the Java approach is to guarantee that the intrazonal logsum is greater than or equal to all other destinations' logsums. For us to maintain this guarantee with the alternative approach, we would likely need to select the bike boulevard class III bike route coefficient (-0.343, the least negative value) from the table above - however, this may be quite a dubious assumption to use across all zones as, depending on location, bike boulevards may be rare or nonexistent. It's not immediately clear to me if there is an alternative approach we could take to maintain this guarantee.

[dhensle]

re: non-linearity -- if the person goes half as far and we assume the total utility drops by half, that is not the same as the logsum dropping by half. i.e. ln(10) / 2 != ln(10 / 2) (1.15 != 1.61). Therefore just halving the logsum to the nearest zone is not a valid approach for approximating the intrazonal logsum from a mathematical perspective. However, it is simple and does enforce that the intrazonal logsum is better than any other logsum for that zone.

Calculating the logsum based on distance is a little more valid. I think we would just apply the distance coefficient without bike lanes. If we want to enforce that the logsum is never better than the nearest zone, we could just enforce that in a simple post-process step.

[americalexander]

What's your rationale for selecting that coefficient?

[dhensle]

Simple assumption that someone is going to be spending minimal time on bike lanes when they are only traveling a small distance inside their MAZ. Also assuming that they will be avoiding any arterial that may be traversing through the zone.

[dhensle]

Intrazonal calculations implemented as described above in this commit.

[americalexander]

Due to a miscommunication, the above commit actually used the old Java-style intrazonal calculation, which is not the desired behavior

[americalexander]

Intrazonal calculation modified and reimplemented as described above in commit 90247a2