Add communication_period and impact_period

[skalexch]

BACKGROUND

In the GTFS Realtime Alert spec, active_period is defined as: Time when the alert should be shown to the user. If missing, the alert will be shown as long as it appears in the feed. If multiple ranges are given, the alert will be shown during all of them.

However, there still is an ambiguity of interpretation of the active_period field; whether it is intended for the period of showing the alert or for the period of the related service disruption itself.

PROPOSAL

We propose the addition of two fields, communication_period and impact_period, to disambiguate active_period.

communication_period: Time when the alert should be shown to the user strictly for informative reasons.
impact_period: Time when the services are affected by the disruption mentioned in the alert.

We also define rules of interaction with active_period to ensure that the new fields are mutually exclusive with active_period.

More details and potential combinations can be found in Issue#521 and the proposal doc.

[doconnoronca]

Perhaps the impact period should be allowed even if there is no communication period so the producer doesn't have to support a communications period.

Maybe also indicate the active period is being deprecated.

[gcamp]

Some comments, I agree with @doconnoronca that we should also deprecate active_period

[gcamp]

Suggested change

| **communication_period** | [TimeRange](#message-timerange) | Conditionally Required | Many | Time when the alert should be shown to the user strictly for informative reasons. If missing, the alert will be shown as long as it appears in the feed. If multiple ranges are given, the alert will be shown during all of them. <br><br> - **Required** If impact_period is specified.<br> - **Forbidden** otherwise.|

| **communication_period** | [TimeRange](#message-timerange) | Conditionally Forbidden | Many | Time when the alert should be shown to the user strictly for informative reasons. If missing, the consuming application can decide when it's appropriate to be shown. If multiple ranges are given, the alert will be shown during all of them. <br><br> - **Optional** If impact_period is specified.<br> - **Forbidden** otherwise.|

[miklcct]

What is the use case of communication_period? Why do you want to have an alert in a feed when it is outside the communication period?

[stevenmwhite]

I'd remove the word "disruption" since alerts come in a lot of different flavors...

Time when the services are affected by this alert.

[stevenmwhite]

What is the use case of communication_period? Why do you want to have an alert in a feed when it is outside the communication period?

Agencies often want to alert riders to upcoming situations, and create alerts with a very broad active_period in order to do so. This comes out of the discussion here: #482 (comment)

I'm in favor of this generally, with a few notes:

• I don't think communication_period should be required. If there's no communication period I think consumers should just show it when impactful.
• On the flip side side, we see agencies try to use this for general informational messages that don't have a true impact on service. Should we conditionally require either the communication or the impact period (or both).
• I also agree that we should deprecate active_period, but I'm not sure how that will work with backwards compatibility.

[miklcct]

What is the use case of communication_period? Why do you want to have an alert in a feed when it is outside the communication period?

Agencies often want to alert riders to upcoming situations, and create alerts with a very broad active_period in order to do so. This comes out of the discussion here: #482 (comment)

I'm in favor of this generally, with a few notes:

• I don't think communication_period should be required. If there's no communication period I think consumers should just show it when impactful.
• On the flip side side, we see agencies try to use this for general informational messages that don't have a true impact on service. Should we conditionally require either the communication or the impact period (or both).
• I also agree that we should deprecate active_period, but I'm not sure how that will work with backwards compatibility.

I still don't know why there is a need for communication_period. If the alert is in the feed, we should show it. If the agency doesn't want to show the alert, just leave it out in the feed.

Also, is it required that the impact period is totally within the communication period. Is it allowed to have impact period outside communication period?

Also, should the alert be shown in the following situations, assuming that the impact period is within the communication period?

1. If the current time is outside the communication period, and we are checking journeys within the impact period.
2. If the current time is outside the communication period, and we are checking journeys outside the impact period, but within the communication period.
3. If the current time is inside the communication period, and we are checking journeys outside the impact period, but within the communication period.
4. If the current time is inside the communication period, and we are checking journeys outside the communication period.

[stevenmwhite]

If the alert is in the feed, we should show it. If the agency doesn't want to show the alert, just leave it out in the feed.

I wouldn't be opposed to a spec update that says the dates of the active period are the dates it has an impact, and that an alert appearing in the feed should be considered an affirmative intent from the producer that it is currently within the desired communication timeframe. That would essentially achieve the same thing, but it's not quite how it's interpreted now.

As for your four specific questions/situations... I think those are things that are pretty dependent on the specific consumer and the specific place in their app where the user is at the time. Different consumers may handle it differently, because their UX is different. If you are on a screen, for example, where you are looking at a route without planning a trip. I would suggest that the alert should be shown during the communication period. But if you're on a screen in the app that is specific to a future-planned trip that is outside of the impact period, then I probably wouldn't show the alert on that screen.

In general, I do believe that the details of the user experience should still be the responsibility of the consuming app developer, and not something that's completely explicit in the spec. The spec should allow for communication of the agency's intent.

[skinkie]

Some people want to change the journey planner results based on the alerts. This alone is a reason to know about communication versus actual period.

[miklcct]

If the alert is in the feed, we should show it. If the agency doesn't want to show the alert, just leave it out in the feed.

I wouldn't be opposed to a spec update that says the dates of the active period are the dates it has an impact, and that an alert appearing in the feed should be considered an affirmative intent from the producer that it is currently within the desired communication timeframe. That would essentially achieve the same thing, but it's not quite how it's interpreted now.

As for your four specific questions/situations... I think those are things that are pretty dependent on the specific consumer and the specific place in their app where the user is at the time. Different consumers may handle it differently, because their UX is different. If you are on a screen, for example, where you are looking at a route without planning a trip. I would suggest that the alert should be shown during the communication period. But if you're on a screen in the app that is specific to a future-planned trip that is outside of the impact period, then I probably wouldn't show the alert on that screen.

In general, I do believe that the details of the user experience should still be the responsibility of the consuming app developer, and not something that's completely explicit in the spec. The spec should allow for communication of the agency's intent.

So are you specifically leaving out the answers to my questions above in the spec?

In my use case, there is a journey planner, and there is also a screen where you can look for routes / stations and show their timetables without planning for a journey, and you are allowed to change the date / time in that screen.

Is the spec leaving out the behaviour on which alerts should be shown here?

[westontrillium]

@doconnoronca

Perhaps the impact period should be allowed even if there is no communication period so the producer doesn't have to support a communications period.

+1 to this. In the event that only Impact Period is defined, the alert should still be displayed, but only impact routing during the Impact Period.

But I think agencies will also want the option to have an alert with a Communication Period without the need to define the hard boundaries of an Impact Period, especially if that alert is for something more nebulous, like an expected severe weather event (pun likely intended). For other alerts, there may not really be an "impact." So I would actually be in support of:

• Active Period: Forbidden if Communication OR Impact Period is defined, optional otherwise
• Communication Period: Optional
• Impact Period: Optional

@stevenmwhite

I also agree that we should deprecate active_period, but I'm not sure how that will work with backwards compatibility.

I don't think it would work, strictly speaking. Unless deprecated means we all just don't talk about it. 😅 I think it would have to be here to stay until the versioning question is resolved, yes?

@miklcct

I still don't know why there is a need for communication_period. If the alert is in the feed, we should show it. If the agency doesn't want to show the alert, just leave it out in the feed.

Something else to consider regarding the usefulness of Communication Period is that an agency might not have staff available 24/7 to add an alert at any given moment. Such agencies may want the ability to "queue" up an alert by adding it to their feed ahead of time with a Communication Period for when they actually want it to be displayed in apps.

Also, is it required that the impact period is totally within the communication period. Is it allowed to have impact period outside communication period?

I think there are too many possible scenarios to establish explicit rules around how Communication and Impact Periods' respective time ranges must relate to one another. I'd rather allow agencies more flexibility on how they communicate with riders and keep the responsibility of conveying information in a logical way on them (anyway, you could still publish some very whacky alerts even with limitations on how impact/communication have to relate to one another).

In my use case, there is a journey planner, and there is also a screen where you can look for routes / stations and show their timetables without planning for a journey, and you are allowed to change the date / time in that screen.

I think that if the user is using the screen to select the date/time, then if there is a Communication Period defined and the selected date/time falls within the Communication Period, the tool should show it. If the selected date/time falls outside the Communication Period, do not show the alert. If there is no Communication Period defined but the alert is in the feed, show it.

[miklcct]

@miklcct

I still don't know why there is a need for communication_period. If the alert is in the feed, we should show it. If the agency doesn't want to show the alert, just leave it out in the feed.

Something else to consider regarding the usefulness of Communication Period is that an agency might not have staff available 24/7 to add an alert at any given moment. Such agencies may want the ability to "queue" up an alert by adding it to their feed ahead of time with a Communication Period for when they actually want it to be displayed in apps.

We are talking about GTFS-RT feeds here. Isn't GTFS-RT supposed to be generated real-time?

[skinkie]

We are talking about GTFS-RT feeds here. Isn't GTFS-RT supposed to be generated real-time?

It is, exactly at the moment that someone enters an notification, which is known from now on, but in effect at a later time.

[stevenmwhite]

A couple points to make... Let's remember that GTFS is the standard for communicating information between two systems. It is not the feature specification for the features those systems can provide.

With that in mind...

@miklcct

In my use case, there is a journey planner, and there is also a screen where you can look for routes / stations and show their timetables without planning for a journey, and you are allowed to change the date / time in that screen.

Sorry I've been slow to respond, but I agree with what @westontrillium said here about your use case. This is how I would design it, but again, if this is your product, you get to decide. There are other reasonable design patterns that could be used to accommodate the same intent.

I think that if the user is using the screen to select the date/time, then if there is a Communication Period defined and the selected date/time falls within the Communication Period, the tool should show it. If the selected date/time falls outside the Communication Period, do not show the alert. If there is no Communication Period defined but the alert is in the feed, show it.

@westontrillium

Something else to consider regarding the usefulness of Communication Period is that an agency might not have staff available 24/7 to add an alert at any given moment. Such agencies may want the ability to "queue" up an alert by adding it to their feed ahead of time with a Communication Period for when they actually want it to be displayed in apps.

People don't edit their GTFS-RT feeds directly. They use software to do so. It's totally reasonable for that software to have the "communication period" feature and use it to determine when to include the alert in the feed it produces, without us needing to have this as a field in the data spec. So I don't think that staff wanting to set up alerts ahead of when they want them communicated is necessarily a reason we have to have communication period in the spec -- it could just be a good feature of the producing application, if the spec was clear about what presence in the feed means.

In general, my support for this is around clarifying for everyone what the intent of the people publishing alerts is. In practice, these people who use software to publish alerts have shown that they intend to inform their riders about things at times that are in advance of those things having an actual impact, if they know about them in advance. They do this already by publishing alerts with active_period being greater than the actual impact period, and that confuses everyone.

I'm in support of @westontrillium's suggestion here:

• Active Period: Forbidden if Communication OR Impact Period is defined, optional otherwise
• Communication Period: Optional
• Impact Period: Optional

[tzujenchanmbd]

Since this PR and #504, it may be worth checking the meaning of "deprecate" in the context of GTFS Realtime. Here are some of my findings:

In 2014, TripDescriptor.ScheduleRelationship = REPLACEMENT was completely removed from the spec. (https://groups.google.com/g/gtfs-realtime/c/77c3WZrGBnI)

In 2018, during discussions on experimental field process, the practice of adding the [deprecated=true] tag in .proto was proposed. (#109 (comment))

In 2019, the previously "deprecated" TripDescriptor.ScheduleRelationship = REPLACEMENT was added back in .proto with the [deprecated=true] tag. The main reason for this was for backwards compatibility. (cabaec4#diff-a1a14af3b4aed7d10a3b167231b52fdb483cf71b88f1655ed2e28bccd18800ceR579)

Since this approach allows any existing consumers or producers that have implemented support to leave their code as-is, this type of "deprecate" does not seem to be considered a breaking change but rather a strong recommendation? We can also observe this tendency in the discussion of #504 (e.g., this comment).

If there is a consensus on this, we can follow the approach in #504 and include "deprecate guidance" in both the reference and .proto. @stevenmwhite @westontrillium @doconnoronca @gcamp

[skalexch]

Thank you all for your interest in this change and for your valuable feedback.

@gcamp , @doconnoronca , @stevenmwhite and @westontrillium – on deprecating active_period, please check @tzujenchanmbd 's comment above.

@stevenmwhite , @doconnoronca , and @westontrillium – your points regarding impact_period and communication_period are valid. I will make both fields optional while keeping restrictions on active_period to ensure it doesn’t interact with any new fields.

@miklcct - Restricting impact_period within communication_period (if present) seems like a good approach, so we can add it to the spec change.

Regarding the four cases you outlined, below is how they might play out. I say “might” because, as discussed, consumers determine where to display alerts in their app and how to handle them. The intent of this PR is to clarify when an alert is purely informative vs when it indicates an active impact.

Case 1: If the current time is outside the communication_period, but the trips fall within the impact_period, then they are effectively inside the communication_period as well. Consumers may choose to adjust routing suggestions accordingly and display the alert in results or details pages since it is in effect. However, if the consumer has a “current service alerts” page, the alert might not be shown there.

Case 2: If the current time is outside the communication_period, consumers may choose not to show the alert for informational purposes. Since the journeys are also outside the impact_period, they may not display an alert at all, as those journeys remain unaffected.

Case 3: If the current time is within the communication_period, but the trips are outside the impact_period, the alert can be displayed for informational purposes, though it won’t impact current trips.

Case 4: If the current time is within the communication_period, but the user searches for trips outside of it, the alert may appear on a general “current service alerts” page, but not necessarily in the journey results, this is up to the consumer’s implementation.

[ckraatz]

Sorry to be late to the conversation, which I hope I'm sufficiently caught up on to comment. As a long-time publisher of alerts within a transit agency (Santa Clara VTA) and now with a tool (SimplifyTransit Alerts) used by agencies of all sizes to publish GTFS-realtime Alerts:

• I do see agencies being confused about what the time period refers to. I always emphasize for them that it corresponds to the time range that the Effect is impacting riders. The simplest solution would be to add more clarity to the reference docs to emphasize that to feed publishers.
• I think there should only be one field - rename it impact_period if you want. No need for communication_period. It's unreasonable to expect agency staff (even at large agencies) to go through the complexity of adding multiple time ranges. As the creator of a UI to make publishing GTFS-realtime Alerts easy, that also creates unnecessary design complexity. We sometimes have dispatchers creating alerts, people who are moving very quickly, and we aim to simplify rather than complicate.
• Apps and other consumers should be responsible and free to decide when and how to display alerts, and assume that the time range (especially if there's only one, as I think is appropriate) provided corresponds to when the Effect is/will be affecting riders.

That said, SimplifyTransit also has a product that consumes GTFS-realtime Service Alerts, our Subscriptions module that sends highly personalized SMS/email alerts to riders.

• I could see Subscriptions using a communication_period, if it were provided reliably, to give more sophisticated and staffed-up agencies control over when to send SMS/email alerts or reminders. However, that use-case is even more complex. It would be great to be able to send subscribers periodic reminders as a service change approaches, for example, or when an Alert ends. But I don't see the communication_period supporting those uses cases, as proposed.

I hope that's helpful. Happy to clarify anything or fill in gaps I missed.

[laurentg]

@tzujenchanmbd

Since this approach allows any existing consumers or producers that have implemented support to leave their code as-is, this type of "deprecate" does not seem to be considered a breaking change but rather a strong recommendation?

Strongly agree with this point. At Mecatran, as a transit alert data producer for many different consumers, we have to ensure full backward compatibility for all, regardless of their support for this change. To support this new version, I see two ways of handling this:

1. produce a new "end-point" with the new version only, keeping the existing version. This would make both old and new available. With this we have to ask the consumers handling this new format to switch to a new URL.
2. produce a single data feed with the three fields present (active, communication, impact) at the same time (at least for a certain amount of time, until every consumer support the new version). This would be way easier. This feed would not be strictly following the standard however, as currently stated.

To be honest, I'd strongly prefer to follow option 2: so far the evolution of the GTFS-RT specs never forced us to version our APIs, and option 1 would require a new GTFS-RT version (this being not talked about here?). Option 2 would require to relax indeed a bit the possibility of mixing the 3 fields.

Maybe the standard could express this, to allow mixing active with impact for backward-compatibility purpose? Stating that when the two version are present at the same time, the new version taking precedence over the old one.

[phil-swiftly]

To be honest, I'd strongly prefer to follow option 2: so far the evolution of the GTFS-RT specs never forced us to version our APIs, and option 1 would require a new GTFS-RT version (this being not talked about here?). Option 2 would require to relax indeed a bit the possibility of mixing the 3 fields.

Chiming in to say that Switly is also in favour of Option 2 here, in that we see the inclusion of active_period alongside communication/impact_periods to be the simplest path for everyone in adopting this change.

[miklcct]

I think we should allow both fields, similar to the process of deprecating ADDED trips, and a migration guide added into the specification.

[ckraatz]

This proposal has grown on me! The addition of communication_period will give our customers more control over when alerts are sent via SMS/email or published on their website, which they've appreciated hearing about.

SimplifyTransit is ready to join in the testing phase if that's next, and implement if there are no major obstacles.

Maybe the standard could express this, to allow mixing active with impact for backward-compatibility purpose? Stating that when the two version are present at the same time, the new version taking precedence over the old one.

How long would we continue to have all three fields in Alerts feeds? One year? I don't think including "deprecated" fields in active feeds should go on indefinitely.

If we need to publish all three fields for backwards compatibility, SimplifyTransit would only give our customers impact_period and active_period values would be identical to impact_period. Would that be acceptable to Consumers? Any problems with that approach?

We've always trained our customers that active_period is when the Effect is impacting riders, so they'll enter impact_period the same way they enter active_period today. They won't really know the difference.

a migration guide added into the specification.

@miklcct could a "migration guide" specify a sunset date for active_period for all Producers, giving Consumers a reasonable amount of time to adapt? One year?

[laurentg]

I my experience, one year is rather short to make sure all consumer will support the new specs. I've seen in real life old systems not being updated for so long...

Sorry to go back to this, but as the real meaning of the current active_period is mixing impact + communication period (and I guess it's more impact than communication for most cases), why not keeping the current active_period, narrowing it's specification to mean impact, and only adding communication_period? (basically, the exact reverse of option 4 in the doc). Backward compatibility may be easier to ensure, and I do not really see any strong advantages of deprecating the existing one to be replaced by two new; especially here that:

• the new meaning of the existing field would be just a "better" definition of the old one,
• the common meaning of active is roughly equivalent to impact (at least to me! but I'm not a native speaker),
• if the new communication field is not present, we naturally fallback to the old specification of active (active = impact + communication).

I'm not really sure why this alternative solution has been rejected (or at least not fully discussed)?

[ckraatz]

why not keeping the current active_period, narrowing it's specification to mean impact, and only adding communication_period?

I support this perspective @laurentg. If we have to provide three fields two of them will always be identical anyway.

I also have never been confused by the primary meaning of active_period. What’s “active”? The Effect. Your reading of the connotation is correct.

If an Alert were definitely not “active,” it wouldn’t be in the feed (with very few exceptions that all point to the value of adding communication_period). Active_period has never stopped Consumers from displaying an Alert before it starts (I hope).

If Producers, Consumers and agencies need disambiguation by extracting communication_period into its own field, we can minimize impact 😉 by clarifying that “active_period” = “Effect/Impact is active.” We’ll approach it that way regardless.

[miklcct]

why not keeping the current active_period, narrowing it's specification to mean impact, and only adding communication_period?

I support this perspective @laurentg. If we have to provide three fields two of them will always be identical anyway.

I also have never been confused by the primary meaning of active_period. What’s “active”? The Effect. Your reading of the connotation is correct.

If an Alert were definitely not “active,” it wouldn’t be in the feed (with very few exceptions that all point to the value of adding communication_period). Active_period has never stopped Consumers from displaying an Alert before it starts (I hope).

If Producers, Consumers and agencies need disambiguation by extracting communication_period into its own field, we can minimize impact 😉 by clarifying that “active_period” = “Effect/Impact is active.” We’ll approach it that way regardless.

My current app will display alerts within the active period - i.e. for journey searches within the active period and timetable views when the user has selected a date/time within the active period. If outside, it won't be displayed.

If this PR goes through, I will display the alerts within the communication period, where in the alert details, the impact period is shown to the user.

[ckraatz]

@miklcct that’s perfect! You would do that regardless of when your user looks up that future journey, so you’re interpreting active_period as I understand it. That’s when the Effect is happening, but there’s no reason to hide it from riders before then and many reasons to show it to them.

I honestly think the main benefit of adding communication_period will be helping agencies control website displays and our automated SMS/email. It will likely have minimal impact on apps (in large part because many agencies won’t practically spend the time creating distinct communication_periods).

[skalexch]

@laurentg @phil-swiftly @miklcct @ckraatz Thank you everyone for your feedback.

The current definition of active_period is “Time when the alert should be shown to the user.” However, both the name and the definition can be misleading.

• As currently defined:
  “Whenever you have to show the alert to the user” -> communication_period
  Example: For recurring nightly subway shutdowns, the alert may have to be shown all day, even during operating hours, so that riders can plan ahead.

• As implied by the name:
  "active_period" suggests the time when the alert's effect is “active”-> impact_period

In other words, @laurentg's suggestion to redefine active_period as impact_period will also likely redefine the interpretation of multiple producers and consumers of GTFS who define active_period based on its spec definition. The same thing will happen if we redefine active_period to indicate communication_period and introduce impact_period.

This ambiguity and double interpretation of active_period was previously discussed in PR#482. Please refer to @sam-hickey-arcadis's comment on PR#482 that speaks about an undesired change of behavior during the migration period, a change which results from the redefinition of active_period.

Therefore, proposing two new fields is basically a departure from active_period. That’s why we propose:

• Deprecating active_period
• Adding the two new fields with clearer definitions
• Relax the constraint and allow all 3 fields to coexist. However, this might lead to cases where all 3 fields are present and have values. In that case we might recommend that data consumers use the new fields over the deprecated active_period.
• Creating a migration guide, as suggested by @miklcct, to ensure a smooth transition and to address the coexistence of the 3 fields.

We would like to hear your thoughts on this, specifically:

1. Does the rationale for introducing the two new fields and phasing out active_period make sense?
2. If one of the new fields is missing, should we allow for the use of active_period? (Our opinion is that it should be discouraged, we want to separate active_period from the new fields as much as possible without taxing the producers and having them create separate feeds)

[miklcct]

The migration guide should say that new clients should ignore active_period if at least one of the new field exists.

[felixguendling]

Is there any reason why this problem is not handled with semantic versioning like in any other versioned protocol or API? Version X deprecates the old field(s) and introduces the new field(s). Then version Y removes those previously deprecated fields after a grace period of M months/years/versions.

The producer clearly indicates which version is used, which makes it easy for the consumer to know which fields to expect. If those fields are not present, the message is not valid and will therefore be discarded. Some protocols use two versions (compatibility version + target version, names can differ) to indicate "this message targets target_version but is compatible down to compatibility_version". Therefore the consumer software can directly discard messages that are too old or too new.

GTFS-RT seems to have a version already, but it doesn't seem to be used:

transit/gtfs-realtime/proto/gtfs-realtime.proto

Lines 56 to 58 in 1540c87

	// Version of the feed specification.
	// The current version is 2.0. Valid versions are "2.0", "1.0".
	required string gtfs_realtime_version = 1;

[ckraatz]

@skalexch I'm neutral as to whether there are three fields active (impact_period and communication_period prioritized, active_period deprecated and discouraged) or a redefinition of active_period and addition of communication_period. I see your points about backwards compatibility and clarity and would vote +1 for either option.

Is there any reason why this problem is not handled with semantic versioning like in any other versioned protocol or API?

I strongly agree with @felixguendling that the deprecation and backwards compatibility dilemma's here would be resolved simply by a versioning protocol. It's not on @skalexch or any of us to solve in this PR, and requires a bigger conversation. As far as I can tell, it gets brought up but no one does anything about it.

Another angle: are there examples of technology standards/protocols/languages/frameworks used widely around the world that do not have any sort of versioning protocol? Are GTFS and GTFS-realtime alone in that? Yikes!

[skalexch]

@miklcct @phil-swiftly @laurentg @felixguendling @ckraatz Thank you for the feedback!

Regarding versioning, this topic has been previously discussed and remains a point of debate within GTFS (see PR#504 for an example). To continue the conversation, we’ve created a dedicated issue to focus specifically on versioning.

For the current proposal, I removed the “forbidden” restriction for active_period and added a migration guide explaining how to handle the three fields. Please review the migration guide and let me know if anything is missing or unclear.

[knr2000]

In Switzerland, we use SIRI-SX for the national exchange of event data.

SIRI-SX has 1.n ValidityPeriods and 0.n PublicationWindow.

In addition, there are 3 perspectives:

1. general (timetable information/routing)
2. stopPoint (passenger at the stop)
3. vehicleJourney (passenger in the vehicle)

All SIRI-SX events are then converted into GTFS SA and published centrally for the entire Swiss public transport system.

According to the proposal, a planned SIRI-SX event (e.g. a construction site) with two perspectives could then be converted or interpreted by GTFS SA as follows:

• general: The event should only be displayed in the timetable during the event duration => ValidityPeriod is converted to impact_period and only published then

• stopPoint: The event should also be displayed as advance information 3 days in advance at the stop => PublicationWindow is converted to communication_period and only published then

Unfortunately, the solution discussed here only partially solves our problem. For us, it is imperative that it be possible to map the perspectives. Otherwise, we have to provide 3 separate APIs, i.e. one for each of the 3 perspectives.

This is because the following case cannot be displayed correctly:

In practice, SIRI-SX often publishes an event with customer information for the timetable (Perspective=general / entire line / e.g. ‘Construction work on line 1’) and more specific customer information per stop (Perspective=stopPoint / e.g. ‘Due to construction work on line 6, stop XY has been moved’).
Even with the CR, it would still not be clear to recipients in which perspective an event has to be published.

[skalexch]

@knr2000 Below is a suggestion for a possible way to model the different perspectives using communication_period and impact_period.

Case 1) Perspective=general / entire line. E.g. ‘Construction work on line 1’.

In that case,
communication_period = ValidityPeriod or PublicationWindow if it exists.
impact_period = ValidityPeriod

Then

`informed_entities` = {
    `route_id` = `{route_id_line_1}`
}
`effect` = ‘NO_EFFECT` # General information provided to riders without effect on the service.

Case 2) Perspective=stopPoint. E.g. ‘Due to construction work on line 6, stop XY has been moved’.

In that case,
communication_period = PublicationWindow or ValidityPeriod - 3 days (if PublicationWindow is not present).
impact_period = ValidityPeriod

Then

`informed_entities` =  {
    `route_id` = {route_id_line_6}`, stop_id = {stop_id_XY}
}
`effect` = ‘STOP_MOVED`

I hope I understood your point. Please let me know if I missed anything.

[knr2000]

@skalexch

Thank you for your feedback.

I just realised that I made a small mistake in my example. Both events concern the same line 1.

With your suggestion, both events would be displayed to the passenger at stop_id_XY on line route_id_line_1.

And that is exactly what we want to avoid!

Only one event should be displayed in the routing system and only one event should be displayed on the display at the bus stop.

Passengers have different information needs depending on their perspective.

I hope my requirement is now clear :-)

Do you have any idea how we can solve this?

[johnhelmuth-st]

@skalexch

Thank you for your feedback.

I just realised that I made a small mistake in my example. Both events concern the same line 1.

With your suggestion, both events would be displayed to the passenger at stop_id_XY on line route_id_line_1.

And that is exactly what we want to avoid!

Only one event should be displayed in the routing system and only one event should be displayed on the display at the bus stop.

Passengers have different information needs depending on their perspective.

I hope my requirement is now clear :-)

Do you have any idea how we can solve this?

From your description and example, SIRI-SX has a single data structure (the event) with 1 to 3(?) sub-data-structures (the perspectives.) The perspectives have separate human readable messages and time periods, and (probably) share other metadata about the event, e.g. to what type of real world entity it should be applied (route/schedule signage/pages, stop signage/pages, etc.)

GTFS-RT does not have that hierarchy. Perhaps mapping the perspectives directly to the GTFS-RT service alert on a 1 to 1 basis, might solve that.

Given that... having one GTFS-RT SA with an informed_entity with the route_id only, and the other with an informed_entity with the stop_id only (and having slightly different messages about the event,) could end up with the stop contexts showing both alerts... depending on how the consuming app controlling the signage determines which alerts to display.

It might help if there was a way to group GTFS-RT alerts together to show they are applicable to the same event, adding back in the SIRI-SX hierarchy of event -> perspective.

[skalexch]

@knr2000 regarding the interpretation of different perspectives, @johnhelmuth-st's response sums it up. There is no hierarchy in GTFS-RT Service Alerts that would result in different perspective being shown at different times. Someone can create:

• Alert 1: Route perspective (route_id specified in informed_entities)
• Alert 2: Stop perspective (route_id, stop_id specified in informed_entities)
  That would result in two alerts being shown in a trip planner. "Alert 1" would be shown when the route is looked up separately, while both alerts would be shown in the journey details page, unless the consumer has an internal mechanism that filters redundant alerts.

It definitely is worth discussing ways to group alerts together. In any case, the current proposal will not address this discrepancy. The proposal might however provide a direct mapping of time periods between GTFS-RT and SIRI-SX: communication_period -> PublicationWindow, impact_period -> ValidityPeriod.

[ckraatz]

Must a GTFS-realtime data change account for how it interoperates with a completely separate and distinct data standard? I understand it could, and perhaps some would argue it should. Is this a requirement?

We haven’t had capacity yet, but we’re planning to test this because it has advantages in the GTFS-realtime paradigm. I wouldn’t support changes that make it align with another data standard AND interfere with the benefits in GTFS-realtime.

I’m more interested in making this parallel and consistent with ideas inside GTFS-realtime, like disambiguating informed_entity with communication_entity and impacted_entity fields.

To be clear, I’m all for walk-across bridges and translations between the data standards. I think there will be limits to that based on the paradigms they operate in.

[skalexch]

Hello everyone,
I'd like to confirm that we will move forward with the proposal in its current form. It seems we have general agreement at this point, so the next step is to identify producers and consumers for communication_period and impact_period.

@felixguendling , @phil-swiftly , @ckraatz , @miklcct , since you're actively working with GTFS-RT Alerts, do you have capacity to produce or consume these fields in the upcoming period?

[felixguendling]

MOTIS already has the distinction on the routing API, so I'm waiting for a producer to test this with.

[miklcct]

Hello everyone, I'd like to confirm that we will move forward with the proposal in its current form. It seems we have general agreement at this point, so the next step is to identify producers and consumers for communication_period and impact_period.

@felixguendling , @phil-swiftly , @ckraatz , @miklcct , since you're actively working with GTFS-RT Alerts, do you have capacity to produce or consume these fields in the upcoming period?

Unfortunately we are a consolidator and we don't have such data available from the operators yet, neither in GTFS or other formats, so we cannot help on this. I am not aware of any operators in Great Britain who already have such distinction, regardless of the format they use. If anyone knows that please let me know.

Furthermore, the general information provision on disruption is still very 3rd world in Great Britain. There is a requirement for local authorities in England to supply disruption data in SIRI-SX onto Bus Open Data Service but compliance is only seen in Greater Manchester. National Rail and Transport for London provide some data but they are not in any international standard, and the meanings are not 100% clear. Transport is a devolved matter in the UK so the requirement by the UK Government only applies to England, Scotland doesn't even have a National Access Point yet, and their government is still consulting on their open data requirement which lists compatibility with England as a point as well.

[felixguendling]

Since the old field is already set to deprecated = true in this PR, you can just fill the same information into both fields which I would count as "data produced". There's no requirement to fill those fields with different information and if that's all you know, setting them both to the same value is fine.

[ckraatz]

I’m excited to test and adopt this change in SimplifyTransit Alerts. We need to focus on some important backlog tasks right now, and I can’t commit to a timeline till I know those are complete.