Improve speed of matrix approach to distance

[dkyleward]

I implemented two ways of calculating distance in the delay-allocation method. The first iterates over every link in the buffer (low fixed cost, high variable cost). The second uses matrix indices (high fixed cost, low variable cost).

Stats after some time studies in Virginia Beach:

The matrix approach to distance calculation takes ~4.3 seconds, with little change depending on the number of links in the buffer area. This may, however, depend on the size of the initial matrix. I'm not sure how TransCAD indexes a matrix when a currency is specified.

The link method, on average, took .0015s per link. This implies that the upfront investment in the matrix approach is faster above 2,879 buffer links. In Virginia, there was a mix of projects that were under and over this threshold - particularly due to the large bodies of water where no roadway network existed.

Initially, I thought about having a toggle that decided which approach to use; however, I decided to go with the matrix approach (even when it was slower) for a number of reasons.

• One process means that maintaining/changing the code is much simpler
• Longer projects (with bigger buffers) tended to have more project links. This meant more time spent dealing with a large number of links than the initial scan of projects suggested.
• Predictability of runtime in other models

[dkyleward]

Could drastically improve the speed of the matrix approach using the "Read Matrix" macro in the Tables GISDK library. Do the following steps before looping over each project (and project link)

• Convert the skim matrix into a table object
• Process the average distance information (accounting for direction)

Once complete, the loop would simply select from this table and join as needed, which is much faster than indexing the full matrix each time.