GTFS primária
Estas são práticas recomendadas para descrever os serviços de transporte público na Especificação Geral sobre Feeds de Transporte Público (GTFS). Elas foram sintetizadas com base na experiência dos membros do grupo de trabalho de práticas recomendadas para a GTFS e nas recomendações para aplicações específicas. Saiba mais nas Perguntas frequentes.
Estrutura do documento
As práticas estão organizadas em três seções principais:
- Práticas gerais e publicação de conjuntos de dados: essas práticas estão relacionadas à estrutura geral do conjunto de dados da GTFS e ao modo como eles são publicados.
- Práticas recomendadas organizadas por arquivo: as recomendações são organizadas por arquivo e campo na GTFS para facilitar a correspondência das práticas com a referência oficial da GTFS.
- Práticas recomendadas organizadas por caso: em casos específicos, como alças de acesso, as práticas podem ser aplicadas a vários arquivos e campos. Essas recomendações estão descritas nesta seção.
Perguntas frequentes
Por que essas práticas recomendadas para a GTFS são importantes?
Os objetivos das práticas recomendadas para a GTFS são:
- melhorar a experiência do usuário final em apps de transporte público;
- permitir ampla interoperabilidade de dados para facilitar a implantação e o escalonamento de aplicativos, produtos e serviços pelos desenvolvedores de software;
- facilitar o uso da GTFS em várias categorias de aplicações, além do planejamento da viagem.
Sem a sistematização das práticas recomendadas para a GTFS, os vários aplicativos que usam essa especificação aplicariam requisitos e expectativas de forma não coordenada, resultando em abordagens divergentes nos conjuntos de dados e menor interoperabilidade. Antes do lançamento das práticas recomendadas, havia grande incoerência e discordância quanto à formatação correta dos dados da GTFS.
Como elas foram desenvolvidas? Por quem?
Essas práticas recomendadas foram desenvolvidas por um grupo de trabalho de 17 organizações, incluindo fornecedores de apps, consumidores de dados, provedores de transporte público e consultores especializados na GTFS. Esse grupo foi montado e coordenado pelo Rock Mountain Institute.
Os membros votaram em cada prática recomendada, e a maioria delas foi aprovada por unanimidade. Apenas algumas foram aprovadas sem o voto de todas as organizações.
Por que não mudar a referência da GTFS?
Boa pergunta! Ao analisarmos a especificação, o uso de dados e as necessidades, descobrimos que algumas mudanças precisam ser feitas (consulte Solicitações de envio fechadas no GitHub, página em inglês). As mudanças na referência estão sujeitas a um processo de investigação mais detalhado do que as práticas recomendadas. No entanto, ainda é preciso definir um conjunto claro de recomendações de práticas recomendadas.
O grupo de trabalho prevê que algumas delas serão integradas à referência da GTFS primária.
As ferramentas de validação da GTFS verificam a conformidade com essas práticas recomendadas?
Atualmente, nenhuma ferramenta de validação verifica a conformidade com todas as práticas recomendadas, mas várias ferramentas inspecionam a compatibilidade com algumas dessas práticas. Para conferir uma lista das ferramentas de validação da GTFS, consulte Como testar feeds. Se você criar uma ferramenta de validação da GTFS que usa essas práticas recomendadas como base, escreva para gtfs@rmi.org.
Represento uma empresa de transporte público. Quais medidas posso adotar para que nossos provedores de serviços de software sigam essas práticas recomendadas?
Envie essas práticas recomendadas ao seu provedor de serviços de software. Recomendamos que você mencione o URL das práticas recomendadas para a GTFS e a referência da especificação primária ao adquirir um software que use a GTFS como base.
O que devo fazer se um feed de dados da GTFS não está em conformidade com essas práticas recomendadas?
Identifique o contato responsável pelo feed usando os campos feed_contact_email ou feed_contact_url propostos em feed_info.txt (se houver) ou procurando no site da empresa de transporte público ou do produtor do feed. Ao comunicar o problema ao produtor do feed, inclua o link para a prática recomendada em questão. Consulte Como adicionar um link para este documento.
Quero propor uma mudança/adição às práticas recomendadas. Como faço isso?
Envie um e-mail para gtfs@rmi.org ou abra um tíquete ou uma solicitação de envio no repositório de práticas recomendadas para a GTFS do GitHub (em inglês).
Como posso participar?
Envie um e-mail para gtfs@rmi.org.
Práticas gerais e publicação de conjuntos de dados
| Recomendações gerais |
|---|
| Os conjuntos de dados precisam ser publicados em um URL público permanente que inclua o nome do arquivo ZIP, por exemplo, www.agency.org/gtfs/gtfs.zip. O ideal é que o URL acione o download diretamente, sem exigir login para acessar o arquivo, porque isso facilita o processo para os aplicativos que usam a especificação. Embora seja recomendado (e mais comum) permitir que um conjunto de dados da GTFS fique disponível para download, se um provedor precisar controlar o acesso à GTFS para fins de licenciamento ou outros motivos, ele poderá usar chaves de API, o que facilita os downloads automáticos. |
| Os dados da GTFS são publicados em iterações para que um único arquivo em um local estável sempre contenha a descrição oficial mais recente do serviço para as empresas de transporte público. |
Sempre que possível, use identificadores permanentes (campos de ID) para stop_id, route_id e agency_id em todas as iterações de dados.
|
Um conjunto de dados da GTFS precisa conter o serviço atual e futuro (às vezes chamado de conjunto de dados "mesclados"). É possível usar a função de mesclagem da ferramenta Google Transitfeed para criar um conjunto de dados mesclados de dois feeds da GTFS diferentes.
|
| Remova os serviços antigos (programações expiradas) do feed. |
| Se uma modificação de serviço for feita em até sete dias, implemente essa mudança usando um feed GTFS Realtime (recomendações de serviços ou atualizações de viagens), em vez de um conjunto de dados da GTFS estática. |
| O servidor da Web que hospeda os dados da GTFS deve ser configurado para informar corretamente a data de modificação do arquivo. Consulte HTTP/1.1 – Solicitação de comentários 2616, na seção 14.29 (link em inglês). |
Práticas recomendadas organizadas por arquivo
Nesta seção, mostramos as práticas organizadas por arquivo e campo, de acordo com a referência da GTFS.
Todos os arquivos
| Nome do campo | Recomendação |
|---|---|
| Uso misto de maiúsculas e minúsculas | Todas as strings de texto visíveis para o cliente (incluindo nomes de paradas/trajetos e letreiros) devem usar letras maiúsculas e minúsculas seguindo as convenções locais referentes a nomes de lugares em telas que oferecem suporte a caracteres minúsculos. |
| Exemplos: | |
| Praça Brighton Churchill | |
| Villiers-Sur-Marne | |
| Market Street | |
| Abreviações | Evite usar abreviações no feed para nomes e outros textos (por exemplo, R. para Rua), a menos que um local seja chamado pelo nome abreviado (por exemplo, "Aeroporto JFK"). As abreviações podem atrapalhar a identificação por interfaces de voz e leitores de tela. É possível configurar o software para converter com segurança palavras inteiras em abreviações, mas o processo contrário pode levar a um risco maior de erros. |
agency.txt
| Nome do campo | Recomendação |
|---|---|
agency_id |
Precisa ser incluído, mesmo se houver apenas uma empresa no feed. Consulte também a recomendação para incluir agency_id no routes.txt e fare_attributes.txt. |
agency_lang |
Precisa ser incluído. |
agency_phone |
Precisa ser incluído, a menos que não exista um telefone de atendimento ao cliente. |
agency_email |
Precisa ser incluído, a menos que não exista um e-mail de atendimento ao cliente. |
agency_fare_url |
Precisa ser incluído, a menos que a empresa não cobre pelo serviço. |
Exemplos:
- Os serviços de ônibus são operados por várias empresas de ônibus de pequeno porte. Mas há uma maior que é responsável pelos horários e pela venda de passagens, e, do ponto de vista do usuário, ela também é responsável pelos serviços de ônibus. Portanto, é preciso adicionar essa empresa ao feed. Mesmo que os dados sejam divididos internamente por diferentes operadores de ônibus de pequeno porte, deve haver apenas uma empresa definida no feed.
- Embora o provedor do feed gerencie o portal de passagens, também há outras empresas que operam os serviços, e os usuários acreditam que elas são as responsáveis. Essas empresas que realmente operam os serviços devem ser adicionadas ao feed.
stops.txt
| Nome do campo | Recomendação | ||||||||
|---|---|---|---|---|---|---|---|---|---|
stop_id |
Paradas que estão em locais físicos diferentes (ou seja, lugares designados para parada de veículos em trajetos específicos, possivelmente indicados por placas, coberturas ou outras informações públicas, localizados em esquinas diferentes ou contendo seções de embarque, como plataformas ou pontos de ônibus, mesmo que estejam próximos entre si) precisam ter um stop_id diferente. |
||||||||
stop_id é um ID interno que não será exibido aos passageiros. |
|||||||||
Use o mesmo stop_id em paradas idênticas nas iterações de dados (consulte Práticas gerais e publicação de conjuntos de dados). |
|||||||||
stop_name |
O stop_name precisa ser igual ao nome público da empresa para a parada, estação ou seção de embarque, por exemplo, as informações impressas em um horário publicado on-line e/ou exibido no local. |
||||||||
| Quando não houver um nome de parada publicado, use a mesma convenção de nomenclatura em todo o feed. | |||||||||
| Evite usar abreviações, exceto para lugares que são conhecidos por um nome abreviado. Consulte Abreviações (#2) em Todos os arquivos. | |||||||||
| Forneça nomes de paradas com letras maiúsculas e minúsculas seguindo as convenções locais, de acordo com a recomendação para todos os campos de texto visíveis ao cliente. | |||||||||
Por padrão, stop_name não pode conter palavras genéricas ou redundantes, como "Estação" ou "Parada", mas alguns casos são permitidos.
|
|||||||||
stop_lat e stop_lon |
Os locais das paradas devem ser o mais precisos possível e ter uma margem de erro de no máximo quatro metros em comparação com a posição real. | ||||||||
| Os locais das paradas devem ser posicionados próximos do ponto de embarque do passageiro, ou seja, no lado correto da rua. | |||||||||
Se um local de parada for compartilhado em feeds de dados separados (ou seja, duas empresas usam exatamente o mesmo ponto de parada / embarque), indique usando stop_lat e stop_lon para as duas paradas. |
|||||||||
stop_code |
stop_code precisa ser incluído na GTFS caso haja identificadores curtos ou números de parada visíveis aos passageiros. |
||||||||
parent_station e location_type |
Muitas estações ou terminais têm vários pontos de embarque (dependendo do modo, podem ser chamados de ponto de ônibus, plataforma, cais, portão ou outro termo). Nesses casos, os produtores do feed precisam descrever as estações, as seções de embarque (também chamadas de paradas secundárias) e a relação delas.
|
||||||||
Ao nomear a estação e as paradas secundárias, defina nomes que sejam bem reconhecidos pelos passageiros e que ajudem a identificar a estação e a seção de embarque (ponto de ônibus, plataforma, cais, portão etc.).
|
routes.txt
| Nome do campo | Recomendação | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
agency_id |
Precisa ser incluído se estiver definido no agency.txt. |
||||||||||||||||||||
route_short_name |
Inclua route_short_name se houver uma denominação curta do serviço. Esse nome precisa ser o mais conhecido do serviço e ter até 12 caracteres. |
||||||||||||||||||||
route_long_name |
Definição da referência da especificação: este nome geralmente é mais descritivo que o Confira abaixo alguns exemplos de tipos de nome longo:
|
||||||||||||||||||||
route_long_name não deve conter route_short_name. |
|||||||||||||||||||||
Inclua a denominação completa, incluindo uma identidade de serviço, ao preencher route_long_name. Exemplos:
|
|||||||||||||||||||||
route_id |
Todas as viagens em um determinado trajeto precisam fazer referência ao mesmo route_id.
|
||||||||||||||||||||
Se um grupo de trajetos incluir bifurcações com nomes distintos (por exemplo, 1A e 1B), siga as recomendações na seção Bifurcações para determinar route_short_name e route_long_name. |
|||||||||||||||||||||
route_color e route_text_color |
Precisa ser consistente com a sinalização e as informações impressas e on-line dos clientes. Portanto, não deverão ser incluídas se não tiverem sido publicadas. | ||||||||||||||||||||
trips.txt
- Confira um caso especial para alças de acesso: nelas, a viagem começa e termina na mesma parada, ao contrário dos trajetos lineares, que têm dois terminais. Elas precisam ser descritas de acordo com as práticas relacionadas. Confira a seção sobre alças de acesso.
- Confira um caso especial para vias de acesso multidirecionais: esse tipo de via é uma combinação de geometrias lineares e circulares, em que os veículos percorrem uma alça de acesso apenas em uma parte do trajeto. Elas precisam ser descritas de acordo com as práticas relacionadas. Confira a seção sobre vias de acesso multidirecionais.
| Nome do campo | Recomendação | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
Não adicione nomes de trajetos (correspondentes a route_short_name e route_long_name) aos campos trip_headsign ou stop_headsign. |
||||||||||||||
Precisa conter destino, rota e/ou outro texto de denominação da viagem mostrado no letreiro do veículo que pode ser usado para distinguir as viagens de um trajeto.
Ao determinar os letreiros fornecidos nos conjuntos de dados da GTFS, é importante manter a consistência com as informações de rotas mostradas no veículo. Só inclua outras informações se elas não comprometerem essa meta. Se os letreiros mudarem durante uma viagem, substitua trip_headsign por stop_times.stop_headsign. Confira abaixo as recomendações para alguns casos possíveis: |
|||||||||||||||
Exemplo de tabela:
|
|||||||||||||||
| Não comece um letreiro com as palavras "Para” ou "Com destino a". | |||||||||||||||
direction_id |
Se as viagens em um trajeto têm sentidos contrários, diferencie esses grupos de viagens com o campo direction_id usando os valores 0 e 1. |
||||||||||||||
Use os valores 0 e 1 de forma consistente em todo o conjunto de dados, ou seja:
|
stop_times.txt
Alças de acesso: esse tipo de trajeto tem requisitos especiais para stop_times. Confira a seção sobre alças de acesso.
| Nome do campo | Recomendação | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pickup_type e drop_off_type |
Para viagens que não geram receita ou sem passageiros, defina os campos pickup_type e drop_off_type como 1 em todas as linhas stop_times. |
||||||||||||
Nas viagens que geram receita, as paradas para monitorar a performance operacional e em lugares como garagens, onde passageiros não podem embarcar, precisam ter pickup_type = 1 (sem embarque) e drop_off_type = 1 (sem desembarque disponível). |
|||||||||||||
timepoint |
O campo timepoint precisa ser adicionado. Ele especifica quais stop_times o operador adotará (timepoint=1) e quais são os outros horários de parada estimados (timepoint=0). |
||||||||||||
arrival_time e departure_time |
Os campos arrival_time e departure_time precisam especificar valores de horário sempre que possível, incluindo horários estimados ou interpolados não vinculados entre os pontos de tempo. |
||||||||||||
stop_headsign |
Os valores de
Nos casos abaixo, "Sentido sul" confunde os clientes porque não é usado nas placas da estação. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
| shape_dist_traveled | shape_dist_traveled precisa ser indicado para trajetos com rota circular ou que repetem parte da rota, por exemplo, o veículo cruza ou percorre a mesma parte da rodovia em uma viagem. Consulte a recomendação para shapes.shape_dist_traveled. |
||||||||||||
calendar.txt
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | calendar_dates.txt precisa conter apenas um número limitado de exceções à programação. Configure o serviço programado regular usando calendar.txt.
|
Incluir um campo calendar.service_name também pode melhorar o reconhecimento da GTFS pelas pessoas, embora essa sugestão não seja mencionada na especificação. |
calendar_dates.txt
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | calendar_dates.txt precisa conter apenas um número limitado de exceções à programação. Configure o serviço programado regular usando calendar.txt.
|
Incluir um campo calendar.service_name também pode melhorar o reconhecimento da GTFS pelas pessoas, embora essa sugestão não seja mencionada na especificação. |
fare_attributes.txt
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | agency_id vai precisar ser incluído no fare_attributes.txt se o campo for adicionado ao agency.txt. |
| Se não for possível definir um sistema de tarifas com precisão, deixe esse campo em branco. | |
Inclua as tarifas (fare_attributes.txt e fare_rules.txt) e use os valores mais precisos possíveis. Nos casos extremos em que as tarifas não puderem ser definidas com precisão, superestime o valor para que os clientes não embarquem sem dinheiro suficiente. Se a grande maioria das tarifas não puder ser determinada corretamente, não inclua informações de tarifa no feed. |
fare_rules.txt
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | agency_id vai precisar ser incluído no fare_attributes.txt se o campo for adicionado ao agency.txt. |
| Se não for possível definir um sistema de tarifas com precisão, deixe esse campo em branco. | |
Inclua as tarifas (fare_attributes.txt e fare_rules.txt) e use os valores mais precisos possíveis. Nos casos extremos em que as tarifas não puderem ser definidas com precisão, superestime o valor para que os clientes não embarquem sem dinheiro suficiente. Se a grande maioria das tarifas não puder ser determinada corretamente, não inclua informações de tarifa no feed. |
shapes.txt
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | No caso de alinhamentos compartilhados (ou seja, em que os Trajetos 1 e 2 operam no mesmo trecho da via ou rota), a parte compartilhada precisa ser idêntica. Isso aumenta a qualidade da cartografia de transporte público. |
| Os alinhamentos devem seguir a linha central à direita do trajeto que o veículo percorre.
Pode ser a linha central da rua se não houver pistas designadas ou a linha central da estrada no sentido em que o veículo se move. Os alinhamentos não podem fazer curvas acentuadas para servir pontos de parada ou entrar em plataformas ou locais de embarque. |
|
shape_dist_traveled |
Precisa ser indicado no 
Se um veículo retorna ou cruza o alinhamento do trajeto em pontos ao longo de uma viagem, é importante inserir |
O campo shape_dist_traveled permite que a empresa especifique exatamente como as paradas no arquivo stop_times.txt se enquadram nos respectivos polígonos. Um valor comum a ser usado no campo shape_dist_traveled é a distância a partir do início do polígono à medida que ele é percorrido pelo veículo. É semelhante à leitura de um odômetro.
|
feed_info.txt
feed_info.txt precisa ser incluído com todos os campos abaixo.
| Nome do campo | Recomendação |
|---|---|
feed_start_date e feed_end_date |
Precisam ser incluídos |
feed_version |
Precisam ser incluídos |
feed_contact_email e feed_contact_url |
Informe pelo menos um deles |
frequencies.txt
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | Os horários de parada reais são ignorados para viagens referenciadas pelo frequencies.txt. Apenas os intervalos de tempo de viagem entre as paradas são importantes para viagens com base em frequência.
Para maior clareza, é recomendável que o primeiro horário de parada de uma viagem indicada no frequencies.txt comece às 00:00:00 (primeiro valor arrival_time de 00:00:00). |
block_id |
Pode ser indicado para viagens com base em frequência. |
transfers.txt
transfers.transfer_type pode ser um dos quatro valores definidos na GTFS. Essas definições de transfer_type são citadas na especificação da GTFS abaixo, além de outras recomendações de prática.
| Nome do campo | Recomendação |
|---|---|
transfer_type |
Se houver várias oportunidades de baldeação que incluam uma opção superior (por exemplo, um terminal com comodidades adicionais ou uma estação com instalações/plataformas de embarque adjacentes ou conectadas), especifique um ponto de baldeação recomendado. |
Cada consumidor de dados calcula o tempo necessário desse intervalo usando o próprio algoritmo. Se esse valor for insuficiente ou houver outras condições não consideradas pelo consumidor, modifique os cálculos de tempo depois de definir o |
|
Especifique o tempo mínimo de baldeação se houver obstruções ou outros fatores que aumentem o tempo de viagem entre as paradas. |
|
Especifique esse valor se não for possível fazer baldeações devido a barreiras físicas ou se houver cruzamentos ou lacunas para os pedestres que tornem as transferências difíceis ou perigosas. |
|
| Se baldeações sem trocar de veículo forem permitidas entre as viagens, a última parada da viagem de chegada precisa ser a mesma da primeira parada da viagem de partida. |
Práticas recomendadas organizadas por caso
Nesta seção, descrevemos casos específicos com implicações em arquivos e campos.
Alças de acesso
Em alças de acesso, as viagens de veículos começam e terminam no mesmo local (às vezes um terminal ou um ponto de baldeação). Normalmente, os veículos operam continuamente e permitem que os passageiros permaneçam a bordo durante o trajeto.
Portanto, use as recomendações de letreiros para mostrar aos passageiros o sentido do veículo.
Para indicar a mudança de direção do trajeto, adicione stop_headsigns ao arquivo stop_times.txt. O stop_headsign descreve a direção das viagens partindo do ponto definido. Adicionar stop_headsigns a cada parada permite que você altere as informações do letreiro ao longo de uma viagem.
Não defina apenas uma viagem circular no arquivo stop_times.txt de um trajeto que opera entre dois pontos de destino (por exemplo, quando o ônibus tem um trajeto de ida e volta). Em vez disso, divida a viagem em duas direções separadas.
Exemplos de modelagem de viagens circulares:
Viagem circular com letreiro que muda a cada parada:
Trip_id |
arrival_time |
departure_time |
stop_id |
stop_sequence |
stop_headsign |
|---|---|---|---|---|---|
trip_1 |
06:10:00 |
06:10:00 |
stop_A |
1 |
"B" |
trip_1 |
06:15:00 |
06:15:00 |
stop_B |
2 |
"C" |
trip_1 |
06:20:00 |
06:20:00 |
stop_C |
3 |
"D" |
trip_1 |
06:25:00 |
06:25:00 |
stop_D |
4 |
"E" |
trip_1 |
06:30:00 |
06:30:00 |
stop_E |
5 |
"A" |
trip_1 |
06:35:00 |
06:35:00 |
stop_A |
6 |
"" |
Viagem circular com dois letreiros:
Trip_id |
arrival_time |
departure_time |
stop_id |
stop_sequence |
stop_headsign |
|---|---|---|---|---|---|
trip_1 |
06:10:00 |
06:10:00 |
stop_A |
1 |
"outbound" |
trip_1 |
06:15:00 |
06:15:00 |
stop_B |
2 |
"outbound" |
trip_1 |
06:20:00 |
06:20:00 |
stop_C |
3 |
"outbound" |
trip_1 |
06:25:00 |
06:25:00 |
stop_D |
4 |
"inbound" |
trip_1 |
06:30:00 |
06:30:00 |
stop_E |
5 |
"inbound" |
trip_1 |
06:35:00 |
06:35:00 |
stop_F |
6 |
"inbound" |
trip_1 |
06:40:00 |
06:40:00 |
stop_A |
7 |
"" |
| Nome do campo | Recomendação | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
Defina a viagem de ida e volta completa para o trajeto circular com uma única viagem. | |||||||||||||||
stop_times.stop_id |
Inclua a primeira/última parada duas vezes no stop_times.txt para a viagem circular. Confira um exemplo abaixo. Muitas vezes, um trajeto circular pode incluir primeiras e últimas viagens que não percorrem o ciclo inteiro. Inclua essas viagens também.
|
|||||||||||||||
trips.direction_id |
Se a alça de acesso funcionar em direções opostas (por exemplo, sentido horário e anti-horário), atribua direction_id como 0 ou 1. |
|||||||||||||||
trips.block_id |
Indique viagens circulares contínuas com o mesmo block_id. |
Vias de acesso multidirecionais
As vias de acesso multidirecionais combinam aspectos de uma alça de acesso e de um trajeto multidirecional.
- Seção reta de A a B
- Seção circular de B até B
- Seção reta de B até A
| Exemplos: |
|---|
| Trajetos de metrô (Chicago) |
| Trajetos de ônibus de áreas periféricas até o centro da cidade (St. Albert ou Edmonton) |
| Linha marrom da CTA (Site da CTA e TransitFeeds) |
| Nome do campo | Recomendação | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
A extensão completa de uma "viagem de ida e volta do veículo" (confira a ilustração acima) consiste em um trajeto de A para B, de volta até B e depois para A. Uma viagem de ida e volta do veículo pode ser expressa da seguinte maneira:
trip_id no trips.txttrip_id no trips.txt, com uma viagem contínua indicada por block_id |
||||||||||
stop_times.stop_headsign |
É preciso enviar paradas nos dois sentidos ao longo da seção A-B.
stop_headsign facilita a distinção entre as rotas. Portanto, é recomendável informar stop_headsign para essas viagens.
|
||||||||||
trip.trip_headsign |
O letreiro precisa ser uma descrição global da viagem, conforme exibido nas programações. Pode ser "Linden até Linden via Alça de acesso" (exemplo de Chicago) ou "A para A via B" (exemplo genérico). |
Bifurcações
Alguns trajetos podem incluir bifurcações. O alinhamento e as paradas são compartilhados entre essas bifurcações, mas cada uma mostra seções distintas de alinhamento e paradas. A relação entre as bifurcações pode ser indicada por nomes de trajeto, letreiros e nomes curtos de viagem usando as diretrizes abaixo.
| Nome do campo | Recomendação |
|---|---|
| Todos os campos | Ao nomear trajetos de bifurcação, siga as orientações em outros materiais de informação para passageiros. Confira abaixo as descrições e exemplos para dois casos: |
Se os horários e as sinalizações nas ruas representam dois trajetos com nomes diferentes (por exemplo, 1A e 1B), indique essas informações conforme especificado na GTFS, usando os campos route_short_name e/ou route_long_name. Por exemplo: os trajetos da GoDurham 2, 2A e 2B compartilham um alinhamento ao longo da maior parte da rota, mas têm alguns aspectos diferenciados.
|
|
Se as informações fornecidas pela empresa descreverem bifurcações como trajetos de mesmo nome, utilize os campos trips.trip_headsign, stop_times.stop_headsign e/ou trips.trip_short_name. Por exemplo, a linha 300 da GoTriangle leva a locais diferentes, dependendo da hora do dia. Durante os horários de pico, outros caminhos são adicionados ao trajeto padrão para atender os trabalhadores que entram e saem da cidade. |
Sobre este documento
Objetivos
O objetivo da manutenção das práticas recomendadas para a GTFS é:
- oferecer maior interoperabilidade dos dados de transporte público;
- melhorar a experiência do cliente final em apps de transporte público;
- facilitar a implantação e o escalonamento de aplicativos, produtos e serviços para desenvolvedores de software;
- facilitar o uso da GTFS em várias categorias de aplicações, além do planejamento da viagem.
Como propor ou alterar as práticas recomendadas para a GTFS
As aplicações e a prática para a GTFS evoluem com o tempo, e talvez este documento precise ser alterado periodicamente. Para propor uma modificação neste documento, abra uma solicitação de envio no repositório de práticas recomendadas para a GTFS do GitHub (link em inglês). Você também pode enviar um e-mail para specifications@mobilitydata.org.
Link deste documento
Inclua um link aqui para fornecer orientações sobre a formação correta dos dados da GTFS aos produtores de feed. Cada recomendação tem um link fixo. Clique nela para conferir o URL do link fixo na página.
Se um aplicativo que usa a GTFS tem requisitos ou recomendações de práticas relacionadas a dados da GTFS não descritos aqui, publique um documento para complementar as práticas recomendadas comuns.
Grupo de trabalho de práticas recomendadas para a GTFS
O grupo de trabalho de práticas recomendadas para a GTFS foi coordenado pelo Rocky Mountain Institute (link em inglês) entre 2016 e 2017, com provedores de transporte público, desenvolvedores de aplicativos que usam a GTFS, consultores e organizações acadêmicas que ajudam a definir as práticas comuns e expectativas quanto a dados da GTFS. Estes foram os participantes (maior parte dos links em inglês):
- Cambridge Systematics
- Capital Metro
- Centro de Pesquisa sobre Transportes Urbanos da Universidade do Sul da Flórida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Departamento de Transporte do Oregon
- Swiftly
- Transit
- Trillium
- TriMet
- Banco Mundial
Atualmente, este documento é mantido pela organização internacional MobilityData.