Skip to content

GTFS Schedule melhores práticas

Estas são práticas recomendadas para descrever os serviços de transporte público na General Transit Feed Specification (GTFS). Estas práticas foram sintetizadas a partir da experiência dos membros do GTFS Best Practices working group e recomendações de práticas específicas para aplicações GTFS.

Para maiores informações, veja as Perguntas Mais Frequentes.

Estrutura do documento

As práticas estão organizadas em quatro seções primárias:

Dataset Publishing & General Practices

  • Os conjuntos de dados devem ser publicados em uma URL pública e permanente, incluindo o nome do arquivo zip. (por exemplo, GTFS/GTFS.zip">GTFS. O ideal seria que a URL pudesse ser baixada diretamente sem exigir login para acessar o arquivo, para facilitar o download, consumindo aplicações de software. Embora seja recomendado (e a prática mais comum) fazer um conjunto de dados GTFS descarregar abertamente, se um provedor de dados precisar controlar o acesso ao GTFS para licenciamento ou outros motivos, é recomendado controlar o acesso ao conjunto de dados GTFS usando chaves API, o que facilitará os downloads automáticos.
  • Os dadosGTFS são publicados em iterações para que um único arquivo em um local estável sempre contenha a última descrição oficial de serviço para uma agência (ou agências) de trânsito.
  • Manter identificadores persistentes (campos id) para stop_id, route_id e agency_id através de iterações de dados sempre que possível.
  • Um conjunto de dados GTFS deve conter serviços atuais e futuros (às vezes chamados de conjuntos de dados "fundidos"). A função de fusão da ferramenta Google transitfeed pode ser usada para criar um conjunto de dados fundidos a partir de dois alimentadores GTFS diferentes.
    • A qualquer momento, o conjunto de dados GTFS publicado deve ser válido por pelo menos os próximos 7 dias e, idealmente, enquanto o operador estiver confiante de que a Schedule continuará a ser operada.
    • Se possível, o conjunto de dados GTFS deve cobrir pelo menos os próximos 30 dias de serviço.
  • Remover os serviços antigos (calendários vencidos) da ração.
  • Se uma modificação do serviço entrar em vigor em 7 dias ou menos, expresse esta mudança de serviço através de um feed GTFS-Realtime/">GTFS (serviços de consultoria ou atualizações de viagem) em vez de um conjunto de dados GTFS estático.
  • O servidor web que hospeda os dados GTFS deve ser configurado para informar corretamente a data de modificação do arquivo (ver HTTP/1.1 - Request for Comments 2616, na seção 14.29).

Recomendações Práticas Organizadas por Arquivo

Esta seção mostra práticas organizadas por arquivo e campo, alinhadas com a referência do GTFS.

Todos os arquivos

Nome do campo Recomendação
Estojo misto Todas as cadeias de texto voltadas para o cliente (incluindo nomes de paradas, nomes de rotas e cabeçalhos) devem usar Caixa Mista (não TODOS os CAPS), seguindo as convenções locais para capitalização de nomes de lugares em displays capazes de exibir caracteres em caixa baixa.
Exemplos:
Praça Brighton Churchill
Villiers-sur-Marne
Rua Market
Abreviaturas Evite o uso de abreviações em toda a alimentação para nomes e outros textos (por exemplo, St. for Street), a menos que um local seja chamado por seu nome abreviado (por exemplo, "Aeroporto JFK"). As abreviações podem ser problemáticas para a acessibilidade por software de leitor de tela e interfaces de usuário de voz. O software de consumo pode ser projetado para converter de forma confiável palavras completas em abreviaturas para exibição, mas a conversão de abreviaturas para palavras completas é propensa a mais risco de erro.

agency.txt

Nome do campo Recomendação
agency_id Deve ser incluída, mesmo que haja apenas uma agência na ração. (Veja também a recomendação de incluir agency_id em routes.txt e fare_attributes.txt)
agency_phone Deve ser incluído, a menos que não exista um telefone de atendimento ao cliente.
agency_email Deve ser incluído a menos que não exista tal e-mail de atendimento ao cliente.
agency_fare_url Deve ser incluído, a menos que a agência esteja totalmente livre.

Exemplos:

  • Os serviços de ônibus são administrados por várias pequenas agências de ônibus. Mas há uma grande agência que é responsável pela programação e emissão de bilhetes e, da perspectiva do usuário responsável pelos serviços de ônibus, a única grande agência deve ser definida como agência dentro do feed. Mesmo que os dados sejam divididos internamente por diferentes operadores de ônibus pequenos, deve haver apenas uma agência definida na ração.

  • O provedor de alimentação administra o portal de bilhetagem, mas existem diferentes agências que realmente operam os serviços e são conhecidas pelos usuários como sendo responsáveis. As agências que realmente operam os serviços devem ser definidas como agências dentro da ração.

stops.txt

Nome do campo Recomendação
stop_name Quando não houver um nome de parada publicado, siga as convenções consistentes de nomes de parada em toda a alimentação.
Por padrão, stop_name não deve conter palavras genéricas ou redundantes como "Estação" ou "Parar", mas alguns casos de borda são permitidos.
  • Quando na verdade faz parte do nome (Union Station, Central Station
  • Quando o stop_name é muito genérico (como se fosse o nome da cidade). "Estação", "Terminal", ou outras palavras, deixa o significado claro.
stop_lat & stop_lon Os locais de parada devem ser o mais precisos possível. Os locais de parada devem ter um erro de não mais de quatro metros quando comparado com a posição de parada real.
Os locais de parada devem ser colocados muito próximos à direita do pedestre onde um passageiro embarcará (ou seja, do lado correto da rua).
Se um local de parada for compartilhado através de alimentação de dados separados (ou seja, duas agências usam exatamente a mesma instalação de parada / embarque), indique que a parada é compartilhada usando exatamente a mesma stop_lat e stop_lon para ambas as paradas.
parent_station & location_type Muitas estações ou terminais têm múltiplas instalações de embarque (dependendo do modo, podem ser chamados de baía de ônibus, plataforma, cais, portão, ou outro termo). Nesses casos, os produtores de ração devem descrever estações, instalações de embarque (também chamadas de paradas para crianças), e sua relação.
  • A estação ou terminal deve ser definida como um registro em stops.txt com location_type = 1.
  • Cada instalação de embarque deve ser definida como uma parada com location_type = 0. O parent_station deve fazer referência ao campo stop_id da estação em que se encontra a instalação de embarque.
Ao nomear a estação e as paradas de crianças, defina nomes que sejam bem reconhecidos pelos cavaleiros e que possam ajudar os cavaleiros a identificar a estação e a instalação de embarque (baía, plataforma, cais, portão, etc.).
Nome da estação dos paisNome da parada da criança
Estação União de ChicagoPlataforma da Estação Union Station de Chicago 19
Terminal de São Francisco Ferry BuildingTerminal do Terminal do Ferry Building E de São Francisco
Centro de Trânsito do CentroCentro de Trânsito do Centro da Cidade Bay B

routes.txt

Nome do campo Recomendação
route_short_name Incluir route_short_name se houver uma breve designação de serviço. Este deve ser o nome do passageiro comumente conhecido do serviço, não mais que 12 caracteres.
route_long_name A definição a partir da referência de Especificação: Este nome é geralmente mais descritivo do que o nome_do_caminho_curto e muitas vezes incluirá o destino da rota ou a parada. Pelo menos um dos nome_do_caminho_curto ou nome_da_via_long_nome_da_via deve ser especificado, ou potencialmente ambos, se apropriado. Se o itinerário não tiver um nome longo, por favor especifique um nome_do_caminho_curto e usar um fio vazio como valor para este campo.
Exemplos de tipos de nomes longos estão abaixo:
Caminho ou corredor primário de viagem
Nome da rotaFormulárioAgência
"N"/"Judah"nome_do_caminho_curto/
nome_da_via_long_nome_da_via
Muni, em São Francisco
"6"/"ML King Jr Blvd"nome_do_caminho_curto/
nome_da_via_long_nome_da_via
TriMetem Portland, ou.
PHP?nompdf=m6">"6"/"Nação - Étoile"nome_do_caminho_curto/
nome_da_via_long_nome_da_via
RATP, em Paris, França.
"U2"-"Pankow - Ruhleben".nome_do_caminho_curto-
nome_da_via_long_nome_da_via
BVG, em Berlim, Alemanha
Descrição do serviço
"Hartwell Area Shuttle"
route_long_name não deve conter o route_short_name.
Incluir a designação completa, incluindo uma identidade de serviço ao povoar route_long_name. Exemplos:
Identidade de serviçoRecomendaçãoExemplos:
"Trilho leve MAX".
TriMet, em Portland, Oregon
O nome_da_via_long_nome_da_via deve incluir a marca (MAX) e a designação específica da rota"MAX Linha Vermelha" "MAX Linha Azul"
"Passeio Rápido"
ABQ Ride, em Albuquerque, Novo México
O nome_da_via_long_nome_da_via deve incluir a marca (Rapid Ride) e a designação específica da rota"Rapid Ride Red Line"
"Rapid Ride Blue Line"
route_id Todas as viagens em um determinado itinerário devem fazer referência ao mesmo route_id.
  • As diferentes direções de uma rota não devem ser separadas em diferentes route_id valores.
  • Vãos diferentes de operação de uma rota não devem ser separados em valores diferentes route_id ou seja, não criar registros diferentes em routes.txt para os serviços "Downtown AM" e "Downtown PM").
  • Se um grupo de rotas incluir filiais com nomes distintos (por exemplo, 1A e 1B), siga as recomendações na rota filiais caso para determinar route_short_name e route_long_name.
    route_color & route_text_color Deve ser consistente com a sinalização e informações impressas e on-line do cliente (e, portanto, não incluídas se não existirem em outros lugares).

    trips.txt

    • Veja o caso especial para rotas de loop: As rotas de loop são casos em que as viagens começam e terminam na mesma parada, ao contrário das rotas lineares, que têm dois terminais distintos. As rotas de laço devem ser descritas seguindo práticas específicas. Veja o caso das rotas de loop.
    • Veja o caso especial para rotas de laço: As rotas de laço são um híbrido de geometrias lineares e de laço, no qual os veículos viajam em laço apenas para uma parte da rota. As rotas da laço devem ser descritas de acordo com práticas específicas. Veja o estojo de rotas Lasso.
    Nome do campo Recomendação
    trip_headsign Não forneça nomes de rotas (correspondência route_short_name e route_long_name) no trip_headsign ou stop_headsign campos.
    Deve conter texto de destino, direção e/ou outra designação de viagem mostrada no cartaz do veículo que pode ser usado para distinguir entre viagens em uma rota. A coerência com as informações de direção mostradas no veículo é a principal e principal meta para determinar os sinais de direção fornecidos nos conjuntos de dados GTFS. Outras informações devem ser incluídas somente se não comprometerem esta meta principal. Se os sinais de direção mudarem durante uma viagem, substitua trip_headsign com stop_times.stop_headsign. Abaixo estão as recomendações para alguns casos possíveis:
    Descrição da rotaRecomendação
    2A. Somente destinoForneça o destino final, por exemplo, "Transit Center", "Portland City Center", ou "Jantzen Beach" >
    2B. Destinos com pontos de passagem via " Highgate via Charing Cross". Se o(s) ponto(s) de passagem for(em) removido(s) da placa de sinalização aos passageiros depois que o veículo passar por esses pontos de passagem, use stop_times.stop_headsign para definir um headign atualizado.>
    2C. Nome do placename regional com paradas locaisSe houver múltiplas paradas dentro da cidade ou do município de destino, use stop_times.stop_headsign uma vez chegando à cidade de destino.>
    2D. Somente direçãoIndique usando termos tais como "Norte", "Entrada", "Horário", ou instruções similares.>
    2E. Direção com destino para, por exemplo, "Southbound to San Jose">
    2F. Direção com destino e pontos de passagem via para ( "Northbound via Charing Cross to Highgate").>
    Não comece um sinal de cabeça com as palavras "Para" ou "Para".
    direction_id Use os valores 0 e 1 de forma consistente em todo o conjunto de dados, ou seja, "Para" ou "Para".
    • Se 1 = Saída na rota Vermelha, então 1 = Saída na rota Verde
    • Se 1 = Norte na Rota X, então 1 = Norte na Rota Y
    • Se 1 = sentido horário na Rota X então 1 = sentido horário na Rota Y

    stop_times.txt

    Rotas de loop: Rotas de laço exigem considerações especiais de tempo de parada. (Veja: Estojo de rotas de laço)

    Nome do campo Recomendação
    pickup_type & drop_off_type Viagens sem receita (deadhead), que não prestam serviço de passageiros, devem ser marcadas com pickup_type e drop_off_type valor de 1 para todos stop_times filas.
    Nas viagens de renda, os "pontos de tempo" internos para monitorar o desempenho operacional e outros lugares, tais como garagens que um passageiro não pode embarcar, devem ser marcados com pickup_type = 1 (não há pickup disponível) e drop_off_type = 1 (não há entrega disponível).
    arrival_time & departure_time arrival_time e departure_time Os campos devem especificar valores de tempo sempre que possível, incluindo tempos estimados ou interpolados não vinculativos entre timepoints.
    stop_headsign Em geral, os valores do sinal de cabeça também devem corresponder a sinais nas estações.

    Nos casos abaixo, "Southbound" enganaria os clientes porque não é usado nos sinais das estações.
    Em NYC, para os 2 que vão em direção ao Sul:
    Para stop_times.txt filas:Use stop_headsign valor:
    Até Manhattan ser alcançadaManhattan & Brooklyn
    Até o centro da cidade ser alcançadoCentro da cidade e Brooklyn
    Até o Brooklyn ser alcançadoBrooklyn
    Quando o Brooklyn for alcançadoBrooklyn (Av. New Lots)
    Em Boston, para a Linha Vermelha que vai para o Sul, para a filial Braintree:
    Para stop_times.txt filas:Use stop_headsign valor:
    Até o centro da cidade ser alcançadoEntrada para Braintree
    Quando o centro da cidade for alcançadoBraintree
    Depois do centro da cidadeSaída para Braintree
    shape_dist_traveled shape_dist_traveled devem ser fornecidas para rotas que tenham laço ou inlining (o veículo atravessa ou viaja sobre a mesma porção de alinhamento em uma viagem). Veja o shapes.shape_dist_traveled recomendação.

    calendar.txt

    Nome do campo Recomendação
    Todos os campos Incluindo um calendar.service_name também pode aumentar a capacidade de leitura humana do GTFS, embora isto não seja adotado nas especificações.

    calendar_dates.txt

    Nome do campo Recomendação
    Todos os campos Incluindo um calendar.service_name também pode aumentar a legibilidade humana do GTFS, embora isto não seja adotado nas especificações.

    fare_attributes.txt

    Nome do campo Recomendação
    Todos os campos agency_id deve ser incluído em fare_attributes.txt se o campo estiver incluído em agency.txt.
    Se um sistema tarifário não puder ser modelado com precisão, evite mais confusão e deixe-o em branco.
    Inclua as tarifas (fare_attributes.txt e fare_rules.txt) e modelá-las com a maior precisão possível. Nos casos em que as tarifas não podem ser modeladas com precisão, a tarifa deve ser representada como mais cara em vez de menos cara, para que os clientes não tentem embarcar com tarifa insuficiente. Se a grande maioria das tarifas não puder ser modelada corretamente, não inclua informações sobre a tarifa na ração.

    fare_rules.txt

    Nome do campo Recomendação
    Todos os campos Se um sistema tarifário não puder ser modelado com precisão, evite mais confusões e deixe-o em branco.
    Incluir as tarifas (fare_attributes.txt e fare_rules.txt) e modelá-las da forma mais precisa possível. Em casos extremos onde as tarifas não podem ser modeladas com precisão, a tarifa deve ser representada como mais cara em vez de menos cara, para que os clientes não tentem embarcar com tarifa insuficiente. Se a grande maioria das tarifas não puder ser modelada corretamente, não inclua informações sobre a tarifa na ração.

    shapes.txt

    Nome do campo Recomendação
    Todos os campos Idealmente, para alinhamentos que são compartilhados (isto é, em um caso em que as Rotas 1 e 2 operam no mesmo segmento de estrada ou pista), então a parte compartilhada do alinhamento deve coincidir exatamente. Isto ajuda a facilitar uma cartografia de trânsito de alta qualidade.
    Os alinhamentos devem seguir a linha central do direito de passagem em que o veículo viaja. Esta pode ser ou a linha central da rua se não houver faixas designadas, ou a linha central da lateral da pista que viaja na direção em que o veículo se move.

    Os alinhamentos não devem "jag" para uma parada de calçada, plataforma, ou local de embarque.
    shape_dist_traveled Deve ser providenciado em ambos shapes.txt e stop_times.txt se um alinhamento inclui looping ou inlining (o veículo cruza ou percorre a mesma porção de alinhamento em uma viagem).
    Se um veículo se retrai ou atravessa o alinhamento da rota em pontos no decorrer de uma viagem, shape_dist_travelled é importante para esclarecer como partes dos pontos em shapes.txt correspondem com os registros em stop_times.txt.
    O shape_dist_traveled permite que a agência especifique exatamente como as paradas no campo stop_times.txt se encaixam em sua respectiva forma. Um valor comum a ser usado para o shape_dist_traveled campo é a distância desde o início da forma como viajado pelo veículo (pense em algo como uma leitura de odômetro).
  • Alinhamentos de rota (em shapes.txt) deve estar a menos de 100 metros dos locais de parada que uma viagem serve.
  • Simplificar os alinhamentos de modo que shapes.txt não contém pontos estranhos (ou seja, remover pontos extras em segmentos de linha reta; ver discussão do problema de simplificação de linhas).
  • frequencies.txt

    Nome do campo Recomendação
    Todos os campos Os tempos de parada reais são ignorados para viagens referenciadas por frequencies.txt; apenas intervalos de tempo de viagem entre paradas são significativos para viagens baseadas em freqüência. Para maior clareza/leitura humana, recomenda-se que o primeiro tempo de parada de uma viagem referenciada em frequencies.txt deve começar às 00:00:00 (primeiro arrival_time valor de 00:00:00).
    block_id Pode ser fornecido para viagens baseadas em freqüência.

    transfers.txt

    transfers.transfer_type pode ser um dos quatro valores definidos no GTFS. Estas definições de transfer_type são citadas da Especificação GTFS abaixo, em itálico, com recomendações práticas adicionais.

    Nome do campo Recomendação
    transfer_type 0 ou (vazio): Este é um ponto de transferência recomendado entre as rotas.
    Se houver múltiplas oportunidades de transferência que incluam uma opção superior (ou seja, um centro de trânsito com comodidades adicionais ou uma estação com instalações/plataformas de embarque adjacentes ou conectadas), especifique um ponto de transferência recomendado.
    1: Este é um ponto de transferência cronometrado entre dois itinerários. Espera-se que o veículo de partida aguarde a chegada, com tempo suficiente para que um passageiro se transfira entre as rotas.
    Este tipo de transferência substitui um intervalo necessário para fazer transferências de forma confiável. Como exemplo, o Google Maps assume que os passageiros precisam de 3 minutos para fazer uma transferência com segurança. Outras aplicações podem assumir outros padrões.
    2: Esta transferência requer um tempo mínimo entre a chegada e a partida para garantir uma conexão. O tempo necessário para a transferência é especificado por min_transfer_time.
    Especifique o tempo mínimo de transferência se houver obstruções ou outros fatores que aumentem o tempo de viagem entre as paradas.
    3: As transferências não são possíveis entre as rotas neste local.
    Especifique este valor se as transferências não forem possíveis devido a barreiras físicas, ou se elas forem tornadas inseguras ou complicadas por travessias difíceis de estradas ou falhas na rede de pedestres.
    Se forem permitidos traslados em assentos (blocos) entre viagens, então a última parada da viagem de chegada deve ser a mesma que a primeira parada da viagem de partida.

    feed_info.txt

    feed_info.txt deve ser incluído, com todos os campos abaixo.

    Nome do campo Recomendação
    feed_start_date & feed_end_date Deve ser incluído
    feed_version Deve ser incluído
    feed_contact_email & feed_contact_url Forneça pelo menos um

    Recomendações Práticas Organizadas por Caso

    Esta seção cobre casos particulares com implicações entre arquivos e campos.

    Rotas de Loop

    Nas rotas de loop, as viagens dos veículos começam e terminam no mesmo local (às vezes um centro de trânsito ou transferência). Os veículos geralmente operam continuamente e permitem que os passageiros permaneçam a bordo enquanto o veículo continua seu loop.

    Portanto, as recomendações de sinalização devem ser aplicadas a fim de mostrar aos motociclistas a direção em que o veículo está indo.

    Para indicar a mudança de direção da viagem, forneça sinais de stop_headsigns no arquivo stop_times.txt O sinal de stop_headsign descreve a direção para viagens que partem da parada para a qual está definido. Adicionar os sinais de_cabeça_de_parada a cada parada de uma viagem permite mudar as informações do sinal de_cabeça ao longo de uma viagem.

    Não defina uma única viagem circular no arquivo stop_times.txt para uma rota que opera entre dois pontos finais (como quando o mesmo ônibus vai e volta). Ao invés disso, divida a viagem em duas direções de viagem separadas.

    Exemplos de modelagem de viagem circular:

    • Viagem circular com mudança de sinal de cabeça para cada parada
    trip_id hora_de_chegada hora_de_partida stop_id stop_sequence stop_headsign
    viagem_1 06:10:00 06:10:00 stop_A 1 "B"
    viagem_1 06:15:00 06:15:00 stop_B 2 "C"
    viagem_1 06:20:00 06:20:00 stop_C 3 "D"
    viagem_1 06:25:00 06:25:00 stop_D 4 "E"
    viagem_1 06:30:00 06:30:00 stop_E 5 "A"
    viagem_1 06:35:00 06:35:00 stop_A 6 ""
    • Viagem circular com dois sinais de cabeça
    trip_id hora_de_chegada hora_de_partida stop_id stop_sequence stop_headsign
    viagem_1 06:10:00 06:10:00 stop_A 1 "de saída".
    viagem_1 06:15:00 06:15:00 stop_B 2 "de saída".
    viagem_1 06:20:00 06:20:00 stop_C 3 "de saída".
    viagem_1 06:25:00 06:25:00 stop_D 4 "entrante"
    viagem_1 06:30:00 06:30:00 stop_E 5 "entrante"
    viagem_1 06:35:00 06:35:00 stop_F 6 "entrante"
    viagem_1 06:40:00 06:40:00 stop_A 7 ""
    Nome do campo Recomendação
    trips.trip_id Modelar a viagem completa de ida e volta para o laço com uma única viagem.
    stop_times.stop_id Incluir a primeira/última parada duas vezes em stop_times.txt para a viagem que é um loop. Exemplo abaixo. Muitas vezes, uma rota de loop pode incluir a primeira e a última viagens que não percorrem o loop inteiro. Inclua também essas viagens.
    trip_idstop_idstop_sequence
    90001011
    90001022
    90001033
    90001014
    trips.direction_id Se o laço opera em sentidos opostos (ou seja, no sentido horário e anti-horário), então designe direction_id como 0 ou 1.
    trips.block_id Indicar viagens de loop contínuo com o mesmo block_id.

    Rotas Lasso

    As rotas da Lasso combinam aspectos de uma rota de laço e rota direcional.

    Exemplos:
    Rotas de metrô (Chicago)
    Subúrbio de ônibus para o centro da cidade (São Alberto ou Edmonton)
    CTA Brown Line (Site do CTA e TransitFeeds)
    Nome do campo Recomendação
    trips.trip_id A extensão total de um "veículo de ida e volta" (ver ilustração acima) consiste em viagens de A para B e de volta para A. Um veículo inteiro de ida e volta pode ser expresso por:
  • A único trip_id valor/registo em trips.txt
  • Múltiplos trip_id valores/registros em trips.txtcom viagens contínuas indicadas por block_id.
  • stop_times.stop_headsign As paradas ao longo da seção A-B serão passadas em ambas as direções. stop_headsign facilita a distinção da direção de viagem. Portanto, desde que stop_headsign é recomendado para estas viagens.exemplo_tabela:
    Exemplos:
    "A via B"
    "A"
    Autoridade de Trânsito de Chicago Linha roxa
    "Sul para o Loop"
    "Norte via Loop"
    "Norte para Linden"
    Edmonton Transit Service Bus Lines, aqui os 39
    "Rutherford".
    "Parque do Século".
    trip.trip_headsign O indicativo de viagem deve ser uma descrição global da viagem, como exibido nos horários. Pode ser "Linden to Linden via Loop" (exemplo de Chicago), ou "A to A via B" (exemplo genérico).

    Filiais

    Algumas rotas podem incluir filiais. Alinhamento e paradas são compartilhados entre esses ramos, mas cada um também serve a diferentes paradas e seções de alinhamento. A relação entre as ramificações pode ser indicada pelo nome do(s) itinerário(s), sinais de cabeçalho e nome curto da viagem, usando as diretrizes adicionais abaixo.

    Nome do campo Recomendação
    Todos os campos Ao nomear as rotas dos ramais, é recomendado seguir outros materiais de informação aos passageiros. Abaixo estão as descrições e exemplos de dois casos:
    Se os horários e a sinalização nas ruas representam duas rotas com nomes distintos (por exemplo, 1A e 1B), então apresente isto como tal no GTFS, usando o route_short_name e/ou route_long_name campos. Exemplo: GoDurham Transit rotas 2, 2A, e 2B compartilham um alinhamento comum ao longo da maioria do percurso, mas variam em vários aspectos diferentes.
    • A rota 2 é o serviço principal, funcionando na maioria das horas.
    • A rota 2 inclui um desvio nas noites da Main Street, domingos e feriados.
    • As rotas 2A e 2B operam no horário diurno de segunda a sábado.
    • A rota 2B serve paradas adicionais em um desvio do trajeto de alinhamento compartilhado.
    Se as informações fornecidas pela agência descreverem as filiais como a mesma rota nomeada, então utilize o trips.trip_headsign, stop_times.stop_headsigne/ou trips.trip_short_name campos. Exemplo: GoTriangle rota 300 viaja para diferentes locais, dependendo da hora do dia. Durante as horas de pico, são acrescentadas pernas extras na rota padrão para acomodar os trabalhadores que entram e saem da cidade.

    Perguntas mais freqüentes (FAQ)

    Por que estas Melhores Práticas GTFS são importantes?

    Os objetivos das Melhores Práticas do GTFS são:

    • Melhorar a experiência do usuário final em aplicativos de transporte público
    • Apoiar a ampla interoperabilidade de dados para facilitar a implantação e a escala de aplicações, produtos e serviços por parte dos desenvolvedores de software
    • Facilitar o uso do GTFS em várias categorias de aplicação (além de seu foco original no planejamento da viagem)

    Sem as melhores práticas GTFS coordenadas, várias aplicações GTFS podem estabelecer requisitos e expectativas de forma descoordenada, o que leva a requisitos divergentes e conjuntos de dados específicos da aplicação e menos interoperabilidade. Antes do lançamento das Melhores Práticas, havia maior ambigüidade e discordância no que constitui os dados GTFS corretamente formados.

    Como eles foram desenvolvidos? Quem as desenvolveu?

    Estas Melhores Práticas foram desenvolvidas por um grupo de trabalho de 17 organizações envolvidas no GTFS, incluindo fornecedores de aplicativos e consumidores de dados, fornecedores de trânsito e consultores com amplo envolvimento no GTFS. O grupo de trabalho foi convocado e facilitado pelo Rocky Mountain Institute.

    Os membros do Grupo de Trabalho votaram em cada uma das Melhores Práticas. A maioria das Melhores Práticas foi aprovada por unanimidade. Em uma minoria de casos, as Melhores Práticas foram aprovadas por uma grande maioria de organizações.

    Por que não simplesmente mudar a referência do GTFS?

    Boa pergunta! O processo de examinar a Especificação, o uso de dados e as necessidades realmente desencadeou algumas mudanças na Especificação (ver pedidos fechados de puxar em GitHub). As emendas de referência à especificação estão sujeitas a uma barra de exame e comentário mais alta do que as Melhores Práticas. Entretanto, ainda havia necessidade de se chegar a um acordo sobre um conjunto claro de recomendações de Melhores Práticas.

    O grupo de trabalho prevê que algumas das Melhores Práticas do GTFS acabarão fazendo parte da referência principal do GTFS.

    As ferramentas de validação do GTFS verificam a conformidade com estas Melhores Práticas?

    Nenhuma ferramenta de validação atualmente verifica a conformidade com todas as Melhores Práticas. Várias ferramentas de validação verificam a conformidade com algumas dessas melhores práticas. Para uma lista de ferramentas de validador GTFS, veja GTFS-validators">GTFS Validators. Se você escrever uma ferramenta de validador GTFS que faça referência a estas Melhores Práticas, envie um e-mail para specifications@mobilitydata.org.

    Eu represento uma agência de trânsito. Que medidas posso tomar para que nossos fornecedores e fornecedores de serviços de software sigam estas Melhores Práticas?

    Indique seu fornecedor ou prestador de serviços de software a estas Melhores Práticas. Recomendamos a referência ao URL de Melhores Práticas GTFS, bem como ao núcleo de Referência Específica na aquisição de software GTFS.

    O que devo fazer se notar que um feed de dados GTFS não está de acordo com estas Melhores Práticas?

    Identifique o contato para o feed, usando os campos feed_contact_email propostos ou feed_contact_url no feed_info.txt se eles existirem, ou procurando informações de contato na agência de trânsito ou no site do produtor de feed. Ao comunicar o problema ao produtor de ração, faça um link para as Melhores Práticas específicas GTFS em discussão. (Ver "Vinculação a este documento").

    Eu gostaria de propor uma modificação/aditamento às Melhores Práticas. Como posso fazer isto?

    Envie um e-mail para specifications@mobilitydata.org ou abra um pedido de consulta no GTFS-best-practices">reporte das Melhores Práticas GTFS do GitHub.

    Como faço para me envolver?

    Envie um e-mail para specifications@mobilitydata.org.

    Sobre este documento

    Objetivos

    O objetivo de manter as Melhores Práticas GTFS é o de:

    • Apoiar uma maior interoperabilidade dos dados de trânsito
    • Melhorar a experiência do usuário final em aplicativos de transporte público
    • Facilitar aos desenvolvedores de software a implantação e a escala de aplicações, produtos e serviços
    • Facilitar o uso do GTFS em várias categorias de aplicação (além de seu foco original no planejamento da viagem)

    Como propor ou alterar as Melhores Práticas publicadas no GTFS

    As aplicações e práticasGTFS evoluem e, portanto, este documento pode precisar ser emendado de tempos em tempos. Para propor uma emenda a este documento, abra uma solicitação pull no GTFS Best Practices GitHub repository GitHub e defenda a mudança. Você pode enviar qualquer comentário por e-mail para specifications@mobilitydata.org.

    Ligação com este documento

    Por favor, faça um link aqui para fornecer aos produtores de ração orientações para a formação correta dos dados GTFS. Cada recomendação individual tem um link de ancoragem. Clique na recomendação para obter a URL para o link da âncora na página.

    Se uma aplicação GTFS faz exigências ou recomendações para práticas de dados GTFS que não estão descritas aqui, recomenda-se publicar um documento com essas exigências ou recomendações para complementar essas melhores práticas comuns.

    Grupo de Trabalho de Melhores Práticas doGTFS

    O Grupo de Trabalho de Melhores Práticas do GTFS foi convocado pelo Instituto Rocky Mountain em 2016-17, composto por fornecedores de transporte público, desenvolvedores de aplicações GTFS, consultores e organizações acadêmicas para definir práticas e expectativas comuns para os dados do GTFS:

    Hoje, este documento é mantido pela MobilityData.