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.

[ansoncfit]

I have looked into a range of travel time and path results, and they seem sensible with the latest changes. The min_transfer_time values in transfers.txt do seem long/conservative to me (see Example 1 below), so the general decreases are not unexpected. There are still some cases of increases (see Example 2 below).

Example 1: Maverick (Blue Line) to Symphony (Green Line E branch). The logical transfer point is at Government Center (from stop 70039 to stop 70202, which is directly above). Someone could reasonably make this transfer in ~30 seconds, but min_transfer_time is 124. With default OSM_ONLY transfers, the walking time is minimal. With STOP_TO_PATTERN forcing use of min_transfer_time, the router finds a faster path alighting the Blue Line one stop earlier (at State St) and walking to Government Center. As we discussed early on, this may be a case where STOP_TO_PATTERN mode makes travel time values more defensible (even if the supplied values in GTFS are overly conservative) at the expense of less realistic/intuitive path results.

Example 2: Lower Mills (Mattapan Line) to Andrew (Red Line). This involves a transfer from stop 70261 (Mattapan Line stop at Ashmont, linked southeast to Radford Lane) to 70093 (Red Line Stop at Ashmont, linked west to the busway)

A walk between these stops via OSM is ~6 minutes, and transfers.txt includes min_transfer_time equivalent to 3m33s.

Detailed itineraries show ~3 minute savings

[abyrd]

Thanks for those examples, which reassure me both kinds of transfers are being applied in sensible places. I updated the Javadoc as suggested and I think this is ready to merge.

[ansoncfit]

Approving for merge. Corresponding updates to the user manual are now at conveyal/docs#96