You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
docker run -it --rm -v ~/Downloads/:/usr/node/ shst:latest shst match /usr/node/shst-js-tests/test_one_route_savannah.geojson --out=/usr/node/shst-js-tests/test_one_route_savannah.out.geojson --follow-line-direction
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:
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.
Details
GTFS 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.
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: