Resource details
This resource file is part of the dataset Réseau urbain Forbus.
Download availability
Learn more
HEAD
request with a timeout of 5 seconds. If we detect a downtime, we perform subsequent tests every 10 minutes, until the resource is back online.For SIRI and SIRI Lite feeds, we perform a
GET
request: a 401 or 405 status code is considered successful. In case of HTTP 500, the feed will be considered unavailable, unless the body appears to contain SOAP.Validation details
⚠️1 warning
Validation carried out using the current GTFS file and the GTFS-RT the 2025-04-24 at 09:02 Europe/Paris using the MobilityData GTFS-RT validator.
Warnings
Header timestamp is older than 65 seconds W008 1 error
The data in a GTFS-realtime feed should always be less than one minute old
Sample errors
- header.timestamp is 519 min 14 sec old which is greater than the recommended age of 65 seconds
Previous validations
Here is a recap of all the error types encountered over the last 30 days.
Error ID | Description | Errors count | Number of occurences |
---|---|---|---|
E051 | All stop_time_update stop_sequences in GTFS-realtime data must appear in GTFS stop_times.txt for that trip | 653 | 23 times (77 % of validations) |
W002 | vehicle_id should be populated for TripUpdates and VehiclePositions | 2 559 | 23 times (77 % of validations) |
E037 | Sequential GTFS-rt trip stop_time_updates shouldn't have the same stop_id | 535 | 22 times (73 % of validations) |
E002 | stop_time_updates for a given trip_id must be strictly sorted by increasing stop_sequence | 494 | 16 times (53 % of validations) |
E036 | Sequential GTFS-rt trip stop_time_updates should never have the same stop_sequence | 494 | 16 times (53 % of validations) |
W009 | trip.schedule_relationship and stop_time_update.schedule_relationship should be populated | 3 436 | 16 times (53 % of validations) |
E025 | Within the same stop_time_update, arrival and departures times can be the same, or the departure time can be later than the arrival time - the departure time should never come before the arrival time. | 27 | 15 times (50 % of validations) |
E022 | stop_time_update arrival/departure times between sequential stops should always increase - they should never be the same or decrease. | 2 041 | 9 times (30 % of validations) |
W008 | The data in a GTFS-realtime feed should always be less than one minute old | 9 | 9 times (30 % of validations) |
E003 | All trip_ids provided in the GTFS-rt feed must exist in the GTFS data, unless the schedule_relationship is ADDED | 32 | 7 times (23 % of validations) |
E011 | All stop_ids referenced in GTFS-rt feeds must exist in GTFS stops.txt | 1 099 | 7 times (23 % of validations) |
E045 | If GTFS-rt stop_time_update contains both stop_sequence and stop_id, the values must match the GTFS data in stop_times.txt | 3 527 | 7 times (23 % of validations) |
W001 | Timestamps should be populated for all elements | 974 | 7 times (23 % of validations) |
E004 | All route_ids provided in the GTFS-rt feed must exist in the GTFS data | 10 | 5 times (17 % of validations) |
E043 | If a stop_time_update doesn't have a schedule_relationship of SKIPPED or NO_DATA, then either arrival or departure must be provided | 5 | 5 times (17 % of validations) |
E023 | For normal scheduled trips (i.e., not defined in frequencies.txt), the GTFS-realtime trip start_time must match the first GTFS arrival_time in stop_times.txt for this trip | 2 | 2 times (7 % of validations) |
GTFS-RT feed content
Entities
Entities present in this feed at 2025-04-24 at 00:23 Europe/Paris.
vehicle_positions (0) service_alerts (0) trip_updates (0)Entities seen in the last 7 days.
trip_updatesDecoded GTFS-RT feed
See full payload
Here is the decoded GTFS-RT feed Protobuf at 2025-04-24 at 00:23 Europe/Paris. You can look at the GTFS-RT documentation.
{
"header": {
"gtfs_realtime_version": "1.0",
"timestamp": "1745446998"
}
}