Use map matching with GTFS shapes to find routes in GTFS link mapper

[mark-idleman]

No description provided.

[mark-idleman]

@michaz this is a rough draft of a map matching-based implementation of the GTFS link mapper we're using that I wrote. The
basic approach is to loop through all GTFS feeds, and for each feed, take the points that make up each GTFS trip, map match them, and add all the resulting matched edge IDs to a Set. Then, once this is done for all feeds, set the car vehicle access as "accessible" only for edges that were matched to, and "inaccessible" for all other edges. Then, carry out the standard link mapping process we've been doing, routing between each unique stop->stop pair using the car profile, but now the only routes allowed are (hopefully) those that use the map-matched edges returned from the previous steps.

I'm hoping to test this, but there seems to be some conflicts with the latest version of the core GH dependencies we're using and the current code in the map matching repo; when I try to run this function, I get an error on this line, as it seems that getAlgorithmFactory() is no longer implemented in the latest version of the GraphHopper class.

Is there a way around this perhaps? Or is updating the map matching library our best bet?

[mark-idleman]

@michaz It seems as though I've hit another wall here, and this time it might be a tougher issue to address. Since my last update, I found a version of the GH map matching packages that "agrees with" the code currently in our fork, and tried running the GTFS link mapping process again using GTFS feeds from Sacramento (~15 feeds, I've used this region for testing the link mapper up to this point). The error I'm hitting is:

java.lang.IllegalArgumentException: Sequence is broken for submitted track at time step 1 (86 points). observation:Observation{point=38.5808699477238,-121.525938303825}, 11 candidates: [distance: 43.35848006936979 to 38.580494118790945,-121.52580536587101,NaN, distance: 16.215544297774592 to 38.58072918461403,-121.52588955743364,NaN, distance: 42.55785099807162 to 38.58111773240084,-121.52631144656937,NaN, distance: 38.7607867604333 to 38.58113263356237,-121.5256451783846,NaN, distance: 35.61993323626478 to 38.58117713248789,-121.52605452139288,NaN, distance: 35.61993323626478 to 38.58117713248789,-121.52605452139288,NaN, distance: 20.967781597962 to 38.581051071389,-121.526005411317,NaN, distance: 20.967781597962 to 38.581051071389,-121.526005411317,NaN, distance: 47.53890736372782 to 38.58125743079016,-121.52570720446946,NaN, distance: 33.84877330033995 to 38.58097277558819,-121.52557178755595,NaN, distance: 33.84877330033995 to 38.58097277558819,-121.52557178755595,NaN]. If a match is expected consider increasing max_visited_nodes. at com.graphhopper.matching.MapMatching.computeViterbiSequence(MapMatching.java:313) at com.graphhopper.matching.MapMatching.match(MapMatching.java:178) at com.graphhopper.replica.GtfsLinkMapper.setGtfsLinkMappingsMapMatching(GtfsLinkMapper.java:87) at com.graphhopper.http.cli.GtfsLinkMapperCommand.run(GtfsLinkMapperCommand.java:23) at com.graphhopper.http.cli.GtfsLinkMapperCommand.run(GtfsLinkMapperCommand.java:11) at io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:87) at io.dropwizard.cli.Cli.run(Cli.java:78) at io.dropwizard.Application.run(Application.java:94) at com.graphhopper.http.GraphHopperApplication.main(GraphHopperApplication.java:37)

I tried a few things based off of GH forum posts to see if I could get around this (mainly, increasing the max_visited_nodes param, as I've done in my latest commit), but this didn't seem to help. It seems as though this error is more about "correctness" - basically, the algorithm can't properly match a section of path up with a node/edge in the network.

Any other thoughts on things I could try here? I'm guessing that fixing this would require manual editing of the GTFS, and if that's the case, we might just consider this an "infeasible" solution and move on

[michaz]

Ah yes, this requires a closer look. -- You're right, this means that we couldn't map-match the geometry. I wouldn't let that discourage us, let me check what may be going on.
Will try to do this tomorrow.

[michaz]

To expand on this: You're exactly right, this "exception" is not an error, it's just a negative result -- we couldn't (fully) map-match the provided geometry for whatever reason. So to make it fault-tolerant in the sense that the program doesn't crash, we would catch that exception.

However, I don't know how we would react to that situation. The simple point-to-point routing you're currently doing can react to a not-found route by just.. not having a route for that segment. But what would we do with the map-matching approach here? We could just not mark any edges for that route to prefer in the subsequent point-to-point routing.

Would that help? Or is that getting too messy and we should really shelf it until we think we really need it?