Atualizações de viagem

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_sequences 1 e 2 têm atraso desconhecido.
  • As mensagens das stop_sequences 3, 4, 5, 6 e 7 têm atraso de 300 segundos.
  • As mensagens das stop_sequences 9 e 8 têm atraso de 60 segundos.
  • As mensagens das stop_sequences 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.