Skip to content
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

Open
josiekre opened this issue Jun 15, 2019 · 1 comment
Open

Map match a GTFS route shape #58

josiekre opened this issue Jun 15, 2019 · 1 comment

Comments

@josiekre
Copy link

josiekre commented Jun 15, 2019

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.

@josiekre
Copy link
Author

Summary

The culprit is in matchGeom(). It is set to do nothing when a confidence of 0 is returned.

if(0 < match.confidence ) {

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.

Screen Shot 2019-06-19 at 5 08 57 PM

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.

https://router.project-osrm.org/match/v1/driving/-81.25791,31.998509;-81.257629,31.997689?geometries=geojson&annotations=true

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.

https://router.project-osrm.org/match/v1/driving/-81.257729,31.99755;-81.25515,31.997889?geometries=geojson&annotations=true

If I submit all four points, the match confidence stays at 0.

https://router.project-osrm.org/match/v1/driving/-81.25791,31.998509;-81.257629,31.997689;-81.257729,31.99755;-81.25515,31.997889?geometries=geojson&annotations=true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant