Avoiding duplicate teal-time positions with tfnsw_vehicle_descriptor


Hi - I’m working with the real-time public transport API in the context of a Node.js application and my app is successfully returning data which I am decoding using gtfs-realtime-bindings. All good - except I am hitting an issue previously discussed on this forum of duplicate entries for (say) a ferry with identical coordinates, speed etc with different unique ids.

I believe I need to be using the TfNSW’s custom extension of "tfnsw_vehicle_descriptor: to provide a value that can differentiate these multiple returns and pick only the most recent one. I have the .proto file that defines that extra piece, but I’m stuck figuring out how to have the.proto file used in the dedcoding of the procotl buffer data coming from the API.

In my current code that uses gtfs-realtime-bindings, I don’t see an option to specify an alternate decoding “recipe” in the decode operation on.

var feed = GtfsRealtimeBindings.FeedMessage.decode(body);

That works fine, and I can see all the standard elements of the GTFS FeedMessage And FeedEntity but I don’t have access to the data that I need that is TfNSW specific.

So I started to explore using the lower level protobuf.js approach which looks like I can specify the .proto file prior to executing the decode - but I can’t find an example of doing that that is unambiguous - I’m trying something like this:-

var translate = protobuf.loadProtoFile("/tfnsw.proto");
var feed = translate.nested.transit_realtime.FeedMessage.decode(body);

Can anyone help with the simplest Node.js way to get from received protobuf request to decoded FeedMessage with the TfNSW addition in the result?

Any input much appreciated.



Hi Josh, I don’t believe GTFSReatlimeBindings can handle customised GTFS extensions. I ended up using Pbf to get the tfnsw-vehicle-descriptor. Apparently it has better performance as well. HTH.


Hi Henry - thanks for that - just what I needed.