Best way to be notified of changes in the JSON schema for realtime buses position feed

I have subscribed and use the realtime bus position feed in our application.
Few weeks ago, our application is not functioning and further investigation found that the JSON schema for the realtime bus position have been changes such as trip_id became tripId.

How could be the best way for us to get notified of these changes ahead of time such that we can make the corresponding changes in our application accordingly? Thanks!

Charles

Hi Charles,
We are not aware of any change on our side. Below is the output of our debug parameter https://api.transport.nsw.gov.au/v1/gtfs/vehiclepos/buses?debug=true

Are you decoding the protobuf yourself? We have our recommended proto files on our documentation page, that way you will also get extra info such as the extended vehicle descriptor which I note is missing from your example.

entity {
  id: "20052_295275599172_2449_130_1"
  vehicle {
    trip {
      trip_id: "1194616"
      start_time: "11:20:00"
      start_date: "20210816"
      schedule_relationship: SCHEDULED
      route_id: "2449_130"
    }
    position {
      latitude: -32.80816
      longitude: 151.85562
      bearing: 256.0
      speed: 23.6
    }
    timestamp: 1629081307
    congestion_level: UNKNOWN_CONGESTION_LEVEL
    vehicle {
      id: "20052_295275599172_2449_130_1"
      [transit_realtime.tfnsw_vehicle_descriptor] {
        air_conditioned: true
        wheelchair_accessible: 1
        vehicle_model: "Volvo~B7RLE~Custom Coaches~CB60"
        special_vehicle_attributes: 0
      }
    }
    occupancy_status: MANY_SEATS_AVAILABLE
  }
}

Hi David,

Thanks for responding to my query!
The following is an extract of the converted JSON output from the feed, it was obtained back in November last year (and yes, we have written a Go program to convert the protobuf to JSON). Under the vehicle.trip, attribute trip id and route id were represented as trip_id and route_id respectively. However in the more recent feed, they were shown as tripId and routeId as shown in my initial post. Hence we are looking for the best way for us to be notified changes such as these. Thanks!

"entity": [
        {
            "id": "40287_19739538_2454_690K_1",
            "is_deleted": null,
            "trip_update": null,
            "vehicle": {
                "trip": {
                    "trip_id": "1275121",
                    "route_id": "2454_690K",
                    "direction_id": null,
                    "start_time": "10:00:00",
                    "start_date": "20201123",
                    "schedule_relationship": "SCHEDULED"
                },
                "vehicle": {
                    "id": "40287_19739538_2454_690K_1",
                    "label": null,
                    "license_plate": null,
                    "tfnsw_vehicle_descriptor": null
                },
                "position": {
                    "latitude": -33.691776,
                    "longitude": 150.54533,
                    "bearing": 113,
                    "odometer": null,
                    "speed": 4
                },
                "current_stop_sequence": null,
                "stop_id": null,
                "current_status": null,
                "timestamp": "1606085060",
                "congestion_level": "UNKNOWN_CONGESTION_LEVEL",
                "occupancy_status": "MANY_SEATS_AVAILABLE"
            },
            "alert": null
        },

Charles

Hi David,

I have a second look of your sample JSON using the debug mode and noticed that it is the same as the one that I just posted that we used in our application i.e tip_id and route_id etc.

Are you aware of any renaming of attributes in the actual protobuf output such as renaming from trip_id to tripId etc?

Thanks!
Charles

debug=true does not provide json. it is a text version of protobuf. the protobuf spec contains the name of the field and not the data feed. if the field name has changed, then possibly your protobuf spec file has changed?

Thanks Jayen, in addition your JSON output may be specifying CamelCase instead of snake_case?

Regardless, to keep abreast of any data changes we make, please keep an eye on the forum here, and you can also join our public slack channel: Slack

1 Like

i see now that some feeds do have a format=json parameter and it is indeed now returning camelCase. i don’t use format=json so i can’t say if it has changed.

this is from my open proxy and i’m not currently manipulate the response: https://share.smartcitiestransport.com/api.transport.nsw.gov.au/v1/gtfs/alerts/all?format=json

the official .proto file has underscore: GTFS Realtime Protobuf  |  Realtime Transit  |  Google Developers

if both the Go package and api.transport.nsw.gov.au have changed, then it is likely google have changed their Go/Java bindings in their protobuf library/compiler to convert snake_case to camelCase. but it seems odd that both of you would have updated/recompiled at the same time without noticing the change.