Override OSM transfers with GTFS transfers.txt for same stop-pattern pair

[abyrd]

There turn out to be quite a few nuances here, including the fact that GTFS transfers are in terms of minimum time while OSM transfers are stored as distances and adjusted for user-specified speed; GTFS feeds are loaded one by one in a streaming fashion while OSM transfers are generated all at once in a separate stage; even when transfers supplied within a single GTFS feed are exhaustive, transfers are still needed to stops loaded form other GTFS feeds; OSM transfers are always to the closest (via OSM) stop on another trip pattern, while GTFS transfers might be to other stops that are actually closer due to tunnels (this last point complicating the layering or replacement of OSM transfers by GTFS ones).

Addresses issue #641
Supersedes PR #642, but could benefit from integrating from ideas from that PR.

[abyrd]

In my own testing, this can now load the MBTA feed, including GTFS transfers, and route on it. However, only about 2000 of 7000 GTFS transfers are of types that we currently apply to routing, compared to 84000 transfers that must be built by routing through the OSM streets. I have not yet performed enough testing to be convinced the use of stop-to-pattern pairs as keys when merging OSM and GTFS transfers works exactly as intended.

c.c.r.t.GtfsTransferLoader - GTFS 692fe083a89cef43ca8e5cf8 contains transfers. Loading them in mode STOP_TO_PATTERN.
c.c.r.t.GtfsTransferLoader - Total GTFS transfers processed from all feeds: 7028
c.c.r.t.GtfsTransferLoader - Number with unsupported specificity values: 4930
c.c.r.t.GtfsTransferLoader - Number with unsupported transfer types: 4930
c.c.r.t.GtfsTransferLoader - Number missing stop information: 0
c.c.r.t.GtfsTransferLoader - Net number of GTFS transfers actually loaded: 2098
c.c.r.s.StreetLayer - Building edge lists from edges...
c.c.r.s.StreetLayer - Done building edge lists.
c.c.r.s.StreetLayer - Building edge lists from edges...
c.c.r.s.StreetLayer - Done building edge lists.
c.c.r.s.StreetLayer - Indexing streets...
c.c.r.s.StreetLayer - Done indexing streets.
c.c.r.t.TransitLayer - Rebuilding transient indices.
c.c.r.t.TransitLayer - Done rebuilding transient indices.
c.c.r.t.TransferFinder - Finding transfers through the street network from 10269 new transit stops...
c.c.r.t.TransferFinder - 70k transfers created through the OSM street network.
c.c.r.t.TransferFinder - Done. Processed OSM street transfers from 10k of 10k new transit stops.
c.c.r.t.TransferFinder - 1k of 10k new transit stops are not linked to the street network.
c.c.r.t.TransferFinder - Deferred to GTFS for 1k stop pairs in mode: STOP_TO_PATTERN
c.c.r.t.TransferFinder - 84k transfers created through the OSM street network.

[abyrd]

It is worth noting that commit f1a3173 alone should probably be enough to load the MBTA feed without failing, without applying the loaded transfers to routing. This may be a valid short-term solution if we want to avoid disruptive changes to core routing functionality in an upcoming release.

[abyrd]

After recent discussion, default has been changed to the existing OSM_ONLY behavior, with others selectable through JSON network config. I have observed the default behavior in testing, then switched to STOP_TO_PATTERN layering of GTFS over OSM using the JSON config via the web UI. With the Boston test data, adding the GTFS transfers seems to strictly reduce the accessible area and the cumulative indicator values (see image). This seems to hold for any origin point I have tested. We should carefully consider whether this is the expected outcome and examine individual paths to confirm that the replaced OSM transfers are indeed slightly faster than the GTFS minimum transfer times. In the mean time, OSM_ONLY should remain the default.