Stop time progression
vlopezferrando opened this issue · 4 comments
First, thanks for this awesome piece of software! It works great, it is efficient, and has some pretty advanced functionality. Thanks for sharing it.
The README has the sentence "Validation includes for example checking stop time progressions", but I couldn't find this check in the source code, and in fact I see that erroneous feeds which include "teleports" or trips that go back in time at some point, are left as is by gtfstidy.
Is there any plan to add this check? Are you open to a contribution that implemented this feature? If so, would you provide some tip on how to implement it, so it is acceptable for you to merge it?
Thanks.
Thank you for you feedback! Trips that go back in time should be detected, the check is implemented in the gtfsparser: https://github.com/patrickbr/gtfsparser/blob/master/feed.go#L1092 Do you have an example feed where such a case is not detected as an error by gtfstidy?
By "teleports" I assume you mean extremely high speeds before stations. This check is indeed missing at the moment, but it's on my TODO list.
To be fair, I did not find errors with stop times going back in time, but having the same time.
Do you think it would be reasonable to change the comparison in https://github.com/patrickbr/gtfsparser/blob/master/feed.go#L1092 from > to >=?
If a stop appeared twice in the same position -for some reason-, then it would make sense that two consecutive stop times were equal. It's a bit of an edge case...
What do you think?
Two stops having the same time is valid in GTFS, so I don't think that changing to comparison would be a good idea. It is pretty common in bus and tram schedules that two consecutive (and different) stops have the same arrival and departure time. This is often the case if the real-world travel time between the two stops is smaller than 30 seconds.