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: Estas práticas estão relacionadas à estrutura geral do conjunto de dados GTFS e à maneira pela qual os conjuntos de dados GTFS são publicados.
Recomendações Práticas Organizadas por Arquivo: As recomendações são organizadas por arquivo e campo no GTFS para facilitar as práticas de mapeamento de volta à referência oficial do GTFS.
Recomendações Práticas Organizadas por Caso: Com casos particulares, como rotas de loop, as práticas podem precisar ser aplicadas em vários arquivos e campos. Tais recomendações são consolidadas nesta seção.

Dataset Publishing & General Practices¶

Os conjuntos de dados devem ser publicados em um URL público e permanente, incluindo o nome do arquivo zip. (por exemplo, www.agency.org/gtfs/gtfs.zip). Idealmente, o URL deve poder ser baixado diretamente, sem a necessidade de login para acessar o arquivo, para facilitar o download pelo consumo de aplicativos de software. Embora seja recomendado (e a prática mais comum) tornar um conjunto de dados GTFS disponível para download abertamente, se um provedor de dados precisar controlar o acesso à GTFS por licenciamento ou outros motivos, é recomendado controlar o acesso ao conjunto de dados GTFS usando chaves de API, o que facilitará 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 no serviço entrar em vigor em sete dias ou menos, expresse essa alteração no serviço por meio de um feed GTFS-realtime (avisos de serviço ou atualizações de viagem ) em vez do 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 pais	Nome da parada da criança
Estação União de Chicago	Plataforma da Estação Union Station de Chicago 19
Terminal de São Francisco Ferry Building	Terminal do Terminal do Ferry Building E de São Francisco
Centro de Trânsito do Centro	Centro de Trânsito do Centro da Cidade Bay B

routes.txt¶

Nome do campo Recomendação

agency_id Deve ser incluído, mesmo que haja apenas uma agência na ração. (Veja também recomendação de incluir agency_id no agency.txt e no fare_attributes.txt)

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 rota	Formulário	Agê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`	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 Berlin, 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ço	Recomendação	Exemplos:
"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 rota	Recomendação
2A. Somente destino	Forneç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 locais	Se 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ção	Indique 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).

timepoint O campo de timepoint deve ser fornecido. Ele especifica a que stop_times o operador tentará aderir estritamente (timepoint=1), e que outros tempos de parada são estimativas (timepoint=0).

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çada	`Manhattan & Brooklyn`
Até o centro da cidade ser alcançado	`Centro da cidade e Brooklyn`
Até o Brooklyn ser alcançado	`Brooklyn`
Quando o Brooklyn for alcançado	`Brooklyn (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çado	`Entrada para Braintree`
Quando o centro da cidade for alcançado	`Braintree`
Depois do centro da cidade	`Saí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
`agency_id`	Deve ser incluído, mesmo que haja apenas uma agência na ração. (Veja também recomendação de incluir `agency_id` no `agency.txt` e no `routes.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_id`	`stop_id`	`stop_sequence`
9000	101	1
9000	102	2
9000	103	3
9000	101	4

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_headsign`e/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 validadora verifica atualmente a conformidade com todas as Melhores Práticas. Várias ferramentas validadoras verificam a conformidade com algumas dessas práticas recomendadas. Para obter uma lista de ferramentas de validação GTFS, consulte Validadores GTFS. Se você criar uma ferramenta validadora GTFS que faça referência a essas práticas recomendadas, 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 problema ou pull request no repositório de práticas recomendadas 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.