Resource details
File name:
GTFS-RT Réseau PYBUS
Format: gtfs-rt
GTFS-RT pour le réseau urbain de Parthenay
This resource file is part of the dataset Réseau urbain Pybus.
Download availability
2025-08-19
99.4%
2025-08-20
99.6%
2025-08-21
99.5%
2025-08-22
99.5%
2025-08-23
100%
2025-08-24
100%
2025-08-25
100%
2025-08-26
100%
2025-08-27
100%
2025-08-28
100%
2025-08-29
100%
2025-08-30
100%
2025-08-31
100%
2025-09-01
99.8%
2025-09-02
100%
2025-09-03
100%
2025-09-04
100%
2025-09-05
100%
2025-09-06
100%
2025-09-07
99.6%
2025-09-08
100%
2025-09-09
99.7%
2025-09-10
99.7%
2025-09-11
99.6%
2025-09-12
99.7%
2025-09-13
100%
2025-09-14
99.7%
2025-09-15
99.6%
2025-09-16
99.7%
2025-09-17
99.6%
2025-09-18
100%
Learn more
We test this resource download availability every hour by making an HTTP
For SIRI and SIRI Lite feeds, we perform a
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
✅No error detected
Validation carried out using the current GTFS file and the GTFS-RT the 2025-09-18 at 09:02 Europe/Paris using the MobilityData GTFS-RT validator.
Validate this GTFS-RT nowPrevious validations
Here is a recap of all the error types encountered over the last 30 days.
Error ID | Description | Errors count | Number of occurences |
---|---|---|---|
E003 | All trip_ids provided in the GTFS-rt feed must exist in the GTFS data, unless the schedule_relationship is ADDED | 129 | 12 times (40 % of validations) |
E004 | All route_ids provided in the GTFS-rt feed must exist in the GTFS data | 129 | 12 times (40 % of validations) |
E011 | All stop_ids referenced in GTFS-rt feeds must exist in GTFS stops.txt | 1 560 | 12 times (40 % of validations) |
E028 | The vehicle position should be inside the agency coverage area. This is defined as within roughly 1/8 of a mile (200 meters) of the GTFS shapes.txt data, or stops.txt locations if the GTFS feed doesn't include shapes.txt. | 55 | 12 times (40 % of validations) |
E022 | stop_time_update arrival/departure times between sequential stops should always increase - they should never be the same or decrease. | 74 | 11 times (37 % 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 | 19 | 11 times (37 % of validations) |
W003 | a trip_id that is provided in the VehiclePositions feed should be provided in the TripUpdates feed, and a vehicle_id that is provided in the TripUpdates feed should be provided in the VehiclePositions feed | 19 | 11 times (37 % of validations) |
E047 | If separate `VehiclePositions` and `TripUpdates` feeds are provided, `VehicleDescriptor` or `TripDescriptor` ID value pairing should match between the two feeds. | 12 | 8 times (27 % 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. | 1 | 1 times (3 % of validations) |
E037 | Sequential GTFS-rt trip stop_time_updates shouldn't have the same stop_id | 1 | 1 times (3 % of validations) |
GTFS-RT feed content
Entities
Entities present in this feed at 2025-09-18 at 14:39 Europe/Paris.
vehicle_positions (0) service_alerts (0) trip_updates (0)Decoded GTFS-RT feed
See full payload
Here is the decoded GTFS-RT feed Protobuf at 2025-09-18 at 14:39 Europe/Paris. You can look at the GTFS-RT documentation.
{
"header": {
"gtfsRealtimeVersion": "2.0",
"timestamp": "1758199166"
}
}