Noções básicas do Google Transit

Modelagem da GTFS: combinação de feeds em tempo real e estáticos

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 estático da GTFS contém o cronograma estimado e o design do transporte público. É 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.
    O feed em tempo real da GTFS foi criado para informar o status em tempo real, em vez dos dados estáticos. Ele comunica atrasos usando as posições dos veículos e as atualizações das viagens ou paradas predefinidas no feed estático. O Realtime também fornece alertas de serviço (atrasos, interrupções de serviço) 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 no cronograma.

Práticas recomendadas para atualizar seus feeds estáticos e em tempo real

Acontecem diversas alterações no transporte público, incluindo mudanças 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, no caso de determinadas alterações, existem alguns métodos para fazer outros tipos de mudança no feed em tempo real (sobretudo as temporárias, que precisam ser rápidas por terem um caráter mais reativo). Confira as práticas recomendadas para atualizar seus dados de feed nas tabelas a seguir.

Geral:

  Feed estático (> 2 a 7 dias) Feed em tempo real (~1 minuto)
Adicionar dados do feed A maioria das alterações 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 RT não é adequado para fazer exclusões de dados estáticos. No entanto, ele é indicado para exclusões temporárias.
Modificar dados do feed A maioria das alterações pode ser realizada de maneira direta. Não é compatível nem indicado.
Formas
  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
Paradas
  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.
Horários de parada
  Feed estático (> 2 a 7 dias) Feed em tempo real (~1 minuto)
Adicionar Adicionar um stop_time é equivalente a inserir uma parada existente em uma viagem definida. Aguarde dois dias para que as alterações 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 alterações entrem em vigor. A schedule_relationship de uma StopTimeUpdate deve ser SKIPPED.
Modificar Modifique o arquivo stop_times conforme preferir. As alterações entram em vigor em dois dias.

Basicamente, a posição do veículo (VP, na sigla em inglês) e a atualização da viagem (TU, na sigla em inglês) são tempos de parada modificados no RT.

Alertas de serviço com efeito

SIGNIFICANT_DELAY e

MODIFIED_SERVICE também podem indicar isso.

Viagens
  Feed estático (> 2 a 7 dias) Feed em tempo real (~1 minuto)
Adicionar

Para ativar ou desativar o serviço por data de maneira clara, use o calendar_dates.txt.

Use calendar_dates.txt com calendar.txt para definir exceções aos padrões de serviço padrão definidos em calendar.txt.Esta é 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 um cronograma escolar). 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 no RT.

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 os trechos das viagens podem ser bloqueados em tempo real (conforme mencionado acima) usando alertas de serviço.

 

Trajetos
  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: Podemos ocultar a parada X (alertas de serviço). Ela passará a ser ignorada nas viagens. Não é possível adicionar a parada Y ao cronograma, mas podemos usar o alerta acima para indicar o uso de outra parada intermediária.
P: O festival Y está acontecendo aqui. Temos X novas linhas fazendo o trajeto e fizemos algumas modificações substanciais. Precisamos de ajuda.

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:

  1. 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.
  2. Aponte as viagens afetadas nesse novo calendário (service_id).
  3. 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.
  4. 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.
  5. 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.


 
P: Quero adicionar um novo trajeto.
R: Lamento, mas não é possível.
P: Quero adicionar uma nova viagem.

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 do feed 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

    }

    ...

  }

}

Isso foi útil?
Como podemos melhorá-lo?

Precisa de mais ajuda?

Siga as próximas etapas:

Is there something we can help you with?

Chat with a member of Transit team

Pesquisa
Limpar pesquisa
Fechar pesquisa
Google Apps
Menu principal
Pesquisar na Central de Ajuda
true
82656
false