完整行程更新示例
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
以下示例是完整数据集的行程更新 Feed 的 ASCII 表示法。
如需详细了解如何构建行程更新 Feed,请参阅使用 TripUpdates
提供实时行程信息。
# header information
header {
# version of speed specification. Currently "2.0"
gtfs_realtime_version: "2.0"
# DIFFERENTIAL is unsupported. use FULL_DATASET only
incrementality: FULL_DATASET
# The moment where this dataset was generated on the server.
timestamp: 1656230726
}
# A definition (or update) of an entity in the transit feed.
# Multiple entities can be included in the feed.
# be sure to provide information about EVERY active trip on every feed update
entity {
# unique identifier for the entity within the feed update message
id: "simple-trip"
# "type" of the entity
trip_update {
# a descriptor that identifies an instance of a GTFS trip
# defines the identifier of a trip in reference to the trips.txt file
# it is recommended to provide trip_id, which should be one of the following
# (1) a trip defined in the static feed
# (2) a duplicate trip with schedule_relationship ADDED and new start time
# (3) a frequency based trip with a clearly defined start time
trip {
# the trip_id from the GTFS feed that this trip refers to
trip_id: "trip1"
# the start time of this trip instance as specified from the GTFS feed
start_time: "14:05:00"
# the start date of this trip instance
start_date: "20220628"
# The relation between this trip and the static schedule
schedule_relationship: SCHEDULED
# the route id from the GTFS feed that this trip belongs to
route_id: "ROUTE1"
# the direction_id from the GTFS feed that this trip refers to
direction_id: 0
}
# schedule information update
stop_time_update {
# this must be the same as in stop_times.txt in the GTFS feed
# if stop_id is unique within the trip, use either stop_sequence or stop_id
# if a stop_id appears more than once within the trip, use stop_sequence and optionally stop_id
stop_sequence: 3
# vehicle's arrival time
arrival {
# delayed by 5 seconds
# with respect to the arrival time defined in static feed
delay: 5
}
departure {
# delayed by 5 seconds
# with respect to the departure time defined in static feed
delay: 5
}
}
# this stop’s delay is propagated to subsequent stops
# until the upcoming stop with realtime schedule defined
# i.e. stop 4 - 9 will have 5 seconds delay
# update on the vehicle's schedule for stop sequence 10
stop_time_update {
stop_sequence: 10
# dynamically assign a new platform by providing its stop_id
# together with the stop_sequence
# the new platform assigned must be part of the same station
# as the original stop/platform
stop_id: platform_id_123
arrival {
# with the default delay of 0 (on time)
delay: 0
}
}
stop_time_update {
stop_sequence: 11
arrival {
# the time of arrival in seconds after epoch
time: 1656230830
}
departure {
# the time of departure in seconds after epoch
time: 1656230890
}
}
stop_time_update {
stop_sequence: 11
# the stop is skipped, i.e. the vehicle will not stop at this stop
schedule_relationship: SKIPPED
}
stop_time_update {
stop_sequence: 12
arrival {
# negative delay means vehicle is 2 seconds ahead of schedule
delay: -2
}
}
}
}
# second entity containing update information for another trip
entity {
id: "2"
trip_update {
trip {
# the trip_id from the GTFS feed that this added trip is duplicated after
trip_id: "trip2"
# the start time of the new added trip instance
start_time: "14:05:00"
start_date: "20220628"
# use “ADDED” to specify an extra trip that was added in addition to
# a running schedule
schedule_relationship: ADDED
}
stop_time_update {
stop_sequence: 1
arrival {
# It's recommended to provide an absolute timestamp
# for easy calculation of relative time
time: 1656239890
}
}
}
}
# third entity containing update information for a canceled trip
entity {
id: "3"
trip_update {
trip {
trip_id: "trip2"
start_time: "14:05:00"
start_date: "20220628"
# use “CANCELED” to specify a trip that existed in static GTFS but was canceled
schedule_relationship: CANCELED
}
}
}
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eThis document provides an example of a full-dataset Trip Update feed in the General Transit Feed Specification Realtime (GTFS-realtime) format.\u003c/p\u003e\n"],["\u003cp\u003eThe feed uses the \u003ccode\u003eFULL_DATASET\u003c/code\u003e incrementality, requiring information about every active trip on each update.\u003c/p\u003e\n"],["\u003cp\u003eTrip updates include details like trip and route IDs, start times, delays at specific stops, and platform changes.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eschedule_relationship\u003c/code\u003e can be used to indicate if a trip is \u003ccode\u003eSCHEDULED\u003c/code\u003e, \u003ccode\u003eADDED\u003c/code\u003e, or \u003ccode\u003eCANCELED\u003c/code\u003e compared to the static GTFS schedule.\u003c/p\u003e\n"],["\u003cp\u003eStop time updates provide arrival and departure information, including delays (positive or negative) and absolute timestamps.\u003c/p\u003e\n"]]],["This ASCII data represents a full-dataset Trip Update feed with three entities. The header specifies the `gtfs_realtime_version` as \"2.0\" and `incrementality` as `FULL_DATASET`, with a timestamp of 1656230726. The first entity updates \"trip1\" with a 5-second delay at stop sequence 3 and a new platform at stop sequence 10, arrival at 1656230830 for stop sequence 11. The second entity adds \"trip2\", also starting at 14:05:00, with an arrival time of 1656239890 at stop 1. The third entity cancels \"trip2\".\n"],null,["# Full Trip Update example\n\nThe following example is an ASCII representation of a full-dataset Trip Update\nfeed.\n\nFor more details on how to construct a Trip Update feed, see [Provide realtime\ntrip information with `TripUpdates`](https://support.google.com/transitpartners/answer/10105040). \n\n # header information\n header {\n # version of speed specification. Currently \"2.0\"\n gtfs_realtime_version: \"2.0\"\n\n # DIFFERENTIAL is unsupported. use FULL_DATASET only\n incrementality: FULL_DATASET\n\n # The moment where this dataset was generated on the server.\n timestamp: 1656230726\n }\n # A definition (or update) of an entity in the transit feed.\n # Multiple entities can be included in the feed.\n # be sure to provide information about EVERY active trip on every feed update\n entity {\n # unique identifier for the entity within the feed update message\n id: \"simple-trip\"\n\n # \"type\" of the entity\n trip_update {\n # a descriptor that identifies an instance of a GTFS trip\n # defines the identifier of a trip in reference to the trips.txt file\n # it is recommended to provide trip_id, which should be one of the following\n # (1) a trip defined in the static feed\n # (2) a duplicate trip with schedule_relationship ADDED and new start time\n # (3) a frequency based trip with a clearly defined start time\n trip {\n # the trip_id from the GTFS feed that this trip refers to\n trip_id: \"trip1\"\n # the start time of this trip instance as specified from the GTFS feed\n start_time: \"14:05:00\"\n # the start date of this trip instance\n start_date: \"20220628\"\n # The relation between this trip and the static schedule\n schedule_relationship: SCHEDULED\n # the route id from the GTFS feed that this trip belongs to\n route_id: \"ROUTE1\"\n # the direction_id from the GTFS feed that this trip refers to\n direction_id: 0\n }\n\n # schedule information update\n stop_time_update {\n # this must be the same as in stop_times.txt in the GTFS feed \n # if stop_id is unique within the trip, use either stop_sequence or stop_id\n # if a stop_id appears more than once within the trip, use stop_sequence and optionally stop_id\n stop_sequence: 3\n # vehicle's arrival time\n arrival {\n # delayed by 5 seconds\n # with respect to the arrival time defined in static feed\n delay: 5\n }\n departure {\n # delayed by 5 seconds\n # with respect to the departure time defined in static feed\n delay: 5\n }\n }\n\n # this stop's delay is propagated to subsequent stops\n # until the upcoming stop with realtime schedule defined\n # i.e. stop 4 - 9 will have 5 seconds delay\n\n # update on the vehicle's schedule for stop sequence 10\n stop_time_update {\n stop_sequence: 10\n # dynamically assign a new platform by providing its stop_id\n # together with the stop_sequence\n # the new platform assigned must be part of the same station \n # as the original stop/platform\n stop_id: platform_id_123\n arrival {\n # with the default delay of 0 (on time)\n delay: 0\n }\n }\n stop_time_update {\n stop_sequence: 11\n arrival {\n # the time of arrival in seconds after epoch\n time: 1656230830\n }\n departure {\n # the time of departure in seconds after epoch\n time: 1656230890\n }\n }\n stop_time_update {\n stop_sequence: 11\n # the stop is skipped, i.e. the vehicle will not stop at this stop\n schedule_relationship: SKIPPED\n }\n stop_time_update {\n stop_sequence: 12\n arrival {\n # negative delay means vehicle is 2 seconds ahead of schedule\n delay: -2\n }\n }\n }\n }\n\n # second entity containing update information for another trip\n entity {\n id: \"2\"\n trip_update {\n trip {\n # the trip_id from the GTFS feed that this added trip is duplicated after\n trip_id: \"trip2\"\n # the start time of the new added trip instance\n start_time: \"14:05:00\"\n start_date: \"20220628\"\n # use \"ADDED\" to specify an extra trip that was added in addition to \n # a running schedule\n schedule_relationship: ADDED\n\n }\n stop_time_update {\n stop_sequence: 1\n arrival {\n # It's recommended to provide an absolute timestamp\n # for easy calculation of relative time\n time: 1656239890\n }\n }\n }\n }\n\n # third entity containing update information for a canceled trip\n entity {\n id: \"3\"\n trip_update {\n trip {\n trip_id: \"trip2\"\n start_time: \"14:05:00\"\n start_date: \"20220628\"\n # use \"CANCELED\" to specify a trip that existed in static GTFS but was canceled \n schedule_relationship: CANCELED\n\n }\n }\n }"]]