Trip Monitoring Docs#374
Conversation
br648
left a comment
There was a problem hiding this comment.
This is good! A couple of comments to consider.
| - **Padding/slack before, between, and after transit legs** (boarding, transfer, alighting slack, respectively)<br> | ||
| These constants ensure a traveler has enough time to exit a vehicle and go to the boarding location | ||
| of the next transit vehicle (see diagram below). OTP-middleware can guess the boarding and alighting slacks | ||
| from the original itinerary, however if an overall transfer slack is configured in OTP, it must also be configured in |
There was a problem hiding this comment.
Where under OTP should this be checked and is the parameter the same name? Is it possible to get this value from the response to avoid a mismatch in values?
There was a problem hiding this comment.
I added clarification in 658e206, thank you. The transfer slack is tough because we don't know whether an itinerary with transfers has the shortest allowable transfers or not.
|
|
||
| #### Plan Method | ||
|
|
||
| If the leg id method fails, a `plan` GraphQL query is sent to OTP to replan the entire trip for the target date, using |
There was a problem hiding this comment.
It might be worth adding why the leg id method might fail.
Improve section on slacks
alec-georgoff
left a comment
There was a problem hiding this comment.
One nit! This is awesome, thanks for putting the time into this :D
|
|
||
| The **target date** (`MonitoredTrip.journeyState.targetDate`) is the date a trip is supposed to take place. | ||
| For one-time trips, the target date is simply the date of the trip. For recurring trips, the target date is the next | ||
| occurrence of the trip, based on the days the trip is being monitored. Note that holidays are not supported yet. |
There was a problem hiding this comment.
nit: I might break out the note about holidays into a separate block so it's more noticeable if someone is skimming? Maybe something like this:
Note
Holidays are not yet supported for trip monitoring
There was a problem hiding this comment.
Didn't see that feature in the GH docs, very cool! (dd4ac78)
Add notes sections
Fix notes sections
josh-willis-arcadis
left a comment
There was a problem hiding this comment.
Looks good as is. Some comments about adding more information to the current class diagrams and potential for more class diagrams. This would help clearly show the relationship between all the classes and their methods. I think these would be nice to haves.
| --- | ||
| title: Trip Monitoring Classes and Relevant Fields/Methods | ||
| --- | ||
| classDiagram |
There was a problem hiding this comment.
A nice addition to this class diagram could the specific methods in each class that are relevant to the trip monitoring process.
| [`MonitorAllTripsJob`](../src/main/java/org/opentripplanner/middleware/tripmonitor/jobs/MonitorAllTripsJob.java) | ||
| that runs every minute in the background. The job splits the monitoring of all qualifying trips between threads | ||
| as determined by the number of CPUs on the instance. Each thread runs a | ||
| [`TripAnalyzer`](../src/main/java/org/opentripplanner/middleware/tripmonitor/jobs/TripAnalyzer.java) |
There was a problem hiding this comment.
would love to see class diagrams for these at some point!
There was a problem hiding this comment.
I will delay implementing this suggestion. Right now, the flow diagram below better explains how the analyzers are set up.
| --- | ||
| flowchart LR | ||
| job["⏱️ MonitorAllTripsJob"] | ||
| analyzer1[TripAnalyzer<br>CheckMonitoredTrip] |
There was a problem hiding this comment.
add CheckMonitoredTrip.run() to show which method in the class diagram was called.
| | `PLAN_QUERY_RESOURCE_URI` | Optional location of a custom GraphQL template for the OTP `plan` query. | | ||
| | `MAXIMUM_MONITORED_TRIP_ITINERARY_CHECKS` | The maximum number of attempts to obtain a matching itinerary (default 3). Used with `MonitoredTrip.attemptsToGetMatchingItinerary`. | | ||
|
|
||
| The [`ItineraryExistence`](../src/main/java/org/opentripplanner/middleware/models/ItineraryExistence.java) class |
There was a problem hiding this comment.
these are methods that could be added to the class diagram.
|
|
||
| #### Leg ID Method | ||
|
|
||
| The [`ItineraryChecker`](../src/main/java/org/opentripplanner/middleware/itinerarymatching/ItineraryChecker.java) class |
There was a problem hiding this comment.
Would love to see Itinerary related classes in a class diagram. These are essential classes in this process.
| ("Unable to monitor trip") is sent. | ||
|
|
||
| A provision exists in the `CheckMonitorTrip` logic, so that a notification that a trip is no longer possible is sent | ||
| if no matching itinerary has been found for over a week. (This is not currently implemented.) |
There was a problem hiding this comment.
could be a good use of a note.
| Once an occurrence of a trip completes, the journey state is "reset", | ||
| so that notifications can be sent again for the next trip occurrence. | ||
|
|
||
| A `JourneyState` consists of the following attributes: |
There was a problem hiding this comment.
good place for another class diagram.
| Upon saving a trip (POST), if the trip is recurring, OTP-middleware will perform an additional existence check. | ||
| If the check does not succeed, the request is rejected, and the trip is not saved or monitored. If the check passes, | ||
| the result is saved in `MonitoredTrip.itineraryExistence`. | ||
| (The check is not performed when saving one-time trips.) |
There was a problem hiding this comment.
another good use of a note.
|
|
||
| | Notification Type | Description | | ||
| | --- | --- | | ||
| | `INITIAL_REMINDER` | Advance trip reminder ("Reminder for My Trip at 8:30"). If `MonitoredTrip.notifyAtLeadingInterval` is true, sent once at the lead monitoring time on the day a given trip occurs. | |
There was a problem hiding this comment.
this is a good method to include in class diagram.
Checklist
devbefore they can be merged tomaster)Description
This PR adds a new markdown file that provides an overview of trip monitoring.