Closed JanJakes closed 6 years ago
This looks like a data issue at first sight...
I'd look at the geometries of the trip, then route, then line used : field geometry_id
in respective files (then geometries.txt file).
If my memory doesn't fail me, Navitia completes geometry (projecting stops) of a trip by adding real stops locations to be sure they appear on the path drawn. If the data only contains the route (or line) geometry in one case, it might lead to that behaviour : line geometry describes the main path, but if the service vary we get weird results.
If the data contains the exact trip geometry in the other case, we should have better results drawing it.
Hope that helps you debug!
Nota: not sure tflgtfs is supporting every feature of GTFS but the project is nice (so is the language used :crab: ).
Thanks, I'll try to inspect the data on Monday. What's curious though is that sometimes exactly the same line is correct and the next ride a few minutes later is not. I'll let you know what I find in the data.
I looked to the data and it seems the wrong routes have the following shape:
But it also seems the list of stops is the same for both the good and broken routes. So I guess this is a data/tflgtfs bug?
Sorry for the holidays' delay. Yes it looks like it's a data bug... So I close the issue, please reopen it if you discover something new!
I've tried to import London transport using https://github.com/CommuteStream/tflgtfs. I works well but in some cases I get broken line geometries.
Example (requested departure at 12:00):
Exactly the same route with requested departure 4 minutes later (12:04):
For the blue sections I get exactly the same data in both cases - metro Piccadilly, 17 stops, 49 minutes. The only difference is departure time (the first one leaves at 12:08, the second one at 12:17) and the (in the first case) broken GeoJSON.