Elizabeth Sall

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > While there is no character limit for service alerts, transit riders will often be viewing alerts on mobile devices. Please be concise. ### Considerations...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > Maintain persistent identifiers (id fields) within a GTFS Realtime feed (e.g., FeedEntity.id, VehicleDescriptor.id, CarriageDetails.id) across feed iterations. ### Considerations - This should really be...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > For trips denoted in [GTFS frequency.txt](https://gtfs.org/reference/static/#frequenciestxt) as frequency-based by setting exact_times=0 or omitting the exact_times field In [TripUpdate.StopTimeUpdate](https://gtfs.org/realtime/best-practices/#StopTimeUpdate), schedule_relationship should be UNSCHEDULED. (e.g., re-enforcement...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > If an alert affects all stops on a line, use a line-based alert instead of a stop-based alert. Do not apply the alert to...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > When canceling trips over a number of days, producers should provide TripUpdates referencing the given trip_ids and start_dates as CANCELED as well as an...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > The web-server hosting GTFS Realtime data should be configured to correctly report the file modification date (see HTTP/1.1 - Request for Comments 2616, under...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > Feeds should provide protocol buffer-encoded feed content by default when queried via an HTTP request at the given URL - consumers should not need...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > TripUpdate.delay should represent schedule deviation, i.e., the observed past value for how ahead/behind schedule the vehicle is. Predictions for future stops should be provided...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > StopTimeUpdate: Provide `stop_sequence` whenever possible, as it unambiguously resolves to a GTFS stop time in `stop_times.txt` unlike `stop_id`, which can occur more than once...

### Relevant [Best Practice](https://gtfs.org/realtime/best-practices/) text: > * Provide VehiclePosition.vehicle.trip > * Provide VehiclePosition.vehicle.trip_id > * Provide VehiclePosition.vehicle.start_time > * Provide VehiclePosition.vehicle.vehicle.start_date > * Provide VehiclePosition.vehicle.schedule_relationship > * Provide VehiclePosition.vehicle.position >...