@futurebird If I understand the question correctly: yes-ish. There are a few standard-ish transit data formats in use (of course it's not just one... 🙄) and they generally have some sort of notion of a unique trip identifier (or, in the case of a regular service, a unique line identifier + start time). Separately there's usually a data feed for live delay information that applies *to* the timetable, using those IDs.

I don't think it would make a lot of sense to represent this directly in ActivityPub due to sheer data volume, but what *would* make sense would be to have a 'blessed' standard for getting unique trip IDs (namespaced by transit agency) and the applicable delays for a given ID, and then encode those IDs into a special ActivityPub message type.

Implementations would still need to understand the transit feed specs to get trip/delay information (beyond static information a client chooses to include when posting), but aware clients could then extract the trip ID from the message, and query the relevant transit agency's data feed for the latest delay information and display that.

Most of the infrastructure for this already exists, I expect that the extra work would mostly involve:
1. Working out a namespaced trip ID scheme (probably just $agency:$trip).
2. Maintaining a namespace -> transit feed mapping.
3. Specifying an AP type to represent a trip ID in a message.
4. Convincing transit operators to actually make those feeds public *without* requiring API keys, especially the delay feeds.
5. Adding client support for fetching delay information.

It'd be a bit of work but I'd say it's probably achievable, especially given how many "people who work at transit agencies" probably use fedi (and so can apply internal pressure in the right places in organizations). I don't think transit agencies would need to run a *fedi server* for it, even, they just need to support it.

@joepie91 @futurebird
GTFS seems to be a relatively widespread one?

@sabik @futurebird Sort of; GTFS is essentially the format that Google demands, but it is an extremely limited format that's missing a lot of details you would find in other formats, and IIRC the identifiers are not very reliable either. It's also not necessarily public (or up-to-date), because Google allows manual periodic uploads.

NeTEx is the EU-mandated standard for EU transit operators, and is legally required to be publicly available in up-to-date form; it's similar to TransXChange which is used in the UK.

@joepie91 @futurebird
Cool, TIL!

Figures that the EU would have a this better under control 🙂

@sabik @futurebird Well, on paper anyway :P In practice it's often a challenge to actually *find* the feeds, and although they are required to be public, I don't think it forbids putting them behind an authentication wall...