Especificação Geral de Feed de Trânsito

(Redirecionado de GTFS)

A Especificação Geral de Feed de Trânsito (em inglês: General Transit Feed Specification, GTFS) especifica um formato comum de horários de transporte público e informações geográficas associadas.

Especificação Geral de Feed de Trânsito
Especificação Geral de Feed de Trânsito
Extensão do arquivo .zip
Lançamento 27 de setembro de 2006
Tipo de formato Cronograma de trânsito
Variado para CSV
Padronização Normalização de facto
Página oficial https://developers.google.com/transit/gtfs/

História editar

O que acabou virando o GTFS começou como um projeto secundário do funcionário da Google Chris Harrelson em 2005, que "brincou com maneiras de incorporar dados de trânsito no Google Maps [...] quando ele ouviu notícias de Tim e Bibiana McHugh, cônjuges e gerentes de TI na TriMet , a agência de trânsito de Portland, Oregon". [1]  McHugh é citado como ficando frustrado sobre achar direções de trânsitos em outras cidades, enquanto que serviços populares de mapa já estavam oferecendo direções para condução e fácil usabilidade na época.[2]

Bibiana e Tim McHugh eventualmente entraram em contato com Google e proveram a companhia com exportações CSV de informações da escala de horários da TriMet. Em Dezembro de 2005, Portland tornou-se a primeira cidade a ser caracterizada na primeira versão do programa “Transit Trip Planner”, da Google. Em setembro de 2006, cinco mais cidades dos Estados Unidos foram adicionadas ao Google Transit Trip Planner,e o formato dos dados foram lançados como Google Transit Feed Specification.

Nos Estados Unidos, não havia nenhum padrão para programações de transporte público antes do advento do GTFS, nem mesmo um padrão não determinado. De acordo com Timothy Moore, gerente de website de longo tempo da BART, antes do advento de GTFS, BART tinha que prover diferentes consumidores de informação com diferentes formatos, fazendo um formato padrão de transporte muito desejável. O formato publico e grátis, assim como a disponibilidade dos horários GTFS, rapidamente fez desenvolvedores basearem seus softwares relacionados a transporte no formato. Isso resultou em "centenas de aplicativos de transporte úteis e populares"  assim como catálogos listando os feeds GTFS disponíveis. Devido ao formato de dados comum esses aplicativos aderem a, soluções não precisam ser personalizadas para um operador de transporte, mas podem facilmente ser estendidas para qualquer região onde um feed GTFS está disponível.

Devido ao grande uso do formato, a parte "Google" que fazia parte do nome original, foi considerado inapropriado "fazendo alguns usuários tímidos não adotarem o GTFS ". Como uma consequência, foi proposto uma mudança do nome da especificação para General Transit Feed Specification em 2009.

Estrutura editar

 
Diagrama de classe de GTFS

Um feed GTFS é uma coleção de no mínimo seis, no máximo treze arquivos CSV (com extensões .txt) contidos dentro de um arquivo .zip. A codificação de caracteres preferida é UTF-8. Juntas, as tabelas CSV relacionadas descrevem as operações agendadas de um sistema de trânsito como visíveis para os usuários. A especificação é projetada para ser suficiente de prover uma funcionalidade de planejar viagens, mas também é útil para outros aplicativos como análises de níveis de serviço e algumas medidas de desempenhos gerais. Em contraste aos padrões europeus da indústria de transporte como Transmodel ou VDV-45X, GTFS apenas inclui operações programadas que são feitas para serem distribuídas entre os usuários. Também é limitada para informação programada e não inclui informação em tempo real. Contudo, informação em tempo real pode ser relacionada a programações GTFS se de acordo com a especificação GTFS-realtime.

Abaixo há descrições das tabelas requeridas para um feed GTFS válido. Cada tabela é literalmente um texto de arquivo CSV, com o nome do arquivo sendo o nome da table, sufixado com '.txt'. Então para a tabela 'agency' abaixo, um arquivo CSV chamado 'agency.txt' deve ser incluído em um feed GTFS válido.

agency.txt (Agência) editar

A tabela de agência fornece informações sobre a agência de trânsito, como nome, website e informação de contato.

Campos requeridos:

  • agency_name (Nome da agência)
  • agency_url (Link do website da agência)
  • agency_timezone (Fuso horário da agência)

routes.txt (Rotas) editar

A tabela the rotas identifica rotas distintas. Isto deve ser distinguido de roteamentos distintos, o que vários podem pertencer à uma rota única.

Campos requiridos:

  • route_id (primary key) (Identificação da rota(chave primária))
  • route_short_name (Nome curto da rota)
  • route_long_name (Nome longo da rota)
  • route_type (Tipo da rota)

trips.txt (Viagens) editar

Campos requiridos:

  • trip_id (primary key) (Identificação da viagem(chave primária))
  • route_id (foreign key) (Identificação da rota(chave externa))
  • service_id (foreign key) (Identificação do serviço(chave externa))

Campos opcionais:

  • block_id (Identificação do bloco) - A Identificação do Bloco indica o bloco do cronograma de uma viagem.

stop_times.txt (Tempos de paradas) editar

Campos requiridos:

  • stop_id (primary key) (Identificação da parada(chave primária))
  • trip_id (foreign key) (Identificação da viagem(chave externa))
  • arrival_time (Horário de chegada)
  • departure_time (Horário de saída)
  • stop_sequence (Sequência de parada)

Note que o tempo de permanência pode ser modelado pela diferença do tempo de chegada e saída. Entretanto, várias agências parecem não modelar o tempo de permanência para a maioria das paradas.

stops.txt (Paradas) editar

A tabela de paradas define as localizações geográficas de cada parada ou estação no sistema de transporte assim como, opcionalmente, algumas das facilidades com essas paradas.

Campos requeridos:

  • stop_id (primary key) (Identificação de parada(chave primária))
  • stop_name (Nome da parada)
  • stop_lon (Longitude da parada)
  • stop_lat (Latitude da parada)

calendar.txt (Calendário) editar

A tabela do calendário define padrões de serviço que operam recorrentemente como, por exemplo, todo dia da semana. Padrões de serviço que não repetem, como para um evento especial de uma única vez, serão definidos na tabela calendar_dates.

Campos requeridos:

  • service_id (primary key) (Identificação do serviço(chave primária))
  • monday (segunda)
  • tuesday (terça)
  • wednesday (quarta)
  • thursday (quinta)
  • friday (sexta)
  • saturday (sábado)
  • sunday (domingo)
  • start_date (Data de início)
  • end_date (horário de fim)

Campos opcionais:

  • calendar_dates.txt (Datas do calendário)
  • fare_attributes.txt (Atributos da tarifa)
  • fare_rules.txt (Regras)
  • shapes.txt
  • frequencies.txt (Frequências)
  • transfers.txt ()
  • feed_info.txt

Ver também editar

Referências

Ligações externas editar

 
O Commons possui uma categoria com imagens e outros ficheiros sobre Especificação Geral de Feed de Trânsito