VehicleID in SL GTFS-RT stream
Hello Trafiklab,
When using the GTFS-RT stream for the SL operator, I spotted a possible inconsistency in vehicleIDs. The two messages below are received a few seconds apart, one is a TripUpdate, the other is a VehiclePosition. Both messages relate to the same trip. However, the vehicle IDs are different (very similar though) .
***** VEHICLE message *****
entity {
id: "497325680697016461"
vehicle {
trip {
trip_id: "14010000640016551"
schedule_relationship: SCHEDULED
}
position {
latitude: 59.2439766
longitude: 17.8141823
bearing: 93
speed: 0
}
timestamp: 1696408482
vehicle {
id: "9031001001003679"
}
}
}
***** TRIP_UPDATE message *****
entity {
id: "14010515410716190"
trip_update {
trip {
trip_id: "14010000640016551"
start_date: "20231004"
schedule_relationship: SCHEDULED
}
{...stop_time_updates omitted for clarity ...}
vehicle {
id: "9031001000103679"
}
timestamp: 1696408220
}
}
Note the resemblance between the two vehicle IDs: 9031001001003679 / 9031001000103679 ... still they are different, and that is unexpected to me.
What's your opinion about this ?
When using the GTFS-RT stream for the SL operator, I spotted a possible inconsistency in vehicleIDs. The two messages below are received a few seconds apart, one is a TripUpdate, the other is a VehiclePosition. Both messages relate to the same trip. However, the vehicle IDs are different (very similar though) .
***** VEHICLE message *****
entity {
id: "497325680697016461"
vehicle {
trip {
trip_id: "14010000640016551"
schedule_relationship: SCHEDULED
}
position {
latitude: 59.2439766
longitude: 17.8141823
bearing: 93
speed: 0
}
timestamp: 1696408482
vehicle {
id: "9031001001003679"
}
}
}
***** TRIP_UPDATE message *****
entity {
id: "14010515410716190"
trip_update {
trip {
trip_id: "14010000640016551"
start_date: "20231004"
schedule_relationship: SCHEDULED
}
{...stop_time_updates omitted for clarity ...}
vehicle {
id: "9031001000103679"
}
timestamp: 1696408220
}
}
Note the resemblance between the two vehicle IDs: 9031001001003679 / 9031001000103679 ... still they are different, and that is unexpected to me.
What's your opinion about this ?
Följ inlägget
2
följare
We pass these ids directly from the operator into our open data streams, so in this case it seems to be something going wrong at SLs side if it's not an issue in our data format conversion. We've seen some other issues with the speed of certain SL busses as well, and will contact SL regarding this.
Regards,
Bert
Are you still seeing these erroneous ids? We have checked throughout the day and are not seeing this incorrect behaviour anymore.
Regards,
Bert
Hi Bert,
Thanks for looking into this. The problem is not very easy to spot, but I have run a new test this morning and am still seeing it.
Regards,
Guillaume.
We have now checked our systems and discussed this issue with SL. The cause lies in some legacy realtime reporting systems which will be replaced in the future.
In the meantime, you can replace "001" for digits 9-11 (9031001000103679) to "010", since "001" should never occur on that position.
SL will check if they can fix this issue on their side already before the systems are replaced.
Regards,
Bert
A few questions about the workaround you suggest:
- can it be applied to all TripUpdates provided for the "sl" operator?
- could the same problem occur for other operators?
- do you have any information about the timeline of the actual fix by SL?
Regards,
Guillaume.
- Yes, it can be applied to all vehicle ids in SLs TripUpdates feed
- No, this is a specific issue linked to the services at SL which generate this data
- We do not have an ETA on when this will be fixed definitely.
Regards,
Bert