Para garantir a continuidade do serviço e a precisão com que os dados são veiculados para os usuários do Google Transit, é necessário seguir a modelagem da Especificação Geral sobre Feeds de Transporte Público (GTFS). Essa modelagem tem como objetivo criar uma combinação de feeds em tempo real (RT, na sigla em inglês) e estáticos para retratar o que realmente está acontecendo.
Princípios básicos da modelagem da GTFS
- Feeds estáticos da GTFS: requerem um tempo de processamento de 24 a 48 horas após o envio ao Google, embora possa haver atraso se detectarmos problemas.
O feed GTFS estático (em inglês) é usado no design de programações e meios de transporte público que não passam por mudanças. É recomendável fornecer o feed estático ao Google com, no mínimo, dois dias de antecedência. No entanto, a antecedência ideal é de uma semana, como precaução caso o Google detecte conflitos ou problemas suspeitos no feed que exijam uma revisão humana. - Feeds em tempo real da GTFS: as atualizações enviadas ao Google são aplicadas imediatamente.
A GTFS Realtime foi criada para informar o status em tempo real, em vez dos dados estáticos. Ela comunica atrasos usando as posições dos veículos e as atualizações das viagens ou paradas predefinidas no feed estático, além de apresentar alertas de serviço (como atrasos e interrupções) aos usuários. - Embora seja possível ativar e desativar viagens na GTFS, ela é limitada, já que a adição de serviços indefinidos (forma, sequência e horário das paradas e trajeto) em menos de dois dias (em tempo real) não é viável. A adição de serviços leva de dois a sete dias (ou mais), porque há um processo de revisão humana para evitar conflito das informações alteradas ou edições suspeitas.
- Você pode usar o feed_info.txt no feed estático para determinar (com dois a sete dias ou mais de antecedência) quando as alterações estáticas entrarão em vigor, garantindo a consistência com os feeds em tempo real. Use os campos "feed_start_date" e "feed_end_date" para especificar as datas em que o feed estático deve estar ativo. Se o feed começar em uma data futura (informação do campo "feed_start_date", com base na data de processamento), ele será processado, mas manteremos a versão atual e a "futura".
- Os feeds estáticos contêm os dados principais sobre trajetos, paradas e programação de viagens. Porém, conforme mencionado acima, as alterações nos feeds estáticos levam de dois a sete dias para fazer efeito. Veja a seguir as práticas recomendadas para fazer mudanças na programação.
Práticas recomendadas para atualizar seus feeds estáticos e em tempo real
Diversas alterações pode acontecer no transporte público, incluindo na duração das viagens, nos níveis de urgência e no tipo de entidade. De modo geral, qualquer alteração nos dados principais, incluindo adições, modificações ou exclusões de paradas, trajetos ou viagens, deve ser feita no feed estático. No entanto, em alguns casos, há métodos para fazer outros tipos de mudança no feed em tempo real (principalmente as temporárias, que precisam ser rápidas por serem mais reativas). Veja as práticas recomendadas nas tabelas a seguir para atualizar os dados no seu feed.
Geral:
| Feed estático (de 2 a 7 dias ou mais) | Feed em tempo real (cerca de 1 minuto) | |
|---|---|---|
| Adicionar dados ao feed | A maioria das mudanças pode ser realizada de maneira direta. | Em geral, isso não é possível, a menos que a adição seja feita a uma frequência existente com schedule_relationship. |
| Excluir dados do feed | Exclusões significativas são sinalizadas como suspeitas e podem passar por uma revisão mais detalhada. | O feed em tempo real não é adequado para exclusões estáticas. No entanto, ele é indicado para exclusões temporárias. |
| Modificar dados no feed | A maioria das mudanças pode ser realizada de maneira direta. | Não é compatível nem indicado. |
| Feed estático (> 2 a 7 dias) | Feed em tempo real (~1 minuto) | |
|---|---|---|
| Adicionar | Adicione o shape_id à viagem existente no arquivo trips.txt, conforme preferir. | Não é permitido. O shape_id é obrigatório. |
| Excluir | Remova o shape_id das viagens existentes no arquivo trips.txt, conforme preferir. É possível que haja formas não utilizadas. | N/A |
| Modificar | Modifique o formato como quiser. As alterações entram em vigor em dois dias. | N/A |
| Feed estático (> 2 a 7 dias) | Feed em tempo real (~1 minuto) | |
| Adicionar |
Sim. Pode ser necessário fazer alterações nos stop_times e nas viagens. Observação: os nomes das novas paradas levam algum tempo (dois dias ou mais) para aparecer no Google Maps, já que estão sujeitos a revisão. |
N/A |
| Excluir | Possível. Nenhum stop_time deve continuar se referindo a paradas não definidas. |
Efeito NO_SERVICE no alerta de serviço: a parada não será feita nas viagens das quais ela faz parte. Como alternativa, a schedule_relationship de uma StopTimeUpdate pode ser SKIPPED. |
| Modificar | As revisões podem levar mais de dois dias para serem concluídas devido ao processo de análise detalhado. | Não. Apenas a exclusão é possível. |
| Feed estático (de 2 a 7 dias ou mais) | Feed em tempo real (cerca de 1 minuto) | |
| Adicionar | Adicionar um stop_time é equivalente a inserir uma parada existente em uma viagem definida. Aguarde dois dias para que as mudanças entrem em vigor. | Não é permitido. |
| Excluir | Remova os stop_times que você quiser das viagens escolhidas (para remover as respectivas paradas das viagens). Aguarde dois dias para que as mudanças entrem em vigor. | A schedule_relationship de uma StopTimeUpdate deve ser SKIPPED. |
| Modificar | Modifique o arquivo stop_times conforme preferir. As mudanças entram em vigor em dois dias. |
Em resumo, a posição do veículo e a atualização da viagem (VP e TU, respectivamente, nas siglas em inglês) são tempos de parada modificados em tempo real. Alertas de serviço com efeito SIGNIFICANT_DELAY e MODIFIED_SERVICE também podem indicar isso. |
| Feed estático (de 2 a 7 dias ou mais) | Feed em tempo real (cerca de 1 minuto) | |
| Adicionar |
Para ativar ou desativar o serviço por data de maneira clara, use o calendar_dates.txt. Use o calendar_dates.txt com o calendar.txt para definir exceções aos padrões de serviço estabelecidos no calendar.txt. Essa é uma boa abordagem se o serviço é, em geral, regular, com poucas alterações nas datas explícitas (por exemplo, para acomodar serviços de eventos especiais ou a programação de uma escola). Ela levará dois dias para entrar em vigor, mas a GTFS não precisa de muitas modificações. Se o serviço é oferecido nas viagens, é necessário editar apenas uma linha. O serviço e a viagem com granularidade mais baixa podem ter mapas 1:1. |
Use os valores schedule_relationship para sinalizar viagens não planejadas em tempo real. Os valores shape e stop_time precisam ser predefinidos de acordo com uma viagem existente. O valor ADDED copia as viagens planejadas com um novo start_time desde que a viagem principal não tenha transferências de blocos. Ter um start_time consistente é fundamental para diferenciar as viagens. O valor ADDITIONAL_SERVICE nos alertas de serviço é usado para descrever ônibus extras inseridos em linhas de serviço já existentes. |
| Excluir |
Remova a viagem e garanta que todas as referências sejam excluídas (frequencies, stop_times, trips). Entrará em vigor em dois dias. Outra maneira de conseguir isso é com a remoção das entradas correspondentes do arquivo calendar.txt ou adição de exceções ao calendar_dates.txt. |
A atualização de uma viagem com a relação programada CANCELED possibilita isso. O alerta com efeito NO_SERVICE ou REDUCED_SERVICE também indica a falta ou limitação do serviço ao usuário. Use um texto descritivo. |
| Modificar |
Você pode modificar as viagens conforme necessário. Outra maneira de fazer isso é incluir as entradas correspondentes do arquivo calendar.txt ou adicionar exceções ao calendar_dates.txt. |
Não é permitido modificar as paradas da viagem, mas os atrasos e chegadas antecipadas são sinalizados com "TU" ou "VP". As paradas e as partes das viagens podem ser bloqueadas em tempo real (conforme mencionado acima) usando os alertas de serviço. |
| Feed estático (> 2 a 7 dias) | Feed em tempo real (~1 minuto) | |
| Adicionar | Para adicionar um trajeto, inclua uma única linha a routes.txt. No entanto, essa mudança só ficará visível depois que as viagens forem criadas e atribuídas ao trajeto correto no arquivo trips.txt. | Não é permitido nem recomendado. |
| Excluir | Remova o trajeto e garanta que as viagens em questão sejam removidas ou atribuídas a outro trajeto. Entrará em vigor em dois dias. |
O alerta NO_SERVICE interromperia todas as viagens associadas a esse trajeto. As paradas do trajeto não são alteradas quando estão compartilhadas com outros trajetos ou viagens. Observação: a exclusão do trajeto ainda é um conceito estático. |
| Modificar |
Você pode modificar as viagens conforme necessário. Dica: os usuários identificam trajetos com cores ou nomes. Não é recomendado fazer alterações frequentes. |
Não é permitido nem recomendado. |
Mais detalhes sobre os feeds em tempo real
Importante: não é possível nem recomendado fazer modificações em tempo real de formas ou caminhos e elementos essenciais dos feeds estáticos.
É possível fazer adições e exclusões em tempo real: para isso, é necessário ter um esboço do caminho, uma stop_sequence e um stop_time (uma viagem que sirva de modelo) no feed estático.
Use os arquivos calendar.txt e calendar_dates.txt de forma criativa. Por exemplo, para mostrar dias com previsão de neve, especifique viagens que podem não estar "em serviço", mas que poderão ser feitas no futuro caso haja demanda. Em outras palavras, defina as viagens com antecedência. Isso permite a "ativação/desativação com base no RT (padrão)" quando chegar o momento.
Perguntas frequentes
P: Houve um pequeno acidente na parada X. Quero encontrar um trajeto alternativo pela parada Y o mais rápido possível. Posso fazer isso?R: Nossas opções de solução dependerão da data de início do festival.
Se faltar mais de dois dias para o início do festival, recomendamos o seguinte:
Use o arquivo calendar_dates.txt para remover todas as viagens modificadas existentes durante o festival. Você também pode adicionar novas viagens durante o período. Como é difícil adicionar novas paradas, esperamos que você tenha se planejado para isso (se possível, com uma semana ou mais de antecedência). É possível usar as paradas existentes. Para modificá-las, siga estas etapas:
- Crie um novo calendário e entradas de calendar_date (novo service_id) para as viagens existentes que contêm o calendário normal e a exclusão das calendar_dates.
- Aponte as viagens afetadas nesse novo calendário (service_id).
- Crie entradas de calendar_dates com um novo service_id para as datas do evento a serem usadas com novos trajetos especiais e as versões modificadas das viagens afetadas.
- Crie viagens (e formatos) para as versões modificadas das viagens afetadas. Além disso, crie trajetos, viagens e formatos para as linhas de serviço especiais. Todos esses dados devem estar associados ao service_id criado na etapa 3.
- Depois do evento, retorne ao formato de feed anterior.
Se faltar menos de dois dias para o festival, veja as opções:
Podemos cancelar as viagens existentes, e o efeito MODIFIED_SERVICE é o local ideal para informar isso. Não há tempo suficiente para incluir novas paradas ou stop_times nos cronogramas do trajeto. No entanto, podemos "adicionar veículos" às linhas existentes (incluídas no cronograma ou com base na frequência) para absorver o aumento da demanda pelo serviço.
R: o feed estático tem alguma viagem com as mesmas stop_sequences dessa viagem? Caso não tenha, não será possível incluir nenhuma viagem no índice em menos de dois dias.
No entanto, uma atualização de viagem (TU) ou posição do veículo (VP) poderá ser definida em uma viagem com diferentes horários de início como uma viagem da relação do cronograma ADDED. Esse cronograma adicionado usará as paradas do trip_id fornecidas, mas iniciará uma viagem na nova start_date indicada.
Importante: os valores de start_time, direction, start_date e trip_id precisam permanecer estáveis para manter a referência à viagem depois de adicionada. Isso não é permitido nas viagens com transferências de blocos. Os feeds de TU e VP poderão ter esta aparência:
Este código de tempo real não é válido. Ele serve apenas como uma diretriz.
# informações do título
header {
# versão da especificação de velocidade. Atualmente "2.0"
gtfs_realtime_version: "2.0"
# determina se o conjunto de dados é incremental ou completo
incrementality: FULL_DATASET
# momento em que o conjunto de dados é gerado no servidor
timestamp: 1284457468
}
# várias entidades podem ser incluídas no feed
entity {
# identificador único da entidade
id: "add-a-trip"
# "tipo" da entidade
trip_update {
trip {
# seleciona qual entidade da GTFS (viagem) será afetada
Schedule_relationship: ADDED
trip_id: "tripid_of_trip_to_copy" # definido no feed estático
route_id: “routeid_of_trip_to_copy” # definido no feed estático.
# NÃO pode conter transferências de blocos.
start_time: “10:00:00” # horário local em que a viagem complementar começa
start_date: “20180201” # data local em que a viagem complementar começa
}
...
}
}