General Transit Feed Specification
A General Transit Feed Specification (GTFS), ou Especificação Geral de Feed de Trânsito em português, é um padrão aberto que permite descrever digitalmente o cronograma planejado de funcionamento do transporte público de uma dada cidade [1][2]. Esta especificação define quais e como os elementos de transporte público devem ser descritos digitalmente para representar o cronograma de funcionamento previsto. Por exemplo, o elemento ponto de parada da GTFS contempla não apenas a localização do mesmo, através da latitude e longitude, mas também permite indicar outros dados, como se o ponto encontra-se dentro ou fora de um terminal ou se possui acessibilidade a cadeirantes. A GTFS também especifica como relacionar estes elementos, e.g., permitindo vincular um determinado ponto de parada a uma ou mais linhas de ônibus ou descrever que um metrô passa em uma dada estação com uma frequência de 5 minutos. Além disso, vale salientar que a especificação possui elementos que possibilitam descrever o funcionamento e integração de múltiplo modos de transporte, tais como: ônibus, metrô, trem e teleférico [3]. Os elementos da GTFS e suas relações são descritas como um conjunto de arquivos textuais, que por sua vez é comprimido em um único arquivo .zip.

Ao formalizar a descrição da operação do trânsito digitalmente nestes elementos, o padrão visa permitir que as informações sejam interoperáveis e consumidas por outros programas de computadores [4]. Para exemplificar esse tipo de interação, considere o programa Transitfeed da Google. Este programa possibilita visualizar os dados GTFS de maneira interativa, mostrando os detalhes de cada linha descrita, como trajeto, acessibilidade, horário e pontos de parada. A ilustração ao lado mostra um exemplo desta interação, para a linha 396 da cidade do Rio de Janeiro. Note que o padrão possibilita que as informações descritas possam ser utilizadas por outros programas.
Por exemplo, programas como Google Maps e OpenStreetMaps interagem com o arquivo descrito no formato GTFS para compreender a topologia da malha viária do transporte público e realizar serviços de roteamento para os usuários. Já Sistemas de Informação Geográficos (SIGs), como ArcGis e QGis, podem importar os dados no formato GTFS para realizar algum estudo de geoprocessamento, por exemplo, descobrir quais as maiores rotas ou por quais bairros elas passam. Com base nisso, percebe-se que a descrição de dados do trânsito do transporte público usando o padrão GTFS não somente serve para tornar essa informação digital, mas possibilita que uma gama de aplicações possa interagir e usufruir destes dados.
História
Estrutura
Os elementos do GTFS e suas relações são descritos seguindo o formato aberto Comma-separated values (CSV).
O formato CSV determina que cada entrada de dados seja descrita por uma ou mais linhas, onde cada valor desta é separado pelo caractere vírgula ,
.
Por exemplo, uma descrição simplificada das paradas de uma cidade é descrita no arquivo abaixo (stops.txt
).
Note que a primeira linha do arquivo especifica os cabeçalhos a cerca das paradas.
Por exemplo, o campo stop_id
descreve o identificador da parada, por exemplo, o identificador da parada Terminal Alvorada é 20803757. Tal valor pode ser utilizado para referenciá-la em outro momento, por exemplo, ao associar que uma linha passar por esta parada.
Note que o arquivo também contém outros campos, como stop_lat
, stop_lon
e wheelchair_boarding
, que são descritos com detalhe na Seção de Elementos do GTFS.
Estes valores podem ser utilizados para fornecer informações para os usuários, por exemplo, a latitude e longitude permite encontrar a parada mais próxima do local do usuário.
Já o campo wheelchair_boarding
quando possui o valor 1 indica que a parada é acessível a cadeirantes, enquanto o valor 2 indica que a mesma não contém meios de acessibilidade ao mesmo.
- stops.txt
"stop_id","stop_name","stop_lat","stop_lon","location_type","wheelchair_boarding" "20803757","Terminal Alvorada",-23.001281539713,-43.366142879812,1,1 "20059677","BRT Vendas de Varanda",-22.950882454514,-43.650797832707,1,1 "34915648","CANDELÁRIA",-22.9003933563542,-43.1768603087864,0,0 "27886226","Largo do Curvelo",-22.919030483861746,-43.1832850781533,0,2
Elementos
Com intuito de abordar as diversas realidades das cidades, a especificação GTFS define o funcionamento do transporte público utilizando uma série de elementos modulares, por exemplo, o padrão utiliza módulos como linhas, pontos de paradas, cronograma, tarifas e zonas.
Isto permite que uma cidade possa adotar o padrão mesmo que utilize apenas um subconjunto destes elementos.
Entretanto, para manter o mínimo de informações a outras aplicações, a GTFS especifica a obrigatoriedade dos seguintes elementos modulares [1]: agência (agency.txt
), pontos de paradas (stops.txt
), linhas (routes.txt
), horário de paradas (stop_times.txt
) e cronograma (calendar.txt
).
Já os arquivos opcionais permitem especificar diferentes cronogramas para feriados (calendar_dates.txt
), percursos das linhas (shapes.txt
), frequência de viagens (frequencies.txt
), baldeações (transfers.txt
), dentre outras informações.
Elementos Obrigatórios
Todo arquivo GTFS deve possuir os dados da agência responsável pelo transporte público sendo descrito.
Isto é feito preenchendo o elemento agency.txt
. Este possui campos para descrever os dados de cada agência envolvida no transporte descrito. Os campos do arquivo s
Note, que o elemento possibilita descrever múltiplas agências.
Cada elemento é descrito em um arquivo texto seguindo o formato Comma-separated values (CSV). Este formato
Todo arquivo GTFS deve possuir os dados da agência responsável pelo transporte público sendo descrito.
Isto é feito preenchendo o elemento agency.txt
.
Este possui campos para descrever os dados de cada agência envolvida no transporte descrito.
Os campos do arquivo s
Note, que o elemento possibilita descrever múltiplas agências.
Exemplo

Como caso de uso, nesta seção iremos descrever como especificar a linha de ônibus 275 da Rede Metropolitana de Transportes Coletivos de Goiânia no padrão GTFS [5]. Esta é uma linha alimentadora que realiza o transporte entre as várias unidades do Câmpus II da Universidade Federal de Goiás, conforme ilustrado abaixo. Como a linha atende primariamente a universidade, ela opera durante os dias de semana e na manhã de sábado. Com intuito de simplificar a explicação sobre o GTFS, este exemplo contemplará apenas os arquivos obrigatórios da especificação GTFS.
Como visto nos elementos básicos do GTFS, todas as linhas devem possuir uma agência de transporte responsável. Logo, primeiramente será necessário criar e descrever esta agência no arquivo agency.txt
. Neste exemplo, assumiremos que a linha é responsável pela agência fictícia Wikiportes. O arquivo de agência inclui os dados pertinentes da mesma, como nome, idioma, endereço da página web e fuso horário. Note que o fuso horário é especificado em relação a São Paulo, pois segue o formato ICANN. O arquivo completo, pode ser visto abaixo:
agency.txt | ||||
---|---|---|---|---|
agency_id | agency_name | agency_url | agency_timezone | agency_lang |
WP | WikiPortes | http://www.wikiportes.com.br | America/Sao_Paulo | pt |
routes.txt:
route_id | agency_id | route_short_name | route_long_name | route_type |
---|---|---|---|---|
L725 | WP | 725 | PC Campus / Circular Campus | 3 |
calendar.txt:
service_id | start_date | end_date | monday | tuesday | wednesday | thursday | friday | saturday | sunday |
---|---|---|---|---|---|---|---|---|---|
diasuteis | 20171022 | 20181022 | 1 | 1 | 1 | 1 | 1 | 0 | 0 |
sabados | 20171022 | 20181022 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
domingo | 20171022 | 20181022 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
trips.txt:
trip_id | route_id | service_id | direction_id | trip_headsign |
---|---|---|---|---|
L725-IDA001 | L725 | diasuteis | 0 | CAMPUS CIRCULAR |
L725-IDA002 | L725 | diasuteis | 1 | CAMPUS CIRCULAR |
L725-IDA003 | L725 | diasuteis | 0 | CAMPUS CIRCULAR |
L725-VLT001 | L725 | diasuteis | 1 | CAMPUS CIRCULAR |
L725-VLT002 | L725 | sabados | 0 | CAMPUS CIRCULAR |
L725-VLT003 | L725 | sabados | 0 | CAMPUS CIRCULAR |
stops.txt:
stop_id | stop_name | stop_lat | stop_lon |
---|---|---|---|
L725-IDAPAR001 | ENTRADA UFG | -16.6003566 | -49.2592140 |
L725-IDAPAR002 | ICB UFG | -16.6015514 | -49.2617487 |
L725-IDAPAR003 | CENTRO DE AULAS B | -16.6017007 | -49.2634570 |
L725-IDAPAR004 | INF UFG | -16.6029332 | -49.2666641 |
L725-IDAPAR005 | CEPAE UFG | -16.6080088 | -49.2667869 |
L725-IDAPAR006 | FEFD UFG | -16.6031396 | -49.2675132 |
L725-IDAPAR007 | AGENCIA RURAL | -16.6011252 | -49.2717861 |
L725-IDAPAR008 | VETERINARIA UFG | -16.5992140 | -49.2764849 |
L725-VLTPAR001 | VETERINARIA UFG | -16.5993361 | -49.2763320 |
L725-VLTPAR002 | AGENCIA RURAL | -16.6015069 | -49.2734057 |
L725-VLTPAR003 | FEFD UFG | -16.6033530 | -49.2685251 |
L725-VLTPAR004 | INF UFG | -16.6032882 | -49.2669031 |
L725-VLTPAR005 | CENTRO DE AULAS B | -16.6019598 | -49.2634388 |
L725-VLTPAR006 | ICB UFG | -16.6014207 | -49.2614400 |
L725-VLTPAR007 | ENTRADA UFG | -16.6007757 | -49.2602216 |
stop_times.txt:
trip_id | stop_id | stop_sequence | arrival_time | departure_time |
---|---|---|---|---|
L725-IDA001 | L725-IDAPAR001 | 1 | 9:00:00 | 9:00:00 |
L725-IDA001 | L725-IDAPAR002 | 2 | 9:05:10 | 9:05:10 |
L725-IDA001 | L725-IDAPAR003 | 3 | 9:07:30 | 9:07:30 |
L725-IDA001 | L725-IDAPAR004 | 4 | 9:11:00 | 9:11:00 |
L725-IDA001 | L725-IDAPAR005 | 5 | 9:13:40 | 9:13:40 |
L725-IDA001 | L725-IDAPAR006 | 6 | 9:15:00 | 9:15:00 |
L725-IDA001 | L725-IDAPAR007 | 7 | 9:18:00 | 9:18:00 |
L725-IDA001 | L725-IDAPAR008 | 8 | 9:20:00 | 9:00:00 |