Visão geral

Referência da GTFS (Especificação Geral sobre Feeds de Transporte Público)

Este documento explica os tipos de arquivos que constituem um feed de transporte público GTFS e define os campos usados em todos esses arquivos.

Índice

  1. Definições de termos
  2. Arquivos de feed
  3. Requisitos para os arquivos
  4. Definições de campos

Definições de termos

Esta seção define os termos usados ao longo deste documento.

  • Campo obrigatório: a coluna do campo precisa ser incluída no seu feed e deve ser fornecido um valor para cada registro. Alguns campos obrigatórios permitem strings vazias como valor. Para inserir uma string vazia, simplesmente omita qualquer texto entre as vírgulas do campo, já que "0" é interpretado como uma "string de valor 0" e não como uma string vazia. Para detalhes sobre o campo, consulte sua definição.
  • Campo opcional: a coluna do campo pode ser omitida do seu feed. Se você optar por incluir uma coluna opcional, cada registro do seu feed precisa ter um valor para essa coluna. Você pode incluir uma string vazia como valor para registros que não tenham valores na coluna. Alguns campos opcionais permitem strings vazias como valor. Para inserir uma string vazia, simplesmente omita qualquer texto entre as vírgulas do campo, já que "0" é interpretado como uma "string de valor 0" e não como uma string vazia.
  • Campo obrigatório sob certas condições: o campo ou arquivo é necessário mediante determinadas condições descritas nos Detalhes de cada um deles. Fora dessas condições, o campo ou arquivo é opcional.
  • Exclusivo do conjunto de dados: o campo contém um valor associado a uma entidade única e distinta na coluna. Por exemplo, se um trajeto recebe o ID 1A, nenhum outro trajeto pode usar esse ID de trajeto. No entanto, você pode atribuir o ID 1A a um local, porque os locais são um tipo de entidade diferente dos trajetos.

Arquivos de feed

Esta especificação define os seguintes arquivos juntamente com seu conteúdo relacionado:

Nome do arquivo Obrigatório Define
agency.txt Obrigatório Uma ou mais agências de transporte público que fornecem os dados nesse feed.
stops.txt Obrigatório Locais individuais em que os veículos pegam ou deixam passageiros.
routes.txt Obrigatório Trajetos de transporte público. Um trajeto é um grupo de viagens exibidas aos viajantes como um único serviço.
trips.txt Obrigatório As viagens de cada trajeto. Uma viagem é uma sequência de duas ou mais paradas que ocorrem em um horário específico.
stop_times.txt Obrigatório Horários de partida e chegada dos veículos em paradas específicas em cada viagem.
calendar.txt Obrigatório sob certas condições Datas para IDs de serviço que usam uma programação semanal. Especifica quando o serviço começa e termina, bem como os dias da semana em que está disponível. Esse arquivo é obrigatório, a menos que todas as datas de serviço estejam definidas em calendar_dates.txt.
calendar_dates.txt Obrigatório sob certas condições Exceções para os IDs de serviço definidos no arquivo calendar.txt. Se calendar.txt for omitido, calendar_dates.txt será obrigatório e deverá conter todas as datas de serviço.
fare_rules.txt Opcional Regras para implementação das informações de tarifa dos trajetos de uma empresa de transporte público.
shapes.txt Opcional Regras para desenhar linhas em um mapa para representar os trajetos de uma empresa de transporte público.
frequencies.txt Opcional Intervalo entre as viagens nos trajetos com frequência variável de serviço.
transfers.txt Opcional Regras para conexões em pontos de baldeação entre os trajetos.
feed_info.txt Opcional Informações adicionais sobre o feed, incluindo editor, versão e informações sobre validade.

Requisitos para os arquivos

Os requisitos a seguir aplicam-se aos formatos e ao conteúdo dos seus arquivos:

  • Todos os arquivos de um feed General Transit Feed Spec (GTFS) precisam ser salvos como texto delimitado por vírgulas.
  • A primeira linha de cada arquivo precisa conter nomes de campos. Cada subseção da seção Definições de campo corresponde a um dos arquivos em um feed de transporte público e relaciona os nomes dos campos que você pode usar nesse arquivo.
  • Todos os nomes de campo fazem distinção entre maiúsculas e minúsculas.
  • Os valores de campo podem não conter tabulação, retornos de carro nem novas linhas.
  • Os valores de campo que contêm aspas ou vírgulas precisam ser colocados entre aspas. Além disso, cada aspa no valor do campo precisa ser precedida por outra aspa. Isso é consistente com o modo como o Microsoft Excel gera arquivos delimitados por vírgula (CSV). Para mais informações sobre o formato de arquivo CSV, consulte http://tools.ietf.org/html/rfc4180. O exemplo a seguir demonstra como o valor de um campo seria exibido em um arquivo delimitado por vírgula:
    • Valor original do campo: Contains "quotes", commas and text
    • Valor do campo no arquivo CSV: "Contains ""quotes"", commas and text"
  • Os valores do campo não podem conter tags HTML, comentários nem sequências de escape.
  • Remova todos os espaços excedentes entre os campos ou nomes de campo. Muitos analisadores consideram os espaços como parte do valor, o que pode causar erros.
  • Cada linha precisa terminar com um caractere de fim de linha CRLF ou LF.
  • Os arquivos precisam ser codificados em UTF-8 para aceitar todos os caracteres Unicode. São aceitos arquivos que incluem caracteres BOM (byte-order mark) Unicode. Consulte as Perguntas frequentes sobre Unicode para mais informações sobre o caractere BOM e UTF-8.
  • Compacte os arquivos do seu feed.

Definições de campos

agency.txt

Arquivo: obrigatório

Nome do campo Obrigatório Detalhes
agency_id Opcional O campo agency_id é um ID que identifica de modo exclusivo uma agência de transporte público. Um feed de transporte público pode representar dados de mais de uma agência. O agency_id é exclusivo de cada conjunto de dados. Este campo é opcional para feeds de transporte público que contenham somente dados de uma única agência.
agency_name Obrigatório O campo agency_name contém o nome completo da agência de transporte público. O Google Maps exibirá esse nome.
agency_url Obrigatório O campo agency_url contém o URL da agência de transporte público. O valor precisa ser um URL completo incluindo http:// ou https:// e quaisquer caracteres especiais no URL precisam incluir os caracteres de escape necessários. Consulte uma descrição de como criar valores de URLs completos em http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
agency_timezone Obrigatório O campo agency_timezone contém o fuso horário do local onde a agência de transporte público está localizada. Os nomes de fuso horário nunca contêm o caractere de espaço, mas podem conter um espaço sublinhado. Consulte uma lista de valores válidos em http://en.wikipedia.org/wiki/List_of_tz_zones. Se várias agências são especificadas no feed, elas precisam ter o mesmo agency_timezone.
agency_lang Opcional O campo agency_lang contém um código de idioma IETF BCP 47 que especifica o idioma principal utilizado pela agência de transporte público. Esta configuração ajuda os consumidores da GTFS a escolherem regras para o uso de letras maiúsculas e minúsculas e outras configurações específicas do idioma para o feed. Para uma introdução ao IETF BCP 47, consulte http://www.rfc-editor.org/rfc/bcp/bcp47.txt e http://www.w3.org/International/articles/language-tags/.
agency_phone Opcional O campo agency_phone contém um único número de telefone da agência especificada. Este campo é um valor de string que apresenta o número do telefone como é usado na área de serviço da agência. Ele pode e deve conter marcas de pontuação para agrupar os dígitos do número. É permitido usar texto discável (por exemplo, "503-238-RIDE" do TriMet ), mas o campo não pode conter nenhum outro texto descritivo.
agency_fare_url Opcional O campo agency_fare_url especifica o URL de uma página da Web que permite que um passageiro compre passagens ou outros instrumentos de tarifas dessa agência on-line. O valor precisa ser um URL completo incluindo http:// ou https:// e quaisquer caracteres especiais no URL precisam incluir os caracteres de escape necessários. Consulte uma descrição de como criar valores de URLs completos em http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
agency_email Opcional Contém um único endereço de e-mail válido monitorado ativamente pelo departamento de atendimento ao cliente da agência. Esse endereço de e-mail será considerado um ponto de contato direto pelo qual passageiros de transporte público podem falar com um representante de atendimento ao cliente da agência.

stops.txt

Arquivo: obrigatório

Nome do campo Obrigatório Detalhes
stop_id Obrigatório O campo stop_id contém um ID que identifica de forma exclusiva uma parada, estação ou entrada de estação. Diversos trajetos podem usar a mesma parada. O stop_id é usado pelos sistemas como um identificador interno desse registro (por exemplo, como a chave primária no banco de dados). Portanto, o stop_id precisa ser exclusivo para cada conjunto de dados.
stop_code Opcional O campo stop_code contém um texto curto ou um número que identifica exclusivamente a parada para os passageiros. Os códigos de parada quase sempre são usados em sistemas de informações de transporte público por telefone ou impressos em placas de paradas. Seu objetivo é facilitar a busca dos passageiros por informações de um horário de parada ou de chegada em tempo real de uma parada específica. O campo stop_code contém um texto curto ou um número que identifica exclusivamente a parada para os passageiros. O stop_code pode ser igual ao stop_id, caso seja voltado para o passageiro. Este campo precisa ser deixado em branco no caso de paradas que não apresentam um código aos passageiros.
stop_name Obrigatório O campo stop_name contém o nome de uma parada, estação ou entrada de estação. Use um nome compreensível para as pessoas locais e linguagem turística.
stop_desc Opcional O campo stop_desc contém uma descrição da parada. Forneça informações úteis e de qualidade. Não basta repetir o nome da parada.
stop_lat Obrigatório O campo stop_lat contém a latitude de uma parada, estação ou entrada de estação. O valor do campo precisa ser uma latitude WGS84 válida.
stop_lon Obrigatório O campo stop_lon contém a longitude de uma parada, estação ou entrada de estação. O valor do campo precisa ser uma longitude WGS84 válida de -180 a 180.
zone_id Opcional O campo zone_id define a zona tarifária de um ID de parada. Esses IDs são obrigatórios para fornecer informações de tarifa usando fare_rules.txt. Se este ID de parada representar uma estação, o ID de zona será ignorado.
stop_url Opcional O campo stop_url contém o URL de uma página da web sobre uma parada específica. Ele deve ser diferente dos campos agency_url e route_url. O valor precisa ser um URL completo incluindo http:// ou https:// e quaisquer caracteres especiais no URL precisam incluir os caracteres de escape necessários. Consulte uma descrição de como criar valores de URLs completos em http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
location_type Opcional O campo location_type identifica se este ID de parada representa uma parada, estação ou entrada de estação. Se não for especificado nenhum tipo de local ou se o campo location_type estiver em branco, os IDs de parada serão tratados como paradas. As estações talvez tenham propriedades diferentes das paradas quando forem representadas em um mapa ou usadas em um planejamento de viagem. O campo de tipo de local pode ter os seguintes valores:
* 0 ou em branco: parada. Um local em que os passageiros embarcam ou desembarcam de um veículo de transporte público.
* 1: estação. Uma estrutura ou área física que contém uma ou mais paradas.
* 2: entrada/saída de estação. Local na rua em que passageiros podem entrar ou sair de uma estação. A entrada da parada também precisa especificar um valor parent_station que faz referência ao ID de parada da estação principal da entrada.
parent_station Opcional No caso de paradas fisicamente localizadas dentro de estações, o campo parent_station identifica a estação associada à parada. Para usar este campo, o stops.txt também precisa conter uma linha onde tenha sido atribuído o valor 1 para o campo location_type desse ID de parada.
Este ID de parada representa... O tipo de local desta entrada... O campo parent_station desta entrada contém...
Uma parada localizada dentro de uma estação. 0 ou vazio O ID de parada da estação onde esta parada está localizada. A parada indicada por parent_station precisa ter location_type=1.
Uma parada localizada fora de uma estação. 0 ou vazio Um valor vazio. O campo parent_station não se aplica a esta parada.
Uma estação. 1 Um valor vazio. As estações não podem conter outras estações.
stop_timezone Opcional O campo stop_timezone contém o fuso horário de onde a parada ou estação está localizada. Consulte uma lista de valores válidos na lista de fusos horários da Wikipedia. Quando ele é omitido, considera-se que a parada esteja no fuso horário especificado em agency_timezone no arquivo agency.txt. Quando uma parada tem uma estação principal, considera-se que a parada esteja no fuso horário especificado pelo valor em stop_timezone. Se a estação principal não tem um valor em stop_timezone, considera-se que as paradas que pertencem a essa estação estejam no fuso horário especificado em agency_timezone, mesmo que as paradas tenham seus próprios valores em stop_timezone. Ou seja, se uma parada específica apresenta um valor parent_station, qualquer valor stop_timezone especificado para essa parada precisa ser ignorado. Mesmo que os valores de stop_timezone sejam fornecidos no arquivo "stops.txt", é preciso especificar os horários no arquivo stop_times.txt como um horário após a meia-noite no fuso especificado pelo campo agency_timezone em "agency.txt". Isso garante que os valores de horário de uma viagem sempre aumentam ao longo de uma viagem, independentemente dos fusos horários que a viagem percorre.
wheelchair_boarding Opcional O campo wheelchair_boarding identifica se é possível embarcar utilizando cadeira de rodas na parada, estação ou entrada de estação especificada. O campo pode ter os seguintes valores:
* 0 (ou vazio): indica que não há informações sobre acessibilidade para essa parada.
* 1: indica que alguns veículos nessa parada podem ser embarcados por um passageiro em cadeira de rodas.
* 2: não há embarque de cadeirantes nessa parada
Quando uma parada faz parte de um complexo de estações maiores, como indicado por uma parada com um valor parent_station, o campo wheelchair_boarding da parada apresenta a seguinte semântica adicional:
* 0 (ou vazio): a parada herdará o valor de wheelchair_boarding da estação principal, se especificado.
* 1: existem vias de acesso na parte externa da estação para a parada/plataforma específica.
* 2: não há vias de acesso na parte externa da estação para a parada/plataforma específica.
No caso de entradas de estação, o campo wheelchair_boarding apresenta a seguinte semântica adicional:
* 0 (ou vazio): a entrada de estação herdará o valor de wheelchair_boarding da estação principal, se especificado.
* 1: a entrada da estação é acessível para cadeiras de rodas (por exemplo, está disponível um elevador para as plataformas caso elas estejam em outro nível).
* 2: não há vias de acesso da entrada da estação até as plataformas da estação.
platform_code Opcional O identificador de plataforma de uma parada (pertencente a uma estação) em plataforma. Deve conter apenas o identificador da plataforma (por exemplo "G" ou "3"). Palavras como “plataforma” ou "portão" (ou qualquer outra equivalente no idioma utilizado no feed) não devem ser incluídas. Dessa forma, os consumidores do feed podem internacionalizar e localizar mais facilmente o identificador da plataforma em outros idiomas.

routes.txt

Arquivo: obrigatório

Nome do campo Obrigatório Detalhes
route_id Obrigatório O campo route_id contém um ID que identifica exclusivamente um trajeto. O route_id é exclusivo de cada conjunto de dados.
agency_id Opcional O campo agency_id define uma agência para o trajeto especificado. Esse valor é indicado no arquivo agency.txt. Use este campo quando estiver fornecendo dados para trajetos de mais de uma agência.
route_short_name Obrigatório sob certas condições O route_short_name contém o nome abreviado de um trajeto. Ele normalmente será um identificador curto e abstrato, como "32", "100X" ou "verde" que os passageiros usam para identificar um trajeto, mas que não apresenta qualquer indicação sobre os locais atendidos pelo trajeto. Deve ser especificado pelo menos um dos campos route_short_name ou route_long_name. Se adequado, ambos podem ser especificados. Se o trajeto não tiver um nome abreviado, especifique um route_long_name e use uma string vazia como valor para este campo.
route_long_name Obrigatório sob certas condições O route_long_name contém o nome completo de um trajeto. Esse nome geralmente é mais descritivo que o route_short_name e quase sempre inclui o destino ou a parada do trajeto. Deve ser especificado pelo menos um dos campos route_short_name ou route_long_name. Se adequado, ambos podem ser especificados. Se o trajeto não tiver um nome completo, especifique um route_short_name e use uma string vazia como valor para este campo.
route_desc Opcional O campo route_desc contém uma descrição do trajeto. Forneça informações úteis e de qualidade. Não basta repetir o nome do trajeto. Por exemplo "Os trens da linha Azul operam entre a estação Tucuruvi e a estação Jabaquara. É possível fazer conexão com a linha Verde nas estações Paraíso e Ana Rosa. A conexão com a linha Vermelha é feita na estação da Sé. Na estação da Luz é possível fazer conexão com as seguintes linhas da CPTM: Coral, Rubi e Turquesa."
route_type Obrigatório O campo route_type descreve o tipo de transporte usado em um trajeto. Os valores válidos deste campo são:
* 0: bonde com cabo suspenso, ônibus elétrico, veículo leve sobre trilhos. Qualquer veículo leve sobre trilhos ou sistema de transporte de superfície em uma área metropolitana.
* 1: metrô, trem subterrâneo. Qualquer sistema de transporte subterrâneo sobre trilhos dentro de uma área metropolitana.
* 2: via férrea. Usado para viagens intermunicipais ou de longa distância.
* 3: ônibus. Usado para trajetos de ônibus curtos e de longa distância.
* 4: balsa. Usado para serviço de navegação de curta e longa distância.
* 5: bonde a cabo. Usado para bondes no nível da rua com um cabo que passa por baixo deles.
* 6: teleférico. Usado para transporte por cabo em que cabines, carros ou gôndolas são rebocados por um ou vários cabos sem tocar o solo.
* 7: funicular. Qualquer sistema ferroviário que utilize tração por cabo para se deslocar em inclinações íngremes.
route_url Opcional O campo route_url contém o URL de uma página da Web sobre um trajeto específico. Ele deve ser diferente do agency_url. O valor precisa ser um URL completo incluindo http:// ou https:// e quaisquer caracteres especiais no URL precisam incluir os caracteres de escape necessários. Consulte uma descrição de como criar valores de URLs completos em http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
route_color Opcional Nos sistemas com cores atribuídas aos trajetos, o campo route_color define uma cor que corresponde ao trajeto. A cor precisa ser um número hexadecimal com seis caracteres, por exemplo, 00FFFF. Se nenhuma cor for especificada, a cor do trajeto padrão será a branca (FFFFFF). A diferença de cores entre route_color e route_text_color deve ter contraste suficiente com uma tela em preto e branco. As Técnicas do W3C para avaliação de acessibilidade e ferramentas de reparo oferece um algoritmo útil para avaliar o contraste de cores. Existem também ferramentas on-line úteis para escolher cores de contraste, incluindo o aplicativo de verificação de contraste de cores snook.ca.
route_text_color Opcional O campo route_text_color pode ser usado para especificar uma cor legível a ser usada em texto desenhado sobre um fundo de route_color. A cor precisa ser informada como um número hexadecimal de seis caracteres, por exemplo, FFD700. Se nenhuma cor for especificada, a cor padrão do texto é preto (000000). A diferença de cores entre route_color e route_text_color deve ter contraste suficiente com uma tela em preto e branco.
route_sort_order Opcional O campo route_sort_order pode ser usado para ordenar os trajetos de maneira ideal para apresentação aos clientes. Precisa ser um número inteiro não negativo. Trajetos com valores de route_sort_order menores têm de ser exibidos antes daqueles com valores route_sort_order maiores.

trips.txt

Arquivo: obrigatório

Nome do campo Obrigatório Detalhes
route_id Obrigatório O campo route_id contém um ID que identifica exclusivamente um trajeto. Esse valor é indicado no arquivo routes.txt.
service_id Obrigatório O campo service_id contém um ID que identifica exclusivamente um conjunto de datas em que o serviço estará disponível para um ou mais trajetos. Esse valor é indicado no arquivo calendar.txt ou calendar_dates.txt.
trip_id Obrigatório O campo trip_id contém um ID que identifica uma viagem. O trip_id é exclusivo de cada conjunto de dados.
trip_headsign Opcional O campo trip_headsign contém o texto exibido em uma placa que identifica o destino da viagem aos passageiros. Use este campo para fazer distinção entre diversos padrões de serviço no mesmo trajeto. Se a placa muda durante uma viagem, você pode modificar o campo trip_headsign especificando valores para o campo stop_headsign em stop_times.txt.
trip_short_name Opcional O campo trip_short_name contém o texto exibido nos horários e mostradores para identificar a viagem aos passageiros, por exemplo, para identificar os números dos trens em viagens de serviços de trens metropolitanos. Se os passageiros não recorrem normalmente aos nomes da viagem, deixe este campo em branco. Um valor trip_short_name, se for fornecido, deverá identificar exclusivamente uma viagem no dia do serviço. Ele não deve ser usado para nomes de destino nem designações limitadas/expressas.
direction_id Opcional O campo direction_id contém um valor binário que indica a direção do percurso de uma viagem. Use este campo para distinguir viagens bidirecionais com o mesmo route_id. Este campo não é usado para criar itinerários. Ele permite diferenciar as viagens por direção no momento de publicar as tabelas de horários. Você pode especificar nomes para cada direção com o campo trip_headsign.
* 0: viagem em uma direção (por exemplo, só ida).
* 1: viagem na direção oposta (por exemplo, só volta).
Por exemplo, você pode usar os campos trip_headsign e direction_id juntos para atribuir um nome à viagem em cada direção de um conjunto de viagens. Um arquivo trips.txt pode conter as seguintes linhas para uso em tabelas de horários:
* trip_id,...,trip_headsign,direction_id
* 1234,...,Airport,0
* 1505,...,Downtown,1
block_id Opcional O campo block_id identifica o bloco ao qual pertence a viagem. Um bloco consiste em uma única viagem, ou várias viagens sequenciais, feitas usando o mesmo veículo e definida pelo dia do serviço compartilhado e block_id. Um block_id pode ter viagens com diferentes dias de serviço, criando blocos distintos. Veja um exemplo abaixo.
shape_id Opcional O campo shape_id contém um ID que define um polígono para a viagem. Esse valor é indicado no arquivo shapes.txt. O arquivo shapes.txt permite definir como será traçada uma linha no mapa para representar uma viagem.
wheelchair_accessible Opcional * 0 (ou vazio): indica que não há informações sobre acessibilidade para viagens.
* 1: indica que o veículo usado nessa viagem específica pode acomodar pelo menos um passageiro em cadeira de rodas.
* 2: indica que não é possível acomodar cadeirantes nessa viagem.
bikes_allowed Opcional 0 (ou vazio): indica que não há informações sobre bicicletas para a viagem.
*1: indica que o veículo que está sendo usado nesta viagem específica pode acomodar, pelo menos, uma bicicleta.
* 2: indica que não são permitidas bicicletas nesta viagem.

Exemplo de blocos e dia de serviço

O exemplo abaixo é válido e inclui blocos distintos para cada dia da semana.

route_id trip_id service_id block_id (horário da primeira parada) (horário da última parada)
vermelho viagem_1 seg-ter-qua-qui-sex-sab-dom vermelho_circular 22:00:00 22:55:00
vermelho viagem_2 sex-sab-dom vermelho_circular 23:00:00 23:55:00
vermelho viagem_3 sex-sab vermelho_circular 24:00:00 24:55:00
vermelho viagem_4 seg-ter-qua-qui vermelho_circular 20:00:00 20:50:00
vermelho viagem_5 seg-ter-qua-qui vermelho_circular 21:00:00 21:50:00

Observações sobre a tabela acima: * Na madrugada de sexta-feira para sábado, um único veículo opera na viagem_1, viagem_2 e viagem_3 (das 22h às 0h55). A última viagem ocorre no sábado, entre 0h e 0h55, mas faz parte do "dia de serviço" da sexta-feira, já que os horários são de 24:00:00 a 24:55:00. * Na segunda, terça, quarta e quinta-feira, um único veículo opera na viagem_1, viagem_4 e viagem_5 em um bloco das 20h às 22h55.

stop_times.txt

Arquivo: obrigatório

Nome do campo Obrigatório Detalhes
trip_id Obrigatório O campo trip_id contém um ID que identifica uma viagem. Esse valor é indicado no arquivo trips.txt.
arrival_time Obrigatório O campo arrival_time especifica a hora de chegada em uma parada específica, de uma viagem específica, em um trajeto. O tempo é medido de "meio-dia menos 12h" (efetivamente meia-noite, exceto nos dias em que ocorre a mudança do horário de verão), no início da data do dia de serviço. Para horários após a meia-noite, insira-os como um valor maior que 24:00:00 no horário local HH:MM:SS para o dia em que a programação das viagens começa. Se você não tem horários distintos de chegada e partida em uma parada, insira o mesmo valor para arrival_time e departure_time.

Paradas agendadas em que o veículo segue rigorosamente os horários de chegada e partida especificados representam pontos de tempo. Por exemplo, se um veículo de transporte público chega em uma parada antes da hora de partida agendada, ele permanecerá no local até a hora de partida. Se a parada não for programada, use um valor de string vazio para o campo arrival_time ou forneça um horário interpolado. Além disso, indique que os horários interpolados são fornecidos pelo campo timepoint com valor zero. Se os horários interpolados forem indicados com timepoint=0, os pontos de tempo precisarão ser indicados com um valor de 1 no campo timepoint. Forneça horários de chegada para todas as paradas que representam pontos de tempo.

É necessário especificar um horário de chegada para a primeira e última parada de uma viagem. Os horários precisam ter oito dígitos no formato HH:MM:SS (o formato H:MM:SS também é aceito, se a hora iniciar com 0). Não preencha os horários com espaços. As colunas a seguir relacionam os horários das paradas de uma viagem e o modo apropriado de representá-los no campo arrival_time:
Hora Valor de arrival_time
8h10 08:10:00 ou 8:10:00
13h05 13:05:00
19h40 19:40:00
1h55 25:55:00
Observação: viagens que abrangem mais de um dia têm horários de parada superiores a 24:00:00. Por exemplo, se uma viagem é iniciada às 22h30 e termina às 2h15 do dia seguinte, os horários de parada seriam 22:30:00 e 26:15:00. Inserir esses horários de parada como 22:30:00 e 02:15:00 não apresentaria os resultados desejados.
departure_time Obrigatório O departure_time especifica o horário de partida de uma parada específica de uma determinada viagem em um trajeto. O tempo é medido de "meio-dia menos 12h" (efetivamente meia-noite, exceto nos dias em que ocorre a mudança do horário de verão), no início da data do dia de serviço. Para horários após a meia-noite, insira-os como um valor maior que 24:00:00 no horário local HH:MM:SS para o dia em que a programação das viagens começa. Se você não tem horários distintos de chegada e partida em uma parada, insira o mesmo valor para arrival_time e departure_time.

Paradas agendadas em que o veículo segue rigorosamente os horários de chegada e partida especificados representam pontos de tempo. Por exemplo, se um veículo de transporte público chega em uma parada antes da hora de partida agendada, ele permanecerá no local até a hora de partida. Se a parada não for programada, use um valor de string vazio para o campo departure_time ou forneça um horário interpolado. Além disso, indique que os horários interpolados são fornecidos pelo campo timepoint com valor zero. Se os horários interpolados forem indicados com timepoint=0, os pontos de tempo precisarão ser indicados com um valor de 1 no campo timepoint. Forneça horários de partida para todas as paradas que representam pontos de tempo.

É necessário especificar um horário de partida para a primeira e última parada de uma viagem. Os horários precisam ter oito dígitos no formato HH:MM:SS (o formato H:MM:SS também é aceito, se a hora iniciar com 0). Não preencha os horários com espaços. As colunas a seguir relacionam os horários das paradas de uma viagem e o modo apropriado de representá-los no campo departure_time:
Hora Valor de departure_time
8h10 08:10:00 ou 8:10:00
13h05 13:05:00
19h40 19:40:00
1h55 25:55:00
Observação: viagens que abrangem mais de um dia têm horários de parada superiores a 24:00:00. Por exemplo, se uma viagem é iniciada às 22h30 e termina às 2h15 do dia seguinte, os horários de parada seriam 22:30:00 e 26:15:00. Inserir esses horários de parada como 22:30:00 e 02:15:00 não apresentaria os resultados desejados.
stop_id Obrigatório O campo stop_id contém um ID que identifica exclusivamente uma parada. Diversos trajetos podem usar a mesma parada. O stop_id é indicado no arquivo stops.txt. Se location_type é usado em stops.txt, todas as paradas referenciadas em stop_times.txt precisam ter o valor "0" para location_type. Quando possível, os valores de stop_id precisam permanecer consistentes entre as atualizações de feed. Em outras palavras, a parada A com stop_id 1 deve ter stop_id 1 em todas as atualizações de dados subsequentes. Se uma parada não for programada, insira valores vazios em arrival_time e departure_time.
stop_sequence Obrigatório O campo stop_sequence identifica a ordem das paradas de uma viagem específica. Os valores de stop_sequence precisam ser inteiros não negativos e aumentar ao longo da viagem. Por exemplo, a primeira parada da viagem poderia ter stop_sequence igual a 1, a segunda, stop_sequence igual a 23, a terceira, stop_sequence igual a 40, e assim por diante.
stop_headsign Opcional O campo stop_headsign contém o texto exibido em uma placa que identifica o destino da viagem para os passageiros. Use este campo para substituir o trip_headsign padrão quando a placa mudar entre paradas. Se esta placa está associada a uma viagem inteira, use trip_headsign em vez disso.
pickup_type Opcional O campo pickup_type indica se os passageiros embarcam em uma parada como parte do horário programado ou se o embarque na parada não está disponível. Este campo também permite que a agência de transporte público indique que os passageiros precisam ligar para a agência ou avisar ao motorista para agendar o embarque em determinada parada. Os valores válidos deste campo são:
* 0: embarque no horário normal.
* 1: sem embarque disponível.
* 2: necessário ligar para a agência para agendar o embarque.
* 3: necessário combinar com o motorista para agendar o embarque.
O valor padrão deste campo é 0.
drop_off_type Opcional O campo drop_off_type indica se os passageiros desembarcam em uma parada no horário normal ou se o desembarque na parada não está disponível. Este campo também permite que a agência de transporte público indique que os passageiros precisam ligar para a agência ou avisar ao motorista para agendar um desembarque em determinada parada. Os valores válidos deste campo são:
* 0: desembarque no horário normal.
* 1: desembarque não disponível.
* 2: necessário ligar para a agência para agendar o desembarque.
* 3: necessário combinar com o motorista para agendar o desembarque.
O valor padrão deste campo é 0.
shape_dist_traveled Opcional Quando for usado no arquivo stop_times.txt, o campo shape_dist_traveled posiciona uma parada como uma distância a partir do primeiro ponto do polígono. O campo shape_dist_traveled representa a distância real percorrida ao longo do trajeto em unidades, como pés ou quilômetros. Por exemplo, se um ônibus percorre uma distância de 5,25 km do início do polígono até a parada, o shape_dist_traveled do ID da parada seria "5.25". Essas informações permitem que o planejador da viagem determine quanto do polígono precisa ser traçado ao exibir parte de uma viagem no mapa. Os valores usados para shape_dist_traveled precisam aumentar juntamente com a stop_sequence: eles não podem ser usados para exibir a viagem de retorno em um trajeto. As unidades usadas em shape_dist_traveled no arquivo stop_times.txt precisam corresponder às unidades usadas para esse campo no arquivo "shapes.txt".
timepoint Opcional O campo timepoint pode ser usado para indicar se os tempos de chegada e partida especificados de uma parada são rigorosamente respeitados pelo veículo de transporte público ou se são tempos aproximados e/ou interpolados. O campo permite que um produtor de GTFS forneça horários de parada interpolados que potencialmente incorporem conhecimento local, mas que ainda indicam se os tempos são aproximados. No caso de entradas com horários de chegada e partida especificados, os valores válidos para este campo são:
* vazio: os horários são considerados exatos.
* 0: os horários são considerados aproximados.
* 1: os horários são considerados exatos.
No caso de entradas sem horários de chegada e partida especificados, os consumidores de feeds precisam interpolar os horários de chegada e de partida. Os produtores de feeds também têm a opção de indicar que tal entrada não é um horário programado (valor = 0), mas é um erro marcar uma entrada como horário programado (valor = 1) sem especificar os horários de chegada e partida.

calendar.txt

Arquivo: obrigatório sob certas condições

Nome do campo Obrigatório Detalhes
service_id Obrigatório O campo service_id contém um ID que identifica exclusivamente um conjunto de datas em que o serviço estará disponível para um ou mais trajetos. Cada valor de service_id pode aparecer no máximo uma vez em um arquivo calendar.txt. Este valor é exclusivo de cada conjunto de dados. Esse valor é indicado no arquivo trips.txt.
monday Obrigatório O campo monday contém um valor binário que indica se o serviço é válido para todas as segundas-feiras.
* Um valor 1 indica que o serviço está disponível todas as segundas-feiras do período. O período é especificado usando os campos start_date e end_date.
* Um valor 0 indica que o serviço não está disponível nas segundas-feiras do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
tuesday Obrigatório O campo tuesday contém um valor binário que indica se o serviço é válido para todas as terças-feiras.
Um valor 1 indica que o serviço está disponível todas as terças-feiras do período. O período é especificado usando os campos start_date e end_date.
Um valor 0 indica que o serviço não está disponível nas terças-feiras do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
wednesday Obrigatório O campo wednesday contém um valor binário que indica se o serviço é válido para todas as quartas-feiras.
Um valor 1 indica que o serviço está disponível todas as quartas-feiras do período. O período é especificado usando os campos start_date e end_date.
Um valor 0 indica que o serviço não está disponível nas quartas-feiras do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
thursday Obrigatório O campo thursday contém um valor binário que indica se o serviço é válido para todas as quintas-feiras.
Um valor 1 indica que o serviço está disponível todas as quintas-feiras do período. O período é especificado usando os campos start_date e end_date.
Um valor 0 indica que o serviço não está disponível nas quintas-feiras do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
friday Obrigatório O campo friday contém um valor binário que indica se o serviço é válido para todas as sextas-feiras.
Um valor 1 indica que o serviço está disponível todas as sextas-feiras do período. O período é especificado usando os campos start_date e end_date.
Um valor 0 indica que o serviço não está disponível nas sextas-feiras do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
saturday Obrigatório O campo saturday contém um valor binário que indica se o serviço é válido para todos os sábados.
Um valor 1 indica que o serviço está disponível todos os sábados do período. O período é especificado usando os campos start_date e end_date.
Um valor 0 indica que o serviço não está disponível nos sábados do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
sunday Obrigatório O campo sunday contém um valor binário que indica se o serviço é válido para todos os domingos.
Um valor 1 indica que o serviço está disponível todos os domingos do período. O período é especificado usando os campos start_date e end_date.
Um valor 0 indica que o serviço não está disponível nos domingos do período.
Observação: você pode indicar exceções para datas específicas, como feriados, no arquivo calendar_dates.txt.
start_date Obrigatório O campo start_date contém a data de início do serviço. O valor do campo start_date precisa estar no formato AAAAMMDD.
end_date Obrigatório O campo end_date contém a data de término do serviço. Essa data está incluída no intervalo do serviço. O valor do campo end_date precisa estar no formato AAAAMMDD.

calendar_dates.txt

Arquivo: obrigatório sob certas condições

A tabela "calendar_dates" permite ativar ou desativar explicitamente os IDs de serviço por data. Você pode usá-la de duas maneiras.

  • Recomendada: use o arquivo "calendar_dates.txt" com o calendar.txt, onde o "calendar_dates.txt" determina todas as exceções às categorias de serviço padrão, definidas no arquivo calendar.txt. Esta é uma boa abordagem se seu 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).
  • Alternativa: omita o calendar.txt e inclua TODAS as datas do serviço em calendar_dates.txt. Se o horário varia na maioria dos dias do mês ou se você quer programar datas do serviço sem especificar um horário semanal normal, esta abordagem pode ser a preferencial.
Nome do campo Obrigatório Detalhes
service_id Obrigatório O service_id contém um ID que identifica exclusivamente um conjunto de datas em que uma exceção do serviço está disponível para um ou mais trajetos. Cada par (service_id, date) pode aparecer somente uma vez em calendar_dates.txt. Se um valor de service_id aparece nos arquivos calendar.txt e calendar_dates.txt, as informações contidas em calendar_dates.txt modifica as informações de serviço especificadas em calendar.txt. Esse campo é indicado no arquivo trips.txt.
date Obrigatório O campo date especifica uma data específica quando a disponibilidade do serviço for diferente da norma. Você pode usar o campo exception_type para indicar se o serviço está disponível na data especificada. O valor do campo date precisa estar no formato AAAAMMDD.
exception_type Obrigatório O campo exception_type indica se o serviço está disponível na data especificada no campo date.
* Um valor 1 indica que o serviço foi adicionado para a data especificada.
* Um valor 2 indica que o serviço foi removido para a data especificada.
Por exemplo, suponha que um trajeto tenha um conjunto de viagens disponíveis em feriados e outro conjunto de viagens disponíveis em todos os outros dias. Você poderia ter um service_id que corresponde à programação do serviço regular e outro service_id que corresponde à programação do feriado. Para um feriado específico, você usaria o arquivo calendar_dates.txt para adicionar o feriado ao service_id e para remover o feriado da programação do service_id regular.

fare_attributes.txt

Arquivo: opcional

Nome do campo Obrigatório Detalhes
fare_id Obrigatório O campo fare_id contém um ID que identifica exclusivamente uma classe de tarifa. O fare_id é exclusivo de cada conjunto de dados.
preço Obrigatório O campo price contém o preço da tarifa, na unidade especificada no campo currency_type.
currency_type Obrigatório O campo currency_type define a moeda usada no pagamento da tarifa. Use os códigos de moeda compostos por letras encontrados no seguinte URL: http://en.wikipedia.org/wiki/ISO_4217.
payment_method Obrigatório O campo payment_method indica quando a tarifa precisa ser paga. Os valores válidos deste campo são:
* 0: a tarifa é paga a bordo.
* 1: a tarifa precisa ser paga antes do embarque.
transfers Obrigatório O campo transfers especifica o número de baldeações permitidas nesta tarifa. Os valores válidos deste campo são:
* 0: não são permitidas baldeações nesta tarifa.
* 1: os passageiros só podem fazer uma baldeação.
* 2: os passageiros podem fazer duas baldeações.
* (vazio): se o campo estiver vazio, não haverá limite para baldeações.
agency_id Opcional Obrigatório em feeds com várias agências definidas no arquivo agency.txt. Cada atributo de tarifa precisa especificar um valor de agency_id para indicar à qual agência se aplica a tarifa.
transfer_duration Opcional O campo transfer_duration especifica em segundos o período de validade de uma baldeação. Quando usado com um valor 0 em transfers, o campo transfer_duration indica por quanto tempo o bilhete é válido para uma tarifa quando não forem permitidas baldeações. A não ser que você pretenda usar este campo para indicar a validade do bilhete, transfer_duration deve ser omitido ou estar vazio quando transfers é definido como 0.

fare_rules.txt

Arquivo: opcional

A tabela fare_rules permite especificar como serão aplicadas as tarifas do arquivo fare_attributes.txt a um itinerário. A maioria das estruturas de tarifas usa alguma combinação das seguintes regras:

  • A tarifa depende das estações de origem e destino.
  • A tarifa depende das zonas por onde passa o itinerário.
  • A tarifa depende do trajeto usado pelo itinerário.

Para ver exemplos que demonstram como especificar uma estrutura tarifária com os arquivos fare_rules.txt e fare_attributes.txt, consulte FareExamples no wiki do projeto de código aberto GoogleTransitDataFeed.

Nome do campo Obrigatório Detalhes
fare_id Obrigatório O campo fare_id contém um ID que identifica exclusivamente uma classe de tarifa. Esse valor é indicado no arquivo fare_attributes.txt.
route_id Opcional O campo route_id associa o ID da tarifa a um trajeto. Os IDs de trajeto são indicados no arquivo routes.txt. Se você tiver diversos trajetos com os mesmos atributos de tarifa, crie uma linha para cada trajeto no arquivo fare_rules.txt.
Por exemplo, se a classe de tarifa "b" for válida no trajeto "TSW" e "TSE", o arquivo fare_rules.txt conteria estas linhas para a classe de tarifa:
b,TSW
b,TSE
origin_id Opcional O campo origin_id associa o ID da tarifa a um ID de zona de origem. Os IDs de zona são indicados no arquivo stops.txt. Se você tiver diversos IDs de origem com os mesmos atributos de tarifa, crie uma linha para cada ID de origem no arquivo fare_rules.txt.
Por exemplo, se uma classe de tarifa "b" for válida para todas as viagens iniciadas na zona "2" ou na zona "8", o arquivo fare_rules.txt conteria estas linhas para a classe de tarifa:
b, , 2
b, , 8
destination_id Opcional O campo destination_id associa o ID da tarifa a um ID de zona de destino. Os IDs de zona são indicados no arquivo stops.txt. Se você tiver diversos IDs de destino com os mesmos atributos de tarifa, crie uma linha para cada ID de destino em fare_rules.txt.
Por exemplo, você pode usar os campos origin_ID e destination_ID juntos para especificar que a classe de tarifa "b" é válida para viajar entre as zonas 3 e 4 e para viajar entre as zonas 3 e 5. O arquivo fare_rules.txt conteria estas linhas para a classe de tarifa:
b, , 3,4
b, , 3,5
contains_id Opcional O campo contains_id associa o ID da tarifa a um ID de zona, indicado no arquivo stops.txt. O ID de tarifa é associado então a itinerários que passam em cada zona contains_id.
Por exemplo, se a classe de tarifa "c" estiver associada a todas as viagens do trajeto GRT que passam pelas zonas 5, 6 e 7, o fare_rules.txt conteria estas linhas:
c,GRT,,,5
c,GRT,,,6
c,GRT,,,7
Como todas as zonas contains_id precisam corresponder à tarifa a ser aplicada, um itinerário que passa pelas zonas 5 e 6 mas não pela zona 7 não teria a classe de tarifa "c". Para mais detalhes, veja FareExamples no wiki do projeto GoogleTransitDataFeed.

shapes.txt

Arquivo: opcional

Polígonos descrevem o caminho físico que um veículo percorre. Eles são definidos no arquivo shapes.txt. Os polígonos pertencem às viagens e consistem em uma sequência de pontos. Traçar·pontos·em·determinada·ordem·cria·o·caminho·do·veículo. Os pontos não precisam corresponder a locais de parada.

Nome do campo Obrigatório Detalhes
shape_id Obrigatório O campo shape_id contém um ID que identifica exclusivamente um polígono.
shape_pt_lat Obrigatório O campo shape_pt_lat associa a latitude de um ponto de polígono ao ID de um polígono. O valor do campo precisa ser uma latitude WGS84 válida. Cada linha do arquivo shapes.txt representa um ponto de polígono na sua definição de polígonos.
Por exemplo, se o polígono "A_shp" tiver três pontos na sua definição, o arquivo shapes.txt deverá conter estas linhas para definir o polígono:
A_shp,37.61956,-122.48161,0
A_shp,37.64430,-122.41070,6
A_shp,37.65863,-122.30839,11
shape_pt_lon Obrigatório O campo shape_pt_lon associa a longitude de um ponto de polígono ao ID de um polígono. O valor do campo precisa ser uma longitude WGS84 válida de -180 a 180. Cada linha do arquivo shapes.txt representa um ponto de polígono na sua definição de polígonos.
Por exemplo, se o polígono "A_shp" tiver três pontos na sua definição, o arquivo shapes.txt deverá conter estas linhas para definir o polígono:
A_shp,37.61956,-122.48161,0
A_shp,37.64430,-122.41070,6
A_shp,37.65863,-122.30839,11
shape_pt_sequence Obrigatório O campo shape_pt_sequence associa a latitude e a longitude de um ponto de polígono à sua ordem sequencial no polígono. Os valores de shape_pt_sequence devem ser inteiros não negativos e precisam aumentar durante a viagem.
Por exemplo, se o polígono "A_shp" tiver três pontos na sua definição, o arquivo shapes.txt deverá conter estas linhas para definir o polígono:
A_shp,37.61956,-122.48161,0
A_shp,37.64430,-122.41070,6
A_shp,37.65863,-122.30839,11
shape_dist_traveled Opcional Quando for usado no arquivo shapes.txt, o campo shape_dist_traveled posiciona um ponto do polígono como uma distância percorrida ao longo de um polígono, a partir do primeiro ponto do polígono. O campo shape_dist_traveled representa a distância real percorrida ao longo do trajeto em unidades, como pés ou quilômetros. Essas informações permitem que o planejador da viagem determine quanto do polígono precisa ser traçado ao exibir parte de uma viagem no mapa. Os valores usados para shape_dist_traveled precisam aumentar juntamente com a shape_pt_sequence: eles não podem ser usados para exibir a viagem de retorno em um trajeto.
As unidades usadas para shape_dist_traveled no arquivo "shapes.txt" precisam corresponder às unidades usadas para esse campo no arquivo stop_times.txt.
Por exemplo, se um ônibus viaja ao longo de três pontos definidos acima para A_shp, os outros valores de shape_dist_traveled (exibidos aqui em quilômetros) seriam semelhantes a estes:
A_shp,37.61956,-122.48161,0,0
A_shp,37.64430,-122.41070,6,6.8310
A_shp,37.65863,-122.30839,11,15.8765

frequencies.txt

Arquivo: opcional

Esta tabela tem o objetivo de representar horários que não tenham uma lista fixa de horários de parada. Quando as viagens são definidas no arquivo "frequencies.txt", o planejador de viagens ignora os valores absolutos dos campos arrival_time e departure_time referentes a essas viagens em stop_times.txt. Em vez desses valores, a tabela stop_times define a sequência de paradas e a diferença de horário entre cada parada.

Nome do campo Obrigatório Detalhes
trip_id Obrigatório O trip_id contém um ID que identifica uma viagem na qual é aplicada a frequência específica do serviço. Os IDs de viagem são indicados no arquivo trips.txt.
start_time Obrigatório O campo start_time especifica o horário em que o primeiro veículo parte da primeira parada da viagem com a frequência especificada. O tempo é medido de "meio-dia menos 12h" (efetivamente meia-noite, exceto nos dias em que ocorre a mudança do horário de verão), no início da data do dia de serviço. Para horários após a meia-noite, insira um valor maior que 24:00:00 no horário local com o formato HH:MM:SS, no dia em que está programado o início da viagem. Por exemplo, 25:35:00.
end_time Obrigatório O campo end_time indica a hora na qual o serviço é alterado para uma frequência diferente (ou é interrompido) na primeira parada da viagem. O tempo é medido de "meio-dia menos 12h" (efetivamente meia-noite, exceto nos dias em que ocorre a mudança do horário de verão), no início da data do dia de serviço. Para horários após a meia-noite, insira um valor maior que 24:00:00 no horário local com o formato HH:MM:SS, no dia em que está programado o início da viagem. Por exemplo, 25:35:00.
headway_secs Obrigatório O campo headway_secs indica a hora entre as saídas da mesma parada (intervalo entre duas viagens) para esse tipo de viagem, durante o intervalo especificado por start_time e end_time. O valor do intervalo de tempo entre duas viagens precisa ser inserido em segundos.
Os períodos no qual são definidos os intervalos entre duas viagens (as linhas do arquivo frequencies.txt) não devem se sobrepor para a mesma viagem, já que é difícil determinar o que deve ser deduzido de dois intervalos entre duas viagens sobrepostos. No entanto, um período de intervalo entre duas viagens pode começar exatamente na mesma hora em que outro terminar, por exemplo:
A, 05:00:00, 07:00:00, 600
B, 07:00:00, 12:00:00, 1200
exact_times Opcional O campo exact_times determina se viagens com base em frequência devem ser programadas com exatidão com base nas informações especificadas sobre intervalos. Os valores válidos deste campo são:
* 0 ou (vazio): as viagens com base em frequência não são programadas com exatidão. Este é o comportamento padrão.
* 1: as viagens com base em frequência são programadas com exatidão. Em uma linha do arquivo frequencies.txt, as viagens são programadas a partir de trip_start_time = start_time + x * headway_secs para todos os x em (0, 1, 2...) em que trip_start_time < end_time.
O valor de exact_times precisa ser o mesmo para todas as linhas de frequencies.txt com o mesmo trip_id. Se exact_times for igual a 1 e uma linha de frequencies.txt tiver um start_time igual a end_time, nenhuma viagem precisará ser programada. Quando exact_times for igual 1, será preciso tomar cuidado para escolher um valor para end_time posterior ao horário de início da última viagem desejada, mas anterior ao horário de início da última viagem desejada + headway_secs.

transfers.txt

Arquivo: opcional

Os planejadores da viagem normalmente calculam os pontos de baldeação com base na proximidade relativa das paradas em cada trajeto. No caso de pares de paradas ou baldeações potencialmente ambíguos, em que você quer especificar uma determinada opção, use o arquivo transfers.txt para definir outras regras para as conexões entre os trajetos.

Nome do campo Obrigatório Detalhes
from_stop_id Obrigatório O campo from_stop_id contém um ID de parada que identifica uma parada ou estação onde é iniciada uma conexão entre trajetos. Os IDs de parada são indicados no arquivo stops.txt. Se o ID de parada indicar uma estação que contenha diversas paradas, esta regra de baldeação é aplicada a todas as paradas dessa estação.
to_stop_id Obrigatório O campo to_stop_id contém um ID de parada que identifica uma parada ou estação onde é encerrada uma conexão entre trajetos. Os IDs de parada são indicados no arquivo stops.txt. Se o ID de parada indicar uma estação que contenha diversas paradas, esta regra de baldeação é aplicada a todas as paradas dessa estação.
transfer_type Obrigatório O campo transfer_type especifica o tipo de conexão do par especificado (from_stop_id, to_stop_id). Os valores válidos deste campo são:
* 0 ou (vazio): este é um ponto de baldeação recomendado entre dois trajetos.
* 1: este é um ponto de baldeação programada entre dois trajetos. O veículo que está partindo aguardará a chegada do outro, com tempo suficiente para que o passageiro possa fazer a baldeação entre os trajetos.
* 2: esta baldeação exige um período mínimo de tempo entre a chegada e a partida para garantir uma conexão. O tempo necessário para a baldeação é especificado por min_transfer_time.
* 3: não é possível fazer baldeações entre trajetos neste local.
min_transfer_time Opcional Quando uma conexão entre trajetos exigir um período de tempo entre a chegada e a partida (transfer_type=2), o campo min_transfer_time definirá o período disponível em um itinerário necessário para permitir uma baldeação entre trajetos nessas paradas. O min_transfer_time precisa ser suficiente para permitir que um passageiro comum se desloque entre as duas paradas, inclusive tempo extra para permitir uma variação de horário em cada trajeto.
O valor de min_transfer_time precisa ser inserido em segundos e deve ser um inteiro não negativo.

feed_info.txt

Arquivo: opcional

O arquivo contém informações sobre o feed, e não sobre os serviços que o feed descreve. Atualmente, a GTFS inclui um arquivo agency.txt para fornecer informações sobre as agências que operam os serviços descritos pelo feed. No entanto, o editor do feed pode ser uma entidade diferente de qualquer uma das agências (em caso de agregadores regionais). Além disso, há campos que se aplicam apenas ao feed, e não a toda a agência.

Nome do campo Obrigatório Detalhes
feed_publisher_name Obrigatório O campo feed_publisher_name contém o nome completo da organização que publica o feed. Ele pode ser igual a um dos valores de agency_name em agency.txt. Os aplicativos que consomem GTFS podem exibir este nome ao concederem atribuições relacionadas aos dados de um determinado feed.
feed_publisher_url Obrigatório O campo feed_publisher_url contém o URL do site da organização que publica o feed. Ele pode ser igual a um dos valores de agency_url em agency.txt. O valor precisa ser um URL completo incluindo http:// ou https:// e quaisquer caracteres especiais no URL precisam incluir os caracteres de escape necessários. Consulte uma descrição de como criar valores de URLs completos em http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
feed_lang Obrigatório O campo feed_lang contém um código de idiomas IETF BCP 47 que especifica o idioma padrão usado para o texto no feed. Esta configuração ajuda os consumidores de GTFS a escolherem regras para o uso de letras maiúsculas e minúsculas e outras configurações específicas do idioma para o feed. Para uma introdução ao IETF BCP 47, consulte http://www.rfc-editor.org/rfc/bcp/bcp47.txt e http://www.w3.org/International/articles/language-tags/.
feed_start_date Opcional O feed fornece informações de programação completas e confiáveis sobre o serviço no período entre o início do dia definido em feed_start_date até o final do dia em feed_end_date. Ambos os dias são fornecidos como datas no formato AAAAMMDD, como em calendar.txt, ou deixados vazios caso não estejam disponíveis. A data em feed_end_date não pode ser anterior à data em feed_start_date caso ambos sejam fornecidos. Os produtores de feeds são encorajados a oferecerem dados de programação fora desse período para informar sobre possíveis serviços no futuro, mas os consumidores de feed devem estar conscientes do seu status não oficial. O fato de feed_start_date ou feed_end_date se estenderem para além das datas de calendário ativas definidas em calendar.txt e calendar_dates.txt será considerado uma afirmação explícita de que não há serviço para as datas do intervalo de feed_start_date ou feed_end_date não incluídas nas datas ativas.
feed_end_date Opcional (veja acima)
feed_version Opcional O editor de feeds pode especificar uma string que indique a versão atual do feed GTFS. Os aplicativos que consomem GTFS podem exibir esse valor para ajudar os editores de feed a determinar se a versão mais recente do feed foi incorporada.
feed_contact_email Opcional Um endereço de e-mail para comunicação sobre as práticas de publicação de dados e conjunto de dados da GTFS. O feed_contact_email informa um contato técnico para aplicativos que consomem GTFS. Envie os dados de contato de atendimento ao cliente por meio do arquivo agency.txt.
feed_contact_url Opcional Um URL para dados de contato, um formulário da Web, suporte técnico ou outras ferramentas de comunicação relacionadas às práticas de publicação de dados e conjunto de dados da GTFS. O feed_contact_url* informa um contato técnico para aplicativos que consomem GTFS. Envie os dados de contato de atendimento ao cliente por meio do arquivo agency.txt.