Trip Updates¶

Trip updates представляют собой колебания в расписании. Мы ожидаем получать обновления для всех запланированных вами поездок, которые могут выполняться в реальном времени. Эти обновления будут содержать прогнозируемое время прибытия или отправления для остановок по маршруту. Trip updates могут также предусматривать более сложные сценарии, когда поездки отменяются или добавляются в расписание, или даже изменяется маршрут.

Напоминание: В GTFS поездка - это последовательность из двух или более остановок, происходящих в определенное время.

Для каждой запланированной поездки должно быть не более одного обновления. В случае отсутствия обновления для запланированной поездки будет сделан вывод, что для этой поездки нет данных в реальном времени. Потребитель данных не должен считать, что поездка выполняется вовремя.

Если транспортное средство обслуживает несколько поездок в пределах одного блока (более подробную информацию о поездках и блоках см. в файле GTFS trips.txt):

фид должен включать TripUpdate для путешествие, которая в данный момент обслуживается транспортное средство. Производителям рекомендуется включать TripUpdate для одной или нескольких поездок после текущей путешествие в блоке данного vehicle, если производитель уверен в качестве прогнозов для этих будущих путешествие. Включение нескольких TripUpdates для одного и того же vehicle позволяет избежать "всплытия" прогнозов для пассажиров при переходе от одной путешествие к другой, а также заранее предупредить пассажиров о задержках, которые влияют на последующие поездки (например, когда известная delay превышает запланированное время ожидания между поездками).
соответствующие сущности TripUpdate не обязаны быть добавлен в фид в том же порядке, в котором они Запланированное в блоке. Например, если есть поездки с trip_ids 1, 2 и 3, которые все принадлежат одному блоку, и vehicle совершает путешествие 1, затем путешествие 2, а затем путешествие 3, сущности trip_update могут появляться в любом порядке - например, допускается добавление путешествие 2, затем путешествие 1, а затем путешествие 3.

StopTimeUpdate¶

Обновление поездки состоит из одного или нескольких обновлений времени остановок транспортного средства, которые называются StopTimeUpdates. Они могут быть предоставлены для прошлого и будущего времени остановки. Разрешается, но не требуется, сбрасывать прошлое время остановки. Производители не должны отбрасывать прошлое StopTimeUpdate, если оно относится к остановке с запланированным временем прибытия в будущем для данной поездки (т.е. транспортное средство проехало остановку раньше запланированного времени), поскольку в противном случае будет сделан вывод, что для этой остановки нет обновления.

Например, если в ленте GTFS-rt появляются следующие данные:

Остановка 4 - Прогнозируется в 10:18 утра (запланирована на 10:20 утра - на 2 минуты раньше)
Остановка 5 - Прогнозируется в 10:30 утра (по расписанию в 10:30 утра - вовремя)

...прогноз для остановки 4 не может быть удален из ленты до 10:21 утра, даже если автобус фактически проезжает остановку в 10:18 утра. Если StopTimeUpdate для остановки 4 был удален из ленты в 10:18 или 10:19 утра, а запланированное время прибытия - 10:20 утра, то потребитель должен считать, что для остановки 4 не существует информации в реальном времени в это время, и следует использовать данные расписания из GTFS.

Каждый StopTimeUpdate связан с остановкой. Обычно это можно сделать, используя либо GTFS stop_sequence, либо GTFS stop_id. Однако, в случае, если вы предоставляете обновление для поездки без trip_id GTFS, вы должны указать stop_id, так как stop_sequence не имеет значения. stop_id все равно должен ссылаться на stop_id в GTFS. Если один и тот же stop_id посещается более одного раза в поездке, то stop_sequence должен быть предоставлен во всех StopTimeUpdates для этого stop_id в этой поездке.

Обновление может предоставить точное время arrival и/или departure на остановке в StopTimeUpdates с помощью StopTimeEvent. Оно должно содержать либо абсолютное time, либо delay (т.е. смещение от запланированного времени в секундах). Задержка может быть использована только в том случае, если обновление поездки относится к запланированной поездке GTFS, а не к поездке на основе частоты. В этом случае время должно быть равно запланированному времени + задержка. Вы также можете указать uncertainty прогноза вместе с StopTimeEvent, что более подробно обсуждается в разделе Uncertainty далее по странице.

Для каждого StopTimeUpdate по умолчанию scheduled связь с расписанием. (Обратите внимание, что это отличается от отношения расписания для поездки). Вы можете изменить это значение на skipped, если остановка не будет остановлена, или no data, если у вас есть данные реального времени только для части поездки.

Обновления должны быть отсортированы по stop_sequence (или по stop_ids в том порядке, в котором они встречаются в поездке).

Если одна или несколько остановок отсутствуют в поездке, delay от обновления (или, если в обновлении указано только time, задержка, рассчитанная путем сравнения time с временем расписания GTFS) распространяется на все последующие остановки. Это означает, что обновление времени остановки для определенной остановки изменит все последующие остановки при отсутствии какой-либо другой информации. Обратите внимание, что обновления с отношением расписания SKIPPED не остановят распространение задержки, но обновления с отношением расписания SCHEDULED (также значение по умолчанию, если отношение расписания не предоставлено) или NO_DATA остановят.

Пример 1

Для поездки с 20 остановками, StopTimeUpdate с задержкой прибытия и задержкой отправления 0(StopTimeEvents) для stop_sequence текущей остановки означает, что поездка точно по расписанию.

Пример 2

Для одного и того же экземпляра поездки предоставляется три обновления StopTimeUpdate:

задержка 300 секунд для стоп_последовательности 3
задержка 60 секунд для стоп_последовательности 8
ScheduleRelationship of NO_DATA for stop_sequence 10

Это будет интерпретировано как:

стоп_последовательности 1,2 имеют неизвестную задержку.
стоп_последовательности 3,4,5,6,7 имеют задержку 300 секунд.
Стоп_последовательности 8,9 имеют задержку 60 секунд.
стоп_последовательности 10,...,20 имеют неизвестную задержку.

TripDescriptor¶

Информация, предоставляемая TripDescriptor, зависит от отношения расписания поездки, которое вы обновляете. Вы можете задать несколько параметров:

Значение	Комментарий
Scheduled	Эта поездка выполняется в соответствии с расписанием GTFS или достаточно близка к нему, чтобы быть связанной с ним.
Added	Эта поездка не была запланирована и была добавлена. Например, чтобы удовлетворить спрос или заменить сломавшийся автомобиль.
Unscheduled	Эта поездка выполняется и никогда не была связана с расписанием. Например, если нет расписания, а автобусы ходят по маршруту.
Canceled	Эта поездка была запланирована, но теперь удалена.
Duplicated	Эта новая поездка является копией существующей поездки в статической GTFS, за исключением даты и времени начала обслуживания. Новая поездка будет запущена в дату и время обслуживания, указанные в TripProperties.

В большинстве случаев необходимо указать trip_id запланированной поездки в GTFS, к которой относится это обновление.

Системы с повторяющимися trip_ids¶

Для систем, использующих повторяющиеся trip_ids, например, поездки, смоделированные с помощью файла frequencies.txt, то есть поездки на основе частоты, trip_id сам по себе не является уникальным идентификатором одной поездки, поскольку в нем отсутствует конкретный временной компонент. Чтобы однозначно идентифицировать такие поездки в TripDescriptor, необходимо предоставить тройку идентификаторов:

trip_id
start_time
start_date

start_time должно быть опубликовано первым, и все последующие обновления ленты должны использовать это же start_time, когда речь идет об одной и той же поездке. StopTimeUpdates следует использовать для указания корректировок; время start_time не обязательно должно быть точным временем отправления с первой станции, хотя оно должно быть довольно близким к этому времени.

Например, допустим, мы решаем в 10:00, 25 мая 2015 года, что поездка с trip_id=T начнется в start_time=10:10:00, и предоставляем эту информацию через realtime feed в 10:01. В 10:05 мы вдруг узнаем, что поездка начнется не в 10:10, а в 10:13. В нашей новой ленте реального времени мы по-прежнему можем идентифицировать эту поездку как (T, 2015-05-25, 10:10:00), но предоставляем StopTimeUpdate с отправлением с первой остановки в 10:13:00.

Альтернативное сопоставление поездок¶

Поездки, не основанные на частоте, также могут быть уникально идентифицированы с помощью TripDescriptor, включающего комбинацию из:

route_id
direction_id
start_time
start_date

где start_time - запланированное время начала, определенное в статическом расписании, при условии, что указанная комбинация идентификаторов приводит к уникальной поездке.

Uncertainty¶

Uncertainty применяется как к времени, так и к значению задержки в StopTimeUpdate. Uncertainty приблизительно определяет ожидаемую ошибку в истинной задержке как целое число в секундах (но обратите внимание, точное статистическое значение еще не определено). Возможно, что uncertainty равна 0, например, для поездов, управляемых компьютерным контролем времени.

В качестве примера, автобус дальнего следования, который, по оценкам, задерживается на 15 минут и прибывает на свою следующую остановку в пределах 4-минутного окна ошибки (то есть +2 / -2 минуты), будет иметь значение неопределенности 240.