Neste documento, definimos o formato e a estrutura dos arquivos que compõem um conjunto de dados GTFS.
Índice
- Definições de termos
- Tipos de campo
- Arquivos de conjunto de dados
- Requisitos dos arquivos
- Definições dos campos
Definições de termos
Nesta seção, definimos os termos usados ao longo deste documento.
- Conjunto de dados: uma coleção completa de arquivos definidos por esta referência de especificação. Alterar o conjunto de dados cria uma nova versão dele. Esses conjuntos precisam ser postados em um URL permanente e público, incluindo o nome do arquivo ZIP, por exemplo, https://www.agency.org/gtfs/gtfs.zip.
- Registro: uma estrutura de dados básica composta por valores de campo diferentes que descrevem uma única entidade, como uma empresa de transporte público, uma parada, um trajeto etc. Ele é representado nas tabelas como uma linha.
- Campo: uma propriedade de um objeto ou uma entidade. Ele é representado nas tabelas como uma coluna.
- Valor do campo: uma entrada individual em um campo. Ele é representado nas tabelas como uma única célula.
- Obrigatório: o campo precisa ser incluído no conjunto de dados, e é necessário informar um valor nesse campo para cada registro. Em alguns campos obrigatórios, é permitido usar uma string vazia como valor, que será referido nesta especificação como vazio. Para inserir uma string vazia, basta omitir qualquer texto entre as vírgulas do campo.
- Opcional: é possível omitir o campo do conjunto de dados. Se você incluir uma coluna opcional, algumas das entradas nesse campo poderão ser strings vazias. Para inserir uma string vazia, basta omitir qualquer texto entre as vírgulas do campo. Um campo omitido é equivalente a um totalmente vazio.
- Obrigatório sob certas condições: o campo ou arquivo é obrigatório sob determinadas condições, que são explicadas no campo ou na descrição do arquivo. Se as condições não se aplicarem, eles serão opcionais.
- Dia de serviço: período usado para indicar o cronograma do trajeto. A definição exata dos dias de serviço varia de acordo com a empresa, mas eles geralmente não correspondem a dias corridos. Esse período poderá exceder 24:00:00 se o serviço começar em um dia e terminar em outro. Por exemplo, a operação de um serviço que funciona das 08:00:00 de sexta às 02:00:00 de sábado pode ser representada como das 08:00:00 às 26:00:00 em um único dia de serviço.
Tipos de campo
- Cor: uma cor codificada como um número hexadecimal de seis dígitos. Consulte https://htmlcolorcodes.com (em inglês) para gerar um valor válido (o "#" inicial não está incluído).
Por exemplo,FFFFFF
para branco,000000
para preto ou0039A6
para as linhas A, C e E da NYMTA. - Código de moeda: um código alfabético ISO 4217 de moeda. Para conferir a lista das moedas atuais, consulte https://pt.wikipedia.org/wiki/ISO_4217.
Por exemplo,CAD
para dólar canadense,EUR
para euro ouJPY
para iene japonês. - Data: dia de serviço no formato
YYYYMMDD
. Como o tempo de um dia de serviço pode ser superior a 24:00:00, ele geralmente contém informações relativas aos dias subsequentes.
Por exemplo,20180913
para 13 de setembro de 2018. - E-mail: um endereço de e-mail.
Por exemplo,example@example.com
. - Enumeração: uma opção originada de um conjunto de constantes predefinidas na coluna "Descrição".
Por exemplo, o camporoute_type
contém0
para bondes ou1
para metrô. - ID: um valor do campo de ID é uma sequência de caracteres UTF-8 que não será exibida aos passageiros. Recomendamos o uso apenas de caracteres ASCII para impressão. Os IDs definidos em um arquivo
.txt
normalmente são referenciados em outro arquivo.txt
.
Por exemplo, o campostop_id
nostops.txt
é um ID, e o campostop_id
nostop_times.txt
é um ID que faz referência astops.stop_id
. - Código de idioma: um código de idioma IETF BCP 47. 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/.
Por exemplo,en
para inglês britânico,en-US
para inglês americano oude
para alemão. - Latitude: uma latitude WGS84 em graus decimais. O valor precisa ser maior ou igual a
-90.0
e menor ou igual a90.0
.
Por exemplo,41.890169
para o Coliseu de Roma. - Longitude: uma longitude WGS84 em graus decimais. O valor precisa ser maior ou igual a
-180.0
e menor ou igual a180.0
.
Por exemplo,12.492269
para o Coliseu de Roma. - Valor flutuante não negativo: um número desse tipo maior ou igual a
0
. - Número inteiro não negativo: um número inteiro maior ou igual a
0
. - Número de telefone: um número de telefone.
- Horário: horário no formato HH:MM:SS (H:MM:SS também é aceito). O tempo é medido a partir de "meio-dia menos 12h" do dia de serviço (efetivamente meia-noite, exceto nos dias em que ocorre a mudança do horário de verão). Veja mais informações no artigo de diretrizes. 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,14:30:00
para 14h30 ou25:35:00
para 1h35 do dia seguinte. - Texto: uma string de caracteres UTF-8 que vai ser mostrada aos passageiros e, portanto, precisa ser legível.
- Fuso horário: fuso horário que corresponde ao especificado em https://www.iana.org/time-zones (em inglês), cujo nome não pode conter caracteres de espaço, mas pode estar sublinhado. Consulte uma lista de valores válidos em http://en.wikipedia.org/wiki/List_of_tz_zones (em inglês).
Por exemplo,Asia/Tokyo
,America/Los_Angeles
ouAfrica/Cairo
. - URL: um URL completo que inclui http:// ou https://. Todos os caracteres especiais contidos nele precisam ter caracteres de escape. Consulte uma descrição de como criar valores de URLs completos em http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
Arquivos de conjunto de dados
Esta especificação define os seguintes arquivos:
Nome do arquivo | Obrigatório | Define |
---|---|---|
agency.txt |
Obrigatório | Empresas de transporte público cujos serviços estão representados neste conjunto de dados. |
stops.txt |
Obrigatório | Paradas onde os veículos pegam ou deixam passageiros. Também define estações e entradas de estações. |
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 durante um período específico. |
stop_times.txt |
Obrigatório | Horários de partida e chegada dos veículos nas paradas específicas de cada viagem. |
calendar.txt |
Obrigatório sob certas condições | Datas de serviço especificadas usando um cronograma semanal com datas de início e término. 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 serviços definidos no calendar.txt . Se calendar.txt for omitido, calendar_dates.txt será obrigatório e precisará conter todas as datas de serviço. |
fare_attributes.txt |
Opcional | Informações sobre tarifas dos trajetos de uma empresa de transporte público. |
fare_rules.txt |
Opcional | Regras para aplicar tarifas a itinerários. |
shapes.txt |
Opcional | Regras para mapear caminhos de viagem de veículos, às vezes chamados de alinhamentos de trajetos. |
frequencies.txt |
Opcional | Intervalo entre as viagens para o serviço com base no intervalo ou uma representação resumida do serviço de cronograma fixo. |
transfers.txt |
Opcional | Regras para conexões em pontos de baldeação entre os trajetos. |
pathways.txt |
Opcional | Caminhos que conectam os locais dentro das estações. |
levels.txt |
Opcional | Níveis dentro das estações. |
feed_info.txt |
Obrigatório sob certas condições | Metadados do conjunto de dados, incluindo informações sobre o editor, a versão e a validade. |
translations.txt |
Opcional | Informações traduzidas de uma empresa de transporte público. |
attributions.txt |
Opcional | Especifica as atribuições que são aplicadas ao conjunto de dados. |
Requisitos dos arquivos
Os requisitos a seguir aplicam-se aos formatos e ao conteúdo dos arquivos de conjunto de dados:
- Todos os arquivos precisam ser salvos como texto separado 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 conjunto de dados da GTFS e mostra 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 com aspas ou vírgulas precisam ser colocados entre aspas. Além disso, cada aspa no valor do campo precisa ser precedida por outra aspa. Essa é a abordagem que o Microsoft Excel usa para gerar arquivos delimitados por vírgulas (CSV). Para mais informações sobre o formato de arquivo CSV, consulte http://tools.ietf.org/html/rfc4180 (em inglês).
O exemplo a seguir mostra como um valor de campo aparece em um arquivo delimitado por vírgulas:
- Valor do campo original:
Contains "quotes", commas and text
- Valor do campo no arquivo CSV:
"Contains ""quotes"", commas and text"
- Valor do campo original:
- 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 de marca de ordem de byte (BOM) Unicode. Acesse http://unicode.org/faq/utf_bom.html#BOM (em inglês) para mais informações sobre caracteres BOM e UTF-8.
- Os arquivos do conjunto de dados precisam ser compactados juntos.
Definições dos campos
agency.txt
Arquivo: obrigatório
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
agency_id |
ID | Obrigatório sob certas condições | Identifica uma marca que normalmente é sinônimo de uma agência de transporte público. Em alguns casos, as empresas e as marcas são diferentes, como quando uma única empresa opera vários serviços independentes. Este documento usa o termo "empresa" em vez de "marca". Um conjunto pode conter dados de várias empresas de transporte público, caso em que esse campo é obrigatório. Se ele tiver informações de apenas uma empresa, o campo será opcional. |
agency_name |
Texto | Obrigatório | Nome completo da empresa de transporte público. |
agency_url |
URL | Obrigatório | URL da empresa de transporte público. |
agency_timezone |
Fuso horário | Obrigatório | Fuso horário de onde a empresa de transporte público está localizada. Se várias empresas são especificadas no conjunto de dados, elas precisam ter o mesmo agency_timezone . |
agency_lang |
Código do idioma | Opcional | Idioma principal usado pela empresa de transporte público. Esse campo ajuda os consumidores da GTFS a escolher regras de uso de maiúsculas e minúsculas e outras configurações específicas do idioma para o conjunto de dados. |
agency_phone |
Número de telefone | Opcional | Número de telefone da empresa especificada. Este campo é um valor de string que mostra o telefone da área de cobertura. Ele pode e deve conter marcas de pontuação para agrupar os dígitos do número. É permitido usar caracteres comuns em números de telefone (por exemplo, 503-238-RIDE do TriMet), mas o campo não pode conter nenhum outro texto descritivo. |
agency_fare_url |
URL | Opcional | URL de uma página da Web que permite que um passageiro compre passagens ou outros instrumentos de tarifas dessa empresa pela Internet. |
agency_email |
Opcional | Endereço de e-mail monitorado ativamente pelo serviço de atendimento ao cliente da empresa. Esse endereço precisa ser uma parada de contato direto onde os passageiros de transporte público possam falar com um representante do serviço de atendimento ao cliente na empresa. |
stops.txt
Arquivo: obrigatório
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
stop_id |
ID | Obrigatório | Identifica uma parada de ônibus, estação ou entrada da estação. O termo "entrada" refere-se às entradas e às saídas da estação. Paradas, estações e entradas de estações são chamadas coletivamente de locais. Diversos trajetos podem usar a mesma parada. |
stop_code |
Texto | Opcional | Texto curto ou um número que identifica o local para os passageiros. Esses códigos costumam ser usados em sistemas de informações de transporte público para smartphones ou impressos na sinalização, dando aos passageiros informações sobre um local específico. O stop_code pode ser igual ao stop_id se o código está disponível para o público. Este campo precisa ser deixado em branco no caso de locais que não mostram um código aos passageiros. |
stop_name |
Texto | Obrigatório sob certas condições | Nome do local. Use um nome compreensível para as pessoas locais e turistas. Quando o lugar é uma área de embarque ( location_type=4 ), o stop_name precisa incluir o nome da área conforme exibido pela empresa. Pode ser apenas uma letra, como em algumas estações ferroviárias interurbanas da Europa, ou texto como "Área de embarque para cadeiras de rodas" (metrô de Nova York) ou "Parte frontal de trens curtos" (RER de Paris).Obrigatório sob certas condições: • Obrigatório para locais que são paradas de ônibus ( location_type=0 ), estações (location_type=1 ) ou entradas/saídas (location_type=2 ).• Opcional para locais que são nós genéricos ( location_type=3 ) ou áreas de embarque (location_type=4 ). |
stop_desc |
Texto | Opcional | Descrição do local que oferece informações úteis e de qualidade. Não basta repetir o nome dele. |
stop_lat |
Latitude | Obrigatório sob certas condições | Latitude do local. Obrigatório sob certas condições: • Obrigatório para locais que são paradas de ônibus ( location_type=0 ), estações (location_type=1 ) ou entradas/saídas (location_type=2 ).• Opcional para locais que são nós genéricos ( location_type=3 ) ou áreas de embarque (location_type=4 ). |
stop_lon |
Longitude | Obrigatório sob certas condições | Longitude do local. Obrigatório sob certas condições: • Obrigatório para locais que são paradas de ônibus ( location_type=0 ), estações (location_type=1 ) ou entradas/saídas (location_type=2 ).• Opcional para locais que são nós genéricos ( location_type=3 ) ou áreas de embarque (location_type=4 ). |
zone_id |
ID | Obrigatório sob certas condições | Identifica a zona de tarifa de uma parada. Esse campo será obrigatório se você enviar informações de tarifa usando o fare_rules.txt . Caso contrário, será opcional. Se esse registro representar uma estação ou entrada de estação, o zone_id será ignorado. |
stop_url |
URL | Opcional | URL de uma página da Web sobre o local, que precisa ser diferente dos valores do campos agency.agency_url e routes.route_url . |
location_type |
Enumeração | Opcional | Tipo do local: • 0 (ou vazio): parada (ou plataforma). Um local onde os passageiros embarcam ou desembarcam do transporte público. São chamados de "plataforma" quando definidos em uma parent_station .• 1 : estação. Uma estrutura ou área física que contém uma ou mais plataformas.• 2 : entrada/saída. Local na rua em que passageiros podem entrar ou sair de uma estação. Se uma entrada/saída pertencer a várias estações, ela poderá ser vinculada por caminhos a ambas, mas o provedor de dados vai precisar escolher uma delas como a principal.• 3 : nó genérico. Um local dentro de uma estação que não corresponde a nenhum outro location_type e que pode ser usado para vincular caminhos definidos no pathways.txt .• 4 : área de embarque. Um local específico em uma plataforma, em que os passageiros podem embarcar e/ou desembarcar de veículos. |
parent_station |
ID que faz referência a stops.stop_id |
Obrigatório sob certas condições | Define a hierarquia entre os diferentes locais especificados no stops.txt . Contém o ID do local principal da seguinte forma:• Parada/plataforma ( location_type=0 ): o campo parent_station contém o ID de uma estação.• Estação ( location_type=1 ): este campo precisa estar vazio.• Entrada/saída ( location_type=2 ) ou nó genérico (location_type=3 ): o campo parent_station contém o ID de uma estação (location_type=1 )• Área de embarque ( location_type=4 ): o campo parent_station contém o ID de uma plataforma.Obrigatório sob certas condições: • Obrigatório para locais que são entradas ( location_type=2 ), nós genéricos (location_type=3 ) ou áreas de embarque (location_type=4 ).• Opcional para paradas/plataformas ( location_type=0 ).• Proibido para estações ( location_type=1 ). |
stop_timezone |
Fuso horário | Opcional | Fuso horário do local. Se o local tiver uma estação principal, ele herdará o fuso horário dela em vez de aplicar o próprio. As estações e as paradas de ônibus de menor movimento com stop_timezone vazio herdam o fuso horário especificado por agency.agency_timezone . Se os valores de stop_timezone forem fornecidos, os horários no stop_times.txt precisarão ser inseridos como um horário após a meia-noite no fuso especificado por agency.agency_timezone . Isso garante que os valores de horário de uma viagem sempre aumentem, independente dos fusos que ela percorre. |
wheelchair_boarding |
Enumeração | Opcional | Indica se é possível embarcar utilizando cadeira de rodas no local. Estas são as opções válidas: Para paradas de menor movimento: 0 ou vazio: nenhuma informação de acessibilidade disponível.1 : alguns veículos aceitam embarque de passageiros em cadeira de rodas nessa parada.2 : não há embarque de cadeirantes nessa parada. Para paradas dentro de um grande terminal ou estação: 0 ou vazio: a parada herdará o valor de wheelchair_boarding do terminal ou a estação principal, se especificado.1 : existem vias de acesso na parte externa da estação para a plataforma ou parada específica.2 : não há vias de acesso na parte externa da estação para a plataforma ou o parada específica.Para entradas/saídas de estações: 0 ou vazio: a entrada da estação herdará o valor de wheelchair_boarding do terminal ou estação principal, se especificado.1 : a entrada da estação é acessível para cadeira de rodas.2 : não há via de acesso da entrada da estação para as paradas/plataformas. |
level_id |
ID que faz referência a levels.level_id |
Opcional | Nível do local. O mesmo nível pode ser usado por várias estações desvinculadas. |
platform_code |
Texto | Opcional | O identificador de plataforma de uma parada (pertencente a uma estação) em plataforma. Deve incluir 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 podem 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 | Tipo | Obrigatório | Descrição |
---|---|---|---|
route_id |
ID | Obrigatório | Identifica um trajeto. |
agency_id |
ID que faz referência a agency.agency_id |
Obrigatório sob certas condições | Empresa do trajeto especificado. Esse campo é obrigatório quando o conjunto oferece dados para trajetos de mais de uma empresa no agency.txt . Caso contrário, ele é opcional. |
route_short_name |
Texto | Obrigatório sob certas condições | Nome abreviado de um trajeto. Costuma ser um identificador curto e abstrato, como "32", "100X" ou "Verde", que os passageiros usam para distinguir um trajeto, mas que não apresenta indicação sobre os locais atendidos. É preciso especificar route_short_name ou route_long_name . Se adequado, ambos podem ser definidos. |
route_long_name |
Texto | Obrigatório sob certas condições | Nome completo de um trajeto. Geralmente, esse nome é mais descritivo do que route_short_name e pode incluir o destino ou a parada. É preciso especificar route_short_name ou route_long_name . Se adequado, ambos podem ser definidos. |
route_desc |
Texto | Opcional | Descrição de um trajeto que apresenta informações úteis e de qualidade. Não basta repetir o nome do trajeto. Por exemplo: "Os trens da linha Azul operam entre as estações Tucuruvi e 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 Sé. Na estação da Luz, é possível fazer conexão com as seguintes linhas da CPTM: Coral, Rubi e Turquesa.". |
route_type |
Enumeração | Obrigatório | Descreve o tipo de transporte usado em um trajeto. Estas são as opções válidas: 0 : bonde com cabo suspenso, ônibus elétrico, veículo leve sobre trilhos (VLT). Qualquer VLT 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 vagões de superfície, em que o cabo passa por baixo do veículo, como o bonde de São Francisco.6 : teleférico (por exemplo, gôndola). Transporte a cabo em que cabines, carros, gôndolas ou cadeiras abertas são suspensos por um ou mais cabos.7 : funicular. Qualquer sistema de trilho projetado para subir ladeiras.11 : ônibus elétrico. Ônibus elétricos que recebem energia de cabos suspensos por postes.12 : monotrilho. Sistema ferroviário com um único trilho ou uma barra. |
route_url |
URL | Opcional | URL de uma página da Web sobre o trajeto específico. Precisa ser diferente do valor de agency.agency_url . |
route_color |
Cor | Opcional | Designação de cor do trajeto que corresponde ao material voltado para o público. Quando o valor estiver vazio ou for omitido, o padrão será branco (FFFFFF ). A diferença de cores entre route_color e route_text_color deve ter contraste suficiente com uma tela em preto e branco. |
route_text_color |
Cor | Opcional | Cor legível a ser usada em um texto sobre um plano de fundo de route_color . Quando o valor estiver vazio ou for omitido, o padrão será 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 |
Número inteiro não negativo | Opcional | Ordena os trajetos da maneira ideal para apresentação aos clientes. Trajetos com valores de route_sort_order menores precisam aparecer primeiro. |
continuous_pickup |
Enumeração | Opcional | Indica se um passageiro pode embarcar no transporte público em qualquer lugar ao longo do caminho. O caminho é descrito por shapes.txt em cada viagem do trajeto. As opções válidas são estas a seguir:0 : embarque com paradas contínuas.1 ou vazio: nenhum embarque com paradas contínuas.2 : necessário ligar para a empresa e agendar o embarque com paradas contínuas.3 : necessário combinar com o motorista para agendar o embarque com paradas contínuas.O comportamento padrão desse tipo de embarque definido em routes.txt pode ser substituído em stop_times.txt . |
continuous_drop_off |
Enumeração | Opcional | Indica se um passageiro pode sair do transporte público em qualquer ponto ao longo do caminho. O caminho é descrito por shapes.txt em cada viagem do trajeto. As opções válidas são estas :0 : desembarque com paradas contínuas.1 ou vazio: nenhum desembarque com paradas contínuas.2 : necessário ligar para a empresa e agendar o desembarque com paradas contínuas.3 : necessário combinar com o motorista para agendar o desembarque com paradas contínuas.O comportamento padrão desse tipo de desembarque definido em routes.txt pode ser substituído em stop_times.txt . |
trips.txt
Arquivo: obrigatório
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
route_id |
ID que faz referência a routes.route_id |
Obrigatório | Identifica um trajeto. |
service_id |
ID que faz referência a calendar.service_id ou calendar_dates.service_id |
Obrigatório | Identifica um conjunto de datas em que o serviço está disponível para um ou mais trajetos. |
trip_id |
ID | Obrigatório | Identifica uma viagem. |
trip_headsign |
Texto | Opcional | Texto que aparece na sinalização identificando o destino da viagem para os passageiros. Use este campo para fazer distinção entre diversos padrões de serviço no mesmo trajeto. Se o letreiro mudar durante uma viagem, trip_headsign poderá ser modificado especificando valores para stop_times.stop_headsign . |
trip_short_name |
Texto | Opcional | Texto visível ao público usado para identificar a viagem aos passageiros, por exemplo, destacar os números dos trens. Se as pessoas não costumam consultar os nomes da viagem, deixe este campo em branco. Um valor trip_short_name , se informado, precisará identificar exclusivamente uma viagem no dia do serviço. Ele não pode ser usado para nomes de destino nem designações limitadas/expressas. |
direction_id |
Enumeração | Opcional | Indica a direção de uma viagem. Este campo não é usado para criar trajetos. Com ele, é possível diferenciar as viagens por direção no momento de publicar as tabelas de horários. Estas são as opções válidas: 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 estes registros para uso em tabelas de horários: trip_id,...,trip_headsign,direction_id 1234,...,Airport,0 1505,...,Downtown,1 |
block_id |
ID | Opcional | Identifica o bloco a que a viagem pertence. Um bloco consiste em uma única viagem ou diversas viagens sequenciais feitas no mesmo veículo e definidas pelos dias de serviço compartilhados e pelo block_id . Um block_id pode ter viagens com diferentes dias de serviço, criando blocos distintos. Veja o exemplo abaixo. |
shape_id |
ID que se refere a shapes.shape_id |
Obrigatório sob certas condições | Identifica uma forma geoespacial que descreve o caminho do veículo em uma viagem. Obrigatório sob certas condições: esse campo é obrigatório se a viagem tiver um comportamento contínuo definido, seja no nível do trajeto ou do tempo de parada. Caso contrário, é opcional. |
wheelchair_accessible |
Enumeração | Opcional | Indica a acessibilidade para cadeira de rodas. Estas são as opções válidas:0 ou vazio: nenhuma informação de acessibilidade disponível para a viagem.1 : o veículo utilizado na viagem em questão pode acomodar pelo menos um passageiro em cadeira de rodas.2 : nenhum passageiro em cadeira de rodas pode ser acomodado nesta viagem. |
bikes_allowed |
Enumeração | Opcional | Indica se bicicletas são permitidas. Estas são as opções válidas:0 ou vazio: não há informações sobre bicicletas para a viagem.1 : o veículo utilizado nesta viagem específica pode acomodar pelo menos uma bicicleta.2 : não são permitidas bicicletas nesta viagem. |
Exemplo: 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) |
---|---|---|---|---|---|
red |
trip_1 |
mon-tues-wed-thurs-fri-sat-sun |
red_loop |
22:00:00 | 22:55:00 |
red |
trip_2 |
fri-sat-sun |
red_loop |
23:00:00 | 23:55:00 |
red |
trip_3 |
fri-sat |
red_loop |
24:00:00 | 24:55:00 |
red |
trip_4 |
mon-tues-wed-thurs |
red_loop |
20:00:00 | 20:50:00 |
red |
trip_5 |
mon-tues-wed-thurs |
red_loop |
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
trip_1
,trip_2
etrip_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
trip_1
,trip_4
etrip_5
em um bloco das 20h às 22h55.
stop_times.txt
Arquivo: obrigatório
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
trip_id |
ID que faz referência a trips.trip_id |
Obrigatório | Identifica uma viagem. |
arrival_time |
Horário | Obrigatório sob certas condições | Hora de chegada em uma parada de uma viagem específica no trajeto. Se não houver horários distintos de chegada e partida em uma parada, insira o mesmo valor para arrival_time e departure_time . Para horários após a meia-noite, insira um valor maior que 24:00:00 no formato HH:MM:SS com a hora local do dia em que a viagem está programada para iniciar.Pontos de tempo são paradas programadas em que o veículo cumpre pontualmente os horários de chegada e partida especificados. Se essa parada não for programada, é recomendável informar um horário estimado ou interpolado. Se esse valor não estiver disponível, arrival_time poderá ser deixado em branco. Além disso, indique que os horários interpolados são fornecidos inserindo o valor no campo timepoint=0 . Se esses horários forem determinados usando o timepoint=0 , os pontos de tempo precisarão ser especificados com timepoint=1 . 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. |
departure_time |
Horário | Obrigatório sob certas condições | Horário de partida de uma parada específica de uma determinada viagem no trajeto. Para horários após a meia-noite, insira um valor maior que 24:00:00 no formato HH:MM:SS com a hora local do dia em que a viagem está programada para iniciar. Se não houver horários distintos de chegada e partida em uma parada, insira o mesmo valor para arrival_time e departure_time . Veja a descrição de arrival_time para mais detalhes sobre como usar pontos de tempo corretamente. O campo departure_time precisa especificar valores de tempo sempre que possível, incluindo horários estimados ou interpolados não vinculados entre os pontos. |
stop_id |
ID que faz referência a stops.stop_id |
Obrigatório | Identifica a parada de serviço. É necessário registrar todas as paradas atendidas durante uma viagem no stop_times.txt . Os locais referenciados precisam ser paradas, e não estações ou entradas de estações. Uma parada pode ser atendida várias vezes na mesma viagem, e várias viagens e trajetos podem atender a mesma parada. |
stop_sequence |
Número inteiro não negativo | Obrigatório | Ordem das paradas de uma viagem específica. Os valores precisam aumentar ao longo da viagem, mas não precisam ser consecutivos. Por exemplo, o primeiro local da viagem poderia ter stop_sequence=1 , o segundo, stop_sequence=23 , o terceiro, stop_sequence=40 , e assim por diante. |
stop_headsign |
Texto | Opcional | Texto que aparece na sinalização identificando o destino da viagem para os passageiros. Este campo substitui o padrão trips.trip_headsign quando o letreiro muda entre as paradas. Se o letreiro é exibido na viagem inteira, use trips.trip_headsign . Um valor de stop_headsign especificado para um stop_time não se aplica aos stop_time s subsequentes na mesma viagem. Se você quiser modificar o trip_headsign de vários stop_time s na mesma viagem, o valor de stop_headsign precisará ser repetido em todas as linhas de stop_time . |
pickup_type |
Enumeração | Opcional | Indica a forma do embarque. Estas são as opções válidas:0 ou vazio: embarque programado regularmente. 1 : sem embarque disponível.2 : necessário ligar para a empresa para agendar o embarque.3 : necessário combinar com o motorista para agendar o embarque. |
drop_off_type |
Enumeração | Opcional | Indica a forma do desembarque. Estas são as opções válidas:0 ou vazio: desembarque programado regularmente.1 : desembarque não disponível.2 : é necessário ligar para a empresa e definir o desembarque.3 : é necessário combinar com o motorista para definir o desembarque. |
continuous_pickup |
Enumeração | Opcional | Indica se um passageiro pode embarcar no transporte público em qualquer ponto ao longo do caminho. O caminho é descrito por shapes.txt , deste stop_time para o próximo stop_time , na stop_sequence da viagem. As opções válidas são estas a seguir:0 : embarque com paradas contínuas.1 ou vazio: nenhum embarque com paradas contínuas.2 : necessário ligar para a empresa e agendar o embarque com paradas contínuas.3 : necessário combinar com o motorista para agendar o embarque com paradas contínuas.O comportamento desse tipo de embarque indicado em stop_times.txt modifica qualquer comportamento definido em routes.txt . |
continuous_drop_off |
Enumeração | Opcional | Indica se um passageiro pode sair do transporte público em qualquer ponto ao longo do caminho, conforme descrito por shapes.txt , deste stop_time para o próximo stop_time , na stop_sequence da viagem.0 : desembarque com paradas contínuas.1 ou vazio: nenhum desembarque com paradas contínuas.2 : necessário ligar para a empresa e agendar o desembarque com paradas contínuas.3 : necessário combinar com o motorista o desembarque com paradas contínuas.O comportamento desse tipo de desembarque indicado em stop_times.txt modifica qualquer comportamento definido em routes.txt . |
shape_dist_traveled |
Valor flutuante não negativo | Opcional | Distância real percorrida ao longo do polígono associado, desde a primeira parada até a parada especificada neste registro. Este campo especifica o polígono entre duas paradas de uma viagem. Precisa ter as mesmas unidades que aquelas usadas no shapes.txt . Os valores usados para shape_dist_traveled precisam aumentar com stop_sequence e não podem ser utilizados para mostrar a viagem de retorno em um trajeto.Por exemplo, se um ônibus percorre uma distância de 5,25 km do início do polígono até a parada, seria shape_dist_traveled=5.25 . |
timepoint |
Enumeração | Opcional | Indica se os horários de chegada e partida de uma parada são cumpridos pontualmente pelo veículo ou se são horários aproximados e/ou interpolados. Com esse campo, um produtor de GTFS pode informar tempos de parada interpolados e indicar se eles são aproximados. Estas são as opções válidas:0 : o horário é aproximado.1 ou vazio: o horário é exato. |
calendar.txt
Arquivo: obrigatório sob certas condições
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
service_id |
ID | Obrigatório | Identifica exclusivamente um conjunto de datas quando o serviço está disponível para um ou mais trajetos. Cada valor de service_id pode aparecer no máximo uma vez em um arquivo calendar.txt . |
monday |
Enumeração | Obrigatório | Indica se o serviço opera todas as segundas-feiras dentro do período especificado pelos campos start_date e end_date . Você pode indicar exceções para datas específicas no arquivo calendar_dates.txt . Estas são as opções válidas:1 : o serviço está disponível para todas as segundas-feiras no período.0 : o serviço não está disponível para as segundas-feiras no período. |
tuesday |
Enumeração | Obrigatório | Funciona da mesma maneira que monday , mas se aplica às terças-feiras. |
wednesday |
Enumeração | Obrigatório | Funciona da mesma maneira que monday , mas se aplica às quartas-feiras. |
thursday |
Enumeração | Obrigatório | Funciona da mesma maneira que monday , mas se aplica às quintas-feiras. |
friday |
Enumeração | Obrigatório | Funciona da mesma maneira que monday , mas se aplica às sextas-feiras. |
saturday |
Enumeração | Obrigatório | Funciona da mesma maneira que monday , mas se aplica aos sábados. |
sunday |
Enumeração | Obrigatório | Funciona da mesma maneira que monday , mas se aplica aos domingos. |
start_date |
Data | Obrigatório | Data de início do dia de serviço para o intervalo. |
end_date |
Data | Obrigatório | Data de término do dia de serviço para o intervalo. Este dia está incluído no intervalo. |
calendar_dates.txt
Arquivo: obrigatório sob certas condições
A tabela calendar_dates.txt
pode ativar ou desativar explicitamente o serviço por data, além de poder ser usada em qualquer direção.
- Recomendado: use
calendar_dates.txt
comcalendar.txt
para definir exceções aos padrões de serviço definidos nocalendar.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 a programação de uma escola). Nesse caso,calendar_dates.service_id
é um ID que faz referência acalendar.service_id
. - Alternativa: omita
calendar.txt
e especifique cada data de serviço nocalendar_dates.txt
. Isso permite maior flexibilidade e acomoda serviços que não têm cronogramas semanais normais. Nesse caso,service_id
é um ID.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
service_id |
ID que faz referência a calendar.service_id ou ID normal |
Obrigatório | Identifica um conjunto de datas em que ocorre uma exceção de serviço para um ou mais trajetos. Cada par (service_id , date ) só vai poder aparecer uma vez no calendar_dates.txt se você estiver usando calendar.txt e calendar_dates.txt . Se um valor de service_id estiver presente no calendar.txt e calendar_dates.txt , as informações no calendar_dates.txt modificarão os dados de serviço especificados no calendar.txt . |
date |
Data | Obrigatório | Data em que a exceção do serviço ocorre. |
exception_type |
Enumeração | Obrigatório | Indica se o serviço está disponível na data especificada, no campo date . Estas são as opções válidas:1 : o serviço está disponível para a data especificada.2 : o serviço não está disponível para a data especificada.Por exemplo, suponha que um trajeto tenha um conjunto de viagens disponíveis em feriados e outro em todos os outros dias. Um service_id poderia corresponder ao cronograma de serviço regular, e outro service_id , ao cronograma de feriados. Para um feriado específico, o arquivo calendar_dates.txt pode ser usado para relacionar o feriado e o service_id correspondente e removê-lo da programação regular do service_id . |
fare_attributes.txt
Arquivo: opcional
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
fare_id |
ID | Obrigatório | Identifica uma classe de tarifa. |
price |
Valor flutuante não negativo | Obrigatório | Preço da tarifa, na unidade especificada por currency_type . |
currency_type |
Código da moeda | Obrigatório | Moeda usada para pagar a tarifa. |
payment_method |
Enumeração | Obrigatório | Indica quando a tarifa precisa ser paga. Estas são as opções válidas:0 : a tarifa é paga a bordo.1 : a tarifa precisa ser paga antes do embarque. |
transfers |
Enumeração | Obrigatório | Especifica o número de baldeações permitidas nesta tarifa. Esse campo pode ficar vazio e é, portanto, uma exceção ao requisito de que um campo obrigatório não pode ficar em branco. Estas são as opções válidas: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: as baldeações são ilimitadas. |
agency_id |
ID que faz referência a agency.agency_id |
Obrigatório sob certas condições | Identifica a empresa relevante para uma tarifa. Este campo é obrigatório para conjuntos de dados que têm várias empresas definidas no agency.txt . Caso contrário, é opcional. |
transfer_duration |
Número inteiro não negativo | Opcional | Tempo em segundos antes de a baldeação expirar. Quando transfers=0 , esse campo poderá ser usado para indicar por quanto tempo um bilhete é válido ou poderá ficar em branco. |
fare_rules.txt
Arquivo: opcional
A tabela fare_rules.txt
especifica como as tarifas no fare_attributes.txt
se aplicam 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 de tarifa com fare_rules.txt
e fare_attributes.txt
, consulte https://code.google.com/p/googletransitdatafeed/wiki/FareExamples no wiki do projeto de código aberto GoogleTransitDataFeed.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
fare_id |
ID que faz referência a fare_attributes.fare_id |
Obrigatório | Identifica uma classe de tarifa. |
route_id |
ID que faz referência a routes.route_id |
Opcional | Identifica um trajeto associado à classe de tarifa. Se houver trajetos com os mesmos atributos de tarifa, crie um registro no fare_rules.txt para cada trajeto.Exemplo: se a classe de tarifa "b" for válida nos trajetos "TSW" e "TSE", o arquivo fare_rules.txt conterá estes registros: fare_id,route_id b,TSW b,TSE |
origin_id |
ID que faz referência a stops.zone_id |
Opcional | Identifica uma zona de origem. Se uma classe de tarifa tem várias zonas de origem, crie um registro no fare_rules.txt para cada origin_id .Exemplo: se a classe de tarifa "b" for válida para todas as viagens provenientes da zona 2 ou 8, o arquivo fare_rules.txt conterá estes registros: fare_id,...,origin_id b,...,2 b,...,8 |
destination_id |
ID que faz referência a stops.zone_id |
Opcional | Identifica uma zona de destino. Se uma classe de tarifa tiver várias zonas de destino, crie um registro no fare_rules.txt para cada destination_id .Exemplo: você pode usar os campos origin_id e destination_id para especificar que a classe de tarifa "b" é válida para viagens entre as zonas 3 e 4 e as zonas 3 e 5. O arquivo fare_rules.txt conteria estes registros: fare_id,...,origin_id,destination_id b,...,3,4 b,...,3,5 |
contains_id |
ID que faz referência a stops.zone_id |
Opcional | Identifica as zonas pelas quais um passageiro passa em uma determinada classe de tarifa. Usado em alguns sistemas para calcular a classe correta. 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 estes registros: fare_id,route_id,...,contains_id c,GRT,...,5 c,GRT,...,6 c,GRT,...,7 Como todas as zonas contains_id precisam corresponder à tarifa usada, um itinerário que passa pelas zonas 5 e 6, mas não pela 7, não tem a classe de tarifa "c". Para mais detalhes, acesse https://code.google.com/p/googletransitdatafeed/wiki/FareExamples no wiki do projeto do GoogleTransitDataFeed. |
shapes.txt
Arquivo: opcional
Os polígonos descrevem o caminho que um veículo percorre ao longo de um trajeto e são definidos no arquivo shapes.txt
. Eles estão associados às viagens e consistem em uma sequência de paradas na ordem em que o veículo passa. Os polígonos não precisam interceptar exatamente o local das paradas, mas todas as paradas em uma viagem precisam estar a uma curta distância do polígono correspondente, ou seja, perto de segmentos de linha reta que conectam os pontos.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
shape_id |
ID | Obrigatório | Identifica um polígono. |
shape_pt_lat |
Latitude | Obrigatório | Latitude de uma parada do polígono. Cada registro no shapes.txt representa um ponto do polígono usado para definir o polígono. |
shape_pt_lon |
Longitude | Obrigatório | Longitude de uma parada do polígono. |
shape_pt_sequence |
Número inteiro não negativo | Obrigatório | Sequência em que os pontos se conectam para formar o polígono. Os valores precisam aumentar ao longo da viagem, mas não precisam ser consecutivos. Por exemplo, se o polígono "A_shp" tiver três pontos na definição, o arquivo shapes.txt poderá conter estes registros para definir o polígono: shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence A_shp,37.61956,-122.48161,0 A_shp,37.64430,-122.41070,6 A_shp,37.65863,-122.30839,11 |
shape_dist_traveled |
Valor flutuante não negativo | Opcional | Distância real percorrida ao longo do polígono desde o primeiro ponto até o ponto especificado nesse registro. Usado pelos planejadores de viagem para mostrar a parte correta do polígono em um mapa. Os valores precisam aumentar com a shape_pt_sequence e não podem ser usados para exibir a viagem de retorno em um trajeto. Use as mesmas unidades de distância utilizadas no stop_times.txt ..Por exemplo, se um ônibus passa pelos três pontos definidos acima para A_shp, os outros valores de shape_dist_traveled (em quilômetros) seriam semelhantes a estes: shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled 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
O arquivo frequencies.txt
representa viagens que operam em intervalos regulares (entre viagens) e pode ser usado para definir dois tipos diferentes de serviço.
- Serviço com base em frequência (
exact_times=0
) em que o serviço não segue um cronograma fixo ao longo do dia. Em vez disso, os operadores tentam manter os intervalos predeterminados para as viagens. - Uma representação compacta do serviço com base em horários (
exact_times=1
) que tem exatamente o mesmo intervalo para viagens em períodos especificados. No serviço com base em cronograma, os operadores tentam cumprir estritamente uma programação.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
trip_id |
ID que faz referência a trips.trip_id |
Obrigatório | Identifica uma viagem à qual o intervalo especificado do serviço se aplica. |
start_time |
Horário | Obrigatório | Horário em que o primeiro veículo sai da primeira parada da viagem com o intervalo especificado. |
end_time |
Horário | Obrigatório | Horário em que o serviço muda para um intervalo diferente ou é interrompido na primeira parada da viagem. |
headway_secs |
Número inteiro não negativo | Obrigatório | Tempo, em segundos, entre as partidas de uma mesma parada (intervalo) da viagem, durante o período especificado por start_time e end_time . É possível haver vários intervalos para a mesma viagem, mas eles não podem se sobrepor. Novos intervalos podem começar no momento exato em que o intervalo anterior termina. |
exact_times |
Enumeração | Opcional | Indica o tipo de serviço de uma viagem. Veja a descrição do arquivo para mais informações. Estas são as opções válidas:0 ou vazio: viagens com base na frequência.1 : viagens com base em cronograma com o mesmo intervalo ao longo do dia. Nesse caso, o valor de end_time precisa ser maior que o último start_time desejado, mas menor que o último start_time desejado + headway_secs . |
transfers.txt
Arquivo: opcional
Quando um itinerário é calculado, os aplicativos que usam a GTFS interpolam as baldeações com base no tempo permitido e na proximidade com a parada. O arquivo transfers.txt
especifica outras regras e as substitui para as baldeações selecionadas.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
from_stop_id |
ID que faz referência a stops.stop_id |
Obrigatório | Identifica uma parada ou estação onde começa uma conexão entre os trajetos. Se esse campo se referir a uma estação, a regra de baldeação vai ser usada em todas as paradas de menor movimento. |
to_stop_id |
ID que faz referência a stops.stop_id |
Obrigatório | Identifica uma parada ou estação onde termina uma conexão entre os trajetos. Se esse campo se referir a uma estação, a regra de baldeação vai ser usada em todas as paradas de menor movimento. |
transfer_type |
Enumeração | Obrigatório | Indica o tipo de conexão para o par especificado (from_stop_id , to_stop_id ). Valid options are:0 ou vazio: ponto de baldeação recomendado entre dois trajetos.1 : ponto de baldeação cronometrado 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 : a baldeação exige um intervalo mínimo 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.4 : os passageiros podem permanecer onde estão para fazer a baldeação de uma viagem para outra ("baldeação sem troca de veículo").5 : não é permitido fazer baldeações sem troca de veículo entre viagens sequenciais. O passageiro precisa sair do veículo e embarcar novamente. |
min_transfer_time |
Número inteiro não negativo | Opcional | Tempo, em segundos, para permitir uma baldeação entre os trajetos nos pontos especificados. O min_transfer_time precisa ser suficiente para que um passageiro comum se desloque entre os dois pontos, inclusive tempo extra para permitir uma variação de horário em cada trajeto. |
pathways.txt
Arquivo: opcional
A extensão GTFS-Pathways usa uma representação gráfica para descrever o metrô ou trem, com nós (locais) e arestas (caminhos).
Para ir da entrada (que é um nó representado como um local com location_type=2
) até uma plataforma (que é um nó representado como um local com location_type=0
), o passageiro vai atravessar passarelas, catracas, escadas, etc. (que são arestas representadas como caminhos). A proposta também adiciona outro tipo de local, chamado "nó genérico", para representar, por exemplo, uma passarela que cruza com outras passarelas.
Aviso: é preciso incluir todos os caminhos de uma estação. Assim, presume-se que a estação tenha uma descrição completa dos caminhos quando uma plataforma (como uma parada), entrada ou nó pertencente a uma estação tem um caminho conectado a ela. Portanto, as seguintes regras são aplicáveis:
- Não se esqueça de adicionar locais: se todos os locais dentro de uma estação tiverem um caminho, adicione todos eles ao arquivo, exceto as plataformas que têm áreas de embarque.
- Plataformas não podem ser bloqueadas: cada plataforma precisa estar conectada a pelo menos uma entrada por um conjunto de caminhos. São raras as estações que não têm saída.
- Não adicione caminhos para uma plataforma com áreas de embarque: uma plataforma que tem áreas de embarque precisa ser tratada como um objeto principal, não como um ponto. Não é necessário atribuir caminhos a uma plataforma, mas sim às áreas de embarque.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
pathway_id |
ID | Obrigatório | O campo pathway_id contém um ID que identifica exclusivamente o caminho. O pathway_id é utilizado pelos sistemas como um identificador interno desse registro (por exemplo, como a chave primária no banco de dados). Portanto, o pathway_id precisa ser exclusivo para cada conjunto de dados. Caminhos diferentes podem ser conectados diretamente do mesmo from_stop_id ao mesmo to_stop_id . Por exemplo, isso acontece quando duas escadas rolantes estão lado a lado em direções opostas ou quando uma escada e um elevador têm origens e destinos iguais. |
from_stop_id |
ID que faz referência a stops.stop_id |
Obrigatório | Local onde o caminho começa. Ele contém um stop_id que identifica uma plataforma, entrada/saída, nó genérico ou área de embarque no arquivo stops.txt . |
to_stop_id |
ID que faz referência a stops.stop_id |
Obrigatório | Local onde o caminho termina. Ele contém um stop_id que identifica uma plataforma, entrada/saída, nó genérico ou área de embarque no arquivo stops.txt . |
pathway_mode |
Enumeração | Obrigatório | Tipo de caminho entre o par especificado (from_stop_id , to_stop_id ). Os valores válidos do campo são: • 1 : passarela. • 2 : escadas. • 3 : esteira rolante/esteira transportadora. • 4 : escada rolante. • 5 : elevador. • 6 : catraca: um caminho que atravessa uma área da estação onde é necessário um comprovante de pagamento, geralmente por meio de uma barreira física.As catracas podem separar as áreas pagas da estação das não pagas ou dividir diferentes áreas de pagamento dentro da mesma estação. Essas informações podem ser usadas para evitar que os passageiros cortem caminho pelas estações usando atalhos que exigiriam pagamentos desnecessários, como direcionar um passageiro por uma plataforma de metrô para chegar a uma parada de ônibus. • 7 : portão de saída: indica um caminho que sai de uma área onde a comprovação de pagamento é necessária para uma área em que ela não é mais necessária. |
is_bidirectional |
Enumeração | Obrigatório | Indica em quais direções o caminho pode ser usado: • 0 : caminho unidirecional que só pode ser usado de from_stop_id a to_stop_id .• 1 : caminho bidirecional que pode ser utilizado nas duas direções.As catracas ( pathway_mode=6 ) e os portões de saída (pathway_mode=7 ) não podem ser bidirecionais. |
length |
Valor flutuante não negativo | Opcional | O comprimento horizontal é medido a partir do local de origem (definido em from_stop_id ) até o local de destino (definido em to_stop_id ).Este campo é recomendado para passarelas ( pathway_mode=1 ), catracas (pathway_mode=6 ) e portões de saída (pathway_mode=7 ). |
traversal_time |
Número inteiro positivo | Opcional | Tempo médio em segundos necessário para percorrer o caminho desde o local de origem (definido em from_stop_id ) até o local de destino (definido em to_stop_id ).Este campo é recomendado para esteiras rolantes ( pathway_mode=3 ), escadas rolantes (pathway_mode=4 ) e elevadores (pathway_mode=5 ). |
stair_count |
Número inteiro não nulo | Opcional | Número de escadas do caminho. Práticas recomendadas: é possível usar a aproximação de 1 andar = 15 degraus para gerar valores aproximados. Um valor positivo de stair_count indica que o passageiro sobe de from_stop_id até to_stop_id , e um valor negativo de stair_count indica que o passageiro desce de from_stop_id até to_stop_id .Este campo é recomendado para escadas ( pathway_mode=2 ). |
max_slope |
Valor flutuante | Opcional | Taxa máxima de inclinação do caminho. Os valores válidos deste campo são: • 0 ou vazio: sem inclinação.• Valor flutuante: a taxa de inclinação do caminho, positiva para cima e negativa para baixo. Use este campo somente com passarelas ( pathway_type=1 ) e esteiras rolantes (pathway_type=3 ).Por exemplo, nos EUA, 0,083 (ou 8,3%) é a taxa máxima de inclinação para cadeiras de rodas manuais, o que significa um aumento de 0,083 m (ou 8,3 cm) a cada 1 m. |
min_width |
Valor flutuante positivo | Opcional | Largura mínima do caminho em metros. Esse campo é altamente recomendado se a largura mínima é menor que 1 metro. |
signposted_as |
Texto | Opcional | String de texto da sinalização física visível para os passageiros do transporte público, que pode ser usada para dar instruções de texto aos usuários, como "siga as placas para". O texto deste campo precisa aparecer exatamente como impresso nas sinalizações, ou seja, sem tradução. |
reversed_signposted_as |
Texto | Opcional | Igual ao campo signposted_as , mas usado quando o caminho é percorrido na direção inversa, isto é, do to_stop_id para o from_stop_id . |
levels.txt
Arquivo: opcional
Descreve os diferentes níveis de uma estação. Esse arquivo é útil principalmente se usado com o pathways.txt
e é necessário para solicitar ao usuário que pegue o elevador (pathway_mode=5
) até o nível "Mezanino" ou "Plataforma".
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
level_id |
ID | Obrigatório | Código do nível que pode ser referenciado no stops.txt . |
level_index |
Valor flutuante | Obrigatório | Índice numérico do nível que informa a posição relativa desse nível em relação a outros. Presume-se que níveis com índices mais altos estejam localizados acima daqueles com índices mais baixos. O térreo precisa ter índice 0 , com os níveis acima indicados por valores positivos, e os níveis abaixo, por valores negativos. |
level_name |
Texto | Opcional | Nome opcional do nível, que corresponde às letras/numerações do nível usadas dentro do edifício ou da estação. É útil para instruções relacionadas a elevador, por exemplo, "pegue o elevador para o Mezanino" ou "(...) para as Plataformas" ou "(...) para o -1". |
feed_info.txt
Arquivo: obrigatório sob certas condições
Esse arquivo contém informações sobre o conjunto de dados em si, e não sobre os serviços que o conjunto descreve. Em alguns casos, o editor do conjunto de dados é diferente das empresas. Se translations.txt
for fornecido, esse arquivo será necessário.
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
feed_publisher_name |
Texto | Obrigatório | Nome completo da organização que publica o conjunto de dados. Pode ser igual a um dos valores de agency.agency_name . |
feed_publisher_url |
URL | Obrigatório | URL do site da organização que publica o conjunto de dados. Pode ser igual a um dos valores de agency.agency_url . |
feed_lang |
Código do idioma | Obrigatório | Idioma padrão do texto neste conjunto de dados. Esta configuração ajuda os consumidores da GTFS a escolher regras para o uso de letras maiúsculas e minúsculas e outras definições específicas do idioma. Para escolher outro idioma, use o campo language no arquivo translations.txt .Conjuntos de dados multilíngues podem ser o idioma padrão quando o texto original está em várias línguas. Nesses casos, use o código de idioma ISO 639-2 mul no campo feed_lang . Forneça uma tradução para cada um dos idiomas usados no conjunto de dados no translations.txt . Se todo o texto original do conjunto de dados estiver no mesmo idioma, não use mul .Por exemplo, em um conjunto na Suíça, o campo stops.stop_name original pode ser preenchido com os nomes das paradas em vários idiomas. Cada nome de parada é escrito de acordo com o idioma dominante na localização geográfica dela. Exemplos incluem "Genève" para a cidade de Genebra, onde se fala francês, "Zürich" para a cidade de Zurique, onde o idioma principal é o alemão, e "Biel/Bienne" para a cidade de Bienna, que é bilíngue. Defina feed_lang=mul e forneça as traduções a seguir no translations.txt :
|
default_lang |
Código do idioma | Opcional | Define o idioma usado quando o consumidor de dados não sabe que língua o passageiro fala. Geralmente, ele é configurado como en , inglês. |
feed_start_date |
Data | Opcional | O conjunto de dados apresenta informações de cronograma completas e confiáveis para o serviço no período que abrange o início do dia em feed_start_date até o fim do dia em feed_end_date . Ambos os dias poderão ser deixados em branco se não estiverem disponíveis. A data em feed_end_date não poderá ser anterior à data em feed_start_date caso ambos sejam informadas. Recomendamos que os produtores de conjuntos disponibilizem dados de cronograma fora desse período para informar sobre possíveis serviços futuros, mas os consumidores precisam estar conscientes do 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 nos arquivos 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 a feed_end_date não incluídas nas datas ativas. |
feed_end_date |
Data | Opcional | Consulte a linha feed_start_date nesta tabela. |
feed_version |
Texto | Opcional | String que indica a versão atual do conjunto de dados da GTFS. Os aplicativos que usam a GTFS podem mostrar esse valor para ajudar os editores de conjuntos de dados a determinar se o conjunto mais recente foi incorporado. |
feed_contact_email |
Opcional | Endereço de e-mail para comunicação sobre as práticas de publicação de informações e conjunto de dados da GTFS. O feed_contact_email representa um contato técnico para os aplicativos que usam a GTFS. Envie os dados de contato para atendimento ao cliente pelo agency.txt . |
|
feed_contact_url |
URL | Opcional | Um URL para dados de contato, um formulário da Web, suporte técnico ou outras ferramentas de comunicação sobre as práticas de publicação de informações e conjunto de dados da GTFS. O feed_contact_url representa um contato técnico para os aplicativos que usam a GTFS. Envie os dados de contato para atendimento ao cliente pelo agency.txt . |
translations.txt
Arquivo: opcional
Nome do campo | Tipo | Obrigatório | Descrição | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
table_name |
Enumeração | Obrigatório |
Define a tabela do conjunto de dados que contém o campo a ser traduzido. Os valores a seguir são permitidos:
|
||||||||||||||||||
field_name |
Texto | Obrigatório |
Informa o nome do campo a ser traduzido. Campos com o tipo "Texto" podem ser traduzidos, já com os tipos "URL", "E-mail" e "Número de telefone" podem ser incluídos aqui para serem informados no idioma correto. |
||||||||||||||||||
language |
Código do idioma | Obrigatório |
Informa o idioma da tradução. Se esse idioma for o mesmo de Por exemplo, na Suíça, uma cidade em um cantão bilíngue oficialmente nomeada "Biel/Bienne" seria chamada apenas de "Bienne" em francês e "Biel" em alemão. |
||||||||||||||||||
translation |
Texto, URL, e-mail ou número de telefone | Obrigatório | Informa o valor traduzido para o field_name especificado. |
||||||||||||||||||
record_id |
ID | Obrigatório sob certas condições |
Define o registro que corresponde ao campo a ser traduzido. O valor em
As condições a seguir determinam como esse campo pode ser usado:
|
||||||||||||||||||
record_sub_id |
ID | Obrigatório sob certas condições |
Ajuda a traduzir o registro que contém o campo quando a tabela referenciada em
As condições a seguir determinam como esse campo pode ser usado:
|
||||||||||||||||||
field_value |
Texto, URL, e-mail ou número de telefone | Obrigatório sob certas condições |
Em vez de usar O campo precisa corresponder com exatidão ao valor de Se duas regras de tradução corresponderem ao mesmo registro, uma com As condições a seguir determinam como esse campo pode ser usado:
|
attributions.txt
Arquivo: opcional
Nome do campo | Tipo | Obrigatório | Descrição |
---|---|---|---|
attribution_id |
ID | Opcional | Identifica uma atribuição para o conjunto de dados ou um subconjunto dele. Este campo é útil para traduções. |
agency_id |
ID que faz referência | Opcional | A empresa a que a atribuição se aplica. Se uma atribuição agency_id , route_id ou trip_id for definida, os outros campos precisarão estar vazios. Se nada for especificado, a atribuição será aplicada ao conjunto de dados inteiro. |
route_id |
ID que faz referência | Opcional | Esse campo funciona da mesma maneira que agency_id , mas a atribuição se aplica a um trajeto. Várias atribuições podem servir para o mesmo trajeto. |
trip_id |
ID que faz referência | Opcional | Esse campo funciona da mesma maneira que agency_id , mas a atribuição se aplica a uma viagem. Várias atribuições podem servir para a mesma viagem. |
organization_name |
Texto | Obrigatório | O nome da organização a que o conjunto de dados é atribuído. |
is_producer |
Enumeração | Opcional | O papel da organização é de produtora. Estes são os valores permitidos: • 0 ou vazio: a organização não tem esse papel.• 1 : a organização tem esse papel.Pelo menos um dos campos ( is_producer , is_operator ou is_authority ) precisa ser definido em 1 . |
is_operator |
Enumeração | Opcional | Funciona da mesma maneira que is_producer , mas o papel da organização é de operadora. |
is_authority |
Enumeração | Opcional | Funciona da mesma maneira que is_producer , mas o papel da organização é de autoridade. |
attribution_url |
URL | Opcional | O URL da organização. |
attribution_email |
Opcional | O e-mail da organização. | |
attribution_phone |
Número de telefone | Opcional | O número de telefone da organização. |