Correção de inconsistências nos dados de GPS de ônibus do Rio de Janeiro

(1)

Instituto de Computa¸

c˜

ao

Departamento de Ciˆ

encia da Computa¸

c˜

ao

NATALIA ROCHA DE ALMEIDA PIPAS

CORRE ¸

C ˜

AO DE INCONSISTˆ

ENCIAS NOS DADOS

DE GPS DE ˆ

ONIBUS DO RIO DE JANEIRO

Niter´

oi-RJ

2017

(2)

ii NATALIA ROCHA DE ALMEIDA PIPAS

CORRE ¸C ÃO DE INCONSIST ÊNCIAS NOS DADOS DE GPS DE ÔNIBUS DO RIO DE JANEIRO

Trabalho submetido ao Curso de

Bacharelado em Ciência da Computa¸cão da Universidade Federal Fluminense como requisito parcial para a obten¸cão do t´ıtulo de Bacharel em Ciência da Computa¸cão.

Orientador: Prof. Marcos Lage Co-orientador: Prof. Antˆonio Augusto Rocha

Niter´oi-RJ 2017

(3)

(4)

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

(5)

`

A minha irm˜a Lara, que me prometeu um brownie para aparecer aqui.

(6)

v

Agradecimentos

`

A minha fam´ılia, apoiadora de todos os meus projetos e sonhos.

Aos meus orientadores Marcos Lage e Antˆonio Augusto Rocha, sempre sol´ıcitos durante todo o trabalho.

Aos professores Lhaylla Crissaff, Aline Paes e Antˆonio Augusto Rocha pela presen¸ca na banca examinadora.

Aos meus colegas de trabalho, que reclamaram apenas um pouco do tempo que dediquei a esse projeto.

(7)

Resumo

Com os avan¸cos recentes na coleta de dados urbanos, consequência da evolu¸cão de diversos tipos de sensores, das tecnologias de comunica¸cão sem fio e da capacidade de armazenamento de dados, surgem oportunidades para o desenvolvimento de aplicativos, sistemas e tecnologias baseados na análise dos dados coletados e capazes de aumentar o entendimento que se tem sobre áreas urbanas. Seguindo essa tendência, a prefeitura do Rio de Janeiro tem disponibilizado dados de GPS de sua frota de ônibus, que contém informa¸cões como a localiza¸cão geográfica e velocidade dos ve´ıculos em tempo real. En-tretanto, o grande desafio de utilizar esta base de dados é a presen¸ca de inconsistências como a ausência do número da linha servida por alguns ve´ıculos e a presen¸ca de regis-tros de ônibus em posi¸cões geográficas absurdas. Por outro lado, muitos destes problemas podem ser corrigidos automaticamente através de modelos matemáticos e estratégias com-putacionais. Com base no exposto, foi desenvolvido um sistema capaz de, na posse das trajetórias das linhas de ônibus da cidade, corrigir alguns dos problemas mais frequentes da base do GPS dos ônibus do Rio de Janeiro e disponibilizar os dados corrigidos em um formato de fácil acesso aos sistemas externos que desejarem utilizá-los.

(8)

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.

(9)

Sum´

ario

Resumo vi

Abstract vii

Lista de Figuras xi

Lista de Tabelas xii

1 Introdu¸c˜ao 1

1.1 Escopo . . . 2

1.2 Objetivos . . . 3

1.3 Organiza¸c˜ao da Monografia . . . 4

2 A base dos ˆonibus do Rio de Janeiro 5 2.1 Descri¸c˜ao . . . 5

2.2 Inconsistˆencias nos dados . . . 6

2.3 Filtragem dos dados . . . 8

2.4 Estrutura¸c˜ao dos dados . . . 10

3 Sistema Proposto 13 3.1 M´odulo de carregamento de linhas . . . 13

3.2 M´odulo de acesso aos dados do Data Rio . . . 15

3.3 M´odulo de inferˆencia de linhas . . . 16

3.4 Disponibiliza¸c˜ao dos resultados . . . 19

4 Estudo de Caso 21 4.1 Precis˜ao da estimativa das rotas . . . 21

4.1.1 Resultados obtidos . . . 22 viii

(10)

ix

4.2 Origem dos erros . . . 25

4.3 Integra¸c˜ao com outros sistemas . . . 28

4.3.1 Resultados obtidos . . . 29 5 Conclus˜oes 30 5.1 Limita¸c˜oes . . . 31 5.1.1 Escalabilidade . . . 31 5.1.2 Cobertura da cidade . . . 31 5.2 Trabalhos futuros . . . 32

(11)

Lista de Figuras

2.1 Ultima atualiza¸c˜´ ao x Número de ônibus. A imagem mostra que nem todos os ônibus são atualizados minuto a minuto, como se imaginava a princ´ıpio. 8 2.2 Propor¸cão de ônibus com/sem linha associada. Apesar de serem minoria,

os ônibus sem linha informada representam uma fra¸cão relevante do total de ordens. . . 9 2.3 Elementos que compõem o dicionário Grid. Este dicionário é usado para

dividir a cidade em células e guardar os pontos das trajetórias das linhas de ônibus. . . 11 2.4 Elementos que compõem o dicionário dicionário Ordem. Este dicionário

guarda, para cada ordem, informa¸cões necessárias para a inferência de sua linhas, entre elas, uma lista com os últimos N pontos de sua trajetória. . . 11 2.5 Elementos que compõem o dicionário dicionário Linha. Este dicionário

armazena as ordens pertencentes a cada linha. . . 12 3.1 Diagrama com os módulos do sistema proposto e as dependências entre eles. 14 3.2 Exemplo de cálculo da distância ordem-linha, onde os pontos em laranja e

azul representam pontos de trajetória de duas linhas conhecidas e o ponto rosa é o ponto sob análise em uma rodada. As linhas tracejadas representam a distância em linha reta entre a ordem e cada uma das linhas. . . 17 3.3 Código necessário para subir o servidor web . . . 20 4.1 Resultado da estimativa das linhas. Foram analisados os 5 últimos

pon-tos da trajet´oria de cada ve´ıculo, com c´elulas de tamanhos 1111x1111m2

(imagem da esquerda) e 111x111m2 (imagem da direita). . . 23

(12)

xi 4.2 Resultado da estimativa das linhas. Foram analisados os 10 ´ultimos

pon-tos da trajet´oria de cada ve´ıculo, com c´elulas de tamanhos 1111x1111m2 (imagem da esquerda) e 111x111m2 _{(imagem da direita). . . .} ₂₃

4.3 Resultado da estimativa das linhas. Foram analisados os 20 últimos pon-tos da trajetória de cada ve´ıculo, com células de tamanhos 1111x1111m2

(imagem da esquerda) e 111x111m2 (imagem da direita). . . 24 4.4 Trajet´oria da linha 455 (azul) e pontos de ordens cuja linha informada pelo

DataRio era 455, mas que receberam pontua¸cão zerada para tal linha na estimativa (vermelho). Os pontos em vermelho foram obtidos no Caso de Teste 1, com 20 pontos anteriores e células de 1111 x 1111m2. . . 25 4.5 Trajetória da linha 422 (azul) e pontos de ordens cuja linha informada pelo

DataRio era também a 422, mas que receberam pontua¸cão zerada para tal linha na estimativa (vermelho). Diferente da figura anterior, os pontos em vermelho ficaram concentrados em uma área pequena. Os resultados foram obtidos em teste realizado no final da tarde do dia 08/07/2017. . . 26 4.6 Mesma compara¸cão da figura 4.5, mas com o teste tendo sido realizado na

parte da manh˜a do dia 10/07/2017. . . 27 4.7 Exemplo de exibi¸c˜ao dos dados fornecidos pelos sistema desenvolvido nesta

monografia no Trackbus. Ícones de cores iguais representam logs de mesma linha. . . 28 5.1 Propor¸cão de ordens classificadas . . . 31 5.2 Classifica¸cão realizada dos ônibus sem linha . . . 32

(13)

Lista de Tabelas

3.1 Distância média entre os pontos das trajetórias de linhas, utilizada para avaliar a viabilidade do tamanho de célula escolhido. . . 15 4.1 Configura¸cão do caso de teste elaborado com a finalidade de verificar a

qualidade das estimativas das linhas. Foram feitos testes com diferentes parâmetros. . . 22 4.2 Rela¸cão parâmetros x Porcentagem média de acerto. . . 24 4.3 Rela¸cão parâmetros x Porcentagens médias de acerto, com e sem a

elimi-na¸cão de ordens que tiveram pontua¸cão zero para a linha correta. . . 28 4.4 Configura¸cão do sistema no teste de integra¸cão com o sistema TrackBus

(14)

Cap´ıtulo 1

Introdu¸

c˜

ao

A cidade do Rio de Janeiro, uma das mais populosas e movimentadas do pa´ıs, tem sofrido muito nos últimos 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 econômicas por conta do trânsito [IBGE 2016], é urgente falar sobre dados urbanos e como eles podem auxiliar a questão da mobilidade.

Diversos avan¸cos tecnológicos recentes também colaboram para o desenvolvimento de novas pesquisas e solu¸cões na área de análise 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 áreas como Inte-ligência Artificial e Big Data e resultam em um crescimento exponencial das capacidades de comunica¸cão sem fio, armazenamento de dados, oferta de sensores de diversos tipos e análise de informa¸cões. Neste novo cenário, é bastante natural pensarmos em solu¸cões que agreguem estas novas capacidades para auxiliar na resolu¸cão de problemas enfrentados pelas grandes cidades.

Ainda, como parte do cumprimento da lei de acesso `a informa¸c˜ao1_{, muitas cidades}

passaram a disponibilizar em tempo real informa¸c˜oes sobre o seu quotidiano. A cidade do Rio de Janeiro, por exemplo, conta com o portal de dados DataRio2_{. O DataRio fornece}

informa¸cões nas áreas de transporte e mobilidade urbana, entretenimento, educa¸cão, ur-banismo, esportes, turismo, meio ambiente, saúde e etc. Em particular, o DataRio oferece informa¸cões em tempo real, atualizadas de minuto em minuto, sobre todos os ônibus em

1_{Lei n}o _12.527/2011 2_{http://data.rio/}

(15)

atividade na cidade. Essas informa¸cões são mantidas pela FETRANSPOR e contêm a posi¸cão geográfica, a velocidade, a linha e um identificador único de cada ônibus.

Apesar dos esfor¸cos realizados pela prefeitura, a qualidade dos dados é muitas vezes questionada e impacta o desenvolvimento de solu¸cões inovadoras para auxiliar no combate ao problema da mobilidade urbana. Uma das principais reclama¸cões diz respeito `

a informa¸cão da linha associada aos ônibus, que muitas vezes não é informada pela em-presa responsável. Trabalhos relacionados [Schettino 2016] sugerem que 68% dos registros fornecidos pelo DataRio no ano de 2015 contêm algum tipo de inconsistência.

Pensando em minimizar os problemas encontrados mais frequentemente na base de dados de ônibus do DataRio, foi desenvolvido um sistema que atua como intermediário entre aplica¸cões e usuários consumidores desses dados e o portal DataRio. Em outras palavras, o objetivo do sistema proposto é corrigir algumas das inconsistências encontradas e oferecer dados de melhor qualidade às diversas aplica¸cões dependentes da base, muitas delas sendo mantidas na própria Universidade Federal Fluminense.

1.1 Escopo

Para que o objetivo deste projeto fosse alcan¸cado, era necessário ter acesso não apenas à base de dados de ônibus do DataRio citada anteriormente, mas também às trajetórias das linhas de ônibus em atividade no Rio de Janeiro. O site de dados abertos da prefeitura do Rio, no entanto, não mantém informa¸cões dos trajetos das linhas de ônibus. 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 Computa¸cão da UFF [Padilha 2017]. O objetivo desse trabalho é inferir dados operacionais das linhas de ônibus, como a posi¸cão da garagem, os pontos inicial/final e o trajeto usando dados históricos de GPS.

Outro projeto relacionado ao sistema aqui descrito é o Trackbus, trabalho de con-clusão de curso descrito em [Rocha e Amaral 2016]. O sistema, também desenvolvido por alunos da Universidade Federal Fluminense permite, entre outras funcionalidades, a exi-bi¸cão de pontos tur´ısticos, pontos de parada de ônibus e a consulta da posi¸cão geográfica dos ônibus em atividade na cidade do Rio de Janeiro, em tempo real. O aplicativo em questão consome os dados do portal DataRio diretamente. Em outras palavras, o sistema

(16)

3 não faz nenhum tratamento ou limpeza nos dados dos ônibus fornecidos pelo portal Data-Rio. Entretanto, como dito anteriormente, a base de dados em questão apresenta diversas inconsistências e, por este motivo, a qualidade do servi¸co oferecido pelo aplicativo fica comprometida. O trabalho aqui proposto foi motivado pela necessidade de se desenvolver uma aplica¸cão capaz de reparar inconsistências da base do DataRio em tempo real para que a informa¸cão corrigida fosse disponibilizada para aplica¸cões como o TrackBus. A integra¸cão do sistema proposto nesse trabalho e o TrackBus está descrita na Se¸cão 4.3.

Ainda, é grande o número de trabalhos que utilizam a base de dados do DataRio, tendo alguns deles funcionalidades semelhantes às de nosso sistema. Como exemplo, temos o trabalho [Barbosa et al. 2014], que quantifica o desvio de ônibus de suas linhas originais através do cálculo de uma pontua¸cão baseada na distância entre o ve´ıculo e a trajetória de sua linha. A ideia de mostrar desvios espaciais e temporais de um ônibus também aparece no trabalho [Bessa et al. 2016], que utiliza redes neurais para exibir ve´ıculos que possuam inconsistências em rela¸cão à trajetória seguida ou ao tempo de percurso, que pode ser influenciado pelo trânsito ou pelo próprio desvio à rota original. No entanto, apesar da proposta parecida, não é o objetivo de nenhum desses trabalhos inferir a qual linha pertencem os ônibus 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 ônibus do DataRio, de minuto em minuto. Tendo em vista que a existência de registros de ônibus sem linha associada e registros em regiões fora dos limites da cidade do Rio de Janeiro são os problemas mais prejudiciais encontrados na base de dados, o sistema aqui desenvolvido objetiva corrigir esses dois tipos de problemas.

O sistema implementado é composto por quatro módulos, responsáveis pelo car-regamento de linhas conhecidas, pela obten¸cão dos dados do DataRio, pela inferência de linhas percorridas por cada ônibus sem linha informada e a disponibiliza¸cão dos resulta-dos. Os módulos que compõe o sistema serão 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;

(17)

• O sistema deve ser capaz de detectar e remover da base de dados registros com coordenadas geogr´aficas 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 através de uma API para consulta análoga à do DataRio.

1.3 Organiza¸

c˜

ao da Monografia

O restante deste trabalho está dividido em quatro outros cap´ıtulos, totalizando cinco com a introdu¸cão. O Segundo Cap´ıtulo 2 apresenta uma descri¸cão 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 é responsável por explicar deta-lhadamente cada módulo do sistema, definindo conceitos utilizados por ele. O Cap´ıtulo 4 concentra a descri¸cão dos resultados obtidos pelos testes realizados, bem como uma breve conclusão após cada um deles. A conclusão, com apresenta¸cão das limita¸cões, contribui-¸cões e reflexões quanto a trabalhos futuros são encontrados no Cap´ıtulo 5.

(18)

Cap´ıtulo 2

A base dos ˆ

onibus do Rio de Janeiro

2.1 Descri¸

c˜

ao

Como dito no Cap´ıtulo 1, o portal DataRio é uma base de dados que disponibiliza informa¸cões sobre diferentes aspectos da cidade do Rio de Janeiro, desde a localiza¸cão dos ônibus em circula¸cão até dados administrativos, indicadores de frequência escolar, entre outros. Sendo assim, o portal é uma fonte rica de informa¸cão para diversos projetos que visam estudar aspectos urbanos, sociais ou demográficos da cidade. Uma das bases fornecidas no DataRio, mantida pela FETRANSPOR (Federa¸cão das Empresas de Trans-portes de Passageiros do Estado do Rio de Janeiro), fornece informa¸cões como a posi¸cão geográfica, velocidade, linha e identificador único dos aproximadamente 8000 ônibus na cidade do Rio Janeiro, atualizados minuto a minuto. O acesso a essas informa¸cões pode ser feito através de uma API HTTP1_.

Os dados de ônibus são disponibilizados pelo DataRio em três formatos; JSON, CSV e PDF. Para o escopo desse trabalho, foi escolhido o formato CSV pela facilidade de leitura e escrita das informa¸cões. No formato CSV disponibilizado pelo portal, as informa¸cões são disponibilizadas de acordo com as colunas abaixo:

• Data/hora: String que representa o instante de tempo em que o registro foi gerado. As strings s˜ao 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 único de cada ônibus. Um exemplo de Ordem é a string A29004 ;

1_{http://dadosabertos.rio.rj.gov.br /apiTransporte/apresentacao/csv/onibus.cfm}

(19)

• Linha: String contendo o identificador da linha a qual o ve´ıculo está servindo. São exemplos de linhas de ônibus os identificadores 422 e 455-SV ;

• Latitude - Valor numérico representando a distância em graus ao Equador me-dida sobre o meridiano de Greenwich. Um exemplo de latitude é o valor -22.868 ;

• Longitude - Valor numérico representando a distância em graus ao meridiano de Greenwich medida ao longo do Equador. Um exemplo de longitude é o valor -43.292 ;

• Velocidade: Valor num´erico que representa a velocidade do ve´ıculo no instante em que foi armazenado do registro.

As requisi¸cões HTTP realizadas pelo sistema foram implementadas utilizando a biblioteca urllib do Python, que é capaz de realizar a requisi¸cão e gravar o resultado dentro de um diretório local também no formato CSV. Um arquivo CSV é baixado pelo sistema a cada minuto e contém as últimas informa¸cões conhecidas de cada ve´ıculo da frota de ônibus da cidade do Rio de Janeiro. De posse do arquivo CSV, o sistema carrega todas as informa¸cões (Data/hora, ordem, linha, latitude, longitude e velocidade) em memória na forma de uma cole¸cão de dicionários. A estrutura de dados utilizada para armazenar os dados obtidos do DataRio será explicada na Se¸cão 2.4.

2.2 Inconsistˆ

encias nos dados

Como foi brevemente mencionado no Cap´ıtulo 1, os dados dos ônibus do Rio de Janeiro, fornecidos pelo portal DataRio, apresentam problemas de diversas naturezas. Esses problemas, ou inconsistências, podem limitar ou até mesmo inviabilizar o desenvol-vimento de sistemas e/ou algoritmos de análise de dados que utilizam a base de registros de GPS dos ônibus. Um exemplo de aplicativo que sofre das limita¸cões impostas pela base de dados é o TrackBus, descrito em [Rocha e Amaral 2016]. Nesta Se¸cão, listamos os problemas encontrados de forma mais frequentes na base de dados.

Imprecisão das coordenadas geográficas. Apesar de o DataRio fornecer informa¸cões de latitude e longitude com até seis casas decimais de precisão, o que geraria erros de no máximo 0.11 metros, em alguns locais da cidade, a precisão da posi¸cão dos registros pode

(20)

7 variar bastante. Tal fenômeno se deve a interferências externas como a presen¸ca de prédios ou montanhas e má qualidade dos aparelhos utilizados. Este problema é de dif´ıcil solu¸cão, mas a incerteza gerada pela imprecisão nas coordenadas geográficas dos registros precisa ser considerada durante a estimativa das linhas proposta nesse trabalho.

Para tratar essa questão, foi implementado um cálculo de confiabilidade das esti-mativas produzidas pelo sistema. Tal mecanismo está descrito no Cap´ıtulo 3 desse do-cumento. Vale ressaltar que, mesmo que os GPS retornassem posi¸cões geográficas 100% precisas, ainda assim não seria poss´ıvel estimar a linha de um ve´ıculo com 100% de pre-cisão. Essa impossibilidade se deve ao fato de vários ve´ıculos compartilharem partes de sua trajetória com outros ônibus.

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 legisla¸cão brasileira. Tal fato é causado por falhas ou defeitos nos aparelhos de GPS presentes nos ve´ıculos. Como a informa¸cão da velocidade do ve´ıculo não é fundamental para a estimativa das linhas servidas por cada ve´ıculo, tais inconsistências não foram tratadas nesse trabalho.

Registro no mar, rios ou lagoas. Devido a falhas do GPS dos ônibus e/ou a im-precisão das coordenadas geográficas, alguns registros são feitos em áreas ocupadas por rios, lagoas ou pelo mar. Como esses registros não podem ser associados ao trajeto de ne-nhuma linha, definimos uma estratégia para eliminar estas informa¸cões da base de dados. A Se¸cão 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 execu¸cão 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 comunica¸cão. De fato, o sistema proposto neste trabalho poderia substituir o DataRio temporariamente para evitar que servi¸cos que dependam dos dados fornecidos pelo portal fiquem fora do ar. Indisponibilidades mais severas, como queda do portal por longos per´ıodos, são imposs´ıveis de se resolver já que o portal é a fonte primária dos dados em questão.

(21)

Taxa de atualiza¸cão. Em teoria, a base de dados dos ônibus fornecida pelo DataRio deveria ser atualizada a cada minuto. Contudo, muitos ve´ıculos passam horas sem sequer uma atualiza¸cão. Como exemplo, podemos citar a Figura 2.1, que representa uma amostra capturada às 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 último registro conhecido de cada ve´ıculo da frota de ônibus da cidade do Rio de Janeiro.

Figura 2.1: Última atualiza¸cão x Número de ônibus. A imagem mostra que nem todos os ˆ

onibus s˜ao atualizados minuto a minuto, como se imaginava a princ´ıpio.

Ordens sem linha. Razão motivadora da implementa¸cão desse sistema, alguns ônibus não vêm associadas a linha alguma nos arquivos disponibilizados pelo DataRio. Como ilustra a figura 2.2, a ocorrência desse fenômeno é de aproximadamente 7% e impacta os sistemas dependentes da completude dos dados. Tal porcentagem fora retirada de uma análise feita em uma amostra de 6653 ordens retirada do próprio DataRio em dezembro de 2016 na parte da manhã.

2.3 Filtragem dos dados

Apesar de ser importante que se consiga oferecer o melhor servi¸co poss´ıvel (isto é, com o maior número de registros) para as aplica¸cões interessadas em consumir os dados de ônibus do Rio de Janeiro tratados pelo nosso sistema, alguns registros com informa¸cões

(22)

9

Figura 2.2: Propor¸c˜ao de ˆonibus com/sem linha associada. Apesar de serem minoria, os ˆ

onibus sem linha informada representam uma fra¸c˜ao relevante do total de ordens.

inconsistentes e que não são tratadas pelo nosso sistema precisam ser descartados. Sendo assim, registros que não atendam aos critérios de qualidade impostos pelo sistema são ignorados pelo programa, não havendo nem mesmo a grava¸cão dos mesmos em diretórios separados. Portanto, caso algum sistema externo queira utilizar os arquivos gravados por esse programa, deve considerar a poss´ıvel perda de informa¸cões. Nesta Se¸cão descrevere-mos os filtros utilizados em nosso sistema.

Filtro de formato inconsistente. Caso algum registro seja disponibilizado em um formato fora do padrão estabelecido pelo portal DataRio e descrito no in´ıcio deste Ca-p´ıtulo, o mesmo será desconsiderado. Durante os nossos testes, não houve registros da ocorrência de tais eventos. Ainda assim, o filtro foi adicionado para garantir a robustez e a não interrup¸cão do sistema.

Filtro por data. Como o Data Rio disponibiliza os dados de forma instantânea (ou seja, sempre fornece as últimas informa¸cões disponibilizadas por um ônibus, independente de seu GPS estar ativo e logando ou não), é necessário armazenar, para cada ordem, a data e hora de sua última atualiza¸cão. Caso o sistema receba um registro com data igual `

a última data armazenada, esse é desconsiderado. Dessa forma, não são armazenadas informa¸cões repetidas na base.

(23)

Filtro por duplicidade. Caso as informa¸cões de latitude e longitude se repitam em sequência, ou seja, dois registros consecutivos possuam a mesma localiza¸cão geográfica, o registro também é rejeitado, evitando que estimativas sejam feitas para ônibus que não estão em movimento.

Filtro por registros em rios, lagoas e no mar. Como é imposs´ıvel que um ônibus circule sobre água, qualquer registro sobre o mar, rios ou lagoas deve ser desconsiderado. Para filtrar esses registros, utilizamos as informa¸cões geográficas 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 classifica¸cão ponto conjunto como o winding number. O algoritmo é implementado por bibliotecas como a Shapely.

2.4 Estrutura¸

c˜

ao dos dados

A estrutura de dados utilizada para armazenar e manipular os dados obtidos do portal DataRio em nossa aplica¸cão é uma cole¸cão de dicionários. Dicionários são estrutu-ras de dados eficientes, já que são tipicamente implementadas através de tabelas hash, e simples de usar. Estas caracter´ısticas fazem com que o carregamento, atualiza¸cão e ma-nipula¸cão dos dados de GPS de ônibus usando dicionários seja intuitiva e apresente boa performance, dentro das restri¸cões temporais impostas pela taxa de atualiza¸cão dos dados do DataRio. As estruturas de dicionários utilizados em nossa aplica¸cão para representar e manipular os dados obtidos do DataRio serão descritos no restante desta Se¸cão.

Grid. E respons´´ avel por armazenar as rotas das linhas conhecidas estimadas e fornecidas por [Padilha 2017]. Este dicionário é preenchido na inicializa¸cão do sistema e consultado pelo algoritmo responsável por estimar a qual linha pertence um registro. Cada item do dicionário representa uma célula de um grid que cobre toda a cidade do Rio de Janeiro. A chave de cada célula é a string lat,lng onde lat e lng são, respectivamente, os valores da latitude e da longitude truncados na terceira casa decimal, como explicado na se¸cão 3.2. Sendo assim cada célula grid [“lat,lng”] = <lista–pontos> armazena a lista de pontos das trajetórias conhecidas que estão contidos na região espacial representada pela célula do grid. A Figura 2.3 mostra a rela¸cão entre os elementos que compõem o dicionário.

(24)

11

Figura 2.3: Elementos que compõem o dicionário Grid. Este dicionário é usado para dividir a cidade em células e guardar os pontos das trajetórias das linhas de ônibus.

Figura 2.4: Elementos que compõem o dicionário dicionário Ordem. Este dicionário guarda, para cada ordem, informa¸cões necessárias para a inferência de sua linhas, entre elas, uma lista com os últimos N pontos de sua trajetória.

Ordem. E respons´´ avel por armazenar as informa¸cões de cada ve´ıculo fornecidas pelo DataRio. Este dicionário é atualizado minuto a minuto de modo que, para cada ordem, haja o histórico completo dos N últimos registros dispon´ıveis. Neste dicionário também é armazenado se a linha relativa a uma determinada ordem foi informada pelo DataRio ou inferida pelo sistema. Tal distin¸cão é necessária pois o sistema tenta descobrir a linha apenas de ordens que tenham originalmente sido recebidas sem essa informa¸cão. Em outras palavras, mesmo que uma ordem tenha sua linha inferida, é desejável que ela continue sendo avaliada em próximos ciclos de processamento. Os elementos que compõem o dicionário Ordem podem ser observados na Figura 2.4.

(25)

Figura 2.5: Elementos que compõem o dicionário dicionário Linha. Este dicionário arma-zena as ordens pertencentes a cada linha.

Linha. E respons´´ avel por armazenar quais ordens estão associadas a uma determinada linha. Durante a atualiza¸cão dessa estrutura, é 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-ra¸cões. Sendo assim, é necessário garantir que, para cada atualiza¸cão da linha a qual uma ordem pertence, haja a desassocia¸cão à linha anterior, que fora substitu´ıda. Os elementos que compõem o dicionário Linha podem ser vistos na figura 2.5.

Como os módulos do sistema são executados através de threads independentes e um dicionário não pode ser acessado e modificado ao mesmo tempo, foi necessário adicionar um lock para lidar com as questões de concorrência. O uso do lock é feito de modo que, toda vez que uma opera¸cão de leitura ou escrita está prestes a ser realizada em um dicionário, o lock seja adquirido e liberado após a realiza¸cão da opera¸cão.

(26)

Cap´ıtulo 3

Sistema Proposto

A proposta desta monografia é o desenvolvimento de um sistema capaz de, a partir dos registros de GPS dos ônibus que compõem a frota e das rotas das linhas de ônibus, inferir a qual linha pertence cada ve´ıculo em opera¸cão na cidade do Rio de Janeiro. Sendo assim, um subproduto do sistema proposto é o enriquecimento dos dados fornecidos pelo DataRio. Como descrito nos cap´ıtulos anteriores, a informa¸cão da linha servida pelos ve´ıculos em opera¸cão no Rio de Janeiro está frequentemente indispon´ıvel na base de dados originalmente disponibilizada pelo portal. Portanto, a oferta de um sistema capaz de estimar essa informa¸cão e usar esta estimativa para enriquecer os registros da base de dados original é uma grande colabora¸cão para todos interessados em desenvolver tecnologias baseadas nos registros de GPS dos ônibus do Rio de Janeiro.

Neste cap´ıtulo, vamos apresentar os módulos que compõem o sistema proposto. Uma visão geral desses módulos e da dependência entre eles pode ser vista na Figura 3.1.

3.1 M´

odulo de carregamento de linhas

Executado uma vez, na inicializa¸cão do sistema, o módulo de carregamento de linhas consiste em, a partir de arquivos previamente obtidos, carregar para o dicionário Grid (apresentado no Cap´ıtulo 2) os pontos das trajetórias que compõem as linhas da cidade do Rio de Janeiro. Tais linhas foram obtidas utilizando o trabalho de mestrado [Padilha 2017], como dito na Se¸cão 1.1. As sete linhas que estavam dispon´ıveis e foram utilizadas pelo sistema são 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

(27)

Figura 3.1: Diagrama com os módulos do sistema proposto e as dependências entre eles. volta. Sendo assim, o sistema aqui proposto é capaz de informar não apenas a qual linha pertence um ve´ıculo, mas também qual a dire¸cão percorrida por cada ônibus em opera¸cão. Contudo, é importante ressaltar que o funcionamento do módulo não está atrelado às linhas aqui citadas, podendo quaisquer outras trajetórias serem utilizadas.

A estratégia utilizada para otimizar o acesso das linhas conhecidas foi a utiliza¸cão do dicionário Grid com células de aproximadamente 111m x 111m. A escolha de tamanho da célula foi feita de forma que a área ocupada pelas mesmas fosse suficientemente abran-gente (de aproximadamente um quarteirão), mas que não tornasse excessiva a quantidade de pontos de trajetória em cada célula do grid. De fato, o custo computacional do algo-ritmo de estimativa de linhas é fun¸cão do número registros analisados a cada itera¸cão e dos pontos de rotas conhecidas por célula do grid.

(28)

15 Linha Distˆancia

326(ida) 112,01

864(ida) 45,87

864(volta) 45,93

298 99,56

Tabela 3.1: Distância média entre os pontos das trajetórias de linhas, utilizada para avaliar a viabilidade do tamanho de célula escolhido.

Para definir o valor ótimo do tamanho de célula, também foi analisada a distância média entre os pontos das trajetórias de algumas linhas conhecidas. O resultado, que pode ser observado na tabela 3.1, mostra que, utilizando células de tamanho 111m x 111m, há uma grande probabilidade de que exista ao menos um ponto da trajetória do ˆ

onibus em cada célula. Por esse motivo, é fácil observar que a escolha do tamanho da célula influencia diretamente na qualidade da estimativa de linha realizada pelo sistema. Para garantir que a parametriza¸cão do módulo seja definida de forma consistente, um caso de teste analisando os resultados de diferentes configura¸cões foi adicionado à Se¸cão 4.1.

Outro fator que influenciou a escolha do tamanho de célula foi a conveniência de ser poss´ıvel acessar os dados de uma célula 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 módulo de inferência de linhas deseja obter todas as linhas que passam pela mesma célula onde se encontra o ponto (22.246421,-44.543211), bastaria apenas acessar o dicio-nário Grid passando a string “22.246,-44.543” como chave, pois o módulo de carregamento das linhas conhecidas utiliza a mesma estratégia para construir o dicionário.

Como o módulo de carregamento é executado durante a inicializa¸cão do sistema, não há quaisquer requisitos mais r´ıgidos referentes à sua performance.

3.2 M´

odulo de acesso aos dados do Data Rio

Nesse módulo, são realizadas as requisi¸cões HTTP para o portal de dados DataRio e a carga das informa¸cões no dicionário Ordem, descrito na se¸cão 2.1. É crucial que, dentro de sessenta segundos (per´ıodo estabelecido para que seja feita uma nova requisi¸cão ao DataRio), a carga dos dados seja completa. Se essa condi¸cão não for atendida, haverá

(29)

perda de informa¸cões. Mesmo a carga de dados levando em média 1.6 segundos, valor bem inferior ao limite estabelecido, o sistema monitora o tempo de execu¸cão do módulo e alerta o usuário caso o limite de tempo seja excedido.

3.3 M´

odulo de inferˆ

encia de linhas

Crucial ao sistema, o módulo de inferência é responsável por tentar associar regis-tros inicialmente sem linha (ou de linha anteriormente inferida pela aplica¸cão) a uma das linhas inseridas no sistema pelo módulo de carregamento de linhas. São avaliadas apenas ordens que possuam ao menos cinco (valor parametrizável, denotado por N ) registros já conhecidos, que servirão de referência, e cuja linha associada não tenha sido informada pelo DataRio. A fim de obter o melhor parâmetro para o número de registros conhecidos a serem analisados, foi adicionado um caso de teste focado nessa questão à Se¸cão 4.1.

A razão pela qual o sistema recalcula linhas de uma ordem já inferidas anterior-mente é a possibilidade de um ve´ıculo alterar sua trajetória durante o servi¸co, fato que precisa ser diagnosticado pelo módulo. Como exemplo, é poss´ıvel citar um ônibus sem linha informada que fazia a rota do 512 e, após algum tempo, passou a fazer a rota do 513. Inicialmente, o sistema irá responder que o ônibus pertence à linha 512, mas é necessário que essa informa¸cão seja constantemente recalculada em itera¸cões posteriores para que essa mudan¸ca de trajetória seja percebida o mais rápido poss´ıvel.

A seguir, descreveremos os conceitos utilizados na implementa¸cão dos Algoritmos 1 e 2 responsáveis pela estimativa das rotas dos ônibus em opera¸cão.

Esquema de pontua¸cão. Suponha que sejam utilizados cinco pontos conhecidos da trajetória de uma ordem para que sua linha seja inferida. A análise de cada um destes cinco pontos constitui o que chamamos de rodada e o resultado retornado pelo módulo é composto pela agrega¸cão das pontua¸cões recebidas pelas linhas candidatas em cada rodada. Sendo assim, cada linha candidata recebe, ao final do processamento do m´ o-dulo, uma pontua¸cão que pode ser enxergada como sendo um ´ındice de confiabilidade do resultado. A linha com maior pontua¸cão é associada à ordem analisada.

A soma das pontua¸cões de todas as linhas é necessariamente um valor predetermi-nado, chamado de Pontua¸cão Máxima e denotado por PM, normalmente o de cem pontos.

(30)

17 Pontua¸c˜ao 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 cálculo da Pontua¸cão da Rodada é dado pela fórmula abaixo:

Pr=

PM

N (3.1)

A quantidade de pontos atribu´ıda a cada linha candidata depende da distância entre o ponto em análise e as rotas que passam pela célula do dicionário Grid que contém o registro. O critério de distribui¸cão será descrito nos próximos parágrafos. É importante observar que, devido ao baixo número de linhas conhecidas pelo sistema, muitas vezes as ordens analisadas não compartilham células com linha alguma. Por conta disso, foi introduzido ao sistema o conceito de linha vazia, que pode ser vista como o conjunto de linhas não cadastradas ou inexistentes. A linha vazia recebe pontua¸cão toda vez que não for poss´ıvel atribuir pontos a alguma linha conhecida pelo sistema durante uma rodada.

Distribui¸cão da pontua¸cão. Durante sua execu¸cão, o módulo recebe os N últimos pontos por onde uma determinada ordem passou e os analisa individualmente. Para cada ponto recebido, são obtidas todas as linhas candidatas através do acesso à célula onde se encontra o ponto. Uma linha é considerada candidata quando ao menos um ponto de sua trajetória se encontra na mesma célula em que o ponto sob análise em uma rodada.

Figura 3.2: Exemplo de cálculo da distância ordem-linha, onde os pontos em laranja e azul representam pontos de trajetória de duas linhas conhecidas e o ponto rosa é o ponto sob análise em uma rodada. As linhas tracejadas representam a distância em linha reta entre a ordem e cada uma das linhas.

(31)

O passo executado na sequência é o cálculo da distância entre o registro atual e cada linha candidata, denotada por l. Para calcular essa distância utilizamos as coordenadas do registro p analisado na rodada e um ou mais pontos que compõem a rota da linha l. Caso haja apenas um ponto de l presente na célula do dicionário Grid que contém p, será realizado o cálculo simples de distância ponto a ponto. Caso l possua mais de um ponto de sua trajetória dentro da célula em questão, serão tra¸cados um ou mais segmentos de reta s que conectem os pontos de trajetória (como na trajetória laranja no exemplo ilustrado pela Figura 3.2). No caso de haver apenas um segmento resultante, a distância entre a ordem e a linha será a distância entre este segmento e o registro p. Caso haja mais de um segmento de reta, será calculada a distância entre p e cada um dos segmentos produzidos, sendo a resposta a menor distância encontrada. É importante frisar que, como a trajetória das linhas conhecidas tem seus pontos ordenados temporalmente, os segmentos de reta tra¸cados devem respeitar essa ordena¸cão de modo que somente pontos consecutivos sejam associados.

Algorithm 1 Inferˆencia de Linhas

1: _{function Infere(lista–pontos, P}_M) . 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 pontua¸c˜ao

11: end function

As distâncias calculadas são, então, armazenados temporariamente através de uma rela¸cão (l,d), sendo d a distância entre o registro p e a linha l. A partir dessa rela¸cão, a pontua¸cão da rodada Pr é distribu´ıda entre as linhas candidatas de modo que as linhas

mais próximas ao ponto recebam proporcionalmente maior pontua¸cão do que as linhas de maior distância, sendo esse cálculo feito considerando a soma s de todas as distâncias ordem-linha da rodada. Caso não haja linha candidata, a pontua¸cão completa da rodada

(32)

19 Algorithm 2 C´alculo das pontua¸c˜oes em uma rodada

1: _{function calcula–pontuacao(p, P}_r)

2: linhas–candidatas = linhas contidas na mesma c´elula 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

é dada à linha vazia. A fórmula da distribui¸cão de pontua¸cão entre as linhas candidatas, caso haja mais de uma, é a seguinte:

scoreLinha[l] = (1 − distanciaLinha[l]

s ) ∗ Pr (3.2)

Um dos requisitos do sistema é que ele retorne apenas uma linha como resposta para cada ordem. Sendo assim, será escolhida a linha de maior pontua¸cão ao final das N rodadas, desde que não seja a linha vazia. Essa será considerada apenas caso nenhuma outra linha possua pontua¸cão diferente de zero.

Para o sucesso da execu¸cão do sistema, é necessário que, a cada minuto, todas as ordens que não tenham linha informada pelo DataRio sejam avaliadas ou reavaliadas. Assim, o sistema monitora constantemente a execu¸cão do módulo e alerta o usuário caso o valor tempo limite de sessenta segundos seja ultrapassado sem que todas as ordens sem linha tenham sido analisadas. Durante os testes da versão final do sistema, esse valor nunca foi excedido.

3.4 Disponibiliza¸

c˜

ao dos resultados

Para disponibilizar os dados para usuários externos, foi implementado um servidor capaz de produzir um arquivo JSON no mesmo formato utilizado pelo DataRio, enrique-cido com as informa¸cões de rotas estimadas pelo sistema, permitindo que usuários que atualmente obtém informa¸cões dessa fonte possam migrar para esse sistema sem maior

(33)

esfor¸co, apenas alterando a url consultada.

Para isso, foi necessário utilizar a biblioteca web do Python, que permite a cria¸cão de um servidor web capaz de tratar requisi¸cões HTTP. Como a biblioteca já implementa e pré-configura uma razoável gama de funcionalidades, o trabalho de disponibilizar as informa¸cões computadas pelo sistema se resume à adequa¸cão ao formato JSON. A Figura 3.3 apresenta o código necessário para instanciar o servidor.

Figura 3.3: C´odigo necess´ario para subir o servidor web

Quando o usuário acessa o endere¸co https://<ip>/linhas, lhe é retornado uma fotografia dos últimos registros de cada ordem presente no sistema, de modo semelhante ao realizado pelo DataRio, com a diferen¸ca da adi¸cão de filtros e das linhas inferidas. Para atender tal requisi¸cão, o sistema acessa o dicionario Ordens, faz um percorrimento completo da estrutura adicionando à variável de retorno cada registro encontrado. Após o percorrimento, o retorno é colocado no formato JSON e repassado ao usuário.

Caso a url https://<ip>/linha/<l>, onde l é uma linha de ônibus da cidade, seja acessada, o sistema buscará todas as ordens que atualmente possuam essa linha associada e retornará ao usuário as informa¸cões no mesmo formato JSON já descrito. Para realizar essa consulta, primeiro é acessado o dicionário Linha passando l como chave, o que retorna como resultado todas as ordens associadas a l. Essas linhas são então adicionadas a uma variável temporária de retorno. Em seguida, como o dicionário Linha apenas possui o número das ordens, é necessário consultar o restante das informa¸cões, entre elas a última posi¸cão geográfica registrada. Esse complemento das informa¸cões é feito através do acesso do dicionário Ordem, passando como chave cada uma das ordens. Conforme os dados vão sendo obtidos, a variável de retorno vai sendo atualizada. Tendo obtido todas as informa¸cões necessárias, resta ao sistema apenas formatá-las e retornar a requisi¸cão.

(34)

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 Se¸cão 1.2, foi realizada uma série de testes. Nesse cap´ıtulo, serão descritos os resultados obtidos em três casos de uso, responsáveis por analisar pontos diferentes do projeto.

4.1 Precis˜

ao da estimativa das rotas

A ideia desse primeiro teste consiste em selecionar ordens cujas linhas tenham sido informadas pelo DataRio - ou seja, já conhecidas de antemão - e solicitar que o sistema estime a quais linhas os ve´ıculos estão servindo, baseado nas rotas produzidas pelo trabalho [Padilha 2017]. Tal proposta é interessante pois permite avaliar a confiabilidade da estimativa produzida pelo sistema. Quanto maior for o ´ındice de acertos em rela¸cão ao valor informado pelo DataRio, mais confiável é o cálculo realizado e mais útil é o servi¸co oferecido pela aplica¸cão proposta nesse trabalho.

Esse teste também nos permite analisar qual a sensibilidade do método em rela¸cão aos parâmetros de tamanho de célula e de número de pontos a serem analisados. Dessa forma, o mesmo teste foi executado com parâmetros diferentes, para que fosse poss´ıvel julgar qual configura¸cão funciona melhor para a aplica¸cão.

Para obtermos resultados consistentes, todas as execu¸cões desse caso de teste fo-ram iniciadas às 10:00 do dia 10/07/2017 e encerradas às 12:00 do mesmo dia. Como o objetivo era observar o ´ındice médio de acertos das estimativas, a dura¸cão de duas horas foi suficiente para obter uma amostragem satisfatória para a análise, processando uma

(35)

média de 3000 ve´ıculos por linha. Assim, os parâmetros de configura¸cão usados neste teste podem ser vistos na Tabela 4.1.

Atributo V alor

N´umero de pontos analisados 5,10 e 20

Tamanho de cada c´elula 1111x1111m2 _{e 111x111m}2

Considerar trajet´orias de ida e volta False

Retornar mais de uma possibilidade False

Tabela 4.1: Configura¸c˜ao do caso de teste elaborado com a finalidade de verificar a qua-lidade das estimativas das linhas. Foram feitos testes com diferentes parˆametros.

Para que a execu¸cão do teste fosse poss´ıvel, foi necessário fazer uma altera¸cão no programa de modo que o módulo de inferência de linhas recebesse, além dos pontos de trajetória da ordem, a informa¸cão de linha informada pelo DataRio. Assim, caso a linha informada fosse uma das linhas conhecidas pelo sistema, ele armazenaria o resultado obtido pelo módulo, gravando em um arquivo com a pontua¸cão obtida pela linha e um indicador de sucesso da estimativa (ou seja, armazena se o sistema foi capaz ou não de acertar a inferência da linha).

4.1.1 Resultados obtidos

No fim da execu¸c˜ao dos testes, os dados armazenados foram agrupados e o resultado pode ser observado nos gr´aficos 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 parâmetros de 5 pontos anteriores de trajetória e tamanho de célula como sendo 1111x1111m2_{e 111x111m}2_.

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 células menores. Analisando os dados, percebemos que, com o aumento da célula, a acurácia média aumenta. No entanto, linhas como a 422 e a 326 tiveram seu ´ındice de acerto diminu´ıdo com essa altera¸cão.

Fenômeno semelhante pode ser observado na Figura 4.2, onde são utilizados os parâmetros de 10 pontos anteriores e células de 1111x1111m2 _{e 111x111m}2_{. Como}

(36)

23

Figura 4.1: Resultado da estimativa das linhas. Foram analisados os 5 últimos pontos da trajetória de cada ve´ıculo, com células de tamanhos 1111x1111m2 _{(imagem da esquerda)}

e 111x111m2 _{(imagem da direita).}

mas as linhas 422 e 326 não acompanharam a tendência e novamente perderam acurácia com células maiores.

A Figura 4.3, que representa os ´ındices de acerto com parâmetros de 20 pontos anteriores e células de 1111x1111m2 e 111x111m2 confirma o crescimento no ´ındice de acurácia com o aumento de célula. No entanto, ao compararmos os gráficos presentes nas 3 figuras, é poss´ıvel observar que, conforme o número de pontos analisados aumenta, menor é o ganho em precisão que se tem ao aumentar a área coberta pela célula. Tal observa¸cão pode ser confirmada observando a Tabela 4.2, que permite uma análise quantitativa dos resultados.

Como a análise visual dos gráficos nem sempre possibilita uma avalia¸cão quanti-tativa dos valores exibidos, para definir o conjunto de parâmetros com melhor resultado no teste, foi calculada a média entre as porcentagens de acerto para cada um deles. O resultado pode ser observado na tabela 4.2, onde é poss´ıvel perceber uma melhora na

Figura 4.2: Resultado da estimativa das linhas. Foram analisados os 10 últimos pontos da trajetória de cada ve´ıculo, com células de tamanhos 1111x1111m2 (imagem da esquerda) e 111x111m2 _{(imagem da direita).}

(37)

Figura 4.3: Resultado da estimativa das linhas. Foram analisados os 20 últimos pontos da trajetória de cada ve´ıculo, com células de tamanhos 1111x1111m2 _{(imagem da esquerda)}

e 111x111m2 (imagem da direita).

acurácia da estimativa conforme o número de pontos analisados e o tamanho de célula aumentam. O resultado era esperado no sentido em que os dois parâmetros influenciam diretamente na quantidade de informa¸cão passada ao módulo de inferência de linhas. Em outras palavras, com o aumento do número de pontos de trajetória analisados e do ta-manho de célula, mais insumos são passados ao módulo de inferência e consequentemente melhor é a qualidade do resultado. É importante frisar que o aumento desses parâmetros acarreta em um maior consumo de recursos de memória e processamento, devendo assim seu ajuste ser feito com cautela.

Número de pontos Tamanho de Célula Porcentagem média 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: Rela¸cão parâmetros x Porcentagem média de acerto.

Assim, é poss´ıvel concluir que a eficácia do módulo de inferência de linhas está diretamente atrelada aos parâmetros passados a ele. No entanto, em todas as combina¸cões de parâmetros utilizadas, foram obtidos ´ındices de acerto médio acima de 70%. Para que essa métrica possa ser melhorada, um próximo passo é buscar entender que fatores além da parametriza¸cão influenciam a porcentagem de acertos.

(38)

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 se¸cão anterior apresentaram baixa precisão. Isto é, apesar de a precisão geral da estimativa ser relati-vamente satisfatória, seria interessante descobrir as razões que a fizeram ser mais baixa para algumas linhas para entender se a estimativa poderia ser melhorada.

Um acontecimento que chamou a aten¸cão durante o primeiro caso de teste foi a presen¸ca de pontua¸cões zeradas atribu´ıdas à linha conhecida em algumas estimativas. De acordo com o nosso algoritmo, neste caso, nenhum dos N últimos pontos conhecidos da ordem em questão compartilhou célula do dicionário Grid com pontos da trajetória correta. Esse evento é altamente improvável, mas aconteceu com certa frequência durante as análises. Para entender o problema, decidimos gerar uma visualiza¸cão dos pontos das rotas e dos registros desses ônibus.

Figura 4.4: Trajetória da linha 455 (azul) e pontos de ordens cuja linha informada pelo DataRio era 455, mas que receberam pontua¸cão 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 células de 1111 x 1111m2_.

Observe a Figura 4.4, que compara pontos da rota da linha 455 (em azul) com pontos de trajetória de ordens cuja linha informada pelo DataRio era a própria 455 (em vermelho). Em rela¸cão aos testes realizados, o que difere os pontos em vermelho dos outros registros analisados para esta rota é que a pontua¸cão final da linha 455 atribu´ıda

(39)

a eles foi zero. Isso indica que há alguma inconsistência no teste realizado ou no dado fornecido pelo DataRio. A Figura deixa claro que as ordens, representadas pelos pontos em vermelho, não seguem a rota da linha informada pelo portal.

A primeira hipótese que justificaria tal fato é a de que a trajetória oficial da linha 455 tenha mudado recentemente. Como as rotas de linhas conhecidas foram calculadas utilizando dados de 2016 e essa análise foi realizada em 2017, ano de profundas altera¸cões nas linhas do Rio de Janeiro, é poss´ıvel que as linhas utilizadas por nosso sistema também tenham passado por mudan¸cas. Contudo, de acordo com site [Onilinhas - Itinerarios], a linha 455 permanece com a mesma trajetória aqui utilizada. Não é descartada a hipótese de o site em questão também estar desatualizado.

Figura 4.5: Trajetória da linha 422 (azul) e pontos de ordens cuja linha informada pelo DataRio era também a 422, mas que receberam pontua¸cão zerada para tal linha na estima-tiva (vermelho). Diferente da figura anterior, os pontos em vermelho ficaram concentrados em uma área 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 está re-lacionada ao fato de o módulo de inferência de linhas sempre considerar a última linha informada de uma ordem. Assim, caso uma ordem tivesse sua trajetória alterada, ela ainda assim carregaria consigo no dicionário Ordem os N - 1 pontos da trajetória ante-rior, que seriam considerados na estimativa. No entanto, tal evento não deveria acontecer

(40)

27 com tanta frequência em um per´ıodo de duas horas, dura¸cão do primeiro teste realizado. Também é plaus´ıvel supor que o DataRio tenha fornecido informa¸cões incorretas, informando uma linha quando na verdade a ordem pertence a outra, ou que os ve´ıculos tenham sido for¸cados, por algum motivo, a alterar sua trajetória no per´ıodo do teste. A realiza¸cão de obras na cidade ou questões de seguran¸ca podem ter motivado tais desvios.

Figura 4.6: Mesma compara¸c˜ao da figura 4.5, mas com o teste tendo sido realizado na parte da manh˜a do dia 10/07/2017.

Comparando os resultados das figuras 4.5 e 4.6, onde os pontos em vermelho tam-bém representam a trajetória de ordens cuja linha informada pelo DataRio não obteve pontua¸cão durante os testes, é poss´ıvel formular mais uma teoria que explique o fenômeno. Na figura 4.5, representa¸cão de um teste realizado no final da tarde, é poss´ıvel perceber claramente que os pontos vermelhos estão concentrados em uma região, que poderia ser de garagem. A tese é refor¸cada pela figura 4.6, visualiza¸cão do mesmo teste, mas realizado pela manhã, onde ainda se podem ver muitos pontos concentrados na mesma poss´ıvel região de garagem, mas com outros pontos formando um percurso que liga a garagem à verdadeira trajetória da linha.

De fato, não é poss´ıvel afirmar com certeza o que causou o desvio de algumas ordens em rela¸cão à sua linha informada. No entanto, tal análise é importante para entender os motivos que influenciam a acurácia das estimativas realizadas por nosso sistema. Caso esses pontos de desvio (onde a pontua¸cão final da linha informada foi igual a zero) fossem removidos, a acurácia do sistema melhoraria bastante. Isso é observado na tabela 4.3.

(41)

Número de pontos Tamanho de Célula Acerto Acerto (sem pontua¸cões 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: Rela¸cão parâmetros x Porcentagens médias de acerto, com e sem a elimina¸cão de ordens que tiveram pontua¸cão zero para a linha correta.

4.3 Integra¸

c˜

ao com outros sistemas

Diferente dos outros, esse caso de teste objetiva verificar a capacidade de integra-¸cão desse sistema com outros. Para isso, foi selecionado o aplicativo Trackbus, descrito no trabalho [Rocha e Amaral 2016]. Como uma das funcionalidades do aplicativo é justa-mente exibir, em tempo real, posi¸cões e linhas de ônibus cujas informa¸cões são oferecidas pelo DataRio, o teste pôde ser feito apenas realizando altera¸cões pontuais no código 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 exibi¸c˜ao 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 comunica¸cão entre as duas aplica¸cões, os parâmetros utilizados não tinham tanta relevância para o que se desejava

(42)

29 observar, com exce¸cão da configura¸cão do número de resultados retornados por linha.

Diferente dos outros testes, não estávamos interessados em analisar a precisão da estimativa, mas sim na capacidade do sistema em disponibilizar os resultados obtidos. Para que a integra¸cão funcionasse, era necessário que as informa¸cões fornecidas estivessem exatamente no mesmo formato disponibilizado pelo DataRio. Sendo assim, a configura¸cão utilizada para este teste está listada na Tabela 4.4.

Atributo V alor

N´umero de pontos analisados 5 Tamanho de cada c´elula 111m2

Considerar trajet´orias de ida e volta True Retornar mais de uma possibilidade False

Tabela 4.4: Configura¸c˜ao do sistema no teste de integra¸c˜ao com o sistema TrackBus proposto em [Rocha e Amaral 2016].

Para executar o teste, foi necessário alterar dois pontos no código do aplicativo Trackbus: o trecho de código que acessava informa¸cões de uma linha espec´ıfica e o que bus-cava o último log de todas as linhas presentes na base. Para isso, bastou alterar as URLs utilizadas pelo aplicativo para https://<Endere¸co IP do do sistema>/linha/<Número da linha> e https://<Endere¸co IP do sistema>/linhas, respectivamente.

4.3.1 Resultados obtidos

Inicialmente, verificou-se que a integra¸cão não fora bem sucedida devido a um problema no formato disponibilizado pelo sistema. Após 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 já eram informadas pelo DataRio com a adi¸cão das linhas inferidas pelo sistema que desenvolvemos neste trabalho.

Foi também poss´ıvel observar que o processo de filtragem por número de linha e execu¸cão de outras funcionalidades do aplicativo permaneceram sem altera¸cões 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 aplica¸cões externas.

(43)

Cap´ıtulo 5

Conclus˜

oes

Neste trabalho propusemos um sistema de enriquecimento dos dados fornecidos pelo portal de Dados Abertos DataRio, que tem como principal objetivo estimar a infor-ma¸cão das linhas dos ônibus em servi¸co na cidade do Rio de Janeiro, quando a mesma não é 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 aplica¸cões que dependam dos dados fornecidos pelo DataRio como um componente inter-mediário entre a aplica¸cão e o portal de dados, o que garante maior qualidade dos dados. O código completo desenvolvido durante esse estudo está dispon´ıvel a quem tiver interesse no repositório de link https://github.com/nataliapipas/bus.

Os resultados apresentados mostram que a qualidade das estimativas é acima de 90% nos casos em que os ônibus sem informa¸cão de linha estão seguindo a rota de alguma linha conhecida. Também foi apresentado um estudo dos casos em que o sistema não consegue estimar corretamente as linhas e um estudo de caso do uso do sistema por uma aplica¸cão de celular baseada nos dados do DataRio.

Nos próximos parágrafos discutiremos algumas limita¸cões do sistema e apontare-mos dire¸cões de trabalhos futuros.

(44)

31

5.1 Limita¸

c˜

oes

5.1.1 Escalabilidade

Atualmente, o projeto consegue obter, processar e disponibilizar os dados dentro da janela de tempo estabelecida como limite. Contudo, não estão descartadas as possibilida-des de crescimento da frota de ônibus, aumento no layout das informa¸cões disponibilizadas ou até mesmo adi¸cão de novas funcionalidades à aplica¸cão. Dessa forma, não há garantia de que a performance do programa se manterá aceitável.

Uma solu¸cão para amenizar tal problema seria distribuir o processamento da apli-ca¸cão para que, no caso da necessidade de aumento dos recursos dispon´ıveis, seja poss´ıvel aumentar o número de nós do cluster ao invés de migrar o processamento para uma máquina mais potente, o que seria razoavelmente mais caro. Contudo, tal alternativa demandaria uma reestrutura¸cão da solu¸cão para acomodar a computa¸cão paralela.

5.1.2 Cobertura da cidade

Infelizmente, o baixo número de linhas conhecidas pelo sistema resultou em análises em apenas uma pequena área da cidade. Assim, em um universo de 462 ônibus 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: Propor¸c˜ao de ordens classificadas

Por outro lado, foi poss´ıvel observar nessa análise uma relativamente boa distribui-¸cão das linhas presentes nas classifica¸cões, havendo uma ligeira predominância das linhas 326 (ida) e 455 (volta), como mostra a figura 5.2.

(45)

Observamos no entanto, que essa limita¸cão é causada pela indisponibilidade da informa¸cão das rotas de ônibus 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 ônibus da cidade para a execu¸cão do projeto.

Figura 5.2: Classifica¸c˜ao realizada dos ˆonibus sem linha

5.2 Trabalhos futuros

Talvez o mais relevante trabalho futuro esteja relacionado à adi¸cão de novas rotas conhecidas ao sistema, aumentando a confiabilidade dos resultados obtidos, bem como o volume de linhas inferidas. Tal melhoramento necessitaria da gera¸cão de novas linhas por parte do trabalho mencionado na se¸cão 1.1 ou então a obten¸cão manual de tais linhas.

Também é poss´ıvel a elabora¸cão de novos filtros e tratamentos para a base de dados, tais como os filtros de velocidade, inicialmente descontinuados por esse projeto, ou filtros de localiza¸cão que exibissem apenas ordens próximas ao usuário.

Como esse é um sistema que trabalha com a posi¸cão de todos os ônibus da cidade em tempo real, seria também interessante pensar em algoritmos preditivos capazes de estimar tempos de deslocamento, bem como diagnosticar áreas que não estejam sendo suficientemente cobertas, especialmente no que diz respeito ao fluxo de ônibus.

(46)

33

5.3 Considera¸

c˜

oes finais

A realiza¸cão 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, é 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 até mesmo poss´ıvel amenizar a questão de indisponibilidade do servi¸co atualmente ofertado pelo DataRio.

A integra¸cão com o TrackBus permitiu uma abordagem mais prática do estudo, possibilitando uma valida¸cão em tempo real dos resultados, ainda que em um ambiente controlado. Tal integra¸cão foi altamente relevante para o projeto pois confirma que alte-ra¸cões m´ınimas são necessárias no sistema consumidor para que o sistema fonte passe a ser o descrito aqui e que não há perda de consistência nessa transi¸cão.

Com a chegada de novos trajetos de linha conhecidos, será poss´ıvel obter um re-sultado ainda mais relevante, visto que uma maior área da cidade será coberta. Isso resultará também em maior acurácia dos resultados obtidos, visto que minimiza a chance de o sistema retornar uma linha errada pelo motivo de a linha certa ainda não ter sido cadastrada.

(47)

Referˆ

encias Bibliogr´

aficas

[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 Demogr´afico 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. Informa¸cões sobre linhas de ônibus usando históricos de gps. 2017.

(48)

35 [Raymond e Imamichi 2016]RAYMOND, R.; IMAMICHI, T. Bus trajectory identifica-tion by map-matching. In: IEEE. Pattern Recogniidentifica-tion (ICPR), 2016 23rd Internaidentifica-tional 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 usu´arios 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.