API change re: vehicle data

[clevercommute]

My dev team reports that a change was made to the this API

https://api-endpoint.mta.info/Dataservice/mtagtfsfeeds/lirr%2Fgtfs-lirr  

Old: the value for "train ID" was found in vehicle->id field.

Now: Found here vehicle->label

Can MTA please verify?

If yes, how/when was this communicated to the dev community?

Thanks,

[Sunny]

There have been no changes made to the LIRR GTFS-RT recently.

The "id" tags in GTFS-RT entities are meant to be opaque identifiers and not to be parsed. As per specification, the association between vehicle and trip is done through the VehicleDescriptor element, which is consistent between TripUpdate and VehiclePosition entities. The "label" field is the customer-facing label, i.e. the fleet number.

[clevercommute]

Hi 

Thanks. 

Can you please help me to understand what "recently" means? (1) When was the last change? ((2) and how was it announced) 

(My developer is telling me what fields were moved, and I'm trying to get to the bottom of this. )

(3) Can you please point me to the spec you mention? 

I understand your point of view, but we may not agree. 

Any field exposed via an API is available for whatever use the user can imagine (at their own business risk) 

The user is certainly responsible for whatever they do with it, but that is not the same thing as whether or not the API provider can change that endpoint at all, let alone via unannounced change.

Not looking to dicker here. But please just share (1) and (2) and (3) so I can report to my stakeholders. 

Thank you

[clevercommute]

Hi 

Can someone from MTA please reply? 

Thanks, 

-Josh 

[clevercommute]

My stakeholders need me to trace this outage to its root cause. Please share the requested info. Thanks

[MTA Dev Reply]

As Sunny described previously, per https://developers.google.com/transit/gtfs-realtime/reference#message-vehicledescriptor, the value of this field is an internal field.

> Internal system identification of the vehicle. Should be unique per vehicle, and is used for tracking the vehicle as it proceeds through the system. This id should not be made visible to the end-user; for that purpose use the label field [emphasis added].

The MTA has not changed the industry specification, and their data has remained compliant with the specification throughout this time. The endpoint clearly defines the value you were using as an internal identifier, distinct from the user-visible `label` field. Insofar as there is correspondence between keys across fields, the structure is valid, regardless of the value's content (be it a random hex string, potato, 1234, etc.). These fields could change at random and would not warrant notice.

Per your own message, your decision to make an inference from a field's content in direct contravention of the specification was done at your own business risk.

Accordingly, please convey this as the root cause to your stakeholders.

[Disclosure: I am not an MTA representative and am speaking as a fellow member of this group frustrated by this interaction. There are plenty of opportunities for fair criticism of the MTA, but this is not one such instance. Continuing to press the issue disincentivizes the MTA to actively participate and address actual issues or discrepancies.]