As atualizações de viagem representam flutuações na tabela de horário. Esperamos receber atualizações em tempo real para todas as viagens programadas. Essas atualizações fornecem uma previsão para os horários de partida e de chegada nas paradas ao longo do trajeto. As atualizações de viagem também especificam cenários mais complexos, quando as viagens são canceladas ou adicionadas à programação ou até mesmo mudam de trajeto.
Lembrete: no Feed 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. Caso não haja nenhuma atualização para uma viagem programada, 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 StopTimeUpdates. Essas atualizações podem ser fornecidas para horários de parada passados e futuros. Você pode remover do feed 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 programada futuro para determinada viagem (isto é, se o veículo passou pela parada antes da programação). Se fizer isso, dará 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é às 10h21, mesmo que o ônibus passe pela parada às 10h18. Se a StopTimeUpdate da Parada 4 for removida do feed à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 a Parada 4 no momento e usará os dados de programação da GTFS.
Cada StopTimeUpdate está vinculada a uma parada. De um modo geral, isso pode ser feito utilizando-se stop_sequence ou stop_id da GTFS. No entanto, caso você esteja fornecendo uma atualização para uma viagem sem trip_id da GTFS, deve especificar stop_id, uma vez que stop_sequence não possui nenhum valor. 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 indicar a stop_sequence em todas as StopTimeUpdates desse stop_id da viagem.
A atualização pode informar um horário exato para arrival e/ou departure em uma parada em StopTimeUpdates usando StopTimeEvent. Ela deve fornecer time ou delay absolutos (isto é, um desvio, em segundos, em relação ao horário programado). O atraso pode ser usado caso a atualização da viagem se refira a uma viagem GTFS programada, 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 o valor uncertainty da previsão com StopTimeEvent, que é discutido em mais detalhes na seção Indefinição mais adiante nesta página.
Para cada StopTimeUpdate, a relação padrão com a programação é scheduled. Isso é diferente da relação da viagem com a programação. Você poderá alterar uma parada para skipped se ela não for feita ou para no data se você tiver dados em tempo real apenas para parte da viagem.
As atualizações devem 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 é propagada para todas as paradas subsequentes. Isso significa que a atualização do horário de uma parada específica alterará todas as paradas subsequentes, na falta de outras informações.
Exemplo 1
Em uma viagem com 20 paradas, uma StopTimeUpdate que tem atrasos na chegada e na partida iguais a 0 (StopTimeEvents) na stop_sequence da parada atual significa que a viagem está exatamente dentro do horário.
Exemplo 2
São fornecidas três StopTimeUpdates na mesma instância de viagem:
- Atraso de 300 segundos para a stop_sequence 3.
- Atraso de 60 segundos para a stop_sequence 8.
- Atraso de duração não especificada para a stop_sequence 10.
Isso será interpretado como:
- stop_sequences 1 e 2 têm atraso desconhecido.
- stop_sequences 3, 4, 5, 6 e 7 têm atraso de 300 segundos.
- stop_sequences 8 e 9 têm atraso de 60 segundos.
- stop_sequences de 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 | Esta viagem está sendo feita de acordo com uma programação GTFS ou está próxima o suficiente para continuar relacionada a ela. |
| Added | Esta viagem não foi programada e foi adicionada. Por exemplo, para atender à demanda ou substituir um veículo quebrado. |
| Unscheduled | Esta 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 translado. |
| Canceled | Esta viagem foi programada, mas foi removida. |
Na maioria dos casos, você deve fornecer o trip_id da viagem programada na GTFS a que essa atualização está relacionada.
Sistemas com trip_ids repetidos
No caso de sistemas que usam trip_ids repetidos, como viagens modeladas com o frequencies.txt (com base em frequência), o trip_id não representa um identificador exclusivo de uma única jornada, já que não inclui um componente de tempo específico. Para identificar essas viagens de forma exclusiva em um TripDescriptor, é necessário especificar três identificadores:
- trip_id
- start_time
- start_date
É importante que o start_time seja publicado primeiro e todas as atualizações de feed posteriores utilizem o mesmo start_time quando se referirem à mesma jornada. StopTimeUpdates deve ser usado 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 desse horário.
Por exemplo, digamos que, às 10h do dia 25 de maio de 2015, decidimos que o horário de partida de uma viagem com trip_id=T será às 10h10 (start_time=10:10:00) e especificamos essas informações no feed em tempo real às 10h01. De repente, às 10h05, descobrimos que o horário de partida 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 precisamos especificar uma StopTimeUpdate com partida da primeira parada às 10h13.
Correspondência de viagens alternativas
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
Sendo start_time a hora de início agendada, 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. A indefinição especifica o erro esperado no atraso real como um número inteiro, em segundos (observe que o significado estatístico preciso ainda não é definido). "uncertainty" 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 quatro minutos (isto é +2 / -2 minutos) terá um valor de 240 em "uncertainty".