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 cobrir todos os itinerários que o parceiro quer mostrar. Isso permite que as informações de horários e trajetos sejam exibidas no Google. Se quiser, o parceiro pode mostrar outras informações 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 para a GTFS: siga as práticas recomendadas como se fossem obrigatórias.

Como fazer upload de Feeds GTFS: siga este processo para enviar o feed.

Atualizações: após o upload dos feeds, eles podem 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 cobrir um único país ou uma parte de um país. As viagens que ultrapassam as fronteiras dos países precisam ser fornecidas em feeds separados para todo o continente. Se um Feed GTFS abrange algo além de um país, entre em contato com a equipe de transporte público.
  • Os arquivos no ZIP da GTFS precisam ter menos de 4 GB. Arquivos maiores que isso geralmente são sinal de práticas não recomendadas, como ignorar as opções de compactação oferecidas pelo frequencies.txt ou recursos semelhantes. Isso pode causar problemas durante o processamento. Se você acha que precisa de arquivos com mais de 4 GB, entre em contato com a equipe de transporte de viagens pelo e-mail [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 períodos diferentes não é aceitável.
• Todas as datas de um determinado operador precisam estar em um único feed.

Traduções

• As traduções podem ser fornecidas pelo translations.txt e serão exigidas nos países em que:
  • As informações aos usuários podem ser fornecidas em diferentes scripts ou em outros scripts que não
  • As informações podem ser fornecidas em vários idiomas ou quando as entidades podem usar nomes diferentes nesses idiomas (por exemplo, Bruxelas/Bruxelas/Bruxelles).
• Entidades a serem traduzidas
  • nomes de agências/paradas/trajetos
  • letreiros de viagem/parada

Nomes de trajetos, nomes curtos de viagens e letreiros

• Os letreiros precisam ser fornecidos para todas as viagens em trips.txt (se o letreiro permanecer consistente durante toda a viagem) ou em stop_times.txt (se ele mudar durante diferentes etapas).
• Os letreiros devem corresponder às informações que os usuários podem encontrar no chão. Por exemplo, letreiros exibidos no veículo ou em placas.
• Quando um trajeto tem um nome, ele precisa ser fornecido como o 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 o short_name em routes.txt.
• Quando as viagens no trajeto 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 trajeto, escolher um nome de trajeto se torna um problema. A diretriz geral nessas situações é que uma combinação do nome do trajeto e do letreiro ajuda o usuário a identificar o veículo sem ambiguidade. Por exemplo, o nome da empresa que opera pode ser usado como o nome do trajeto, enquanto o destino da viagem (se exibido no veículo) deve ser usado como o letreiro de itinerário.

Exemplos

• Indian Railways Kamayani Express Train 11071 de Mumbai a Varanasi. Observação: o número 11071 identifica uma viagem de trem específica de Mumbai a Varanasi, não o trajeto em si.
  • routes.txt:
    • nome_curto: <vazio>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • letreiro: Varanasi
• Ônibus de Buenos Aires para Córdoba operado pela Chevallier Bus. Observação: o ônibus que operava esse serviço não mostra um nome de trajeto específico. Em vez disso, exibe o nome da agência de operação e o destino dela. Essa viagem específica não tem um número/identificador individual que a diferencie de outras viagens operadas pela mesma empresa ou que veiculam o mesmo trajeto. Nesse caso, é aceitável usar "Chevallier" como nome da agência (em agencies.txt) e long_name do trajeto (em routes.txt). O destino precisa ser usado no letreiro. O "trip_short_name" precisa permanecer vazio.
  • routes.txt:
    • nome_curto: <vazio>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • letreiro: Córdoba

Horários de parada

O valor de arrival_time e Controlado_de_partida precisa ser informado em stop_times.txt.

Estrutura da viagem

• Viagens de longa distância que atendem várias cidades/áreas precisam ser fornecidas de ponta a ponta sem segmentação (por exemplo,A->B->C e não [A->B,A->C,B->C]), em que A, B e C são áreas urbanas. Por exemplo, um ônibus de longa distância que vai de Buenos Aires a 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 "Rosario - Córdoba".
• Quando o provedor não conseguir as informações sobre a estrutura de viagem correta, as viagens segmentadas de cidade a cidade podem ser fornecidas caso a caso. Se essas viagens tiverem vários pontos de embarque ou desembarque dentro de uma mesma cidade, a segmentação de parada a parada não será permitida. Todos os pontos de partida 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 as baías/plataformas específicas precisam ser identificadas pelo campo platform_code em stops.txt. Veículos que saem ou chegam de forma consistente em uma baía ou plataforma específica precisam ser vinculados a eles no Feed GTFS. Se a plataforma de partida/chegada ou a baía mudarem em diferentes dias/horários de partida, essa informação poderá ser fornecida na GTFS em tempo real.

Locais de estações/paradas

• Em estações grandes que têm várias plataformas ou baías, o local da estação precisa ser definido como o local da entrada de pedestres mais proeminente (se a estação tiver uma construção ou estrutura) ou o local da área de espera de passageiros (para estações ao ar livre).
• Para paradas menores na lateral da estrada, o local de uma parada deve ser definido como o local do ponto de ônibus quando for identificado. Quando um ponto de ônibus específico não pode ser identificado, o local precisa ser posicionado no lado correto da via e dentro das proximidades do local real ao longo da via (de preferência, dentro de 10 m) onde o veículo para.

Extensões adicionais da GTFS

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

Extensão da venda de passagens do Google Transit

• Os parceiros precisam implementar a especificação de extensão de venda de passagens do Google Transit, que é um subconjunto da extensão de venda de passagens da GTFS.
• Aplicamos os seguintes requisitos aos IDs de venda de ingressos:
  • Os códigos de venda de ingressos precisam ser estáveis, ou seja, não podem ser alterados com frequência, por um bom motivo. Quando os IDs de passagens mudarem, será necessária a compatibilidade com versões anteriores (pelo período mínimo de uma semana).
  • Para determinar os parâmetros da SegmentKey em solicitações da API, ticketing_trip_id (em trips.txt) e ticketing_stop_id (em ticketing_identifiers.txt) são obrigatórios. O substituto em stop_sequence não tem suporte 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 se integrar às APIs do parceiro, esses arquivos não poderão ser fornecidos.