Embed Size (px)
Citation preview
Universidade Federal Fluminense
Instituto de Computacao
Departamento de Ciencia da Computacao
NATALIA ROCHA DE ALMEIDA PIPAS
CORRECAO DE INCONSISTENCIAS NOS DADOS
DE GPS DE ONIBUS DO RIO DE JANEIRO
Niteroi-RJ
2017
ii
NATALIA ROCHA DE ALMEIDA PIPAS
CORRECAO DE INCONSISTENCIAS NOS DADOS DE GPS DE ONIBUS
DO RIO DE JANEIRO
Trabalho submetido ao Curso de
Bacharelado em Ciencia da Computacao
da Universidade Federal Fluminense como
requisito parcial para a obtencao do tıtulo
de Bacharel em Ciencia da Computacao.
Orientador: Prof. Marcos Lage Co-orientador: Prof. Antonio Augusto Rocha
Niteroi-RJ
2017
Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF
P664 Pipas, Natalia Rocha de Almeida
Correção de inconsistências nos dados de GPS de ônibus do Rio de Janeiro / Natalia Rocha de Almeida Pipas. – Niterói, RJ : [s.n.], 2017.
47 f.
Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.
Orientador: Marcos Lage, Antônio Augusto Rocha. 1. Processamento de dados. 2. GPS. 3. Ônibus. I. Título.
CDD 004.33
iv
A minha irma Lara, que me prometeu um
brownie para aparecer aqui.
v
Agradecimentos
A minha famılia, apoiadora de todos os meus projetos e sonhos.
Aos meus orientadores Marcos Lage e Antonio Augusto Rocha, sempre solıcitos
durante todo o trabalho.
Aos professores Lhaylla Crissaff, Aline Paes e Antonio Augusto Rocha pela presenca
na banca examinadora.
Aos meus colegas de trabalho, que reclamaram apenas um pouco do tempo que
dediquei a esse projeto.
vi
Resumo
Com os avancos recentes na coleta de dados urbanos, consequencia da evolucao
de diversos tipos de sensores, das tecnologias de comunicacao sem fio e da capacidade de
armazenamento de dados, surgem oportunidades para o desenvolvimento de aplicativos,
sistemas e tecnologias baseados na analise dos dados coletados e capazes de aumentar o
entendimento que se tem sobre areas urbanas. Seguindo essa tendencia, a prefeitura do
Rio de Janeiro tem disponibilizado dados de GPS de sua frota de onibus, que contem
informacoes como a localizacao geografica e velocidade dos veıculos em tempo real. En-
tretanto, o grande desafio de utilizar esta base de dados e a presenca de inconsistencias
como a ausencia do numero da linha servida por alguns veıculos e a presenca de regis-
tros de onibus em posicoes geograficas absurdas. Por outro lado, muitos destes problemas
podem ser corrigidos automaticamente atraves de modelos matematicos e estrategias com-
putacionais. Com base no exposto, foi desenvolvido um sistema capaz de, na posse das
trajetorias das linhas de onibus da cidade, corrigir alguns dos problemas mais frequentes
da base do GPS dos onibus do Rio de Janeiro e disponibilizar os dados corrigidos em um
formato de facil acesso aos sistemas externos que desejarem utiliza-los.
Palavras-chave: Onibus, DataRio, Linha, Dados Urbanos
vii
Abstract
With the global advance in collecting urban data, a consequence of the evolution
of many types of sensors, wireless communication technology and data storage, a number
of opportunities to develop apps and systems based on the analysis of the collected urban
data have emerged. This advance on the technology has the potential of significantly
improving the understanding we have on the urban area. Following this tendency, the
Rio de Janeiro government has made available GPS data from its buses, which contains
information like the geographic location and the speed of the vehicles in real time. Howe-
ver, the biggest challenge in using this data is related to some inconsistencies like the
absence of the line number of some buses and the presence of records containing absurd
geographic positions. On the other hand, many of these problems can be fixed automati-
cally by mathematical models and computational strategies. Based on that, we developed
a system capable of, by knowing the trajectory of the city’s buses, fix some of the most
frequent problems on the dataset and make the corrected results available in a format
that is easy to access to the external systems that wish to use it.
Keywords: Bus, DataRio, Line, Urban Data Monograph
Sumario
Resumo vi
Abstract vii
Lista de Figuras xi
Lista de Tabelas xii
1 Introducao 1
1.1 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organizacao da Monografia . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 A base dos onibus do Rio de Janeiro 5
2.1 Descricao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Inconsistencias nos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Filtragem dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Estruturacao dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Sistema Proposto 13
3.1 Modulo de carregamento de linhas . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Modulo de acesso aos dados do Data Rio . . . . . . . . . . . . . . . . . . . 15
3.3 Modulo de inferencia de linhas . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Disponibilizacao dos resultados . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Estudo de Caso 21
4.1 Precisao da estimativa das rotas . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
viii
ix
4.2 Origem dos erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Integracao com outros sistemas . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Resultados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Conclusoes 30
5.1 Limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2 Cobertura da cidade . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Lista de Figuras
2.1 Ultima atualizacao x Numero de onibus. A imagem mostra que nem todos
os onibus sao atualizados minuto a minuto, como se imaginava a princıpio. 8
2.2 Proporcao de onibus com/sem linha associada. Apesar de serem minoria,
os onibus sem linha informada representam uma fracao relevante do total
de ordens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Elementos que compoem o dicionario Grid. Este dicionario e usado para
dividir a cidade em celulas e guardar os pontos das trajetorias das linhas
de onibus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Elementos que compoem o dicionario dicionario Ordem. Este dicionario
guarda, para cada ordem, informacoes necessarias para a inferencia de sua
linhas, entre elas, uma lista com os ultimos N pontos de sua trajetoria. . . 11
2.5 Elementos que compoem o dicionario dicionario Linha. Este dicionario
armazena as ordens pertencentes a cada linha. . . . . . . . . . . . . . . . . 12
3.1 Diagrama com os modulos do sistema proposto e as dependencias entre eles. 14
3.2 Exemplo de calculo da distancia ordem-linha, onde os pontos em laranja e
azul representam pontos de trajetoria de duas linhas conhecidas e o ponto
rosa e o ponto sob analise em uma rodada. As linhas tracejadas representam
a distancia em linha reta entre a ordem e cada uma das linhas. . . . . . . . 17
3.3 Codigo necessario para subir o servidor web . . . . . . . . . . . . . . . . . 20
4.1 Resultado da estimativa das linhas. Foram analisados os 5 ultimos pon-
tos da trajetoria de cada veıculo, com celulas de tamanhos 1111x1111m2
(imagem da esquerda) e 111x111m2 (imagem da direita). . . . . . . . . . . 23
x
xi
4.2 Resultado da estimativa das linhas. Foram analisados os 10 ultimos pon-
tos da trajetoria de cada veıculo, com celulas de tamanhos 1111x1111m2
(imagem da esquerda) e 111x111m2 (imagem da direita). . . . . . . . . . . 23
4.3 Resultado da estimativa das linhas. Foram analisados os 20 ultimos pon-
tos da trajetoria de cada veıculo, com celulas de tamanhos 1111x1111m2
(imagem da esquerda) e 111x111m2 (imagem da direita). . . . . . . . . . . 24
4.4 Trajetoria da linha 455 (azul) e pontos de ordens cuja linha informada pelo
DataRio era 455, mas que receberam pontuacao zerada para tal linha na
estimativa (vermelho). Os pontos em vermelho foram obtidos no Caso de
Teste 1, com 20 pontos anteriores e celulas de 1111 x 1111m2. . . . . . . . 25
4.5 Trajetoria da linha 422 (azul) e pontos de ordens cuja linha informada pelo
DataRio era tambem a 422, mas que receberam pontuacao zerada para tal
linha na estimativa (vermelho). Diferente da figura anterior, os pontos em
vermelho ficaram concentrados em uma area pequena. Os resultados foram
obtidos em teste realizado no final da tarde do dia 08/07/2017. . . . . . . . 26
4.6 Mesma comparacao da figura 4.5, mas com o teste tendo sido realizado na
parte da manha do dia 10/07/2017. . . . . . . . . . . . . . . . . . . . . . . 27
4.7 Exemplo de exibicao dos dados fornecidos pelos sistema desenvolvido nesta
monografia no Trackbus. Icones de cores iguais representam logs de mesma
linha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Proporcao de ordens classificadas . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Classificacao realizada dos onibus sem linha . . . . . . . . . . . . . . . . . 32
xii
Lista de Tabelas
3.1 Distancia media entre os pontos das trajetorias de linhas, utilizada para
avaliar a viabilidade do tamanho de celula escolhido. . . . . . . . . . . . . 15
4.1 Configuracao do caso de teste elaborado com a finalidade de verificar a
qualidade das estimativas das linhas. Foram feitos testes com diferentes
parametros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Relacao parametros x Porcentagem media de acerto. . . . . . . . . . . . . 24
4.3 Relacao parametros x Porcentagens medias de acerto, com e sem a elimi-
nacao de ordens que tiveram pontuacao zero para a linha correta. . . . . . 28
4.4 Configuracao do sistema no teste de integracao com o sistema TrackBus
proposto em [Rocha e Amaral 2016]. . . . . . . . . . . . . . . . . . . . . . 29
Capıtulo 1
Introducao
A cidade do Rio de Janeiro, uma das mais populosas e movimentadas do paıs, tem
sofrido muito nos ultimos anos com o crescente fluxo de veıculos. Para uma cidade que
lidera os rankings brasileiros de tempo gasto no trajeto ao trabalho e de perdas economicas
por conta do transito [IBGE 2016], e urgente falar sobre dados urbanos e como eles podem
auxiliar a questao da mobilidade.
Diversos avancos tecnologicos recentes tambem colaboram para o desenvolvimento
de novas pesquisas e solucoes na area de analise de dados urbanos [Freire et al. 2014,
Ferreira et al. 2013, Raymond e Imamichi 2016, Wang et al. 2014, Doraiswamy et al. 2014,
Chen, Guo e Wang 2015]. Novos algoritmos e hardwares tem alavancado areas como Inte-
ligencia Artificial e Big Data e resultam em um crescimento exponencial das capacidades
de comunicacao sem fio, armazenamento de dados, oferta de sensores de diversos tipos
e analise de informacoes. Neste novo cenario, e bastante natural pensarmos em solucoes
que agreguem estas novas capacidades para auxiliar na resolucao de problemas enfrentados
pelas grandes cidades.
Ainda, como parte do cumprimento da lei de acesso a informacao1, muitas cidades
passaram a disponibilizar em tempo real informacoes sobre o seu quotidiano. A cidade do
Rio de Janeiro, por exemplo, conta com o portal de dados DataRio2. O DataRio fornece
informacoes nas areas de transporte e mobilidade urbana, entretenimento, educacao, ur-
banismo, esportes, turismo, meio ambiente, saude e etc. Em particular, o DataRio oferece
informacoes em tempo real, atualizadas de minuto em minuto, sobre todos os onibus em
1Lei no 12.527/20112http://data.rio/
1
2
atividade na cidade. Essas informacoes sao mantidas pela FETRANSPOR e contem a
posicao geografica, a velocidade, a linha e um identificador unico de cada onibus.
Apesar dos esforcos realizados pela prefeitura, a qualidade dos dados e muitas
vezes questionada e impacta o desenvolvimento de solucoes inovadoras para auxiliar no
combate ao problema da mobilidade urbana. Uma das principais reclamacoes diz respeito
a informacao da linha associada aos onibus, que muitas vezes nao e informada pela em-
presa responsavel. Trabalhos relacionados [Schettino 2016] sugerem que 68% dos registros
fornecidos pelo DataRio no ano de 2015 contem algum tipo de inconsistencia.
Pensando em minimizar os problemas encontrados mais frequentemente na base de
dados de onibus do DataRio, foi desenvolvido um sistema que atua como intermediario
entre aplicacoes e usuarios consumidores desses dados e o portal DataRio. Em outras
palavras, o objetivo do sistema proposto e corrigir algumas das inconsistencias encontradas
e oferecer dados de melhor qualidade as diversas aplicacoes dependentes da base, muitas
delas sendo mantidas na propria Universidade Federal Fluminense.
1.1 Escopo
Para que o objetivo deste projeto fosse alcancado, era necessario ter acesso nao
apenas a base de dados de onibus do DataRio citada anteriormente, mas tambem as
trajetorias das linhas de onibus em atividade no Rio de Janeiro. O site de dados abertos da
prefeitura do Rio, no entanto, nao mantem informacoes dos trajetos das linhas de onibus.
Sendo assim, utilizamos como insumo para o nosso sistema as estimativas produzidas pelo
trabalho do aluno Daniel Padilha, do grupo de Dados Urbanos do Instituto de Computacao
da UFF [Padilha 2017]. O objetivo desse trabalho e inferir dados operacionais das linhas
de onibus, como a posicao da garagem, os pontos inicial/final e o trajeto usando dados
historicos de GPS.
Outro projeto relacionado ao sistema aqui descrito e o Trackbus, trabalho de con-
clusao de curso descrito em [Rocha e Amaral 2016]. O sistema, tambem desenvolvido por
alunos da Universidade Federal Fluminense permite, entre outras funcionalidades, a exi-
bicao de pontos turısticos, pontos de parada de onibus e a consulta da posicao geografica
dos onibus em atividade na cidade do Rio de Janeiro, em tempo real. O aplicativo em
questao consome os dados do portal DataRio diretamente. Em outras palavras, o sistema
3
nao faz nenhum tratamento ou limpeza nos dados dos onibus fornecidos pelo portal Data-
Rio. Entretanto, como dito anteriormente, a base de dados em questao apresenta diversas
inconsistencias e, por este motivo, a qualidade do servico oferecido pelo aplicativo fica
comprometida. O trabalho aqui proposto foi motivado pela necessidade de se desenvolver
uma aplicacao capaz de reparar inconsistencias da base do DataRio em tempo real para
que a informacao corrigida fosse disponibilizada para aplicacoes como o TrackBus. A
integracao do sistema proposto nesse trabalho e o TrackBus esta descrita na Secao 4.3.
Ainda, e grande o numero de trabalhos que utilizam a base de dados do DataRio,
tendo alguns deles funcionalidades semelhantes as de nosso sistema. Como exemplo, temos
o trabalho [Barbosa et al. 2014], que quantifica o desvio de onibus de suas linhas originais
atraves do calculo de uma pontuacao baseada na distancia entre o veıculo e a trajetoria
de sua linha. A ideia de mostrar desvios espaciais e temporais de um onibus tambem
aparece no trabalho [Bessa et al. 2016], que utiliza redes neurais para exibir veıculos que
possuam inconsistencias em relacao a trajetoria seguida ou ao tempo de percurso, que
pode ser influenciado pelo transito ou pelo proprio desvio a rota original. No entanto,
apesar da proposta parecida, nao e o objetivo de nenhum desses trabalhos inferir a qual
linha pertencem os onibus sem linha informada pelo DataRio.
1.2 Objetivos
Este trabalho descreve um sistema de tempo real capaz de obter, corrigir e dispo-
nibilizar os dados de onibus do DataRio, de minuto em minuto. Tendo em vista que a
existencia de registros de onibus sem linha associada e registros em regioes fora dos limites
da cidade do Rio de Janeiro sao os problemas mais prejudiciais encontrados na base de
dados, o sistema aqui desenvolvido objetiva corrigir esses dois tipos de problemas.
O sistema implementado e composto por quatro modulos, responsaveis pelo car-
regamento de linhas conhecidas, pela obtencao dos dados do DataRio, pela inferencia de
linhas percorridas por cada onibus sem linha informada e a disponibilizacao dos resulta-
dos. Os modulos que compoe o sistema serao descritos no Capıtulo 3. Foram elaborados
os seguintes requisitos para auxiliar o desenvolvimento do sistema:
• O sistema deve ser capaz de inferir, a partir de rotas obtidas previamente, a
qual linha um determinado onibus pertence;
4
• O sistema deve ser capaz de detectar e remover da base de dados registros com
coordenadas geograficas fora dos limites do Rio de Janeiro;
• Os dados devem ser carregados, processados e disponibilizados pelo sistema
dentro do intervalo de um minuto;
• Os dados corrigidos devem ser disponibilizados pelo sistema atraves de uma API
para consulta analoga a do DataRio.
1.3 Organizacao da Monografia
O restante deste trabalho esta dividido em quatro outros capıtulos, totalizando
cinco com a introducao. O Segundo Capıtulo 2 apresenta uma descricao dos dados utili-
zados, alguns problemas encontrados no desenvolvimento do sistema e como se organizam
as estruturas de dados do mesmo. O Terceiro Capıtulo 3 e responsavel por explicar deta-
lhadamente cada modulo do sistema, definindo conceitos utilizados por ele. O Capıtulo 4
concentra a descricao dos resultados obtidos pelos testes realizados, bem como uma breve
conclusao apos cada um deles. A conclusao, com apresentacao das limitacoes, contribui-
coes e reflexoes quanto a trabalhos futuros sao encontrados no Capıtulo 5.
Capıtulo 2
A base dos onibus do Rio de Janeiro
2.1 Descricao
Como dito no Capıtulo 1, o portal DataRio e uma base de dados que disponibiliza
informacoes sobre diferentes aspectos da cidade do Rio de Janeiro, desde a localizacao
dos onibus em circulacao ate dados administrativos, indicadores de frequencia escolar,
entre outros. Sendo assim, o portal e uma fonte rica de informacao para diversos projetos
que visam estudar aspectos urbanos, sociais ou demograficos da cidade. Uma das bases
fornecidas no DataRio, mantida pela FETRANSPOR (Federacao das Empresas de Trans-
portes de Passageiros do Estado do Rio de Janeiro), fornece informacoes como a posicao
geografica, velocidade, linha e identificador unico dos aproximadamente 8000 onibus na
cidade do Rio Janeiro, atualizados minuto a minuto. O acesso a essas informacoes pode
ser feito atraves de uma API HTTP1.
Os dados de onibus sao disponibilizados pelo DataRio em tres formatos; JSON,
CSV e PDF. Para o escopo desse trabalho, foi escolhido o formato CSV pela facilidade
de leitura e escrita das informacoes. No formato CSV disponibilizado pelo portal, as
informacoes sao disponibilizadas de acordo com as colunas abaixo:
• Data/hora: String que representa o instante de tempo em que o registro foi
gerado. As strings sao fornecidas no formato mm-dd-yyyy hh:mm:ss. Um exemplo
de instante de tempo fornecido pelo DataRio e a string 25-02-2017 00:08:01 ;
• Ordem: String contendo o identificador unico de cada onibus. Um exemplo de
Ordem e a string A29004 ;
1http://dadosabertos.rio.rj.gov.br /apiTransporte/apresentacao/csv/onibus.cfm
5
6
• Linha: String contendo o identificador da linha a qual o veıculo esta servindo.
Sao exemplos de linhas de onibus os identificadores 422 e 455-SV ;
• Latitude - Valor numerico representando a distancia em graus ao Equador me-
dida sobre o meridiano de Greenwich. Um exemplo de latitude e o valor -22.868 ;
• Longitude - Valor numerico representando a distancia em graus ao meridiano
de Greenwich medida ao longo do Equador. Um exemplo de longitude e o valor
-43.292 ;
• Velocidade: Valor numerico que representa a velocidade do veıculo no instante
em que foi armazenado do registro.
As requisicoes HTTP realizadas pelo sistema foram implementadas utilizando a
biblioteca urllib do Python, que e capaz de realizar a requisicao e gravar o resultado
dentro de um diretorio local tambem no formato CSV. Um arquivo CSV e baixado pelo
sistema a cada minuto e contem as ultimas informacoes conhecidas de cada veıculo da frota
de onibus da cidade do Rio de Janeiro. De posse do arquivo CSV, o sistema carrega todas
as informacoes (Data/hora, ordem, linha, latitude, longitude e velocidade) em memoria
na forma de uma colecao de dicionarios. A estrutura de dados utilizada para armazenar
os dados obtidos do DataRio sera explicada na Secao 2.4.
2.2 Inconsistencias nos dados
Como foi brevemente mencionado no Capıtulo 1, os dados dos onibus do Rio de
Janeiro, fornecidos pelo portal DataRio, apresentam problemas de diversas naturezas.
Esses problemas, ou inconsistencias, podem limitar ou ate mesmo inviabilizar o desenvol-
vimento de sistemas e/ou algoritmos de analise de dados que utilizam a base de registros
de GPS dos onibus. Um exemplo de aplicativo que sofre das limitacoes impostas pela
base de dados e o TrackBus, descrito em [Rocha e Amaral 2016]. Nesta Secao, listamos
os problemas encontrados de forma mais frequentes na base de dados.
Imprecisao das coordenadas geograficas. Apesar de o DataRio fornecer informacoes
de latitude e longitude com ate seis casas decimais de precisao, o que geraria erros de no
maximo 0.11 metros, em alguns locais da cidade, a precisao da posicao dos registros pode
7
variar bastante. Tal fenomeno se deve a interferencias externas como a presenca de predios
ou montanhas e ma qualidade dos aparelhos utilizados. Este problema e de difıcil solucao,
mas a incerteza gerada pela imprecisao nas coordenadas geograficas dos registros precisa
ser considerada durante a estimativa das linhas proposta nesse trabalho.
Para tratar essa questao, foi implementado um calculo de confiabilidade das esti-
mativas produzidas pelo sistema. Tal mecanismo esta descrito no Capıtulo 3 desse do-
cumento. Vale ressaltar que, mesmo que os GPS retornassem posicoes geograficas 100%
precisas, ainda assim nao seria possıvel estimar a linha de um veıculo com 100% de pre-
cisao. Essa impossibilidade se deve ao fato de varios veıculos compartilharem partes de
sua trajetoria com outros onibus.
Velocidades absurdas. E possıvel encontrar na base de dados veıculos que permane-
cem com velocidade nula por perıodos muito longos ou veıculos com valores de velocidade
muito acima do permitido pela legislacao brasileira. Tal fato e causado por falhas ou
defeitos nos aparelhos de GPS presentes nos veıculos. Como a informacao da velocidade
do veıculo nao e fundamental para a estimativa das linhas servidas por cada veıculo, tais
inconsistencias nao foram tratadas nesse trabalho.
Registro no mar, rios ou lagoas. Devido a falhas do GPS dos onibus e/ou a im-
precisao das coordenadas geograficas, alguns registros sao feitos em areas ocupadas por
rios, lagoas ou pelo mar. Como esses registros nao podem ser associados ao trajeto de ne-
nhuma linha, definimos uma estrategia para eliminar estas informacoes da base de dados.
A Secao 2.3 desse documento descreve com mais detalhes o procedimento adotado.
Indisponibilidade do DataRio. Como observado no trabalho [Rocha e Amaral 2016],
percebemos durante a execucao deste projeto que o DataRio sofre frequentemente de pro-
blemas de instabilidade de acesso. Sendo assim, seria interessante fornecer uma alter-
nativa capaz de minimizar falhas pontuais de comunicacao. De fato, o sistema proposto
neste trabalho poderia substituir o DataRio temporariamente para evitar que servicos que
dependam dos dados fornecidos pelo portal fiquem fora do ar. Indisponibilidades mais
severas, como queda do portal por longos perıodos, sao impossıveis de se resolver ja que
o portal e a fonte primaria dos dados em questao.
8
Taxa de atualizacao. Em teoria, a base de dados dos onibus fornecida pelo DataRio
deveria ser atualizada a cada minuto. Contudo, muitos veıculos passam horas sem sequer
uma atualizacao. Como exemplo, podemos citar a Figura 2.1, que representa uma amostra
capturada as 18h do dia 18/06/2017, onde 27% dos 5566 registros haviam sido gravados
antes do meio-dia. De fato, o DataRio fornece, a cada minuto, o ultimo registro conhecido
de cada veıculo da frota de onibus da cidade do Rio de Janeiro.
Figura 2.1: Ultima atualizacao x Numero de onibus. A imagem mostra que nem todos os
onibus sao atualizados minuto a minuto, como se imaginava a princıpio.
Ordens sem linha. Razao motivadora da implementacao desse sistema, alguns onibus
nao vem associadas a linha alguma nos arquivos disponibilizados pelo DataRio. Como
ilustra a figura 2.2, a ocorrencia desse fenomeno e de aproximadamente 7% e impacta os
sistemas dependentes da completude dos dados. Tal porcentagem fora retirada de uma
analise feita em uma amostra de 6653 ordens retirada do proprio DataRio em dezembro
de 2016 na parte da manha.
2.3 Filtragem dos dados
Apesar de ser importante que se consiga oferecer o melhor servico possıvel (isto e,
com o maior numero de registros) para as aplicacoes interessadas em consumir os dados
de onibus do Rio de Janeiro tratados pelo nosso sistema, alguns registros com informacoes
9
Figura 2.2: Proporcao de onibus com/sem linha associada. Apesar de serem minoria, os
onibus sem linha informada representam uma fracao relevante do total de ordens.
inconsistentes e que nao sao tratadas pelo nosso sistema precisam ser descartados. Sendo
assim, registros que nao atendam aos criterios de qualidade impostos pelo sistema sao
ignorados pelo programa, nao havendo nem mesmo a gravacao dos mesmos em diretorios
separados. Portanto, caso algum sistema externo queira utilizar os arquivos gravados por
esse programa, deve considerar a possıvel perda de informacoes. Nesta Secao descrevere-
mos os filtros utilizados em nosso sistema.
Filtro de formato inconsistente. Caso algum registro seja disponibilizado em um
formato fora do padrao estabelecido pelo portal DataRio e descrito no inıcio deste Ca-
pıtulo, o mesmo sera desconsiderado. Durante os nossos testes, nao houve registros da
ocorrencia de tais eventos. Ainda assim, o filtro foi adicionado para garantir a robustez e
a nao interrupcao do sistema.
Filtro por data. Como o Data Rio disponibiliza os dados de forma instantanea (ou
seja, sempre fornece as ultimas informacoes disponibilizadas por um onibus, independente
de seu GPS estar ativo e logando ou nao), e necessario armazenar, para cada ordem, a
data e hora de sua ultima atualizacao. Caso o sistema receba um registro com data igual
a ultima data armazenada, esse e desconsiderado. Dessa forma, nao sao armazenadas
informacoes repetidas na base.
10
Filtro por duplicidade. Caso as informacoes de latitude e longitude se repitam em
sequencia, ou seja, dois registros consecutivos possuam a mesma localizacao geografica, o
registro tambem e rejeitado, evitando que estimativas sejam feitas para onibus que nao
estao em movimento.
Filtro por registros em rios, lagoas e no mar. Como e impossıvel que um onibus
circule sobre agua, qualquer registro sobre o mar, rios ou lagoas deve ser desconsiderado.
Para filtrar esses registros, utilizamos as informacoes geograficas dos limites do municıpio
do Rio de Janeiro2 e testamos se os registros obtidos do DataRio pertencem ao interior do
polıgono, utilizando um algoritmo de classificacao ponto conjunto como o winding number.
O algoritmo e implementado por bibliotecas como a Shapely.
2.4 Estruturacao dos dados
A estrutura de dados utilizada para armazenar e manipular os dados obtidos do
portal DataRio em nossa aplicacao e uma colecao de dicionarios. Dicionarios sao estrutu-
ras de dados eficientes, ja que sao tipicamente implementadas atraves de tabelas hash, e
simples de usar. Estas caracterısticas fazem com que o carregamento, atualizacao e ma-
nipulacao dos dados de GPS de onibus usando dicionarios seja intuitiva e apresente boa
performance, dentro das restricoes temporais impostas pela taxa de atualizacao dos dados
do DataRio. As estruturas de dicionarios utilizados em nossa aplicacao para representar
e manipular os dados obtidos do DataRio serao descritos no restante desta Secao.
Grid. E responsavel por armazenar as rotas das linhas conhecidas estimadas e fornecidas
por [Padilha 2017]. Este dicionario e preenchido na inicializacao do sistema e consultado
pelo algoritmo responsavel por estimar a qual linha pertence um registro. Cada item do
dicionario representa uma celula de um grid que cobre toda a cidade do Rio de Janeiro.
A chave de cada celula e a string lat,lng onde lat e lng sao, respectivamente, os valores da
latitude e da longitude truncados na terceira casa decimal, como explicado na secao 3.2.
Sendo assim cada celula grid [“lat,lng”] = <lista–pontos> armazena a lista de pontos das
trajetorias conhecidas que estao contidos na regiao espacial representada pela celula do
grid. A Figura 2.3 mostra a relacao entre os elementos que compoem o dicionario.
2https://goo.gl/9QNtwD
11
Figura 2.3: Elementos que compoem o dicionario Grid. Este dicionario e usado para
dividir a cidade em celulas e guardar os pontos das trajetorias das linhas de onibus.
Figura 2.4: Elementos que compoem o dicionario dicionario Ordem. Este dicionario
guarda, para cada ordem, informacoes necessarias para a inferencia de sua linhas, entre
elas, uma lista com os ultimos N pontos de sua trajetoria.
Ordem. E responsavel por armazenar as informacoes de cada veıculo fornecidas pelo
DataRio. Este dicionario e atualizado minuto a minuto de modo que, para cada ordem,
haja o historico completo dos N ultimos registros disponıveis. Neste dicionario tambem
e armazenado se a linha relativa a uma determinada ordem foi informada pelo DataRio
ou inferida pelo sistema. Tal distincao e necessaria pois o sistema tenta descobrir a
linha apenas de ordens que tenham originalmente sido recebidas sem essa informacao.
Em outras palavras, mesmo que uma ordem tenha sua linha inferida, e desejavel que ela
continue sendo avaliada em proximos ciclos de processamento. Os elementos que compoem
o dicionario Ordem podem ser observados na Figura 2.4.
12
Figura 2.5: Elementos que compoem o dicionario dicionario Linha. Este dicionario arma-
zena as ordens pertencentes a cada linha.
Linha. E responsavel por armazenar quais ordens estao associadas a uma determinada
linha. Durante a atualizacao dessa estrutura, e preciso evitar que uma ordem seja associ-
ada a mais de uma linha em um mesmo instante. Isto pode acontecer quando o algoritmo
que estima a linha a qual pertence uma ordem corrige a estimativa com o passar das ite-
racoes. Sendo assim, e necessario garantir que, para cada atualizacao da linha a qual uma
ordem pertence, haja a desassociacao a linha anterior, que fora substituıda. Os elementos
que compoem o dicionario Linha podem ser vistos na figura 2.5.
Como os modulos do sistema sao executados atraves de threads independentes e um
dicionario nao pode ser acessado e modificado ao mesmo tempo, foi necessario adicionar
um lock para lidar com as questoes de concorrencia. O uso do lock e feito de modo
que, toda vez que uma operacao de leitura ou escrita esta prestes a ser realizada em um
dicionario, o lock seja adquirido e liberado apos a realizacao da operacao.
Capıtulo 3
Sistema Proposto
A proposta desta monografia e o desenvolvimento de um sistema capaz de, a partir
dos registros de GPS dos onibus que compoem a frota e das rotas das linhas de onibus,
inferir a qual linha pertence cada veıculo em operacao na cidade do Rio de Janeiro.
Sendo assim, um subproduto do sistema proposto e o enriquecimento dos dados fornecidos
pelo DataRio. Como descrito nos capıtulos anteriores, a informacao da linha servida
pelos veıculos em operacao no Rio de Janeiro esta frequentemente indisponıvel na base
de dados originalmente disponibilizada pelo portal. Portanto, a oferta de um sistema
capaz de estimar essa informacao e usar esta estimativa para enriquecer os registros da
base de dados original e uma grande colaboracao para todos interessados em desenvolver
tecnologias baseadas nos registros de GPS dos onibus do Rio de Janeiro.
Neste capıtulo, vamos apresentar os modulos que compoem o sistema proposto.
Uma visao geral desses modulos e da dependencia entre eles pode ser vista na Figura 3.1.
3.1 Modulo de carregamento de linhas
Executado uma vez, na inicializacao do sistema, o modulo de carregamento de
linhas consiste em, a partir de arquivos previamente obtidos, carregar para o dicionario
Grid (apresentado no Capıtulo 2) os pontos das trajetorias que compoem as linhas da
cidade do Rio de Janeiro. Tais linhas foram obtidas utilizando o trabalho de mestrado
[Padilha 2017], como dito na Secao 1.1. As sete linhas que estavam disponıveis e foram
utilizadas pelo sistema sao a 422, 298, 864, 326, 455, 778, 908. Para cada uma das sete
linhas citadas, o trabalho de [Padilha 2017] fornece um trajeto de ida e um trajeto de
13
14
Figura 3.1: Diagrama com os modulos do sistema proposto e as dependencias entre eles.
volta. Sendo assim, o sistema aqui proposto e capaz de informar nao apenas a qual
linha pertence um veıculo, mas tambem qual a direcao percorrida por cada onibus em
operacao. Contudo, e importante ressaltar que o funcionamento do modulo nao esta
atrelado as linhas aqui citadas, podendo quaisquer outras trajetorias serem utilizadas.
A estrategia utilizada para otimizar o acesso das linhas conhecidas foi a utilizacao
do dicionario Grid com celulas de aproximadamente 111m x 111m. A escolha de tamanho
da celula foi feita de forma que a area ocupada pelas mesmas fosse suficientemente abran-
gente (de aproximadamente um quarteirao), mas que nao tornasse excessiva a quantidade
de pontos de trajetoria em cada celula do grid. De fato, o custo computacional do algo-
ritmo de estimativa de linhas e funcao do numero registros analisados a cada iteracao e
dos pontos de rotas conhecidas por celula do grid.
15
Linha Distancia
326(ida) 112,01
864(ida) 45,87
864(volta) 45,93
298 99,56
Tabela 3.1: Distancia media entre os pontos das trajetorias de linhas, utilizada para
avaliar a viabilidade do tamanho de celula escolhido.
Para definir o valor otimo do tamanho de celula, tambem foi analisada a distancia
media entre os pontos das trajetorias de algumas linhas conhecidas. O resultado, que
pode ser observado na tabela 3.1, mostra que, utilizando celulas de tamanho 111m x
111m, ha uma grande probabilidade de que exista ao menos um ponto da trajetoria do
onibus em cada celula. Por esse motivo, e facil observar que a escolha do tamanho da
celula influencia diretamente na qualidade da estimativa de linha realizada pelo sistema.
Para garantir que a parametrizacao do modulo seja definida de forma consistente, um
caso de teste analisando os resultados de diferentes configuracoes foi adicionado a Secao
4.1.
Outro fator que influenciou a escolha do tamanho de celula foi a conveniencia de ser
possıvel acessar os dados de uma celula apenas truncando seus valores de latitude e longi-
tude na terceira casa decimal e os utilizando como chave de acesso ao grid. Por exemplo,
se o modulo de inferencia de linhas deseja obter todas as linhas que passam pela mesma
celula onde se encontra o ponto (22.246421,-44.543211), bastaria apenas acessar o dicio-
nario Grid passando a string “22.246,-44.543” como chave, pois o modulo de carregamento
das linhas conhecidas utiliza a mesma estrategia para construir o dicionario.
Como o modulo de carregamento e executado durante a inicializacao do sistema,
nao ha quaisquer requisitos mais rıgidos referentes a sua performance.
3.2 Modulo de acesso aos dados do Data Rio
Nesse modulo, sao realizadas as requisicoes HTTP para o portal de dados DataRio
e a carga das informacoes no dicionario Ordem, descrito na secao 2.1. E crucial que,
dentro de sessenta segundos (perıodo estabelecido para que seja feita uma nova requisicao
ao DataRio), a carga dos dados seja completa. Se essa condicao nao for atendida, havera
16
perda de informacoes. Mesmo a carga de dados levando em media 1.6 segundos, valor
bem inferior ao limite estabelecido, o sistema monitora o tempo de execucao do modulo
e alerta o usuario caso o limite de tempo seja excedido.
3.3 Modulo de inferencia de linhas
Crucial ao sistema, o modulo de inferencia e responsavel por tentar associar regis-
tros inicialmente sem linha (ou de linha anteriormente inferida pela aplicacao) a uma das
linhas inseridas no sistema pelo modulo de carregamento de linhas. Sao avaliadas apenas
ordens que possuam ao menos cinco (valor parametrizavel, denotado por N) registros ja
conhecidos, que servirao de referencia, e cuja linha associada nao tenha sido informada
pelo DataRio. A fim de obter o melhor parametro para o numero de registros conhecidos
a serem analisados, foi adicionado um caso de teste focado nessa questao a Secao 4.1.
A razao pela qual o sistema recalcula linhas de uma ordem ja inferidas anterior-
mente e a possibilidade de um veıculo alterar sua trajetoria durante o servico, fato que
precisa ser diagnosticado pelo modulo. Como exemplo, e possıvel citar um onibus sem
linha informada que fazia a rota do 512 e, apos algum tempo, passou a fazer a rota do 513.
Inicialmente, o sistema ira responder que o onibus pertence a linha 512, mas e necessario
que essa informacao seja constantemente recalculada em iteracoes posteriores para que
essa mudanca de trajetoria seja percebida o mais rapido possıvel.
A seguir, descreveremos os conceitos utilizados na implementacao dos Algoritmos
1 e 2 responsaveis pela estimativa das rotas dos onibus em operacao.
Esquema de pontuacao. Suponha que sejam utilizados cinco pontos conhecidos da
trajetoria de uma ordem para que sua linha seja inferida. A analise de cada um destes
cinco pontos constitui o que chamamos de rodada e o resultado retornado pelo modulo
e composto pela agregacao das pontuacoes recebidas pelas linhas candidatas em cada
rodada. Sendo assim, cada linha candidata recebe, ao final do processamento do mo-
dulo, uma pontuacao que pode ser enxergada como sendo um ındice de confiabilidade do
resultado. A linha com maior pontuacao e associada a ordem analisada.
A soma das pontuacoes de todas as linhas e necessariamente um valor predetermi-
nado, chamado de Pontuacao Maxima e denotado por PM , normalmente o de cem pontos.
Esse valor e distribuıdo igualmente entre cada rodada. Essa distribuicao e chamada de
17
Pontuacao da Rodada e denotada por Pr, que pode ser compreendida como o total de
pontos distribuıdo entre as linhas candidatas a cada rodada. O calculo da Pontuacao da
Rodada e dado pela formula abaixo:
Pr =PM
N(3.1)
A quantidade de pontos atribuıda a cada linha candidata depende da distancia
entre o ponto em analise e as rotas que passam pela celula do dicionario Grid que contem
o registro. O criterio de distribuicao sera descrito nos proximos paragrafos. E importante
observar que, devido ao baixo numero de linhas conhecidas pelo sistema, muitas vezes
as ordens analisadas nao compartilham celulas com linha alguma. Por conta disso, foi
introduzido ao sistema o conceito de linha vazia, que pode ser vista como o conjunto de
linhas nao cadastradas ou inexistentes. A linha vazia recebe pontuacao toda vez que nao
for possıvel atribuir pontos a alguma linha conhecida pelo sistema durante uma rodada.
Distribuicao da pontuacao. Durante sua execucao, o modulo recebe os N ultimos
pontos por onde uma determinada ordem passou e os analisa individualmente. Para cada
ponto recebido, sao obtidas todas as linhas candidatas atraves do acesso a celula onde se
encontra o ponto. Uma linha e considerada candidata quando ao menos um ponto de sua
trajetoria se encontra na mesma celula em que o ponto sob analise em uma rodada.
Figura 3.2: Exemplo de calculo da distancia ordem-linha, onde os pontos em laranja e
azul representam pontos de trajetoria de duas linhas conhecidas e o ponto rosa e o ponto
sob analise em uma rodada. As linhas tracejadas representam a distancia em linha reta
entre a ordem e cada uma das linhas.
18
O passo executado na sequencia e o calculo da distancia entre o registro atual e cada
linha candidata, denotada por l. Para calcular essa distancia utilizamos as coordenadas
do registro p analisado na rodada e um ou mais pontos que compoem a rota da linha l.
Caso haja apenas um ponto de l presente na celula do dicionario Grid que contem p, sera
realizado o calculo simples de distancia ponto a ponto. Caso l possua mais de um ponto de
sua trajetoria dentro da celula em questao, serao tracados um ou mais segmentos de reta
s que conectem os pontos de trajetoria (como na trajetoria laranja no exemplo ilustrado
pela Figura 3.2). No caso de haver apenas um segmento resultante, a distancia entre a
ordem e a linha sera a distancia entre este segmento e o registro p. Caso haja mais de um
segmento de reta, sera calculada a distancia entre p e cada um dos segmentos produzidos,
sendo a resposta a menor distancia encontrada. E importante frisar que, como a trajetoria
das linhas conhecidas tem seus pontos ordenados temporalmente, os segmentos de reta
tracados devem respeitar essa ordenacao de modo que somente pontos consecutivos sejam
associados.
Algorithm 1 Inferencia de Linhas
1: function Infere(lista–pontos, PM) . lista–pontos : N ultimos pontos de uma ordem
2: for i = 0 to N do
3: scores–rodada = calcula–pontuacao(lista–pontos [i], Pr)
4: scores–linhas.push(scores–rodada)
5: end for
6: soma–total = consolida(score–linhas)
7: for l in soma–total do
8: soma–total[l] = soma–total[l] / PM
9: end for
10: return linha de maior pontuacao
11: end function
As distancias calculadas sao, entao, armazenados temporariamente atraves de uma
relacao (l,d), sendo d a distancia entre o registro p e a linha l. A partir dessa relacao, a
pontuacao da rodada Pr e distribuıda entre as linhas candidatas de modo que as linhas
mais proximas ao ponto recebam proporcionalmente maior pontuacao do que as linhas
de maior distancia, sendo esse calculo feito considerando a soma s de todas as distancias
ordem-linha da rodada. Caso nao haja linha candidata, a pontuacao completa da rodada
19
Algorithm 2 Calculo das pontuacoes em uma rodada
1: function calcula–pontuacao(p, Pr)
2: linhas–candidatas = linhas contidas na mesma celula de p
3: soma = 0
4: for l in linhas–candidatas do
5: distancia–linha[l] = distancia(l, p)
6: soma += distancia–linha[l]
7: end for
8: score–linha[l] = (1− distancia–linha[l] / soma) * Pr
9: return score–linha
10: end function
e dada a linha vazia. A formula da distribuicao de pontuacao entre as linhas candidatas,
caso haja mais de uma, e a seguinte:
scoreLinha[l] = (1 − distanciaLinha[l]
s) ∗ Pr (3.2)
Um dos requisitos do sistema e que ele retorne apenas uma linha como resposta
para cada ordem. Sendo assim, sera escolhida a linha de maior pontuacao ao final das N
rodadas, desde que nao seja a linha vazia. Essa sera considerada apenas caso nenhuma
outra linha possua pontuacao diferente de zero.
Para o sucesso da execucao do sistema, e necessario que, a cada minuto, todas
as ordens que nao tenham linha informada pelo DataRio sejam avaliadas ou reavaliadas.
Assim, o sistema monitora constantemente a execucao do modulo e alerta o usuario caso
o valor tempo limite de sessenta segundos seja ultrapassado sem que todas as ordens sem
linha tenham sido analisadas. Durante os testes da versao final do sistema, esse valor
nunca foi excedido.
3.4 Disponibilizacao dos resultados
Para disponibilizar os dados para usuarios externos, foi implementado um servidor
capaz de produzir um arquivo JSON no mesmo formato utilizado pelo DataRio, enrique-
cido com as informacoes de rotas estimadas pelo sistema, permitindo que usuarios que
atualmente obtem informacoes dessa fonte possam migrar para esse sistema sem maior
20
esforco, apenas alterando a url consultada.
Para isso, foi necessario utilizar a biblioteca web do Python, que permite a criacao
de um servidor web capaz de tratar requisicoes HTTP. Como a biblioteca ja implementa
e pre-configura uma razoavel gama de funcionalidades, o trabalho de disponibilizar as
informacoes computadas pelo sistema se resume a adequacao ao formato JSON. A Figura
3.3 apresenta o codigo necessario para instanciar o servidor.
Figura 3.3: Codigo necessario para subir o servidor web
Quando o usuario acessa o endereco https://<ip>/linhas, lhe e retornado uma
fotografia dos ultimos registros de cada ordem presente no sistema, de modo semelhante
ao realizado pelo DataRio, com a diferenca da adicao de filtros e das linhas inferidas.
Para atender tal requisicao, o sistema acessa o dicionario Ordens, faz um percorrimento
completo da estrutura adicionando a variavel de retorno cada registro encontrado. Apos
o percorrimento, o retorno e colocado no formato JSON e repassado ao usuario.
Caso a url https://<ip>/linha/<l>, onde l e uma linha de onibus da cidade, seja
acessada, o sistema buscara todas as ordens que atualmente possuam essa linha associada
e retornara ao usuario as informacoes no mesmo formato JSON ja descrito. Para realizar
essa consulta, primeiro e acessado o dicionario Linha passando l como chave, o que retorna
como resultado todas as ordens associadas a l. Essas linhas sao entao adicionadas a uma
variavel temporaria de retorno. Em seguida, como o dicionario Linha apenas possui o
numero das ordens, e necessario consultar o restante das informacoes, entre elas a ultima
posicao geografica registrada. Esse complemento das informacoes e feito atraves do acesso
do dicionario Ordem, passando como chave cada uma das ordens. Conforme os dados
vao sendo obtidos, a variavel de retorno vai sendo atualizada. Tendo obtido todas as
informacoes necessarias, resta ao sistema apenas formata-las e retornar a requisicao.
Capıtulo 4
Estudo de Caso
Para avaliar a qualidade das estimativas de linhas produzidas pelo sistema e testar
o atendimento aos requisitos estabelecidos na Secao 1.2, foi realizada uma serie de testes.
Nesse capıtulo, serao descritos os resultados obtidos em tres casos de uso, responsaveis
por analisar pontos diferentes do projeto.
4.1 Precisao da estimativa das rotas
A ideia desse primeiro teste consiste em selecionar ordens cujas linhas tenham
sido informadas pelo DataRio - ou seja, ja conhecidas de antemao - e solicitar que o
sistema estime a quais linhas os veıculos estao servindo, baseado nas rotas produzidas pelo
trabalho [Padilha 2017]. Tal proposta e interessante pois permite avaliar a confiabilidade
da estimativa produzida pelo sistema. Quanto maior for o ındice de acertos em relacao ao
valor informado pelo DataRio, mais confiavel e o calculo realizado e mais util e o servico
oferecido pela aplicacao proposta nesse trabalho.
Esse teste tambem nos permite analisar qual a sensibilidade do metodo em relacao
aos parametros de tamanho de celula e de numero de pontos a serem analisados. Dessa
forma, o mesmo teste foi executado com parametros diferentes, para que fosse possıvel
julgar qual configuracao funciona melhor para a aplicacao.
Para obtermos resultados consistentes, todas as execucoes desse caso de teste fo-
ram iniciadas as 10:00 do dia 10/07/2017 e encerradas as 12:00 do mesmo dia. Como o
objetivo era observar o ındice medio de acertos das estimativas, a duracao de duas horas
foi suficiente para obter uma amostragem satisfatoria para a analise, processando uma
21
22
media de 3000 veıculos por linha. Assim, os parametros de configuracao usados neste
teste podem ser vistos na Tabela 4.1.
Atributo V alor
Numero de pontos analisados 5,10 e 20
Tamanho de cada celula 1111x1111m2 e 111x111m2
Considerar trajetorias de ida e volta False
Retornar mais de uma possibilidade False
Tabela 4.1: Configuracao do caso de teste elaborado com a finalidade de verificar a qua-
lidade das estimativas das linhas. Foram feitos testes com diferentes parametros.
Para que a execucao do teste fosse possıvel, foi necessario fazer uma alteracao
no programa de modo que o modulo de inferencia de linhas recebesse, alem dos pontos
de trajetoria da ordem, a informacao de linha informada pelo DataRio. Assim, caso a
linha informada fosse uma das linhas conhecidas pelo sistema, ele armazenaria o resultado
obtido pelo modulo, gravando em um arquivo com a pontuacao obtida pela linha e um
indicador de sucesso da estimativa (ou seja, armazena se o sistema foi capaz ou nao de
acertar a inferencia da linha).
4.1.1 Resultados obtidos
No fim da execucao dos testes, os dados armazenados foram agrupados e o resultado
pode ser observado nos graficos das Figuras 4.1, 4.2 e 4.3 comparando as porcentagens de
acerto da estimativa para cada linha conhecida.
Na Figura 4.1, apresentamos os resultados obtidos utilizando os parametros de 5
pontos anteriores de trajetoria e tamanho de celula como sendo 1111x1111m2 e 111x111m2.
Observamos que ındice de acerto foi superior a 75% para as linhas 326, 778 e 908 em am-
bos os casos. Contudo, para as linhas 455 e 864, os resultados mostram um baixo ındice
de acerto com celulas menores. Analisando os dados, percebemos que, com o aumento
da celula, a acuracia media aumenta. No entanto, linhas como a 422 e a 326 tiveram seu
ındice de acerto diminuıdo com essa alteracao.
Fenomeno semelhante pode ser observado na Figura 4.2, onde sao utilizados os
parametros de 10 pontos anteriores e celulas de 1111x1111m2 e 111x111m2. Como espe-
ravamos, o ındice geral de acerto tambem subiu com o aumento do tamanho da celula,
23
Figura 4.1: Resultado da estimativa das linhas. Foram analisados os 5 ultimos pontos da
trajetoria de cada veıculo, com celulas de tamanhos 1111x1111m2 (imagem da esquerda)
e 111x111m2 (imagem da direita).
mas as linhas 422 e 326 nao acompanharam a tendencia e novamente perderam acuracia
com celulas maiores.
A Figura 4.3, que representa os ındices de acerto com parametros de 20 pontos
anteriores e celulas de 1111x1111m2 e 111x111m2 confirma o crescimento no ındice de
acuracia com o aumento de celula. No entanto, ao compararmos os graficos presentes nas
3 figuras, e possıvel observar que, conforme o numero de pontos analisados aumenta, menor
e o ganho em precisao que se tem ao aumentar a area coberta pela celula. Tal observacao
pode ser confirmada observando a Tabela 4.2, que permite uma analise quantitativa dos
resultados.
Como a analise visual dos graficos nem sempre possibilita uma avaliacao quanti-
tativa dos valores exibidos, para definir o conjunto de parametros com melhor resultado
no teste, foi calculada a media entre as porcentagens de acerto para cada um deles. O
resultado pode ser observado na tabela 4.2, onde e possıvel perceber uma melhora na
Figura 4.2: Resultado da estimativa das linhas. Foram analisados os 10 ultimos pontos da
trajetoria de cada veıculo, com celulas de tamanhos 1111x1111m2 (imagem da esquerda)
e 111x111m2 (imagem da direita).
24
Figura 4.3: Resultado da estimativa das linhas. Foram analisados os 20 ultimos pontos da
trajetoria de cada veıculo, com celulas de tamanhos 1111x1111m2 (imagem da esquerda)
e 111x111m2 (imagem da direita).
acuracia da estimativa conforme o numero de pontos analisados e o tamanho de celula
aumentam. O resultado era esperado no sentido em que os dois parametros influenciam
diretamente na quantidade de informacao passada ao modulo de inferencia de linhas. Em
outras palavras, com o aumento do numero de pontos de trajetoria analisados e do ta-
manho de celula, mais insumos sao passados ao modulo de inferencia e consequentemente
melhor e a qualidade do resultado. E importante frisar que o aumento desses parametros
acarreta em um maior consumo de recursos de memoria e processamento, devendo assim
seu ajuste ser feito com cautela.
Numero de pontos Tamanho de Celula Porcentagem media de acerto
5 111x111m2 72.72%
5 1111x1111m2 81.37%
10 111x111m2 78.21%
10 1111x1111m2 83.54%
20 111x111m2 83.96%
20 1111x1111m2 87.82%
Tabela 4.2: Relacao parametros x Porcentagem media de acerto.
Assim, e possıvel concluir que a eficacia do modulo de inferencia de linhas esta
diretamente atrelada aos parametros passados a ele. No entanto, em todas as combinacoes
de parametros utilizadas, foram obtidos ındices de acerto medio acima de 70%. Para que
essa metrica possa ser melhorada, um proximo passo e buscar entender que fatores alem
da parametrizacao influenciam a porcentagem de acertos.
25
4.2 Origem dos erros
O segundo caso de teste surgiu como uma tentativa de entender os motivos pe-
los quais algumas estimativas de linha do caso de teste apresentado na secao anterior
apresentaram baixa precisao. Isto e, apesar de a precisao geral da estimativa ser relati-
vamente satisfatoria, seria interessante descobrir as razoes que a fizeram ser mais baixa
para algumas linhas para entender se a estimativa poderia ser melhorada.
Um acontecimento que chamou a atencao durante o primeiro caso de teste foi a
presenca de pontuacoes zeradas atribuıdas a linha conhecida em algumas estimativas.
De acordo com o nosso algoritmo, neste caso, nenhum dos N ultimos pontos conhecidos
da ordem em questao compartilhou celula do dicionario Grid com pontos da trajetoria
correta. Esse evento e altamente improvavel, mas aconteceu com certa frequencia durante
as analises. Para entender o problema, decidimos gerar uma visualizacao dos pontos das
rotas e dos registros desses onibus.
Figura 4.4: Trajetoria da linha 455 (azul) e pontos de ordens cuja linha informada pelo
DataRio era 455, mas que receberam pontuacao zerada para tal linha na estimativa (ver-
melho). Os pontos em vermelho foram obtidos no Caso de Teste 1, com 20 pontos ante-
riores e celulas de 1111 x 1111m2.
Observe a Figura 4.4, que compara pontos da rota da linha 455 (em azul) com
pontos de trajetoria de ordens cuja linha informada pelo DataRio era a propria 455 (em
vermelho). Em relacao aos testes realizados, o que difere os pontos em vermelho dos
outros registros analisados para esta rota e que a pontuacao final da linha 455 atribuıda
26
a eles foi zero. Isso indica que ha alguma inconsistencia no teste realizado ou no dado
fornecido pelo DataRio. A Figura deixa claro que as ordens, representadas pelos pontos
em vermelho, nao seguem a rota da linha informada pelo portal.
A primeira hipotese que justificaria tal fato e a de que a trajetoria oficial da linha
455 tenha mudado recentemente. Como as rotas de linhas conhecidas foram calculadas
utilizando dados de 2016 e essa analise foi realizada em 2017, ano de profundas alteracoes
nas linhas do Rio de Janeiro, e possıvel que as linhas utilizadas por nosso sistema tambem
tenham passado por mudancas. Contudo, de acordo com site [Onilinhas - Itinerarios], a
linha 455 permanece com a mesma trajetoria aqui utilizada. Nao e descartada a hipotese
de o site em questao tambem estar desatualizado.
Figura 4.5: Trajetoria da linha 422 (azul) e pontos de ordens cuja linha informada pelo
DataRio era tambem a 422, mas que receberam pontuacao zerada para tal linha na estima-
tiva (vermelho). Diferente da figura anterior, os pontos em vermelho ficaram concentrados
em uma area pequena. Os resultados foram obtidos em teste realizado no final da tarde
do dia 08/07/2017.
Uma outra possibilidade que pode ter gerado o que vimos na figura 4.4 esta re-
lacionada ao fato de o modulo de inferencia de linhas sempre considerar a ultima linha
informada de uma ordem. Assim, caso uma ordem tivesse sua trajetoria alterada, ela
ainda assim carregaria consigo no dicionario Ordem os N - 1 pontos da trajetoria ante-
rior, que seriam considerados na estimativa. No entanto, tal evento nao deveria acontecer
27
com tanta frequencia em um perıodo de duas horas, duracao do primeiro teste realizado.
Tambem e plausıvel supor que o DataRio tenha fornecido informacoes incorretas,
informando uma linha quando na verdade a ordem pertence a outra, ou que os veıculos
tenham sido forcados, por algum motivo, a alterar sua trajetoria no perıodo do teste. A
realizacao de obras na cidade ou questoes de seguranca podem ter motivado tais desvios.
Figura 4.6: Mesma comparacao da figura 4.5, mas com o teste tendo sido realizado na
parte da manha do dia 10/07/2017.
Comparando os resultados das figuras 4.5 e 4.6, onde os pontos em vermelho tam-
bem representam a trajetoria de ordens cuja linha informada pelo DataRio nao obteve
pontuacao durante os testes, e possıvel formular mais uma teoria que explique o fenomeno.
Na figura 4.5, representacao de um teste realizado no final da tarde, e possıvel perceber
claramente que os pontos vermelhos estao concentrados em uma regiao, que poderia ser de
garagem. A tese e reforcada pela figura 4.6, visualizacao do mesmo teste, mas realizado
pela manha, onde ainda se podem ver muitos pontos concentrados na mesma possıvel
regiao de garagem, mas com outros pontos formando um percurso que liga a garagem a
verdadeira trajetoria da linha.
De fato, nao e possıvel afirmar com certeza o que causou o desvio de algumas ordens
em relacao a sua linha informada. No entanto, tal analise e importante para entender os
motivos que influenciam a acuracia das estimativas realizadas por nosso sistema. Caso
esses pontos de desvio (onde a pontuacao final da linha informada foi igual a zero) fossem
removidos, a acuracia do sistema melhoraria bastante. Isso e observado na tabela 4.3.
28
Numero de pontos Tamanho de Celula Acerto Acerto (sem pontuacoes zeradas)
5 111x111m2 72.72% 86.29%
5 1111x1111m2 81.37% 86.94%
10 111x111m2 78.21% 87.50%
10 1111x1111m2 83.54% 89.15%
20 111x111m2 83.96% 90.71%
20 1111x1111m2 87.82% 93.52%
Tabela 4.3: Relacao parametros x Porcentagens medias de acerto, com e sem a eliminacao
de ordens que tiveram pontuacao zero para a linha correta.
4.3 Integracao com outros sistemas
Diferente dos outros, esse caso de teste objetiva verificar a capacidade de integra-
cao desse sistema com outros. Para isso, foi selecionado o aplicativo Trackbus, descrito
no trabalho [Rocha e Amaral 2016]. Como uma das funcionalidades do aplicativo e justa-
mente exibir, em tempo real, posicoes e linhas de onibus cujas informacoes sao oferecidas
pelo DataRio, o teste pode ser feito apenas realizando alteracoes pontuais no codigo fonte
do aplicativo. A Figura 4.7 mostra uma tela do aplicativo TrackBus, que exibe dados
fornecidos pelo sistema proposto nessa monografia.
Figura 4.7: Exemplo de exibicao dos dados fornecidos pelos sistema desenvolvido nesta
monografia no Trackbus. Icones de cores iguais representam logs de mesma linha.
Tendo em vista que o foco do teste era analisar a comunicacao entre as duas
aplicacoes, os parametros utilizados nao tinham tanta relevancia para o que se desejava
29
observar, com excecao da configuracao do numero de resultados retornados por linha.
Diferente dos outros testes, nao estavamos interessados em analisar a precisao
da estimativa, mas sim na capacidade do sistema em disponibilizar os resultados obtidos.
Para que a integracao funcionasse, era necessario que as informacoes fornecidas estivessem
exatamente no mesmo formato disponibilizado pelo DataRio. Sendo assim, a configuracao
utilizada para este teste esta listada na Tabela 4.4.
Atributo V alor
Numero de pontos analisados 5
Tamanho de cada celula 111m2
Considerar trajetorias de ida e volta True
Retornar mais de uma possibilidade False
Tabela 4.4: Configuracao do sistema no teste de integracao com o sistema TrackBus
proposto em [Rocha e Amaral 2016].
Para executar o teste, foi necessario alterar dois pontos no codigo do aplicativo
Trackbus: o trecho de codigo que acessava informacoes de uma linha especıfica e o que bus-
cava o ultimo log de todas as linhas presentes na base. Para isso, bastou alterar as URLs
utilizadas pelo aplicativo para https://<Endereco IP do do sistema>/linha/<Numero da
linha> e https://<Endereco IP do sistema>/linhas, respectivamente.
4.3.1 Resultados obtidos
Inicialmente, verificou-se que a integracao nao fora bem sucedida devido a um
problema no formato disponibilizado pelo sistema. Apos alterar tal formato do arquivo
de texto para JSON, o teste correu como esperado e foi possıvel observar em tempo real
as linhas que ja eram informadas pelo DataRio com a adicao das linhas inferidas pelo
sistema que desenvolvemos neste trabalho.
Foi tambem possıvel observar que o processo de filtragem por numero de linha e
execucao de outras funcionalidades do aplicativo permaneceram sem alteracoes no que diz
respeito a seu funcionamento. Dessa forma, foi possıvel concluir que o sistema atingiu seu
objetivo de servir como fornecedor de dados para aplicacoes externas.
Capıtulo 5
Conclusoes
Neste trabalho propusemos um sistema de enriquecimento dos dados fornecidos
pelo portal de Dados Abertos DataRio, que tem como principal objetivo estimar a infor-
macao das linhas dos onibus em servico na cidade do Rio de Janeiro, quando a mesma
nao e fornecida pelo sistema.
O sistema desenvolvido pode assim obter, transformar e distribuir os dados do
DataRio ou fazer consultas de linha individualmente, e pode ser utilizado por outras
aplicacoes que dependam dos dados fornecidos pelo DataRio como um componente inter-
mediario entre a aplicacao e o portal de dados, o que garante maior qualidade dos dados.
O codigo completo desenvolvido durante esse estudo esta disponıvel a quem tiver interesse
no repositorio de link https://github.com/nataliapipas/bus.
Os resultados apresentados mostram que a qualidade das estimativas e acima de
90% nos casos em que os onibus sem informacao de linha estao seguindo a rota de alguma
linha conhecida. Tambem foi apresentado um estudo dos casos em que o sistema nao
consegue estimar corretamente as linhas e um estudo de caso do uso do sistema por uma
aplicacao de celular baseada nos dados do DataRio.
Nos proximos paragrafos discutiremos algumas limitacoes do sistema e apontare-
mos direcoes de trabalhos futuros.
30
31
5.1 Limitacoes
5.1.1 Escalabilidade
Atualmente, o projeto consegue obter, processar e disponibilizar os dados dentro da
janela de tempo estabelecida como limite. Contudo, nao estao descartadas as possibilida-
des de crescimento da frota de onibus, aumento no layout das informacoes disponibilizadas
ou ate mesmo adicao de novas funcionalidades a aplicacao. Dessa forma, nao ha garantia
de que a performance do programa se mantera aceitavel.
Uma solucao para amenizar tal problema seria distribuir o processamento da apli-
cacao para que, no caso da necessidade de aumento dos recursos disponıveis, seja possıvel
aumentar o numero de nos do cluster ao inves de migrar o processamento para uma
maquina mais potente, o que seria razoavelmente mais caro. Contudo, tal alternativa
demandaria uma reestruturacao da solucao para acomodar a computacao paralela.
5.1.2 Cobertura da cidade
Infelizmente, o baixo numero de linhas conhecidas pelo sistema resultou em analises
em apenas uma pequena area da cidade. Assim, em um universo de 462 onibus sem linha
do Rio de Janeiro, uma pequena parcela de apenas 7% (ou seja 32 ordens) conseguiu ser
classificada, como mostra a figura 5.1.
Figura 5.1: Proporcao de ordens classificadas
Por outro lado, foi possıvel observar nessa analise uma relativamente boa distribui-
cao das linhas presentes nas classificacoes, havendo uma ligeira predominancia das linhas
326 (ida) e 455 (volta), como mostra a figura 5.2.
32
Observamos no entanto, que essa limitacao e causada pela indisponibilidade da
informacao das rotas de onibus da cidade do Rio de Janeiro. Como discutido durante o
texto, para contornar esse problema, utilizamos como dado de entrada do sistema as rotas
estimadas pelo trabalho de [Padilha 2017] que nos forneceu apenas um subconjunto das
rotas das linhas de onibus da cidade para a execucao do projeto.
Figura 5.2: Classificacao realizada dos onibus sem linha
5.2 Trabalhos futuros
Talvez o mais relevante trabalho futuro esteja relacionado a adicao de novas rotas
conhecidas ao sistema, aumentando a confiabilidade dos resultados obtidos, bem como o
volume de linhas inferidas. Tal melhoramento necessitaria da geracao de novas linhas por
parte do trabalho mencionado na secao 1.1 ou entao a obtencao manual de tais linhas.
Tambem e possıvel a elaboracao de novos filtros e tratamentos para a base de
dados, tais como os filtros de velocidade, inicialmente descontinuados por esse projeto, ou
filtros de localizacao que exibissem apenas ordens proximas ao usuario.
Como esse e um sistema que trabalha com a posicao de todos os onibus da cidade
em tempo real, seria tambem interessante pensar em algoritmos preditivos capazes de
estimar tempos de deslocamento, bem como diagnosticar areas que nao estejam sendo
suficientemente cobertas, especialmente no que diz respeito ao fluxo de onibus.
33
5.3 Consideracoes finais
A realizacao desse estudo mostrou ser possıvel, em posse de recursos limitados,
analisar uma base de dados relativamente grande e dar respostas em tempo real. Assim, e
confirmada a possibilidade de que o sistema atue como fornecedor dos dados do DataRio
de forma enriquecida, sem perda de integridade. Havendo disponibilidade de recursos,
seria ate mesmo possıvel amenizar a questao de indisponibilidade do servico atualmente
ofertado pelo DataRio.
A integracao com o TrackBus permitiu uma abordagem mais pratica do estudo,
possibilitando uma validacao em tempo real dos resultados, ainda que em um ambiente
controlado. Tal integracao foi altamente relevante para o projeto pois confirma que alte-
racoes mınimas sao necessarias no sistema consumidor para que o sistema fonte passe a
ser o descrito aqui e que nao ha perda de consistencia nessa transicao.
Com a chegada de novos trajetos de linha conhecidos, sera possıvel obter um re-
sultado ainda mais relevante, visto que uma maior area da cidade sera coberta. Isso
resultara tambem em maior acuracia dos resultados obtidos, visto que minimiza a chance
de o sistema retornar uma linha errada pelo motivo de a linha certa ainda nao ter sido
cadastrada.
Referencias Bibliograficas
[Barbosa et al. 2014]BARBOSA, L. et al. Vistradas: Visual analytics for urban trajectory
data. In: GeoInfo. [S.l.: s.n.], 2014. p. 174–179.
[Bessa et al. 2016]BESSA, A. et al. Riobusdata: Outlier detection in bus routes of rio de
janeiro. arXiv preprint arXiv:1601.06128, 2016.
[Chen, Guo e Wang 2015]CHEN, W.; GUO, F.; WANG, F.-Y. A survey of traffic data
visualization. IEEE Transactions on Intelligent Transportation Systems, IEEE, v. 16,
n. 6, p. 2970–2984, 2015.
[Doraiswamy et al. 2014]DORAISWAMY, H. et al. Using topological analysis to support
event-guided exploration in urban data. IEEE transactions on visualization and computer
graphics, IEEE, v. 20, n. 12, p. 2634–2643, 2014.
[Ferreira et al. 2013]FERREIRA, N. et al. Visual exploration of big spatio-temporal urban
data: A study of new york city taxi trips. IEEE Transactions on Visualization and
Computer Graphics, IEEE, v. 19, n. 12, p. 2149–2158, 2013.
[Freire et al. 2014]FREIRE, J. et al. Riding from urban data to insight using new york
city taxis. IEEE Data Eng. Bull., v. 37, n. 4, p. 43–55, 2014.
[IBGE 2016]IBGE. CENSO Demografico 2010. Ultimo Acesso: Abril 2016. http://goo.
gl/NPvw6L.
[Onilinhas - Itinerarios]ONILINHAS - Itinerarios. https://www.onilinhas.com.br/
rio-de-janeiro/itinerario/linha-455/. Ultimo acesso em 11/07/2017.
[Padilha 2017]PADILHA, D. Informacoes sobre linhas de onibus usando historicos de gps.
2017.
34
35
[Raymond e Imamichi 2016]RAYMOND, R.; IMAMICHI, T. Bus trajectory identifica-
tion by map-matching. In: IEEE. Pattern Recognition (ICPR), 2016 23rd International
Conference on. [S.l.], 2016. p. 1618–1623.
[Rocha e Amaral 2016]ROCHA, M. V. Cunha da; AMARAL, R. P. Trackbus: Um apli-
cativo de apoio aos usuarios de onibus ba cidade do rio de janeiro. 2016.
[Schettino 2016]SCHETTINO, B. de P. An infrastructure for bus data analyses applied
to the rio de janeiro city. 2016.
[Wang et al. 2014]WANG, Z. et al. Visual exploration of sparse traffic trajectory data.
IEEE transactions on visualization and computer graphics, IEEE, v. 20, n. 12, p. 1813–
1822, 2014.
