Request for GTFS-realtime extension ID for IBI Group

[transit...@ibigroup.com]

Hi,

IBI Group would like to request a GTFS-realtime extension ID to include timestamp fields in the Service Alerts feed.

We opened a proposal to include three additional fields in the specification, which was rejected (see discussion and voting results on the pull request here: https://github.com/google/transit/pull/134)

According to the specification amendment process, if a proposal is rejected, the producer may choose to implement it as a custom extension. So we have decided to do that at this point, and are requesting an extension ID.

Please let us know if you need more information.

Thank you,

IBI Group

[Sean Barbeau]

IBI Group,

We've assigned you Extension ID 1010:

https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md#extension-registry

Thanks for going through the process!

Sean

[sm12...@gmail.com]

There already is a timestamp associated with a message alert in the GTFS-RT spec. It's not obvious but it's there.

Each feed message is composed one FeedHeader (with a required timestamp) and many FeedEntity(s). Each FeedEntity can contain an Alert. The Alert message does not contain a timestamp. However, there's still the header's timestamp. Just keep the links intact from alert to entity to header and you have the timestamp.

There should be no need for a duplicate timestamp in the alert, unless the latency between when an alert is issued and when its transmitted in the feed is important. If it is, chances are the feed rate isn't sufficiently frequent.

On Wednesday, January 30, 2019 at 12:34:41 PM UTC-5, transit...@ibigroup.com wrote:

[Stefan de Konink]

On zaterdag 2 februari 2019 19:23:58 CET, sm12...@gmail.com wrote:
> There already is a timestamp associated with a message alert in
> the GTFS-RT spec. It's not obvious but it's there.
>
> Each feed message is composed one FeedHeader (with a required
> timestamp) and many FeedEntity(s). Each FeedEntity can contain
> an Alert. The Alert message does not contain a timestamp.
> However, there's still the header's timestamp. Just keep the
> links intact from alert to entity to header and you have the

The reason they want to have a timestamp seems to be as a information
attribute as part of of a message. Similar to an extra string with "author
of the message".

So I quite understand what they want to do with it, there should just be
more details on what is should absolutely not do.

--
Stefan

[Holger Bruch]

Hi Sean,

I just saw that IBI Group was assigned Extension ID 1010. https://developers.google.com/transit/gtfs-realtime/guides/extensions currently does not reflect that information. Could you update that page or let the person in charge know?

Thanks,

Holger