Os dados de transportes têm falhas de origem. É assim que as corrigimos.
Qualquer operador de transportes pode publicar um feed GTFS, e ninguém o verifica antes de entrar em funcionamento. O que é efetivamente publicado é inconsistente, incompleto e, por vezes, simplesmente errado: paragens duplicadas, calendários inválidos, coordenadas incorretas, horas de chegada registadas depois das horas de partida. Um planeador de viagens construído diretamente sobre esses dados envia alguém para a esquina errada; um agente de IA que repete um horário desatualizado deixa à espera, numa paragem, a pessoa que confiou nele. Processamos 7 000+ feeds de operadores de transportes de todo o mundo num processo criado para colmatar essa falha: obtemos e normalizamos cada feed, consolidamos os operadores sobrepostos num conjunto de dados coerente e, em seguida, aplicamos 150+ verificações de correção, enriquecimento e validação, aperfeiçoadas com dados reais de produção.
Manutenção ativa, não uma correção pontual
Este processo está em desenvolvimento contínuo - novas regras, algoritmos melhorados e correções da qualidade dos dados são publicados todas as semanas. As respostas da pesquisa, dos horários e da API utilizam a versão validada mais recente do processamento, publicada através de uma alternância de servidores blue-green: o tráfego passa para um ambiente acabado de implementar, em vez de se reiniciar o ambiente atual. O cálculo de percursos funciona numa infraestrutura própria e dedicada, com um ciclo de versões independente. As entregas de dados pontuais e recorrentes exigem aprovação manual. Envie o formulário de pedido de dados para discutir exportações de dados e condições de entrega.
Regras aperfeiçoadas com dados reais de transporte
Algumas verificações estruturais demoram milissegundos. A deduplicação de paragens entre feeds, a impressão digital das viagens e a unificação de calendários exigiram mais de um ano de testes e aperfeiçoamento com dados reais de produção.
Cada regra é validada com 7 000+ feeds reais em cada ciclo semanal de processamento.
Processo de tratamento do GTFS estático
O que corrigimos, diretamente do processamento
O GTFS é um formato aberto e autopublicado: qualquer operador pode publicar um feed, e nenhuma autoridade central o valida antes de entrar em funcionamento. Acompanhamos 10 000+ operadores de transporte em 90+ países - desde redes de metro com equipas de dados dedicadas até pequenas empresas de autocarros que exportam os dados de um software de horários atualizado pela última vez há uma década. 150+ verificações automatizadas são executadas em cada feed para detetar os problemas daí resultantes. Não se limitam a eliminar os dados errados: uniformizam as maiúsculas e minúsculas dos nomes, reconstroem relações quebradas e dão a cada paragem, linha e viagem uma identidade e uma ordenação estáveis entre as atualizações semanais. É também por isso que a API baseada nestes dados é rápida: os resultados já chegam com nomes corretos, sem duplicados e pela ordem certa, em vez de serem limpos no cliente a cada pedido. Seguem-se as verificações que mais vale a pena mostrar, agrupadas pelos dados que alteram - não é a lista completa:
Nomes e identificadores
Os campos que deveriam conter nomes legíveis chegam da fonte com valores vazios, maiúsculas e minúsculas inconsistentes ou dois campos que, sem aviso, se duplicam um ao outro.
Cada nome parece ter sido escrito por uma pessoa
Chega de paragens EM MAIÚSCULAS ou caracteres duplicados e ilegíveis: todos os campos de nome são limpos e uniformizados, para que a sua interface nunca tenha de esconder imperfeições da fonte.
Nomes de linhas que funcionam numa lista
Os nomes curtos e longos são equilibrados automaticamente entre si: nada vazio, nada duplicado, nada tão longo que estrague o seu seletor de linhas.
Sem informações repetidas nos dados de paragens
Quando a descrição apenas repete o nome da paragem, eliminamo-la, em vez de entregar o mesmo texto em dois campos diferentes.
Nada é entregue sem nome
Uma paragem, um operador ou uma viagem sem nome recebe um texto substituto claro e honesto, em vez de um campo vazio que estrague a sua lógica de apresentação.
O passageiro vê sempre para onde vai o veículo
Quando o fornecedor omite o destino da viagem, preenchemo-lo com a última paragem, para que a sua aplicação possa mostrar sempre um destino.
O idioma certo, sempre
Quando o idioma declarado no feed não corresponde ao do operador, corrigimo-lo, para que a sua lógica de localização possa realmente confiar nesse campo.
Calendários e horários
Períodos de serviço em que quase nada circula, chegadas posteriores às partidas, horários que implicam um autocarro mais rápido do que é fisicamente possível: para quem confia no feed bruto, os erros de uma ferramenta de exportação de horários parecem serviço real.
Calendários que refletem o serviço real, não restos da programação
Períodos de serviço fictícios, registos contraditórios e calendários duplicados são detetados e eliminados antes de dizerem a um passageiro que um autocarro circula num dia em que não circula.
Viagens no tempo não entram nos seus horários
Quando a chegada à paragem atual é anterior à partida da paragem anterior - um erro de exportação real e recorrente -, corrigimo-la e assinalamos os raros feeds em que o problema está demasiado generalizado para ser corrigido sem revisão.
Todas as viagens têm hora real de partida e de chegada
Os campos de hora vazios são validados e preenchidos, para que nenhum sistema a jusante tenha de adivinhar quando o veículo parte realmente.
Sem viagens que não podem circular
Uma viagem sem a primeira ou a última hora não pode ser programada: eliminamo-la, em vez de a deixar estragar silenciosamente o itinerário de um passageiro.
Serviço noturno tratado corretamente
As partidas depois da meia-noite são convertidas para um formato de hora GTFS válido sem alterar o horário real - um pormenor que engana a maioria dos analisadores mais simples.
Sem ambiguidade sobre quais horários são exatos
O campo timepoint é definido automaticamente consoante existam ou não dados reais de chegada/partida, em vez de ficar vazio para que cada consumidor o interprete de forma diferente.
Viagens fisicamente impossíveis não chegam aos utilizadores
Os intervalos de frequência sobrepostos são corrigidos, e as viagens que implicam velocidades que nenhum veículo consegue atingir são eliminadas: nenhum passageiro deve ser informado de que um autocarro circula a 2000 km/h.
Paragens e coordenadas
Dois operadores que servem a mesma esquina publicam, cada um, a sua versão da paragem; uma viagem pode referir um stop_id que o próprio feed nunca chegou a definir; e os dados de acessibilidade estão em falta ou simplesmente errados.
Cada paragem sabe que tipo de paragem é
As paragens só de embarque recebem automaticamente o tipo de localização, e as viagens que referem um tipo de paragem incompatível são detetadas antes de estragarem o seu mapa.
Estações com entradas reais, não apenas um ponto no mapa
As entradas, as saídas e as ligações às estações principais são adicionadas a partir de uma base de dados de interfaces que mantemos, e as estações principais mal posicionadas são deslocadas para a sua localização real.
Nenhuma viagem falha por causa de uma paragem não definida
Quando uma viagem refere uma paragem que o próprio stops.txt do feed nunca chegou a definir, reconstruímo-la - incluindo o nome e as coordenadas dos dados oficiais NAPTAN do Reino Unido, quando disponíveis - em vez de deixar a viagem falhar silenciosamente.
Dados de acessibilidade em que pode realmente confiar
Uma estação é marcada como acessível logo que uma plataforma o seja, e como inacessível apenas quando todas as plataformas o são explicitamente - as paragens sem dados ficam como desconhecidas, nunca com um "não" falso.
Precisão sem excesso de dados
As coordenadas são arredondadas para seis casas decimais - precisão inferior a um metro -, reduzindo o tamanho dos ficheiros sem perda de precisão de posicionamento.
Uma paragem, um registo - mesmo quando dois operadores a publicam
As paragens a cerca de 20 metros uma da outra e com o mesmo sentido são reconhecidas como o mesmo local físico e unificadas, em vez de aparecerem duas vezes no seu mapa.
Cada paragem sabe que transportes a servem
O modo de transporte de uma paragem é obtido a partir das linhas que realmente a servem, para que o seu mapa e os seus filtros mostrem o ícone correto sem consultas adicionais.
Respostas ao nível da cidade, sem ter de tratar da geografia
Cada paragem é associada à cidade em que se encontra, para que as exportações e os filtros da API por cidade funcionem sem mais.
Sem viagens que não levam a lado nenhum
Uma viagem com uma única paragem não é um verdadeiro serviço de transporte: é eliminada juntamente com os registos de paragem duplicados que normalmente a acompanham.
Linhas e tarifas
Os campos de tipo de veículo, cor ou tarifa de uma linha estão frequentemente errados: mal codificados, vazios ou copiados de um campo que já existe noutra parte do feed.
Tipos de veículo incorretos não chegam aos utilizadores
Os tipos de veículo, os nomes de linhas e as associações a operadores incorretos são detetados e corrigidos com base numa tabela que a nossa equipa de dados mantém ativamente.
Nenhuma linha é entregue com um tipo irreconhecível
Um tipo de linha em falta ou inválido assume, por segurança, o valor Bus, para que a sua aplicação nunca falhe perante um valor desconhecido - e cada correção gera um alerta interno, para que uma pessoa verifique os casos invulgares.
Cores de linhas sempre legíveis
Os códigos de cor inválidos são corrigidos, e a cor do texto em falta é definida em função do fundo, para que o identificador da linha nunca fique ilegível.
Sem ligações duplicadas nos dados das linhas
Um URL de linha que apenas repete o site do operador é eliminado, em vez de ser entregue como ruído.
Até os pequenos pormenores são tratados
As viagens de ferry recebem o valor correto no campo de transporte de bicicletas, eliminando um aviso de validação que a maioria dos feeds traz por predefinição.
Dados tarifários que passam na validação
Os campos das regras tarifárias são verificados e corrigidos segundo a especificação GTFS antes de lhe chegarem.
Identidade estável, ordenação e velocidade
Um fornecedor renumera os seus próprios IDs de viagem entre atualizações, duas fontes publicam a mesma linha com identificadores diferentes e nada no feed bruto indica a ordem pela qual as viagens de um dia devem ser apresentadas.
A mesma linha, reconhecida onde quer que seja publicada
As linhas recebem uma impressão digital baseada na sua geografia real, para que a mesma linha publicada por duas fontes diferentes seja reconhecida como uma só - e não apareça duas vezes.
A identidade da viagem mantém-se mesmo quando o fornecedor muda os seus IDs
As viagens recebem uma impressão digital baseada na sequência de paragens e nos horários, para que o mesmo serviço programado mantenha uma identidade estável entre as atualizações semanais - mesmo quando a fonte renumera os seus próprios IDs de viagem.
Sem viagens duplicadas a inflacionar os seus dados
As viagens com a mesma impressão digital de linha e horário são reconhecidas como a mesma viagem e unificadas num único registo canónico.
Resultados sempre pela ordem certa
Cada viagem recebe uma ordem diária estável, calculada uma única vez durante o processamento, para que nem a sua aplicação nem a nossa tenham de ordenar as viagens no cliente a cada pedido.
Sequência de paragens contínua e sem lacunas
As sequências de paragens com numeração fora do padrão são renumeradas a partir de zero, sem lacunas, para que tudo o que percorre as paragens de uma viagem funcione sem problemas.
A identidade da paragem mantém-se em cada ciclo de atualização
As paragens recebem uma impressão digital baseada no nome, nas coordenadas e no tipo de transporte - a base para reconhecer a mesma paragem física entre fontes e entre atualizações semanais.
Geometrias de linhas rápidas a desenhar e sem erros visuais
Os pontos de geometria desnecessários são eliminados e as distâncias recalculadas, reduzindo o volume de dados - e uma geometria que se afasta muito do trajeto real da viagem é desassociada, em vez de induzir em erro o seu mapa.
Operador, fuso horário e consultas
Um operador declara o fuso horário errado, ou nenhum, e todos os planeadores de viagens baseados no feed mostram chegadas uma hora adiantadas ou atrasadas - para todos os passageiros, todos os dias, até alguém dar por isso.
Contactos do operador que pode realmente utilizar
Os emails e URLs mal formados são eliminados, em vez de serem entregues com erros, e um URL de operador em falta recebe um valor substituto, para que nenhum sistema a jusante falhe por falta de um campo obrigatório.
Sem adivinhar o idioma do operador
O idioma em falta de um operador é preenchido com o idioma predefinido do país, para que a sua lógica de localização tenha sempre um valor real com que trabalhar.
Horários de partida corretos, não apenas plausíveis
Os fusos horários inválidos ou geograficamente incompatíveis de operadores e paragens são corrigidos - uma das causas mais comuns de um planeador mostrar um autocarro a chegar com uma hora de diferença.
Transbordos que apontam para locais reais
Uma regra de transbordo que refere uma paragem ou linha inexistente no feed é eliminada, em vez de ficar a estragar a pesquisa de ligações.
Respostas instantâneas sobre as linhas que servem uma paragem
Cada paragem recebe um índice pré-calculado das linhas que a servem, pelo que a chamada à API para obter as "linhas nesta paragem" é uma consulta direta e não um cruzamento de dados em tempo real.
Processo de tratamento em tempo real
A sincronização GTFS-RT é um dos problemas mais difíceis da engenharia de dados de transportes. Cada fornecedor utiliza os seus próprios IDs internos, formatos e convenções de nomes, que têm de ser associados ao horário estático em tempo real. O nosso processo inclui regras dedicadas de correspondência em tempo real, além do processamento estático:
- Verificação de coerência geográfica das posições dos veículos: as coordenadas fora da região de serviço são descartadas automaticamente (exemplo real: um feed de Londres a indicar autocarros nos EUA)
- A unificação de feeds de operadores diferentes pode gerar o mesmo ID de linha duas vezes - quando isso acontece, a prioridade de correspondência entre os duplicados é preservada explicitamente, e não escolhida de forma arbitrária mesmo operador+linha, 2 fontes → prioridade de correspondência preservada
- A correspondência de viagens não é um palpite pela hora mais próxima: quando uma chegada em tempo real fica entre duas viagens programadas, é atribuída através de uma janela temporal assimétrica, e não pelo ponto médio horário entre 2 viagens programadas → correspondência pela janela 75/25
- Uma sequência de alternativas por níveis tenta primeiro a correspondência mais específica e só alarga os critérios quando esta falha, em vez de aplicar uma única regra de tudo ou nada paragem+horário exatos indisponíveis → tenta linha+viagem, depois linha+horário
- Quando um sinal não pode mesmo ser resolvido - sentido em falta e nenhuma alternativa aplicável -, a correspondência falha de forma segura e devolve o registo sem associação, em vez de adivinhar sentido em falta, nenhuma alternativa resolve → sem correspondência
- Previsão da hora de chegada para paragens com dados em tempo real atrasados ou em falta
Processamento específico por país
Além do processo universal, desenvolvemos regras de processamento próprias para cada país, que têm em conta os formatos de dados locais, as normas de codificação e as particularidades de cada operador. As regras por país funcionam como uma camada adicional sobre o processo base e são ajustadas aos problemas reais de qualidade dos dados de cada fornecedor.
Os dados por trás do BusMaps
Os mesmos dados processados alimentam as pesquisas de percursos, os painéis de partidas e as respostas da API no BusMaps. Pode utilizá-los através da nossa API ou pedir conjuntos de dados corrigidos para a sua própria infraestrutura.
Obtenha dados de transportes corrigidos para o seu projeto
Peça GTFS corrigido, GeoJSON e exportações personalizadas ou ligue a sua aplicação através da nossa API. Indique a cobertura, os formatos e os requisitos de atualização de que precisa para acordarmos a entrega ou a integração.