Malformed delay on 4Trak feed

I’m noticing some trips are displaying a delay of around 600 thousand million years. The documentation doesn’t shed any light about this.

I’m assuming this is a bug, so I’m curious as to how we should handle these?

{
        "trip": {
            "trip_id": "V603.1480522860",
            "route_id": "4T.T.HUN",
            "start_time": "",
            "start_date": "",
            "schedule_relationship": 0
        },
        "vehicle": null,
        "stop_time_update": [
            {
                "stop_sequence": 1,
                "stop_id": "2303151",
                "arrival": null,
                "departure": {
                    "delay": 15,
                    "time": 0,
                    "uncertainty": 0
                },
                "schedule_relationship": 0
            },
            {
                "stop_sequence": 3,
                "stop_id": "2304302",
                "arrival": {
                    "delay": 18446744069414584000,
                    "time": 0,
                    "uncertainty": 0
                },
                "departure": {
                    "delay": 0,
                    "time": 0,
                    "uncertainty": 0
                },
                "schedule_relationship": 0
            }
        ],
        "timestamp": 0
    }

by letting us know :slight_smile:

We’ll try and find out what is happening.

Thanks.

Hi @jxeeno

Are you able to provide us a bit more info?

There are a few differences in structure between the GTFS output files and the sample posted.
Would it be possible to find out what trips this is occurring in and what files you are getting this value in?

Thanks
Yvonne

@yvonne.lee: Oops, upon further investigation, looks like it’s an issue with this particular protobuf library handing negative numbers. Sorry about that!

ok thanks. So we’ll close out the issue?

Yes please :slight_smile:

1 Like

@jxeeno I just encountered this exact problem. I am using this Node JS librar called “protocol-buffers”. Would this be protobuf library you mentioned by any chance? Thanks.

@hkotfnsw I don’t actually remember which library I was using, sorry! But it was definitely a Node.js library.

One solution I found for my particular library was to modify the .proto file to explicitly type the integers to signed integers:

optional int32 delay = 1;

becomes

optional sint32 delay = 1;

You can refer to the protocol buffer documentation for more data types: Encoding  |  Protocol Buffers  |  Google Developers

Thanks for the reply, modifying the proto file instead of 3rd party library sounds like a clever idea! I resolved this issue by using another library and this one seems to work well: GitHub - mapbox/pbf: A low-level, lightweight protocol buffers implementation in JavaScript.

1 Like