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.

[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.

[ue71603]

Switzerland would also produce/consume it, if it shows up.
@skinkie : What for the Netherlands?

[skinkie]

Switzerland would also produce/consume it, if it shows up. @skinkie : What for the Netherlands?

When SIRI-SX is available we can, until then it is not part of the current travel information.

[knr2000]

In Switzerland, this may enable us to resolve the challenges associated with the SIRI-SX perspectives.

Of the current three and future four perspectives in SIRI-SX, we only want to publish the two perspectives general (timetable information) and stopPoint (monitor at the stop).

In the general perspective, an event should only be published for journeys within the impact_period.

In the stopPoint perspective, an event should only be published for journeys within the communication_period.

The alternative solution we are discussing is two separate streams for the two perspectives.

[ue71603]

As @knr2000 said, is SBB working on the implementation. We think that this might be ready for August 2026 (product increment 2026-07)

[phil-swiftly]

Swiftly is working on an implementation for this and can provide a timeline in the coming months once we have adequately scoped the work.

[sebastianknopf]

As long as VPE (Verkehrsverbund Pforzheim-Enzkreis) in Southern Germany exists, we'd also be able to adapt our implementation for testing.

Actually, we're also converting SIRI-SX to GTFS-RT ServiceAlerts. As the effect modifies the results in Google Maps (e.g. with NO_SERVICE for a certain stop leading to supress all departures for that stop), we decided to publish the message in the feed, but set active_period to the value of SIRI-SX ValidityPeriod. That also means, that we could not inform passengers in Google Maps prior to the entire event, but our other consuming systems show the information as it is published. This PR would clarify this issue.

As I am working on a complete opensource re-implementation for using it in future (even without VPE), I'd add the new proposed fields and let active_period in there for backwards compatibility.

[skalexch]

@sebastianknopf glad to hear this proposal can support you! When do you think you'll have support for those two fields?

[sebastianknopf]

I'd carefully say in around two weeks. Maybe a little earlier in my staging system with fictive alerts.

[sebastianknopf]

My staging system has the first draft installed now and exposes currently one test alert.

The matching GTFS static feed is here: https://gtfs.skc-hub.app/data/internal/static/gtfs.zip

The GTFS RT feed is here: https://echogtfs.skc-hub.app/api/realtime/service-alerts.pbf

Simply add ?json to see the output as JSON. Feel free to ask for more examples, if you need. I will internally test some things and update the prod system to the draft to see whether Google Transit also works with the extended period support with backwards compatibility in active_period.

[felixguendling]

MOTIS supports it now (part of next release).

[skalexch]

Hi everyone, any implementation updates to share?

@phil-swiftly do you have a clearer timeline for when the fields will be implemented?
@felixguendling once the feature is released in MOTIS, could you please include a link to the release notes or any examples of the feature in action?

@sebastianknopf, a couple of questions about your implementation:

• As a producer, what organization do you represent? And are you the official producer for Verkehrsverbund Pforzheim-Enzkreis?
• Is the feed you shared the complete GTFS-RT Service Alerts feed for the agency? Or just a sample of it?

[sebastianknopf]

@skalexch I'm working currently as external employee / consultant for Verkehrsverbund Pforzheim-Enzkreis. The agency is producing the GTFS data themselves, but I am responsible for the data pipeline. The agency is going to be dissolved with the end of this year, but as for now, we're still able to produce data.

What I just shared was my staging system for tests, you also can access the official OpenData offers from VPE at https://opendata.vpe.de - Here you'll see all service alerts which are also published to Google Maps.

[felixguendling]

@felixguendling once the feature is released in MOTIS, could you please include a link to the release notes or any examples of the feature in action?

It's available in MOTIS v2.10. There is no mention of it in the release notes because MOTIS always distinguished between communication period and impact period, so the only change is now that those fields are filled properly when working with GTFS and not just set to the same value. v2.10 is live on Transitous.

[skalexch]

@sebastianknopf @felixguendling Thank you both for clarifying! I set up a MOTIS instance and tried VPE's feed. The result looks great!

[skalexch]

This proposal has been implemented by:

• MOTIS (consumer) @felixguendling
• Verkehrsverbund Pforzheim-Enzkreis (producer) @sebastianknopf

We have enough to proceed. We are starting a vote to add these two fields as experimental formally to the spec.

The voting period will span 2 weeks and will end at 2026-06-25 at 23:59:59 UTC.

[felixguendling]

I am against making them experimental.

Because at the same time you kept this for the old field:

Should not be used - for backwards-compatibility only.

So now we have

• one deprecated ("should not be used")
• and two experimental

That's not a good state.

Protobuf is in this case

• upward compatible: a old client will still understand the new way as long as active_period is still provided
• downward compatible: a new client will still understand the old data as long as it still parses active_period

So the right way to proceed would be to recommend

• producers to produce all three fields
• and consumers to prioritize communication_period and impact_period but keep support for active_period
• and then remove the experimental remark (because this will just hinder adoption)

[skalexch]

@felixguendling I removed the experimental tags.

We will try to adopt this directly formally and see what the community thinks in the vote. In all cases, the migration guide makes it possible to continue producing the deprecated field.

We are also extending the vote by another week. So the voting now ends on 2026-06-25 at 23:59:59 UTC.

[felixguendling]

+1 MOTIS

[gcamp]

+1 Transit

[ue71603]

+1

[westontrillium]

+1 Optibus