Requisitos da GTFS

O parceiro precisa fornecer um feed GTFS que atenda a todas as especificações padrão, além das listadas abaixo. Esse feed precisa abranger todos os itinerários que o parceiro quer mostrar. Ao fornecer essas informações, os dados de programação e trajeto vão aparecer no Google. Um parceiro pode escolher expor informações adicionais de preço e disponibilidade para alguns ou todos os itinerários no feed fornecido.

Requisitos padrão

Referência da GTFS estática: todos os requisitos padrão são aplicados.

Práticas recomendadas da GTFS: siga as práticas recomendadas como se fossem obrigatórias.

Como fazer upload de feeds GTFS: siga este processo para fazer upload do feed GTFS.

Atualizações: depois que os feeds forem enviados, eles poderão ser atualizados seguindo o processo descrito aqui. Em geral, essas atualizações de feed podem levar de dois a três dias para serem totalmente propagadas.

Outros requisitos

Escopo

• Um único feed GTFS precisa abranger um único país ou uma parte de um país. As viagens que cruzam fronteiras nacionais precisam ser fornecidas em feeds separados em todo o continente. Se um feed GTFS abranger algo maior que um país, entre em contato com a equipe de transporte de viagens.
  • Os arquivos no arquivo ZIP da GTFS precisam ter menos de 4 GB. Arquivos maiores geralmente são um sinal de práticas inadequadas, como ignorar as opções de compactação oferecidas por frequencies.txt ou recursos semelhantes. Isso pode causar problemas durante o processamento. Se você acha que precisa de arquivos maiores que 4 GB, entre em contato com a equipe de transporte de viagens em [e-mail].
  • Os dados de todo o período futuro de operação dos serviços em um feed GTFS precisam ser fornecidos com cada atualização dos dados da GTFS. A segmentação de serviços por diferentes períodos não é aceitável.
• Todas as datas de uma determinada operadora precisam estar em um único feed.

Traduções

• As traduções podem ser fornecidas usando translations.txt e serão necessárias em países em que:
  • As informações aos usuários podem ser fornecidas em scripts diferentes ou em scripts que não sejam latinos.
  • As informações aos usuários podem ser fornecidas em vários idiomas ou em que as entidades podem usar nomes diferentes nesses idiomas (por exemplo, Bruxelas/Brussel/Bruxelles).
• Entidades a serem traduzidas
  • Nomes de agências/paradas/trajetos
  • Letreiros de itinerário de viagens/paradas

Nomes de trajetos, nomes curtos de viagens e letreiros de itinerário

• Os letreiros de itinerário precisam ser fornecidos para todas as viagens em trips.txt (se o letreiro de itinerário permanecer consistente durante toda a viagem) ou em stop_times.txt (se o letreiro de itinerário mudar durante as diferentes etapas da viagem).
• Os letreiros de itinerário precisam corresponder às informações que os usuários podem encontrar no local. Por exemplo, letreiros de itinerário mostrados no veículo ou em placas.
• Quando um trajeto tem um nome, ele precisa ser fornecido como long_name em routes.txt.
• Quando um trajeto tem um número específico ou um identificador alfanumérico que se aplica a todas as viagens nesse trajeto e em ambas as direções, ele precisa ser fornecido como short_name em routes.txt.
• Quando as viagens dentro da rota têm identificadores individuais (por exemplo, números de trem), esses identificadores precisam ser fornecidos como nomes curtos de viagens.
• Para serviços de longa distância que não têm números ou nomes de trajetos, a escolha de um nome de trajeto se torna problemática. A diretriz geral nessas situações é que uma combinação do nome do trajeto e do letreiro de itinerário ajude o usuário a identificar o veículo de forma inequívoca. Por exemplo, o nome da agência operadora pode ser usado como o nome da rota, enquanto o destino da viagem (se mostrado no veículo) precisa ser usado como o letreiro de itinerário da viagem.

Exemplos

• Trem Kamayani Express 11071 das ferrovias indianas de Mumbai para Varanasi. Observação: o número 11071 identifica uma viagem de trem específica de Mumbai para Varanasi, não o trajeto em si.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Um ônibus de Buenos Aires para Córdoba operado pela Chevallier Bus. Observação: o ônibus que operou esse serviço não mostra um nome de trajeto específico. Em vez disso, ele mostra o nome da agência operadora e o destino. Essa viagem específica não tem um número/identificador individual que a distinga de outras viagens operadas pela mesma agência ou que atendam ao mesmo trajeto. Nesse caso, é aceitável usar "Chevallier" como o nome da agência (em agencies.txt) e o nome longo do trajeto (em routes.txt). O destino precisa ser usado para o letreiro de itinerário. trip_short_name precisa permanecer vazio.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

Horários de parada

arrival_time e departure_time precisam ser fornecidos em stop_times.txt.

Estrutura da viagem

• Viagens de longa distância que atendem a várias cidades/áreas precisam ser fornecidas de ponta a ponta sem segmentação (por exemplo, A->B->C não [A->B,A->C,B->C]), em que A, B, C são áreas da cidade. Por exemplo, um ônibus de longa distância que viaja de Buenos Aires para Córdoba, com uma parada em Rosário, precisa ser representado como uma viagem com paradas nessas três cidades, não como três viagens "Buenos Aires - Rosário", "Buenos Aires - Córdoba" e "Rosário - Córdoba".
• Nos casos em que o provedor de dados não consegue receber as informações sobre a estrutura correta da viagem, viagens segmentadas de cidade para cidade podem ser fornecidas caso a caso. Se essas viagens de cidade para cidade tiverem vários pontos de embarque ou desembarque em uma cidade (área da cidade), a segmentação de parada para parada não será permitida. Todos os pontos de embarque e desembarque precisam ser listados em uma única viagem.

Estruturas de estações

Para estações grandes que têm várias plataformas/baias, as relações entre estação e plataforma precisam ser especificadas no feed, e baias/plataformas específicas precisam ser identificadas pelo campo platform_code em stops.txt. Os veículos que partem ou chegam consistentemente a uma baia ou plataforma específica precisam ser vinculados a essa baia ou plataforma no feed GTFS. Se a plataforma ou baia de partida ou chegada mudar em diferentes dias/horários de partida, essas informações poderão ser fornecidas em tempo real da GTFS.

Locais de estações/paradas

• Para estações grandes que têm várias plataformas ou baias, o local da estação precisa ser definido como o local da entrada de pedestres mais proeminente (se a estação tiver um prédio ou uma estrutura) ou como o local da área de espera de passageiros (para estações ao ar livre).
• Para paradas menores na beira da estrada, o local de uma parada precisa ser definido como o local do poste de ônibus quando um puder ser identificado. Quando um poste de ônibus específico não puder ser identificado, o local precisará ser colocado no lado correto da estrada e nas proximidades do local real ao longo da estrada (idealmente, em um raio de 10 metros) onde o veículo para.

Extensões adicionais da GTFS

Necessário apenas para parceiros que querem mostrar informações de preço/disponibilidade implementando as APIs de parceiros.

Extensão de venda de passagens do Google Transit

• Os parceiros precisam implementar a especificação da extensão de venda de passagens do Google Transit que é um subconjunto da extensão de venda de passagens da GTFS.
• Impomos os seguintes requisitos aos IDs de venda de ingressos:
  • Os IDs de venda de ingressos precisam ser estáveis (ou seja, podem mudar com pouca frequência, por um bom motivo). Nos casos em que os IDs de venda de ingressos mudam, a compatibilidade com versões anteriores será necessária (pelo período mínimo de pelo menos uma semana).
  • Para determinar os parâmetros da SegmentKey nas solicitações de API, ticketing_trip_id (em trips.txt) e ticketing_stop_id (em ticketing_identifiers.txt) são obrigatórios. O fallback em stop_sequence indisponível porque não é estável.

GTFS-Fares v1

A referência da GTFS estática especifica os arquivos opcionais fare_attributes.txt e fare_rules.txt. Se um parceiro fizer a integração com as APIs de parceiros, esses arquivos não precisarão ser fornecidos.