Alterações

Introdução

A especificação GTFS não está definida de forma rígida. Em vez disso, é uma especificação aberta desenvolvida e mantida pela comunidade de agências, desenvolvedores e outras partes interessadas de transportes públicos que usam a GTFS. Espera-se que essa comunidade de produtores e consumidores de dados GTFS tenham propostas para ampliar a especificação a fim de permitir novos recursos. Para ajudar a gerenciar esse processo, foram estabelecidos os seguintes procedimentos e orientações.

O processo de alteração

O esboço geral para a alteração da especificação possui algumas etapas:

  1. Propor uma alteração na lista de discussão de alterações da GTFS.
  2. Receber comentários e feedback da comunidade GTFS e reiterar a alteração proposta.
  3. Localizar, pelo menos, um produtor e um consumidor de GTFS para implementar e testar a alteração proposta.
  4. Enviar uma solicitação de comentários final sobre a alteração proposta para a lista de discussão. Se nenhuma questão pendente for identificada após uma semana, a proposta será adotada oficialmente.

O grupo de discussão servirá como o local principal para se sugerirem alterações na especificação, de tal modo que os usuários da GTFS possam aprender e oferecer feedback sobre as alterações propostas. Se a comunidade, de um modo geral, concordar que a proposta é válida e segue os princípios da GTFS descritos abaixo, ela será oficialmente adicionada à especificação. Exigimos também que qualquer alteração proposta seja implementada por, pelo menos, um produtor e um consumidor da GTFS a fim de confirmarem a viabilidade dessa alteração na prática.

Além do grupo de discussão, observe que o Site de alterações da GTFS será usado para documentar as propostas já de alterações da GTFS já existentes como suporte ao grupo de discussão.

Princípios de orientação

A fim de preservar a visão original da GTFS, foram estabelecidos vários princípios de orientação que devem ser levados em consideração ao se estender a especificação:

Os feeds devem ser fáceis de criar e editar.

Escolhemos CSV como base para a especificação, porque esse formato é fácil de visualizar e editar usando programas de planilhas e editores de texto, o que é útil para agências menores. Também é simples de gerar na maioria dos idiomas 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 de feed devem ser capazes de extrair as informações que estão procurando com o menor esforço possível. As alterações e adições ao feed devem ser as mais úteis possíveis a fim de minimizarem o número de caminhos de código que os leitores de feed precisam implementar. No entanto, a prioridade deve ser a dada ao processo de uma criação mais fácil, uma vez que haverá mais editores de feed que leitores.

As alterações feitas na especificação devem ser compatíveis com versões anteriores.

Quando recursos são adicionados à especificação, tentamos evitar fazer alterações que possam tornar inválidos os feeds. Não queremos criar mais trabalho para os editores de feed até que eles adicionem recursos 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.

Recursos especulativos são desencorajados.

Cada novo recurso adiciona complexidade à criação e à leitura de feeds. Portanto, queremos tomar cuidado para adicionar apenas recursos que sejam reconhecidamente úteis. Idealmente, qualquer proposta terá sido testada, gerando dados para um sistema de transporte público real que utilize os novos recursos e criando software para ler e exibi-lo. Observe que a GTFS permite prontamente extensões ao formato com a adição de colunas extras e arquivos que são ignorados pelos analisadores e validadores oficiais a fim de que as propostas possam ter um protótipo e sejam testadas em feeds já existentes.

Histórico de revisão

15 de outubro de 2012

  • Adicionada proposta 'wheelchair_accessible' do trips.txt à especificação: discussão

20 de junho de 2012

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

02 de fevereiro de 2012

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

18 de janeiro de 2012

26 de setembro de 2011

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

6 de setembro de 2011

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

30 de março de 2009

  • Uma nova seção sobre como disponibilizar um feed de transporte publicamente. Isso não foi discutido antes no grupo, porque não era uma alteração na forma como os dados são interpretados ou gravados. No entanto, alguns dos colegas do Google acharam que poderia ser útil incluir a discussão de usos de GTFS fora do Google, uma vez que há um número cada vez maior de aplicativos que podem usar dados formatados por GTFS.
  • Esclarecimentos sobre o formato CSV: discussão.
  • Orientações adicionais sobre como escolher cores contrastantes nas descrições dos campos route_color e route_text_color.
  • trip_short_name, conforme proposto e testado nestas sequências: a e b.
  • Incluída uma correção para um pequeno erro nos dados de amostra, no final do documento (fornecendo à parada S7 a parent_station S8).
  • Adicionadas informações "agency_lang" aos dados de amostra ao final do documento, conforme sugerido pela Marcy durante o período de comentários: discussão.
  • Atualizado o link para o feed GTFS da OCTA na barra lateral
  • Consulte o resumo original.

26 de fevereiro de 2009

  • Removida a maior parte das instruções sobre envio de feeds específicos do Google, uma vez que há muitos outros aplicativos que consomem dados GTFS neste momento.
  • Corrigido um link na barra lateral para o feed público Orange County OCTA.

07 de agosto de 2008

  • Restaurando o campo stop_url, que foi omitido acidentalmente na versão de 6 de agosto
  • Adicionado agency_phone aos dados de exemplo
  • Adicionada uma menção ao contrato de uso de dados durante o envio de um feed ao Google

6 de agosto de 2008

  • Adicionado arquivo transfers.txt, permitindo que os editores de feed forneçam dicas sobre comportamento de transferência preferido (proposta original)
  • Adicionados campos location_type e parent_station a stops.txt, permitindo que os postos de parada sejam agrupados por estações (proposta original)
  • Adicionado campo agency_phone para fornecer número de telefone por voz de uma agência (proposta original)
  • Adicionada seção "Como testar seus feeds", mencionando ferramenta de teste de código aberto
  • Adicionados esclarecimentos sobre formato CSV format, 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 feeds e corrigidos alguns links de feeds públicos
  • Atualizadas imagens de exemplos para descrever a interface do usuário atual do Google Maps
  • Atualizados e corrigidos dados de exemplos no documento

29 de fevereiro de 2008

  • Adicionado o campo stop_code field em stops.txt para permtir a especificação de códigos de paradas para os passageiros (proposta original)
  • Esclarecidas as descrições de route_short_name e route_long_name em routes.txt
  • Esclarecidas as descrições de arrival_time e departure_time em stop_times.txt
  • Corrigidos erros de digitação na seção "Dados de exemplo"

20 de novembro de 2007

  • Esclarecida a descrição de block_id
  • Alterado o idioma para tirar o foco do Google Transit (uma vez que aplicativos diferentes do Google estão usando GTFS e os trajetos dos transportes públicos são agora um recurso integrado do Google Maps) e para corrigir erros de digitação diversos
  • Atualizadas capturas de tela de exemplos para refletir a apresentação de campos GTFS na interface do usuário atual do Google Maps
  • Atualizado o endereço de e-mail de contato do Google para provedores de dados de transporte público
  • Atualizada a formatação

5 de outubro de 2007

  • Alterados stop_sequence e shape_pt_sequence para permitir aumento de números inteiros não-negativos
  • Esclarecidas descrições e corrigidos erros de digitação

31 de maio de 2007

  • Atualizado estilo da página, HTML esclarecido e tornado mais acessível
  • Adicionados links a exemplos de feeds públicos e outros sites úteis
  • Removidos exemplos das descrições de campos individuais

09 de abril de 2007

  • Adicionada seção sobre como enviar um feed.
  • Adicionado o feed Exemplo de agência de transporte público.
  • Adicionada note informando que calendar.txt pode ser omitido se todas as datas de serviço estiverem definidas em calendar_dates.txt.
  • Tornado opcional o campo agency_id em feeds contendo apenas uma agência. Isso permite que feeds existentes sem agency_id permaneçam válidos.
  • Adicionadas especificação mais completa de agency_url, stop_url, e route_url e valores de exemplo adicionais para esses campos.
  • Adicionados 6 (Gondola) e 7 (Funicular) como valores válidos de route_type.

08 de marco de 2007

  • Pequena edição para mover o campo stop_url de stop_times.txt, que foram especificados incorretamente na atualização de 28 de fevereiro para stops.txt, ao qual ele pertence.

05 de março de 2007

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

28 de fevereiro de 2007

  • Adicionado frequencies.txt para suporte a programação baseada em intervalo entre as viagens
  • Várias agências agora permitidas no mesmo feed. Adicionado também novo campo agency_id em agencies.txt e routes.txt, que permite especificar qual trajeto é operado por qual agência.
  • Adicionados URLs por trajeto e por parada.
  • Adicionado campo direction_id em trips.txt.
  • Suporte para alterações nas placas de viagens intermediárias com adição do campo stop_headsign em stop_times.txt.
  • Suporte par cores dos trajetos com adição de route_color e route_text_color em routes.txt.
  • Removida a habilidade de especificar paradas usando endereços de ruas. A versão anterior da especificação permitia dar a localização de uma parada de transporte público usando um endereço nos campos stop_street, stop_city, stop_region, stop_postcode e stop_country. Agora os locais de parada devem ser fornecidos usando stop_lat, para latitude, e stop_lon para longitude, que são mais úteis para a maioria dos aplicativos.
  • Adicionado tipo de veículo teleférico para o campo route_type em in routes.txt.
  • Cosnulte a postagem do blog sobre placas para ver um resumo das alterações.

29 de novembro de 2006

  • Adicionado suporte para informações de forma de viagem por meio de shapes.txt
  • Esclarecida a definição de stop_sequence
  • pickup_type e drop_off_type marcados como opcional

31 de outubro de 2006

  • Adicionado suporte para informações sobre tarifas
  • Removidas datas de nomes de arquivos individuais
  • Alteradas as definições do valor route_type
  • Permitido que arquivos de vários feeds sejam postados ao mesmo tempo, contanto que o período do serviço não seja sobreposto
  • Corrigido block_id em trips.txt para que fosse corretamente marcado como Opcional
  • Observado 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.