Enrich new stop-to-street linking code

[abyrd]

Pull request #1922 introduces new code for linking transit stops to the street network.

The new stop linker code has a similar purpose to the old code, but behaves in a much more predictable manner. The old stop linker code has not been removed from the repo because it is used elsewhere, and various parts of OTP will need to be migrated to cooperate with the new stop linker code. In normal (non-Analyst) routing, linking result quality with the new code is much better because there is a tendency to link to pedestrian paths instead of car roads. We expect to see most linking problems now at multi-level overpasses and subways.

The new linker was made to be "the simplest thing that works right", and as such it provides great results but does not quite match all the features of the existing linker. Some additional things that will need to be addressed:

• Direct linking of GTFS stops to transit platforms in OSM that have been tagged with stop IDs.
• Preferential linking of stops to streets that have the right transit lines running on them.
• Only linking GTFS stops that are within the envelope of the OSM data (just a speed optimization).

Direct linking of GTFS stops to OSM nodes tagged with stop IDs

There are two street-to-transit linking graph builders in OTP, TransitToTaggedStopsModule and StreetLinkerModule. StreetLinkerModule links transit stops, bike rental stations, and park-and-ride lots into the OSM street network, and now does so using the new SimpleStreetSplitter linking code. The TransitToTaggedStopsModule is always run before the main StreetLinkerModule. It takes advantage of the fact that in some cities, OSM contains the definitive location of every transit stop as a node along a walkable way, and those nodes are tagged with GTFS stop_ids (a method that could in fact be quite useful in improving the result quality of our bulk analyses). The TransitToTaggedStopsModule doesn’t need to be modified to use the new splitter because it doesn't perform any splitting, it just creates edges to existing nodes. But it does mean that some stops may already be linked by the time we reach the main StreetLinkerModule.

As a solution, we need to either:

A) In SimpleStreetSplitter method link(), check whether each transit stop vertex has any outgoing StreetTransitLink edges before calling public boolean link (Vertex vertex).

B) Merge the two modules (TransitToTaggedStopsModule and StreetLinkerModule), and in the section of StreetLinkerModule that handles transit stops, call a function that looks for tagged OSM nodes before calling the splitter code.

Personally I lean toward solution B, which I think would lead to more readable code.

Preferential linking of stops to transit-served streets

There is a module that used to be cryptically named "MapBuilder", and is now called "BusRouteStreetMatcher" which improves the quality of stop-to-street linking by favoring streets where transit actually travels. GTFS provides a mapping from trips to shapes. This module provides a mapping from stops to trips and from GTFS shapes to OSM street edges, which transitively gives us a mapping from stops to OSM street edges. The street edges that belong to a stop are favored when linking that stop to the street network.

The BusRouteStreetMatcher can be quite slow, and @buma has rewritten it in a branch but the idea is roughly the same. The BusRouteStreetMatcher is optional and turned off by default, but when it's turned on this information should affect stop to street linking, presumably by using a scoring system instead of only distance to select edges for linking.

Applying a geographic envelope when stop linking

@buma has changed the old stop linking code to link only stops that are inside the OSM envelope. Some users include extensive national rail networks in local graphs that only include OSM for a single city, and the (pointless) linking attempts for the GTFS stops completely outside the OSM coverage area can be time consuming. The graph builder module(s) that call the new linking code could also be adapted to check whether each vertex is inside an envelope before linking it. However @mattwigway has pointed out that the slowness of unlinked stops was probably due to the search envelope being repeatedly expanded, something we don't do in the new code. Therefore this optimization may no longer be necessary.