Coalescing undermines the integrity of the network

[kuanb]

In posts such as this one (http://kuanbutts.com/2018/04/01/spectral-cluster-transit/) and elsewhere, I have suggested that coalescing networks can improve speed.

This is true, but accuracy is sacrificed on graphs like a transit network.

In cases, such as a walk network, such a naive coalesce operation might be acceptable.

In the case of a transit network, we might effectively prune out critical edges such as those for providing transfers between routes (e.g. creating "free," immediate transfers from one line to another), thus artificially increasing accessibility.

This needs to be called out at least in a comment in the method. Better would be a way of improving the method to account for the transfer costs and keep different routes segmented.

[kuanb]

Thanks for noting this, @yiyange

[yiyange]

Profiled this operation's impacts on one accessibility measure (number of jobs each parcel get reach within a cost bound):

• x-axis: Parcel IDs sorted by access to jobs. Parcels on the left have less accessibility to jobs (given the full walk network)
• y-axis: number of jobs accessible given a cost bound
• bottom "line" in grey is the accessibility measure on full network.
  
  Note: this is using mean of grouped edge weights (see PR [coalesce] Use mean of grouped edge weights rather than minimum #127)

[yiyange]

Also tested on using MAX rather than AVG of grouped edge lengths -- using max generally brings down accessibility measure as expected

Seemingly it does not create a lot overly low accessibility measures but that needs further testing because that is a function of cost bound. For example, using max weight length has less impacts when we look at access to jobs within 60 mins than access to jobs within 20 mins.