Update GtfsRealtime and include severity, effect and cause from GTFS RT#3747
Conversation
optionsome
left a comment
There was a problem hiding this comment.
I need clarification for the commented things before I'll finish this pr.
| // TODO | ||
| // This is deprecated | ||
| @Override | ||
| public DataFetcher<Iterable<TripPattern>> patterns() { |
There was a problem hiding this comment.
Not sure if this should be fixed or not
| return AlertSeverity.WARNING; | ||
| } | ||
| switch (severity) { | ||
| case PTI_26_255: |
There was a problem hiding this comment.
Is it ok to map these values into what seems to be their human readable versions?
There was a problem hiding this comment.
As a general principle, I don't think OTP should change any of the data provided in any service.
However, all the PTI_-values have been removed in the upcoming version of SIRI, so I am not sure if these values are actually needed anymore.
There was a problem hiding this comment.
Currently, the transmodel enum for the severity doesn't contain those so I'm not sure what would happen now if someone tried to use a SIRI updater that used the PTI_-values together with the transmodel API. We could alternatively just map these PTI_-values to the values known by the transmodel API in that side instead of when loading in the severities to the internal data model. But as you pointed out about the upcoming change, I'm not sure if that is worth the effort here.
| /** | ||
| * An enum containing cause options for an alert. | ||
| */ | ||
| public enum AlertCause { |
There was a problem hiding this comment.
Is creating these duplicate enums for the internal model wanted?
There was a problem hiding this comment.
We decided that it's better to use duplicate enums for the internal data models instead of using enum directly from the GTFS RT library.
| @@ -67,7 +67,7 @@ type Alert implements Node { | |||
| stop: Stop | |||
There was a problem hiding this comment.
These stop, route, agency and trip fields need to be replaced with stops etc because alerts can have multiple entities but I'm not sure what is the ideal way. Should the stops etc field be at the root level of the alert of under some entities field in some way.
There was a problem hiding this comment.
We discussed this in today's meeting. @hannesj suggested that we should implement the entities similarly as the places in the nearest query so you need to use fragments to handle the different entity types.
| return environment -> null; | ||
| return environment -> { | ||
| var text = getSource(environment).alertDescriptionText; | ||
| return text instanceof TranslatedString |
There was a problem hiding this comment.
This is duplicated code. Can you use a reusable method?
There was a problem hiding this comment.
Indeed. I'll do that.
|
This is ready for review now. I'll also do some final checks with different kinds of alerts data in the meanwhile. One difference I noticed at least when compared against the hsldevcom fork of OTP1 is that the default values for the translated fields where in Finnish in OTP1 but in English in OTP2. I'm not sure what causes the difference but maybe it should be possible to add an option to configure the default language if that is not already possible somehow. |
Based on tests created by evansiroky
|
Found some issues while testing and fixed those. e7964d8 was an existing issue when only route_type entity was defined, it tried to add agency selector with empty string which lead to an error. 60706bc makes the start time behave like the end time so if they are not set, null is returned. I plan to add support for the route_type selector (and probably also trip direction) in a separate pull request and also allow alerts with no known selectors to be included (now they are not added if they have no selectors known by OTP). |
6b72182
Summary
Issue
closes #3653
Unit tests
Updated tests related to SIRI and added tests for GTFS RT alerts.
Code style
Used the intellij formatting rules
Documentation
Not needed?
Changelog
From title and updated legacyGraphQL changelog