-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map match a GTFS route shape #58
Comments
SummaryThe culprit is in Line 828 in b81fdaa
Is there a reason we can't add a flag to allow confidence of 0 to pass through? If there is not outright opposition, I can start a pull request to implement this. DetailsGTFS route shapes are not always drawn the most accurately. In my above Gist example, the beginning of the line in the lower left was approximated. The lineString was drawn haphazardly by whoever was creating the GTFS file at the start of the line, not following actual roads. I double-checked that this is the problem by submitting an equivalent API call to the hosted OSRM for the first two points of the example lineString in the Gist. This results in a match confidence of 0.
But if I submit the lineString with points 3 to 4 when the line starts following a road, I get a confidence around 0.98.
If I submit all four points, the match confidence stays at 0.
|
I'm attempting to map match shapes from a GTFS feed. There are many benefits to having ShSt IDs on GTFS feeds in order to describe which routes buses/rail travel (linestring from shape.txt) in addition to where bus stops are located (points from stops.txt).
Some linestrings successfully match all the segments along the route, but the majority return completely unmatched.
Using a Docker container, I'm running the command below.
My first hypothesis was that any route with a loop or turnaround point would fail. So I tested with these two linestrings: https://gist.github.com/josiekre/d584603ae22ee6551ad2661b7f615efa. Notice the section removed in the south west corner of service along Quacco Rd. Both failed to match.
So the problem, at least in this case, is not the turnaround.
It could be that #23 (cc: @emilyeros) could be the reason for unmatched results. But I don't understand why this error exists. If the HMM algo is attempting to route along the direction of the linestring, it would seem that this should not be a problem.
The text was updated successfully, but these errors were encountered: