Processo de alteração das especificações

A Especificação GTFS não é definida em pedra. Ao invés disso, é uma especificação aberta desenvolvida e mantida pela comunidade de agências de trânsito, desenvolvedores e outras partes interessadas que utilizam GTFS. Espera-se que esta comunidade de produtores e consumidores de dados GTFS tenha propostas para ampliar as especificações a fim de permitir novas capacidades. Para ajudar a gerenciar esse processo, foram estabelecidos os seguintes procedimentos e diretrizes.

A especificação oficial, referência e documentação são escritas em inglês. Se uma Translation para um idioma diferente do original em inglês, esta última tem precedência. Toda a comunicação é feita em inglês.

1. Criar uma filial de git com atualização de todas as partes relevantes da definição do protocolo, especificação e arquivos de documentação (exceto para traduções).
2. Criar solicitação de puxar em https://github.com/google/transit. A solicitação de puxar deve conter uma descrição estendida do remendo. O criador do pedido de puxar torna-se o defensor.
3. Uma vez registrada a solicitação pull, ela deve ser anunciada por seu defensor na lista de discussão GTFS Changes, incluindo um link para a solicitação pull. Uma vez anunciada, a solicitação pull é considerada uma proposta. A solicitação pull também deve ser editada para conter um link para o anúncio do Google Groups para que possam ser facilmente referenciados.
4. Como o defensor é um contribuinte, eles devem assinar o Acordo de Licença de Contribuinte antes que a solicitação pull possa ser aceita.
5. A discussão da proposta é a seguinte. Os comentários de solicitação devem ser usados como o único fórum de discussão.
6. A discussão dura o tempo que o defensor julgar necessário, mas deve ser de pelo menos 7 dias corridos.
7. O defensor é responsável pela atualização oportuna da proposta (ou seja, solicitação de retirada) com base nos comentários com os quais concorda.
8. A qualquer time, o defensor pode alegar o abandono da proposta.
9. O defensor pode solicitar a votação de uma versão da proposta em qualquer time após o intervalo inicial de 7 dias necessário para a discussão.
10. Antes de solicitar uma votação, pelo menos um produtor e um consumidor GTFS GTFS devem implementar a mudança proposta. Espera-se que o(s) produtor(es) de GTFS inclua(m) a mudança em uma alimentação GTFS voltada para o público e forneça(m) um link para esses dados nos comentários de solicitação pull, e que o(s) consumidor(es) GTFS forneça(m) um link nos comentários de solicitação pull para uma aplicação que esteja utilizando a mudança de forma não trivial (ou seja, que esteja apoiando funcionalidades novas ou melhoradas).
11. A votação dura o período mínimo suficiente para cobrir 7 dias de calendário e 5 dias úteis Suíços FULL. A votação termina às 23:59:59 UTC.
12. O defensor deve anunciar o time específico time end no start da votação.
13. Durante o período de votação somente são permitidas mudanças editoriais na proposta (erros de digitação, a redação pode mudar desde que não altere o significado).
14. Qualquer pessoa pode votar sim/não em uma forma de comentário ao pedido de puxar, e os votos podem ser mudados até o end do período de votação. Se um eleitor muda seu voto, é recomendável fazê-lo atualizando o comentário de voto original, marcando o voto e escrevendo o novo voto.
15. Votos antes do start do período de votação não são considerados.
16. A abertura e o encerramento das votações devem ser anunciados na lista de correspondência.
17. A proposta é aceita se houver um consenso unânime sim com pelo menos 3 votos.
18. O voto do proponente não conta para o total de 3 votos. Por exemplo, se o Proponente X criar uma solicitação de puxar e votar sim, e os Usuários Y e Z votarem sim, isso será contado como 2 votos totais de sim.
19. Os votos contra devem ser motivados e, idealmente, fornecer um feedback acionável.
20. Se a votação falhar, então o defensor pode optar por continuar o trabalho na proposta, ou abandonar a proposta. Qualquer decisão do defensor deve ser anunciada na lista de discussão.
21. Se o defensor continuar o trabalho sobre a proposta, então uma nova votação pode ser convocada a qualquer time.
22. Qualquer solicitação pull que permaneça inativa por 30 dias corridos será encerrada. Quando uma solicitação pull é fechada, a proposta correspondente é considerada abandonada. O defensor pode reabrir o pedido de puxar a qualquer time se desejar continuar ou manter a conversa.
23. Se a proposta for aceita:
24. O Google se compromete a fundir a versão votada da solicitação pull (desde que os colaboradores tenham assinado o ALC), e realizar a solicitação pull dentro de 5 dias úteis.
25. As traduções não devem ser incluídas na solicitação original de pull. O Google é responsável por eventualmente atualizar as traduções relevantes para os idiomas suportados, mas os pedidos de Translation pura da comunidade são bem-vindos e serão aceitos assim que todos os comentários editoriais forem endereçados.
26. O resultado final da solicitação de retirada (aceita ou abandonada) deve ser anunciado no mesmo tópico do Google Groups onde a solicitação de retirada foi originalmente anunciada.

---

Princípios Orientadores

A fim de preservar a visão original do GTFS, alguns princípios orientadores foram estabelecidos para levar em consideração ao ampliar as especificações:

Feeds devem ser fáceis de criar e editar
Escolhemos o CSV como base para a especificação porque é fácil de visualizar e editar usando programas de planilhas e editores de text, o que é útil para agências menores. Também é simples de gerar a partir da maioria das linguagens de programação e bancos de dados, o que é bom para editores de feeds maiores.

Os feeds devem ser fáceis de analisar
os leitores devem ser capazes de extrair as informações que estão procurando com o mínimo de trabalho possível. As mudanças e adições ao feed devem ser o mais amplamente útil possível, para minimizar o número de caminhos de código que os leitores do feed precisam implementar. (Entretanto, deve ser dada precedência à criação, uma vez que no final haverá mais editores de rações do que leitores de rações).

A especificação é sobre informação aos passageiros
GTFS sepreocupa principalmente com a informação aos passageiros. Ou seja, as especificações devem incluir informações que possam ajudar a impulsionar ferramentas para os cavaleiros, em primeiro lugar e acima de tudo. Há potencialmente uma grande quantidade de informações orientadas a operações que as agências de trânsito podem querer transmitir internamente entre sistemas. GTFS não se destina a essa finalidade e há outras normas de dados potencialmente mais apropriadas para as operações.

As mudanças nas especificações devem ser compatíveis com o passado
Ao acrescentar características à especificação queremos evitar fazer alterações que tornem inválidas as alimentações existentes. Não queremos criar mais trabalho para os editores de feeds existentes até que eles queiram adicionar capacidades a seus feeds. Além disso, sempre que possível, queremos que os analisadores existentes possam continuar a ler as partes mais antigas dos feeds mais recentes.

As características especulativas são desencorajadas
Tudo o novo recurso adiciona complexidade à criação e leitura dos feeds. Portanto, queremos ter o cuidado de acrescentar apenas recursos que sabemos serem úteis. Idealmente, qualquer proposta terá sido testada através da geração de dados para um sistema de trânsito real que usa o novo recurso e software de escrita para lê-lo e exibi-lo. Note que o GTFS permite prontamente extensões para o formato através da adição de colunas e arquivos extras que são ignorados pelos analisadores e validadores oficiais, de modo que as propostas podem ser facilmente prototipadas e testadas em feeds existentes.

---

Histórico de revisão

14 de março de 2023

• Acrescentou a mídia tarifária. Ver discussão.

26 de julho de 2022

• Transferências de ida e volta adicionais com opção no assento. Veja a discussão

17 de maio de 2022

• Implementação da base GTFS-Fares V2. Veja a discussão

22 de outubro de 2021

• Adicionados os campos de id primária e estrangeira. Veja a discussão

5 de outubro de 2021

• Acrescentadas as transferências Trip-to-Trip e Route-to-route. Veja a discussão

15 de setembro de 2021

• Os portões tarifários permitidos (pathway_mode=6) serão bidirecionais. Veja a discussão.

13 de setembro de 2021

• Melhores práticas de stop_name atualizadas. Veja a discussão.

27 de agosto de 2021

• GTFS Schedule atualizada GTFS Schedule para RFC 2119. Veja a discussão.

4 de janeiro de 2021

• Descrição esclarecida de stop_times.stop_id. Veja a discussão.
• Sinais de campo definidos positivos e não-zero. Veja a discussão.

2 de outubro de 2020

• Mudou o tipo de campo de freqüências.headway_secs de não-negativo para inteiro positivo. Ver discussão.

25 de maio de 2020

• Definidos pathways.txt, levels.txt e attributions.txt como tabelas traduzíveis. Acrescentadas recomendações para a tradução de signposted_as multilíngues. Ver discussão.

13 de maio de 2020

• Acrescentadas continuous_pickup e continuous_drop_off às routes.txt e stop_times.txt. Mudado o shape_id de "Optional" para "Conditionally required". Veja a discussão.

24 de março de 2020

• Definido campo text e adicionado tts_stop_name para stops.txt. Veja a discussão.

5 de fevereiro de 2020

• Adicionados os route_types de tróleis e monotrilho. Veja a discussão.

9 de janeiro de 2020

• Acrescentado translations.txt. Ver discussão.

26 de dezembro de 2019

• Definições atualizadas para o bonde-cabo e o elevador aéreo no route_type. Ver discussão.

20 de dezembro de 2019

• attributions.txt adicionadas. Veja a discussão.

26 de agosto de 2019

• Especificou que o stop_lat e o stop_lon sejam posicionados onde os passageiros esperam para embarcar no vehicle. Ver discussão.

9 de julho de 2019

• Adicionadas as melhores práticas de chegada e partida. Ver discussão.
• Acrescentadas as melhores práticas de sinalização. Ver discussão.
• Adicionadas as melhores práticas de stop_id. Ver discussão.

25 de junho de 2019

• Relação esclarecida de pontos de Shape e stops. Ver discussão.

4 de abril de 2019

• Adicionado o campo platform_code em stops.txt Ver discussão.

27 de março de 2019

• Adicionados pathways.txt e levels.txt. Ver discussão.

6 de fevereiro de 2019

• Mudanças editoriais e de formatação para maior clareza. Ver discussão.

2 de outubro de 2018

• Tipos de campos factorizados. Ver discussão.

14 de setembro de 2018

• Adicionado o conceito "Conditionally required". Ver discussão.

4 de setembro de 2018

• Unificou as definições de agency_lang e feed_lang. Ver discussão.

27 de agosto de 2018

• Atualização de CHANGES.md e última data revisada. Ver discussão.

22 de agosto de 2018

• Adicionados campos feed_contact_email e feed_contact_url no arquivo feed_info.txt. Veja a discussão.

11 de dezembro de 2017

• Adicionado route_sort_order ao arquivo routes.txt. Veja a discussão.

15 de março de 2017

• Esclarecido que o voto de um proponente não conta para o total. Ver discussão.
• Especificou que, antes de chamar uma votação, pelo menos um produtor e um consumidor GTFS devem implementar a mudança proposta. Ver discussão.

7 de fevereiro de 2017

• Esclareceu a relação de block_id e service_id. Ver discussão.
• Esclareceu que o serviço baseado na freqüência começa na departure vehicle. Veja a discussão.
• Descrição esclarecida do stop_id e do stop_code. Veja a discussão.

11 de dezembro de 2017

• Adicionado o campo route_sort_order no arquivo routes.txt Veja a discussão.

27 de novembro de 2016

• Acrescentado entrada da estação como um stop.location_type. Veja a discussão.

2 de setembro de 2016

• Documentação atualizada para adicionar agency_id em fare_attributes.txt. Veja a discussão.

16 de março de 2016

• Transição da documentação do GTFS para Github em https://github.com/google/transit

3 de fevereiro de 2016

• Adicionado agency_email à proposta agency.txt para spec: discussão

2 de fevereiro de 2015

• Adicionada a proposta stop_times.txt 'timepoint' à especificação: discussão

17 de fevereiro de 2014

• Acrescentou trips.txt 'bikes_allowed' proposta a spec: discussão

15 de outubro de 2012

• Acrescentou trips.txtwheelchair_accessible' proposta para spec: discussão

20 de junho de 2012

• Adicionada proposta 'wheelchair_boarding' à especificação: discussão

2 de fevereiro de 2012

• Adicionada proposta 'stop_timezone' à especificação: discussão

18 de janeiro de 2012

• Migrou a documentação do antigo code.google.com para sua nova localização em developers.google.com.

26 de setembro de 2011

• Adicionada proposta 'feed_info' à especificação: discussão

6 de setembro de 2011

• Adicionada a proposta 'agency_fare_url' à especificação: discussão
• Adicionada proposta de 'exact_times' à especificação: discussão

30 de março de 2009

• Uma nova seção sobre como tornar uma ração de trânsito disponível ao público. Isto não foi discutido anteriormente no grupo, porque não foi estritamente uma mudança na forma como os dados são interpretados ou escritos. Entretanto, algumas pessoas no Google pensaram que seria informativo incluir a discussão de usos não-Google do GTFS, uma vez que há um número crescente de aplicações que podem fazer uso de dados GTFS.
• Esclarecimentos sobre o formato CSV: discussão.
• Orientação adicional sobre como escolher cores contrastantes nas descrições dos campos route_color e route_text_color.
• trip_short_name, como proposto e testado nestes tópicos: a e b.
• Uma correção para um erro menor nos dados da amostra incluídos no end do documento (dando à parada S7 a parent_station S8).
• Acrescentou informações "agency_lang" aos dados da amostra no end do documento, como sugerido por Marcy durante o período de comentários: discussão.
• Atualizado o link para a alimentação GTFS da OCTA na barra lateral
• Ver resumo original.

26 de fevereiro de 2009

• Removida a maioria das instruções de envio de rações específicas do Google, já que há muitas outras aplicações que consomem dados GTFS neste ponto.
• Corrigido um link quebrado na barra lateral para a alimentação pública do Orange County OCTA.

7 de agosto de 2008

• Restaurou o campo stop_url, que foi omitido acidentalmente na versão de 6 de agosto
• Adicionado agency_phone aos dados de amostra
• Acrescentou uma menção do acordo de uso de dados ao enviar um feed ao Google

6 de agosto de 2008

• Acrescentado o arquivo transfers.txt, permitindo que os editores de feeds dêem dicas sobre o comportamento de transferência preferido(proposta original)
• Adicionados campos do tipo location_type e parent_station aos stops.txt, permitindo que os pontos de parada sejam agrupados em estações(proposta original)
• Adicionado campo agency_phone para fornecer número de telefone de voz para uma agência(proposta original)
• Acrescentada a seção "Testando seus Feeds", mencionando ferramentas de teste de código aberto
• Esclarecimentos adicionais sobre o formato CSV, agency_timezone, agency_lang, route_color, route_text_color, arrival_time, departure_time, calendar.txt vs. calendar_dates.txt, tabelas de tarifas e frequencies.txt
• Adicionado link para documento de histórico de alimentação, e corrigido alguns links de alimentação pública
• Imagens de exemplo atualizadas para retratar a atual interface de usuário do Google Maps
• Dados de amostra atualizados/fixados no documento

29 de fevereiro de 2008

• Adicionado o campo stop_code em stops.txt para permitir a especificação de códigos de parada virados para o cavaleiro(proposta original)
• Esclareceu as descrições de route_short_name e route_long_name em routes.txt
• Esclareceu as descrições de arrival_time e departure_time em stop_times.txt
• Digitação fixa na seção Amostra de dados

20 de novembro de 2007

• Descrição esclarecida do block_id
• Mudou a linguagem para desfatizar o Google Transit (já que aplicações não-Google estão usando GTFS, e o roteamento de trânsito é agora uma característica integrada do Google Maps), e para corrigir diversos erros tipográficos
• Telas de exemplo atualizadas para refletir a apresentação dos campos GTFS na atual UI do Google Maps
• Atualizado o endereço de e-mail de contato do Google para provedores de dados de trânsito
• Formatação atualizada

5 de outubro de 2007

• Mudança de stop_sequence e shape_pt_sequence para permitir qualquer número inteiro não-negativo crescente
• Descrições esclarecidas e tipologias fixas

31 de maio de 2007

• Estilo de página atualizado, tornando o HTML mais limpo e mais acessível
• Adicionados links para exemplos de alimentação pública e outros sites úteis
• Removidos exemplos de descrições de campo individuais

9 de abril de 2007

• Adicionada seção sobre a apresentação de um alimento.
• Acrescentado o exemplo de feed da Agência de Trânsito.
• Acrescente-se que o calendar.txt pode ser omitido se todas as datas de serviço estiverem definidas no calendar_dates.txt.
• Tornou o campo agency_id opcional em feeds contendo apenas uma agência. Isto permite que os feeds existentes sem o agency_id permaneçam válidos.
• Adicionada especificação mais completa de agency_url, stop_url, e route_url, e valores de exemplo adicionais para esses campos.
• Adicionados 6 (Gôndola) e 7 (Funicular) como valores válidos do route_type.

8 de março de 2007

• Pequena edição para mover o campo stop_url do stop_times.txt, onde foi incorretamente especificado na atualização de 28 de fevereiro, para stops.txt, onde ele pertence.

5 de março de 2007

• Pequena edição para esclarecer a descrição do campo route_long_name.

28 de fevereiro de 2007

• Adição de frequencies.txt para suporte de cronograma baseado no progresso.
• Múltiplas agências agora permitidas na mesma alimentação. Também foi adicionado um novo campo agency_id em ambas agências.txt e routes.txt que permite especificar qual rota é operada por qual agência.
• Adição de URLs por rota e por parada.
• Adição de campo direction_id em trips.txt
• Suporte para mudanças de sinal de cabeçalho de viagem com adição de campo stop_headsign em stop_times.txt.
• Suporte para cores de rota com adição de route_color opcional e route_text_color em routes.txt.
• Removida a capacidade de especificar paradas usando endereços de rua. A versão anterior da especificação permitia dar a localização de uma parada de trânsito usando um endereço de rua nos campos stop_street, stop_city, stop_region, stop_postcode, e stop_country. Agora os locais de parada devem ser dados usando stop_lat para latitude e stop_lon para longitude, que são mais úteis para a maioria das aplicações.
• Adição do tipo de vehicle de teleférico para o campo route_type em routes.txt
• Veja o resumo das mudanças no blog original do Headway.

29 de novembro de 2006

• Adicionado suporte para informações de Shape trip via shapes.txt
• Esclareceu a definição de stop_sequence
• Tipo de pickup_type e drop_off_type marcados como opcionais

31 de outubro de 2006

• Suporte adicional para informações tarifárias
• Removidas datas de nomes de arquivos individuais
• Mudou as definições de valor do route_type
• Permitir que múltiplos arquivos de alimentação sejam postados ao mesmo time, desde que seus períodos de serviço não se sobreponham
• Block_id fixo em trips.txt para que estivesse corretamente marcado Opcional
• Notado que os cabeçalhos das colunas devem ser incluídos

29 de setembro de 2006

• Pequena edição para corrigir alguns erros nos exemplos.

25 de setembro de 2006

• Versão inicial.