Práticas recomendadas para GTFS

GTFS primária

Essas 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, na sigla em inglês). 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:

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, realmente descobrimos que algumas mudanças precisam ser feitas (consulte Solicitações de envio fechadas no GitHub, página em inglês). As alterações da 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 ver uma lista das ferramentas de validação da GTFS, consulte Como testar feeds. Se você criar uma ferramenta de validação da GTFS que use 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 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 usar aplicativos de software facilita o processo. Embora seja recomendado (e seja a prática 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 facilitará 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.
  • Esse conjunto publicado precisa ser válido pelos próximos sete dias (no mínimo) e, de preferência, pelo tempo de operação da programação previsto pelo operador.
  • Se possível, o conjunto de dados da GTFS precisa cobrir, pelo menos, os próximos 30 dias de serviço.
Remova os serviços antigos (programações expiradas) do feed.
Se for feita uma modificação de serviço em até sete dias, aplique essa mudança usando um feed GTFS Realtime (recomendações de serviço ou atualizações de viagem), 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.

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
Capitalização mista 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 para capitalização de nomes de lugares em telas que oferecem suporte à exibição de 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.
  • Quando fazem parte do nome (Estação Union, Estação Central).
  • Quando stop_name é muito genérico (por exemplo, se for o nome da cidade), e "Estação", "Terminal" ou outras palavras esclarecem o significado.
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.
  • A estação ou o terminal deve ser definido como um registro no stops.txt com location_type = 1.
  • Cada seção de embarque precisa ser definida como uma parada usando location_type = 0. O campo parent_station precisa mencionar o stop_id da estação em que a seção está.
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.).
Nome da estação principal Nome da parada secundária
Estação Union (Chicago) Plataforma 19 da Estação Union (Chicago)
Terminal San Francisco Ferry Building Portão E do Terminal San Francisco Ferry Building
Downtown Transit Center Baía B do Downtown Transit Center

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 route_short_name e normalmente inclui o destino ou a parada do trajeto. É preciso especificar route_short_name ou route_long_name. Se adequado, ambos podem ser definidos. Se o trajeto não tiver um nome longo, especifique um route_short_name e use uma string vazia como valor para este campo.

Veja abaixo alguns exemplos de tipos de nome longo:

Caminho ou corredor do trajeto principal
Nome do trajeto Formulário Empresa
"N"/"Judah" route_short_name/
route_long_name
Muni, em São Francisco
"6"/"ML King Jr Blvd" route_short_name/
route_long_name
TriMet, em Portland, Oregon
"6"/"Nation - Étoile" route_short_name/
route_long_name
RATP, em Paris, França
"U2"/ "Pankow – Ruhleben" route_short_name/
route_long_name
BVG, em Berlim, Alemanha
Descrição do serviço
"Hartwell Area Shuttle"
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:
Identidade do serviço Recomendação Exemplos
"MAX Light Rail"
TriMet, em Portland, Oregon
O route_long_name precisa incluir a marca (MAX) e a denominação do trajeto específico. "Linha vermelha MAX"
"Linha azul MAX"
"Rapid Ride"
ABQ Ride, em Albuquerque, Novo México
O route_long_name precisa incluir a marca (Rapid Ride) e a denominação do trajeto específico. "Linha vermelha Rapid Ride"
"Linha azul Rapid Ride"
route_id Todas as viagens em um determinado trajeto precisam fazer referência ao mesmo route_id.
  • Não separe sentidos diferentes de um trajeto em valores route_id distintos.
  • Não separe diferentes períodos de operação de um trajeto em valores route_id distintos. Ou seja, não crie registros diferentes no routes.txt para os serviços "Downtown AM" e "Downtown PM".
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

  • Veja um caso especial para alças de acesso: nas alças de acesso, a viagem começa e termina na mesma parada, ao contrário dos trajetos lineares, que têm dois terminais diferentes. Elas precisam ser descritas de acordo com as práticas relacionadas. Veja a seção sobre alças de acesso.
  • Veja 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. Veja a seção sobre vias de acesso multidirecionais.
Nome do campo Recomendação
trip_headsign Não adicione nomes de trajeto (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. Veja abaixo as recomendações para alguns casos possíveis:
Exemplo de tabela:
Descrição do trajeto Recomendação
2A. Somente destino Informe o destino final. Por exemplo, "Transit Center", "Centro de Portland" ou "Praia Jantzen".
2B. Destinos com waypoints <destino> pelo <waypoint> "Highgate via Charing Cross". Se, depois que o veículo passar pelos waypoints, eles forem removidos do letreiro exibido aos passageiros, use stop_times.stop_headsign para mostrar um letreiro atualizado.
2C. Nome regional do lugar com paradas locais Se houver várias paradas na cidade ou no município de destino, use stop_times.stop_headsign ao chegar à cidade final.
2D. Somente rota Indique usando termos como "Sentido norte", "Entrada", "Sentido horário" ou rotas semelhantes.
2E. Rota com destino <sentido> para <nome do terminal>, por exemplo, "Sentido sul para San José".
2F. Rota com destino e waypoints <sentido> via <waypoint> para <destino> ("Sentido norte via Charing Cross para Highgate").
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:
  • se 1 = Saída no Trajeto Vermelho, então 1 = Saída no Trajeto Verde;
  • se 1 = Sentido norte no Trajeto X, então 1 = Sentido norte no Trajeto Y;
  • se 1 = Sentido horário no Trajeto X, então 1 = Sentido horário no Trajeto Y.

stop_times.txt

Alças de acesso: esse tipo de trajeto tem requisitos especiais para stop_times. Veja 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 o desempenho 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 stop_headsign substituem o trip_headsign (no trips.txt). Os valores de stop_headsign precisam ser indicados quando o texto exibido no letreiro muda durante uma viagem. Os valores de stop_headsign não serão transferidos para as paradas subsequentes. Assim, os valores precisarão ser repetidos se o letreiro permanecer o mesmo. Em geral, os valores de letreiro também devem corresponder às placas nas estações.

Nos casos abaixo, "Sentido sul" confunde os clientes porque não é usado nas placas da estação.

Em Nova York, para os dois trajetos "Sentido sul":
Para linhas do stop_times.txt: Usar o valor de stop_headsign:
Até chegar a Manhattan Manhattan & Brooklyn
Até chegar ao centro da cidade Downtown & Brooklyn
Até chegar ao Brooklyn Brooklyn
Quando chegar ao Brooklyn Brooklyn (New Lots Av)
Em Boston, para a Linha Vermelha – Sentido sul até a bifurcação de Braintree:
Para linhas do stop_times.txt: Usar o valor de stop_headsign:
Até chegar ao centro da cidade Inbound to Braintree
Quando chegar ao centro da cidade Braintree
Após passar pelo centro da cidade Outbound to Braintree
shape_dist_traveled shape_dist_traveled precisa ser indicado para trajetos com rota circular ou que repetem parte da rota (o veículo cruza ou percorre a mesma parte de 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 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 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 shapes.txt e no stop_times.txt caso um alinhamento inclua trajetos circulares ou que repetem parte da rota (o veículo cruza ou percorre a mesma parte do alinhamento em uma viagem).

Trajeto que repete parte da rota

Se um veículo retorna ou cruza o alinhamento do trajeto em pontos ao longo de uma viagem, é importante inserir shape_dist_traveled para esclarecer como as partes dos pontos na linha para cima do shapes.txt correspondem aos registros no stop_times.txt:

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.
  • Os alinhamentos de trajeto (no shapes.txt) precisam estar a até 100 metros dos locais de parada de uma viagem.
  • Simplifique os alinhamentos para que shapes.txt não contenha pontos irrelevantes, ou seja, remova pontos extras nos segmentos de linha reta. Veja a seção sobre simplificação de linha.

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 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 0 ou vazio: é um ponto de baldeação recomendado entre os trajetos.

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.

1: é um 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.

Esse tipo de baldeação substitui um intervalo necessário para fazer transferências de maneira confiável. Por exemplo, o Google Maps supõe que os passageiros precisam de três minutos para fazer uma baldeação com tranquilidade. Outros aplicativos podem adotar outros padrões.

2: essa baldeação requer um período mínimo de tempo entre a chegada e a partida para garantir uma conexão. O tempo necessário para a baldeação é especificado por min_transfer_time.

Especifique o tempo mínimo de baldeação se houver obstruções ou outros fatores que aumentem o tempo de viagem entre as paradas.

3: não é possível fazer baldeações entre trajetos neste local.

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.

Veja abaixo uma alça de acesso. O veículo retorna ao ponto de partida em uma viagem. Algumas alças de acesso oferecem viagens para um sentido, e outras para dois sentidos.
Alça de acesso

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. Veja 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.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
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.

Veja a seguir: vias de acesso multidirecionais são trajetos circulares de A até A passando B com três seções:
  • Seção reta de A a B
  • Seção circular de B até B
  • Seção reta de B até A
Via de acesso multidirecional
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" (veja 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:
  • Um valor/registro único de trip_id no trips.txt
  • Vários valores/registros de trip_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.
    Exemplos:
    "A via B"
    "A"
    Linha Roxa da Chicago Transit Authority
    "Sentido sul até a Alça de acesso"
    "Sentido norte pela Alça de acesso"
    "Sentido norte com destino a Linden"
    Linhas de ônibus 39 do serviço rodoviário de Edmonton
    "Rutherford"
    "Parque Century"
    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 exibe 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.

    Veja a seguir três possíveis configurações de bifurcações de trajeto. O alinhamento principal está em preto. A bifurcação está em dourado.
    Configurações de bifurcações de trajeto
    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. Veja 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.
    • O Trajeto 2 é um serviço principal que opera quase ininterruptamente.
    • O Trajeto 2 inclui um desvio aos domingos e feriados e à noite na Main Street.
    • Os Trajetos 2A e 2B operam 24 horas por dia, de segunda a sábado.
    • O Trajeto 2B tem paradas adicionais em um desvio do alinhamento compartilhado.
    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 no GitHub. 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 ver 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 Rock Mountain Institute 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):

    Atualmente, este documento é mantido pela organização internacional MobilityData.