Fix timetable generation for StopTimeUpdate containing only arrival or departure #6392
Conversation
miklcct
force-pushed
the
arrival-only-tripupdate
branch
from
0541650 to
7a96e1a
Compare
miklcct
changed the title
miklcct
force-pushed
the
arrival-only-tripupdate
branch
from
7a96e1a to
f60c1db
Compare
miklcct
force-pushed
the
arrival-only-tripupdate
branch
from
f60c1db to
863c0cd
Compare
miklcct
changed the title
|
I need discussion of the behavior in filling the missing times. |
application/src/test/java/org/opentripplanner/updater/trip/moduletests/delay/DelayedTest.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Thomas Gran <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6392 +/- ##
==========================================
Coverage 69.84% 69.84%
- Complexity 18125 18132 +7
==========================================
Files 2069 2069
Lines 77268 77279 +11
Branches 7855 7861 +6
==========================================
+ Hits 53965 53975 +10
Misses 20546 20546
- Partials 2757 2758 +1 ☔ View full report in Codecov by Sentry. |
| .addStop(STOP_A1, "0:01:00", "0:01:01") | ||
| .addStop(STOP_B1, "0:01:10", "0:01:11") | ||
| .addStop(STOP_C1, "0:01:20", "0:01:21") | ||
| .addStop(STOP_A1, "0:00:00", "0:00:00") |
There was a problem hiding this comment.
Please don't modify existing tests and create new ones instead that test this very feature.
| @@ -312,7 +312,7 @@ public void fixIncoherentTimes() { | |||
| stopTimeUpdateBuilder.setStopSequence(1); | |||
| stopTimeUpdateBuilder.setScheduleRelationship(StopTimeUpdate.ScheduleRelationship.SCHEDULED); | |||
| var stopTimeEventBuilder = stopTimeUpdateBuilder.getArrivalBuilder(); | |||
| stopTimeEventBuilder.setDelay(0); | |||
| stopTimeEventBuilder.setDelay(900); | |||
There was a problem hiding this comment.
Will this test fail if you don't change it?
There was a problem hiding this comment.
The time will be valid after my code change because the bus can make up time during its journey.
| newTimes.updateDepartureDelay(i, delay); | ||
| } | ||
|
|
||
| // propagate arrival and departure times, taking care not to cause negative dwells / hops |
There was a problem hiding this comment.
I think you're mixing several features here, aren't you?
Can you please work in small increments? The first PR should only deal with the case where either arrival or departure is missing. In such a case you can use the other one in its place. This shouldn't need any new interpolation logic.
Once we have finished that PR we can look at more complex cases.
There was a problem hiding this comment.
Okay, I don't get it then and I think I need to see drawing then.
Using an arrival/departure fallback is, IMO, still a wise first step and something I would like to see first, even if it doesn't fix all of your problems.
There was a problem hiding this comment.
The existing interpolation logic isn't what you describe. The existing logic is that if the departure time is missing, it is assumed that the bus will always stop for its original dwell time even if it is late (resulting in negative times down the trip), so what I have written and what you are describing are both changing the logic, which is an integral part of this PR.
|
To explain matter, the following is how OTP fails and my proposed change:
|
|
Thanks for those tables. I think I get it now. I'm not enthusiastic about making a complicated method even more complicated but if you can write separate module tests for this logic I will soften my position. One point remains: I'm aware that they are not doing anything that is explicitly disallowed by the spec, but they could make everyone's live easier if they just specified the exact arrival and departure time. Do we want to pay the cost of the complexity to allow them to keep doing what they are doing? Lets discuss this in the dev meeting. |
|
As discussed in the meeting we should provide options for the deployment how to fill in the missing times.
|
Summary
The GTFS-RT specification does not require both arrival and departure to be provided for a TripUpdate, only either of them is enough. This fixes NEGATIVE_DWELL_TIME or NEGATIVE_HOP_TIME resulting from these updates as they were not processed correctly.
Issue
Closes #6391
Unit tests
Added
Documentation
None needed
Changelog
Bumping the serialization version id
None needed