[leonardehrenfried]

Summary

Add a few files to allow attaching notices to the following entities:

• trip
• segments of a trip
• route
• stop

Notices are short messages that provide additional non-structured information about a the entity.

Describe the Problem

The problem is described in #620

Use Cases

To add additional custom messages to passengers that do not fit into other places in the specification.

Examples:

• "Bike reservation recommended"
• "Special Train - Dedicated fare is required"
• "Express Bus - Please note the special trip times"
• "Seasonal Trip - Runs during the XYZ festival"
• "Dining car available"
• "Pre-booking required for bicycle conveyance"

In apps this shows up like this:

Proposed Solution

I added three files:

• notices.txt
• notice_assignment.txt
• trip_segments.txt

The first two allow you to create and assign the messages to the relevant entities.

The third is a new type of entity, a "trip segment". It allows you to define parts of a trip that you can then apply a notice to. This is useful if the message doesn't apply to the entire trip.

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

GTFS Realtime

• Specification Change
• Specification Change (Experimental Field)

Additional Information

Proposed Discussion Period

I recommend reserving at least one month for discussion to ensure everyone has sufficient time to discuss the proposal.

Testing Details

• Consumer(s): OTP, MOTIS (tbc)
• Producer(s): MBTA (tbc)
• Estimated Testing Period: 6 months

Proposal Update Tracker

Date	Update Description
2026-05-21	Initial version

Checklist

• I have read and understood the GTFS Change process.
• I have read and understood the GTFS Guiding Principles.
• I understand the Role of Advocate and the Responsibilities attached to it.
• I have signed the Contributor License Agreement (CLA).
• I have ensured that this proposal is not covered by an existing Pull Request.

cc @sebastianknopf @alec-georgoff

[sebastianknopf]

If this is interesting for you, I actually convert GTFS data from raw ISA (a widely used proprietary format defined by IVU Traffic Technologies), which also contain notices. I could extend this converter for also rendering the notices according to this draft here. Just give me a sign.

[leonardehrenfried]

Well, at some stage we need some real data to implement this. If you are interested in producing it, that would be great.

I have to read up how to move this proposal into the testing stage but since discussion appears to have died down, I think I am calling a vote to test soon.

[leonardehrenfried]

So far I have only received heart emojis but no comments, presumably because we have disscussed this quite a bit in #620.

Therefore I would like to move forward by getting a maintainer for this proposal. Can someone provide a hint how I get one?

I myself can be the advocate as well as a consumer contributor with OTP. It sounds like @felixguendling might be a consumer, too.

What I am looking for is a producer advocate. @sebastianknopf and @jfabi have indicated that they can provide data for it. Are you interested in the role?

[sebastianknopf]

I think, the main discussion is already done in #620. In my option this is mainly a consumer driven topic and all representatives of consumers have mentioned their implications and we found a good solution.

I have a converter isa2gtfs which could be extended easily to generate some GTFS data according to this spec. Do you have a certain time, when you prefer to have the testing data? So I could spend some energy into generating some sample data.

[leonardehrenfried]

Well, there is a north American agency that is interested in producing data for it, but I suspect it will take them a few month to actually get around to doing it.

If you're faster than that, I would love to implement your feed.

[sebastianknopf]

I'm in the implementation yet. However, I found some restrictions in the base data:

• If have no data for generating trip_segments.txt automatically. I could only create some trip segments manually for testing.
• I also have no data for stop-assigned notices. I also could create manually, if needed.
• I have some 'general notices' in the data, which would be mapped to the routes then, as they're related to the routes at all.

I hope thats fine for you anyway. All other notices which will be generated are related to trips. I think, I will be ready until next week with the implementation of the converter.

[sebastianknopf]

Here you go... https://opendata.vpe.de/gtfs_notices.zip Was a little faster than I thought. This feed is a derivate of the Verkehrsverbund Pforzheim-Enzkreis GTFS feed. You can use if for testing as long as VPE is still existing. If you need an adaptions, just tell me, I'll try my best. The feed contains:

• Notices related to trips
• General notices related to routes

If you need additional realtime data, just take a look at opendata.vpe.de.

[leonardehrenfried]

Thanks, @sebastianknopf. I will use that to build an implementation for OTP.

Regarding the missing notices for trip segments and stops: My current design makes it easy to add them later should we not be able to find a data producer for them. Therefore I'm relaxed about that.

[leonardehrenfried]

So far we have myself as the advocate and data consumer and @sebastianknopf as the data producer.

What I need is a maintainer. How do I get one @etienne0101?

[tzujenchanmbd]

Sorry for joining the discussion a bit late.

As mentioned in #620, some data producers currently use Service Alerts to communicate this type of information. Could we add language directly to this proposal to clarify the distinction between the two, similar to what @sebastianknopf mentioned here?

[leonardehrenfried]

@tzujenchanmbd I adjusted the language a bit.

[leonardehrenfried]

@etienne0101 @tzujenchanmbd Can any of you be the maintainer? Is that required to start a vote to test?

So far no-one has committed to produce data for stops or trip segments, so I'm leaning towards leaving that out of the first vote.

[etienne0101]

Hi @leonardehrenfried
Thank you for moving this proposal forward.

According to the new governance, this functional change requires an official review period, and two votes.

• The review period is at least one week. Despite having started the review here, there needs to be an officially announced review period for any final changes. You can start and announce it now.
• After that, the first vote is called to allow for testing the change.
• If the vote passes, we proceed to the testing phase.
• The second vote happens after the testing phase and leads to adoption when it passes.

We can be the maintainer and assist you through the process.

[leonardehrenfried]

I hereby announce the review period for this proposal.

Like that?

[leonardehrenfried]

I was asked to add the following: This review period will end on Thursday, June 18th at 23:59 UTC, after which we'll initiate a vote to test.

[ffisherBART]

I'm a proponent of including pathways as another entity to consider to allow this for. (and extending alerts to be assigned to pathways) Conceptually, that should be even more straightforward than creating a new trip_segment entity.

[leonardehrenfried]

@ffisherBART Great. Will you be able to create data for it when the time comes?

[leonardehrenfried]

Experimental support under review in OTP: opentripplanner/OpenTripPlanner#7726

[tzujenchanmbd]

Suggestion to align the wording commonly used in the community.

[felixguendling]

The governance document says:

First Adopters must apply, test, and share changes in a public-facing environment:

• a link to a public-facing GTFS feed for Producers
• a public-facing link to a GTFS consuming application for Consumers.

I think an API endpoint fulfills this requirement "a public-facing link to a GTFS consuming application" 100%.

Same here: #546 (comment)

For MOTIS, I would usually wait for a release to announce that a new feature was added (as features on the development branch might still change significantly): #546 (comment)

[leonardehrenfried]

Metro Transit (Minneapolis) were kind enough to publish a feed for spec verification: https://svc.metrotransit.org/mtgtfs/next/GTFS_OTP.zip

Since we are getting closer to a vote, I would like to have a discussion about the following points:

Notice groups & stop notices

So far I have not found a feed that contains notice groups or notices assigned to a stop. Can they stay in this proposal or should they be taken out?

Trip segments

I only have data about individual stop_times, not actual segments. This means that from_stop_sequence and to_stop_sequence are identical.

I would like to be crystal clear about what exactly a segment is: does it apply to the visit at the stop and the hop in between them or just to the hop. In such a case we have to redesign a little and create a separate entity for an individual stop time.

I am asking this, because I think this will be used for things like "dining car open from stop A to B". In the current definition the dining car will be open the second we arrive at stop A, when in reality it's probably not.

It's not a huge issue, so we can also agree to live with a bit of ambiguity.

[felixguendling]

I'm not sure if that helps, but I would start from a use case perspective: Is it clear which notices should be displayed for

• departure and arrival boards
• full trip
• trips inside a journey, so only a partial trip (from departure of enter stop to arrival at exit stop)

Given that a trip segment covers always the interval from departure to arrival [dep, arr], this does not make sense for a stop. So a definition for a notice that covers one stop would have to invert it to [arr, dep]. This would still not allow to set a notice to only [arr, arr[ or only the departure [dep, dep[. Maybe I miss something, but I think this is currently not covered by the spec because the spec uses stop and not event granularity. Not sure if it's worth it to change that.

Notice groups & stop notices

It's mostly a measure to keep feeds with many repetitive notices compact but if that's not important, we can also remove it. But since it's a feature that would be hard to add once implementations support ungrouped notices, we would probably have to live with larger feeds.

[leonardehrenfried]

I think the usecases "full trip" and "partial trip" can be successfully implemented, but I'm not sure the proposal is good for the "departure board" case.

Here are a few ideas how to tackle it:

1: Change definition

When from_sequence_number and to_sequence_number are identical it means that it applies to a stop_time (stop visit) only and not a segment of the trip.

Not a lot of work, but smells a bit.

2: Allow assignment to an individual stop_time

Perhaps by writing a new column to stop_times that allows you to reference a notice or notice group.

Feels a bit inconsistent because the rest goes through notice_assignment.

3: Add information to trip_segment

Allow specifying that a trip segment is actually not a "segment" but refers to an individual stop visit.

This could be done by adding more columns to trip_segments.

I will be doing a bit of thinking - perhaps I have other ideas. If anyone else has, I am all ears.

[leonardehrenfried]

I had a think over the weekend and I believe it's cleanest to allow assignment of a notice to an individual stop time rather than trying to combine the two use cases - stop time, trip segment - into a single entity.

I will therefore explore ways to assign a notice to an individual stop time.

Here are the ideas I have so far:

1. Add an ID to the stop_time file. This feels like the cleanest solution but adding another column to a very large file has some costs.
2. Adding a column to notice_assignments to it would be something like table_name=stop_times, record_id=trip-1, stop_sequence=10. What I don't like about this is, that it mixes several layers of abstraction.

Currently I lean towards number 1 but of course I'm interested in comments.

This would also mean that I would remove the trip_segments from this proposal since there is not data producer that actually has some data for it.

[felixguendling]

Not a lot of work, but smells a bit.

Maybe I missed something but what speaks against from_stop_sequence == to_stop_sequence <=> notice applies to this stop?

Why does it smell? IMO it's a clear definition for a case that would otherwise not make sense. What downsides do you see that would bite us in the future?

[leonardehrenfried]

What I don't like about this is that we change what is being targeted, namely we change from "part of a trip in between stop A and B" to "boarding or alighting at stop A".

Although you could argue that "boarding and alighting at stop A" is part of the trip... i don't know. You seem to think it it's fine, @felixguendling, correct?

[felixguendling]

You seem to think it it's fine, @felixguendling, correct?

Yes. I think about a trip not as a sequence of stops but a sequence of events of arrivals a and departures d. So a trip is adad....

• a segment would be e.g. ada[dadada]dadad
• a stop would be adad[ad]adadadad

The only option this proposal lacks would be to assign a notice to a single event but I think that's fine.

What I don't like about this is that we change what is being targeted

If you look at it on a event level, you always target a sequence of two or more events which to me is "consistent enough".

---

I also think that the other options make it more complicated than just adding a new semantic to a field we want to have anyway.

[leonardehrenfried]

What do you think of these refinements to the text: 9e58525

[felixguendling]

What do you think of these refinements to the text: 9e58525

Nice! 👍

[leonardehrenfried]

Okay, I think we are getting ready for a vote.

@skalexch Can you please verify that all conditions have been met?

[tzujenchanmbd]

Passenger UI

We (MobilityData) recommend including passenger UI, though we think it is not mandatory at the moment. Since GTFS is primarily passenger-facing, UI help community members easily understand how data could be presented to passengers. We will try to include UI(screenshot) in all proposals MobilityData advocates for before calling a vote, and may propose a governance clarification. However, until explicitly added to governance documentation, we don't view this as a hard blocker for opening a vote.

Notice groups & stop notices

Based on the principle that "GTFS additions must be tested," if the components are not included in producer test data (and corresponding consumer outputs), we would recommend removing them or deferring the vote until they are properly tested.

Thoughts we received during Mobility Data Summit:

1. Boundary between structured and plain-text data:
   For example, producers may want to put transfer or facility info in notices. However, transfer details should probably be modeled in transfers.txt, and facility info could belong in current proposals for vehicle / station facilities. The current statement — "It should not replace machine-readable information like pick up/drop off types or fare data" — seems to capture this, but could we make this constraint clearer or broader? For example: notices must not replace or duplicate machine-readable information that is already modeled (or meant to be modeled) in existing GTFS files.

Conceptually, plain-text supplementary information has value, but we probably want to avoid disincentivizing standardized structured data?

2. Display constraints for display_text:
   Related to the point above, to prevent notices from becoming difficult for passengers to read, would adding a character limit to display_text be helpful?

[leonardehrenfried]

Thanks @tzujenchanmbd.

The passenger UI will be available soon, so perhaps lets wait for this.

I have removed stop notices and notice groups - can you live with this @felixguendling?

I also applied your suggestion about not replacing machine-readable information.

Now about the limits for display_text: I'm having a hard time to come up with a limit that is both meaningful but would also not lead to genuine text being truncated. Do you have a suggestion?
My favourite solution to this problem would be to add a URL field that allows data producers to link to some long-form explanation. I hope this would be encouragement enough to not make it "too long".

[felixguendling]

Stop notices are defining something that's undefined now. Adding them should not be a big deal.

Adding groups later would require a new PK which will cause the same problem like service_id in transfers.txt #659. So I would guess that dropping them now will make it way more complicated to add them in the future once implementations support this PR. My guess is that they will never be added. But if nobody wants to produce them, that's probably the only way forward. Don't blame me though when feeds are bloated with redundant notices - at least I tried :D

[tzujenchanmbd]

Thanks @leonardehrenfried!

Regarding the limit for display_text, here are two options we consider:

1. Recommending a character limit, same approach as the current route_short_name description. (E.g. should be no longer than 250 characters)
   However, simple character counts don't account for the difference in information density between CJK (East Asian) and Latin scripts. We’ve previously received feedback that the 12-character recommendation for route_short_name isn't ideal for East Asian scripts.

2. Using a Byte-length limit (e.g., should not exceed 256 bytes in UTF-8)
   This factors in script differences without needing language-detection.

If we can agree on an acceptable threshold here, having a corresponding Notice in the GTFS Validator could be a good way to prevent overly long texts. Adding a URL field for detailed explanations could also be a good approach.

[felixguendling]

For apps to be able to display icons like in the screenshot, it would help to add an enum of commonly used values similar to the stop amenities or Service Alerts (cause + effect) in #608.

In apps this shows up like this:

HRDF uses two-letter codes for this.

[leonardehrenfried]

Categories/icons are a nice feature but I have no-one producing that data and I fear that defining them will lead to a lot of bike shedding.

[skalexch]

responding to @leonardehrenfried 's requirements question: looking at the data from Metro Transit and your API response, the requirements should be met.
As @tzujenchanmbd mentioned, we recommend UI just to further showcase the value of the addition.

Also, I think the we should further explore the conversation on whether we can set an exact limit for notice length. Both to give riders concise information and to prevent abusing the feature. It helps on our side by introducing validations on notice lengths.

[leonardehrenfried]

@skalexch I have added a size limitation to 500 characters as I found 250 too short. Happy to discuss if you think otherwise.

[leonardehrenfried]

This is a text with 500 characters.

Due to construction work on Main Street, this bus does not serve the stops Market Square and City Hall. Please use the temporary stop on Oak Avenue, about 200 metres away. Riders with reduced mobility can call 555-0123 for a free accessible shuttle. On weekends, the shuttle runs every 30 minutes between 8 am and 8 pm. Bicycles are not allowed on this bus during the construction period. Tickets bought from the driver are valid on the shuttle. The works are expected to last until the end of June.

Do you feel that this is too long?

You could argue that these are multiple notices.

[leonardehrenfried]

I changed my mind. I think 250 chars is ok - you can always use several notices and in most UIs this will probably look nicer anyway.

[sebastianknopf]

This is a text with 500 characters.

Due to construction work on Main Street, this bus does not serve the stops Market Square and City Hall. Please use the temporary stop on Oak Avenue, about 200 metres away. Riders with reduced mobility can call 555-0123 for a free accessible shuttle. On weekends, the shuttle runs every 30 minutes between 8 am and 8 pm. Bicycles are not allowed on this bus during the construction period. Tickets bought from the driver are valid on the shuttle. The works are expected to last until the end of June.

Do you feel that this is too long?
You could argue that these are multiple notices.

Without wanting to discussion to be blocked here, but is this not a classical use case for a service alert? I'd expect the notices to be much shorter, with an additional information not already available in machine-readable way, like "ExpressBus - Not stopping between A street and B street! Use line 900 to access this stops." Or did I get something wrong here?

[leonardehrenfried]

Yeah, I have now set a limit of 250 characters.

[skalexch]

@leonardehrenfried I agree with you on the limit. And with @sebastianknopf ; the first part of that example is a service alert. I think the notice is/ the notices are:

Riders with reduced mobility can call 555-0123 for a free accessible shuttle (can also be part of booking_rules.message). ... Bicycles are not allowed on this bus during the construction period. Tickets bought from the driver are valid on the shuttle.