As atualizações de viagem representam flutuações nos horários. Esperamos receber atualizações para todas as viagens programadas que podem ser acompanhadas em tempo real. Essas atualizações dão uma previsão para os horários de partida ou chegada nas paradas ao longo do trajeto. Elas também podem especificar cenários mais complexos, quando as viagens são canceladas ou adicionadas à programação, ou até mesmo mudam de trajeto.
Lembrete: na GTFS, uma viagem é uma sequência de duas ou mais paradas que ocorrem em um horário específico.
Deve haver, no máximo, uma atualização para cada viagem programada. Se não, conclui-se que não há dados em tempo real disponíveis para a viagem. O consumidor de dados não deve assumir que a viagem está dentro do horário.
Atualizações dos horários de parada
Uma atualização de viagem consiste em uma ou mais atualizações nos horários de parada do veículo, chamadas de StopTimeUpdate
, que podem ser fornecidas para horários passados e futuros. Você pode remover os horários de parada passados, mas isso não é obrigatório. Os produtores não devem remover uma StopTimeUpdate
passada se ela se refere a uma parada com um horário de chegada programado no futuro para determinada viagem (isto é, se o veículo passou pela parada antes da programação). Caso contrário, darão a entender que não há atualização referente a essa parada.
Por exemplo, se o feed da GTFS Realtime contiver os seguintes dados:
- Parada 4: previsão de 10h18 (programado para 10h20, 2 min adiantado)
- Parada 5: previsão de 10h30 (programado para 10h30, no horário)
...não é possível remover do feed a previsão da Parada 4 até as 10h21, mesmo que o ônibus passe às 10h18. Se a StopTimeUpdate
da Parada 4 for removida às 10h18 ou 10h19 e o horário programado da chegada for 10h20, o consumidor deduzirá que não há informação em tempo real para essa parada e usará os dados de programação da GTFS.
Cada StopTimeUpdate
é vinculada a uma parada. Normalmente, isso pode ser feito usando uma stop_sequence
ou um stop_id
da GTFS. No entanto, se você fornecer uma atualização para uma viagem sem um trip_id
, precisará especificar o stop_id
já que a stop_sequence
não tem valor. O stop_id
ainda precisa fazer referência a um stop_id
na GTFS. Se o mesmo stop_id
for visitado mais de uma vez em uma viagem, será necessário fornecer a stop_sequence
em todas as mensagens de StopTimeUpdate
para esse stop_id
da viagem.
A atualização pode informar um horário exato de arrival
e/ou departure
em uma parada na StopTimeUpdate
usando StopTimeEvent
.
Ela precisa indicar um time
absoluto ou um delay
(isto é, um desvio, em segundos, em relação ao horário programado). O campo delay
só pode ser usado caso a atualização se refira a uma viagem programada da GTFS, e não a uma viagem com base em frequência. Nesse caso, o horário deve ser igual ao horário programado + atraso. Você também pode especificar a uncertainty
da previsão com o StopTimeEvent
, que é discutido em mais detalhes na seção Indefinição mais adiante nesta página.
A relação de programação padrão é scheduled
para cada StopTimeUpdate
. Essa relação é diferente para a viagem. Você poderá alterá-la para skipped
se a parada não for feita ou no data
, se tiver dados em tempo real apenas para parte da viagem.
As atualizações precisam ser classificadas por stop_sequence
(ou stop_ids
na ordem em que ocorrem na viagem).
Se faltarem uma ou mais paradas ao longo da viagem, a atualização será propagada para todas as paradas subsequentes. Isso significa que, na falta de outras informações, a atualização do horário de uma parada específica mudará todas as outras paradas.
Exemplo 1
Em uma viagem com 20 paradas, uma StopTimeUpdate
com atraso de chegada e partida de 0
(StopTimeEvent
) para a stop_sequence
da parada atual significa que a viagem está no horário.
Exemplo 2
São fornecidas três mensagens StopTimeUpdate
na mesma instância de viagem:
- Atraso de 300 segundos para
stop_sequence
3 - Atraso de 60 segundos para
stop_sequence
8 - Atraso da duração não especificada para
stop_sequence
10
Isso será interpretado da seguinte maneira:
- As mensagens das
stop_sequence
s 1 e 2 têm atraso desconhecido. - As mensagens das
stop_sequence
s 3, 4, 5, 6 e 7 têm atraso de 300 segundos. - As mensagens das
stop_sequence
s 9 e 8 têm atraso de 60 segundos. - As mensagens das
stop_sequence
s 10 a 20 têm atraso desconhecido.
Descritor de viagem
As informações fornecidas pelo descritor de viagem dependem da relação de programação da viagem que você está atualizando. Há várias opções para você definir:
Valor | Comentário |
---|---|
Scheduled |
Essa viagem está sendo feita de acordo com uma programação GTFS ou está próxima o suficiente para continuar associada a ela. |
Added |
Essa viagem não foi programada e foi adicionada. Por exemplo, para atender à demanda ou substituir um veículo quebrado. |
Unscheduled |
Essa viagem está sendo feita e não está associada a uma programação. Por exemplo, quando não há uma programação e os ônibus rodam em um serviço de traslado. |
Canceled |
Essa viagem foi programada, mas foi removida. |
Na maioria dos casos, você precisa fornecer o trip_id
da viagem programada na GTFS a que essa atualização está relacionada.
Sistemas com valores de trip_id repetidos
Para sistemas que usam valores de trip_id
repetidos, como viagens modeladas usando frequencies.txt
, ou seja, viagens com base em frequência, o trip_id
não é um identificador exclusivo de uma única jornada, já que não tem um componente de tempo específico.
Para identificar essas viagens de forma exclusiva em um TripDescriptor
, é necessário fornecer três identificadores:
trip_id
start_time
start_date
Primeiro, é preciso publicar o start_time
. Assim, todas as atualizações de feed posteriores usarão o mesmo start_time
ao se referir à mesma jornada. Depois, é necessário usar StopTimeUpdate
para indicar os ajustes. O start_time
não precisa ser exatamente o horário de partida da primeira estação, mas deve ser bem próximo dele.
Por exemplo, digamos que, às 10h do dia 25 de maio de 2015, o horário de partida de uma viagem com trip_id=T
começa às start_time=10:10:00
e que enviamos essas informações com um feed em tempo real às 10h01. Às 10h05, descobrimos que o horário de partida da viagem não será às 10h10, mas sim às 10h13. No novo feed em tempo real, ainda podemos identificar essa viagem como (T, 2015-05-25, 10:10:00)
, mas fornecemos uma StopTimeUpdate
em que a partida da primeira parada é às 10h13.
Correspondência alternativa de viagens
Viagens que não se baseiam em frequência também podem ser identificadas de forma exclusiva com um TripDescriptor
que inclua a combinação de:
route_id
direction_id
start_time
start_date
em que o start_time
é o horário de início agendado, conforme definido na programação estática, desde que a combinação de IDs fornecida identifique uma única viagem.
Indefinição
A indefinição refere-se ao horário e ao valor de atraso de uma StopTimeUpdate
.
Ela especifica o erro esperado no atraso real como um número inteiro, em segundos (lembre-se de que o significado estatístico preciso ainda não é definido). A indefinição pode ter valor 0
, por exemplo, no caso de trens conduzidos sob o controle automatizado de horário.
Por exemplo, um ônibus que faz uma viagem longa e tem um atraso estimado de 15 minutos para chegar à próxima parada em um intervalo de erro de 4 minutos (isto é +2 / -2 minutos) terá o valor de 240
em uncertainty
.