Importante: não altere o TripDescriptor durante viagem. Ele é usado para selecionar uma única viagem.
Para vincular uma viagem em tempo real ao protótipo estático da Especificação Geral sobre Feeds de Transporte Público (GTFS), é usada a submensagem do TripDescriptor. Neste artigo, explicamos como escolher uma viagem com schedule_relationship definido como SCHEDULED ou CANCELED.
Adicionar ou combinar uma viagem
Para adicionar uma viagem em tempo real com schedule_relationship definido como ADDED, consulte Adicionar uma viagem em tempo real.
Para fazer a correspondência de uma viagem entre conjuntos de dados em tempo real e estáticos, no TripDescriptor, inclua uma tupla:
trip_idstart_timestart_date
trip_id, faça a substituição por route_id e direction_id. Para que as correspondências sejam feitas corretamente, os campos start_time e start_date são obrigatórios.Fornecer o TripDescriptor em programações frequentes e não frequentes
TripDescriptors não baseados na frequência
- Os campos
trip_idestart_datesão necessários para identificar uma viagem da programação estática. O campostart_timeé opcional. Quando fornecido, ele precisa corresponder a um dos horários de início da viagem, na data de início determinada pela programação estática. - Se não for possível fornecer o
trip_id, informe <route_id,direction_id,start_date>.- Para que os métodos de correspondência do
route_ide dodirection_idfuncionem, o feed estático da GTFS precisa incluirdirection_ids. Esse método de correspondência não funciona muito bem, porque é feito na medida do possível e está sujeito a mudanças.
- Para que os métodos de correspondência do
Exemplo de código
trip_update {
trip {
trip_id: "non_frequency-expanded-trip"
start_date: "20160203"
}
}
trip_update {
trip {
route_id: "route1"
direction_id: 0
start_time: "10:10:00"
start_date: "20160203"
}
}
TripDescriptors baseados na frequência
Esse tipo de viagem é modelado com o arquivo frequencies.txt. Nesse caso, o campo start_time é obrigatório porque é necessário ter um componente de tempo específico para identificar uma viagem individual.
- Para identificar uma viagem da programação estática, você precisa de uma tupla de
trip_id,start_dateestart_time. Se há alguma informação faltando, usamos o que for possível para encontrar uma viagem. - Se o
trip_idnão for informado, definaroute_id,direction_id,start_date,start_time. Para que os métodos de correspondência doroute_ide dodirection_idfuncionem, o feed estático da GTFS precisa incluir "direction_ids". Esse método de correspondência não funciona bem.
Ao informar um start_time, considere o seguinte:
- O campo
start_timeprecisa ser igual ao horário de início programado do conjunto de dados estático. - O
start_timeprecisa ser idêntico em todos os TripDescriptors que representam a mesma viagem nos pacotes de feeds. - Não mude o
start_timepara indicar ajustes no primeiro horário de partida da primeira parada. Em vez disso, useStopTimeUpdates. - O
start_timeprecisa ser próximo do horário de partida da primeira estação, mas não obrigatoriamente igual.
Dica: quando trip_id e start_time estão dentro de um intervalo exact_time=1, o start_time precisa ser posterior ao início do intervalo em um múltiplo exato de headway_secs.
Exemplo
Decidimos às 10h, de 25 de maio de 2015, que uma viagem com trip_id=T começará às start_time=10:10:00. Divulgamos essas informações pelo feed em tempo real às 10h01. Às 10h05, percebemos que a viagem começará às 10h13, em vez de 10h10. No novo feed em tempo real, ainda podemos identificar essa viagem como (T, 2015-05-25, 10:10:00), mas precisamos especificar um StopTimeUpdate com a partida da primeira parada às 10:13:00.
Se o start_time for alterado, talvez uma segunda partida de ônibus seja criada. Por exemplo: uma às 10h10, e outra às 10h13.
Exemplo de código:
trip_update {
trip {
trip_id: “T”
start_date: "20150525"
start_time: "10:10:00"
}
stop_time_update {
stop_sequence: 1
departure {
delay: 180
}
}
}