Rnasser

Rafael Barbosa Nasser
Uma Plataforma na Nuvem para Extrao de

Conhecimentos a partir de Dados de Localizao
Georeferenciada de Mobilidade Urbana
Tese de Doutorado
Tese apresentada ao Programa de Psgraduao em Informtica da PUC-Rio como
requisito para obteno do ttulo de Doutor em
Informtica.
Orientador: Prof. Hlio Crtes Vieira Lopes
Rio de Janeiro
Setembro 2016

Uma Plataforma na Nuvem para
Extrao de Conhecimentos a partir de
Dados de Localizao Georeferenciada de
Mobilidade Urbana
Tese apresentada como requisito intermedirio
para obteno do grau de Doutor pelo
Programa de Ps-graduao em Informtica
da
PUC-Rio.
Aprovada
pela
Banca
Examinadora abaixo assinada.
Prof. Hlio Crtes Vieira Lopes

Orientador
Departamento de Informtica PUC-Rio
Prof. Marco A. Casanova
Prof. Carlos Jos Pereira de Lucena
Prof. Jos Antonio Fernandes de Macdo
UFC
Prof. Marcos de Oliveira Lage Ferreira
UFF
Rio de Janeiro, 26 de setembro de 2016
Todos os direitos reservados. proibida a reproduo total ou

parcial do trabalho sem autorizao do autor, do orientador e da
universidade.

O autor Mestre em Informtica e graduado em Engenharia de
Computao pela Pontifcia Universidade Catlica do Rio de
Janeiro (PUC-Rio) com domnio adicional em Empreendedorismo
pela mesma Universidade. Atua como Coordenador Tcnico do
Laboratrio de Engenharia de Software da PUC-Rio, tendo mais de
10 anos de experincias em projetos na rea de tecnologia da
informao.
Ficha Catalogrfica
Nasser, Rafael Barbosa
Uma Plataforma na Nuvem para Extrao de Conhecimentos a
partir de Dados de Localizao Georefernciada de Mobilidade
Urbana / Rafael Barbosa Nasser ; orientador: Hlio Crtes Vieira
Lopes 2016.
137 f. : il. (color.) ; 30 cm
Proposta de Tese (doutorado) Pontifcia Universidade
Catlica do Rio de Janeiro, Departamento de Informtica, 2016.
Inclui bibliografia
1. Informtica Teses. 2. Data Science. 3. Computao na
nuvem. 4. Computao paralela. 5. Geoprocessamento. 6.
Engenharia de software. I. Lopes, Hlio Crtes Vieira. II.
Pontifcia Universidade Catlica do Rio de Janeiro. Departamento
de Informtica. III. Ttulo.
CDD: 004
Aos meus pais, Alberto e Mariana,

que empreenderam minha vida
com amor, sabedoria e suor.
Agradecimentos
Agradeo a minha esposa, Giulianna, meu eterno amor, pelo apoio e carinho
nesses 12 anos, e sem dvida, tambm pela pacincia. Aos meus irmos,
Leonardo e Renato, eternos companheiros. E aos meus filhos, Nina e Theo, que
iluminam diariamente minha vida e que, como esta tese, so frutos desta jornada
de 4 anos.
Agradeo a minha tia, Lilian Nasser, que o sucesso acadmico sempre me
serviu de inspirao, e que sempre esteve disponvel para ajudar. E ao meu tio,
Leibo Kampela, cuja sabedoria sempre estar ao meu lado.
Agradeo ao meu orientador, Prof. Hlio Crtes Vieira Lopes, que trabalha
arduamente e com paixo para consolidar a PUC-Rio como uma referncia
mundial em Data Science e que soube me motivar e administrar. Espero sempre
retribuir seu apoio com resultados. Agradeo tambm ao Prof. Marcos Antonio
Casanova, meu eterno orientador, por sempre me incentivar.
Agradeo ao Bruno Guberfain do Amaral, pela parceria em artigos e
trabalhos nos ltimos anos. E ao Gustavo Carvalho que possibilitou, com seu
apoio profissional e pessoal, minha dedicao a este projeto.
Agradeo tambm a Microsoft pelo fornecimento de crditos para execuo
dos experimentos e a CAPES e ao CNPq pelo apoio aos meus estudos.
Por ltimo, agradeo a PUC-Rio pelos auxlios concedidos e a todos os
professores do Departamento de Informtica, cujo convvio, ano a ano, torna-se
cada vez mais gratificante.
Resumo
Nasser, Rafael Barbosa; Lopes, Hlio Crtes; Uma Plataforma na
Nuvem para Extrao de Conhecimentos a partir de Dados de
Localizao Georefernciada de Mobilidade Urbana. Rio de Janeiro,
2016, 137 p. Tese de Doutorado Departamento de Informtica, Pontifcia
Universidade Catlica do Rio de Janeiro.
A qualidade de vida nos grandes centros urbanos tem sido motivo de
preocupao para governantes, empresrios e para a populao residente em geral.
Os servios de transporte pblico coletivo exercem papel central nessa discusso,
uma vez que determinam, sobretudo para aquela camada da sociedade de menor
poder aquisitivo, o tempo desperdiado diariamente em seus deslocamentos. Nas
metrpoles brasileiras, os nibus municipais so predominantes no transporte
coletivo. Os usurios deste servio passageiros no possuem informaes
atualizadas quanto ao trajeto das linhas de nibus, no dispem de uma tabela de
horrios para planejarem suas viagens e muito menos conhecem o tempo estimado
de chegada em seu destino final. Oferecer essa natureza de informao contribui
para uma melhor experincia de uso dirio deste modal e, consequentemente,
proporciona maior qualidade de vida aos seus usurios. Em uma viso mais
abrangente, os nibus podem ser considerados sensores que viabilizam a
compreenso dos padres e identificao de anomalias no trfego de veculos nas
reas urbanas, possibilitando galgar benefcios para toda populao. O presente
trabalho apresenta uma plataforma na nuvem que captura, enriquece, armazena e
disponibiliza os dados dos dispositivos de GPS instalados nos nibus, permitindo
a extrao de conhecimento a partir deste valioso e volumoso conjunto de
informaes. Experimentos so realizados com os nibus do Municpio do Rio de
Janeiro, com aplicaes focadas no passageiro e na sociedade. As metodologias,
discusses e tcnicas empregadas ao longo do trabalho podero ser reutilizados
para diferentes cidades, modais e perspectivas.
Palavras-chave
Informtica; Engenharia de Software; Data Science; Computao na
Nuvem; Computao Paralela; Geoprocessamento; Mobilidade Urbana.
Abstract
Nasser, Rafael Barbosa; Lopes, Hlio Crtes; Computer Science;
Software Engineering; Data Science; Cloud Computing; Parallel
Computing; Geoprocessing; Urban Mobility.. Rio de Janeiro, 2016, 137
p. Tese de Doutorado Departamento de Informtica, Pontifcia
Universidade Catlica do Rio de Janeiro.
The quality of life in urban centers has been a concern for governments,
business and the resident population in general. Public transportation services
perform a central role in this discussion, since they determine, especially for that
layer of lower-income society, the time wasted daily in their movements. In
Brazilian cities, city buses are predominant in public transport. Users of this
service - passengers - do not have updated information of the bus lines routes, do
not have a timetable to plan your trips and much less know the estimated time of
arrival at your final destination. Offer this kind of information contributes to a
better everyday experience of this modal and therefore provides greater quality of
life for its users. In a broader view, the bus can be considered sensors that enable
the understanding of the patterns and identify anomalies in vehicle traffic in urban
areas, allowing benefits for the whole population. This work presents a platform
in the cloud that captures, enriches, stores and makes available the data from GPS
devices installed on buses, allowing the extraction of knowledge from this
valuable and voluminous set of information. Experiments are performed with the
buses of the Municipality of Rio de Janeiro, with applications focused on
passenger and society. The methodologies, discussions and techniques used
throughout the work can be reused for different cities, modal and perspectives.
Palavras-chave
Computer
Science;
Software
Engineering;
Data
Science;
Computing; Parallel Computing; Geoprocessing; Urban Mobility.
Cloud
Sumrio
1 Introduo ............................................................................................13
1.1 Motivao .........................................................................................13
1.2 Data Science ....................................................................................15
1.3 Conhecimentos Extrados.................................................................17
1.4 Principais Contribuies ...................................................................18
1.5 Desafios Enfrentados .......................................................................19
1.6 Trabalhos Relacionados ...................................................................20
1.7 Organizao do Trabalho .................................................................21
2 Compreendendo o Domnio e os Dados Disponveis ..........................23
2.1 Mobilidade Urbana e Transporte Pblico Coletivo ...........................23
2.2 nibus Municipal do Rio de Janeiro .................................................25
2.3 Lei de Acesso Informao .............................................................26
2.4 Dados Abertos ..................................................................................27
2.5 Dados Abertos no Municpio do Rio de Janeiro ...............................30
2.6 Dados Abertos sobre os nibus do Municpio do Rio de Janeiro ....30
3 Coleta, Armazenamento e Visualizao Bsica dos Dados ................37
3.1 Dados Armazenados ........................................................................37
3.2 Coleta dos Dados .............................................................................41
3.3 Visualizao Bsica dos Dados........................................................43
4 A Plataforma ........................................................................................47
4.1 Objetivo.............................................................................................47
4.2 Computao na Nuvem ....................................................................47
4.3 Estratgia de Armazenamento e Anlise dos Dados .......................48
4.4 Arquitetura ........................................................................................57
4.5 Comunicao com a Plataforma.......................................................59
4.6 Solues Clientes da Plataforma......................................................63
5 Extraindo Conhecimento dos Dados sobre o Trfego .........................64
5.1 Seleo de Segmentos.....................................................................64
5.2 Checagem do Segmento Selecionado .............................................71
5.3 Identificao das Trajetrias dos nibus pelo Segmento ................76
5.4 Anlise Descritiva das Trajetrias ....................................................86
5.5 Identificao de Padres para os Segmentos ..................................88
5.6 Monitoramento do Trfego em Segmentos ......................................95
5.7 Anlise Cruzada de Segmentos .......................................................96
5.8 Correo do Erro de GPS e Clculo de Cumprimento .....................98
5.9 Identificao da Situao (Operando ou no) ..................................99
5.10 Nmeros do Servio de nibus ......................................................100
5.11 Extrao de Rotas das Linhas de nibus ......................................107
6 Tomando Deciso com Dados ..........................................................113
6.1 O Aplicativo.....................................................................................113
6.2 Informaes Bsicas ......................................................................114
6.3 Agregando Informaes .................................................................121
6.4 Informaes do Servio ..................................................................123
6.5 Conhecendo o Trfego ...................................................................126
6.6 Processo de Tomada de Deciso com o App ................................128
7 Concluso ..........................................................................................129
7.1 Descobertas e Contribuies..........................................................129
7.2 Lies Aprendidas ..........................................................................129
7.3 Limitaes.......................................................................................130
7.4 Trabalhos Futuros...........................................................................130
Bibliografia...............................................................................................132
Lista de figuras
Figura 1 Ciclo de atividades envolvidas em projetos de Data Science
Figura 2 Escala de valorizao dos dados (Gartner 2016)
Figura 3 Evoluo dos Principais Modais do Transporte Coletivo
Figura 4 Diviso Territorial do RJ pelos Consrcios de nibus
Figura 5 Diagrama do GTFS
Figura 6 Tela de Filtros Desenvolvida para Visualizao Bsica
Figura 7 Visualizao da ltima posio conhecida
Figura 8 Visualizao da posio com at 10 minutos de atraso
Figura 9 Visualizao da linha 125
Figura 12 Visualizao da linha 390 com pontos de parada
Figura 13 Visualizao das 5 ltimas posies
Figura 14 Um registro do dispositivo de GPS.
Figura 15 Arquitetura da Plataforma na Nuvem
Figura 16 Discretizao OpenStreetMap da Rua Jardim Botnico
Figura 17 Visualizao de polgono inconsistente do OpenStreetMap
Figura 18 Regio que delimita a Rua Jardim Botnico
Figura 19 Trajetrias prximas ao segmento Rua Jardim Botnico
Figura 20 Trajetrias dentro da regio do Rua Jardim Botnico
Figura 21 Segmento Rua Jardim Botnico (Humait => Gvea)
Figura 22 Segmento Rua Jardim Botnico (Gvea =>Humait)
Figura 23 Exemplo de dados de segmentos
Figura 24 Tela inicial do software BusesInRio WinDemo
Figura 25 Visualizao de uma linha de nibus no WinDemo
Figura 26 Visualizao de uma trajetria no WinDemo
Figura 27 Visualizao de um segmento no WinDemo
Figura 28 Dados histricos de GPS em um segmento no WinDemo
Figura 29 Dados histricos de GPS em uma hora no WinDemo
Figura 30 Diagrama do algoritmo de descoberta de trajetrias
Figura 31 Trajetrias da data sobre um segmento no WinDemo
Figura 32 Trajetrias na data/segmento iniciadas as 10h
Figura 33 Trajetria especfica sobre um segmento no WinDemo
Figura 34 Trajetria no WinDemo ilustrando uma situao
Figura 35 Projeo ortogonal
Figura 36 Projeo ortogonal vivel e invivel
Figura 37 Pseudo algoritmo projeo ortogonal de p3 na reta p1-p2
Figura 38 Triangulo esfrico resolvido pela lei de Haversine
Figura 40 Informaes adicionais da trajetria no WinDemo
Figura 41 Grfico durao x percurso da trajetria no WinDemo
Figura 42 Dados das trajetrias por horrio no WinDemo
Figura 43 Escala de cores para os segmentos em funo do trfego
Figura 44 Escala de cores para o segmento s 10 horas
Figura 45 Velocidade Rua Jardim Botnico (Humait => Gvea)
Figura 46 Velocidade Rua Jardim Botnico (Gvea => Humait)
Figura 47 Velocidade Rua So Clemente
Figura 48 Velocidade Rua Voluntrios da Ptria
15
16
25
26
33
43
44
44
45
45
46
46
46
54
58
65
66
67
68
68
69
69
70
71
73
73
74
75
75
77
78
79
79
80
81
81
82
82
83
84
85
86
87
87
88
89
89
89
Figura 49 Velocidade Av. Ns. Sra. de Copacabana

Figura 50 Velocidade Rua Barata Ribeiro
Figura 51 Velocidade ao Longo dos Dias da Semana
Figura 52 Velocidade ao Longo das Horas das Sextas-feiras
Figura 53 Velocidade ao Longo das Horas dos Domingos
Figura 54 Linhas Total x Operando nas Segundas-feiras
Figura 55 Linhas Total x Operando nas Teras-feiras
Figura 56 Linhas Total x Operando nas Quartas-feiras
Figura 57 Linhas Total x Operando nas Quintas-feiras
Figura 58 Linhas Total x Operando nas Sextas-feiras
Figura 59 Linhas Total x Operando nos Sbados
Figura 60 Linhas Total x Operando nos Domingos
Figura 61 Linhas Total x Operando com Linha de Tendncia
Figura 62 nibus Total x Operando nas Segundas-feiras
Figura 63 nibus Total x Operando nas Teras-feiras
Figura 64 nibus Total x Operando nas Quartas-feiras
Figura 65 nibus Total x Operando nas Quintas-feiras
Figura 66 nibus Total x Operando nas Sextas-feiras
Figura 67 nibus Total x Operando nos Sbados
Figura 68 nibus Total x Operando no Domingo
Figura 69 nibus Total x Operando com Linha de Tendncia
Figura 70 Distribuio nibus Operando nas Horas
Figura 71 Registros selecionados da linha 432 em 02/09/2016
Figura 72 Pares discritizando arruamentos dentro da regio
Figura 73 Pares candidatos a discritizar a linha de nibus
Figura 74 Pares candidatos aps novo filtro
Figura 75 Descritizao da linha 432
Figura 76 Destaque de trecho que deve pertencer a rota
Figura 77 Descritizao da linha 432 em 02/09/2016
Figura 78 Tela inicial do iPhone com cone do BusesInRio App
Figura 79 Tela inicial do BusesInRio App
Figura 80 Telas com lista de linhas de nibus
Figura 81 Tela apresentando detalhes de uma linha
Figura 82 Telas apresentando um nibus da linha selecionado
Figura 83 Telas com informaes dos nibus selecionados
Figura 84 Telas com lista de nibus
Figura 85 Telas com visualizao de nibus operando e no
Figura 86 Telas com detalhes do registro de um nibus
Figura 87 nibus prximos da minha localidade atual
Figura 88 Retorno em JSON da API do Google
Figura 89 Tabela com Dados Histricos no App
Figura 90 Tela com Grficos de Dados Histricos
Figura 91 Dados de Data Especfica no App
Figura 92 Monitor do Trfego no App
Figura 93 Velocidade Corrente do Segmento no App
90
90
91
91
92
101
101
102
102
102
103
103
103
104
104
104
105
105
105
106
106
107
108
109
110
110
111
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
125
126
127
Lista de tabelas
Tabela 1 Posio dos nibus
Tabela 2 Pontos de parada das linhas do nibus
Tabela 3 Coordenadas dos trajetos das linhas de nibus
Tabela 4 Arquivos do GTFS
Tabela 5 Viso geral do histrico da posio dos nibus
Tabela 6 Viso geral dos Pontos de Parada e Trajetos dos nibus
Tabela 7 Arquivo ltimas 5 posies conhecidas de cada nibus
Tabela 8 Arquivo histrico de posies dos nibus
Tabela 9 Arquivo linhas de nibus
Tabela 10 Arquivo pontos de parada das linhas de nibus
Tabela 12 Campos da tabela de log
Tabela 13 Tecnologias para armazenamento e processamento
Tabela 14 Resumo das percepes e decises
Tabela 15 Campos do arquivo poligonos-nomes.txt
Tabela 16 Campos do arquivo poligonos-coordenadas.txt
Tabela 17 Campos do arquivo segmentos.txt
Tabela 18 Clculo Velocidade Mdia Padro para 31/08/2016
Tabela 19 Clculo Velocidade Mdia Padro para 31/08/2016 em A
Tabela 20 Destaque comparao A x C
31
31
32
32
34
35
37
38
39
39
40
41
51
56
65
65
70
94
97
97
13
1
Introduo
1.1
Motivao
O congestionamento no trfego em reas urbanas com certeza um grande
problema, principalmente porque ele causa um enorme prejuzo econmico.
Vrios esforos no mundo tm sido feitos para melhor controlar o trfego e
planejar a mobilidade em cidades [1]. Uma possvel soluo para diminuir os
congestionamentos nas cidades prover um sistema pblico de transporte
eficiente, pois ele pode desempenhar um papel extremamente importante nas
grandes cidades. Em [2], os autores mencionam que as principais razes desse
importante papel so porque ele reduz o custo de transporte, oferece um servio
para toda a sociedades e, ainda, economiza energia.
O sistema de transporte pblico na Cidade do Rio de Janeiro
historicamente deficiente, principalmente porque baseado em um antigo sistema
de nibus. Para mudar esse estado, a Prefeitura fez algumas iniciativas, tal como o
desenvolvimento de um projeto de dados abertos que disponibiliza na web, a cada
minuto, a posio instantnea de todos os nibus na cidade. Apesar de no ser
uma tecnologia nova uma primeira iniciativa a ser desenvolvida no Rio. Nesse
trabalho constitumos um imenso conjunto de dados de posies de GPS (mais de
3 bilhes de entradas) de todos os nibus que operaram na cidade desde Junho de
2014. Esses dados foram adquiridos no portal de dados abertos da Prefeitura [6].
Esse portal no armazena o histrico de dados, somente disponibiliza as posies
correntes dos nibus.
Podemos considerar que esses dados de GPS, que so transmitidos de
minuto em minuto, representam sensores mveis de trfego da Cidade. Mais
ainda, as trajetrias desses nibus podem ser entendidas como um data stream
continuamente gerados.
Como a cidade do Rio de Janeiro possui uma rede densa de nibus, as
trajetrias adquiridas formam uma base de dados muito til para anlise de
trfego. De fato, essas trajetrias formam uma fonte estvel de dados pois os
nibus percorrem uma rota fixa nas ruas da cidade, em intervalos de tempo
14
regulares, quando as condies de trfego permitem. Portanto, esses dados podem
ser utilizados na deteco de anormalidades no trafego.
Este trabalho apresenta uma plataforma na nuvem que captura, enriquece,
armazena e disponibiliza os dados dos dispositivos de GPS instalados nos
nibus, permitindo a extrao de conhecimento a partir deste valioso e volumoso
conjunto de dados. Em uma viso geral, essa plataforma:
Captura, de forma automtica, continuada e estvel, os conjuntos de
dados disponibilizados no Portal de Dados Abertos da Prefeitura do Rio de
Janeiro sobre o servio nibus do municpio da Cidade, em especial, as posio
dos veculos, discretizao dos trajetos das linhas de nibus e seus pontos de
parada, alm de outras informaes, como, por exemplo, as tarifas cobradas.
Enriquece os dados histricos acumulados e os recm capturados,
transformando, desta forma, dados em conhecimentos. A arquitetura implantada
permite que novas estratgias, algoritmos e servios sejam desenvolvidos,
favorecendo assim a extrao de novos conhecimentos quando desejado.
Armazena esses conjuntos de dados e os conhecimentos extrados de
forma a racionalizar o uso de recursos computacionais e otimizar o tempo de sua
recuperao buscando, assim, um bom equilbrio entre essas perspectivas.
Disponibiliza os dados, informaes e conhecimentos neste mbito,
atravs de um conjunto de servios, viabilizando o desenvolvimento de solues
clientes que os consumam. Tais solues podem adotar distintas tecnologias,
ambientes (e.g. web, desktop e mvel), objetivar o atendimento a diferentes
pblicos (e.g. usurio, populao, governantes e empresrios de nibus) e, ainda,
visar a extrao de conhecimentos adicionais, possivelmente agregando outras
fontes de dados (e.g. sua localizao com um smartphone).
Em outras palavras, essa plataforma apoia a realizao de atividades de
Data Science, conforme detalhado nas sees que se seguem, i.e. a transformao
dos dados brutos sobre os nibus em conhecimentos relevantes.
Cabe ressaltar que as metodologias, discusses e tcnicas empregadas ao
longo do trabalho podero ser reutilizados para diferentes cidades, modais e
perspectivas.
15
1.2
Data Science
A rea de Data Science tem como objetivo transformar dados em
informao e informao em conhecimento [7]. Se pauta no uso de mtodos
computacionais para fazer descobertas valiosas e prticas a partir de conjuntos de
dados brutos. Para tanto, envolve uma ampla gama de atividades, tal como
indicado pelo ciclo apresentado na Figura 1.
Figura 1 Ciclo de atividades envolvidas em projetos de Data Science

Atualmente Data Science integra conhecimento gerado por vrias outras
reas de conhecimento (Matemtica, Probabilidade e Estatstica, por exemplo).
Em particular, na prpria Cincia da Computao ela abrange diversas subreas,
que esto listadas em ordem alfabtica: Aprendizado de Mquina, Banco de
Dados, Computao de Alta Performance, Computao Grfica, Engenharia de
Software, Inteligncia Artificial, Interao Humano-Computador, Otimizao,
dentre outras.
No universo onde os dados so intensamente gerados, eles se tornam um
ativo crucial, e a rea de Data Science est impulsionando novas pesquisas [8],
novas formas de se fazer negcios [9] e uma nova formao acadmica [10].
O principal objetivo de um projeto em Data Science consiste em otimizar
processos e apoiar melhores tomadas de deciso informadas por dados, gerando
um aumento de valor a eles [11].
O Instituto Gartner [12] resumiu num grfico, apresentado na Figura 2, uma
escala de valorizao dos dados medida que a sua anlise se torna mais
16
sofisticada. Nessa figura, o Instituto Gartner lista quatro diferentes tipos de
anlise de dados:
1. Anlise Descritiva: faz um exame dos dados para responder a pergunta
O que aconteceu? (ou O que est acontecendo?). Usa muitos conceitos de
Business Inteligence (BI) e de explorao visual dos dados.
2. Anlise Diagnstica: o tipo de anlise que examina os dados a fim de
responder a pergunta Porque isso aconteceu? e caracterizada pelo uso de
tcnicas tais como minerao dos dados e correlaes.
3. Anlise Preditiva: um tipo de anlise avanada dos dados que examina
os dados para responder O que mais possivelmente vai acontecer?. Essa anlise
caracterizada pelo uso de tcnicas de forecasting e de aprendizado de mquina.
4. Anlise Prescritiva: o tipo mais avanado de anlise de dados cujo
objetivo examinar os dados a fim de responder O que pode ser feito? ou O
que podemos fazer para que isso acontea?. caracterizada por uso de tcnicas
tais como anlise em grafos, simulao, processamento de eventos complexos,
sistemas de recomendao, heursticas e aprendizado de mquina.
Figura 2 Escala de valorizao dos dados (Gartner 2016)

O presente trabalho no se limita ao desenvolvimento de uma plataforma na
nuvem para extrao de conhecimentos a partir de dados de localizao
georeferenciada de mobilidade urbana. Contemplando tambm a efetiva extrao
17
de um conjunto de conhecimentos, no campo das anlises descritivas e
diagnsticas, visando suportar melhores tomadas de deciso a partir de dados,
conforme detalhamos a seguir.
1.3
Conhecimentos Extrados
A qualidade de vida nos grandes centros urbanos tem sido motivo de
preocupao para governantes, empresrios e para a populao residente em geral.
Os servios de transporte pblico coletivo exercem papel central nessa discusso,
uma vez que determinam, sobretudo para aquela camada da sociedade de menor
poder aquisitivo, o tempo desperdiado diariamente em seus deslocamentos. Nas
metrpoles brasileiras, os nibus municipais so predominantes no transporte
coletivo.
Compreender melhor este servio e os padres de trfego das principais
vias urbanas pode certamente ajudar na tomada de decises melhores, que vo da
simples escolha do melhor horrio para se sair de casa ao complexo planejamento
deste servio.
Em particular, os usurios deste servio passageiros no possuem
informaes atualizadas quanto ao trajeto das linhas de nibus, no dispem de
uma tabela de horrios para planejarem suas viagens e muito menos conhecem o
tempo estimado de chegada em seu destino final. Oferecer essa natureza de
informao contribui para uma melhor experincia de uso dirio deste modal e,
consequentemente, proporciona maior qualidade de vida aos seus usurios.
O presente trabalho apresenta tambm o uso da Plataforma desenvolvida
na transformao desse imenso conjunto de dados - posies de GPS (mais de 3
bilhes de entradas) de todos os nibus que operaram na cidade do Rio de Janeiro
desde Junho de 2014 e demais dados disponibilizados deste servio - em
conhecimentos, visando:
Disponibilizar informaes aos usurios sobre o servio em operao;
Dar transparncia populao das caractersticas histricas do servio;
Descobrir os padres de trfego nas principais vias da Cidade;
18
Identificar a situao do trfego das principais vias da Cidade.
Certamente o conjunto de conhecimentos extrado apenas uma pequena

amostra do potencial destes dados e dos benefcios da Data Science, mas
permitem validar o uso Plataforma em cenrios reais e contribuir com uma melhor
compreenso do potencial destes dados.
1.4
Principais Contribuies
As principais contribuies deste trabalho so:
Coleta e armazenamento de dados de posies de GPS (mais de 3

bilhes de entradas) de todos os nibus que operaram na cidade desde
Junho de 2014 e outras informaes sobre o servio de nibus (pontos
de parada, discretizao das linhas e outras), conforme detalhado no
prximo captulo, que agora estaro disponveis para subsidiar estudos e
pesquisas futuras.
Conceituao, aplicao e anlise da viso de que os dados de GPS dos

nibus, que so transmitidos de minuto em minuto, podem representar
sensores mveis de trfego na cidade e de que as trajetrias desses
nibus podem ser entendidas como um data stream continuamente
gerados pelos equipamentos dos nibus.
Proposio, desenvolvimento e validao de uma plataforma na nuvem

para extrao de conhecimentos a partir de dados de localizao
georefernciada de mobilidade urbana.
Algoritmo para seleo de segmentos que representem as principais vias

da cidade passveis de monitoramento pelos sensores acima citados.
Algoritmo para extrao das trajetrias desses nibus sobre os

segmentos em questo, derivando identificadores e padres, incluindo
exemplos de anlises possveis.
Algoritmo para monitoramento do trfego cruzando a situao corrente

com a esperada.
Desenvolvimento de software desktop para visualizao destes dados

georeferenciados, que pode ser reutilizado para diferentes contextos.
19
Desenvolvimento de aplicativo mvel para consumo dos servios desta

Plataforma, agregando caractersticas do dispositivo.
1.5
Desafios Enfrentados
Esse trabalho venceu obstculos significativos, dentre os quais se destacam:
Dados georeferenciados sem serem visualizados so de difcil
compreenso, alm disso, muitas vezes essa compreenso s obtida ao visualizlos e analis-los de forma conjunta e ordenada. Inclusive, pode ser fazer
necessrio confront-los a padres conhecidos, como o arruamento da cidade.
Desenvolver um software para visualizao dos dados da Plataforma foi
fundamental para suportar o processo de criao dos algoritmos e para
compreender estes dados.
Considerando que: (i) parte relevante dos registros dos nibus no
informavam o nmero da linha; (ii) a maioria das linhas de nibus no possuem
rotas conhecidas; (iii) os dispositivos de GPS apresentam erros intrnsecos na
ordem de 100 metros (em funo das edificaes, este tende a ser maior nas reas
urbanas); (iv) existem pontos cegos para os dispositivos; e (v) possivelmente
ocorrem falhas na entrega dos dados pela Prefeitura ou pelas concessionrias.
Identificar a trajetria dos nibus uma tarefa extremamente complexa. O
algoritmo implementado se pauta pela segmentao da Cidade e realiza diversas
testagens para assegurar a consistncia das trajetrias descobertas. Seu
desenvolvimento demandou inmeras visualizaes com dados reais e
aperfeioamentos sucessivos para alcanar resultados consistentes.
Trabalhar com grande volume de dados exige significativo esforo
computacional, tanto para seu armazenamento quanto manipulao. Desenvolver
a Plataforma em um ambiente de computao em nuvem foi fundamental para
alcanar um bom equilbrio entre custo e performance.
Outros desafios enfrentados ao longo do trabalho culminaram em decises
estratgicas, das quais merecem registro:
Nossa premissa de que um nmero relevante dos registros dos dispositivos
de GPS dos nibus no informavam a linha para a qual o nibus estava servindo
no se confirmou, pois de fato a situao onde esse cenrio se apresenta
20
justificava-se pelo nibus em questo no estar operando, o que foi possvel
concluir com a extrao deste conhecimento a partir dos dados.
O intervalo com que os dados so coletados no permitiu a definio de
uma estratgia conclusiva para identificao de pontos de parada, assim como, os
pontos de parada informados pela Prefeitura se mostraram inconsistentes. Dessa
forma, o estabelecimento de tabelas de horrios para pontos de parada se mostrou
um desafio inatingvel a partir destes dados. As tabelas de horrio podem ser
pensadas a partir da lgica de segmentos, porm esse foco no se mostrou to
atrativo quanto outras abordagens implementadas neste trabalho.
A estratgia adotada a partir da segmentao da cidade permite estimar o
tempo de deslocamento dentro destes segmentos com boa preciso, no entanto
para clculo do tempo estimado de chegada seria necessrio calcular todos os
segmentos presentes na linha. Como no perodo de desenvolvimento deste
trabalho o Google investiu fortemente nesta funcionalidade para atendimento aos
Jogos Olmpicos, o foco neste servio foi retirado dos objetivos do trabalho.
Inclusive, o Google disponibiliza uma API para acesso a esses dados.
1.6
Trabalhos Relacionados
O presente trabalho teve como inspirao inicial [13], que de forma muito
visual atraiu ateno para os dados de GPS disponibilizados pela Prefeitura do Rio
de Janeiro em relao aos nibus municipais da Cidade. Essas visualizaes se
restringiram ao comportamento de algumas linhas de nibus, com rotas
previamente conhecidas. Tais visualizaes foram processadas individualmente
em mquina local, a partir de subconjuntos pr-selecionados dos dados. Em [14]
outras anlises e visualizaes so propostas a partir de um pequeno subconjunto
destes mesmos dados, tambm fortemente amparadas nas linhas de nibus.
Extrapolando o universo dos nibus e suas linhas, existem diversas
pesquisas e sistemas para monitorar e visualizar trajetrias (i.e. sequencia
ordenada de pares de informao temporal e espacial, tais como timestamp e
latitude/longitude). So exemplos: [15] que utiliza dados de trajetrias de txis
para gerar relatrios de monitoramento do trfego da cidade, [16] e [17], onde so
apresentas solues web para visualizar e analisar as condies do trfego e suas
21
tendncias, [18] que estima o estado do trfego a partir de sensores em carros,
[19] que prope uma visualizao em mltiplos nveis, alm de [20], [21] e [22].
De igual forma, muitos trabalhos fazem uso de outras fontes de dados para
enriquecer a anlise destas trajetrias, tais como [23] e [24] que descrevem um
sistema de monitoramento de frotas de caminhes usando o Twitter e [25] que
utiliza vdeos das autoestradas.
Do ponto de vista de tempo estimado de chegada, tambm possvel
localizar muitos trabalhos na literatura, sendo [26] apenas um exemplo. Tambm
podemos exemplificar um trabalho relacionado a tabelas de horrios, a citar [27].
A literatura em relao a deteco e avaliao de anomalias no trfego
muito rica, cabendo destaque para [28], [29], [30], [31], [32], [33], [34], [35],
[36], [37], [38], [39] e [40]. Outra perspectiva interessante a clusterizao de
trajetrias, tratadas, por exemplo, em [41], [42], [43], [44] e [45]. Por ltimo,
outros estudos relacionados so igualmente interessantes, a saber: [46], [47] e
[48].
Diferente dos trabalhos mencionados, este objetiva a construo de um
alicerce slido a Plataforma para que conhecimentos sejam extrados a partir
do conjunto integral de dados capturados e no apenas um subconjunto. No se
limitando a algumas experimentaes, como na maioria dos trabalhos citados, mas
permitindo que servios sejam instanciados de forma a extrair continuamente
conhecimentos relevantes dos dados. Tambm se diferencia pelo uso de servios
na nuvem e seu potencial de processamento distribudo, como explorado em [79].
Alm disso, espera-se instrumentar este processo com algoritmos relevantes
implementados para os dados da Cidade do Rio de Janeiro, incluindo formas de
visualizao e consumo destes conhecimentos.
1.7
Organizao do Trabalho
O presente trabalho se encontra estruturado em 8 captulos, a saber:
Introduo (Captulo 1): Apresenta de forma concisa a motivao,
contribuies e desafios do presente trabalho, assim como os trabalhos
relacionados, a organizao do documento e os objetivos complementares do
trabalho.
22
Compreendendo o Domnio e os Dados Disponveis (Captulo 2):
Discorre sobre a mobilidade urbana, o transporte pblico coletivo e os nibus
municipais do Rio de Janeiro, fornecendo informaes relevantes sobre os
mesmos. Resume a Lei de Acesso Informao e tambm o conceito de dados
abertos, assim como sua aplicao neste domnio. Por ltimo, detalhamos os
dados disponveis sobre os nibus municipais da Cidade.
Coleta, Armazenamento e Visualizao Bsica dos Dados (Captulo 3):
Apresenta o processo de coleta de dados, assim como a forma com que os
mesmos so armazenados. Utilizando um website desenvolvido so realizadas as
primeiras visualizaes bsicas dos dados, para melhor compreend-los.
A Plataforma (Captulo 4): Contextualiza o objetivo da Plataforma e o
conceito de computao em nuvem, justificando seu uso. A arquitetura da
Plataforma detalhada, sendo explicado seus servios e mtodos de comunicao
disponveis, assim como, so apresentadas de forma geral as solues clientes da
Plataforma, desenvolvidos no mbito deste trabalho.
Extraindo Conhecimento dos Dados sobre o Trfego (Captulo 5): Esse
captulo explora com profundidade a descoberta de conhecimento a partir dos
dados, detalhando como cada conhecimento extrado. A seleo de segmentos, a
extrao de trajetrias e deteco da situao de um nibus so alguns exemplos
dos algoritmos apresentados.
Tomando Deciso com Dados (Captulo 6): Os servios disponibilizados
pela Plataforma so explorados em uma aplicao para dispositivos mveis. Esta
oferece funcionalidades populao e aos usurios do servio de nibus, que
agregam
caractersticas
do
prprio
dispositivo,
evidenciando
assim,
multiplicidade de usos da Plataforma.

Concluso (Captulo 7): Neste captulo revisitamos as descobertas e
analisamos as lies aprendidas, limitaes e perspectivas futuras do trabalho.
Bibliografia (Captulo 8): Coletnea de artigos , livros e sites relevantes
aos assuntos tratados no mbito deste trabalho.
23
2
Compreendendo o Domnio e os Dados Disponveis
2.1
Mobilidade Urbana e Transporte Pblico Coletivo
A populao do Brasil vive 84,4% em reas urbanas, segundo o censo
demogrfico de 2010 do Instituto Brasileiro de Geografia e Estatstica [49].
Dentro deste espao, os servios de transporte pblico coletivo exercem
papel fundamental, uma vez que determinam, sobretudo para as classes
desfavorecidas, o grau de praticidade dos seus deslocamentos dirios. Pesquisa do
Instituo de Pesquisa Econmica e Aplicada [50] indica que o transporte pblico
coletivo o meio de transporte mais utilizado pelos brasileiros dentro da cidade
(44,3%), seguido pelo carro (23,8%), moto (12,6%), a p (12,3%) e, por ltimo,
bicicleta (7,0%).
De acordo com a Constituio Federal de 1998 [51], compete aos
Municpios organizar e prestar, diretamente ou sob regime de concesso ou
permisso, o servio de transporte pblico coletivo. A Lei Federal 12.581 de 2 de
janeiro de 2012 [52], institui as diretrizes da poltica nacional de mobilidade
urbana e define, no seu art. 4o, a mobilidade urbana como condio em que se
realizam os deslocamentos de pessoas e cargas no espao urbano. Esse mesmo
artigo define transporte pblico coletivo como servio pblico de transporte de
passageiros acessvel a toda a populao mediante pagamento individualizado,
com itinerrios e preos fixados pelo poder pblico.
O Municpio deve prover condies de locomoo de maneira que seus
habitantes possam exercer seu direito de ir e vir livremente, de forma rpida e
eficiente. Para tanto, deve ser ofertada infraestrutura e demais elementos para essa
movimentao, com transporte pblico virio, ferrovirio e fluvial com uma
sistemtica inteligente. Adicionalmente, o transporte individual por meio de
automveis ou veculos movidos trao humana tambm devem ser facilitados
pelas autoridades urbanas neste permetro.
Para a obteno de um servio de qualidade fundamental a conciliao de
interesses de trs grupos com preocupaes distintas quanto ao desempenho de
um sistema de transporte pblico, sendo eles:
24
Usurios: utilizam o servio pblico para suprir suas necessidades de

deslocamento e no tem maiores preocupaes com a operao dos servios.
Na tomada de deciso quanto ao uso do transporte pblico, levam em
considerao a regularidade, tempo de deslocamento, conforto, custos, entre
outros atributos.
Operadores: encarregados de administrar, operar (financiamento, aquisio,

manuteno, renovao da frota, etc.) e comercializar o transporte coletivo,
sob a forma de prestao de um servio pblico. Suas preocupaes esto
relacionadas com as variveis que influenciam os custos e receitas na oferta do
servio.
Poder pblico: responsvel legal pelo transporte pblico; deve regulamentar,

planejar, programar e fiscalizar a execuo dos servios, interagindo nos
conflitos de interesse existentes entre usurios e operadores, atravs de
legislao especfica. Fica, tambm, a cargo do Poder Pblico defender os
interesses de um quarto grupo, a comunidade em geral, cujo interesse
indireto, provocado pelas externalidades do sistema de transporte publico
(rudo excessivo, poluio ambiental, conflitos com o uso do solo, etc.).
Um cenrio ideal, com a integrao de transporte coletivo e transporte
individual em harmonia com a cidade, sem atrasos e completamente acessvel

para toda a populao o sonho de muitos dos cidados que chegam a passar 3
horas por dia, ou mais, fazendo o trajeto casa-trabalho-casa. Algumas cidades do
mundo, que ainda esto longe deste cenrio utpico, j passaram por mudanas
radicais e se aproximam de alguns objetivos, que representam uma grande
melhora na qualidade de vida de seus moradores. Tais metamorfoses, que se do
de mdio a longo prazo, podem um dia trazer uma efetiva melhoria no dia a dia
das pessoas.
Em particular, no Brasil, a pesquisa Mobilidade Urbana e Cidadania da
Diretoria de Anlise de Polticas Pblicas [53] da Fundao Getlio Vargas
(FGV), realizada nas regies metropolitanas de So Paulo, Rio de Janeiro,
Braslia, Belo Horizonte, Recife e Porto Alegre, entre 25 de maro e 07 de abril de
2014, apontou que mais 70% dos usurios do transporte pblico esto
insatisfeitos com o servio. Assim como, para 65% dos entrevistados o
transporte pblico no melhorou nos ltimos anos e, ainda, para 60% dos
entrevistados, no existe crena que vai melhorar nos prximos.
25
O Municpio do Rio de Janeiro, conforme dados de abril de 2015 [54], tem a
participao dominante do modal nibus Municipal no transporte pblico
coletivo, sem alteraes previstas em curto prazo, conforme detalhado na Figura
3.
Figura 3 Evoluo dos Principais Modais do Transporte Coletivo

Diante do exposto, buscar formas de melhorar a experincia do usurio de
transporte pblico, em especial, de nibus Municipal, possivelmente represente
uma melhoraria na qualidade de vida da populao.
2.2
nibus Municipal do Rio de Janeiro
As estatsticas da Fetranspor (Federao das Empresas de Transportes de
Passageiros do Estado do Rio de Janeiro) [55], referentes ao ano de 2015 e ao
municpio do Rio de Janeiro, indicam nmeros expressivos deste servio:
705 linhas de nibus em operao na poca;
9.008 nibus em operando na poca;
19.075.362 viagens realizadas;
1.085.326.478 passageiros;
723.478.360 quilmetros percorridos;
43 empresas com 39.596 empregados;
26
4,38 anos de idade mdia da frota;
1,5 ndice de passageiros por quilmetro; e
6.694 km de mdia mensal percorrida por nibus.
Observe que segundo o nmero acima temos o equivalente a 47,05% da
populao carioca - que na ordem de 6.320.446 [56] - utilizando este servio
diariamente. Portanto, melhorar este servio ou pelo menos a experincia de uso
do mesmo representa influenciar de forma positiva e significativa a qualidade de
vida do morador do Municpio do Rio de Janeiro.
Este modal, nibus Municipal de transporte pblico coletivo no
Municpio do Rio de Janeiro operado por um consrcio de empresas, que se
divide em quatro reas, conforme representado na Figura 4.
Figura 4 Diviso Territorial do RJ pelos Consrcios de nibus
2.3
Lei de Acesso Informao
Acesso s informaes sob a guarda de rgos e entidades pblicas direito
fundamental do cidado e dever do Estado, conforme previsto pela Constituio
brasileira e regulamentado pela Lei Federal 12.527, sancionada em 18 de
novembro de 2011 pela Presidenta da Repblica.
Esse direito fundamental aparece expresso no artigo 5 da Constituio:
todos so iguais perante a lei, sem distino de qualquer natureza, garantindose aos brasileiros e aos estrangeiros residentes no Pas a inviolabilidade do
direito vida, liberdade, igualdade, segurana e propriedade. No inciso
XXXIII deste artigo, determina-se que todos tm direito a receber dos rgos
pblicos informaes de seu interesse particular, ou de interesse coletivo ou
27
geral, que sero prestadas no prazo da lei, sob pena de responsabilidade,
ressalvadas aquelas cujo sigilo seja imprescindvel segurana da sociedade e
do Estado.
No artigo 37 da Constituio Federal fica explcito que a administrao
pblica direta e indireta de qualquer dos Poderes da Unio, dos estados, do
distrito federal e dos municpios obedecer aos princpios de legalidade,
impessoalidade, moralidade, publicidade e eficincia.
Em funo dos avanos tecnolgicos, novas questes passam a se relacionar
com esses princpios: Como garantir o direito de receber informaes pblicas
quando a relao entre governo e cidados intermediada pelas mquinas? O que
significa ser pblico e eficiente em tempos de Internet acessvel a todos?
Nesse contexto, a Lei 12.527 de 18 de novembro de 2011, Lei de Acesso
Informao, representa uma mudana de paradigma em matria de transparncia
pblica, pois estabelece que o acesso a regra e o sigilo a exceo. Qualquer
cidado poder solicitar acesso s informaes pblicas, ou seja, aquelas no
classificadas como sigilosas, conforme procedimento que dever observar as
regras, prazos, instrumentos de controle e recursos previstos.
O desafio, agora, assegurar a implementao desta Lei, que apresenta
diversos desafios de natureza tcnica e tecnolgica e, tambm, de carter
administrativo, que incluem a necessidade de recursos financeiros e humanos estes, devidamente capacitados - para garantir a observncia do que dispe a Lei.
Alm disso, no menos importante, transpor a cultura do sigilo que, de forma
silenciosa e invisvel,
ainda se constitui um dos grandes obstculos para a
abertura dos governos.

A Controladoria-Geral da Unio disponibilizou uma cartilha onde maiores
informaes podem ser obtidas sobre a lei, os aspectos e vantagens de uma cultura
administrativa pr-acesso informao.
2.4
Dados Abertos
Dado aberto um dado que pode ser livremente utilizado, reutilizado e
redistribudo por qualquer um (Site Dados Abertos).
A definio completa
fornece detalhes especficos do significado do termo, abaixo sumarizados.
28
Disponibilidade e acesso: o dado precisa estar disponvel por inteiro e

por um custo razovel de reproduo, preferencialmente, por meio de
download na Internet; tambm deve estar em um formato conveniente e
modificvel.
Reuso e redistribuio: o dado precisa ser fornecido em condies que

permitam reutilizao e redistribuio, incluindo o cruzamento com
outros conjuntos de dados.
Participao universal: todos podem usar, reutilizar e redistribuir, no

havendo discriminao contra reas de atuao, pessoas ou grupos, por
exemplo, no so permitidas restries como no comercial, que
impedem o uso comercial e restries de uso para determinados fins,
como somente educacional.
Corroborando com esta definio enriquecedor elencar os princpios

pregados pelos ativistas de dados abertos, a saber.
Acessveis: so disponibilizados para a maior quantidade possvel de

pessoas, atendendo, assim, aos mais diferentes propsitos.
Completos: todos os dados pblicos devem ser disponibilizados. Dado

pblico aquele que no est sujeito restries de privacidade,
segurana ou outros privilgios.
Primrios: so apresentados tal como colhidos da fonte, com o maior

nvel possvel de granularidade, sem agregao ou modificao. Por
exemplo, um grfico no fornecido aberto mas, sim, os dados
utilizados para construir a planilha que deu origem a ele podem ser
abertos.
Atuais: devem ser publicados o mais rpido possvel para preservar seu
valor. Em geral tm periodicidade, quanto mais recentes e atuais, mais
teis para seus usurios.
Compreensveis por mquina: devem estar estruturados de modo

razovel, possibilitando que sejam processados automaticamente, por
exemplo, uma tabela em PDF muito bem compreendida por pessoas,
mas para um computador apenas uma imagem; uma tabela em
formato estruturado, como CSV ou XML, processada mais facilmente
por softwares.
29
No discriminatrios: Devem estar disponveis para qualquer pessoa,

sem necessidade de cadastro ou qualquer outro procedimento que
impea o acesso.
No proprietrios: Nenhuma entidade ou organizao deve ter

controle exclusivo sobre os dados disponibilizados.
Livres de licenas: No devem estar submetidos a copyrights, patentes,

marcas registradas ou regulaes de segredo industrial. Restries
razoveis quanto a privacidade, segurana e outros privilgios so
aceitas, desde que transparentes e bem justificadas.
Dados abertos governamentais so dados produzidos pelo governo e

colocados disposio das pessoas de forma a tornar possvel no apenas sua
leitura e acompanhamento, mas tambm sua reutilizao em novos projetos, sites
e aplicativos; seu cruzamento com outros dados de diferentes fontes; e sua
disposio em visualizaes interessantes e esclarecedoras. No processo de
abertura de dados, o foco no est nos dados pessoais, mas naqueles que no
contm informao sobre indivduos especficos.
A interoperabilidade i.e. a capacidade de diversos sistemas e organizaes
trabalharem juntos, sendo esta a ideia central desta proposta.
Dados abertos, especialmente os governamentais, so um timo recurso
ainda muito pouco explorado, considerando que muitos indivduos e organizaes
coletam uma gama de diferentes tipos de dados para executar suas tarefas. O
governo especialmente importante nesse contexto, tanto pela quantidade e
centralidade dos dados que possui, quanto pelo fato de que tais dados serem
essencialmente pblicos, sendo esta, repise-se, uma das garantias fundamentais
prevista pela Constituio Federal.
O debate sobre dados governamentais abertos ganhou a mdia em 2009. Em
governos de vrios pases, tais como Estados Unidos, Reino Unido, Canad e
Nova Zelndia. Foram anunciandas iniciativas voltadas abertura de dados
pblicos, e desde ento, a informao aberta se propaga no mundo e sua utilizao
em prol da sociedade avana exponencialmente.
O Laboratrio Brasileiro de Cultura Digital e o Ncleo de Informao e
Coordenao do Ponto BR (NIC.br) publicaram um manual para governos que
querem abrir dados, podendo ser usado por qualquer pessoa que queira saber mais
sobre os aspectos tcnicos, sociais e polticos dos referidos dados.
30
2.5
Dados Abertos no Municpio do Rio de Janeiro
O Portal de Dados Abertos da Prefeitura do Rio de Janeiro [6] a
ferramenta disponibilizada pelo Municpio para que a sociedade possa encontrar e
utilizar os dados abertos governamentais da cidade do Rio de Janeiro, o que
proporciona ao cidado um melhor entendimento da Administrao Pblica, no
que se refere ao acesso aos servios pblicos, controle das contas pblicas e
participao no planejamento, bem como melhor conhecimento da cidade. O
Portal tambm tem o objetivo de promover a interlocuo entre atores da
sociedade e o governo para pensar a melhor utilizao dos dados em benefcio da
sociedade.
Este canal funcionar como um grande catlogo que facilitar a busca, uso e
reuso de dados publicados pela Prefeitura do Rio de Janeiro e disponibiliza o
acesso s informaes, entre outras, do modal rodovirio municipal fornecido
pelos GPS instalados nos nibus que circulam na cidade do Rio de Janeiro, sade,
educao e Disque-Rio (1746).
Em especial, quando falamos de Transporte e Mobilidade, as informaes
disponveis no Portal so complementadas pelo site Transparncia da Mobilidade,
da Secretaria Municipal de Transportes (SMTP), onde esto disponibilizados
todos os dados relativos s operaes do servio de nibus como custos, receitas e
indicadores de qualidade do servio. Neste site esto os dados relativos operao
do Sistema de Transporte Pblico por nibus licitado.
2.6
Dados Abertos sobre os nibus do Municpio do Rio de Janeiro
Esto disponveis as informaes a seguir sobre os nibus Municipais do
Rio de Janeiro no Portal anteriormente apresentado. A especificao de cada linha
destes conjuntos de dados tambm apresentada a seguir.
Posio dos nibus: Conjunto de dados com a posio - coordenadas

geogrficas de latitude e longitude do sistema global de posicionamento
(GPS) - instantnea de cada veculo. As coletas, a priori, tem intervalo
de 1 minuto entre elas e os dados no so armazenados para consulta ao
histrico. Alm disso, os dados so disponibilizados em dois arquivos
31
no formato JSON, um para linhas convencionais e outro para linhas do
sistema BRT, incluindo, neste segundo, as linhas alimentadores do
sistema. O primeiro passou a ser disponibilizado em Maro de 2014 e o
segundo em Julho de 2015. Posteriormente, uma verso mais abrangente
do primeiro foi tambm disponibilizada. A Tabela 1 lista a descrio dos
campos disponibilizados.
Campo
Descrio
DataHora
Data e hora da coleta do dado
Ordem
Identificao alfanumrica encontrada na lateral dos nibus
Linha
Linha do nibus
Latitude
Latitude do nibus na coleta (GPS, WGS84)
Longitude
Longitude do nibus na coleta (GPS, WGS84)
Velocidade
Velocidade do nibus na hora da coleta do dado
Tabela 1 Posio dos nibus
Pontos de parada das linhas do nibus: Conjunto de dados com a

posio conhecida de todos os pontos de parada das linhas de nibus. O
ponto de nibus ou ponto de parada so locais designados para um
nibus parar temporariamente para os passageiros embarcarem ou
desembarcarem. Este dado, disponibilizado em formato CSV, sendo um
arquivo por linha, a priori, atualizado quando ocorrem mudanas nas
linhas de nibus.
A Tabela 2 lista a descrio dos campos
disponibilizados.
Campo
Descrio
Linha
Identificador da Linha de nibus
Descrio
Descrio da Linha de nibus
Sequncia
Posio da Parada de nibus iniciando em zero
Latitude
Latitude da Parada de nibus (GPS, WGS84)
Longitude
Longitude do Parada de nibus (GPS, WGS84)
Tabela 2 Pontos de parada das linhas do nibus
Coordenadas dos trajetos das linhas de nibus: Conjunto de dados

que discretiza os trajetos das linhas de nibus, onde cada descrio
representa uma posio. Uma linha de nibus pode ser entendida como
um servio de transporte pblico regular que percorre determinado
itinerrio. Por sua vez, o itinerrio a definio dos trajetos a serem
32
percorridos pelos nibus desta linha. Este dado, disponibilizado em
formato CSV, sendo um arquivo por linha, a priori, atualizado quando
ocorrem mudanas nas linhas de nibus. A Tabela 3 lista a descrio dos
campos disponibilizados.
Campo
Descrio
Linha
Identificador da Linha de nibus
Descrio
Descrio da Linha de nibus
Sequncia
Posio do Ponto iniciando em zero (referente ao shape)
Shape_id
Identificador de uma Trajetria realizada pela Linha (shape)
Latitude
Latitude do Ponto (GPS, WGS84)
Longitude
Longitude do Ponto (GPS, WGS84)
Tabela 3 Coordenadas dos trajetos das linhas de nibus
General Transit Feed Specification (GTFS) [57]:

Formato comum para horrios de transportes pblicos e de informao
geogrfica associada, proposto pelo Google, para agncias e
desenvolvedores
interoperarem.
Teoricamente
atualizado
quando
ocorrem mudanas nas linhas de nibus, pontos de parada e outras

caractersticas do servio e contm vrios arquivos em formato texto,
conforme listado abaixo.
Arquivo
Definio
agency.txt*
Agncia de transporte que provm estas informaes.
stops.txt*
Locais onde os veculos embarcam e desembarcam passageiros.
routes.txt*
Agrupamento de viagens em rotas.
trips.txt*
Viagens de cada rota (sequencia de pontos no tempo).
stop_times.txt*
Horrio de chegada e partida de um veculo em determinado ponto

para uma viagem.
calendar.txt*
Especifica quando um servio inicia e quando termina.
calendar_dates.txt
Datas de exceo em relao ao calendrio.
fare_attributes.txt
Tarifas.
fare_rules.txt
Regras para aplicao de tarifas por rota.
shapes.txt
Pontos do trajeto de uma rota.
frequencies.txt
Frequncia entre rotas.
transfers.txt
Regras para conexo entre pontos de transferncia das rotas.
feed_info.txt
Informao adicional sobre esse conjunto de dados.
Tabela 4 Arquivos do GTFS
33
Em especial, no tocante aos dados do Rio de Janeiro, apenas os arquivos
routes.txt, shapes.txt, trips.txt, fare_attributs.txt e fare_rules.txt so
efetivamente relevantes. Os demais possuem informaes depreciadas. Os
dados contidos em cada arquivo e o relacionamento entre os mesmos
ilustrado no diagrama apresentado a seguir. Maiores detalhes podem ser
obtidos em Google Transit APIs. A Tabela 4 lista a definio dos arquivos.
Figura 5 Diagrama do GTFS

Esses conjuntos de dados so gerados pela Federao das Empresas de
Transportes de Passageiros do Estado do Rio de Janeiro (Fetranspor) e mantidos
pelo IPLAM (Empresa Municipal de Informtica da Cidade do Rio de Janeiro).
Os conjuntos de dados Pontos de parada das linhas do nibus,
Coordenadas dos trajetos das linhas de nibus e GTFS (veja a Figura 5)
inicialmente eram coletados e utilizados apenas em sua verso atual, sem
preocupao com a manuteno do histrico de atualizaes. A partir de julho de
2016 iniciou-se o armazenamento dirio de uma verso destes conjuntos de dados.
Por outro lado, a partir de 12/06/2014 a Posio dos nibus passou a ser
capturada e armazenada, formando assim um histrico de posies destes nibus,
sendo acumulados mais de 3 bilhes registros. Uma viso geral do histrico
acumulado at 31/08/2016 apresentada na prxima pgina.
34
Ms
Tamanho
Registros
Sem Linha
Junho de 2014
1,01 GB
73.145.211
22,26%
Julho de 2014
1,49 GB
111.365.317
21,64%
Agosto de 2014
0,52 GB
38.491.314
20,80%
Setembro de 2014
2,00 GB
150.661.127
20,01%
Outubro de 2014
1,58 GB
120.618.942
19,82%
Novembro de 2014
1,12 GB
84.918.283
22,79%
Dezembro de 2014
1,40 GB
106.430.699
19,38%
2014
9,12 GB
685.630.893
20,77%
Janeiro de 2015
1,86 GB
143.626.826
24,74%
Fevereiro de 2015
1,79 GB
137.925.035
26,51%
Maro de 2015
2,10 GB
161.585.524
23,26%
Abril de 2015
1,94 GB
149.803.857
23,19%
Maio de 2015
2,04 GB
156.447.803
20,15%
Junho de 2015
1,83 GB
140.238.082
20,97%
Julho de 2015
1,84 GB
140.770.355
20,94%
Agosto de 2015
1,45 GB
112.364.124
24,06%
Setembro de 2015
1,75 GB
133.602.361
24,82%
Outubro de 2015
2,16 GB
163.624.729
28,79%
Novembro de 2015
0,45 GB
33.764.704
26,41%
Dezembro de 2015
2,06 GB
155.356.670
25,59%
2015
21,27 GB
1.629.110.070
24,12%
Janeiro de 2016
2,21 GB
164.474.333
24,46%
Fevereiro de 2016
1,93 GB
142.424.654
21,65%
Maro de 2016
2,00 GB
146.799.798
21,12%
Abril de 2016
1,75 GB
128.724.763
20,98%
Maio de 2016
1,58 GB
116.684.681
19,25%
Junho de 2016
1,89 GB
139.461.416
20,00%
Julho de 2016
1,87 GB
139.786.136
20,62%
Agosto de 2016
2,29 GB
174.424.424
23,83%
2016
15,52 GB
1.152.780.205
21,49%
Total
45,91
3.467.521.168
22,19%
Tabela 5 Viso geral do histrico da posio dos nibus
35
O conjunto de dados do perodo de 12/06/2014 at 12/06/2015 foi
gentilmente cedido por Bruno Amaral, que defendeu Dissertao de Mestrado na
PUC-Rio nesta data [13]. Estes foram uniformizados para que no apresentem
qualquer diferena estrutural em relao aos posteriormente coletados.
A Tabela 5 apresentou os dados capturados e armazenados a cada Ms, com
a respectiva totalizao e subtotais por ano, sendo a temporalidade apresentada na
sua primeira coluna. O campo Tamanho em Gygabites (GB) corresponde ao
espao em disco necessrio para armazenar de forma compactada esse conjunto de
dados, enquanto o campo Registros apresenta o total de registros acumulado em
cada perodo, onde cada registro corresponde a especificao apresentada na
Tabela 1. Por ltimo, destacado no campo Sem Linha o percentual de
registros que se encontram com a informao da linha do nibus em branco, ou
seja, que no possui a informao de qual linha pertence o nibus cuja posio foi
disponibilizada. Vale ressaltar que quase 22% dos dados do histrico no
continham a relao entre nibus e linha de nibus, o que pode ocorrer pelo fato
de o nibus estar fora de servio ou por inadimplemento da operadora da linha.
nibus em circulao nestas datas
8.133
Linhas em circulao nestas datas
467
Linhas com paradas disponibilizadas
146 (31,26%)
Linhas sem paradas disponibilizadas
321 (68,74%)
Pontos de paradas disponibilizados
22.246
Mdia de pontos de paradas por linha
152,37
Linhas com trajetos disponibilizados
358 (76,66%)
Linhas sem trajetos disponibilizados
109 (23,34%)
Quantidade de trajetos disponibilizados
850
Mdia de trajetos por linha
2,3743
Pontos discretizando os trajetos disponibilizados
620.889
Mdia de pontos discretizados por trajeto
730,45
Tabela 6 Viso geral dos Pontos de Parada e Trajetos dos nibus

Buscando ainda o entendimento desses conjuntos de dados, nos 15, 16 e
17/07/2015, foram obtidos os dados dos Pontos de parada das linhas do nibus
e dos Pontos dos trajetos das linhas de nibus disponibilizados no Portal. Essas
informaes foram confrontadas com a Posio dos nibus obtidas em
36
18/07/2015 tambm no Portal. As principais caractersticas identificadas so
apontadas na Tabela 6.
O nmero de linhas cujos pontos de parada so desconhecidos expressivo,
sendo superior a 68%. Da mesma forma, o nmero de linhas cujos trajetos so
desconhecidos, superior a 23%, considervel. Por outro lado, o nmero de
pontos de parada por linha se mostra exacerbado. Esses nmeros indicam que os
operadores do Servio Pblico de Passageiros por nibus do Municpio do Rio de
Janeiro (SPPO-RJ) no esto disponibilizando informaes atualizadas e
consistentes em relao a suas linhas de nibus.
Por outro lado, o nmero mdio de trajetos por linha consistente com a
ideia de um trajeto de ida e outro de volta, com baixssimas variaes divulgadas.
No entanto, a maioria das linhas no sofreu atualizao h algum tempo, o que
gera a desconfiana de que muitas estejam desatualizadas, em especial, as que
sabidamente passam em reas que sofreram intervenes recentes, como, por
exemplo, o Centro da Cidade.
Cabe registrar que no site Transparncia da Mobilidade possvel encontrar
outras informaes sobre o SPPO-RJ, a saber:
Edital de licitao do sistema de nibus e contratos de concesso dos

nibus com a Transcarioca, Santa Cruz, Internorte e Intersul;
Decreto N 38.279 de 29 de janeiro de 2014, que estabelece medidas

para o aperfeioamento da prestao deste servio;
Gratuidade no transporte pblico para estudantes das redes pblicas;
Histrico do servio e dos reajuste;
Relatrio de operaes por linha;
Indicadores de demanda, participao dos consrcios e de mercado;
Ranking negativo (fiscalizao direcionada sobre linhas de nibus);
Relatrio dirio de operaes do BRT Transcarioca e BRT Transoeste;
Relao dos postos de venda do bilhete nico carioca.
37
3
Coleta, Armazenamento e Visualizao Bsica dos Dados
3.1
Dados Armazenados
O procedimento de coleta, que ser detalhado na seo 3.2, armazena os
arquivos abaixo.
ltimas 5 posies conhecidas de cada nibus (now.txt): Arquivo

em formato texto que contm em cada linha a informao das ltimas
cinco posies conhecidas de um nibus em particular, conforme dados
especificado na Tabela 7.
Campo
Descrio
DataHora
Data e hora da ltima coleta de dados do GPS do nibus
Ordem
Linha
Identificador da linha do nibus
Latitude
ltima latitude conhecida do nibus (GPS, WGS84)
Longitude
ltima longitude conhecida do nibus (GPS, WGS84)
Velocidade
ltima velocidade conhecida do nibus na hora da coleta
DataHora1
Data e hora da penltima coleta de dados do GPS do nibus
Latitude1
Penltima latitude conhecida do nibus (GPS, WGS84)
Longitude1
Penltima longitude conhecida do nibus (GPS, WGS84)
DataHora2
Data e hora da antepenltima coleta de dados do GPS do nibus
Latitude2
Antepenltima latitude conhecida do nibus (GPS, WGS84)
Longitude2
Antepenltima longitude conhecida do nibus (GPS, WGS84)
DataHora3
Data e hora da coleta de dados do GPS do nibus anterior a 2
Latitude3
Latitude conhecida do nibus da coleta anterior a 2
Longitude3
Longitude conhecida do nibus da coleta anterior a 2
DataHora4
Data e hora da coleta de dados do GPS do nibus anterior a 3
Latitude4
Latitude conhecida do nibus da coleta anterior a 3
Longitude4
Longitude conhecida do nibus da coleta anterior a 3
Tabela 7 Arquivo ltimas 5 posies conhecidas de cada nibus

Este arquivo separado por tabulao (caractere \t), ordenado pelo
identificador alfanumrico dos nibus (campo denominado Ordem) e
no possui cabealho. A medida que uma nova posio recebida, ou
seja, uma latitude, longitude, data e hora distintas da ltima posio
38
conhecida, essa armazenada como a ltima conhecida e a que
anteriormente era a ltima passa a ser a penltima, a penltima passa a
ser a antepenltima e assim sucessivamente. So armazenadas sempre as
ltimas cinco posies distintas conhecidas de cada nibus neste
arquivo. O tamanho deste arquivo tende a evoluir lentamente ao longo
do tempo, em funo da entrada de novos nibus em circulao. nibus
que so tirados de circulao permanecem no arquivo com suas ltimas
posies conhecidas.
Histrico de posies dos nibus ({aaammdd}.zip): Arquivo em

formato texto que salva cada nova posio conhecida em sua ltima
linha. Sabe-se que uma posio nova ou no a partir do arquivo
anteriormente apresentado. Ao final de cada dia o arquivo compactado
e nomeado com a respectiva data e um novo arquivo em branco criado.
Campo
Descrio
DataHora
Data e hora da coleta de dados do GPS do nibus
Ordem
Linha
Latitude
Latitude do nibus (GPS, WGS84)
Longitude
Longitude do nibus (GPS, WGS84)
Velocidade
Velocidade do nibus na hora da coleta
Tabela 8 Arquivo histrico de posies dos nibus

Este arquivo tambm separado por tabulao (caractere \t) e a
ordenao cronolgica em funo do recebimento dos dados. O
mesmo no possui linha de cabealho, mas para cada novo conjunto de
posies, ou seja, que so frutos de uma mesma leitura do conjunto de
dados Posio dos nibus, acrescenta uma linha de separao com o
formato # x dado(s) novo(s) inserido(s) em dd-MM-yyyy HH:mm:ss ,
onde o x substitudo pelo total de linhas inseridas com novas
posies e dd-MM-yyyy HH:mm:ss pelo momento em que ocorreu a
leitura do conjunto de dados, sendo esse com preciso de segundos. Em
funo do volume de nibus em circulao e da atualizao de sua
posio, ao longo do dia, a cada 1 minuto, esse arquivo cresce. A Tabela
8 descreve resumidamente as informaes armazenadas nesse arquivo.
39
Linhas de nibus (lines.txt): Arquivo em formato texto que contm

em cada linha informaes sobre cada linha de nibus, conforme dados
especificado na Tabela 9.
Campo
Descrio
Linha
Descrio
Texto apresentado no letreiro dos nibus desta linha
ShapesId
Identificador dos trajetos da linha separado por ponto e vrgula
TemShape
True se possui trajeto conhecido e False caso contrrio
TemParadas
True se possui paradas conhecidas e False caso contrrio
Tabela 9 Arquivo linhas de nibus

Este arquivo tambm separado por tabulao (caractere \t) e
ordenado pelo identificador da linha de nibus (campo denominado
Linha). O mesmo no possui linha de cabealho. A cada novo
recebimento de informaes sobre as linhas, as informaes
armazenadas so apagadas e as novas informaes recebidas so
armazenadas. O tamanho deste arquivo evolui de forma proporcional
quantidade de linhas de nibus em operao, sendo as diferentes linhas
de nibus em operao identificada a partir do campo Linha do conjunto
de dados Posio dos nibus.
Pontos
de
parada
das
linhas
de
nibus
(stops.txt
stop_{linha}.txt): Arquivo em formato texto que contm em cada

linha informaes sobre uma parada de nibus, conforme dados
especificados na Tabela 10.
Campo
Descrio
Linha
Sequncia
Nmero da parada que um sequencial para cada linha
Latitude
Latitude do ponto de parada de nibus (GPS, WGS84)
Longitude
Longitude do ponto de parada de de nibus (GPS, WGS84)

ordenado pelo identificador da linha de nibus (campo denominado
Linha). Alm disso, o mesmo no possui linha de cabealho. A cada
novo recebimento de informaes sobre as paradas, estas so
40
armazenadas e apagadas para o armazenamento de novas informaes
recebidas.
Trajetos da linha de nibus (shape_{linha}.txt): Arquivo em

formato texto que contm em cada linha posies geogrficas referentes
a um trajeto da linha de nibus, conforme dados especificado na Tabela
11.
Campo
Descrio
Sequncia
Nmero da coordenada em relao ao trajeto ao qual pertence
ShapeId
Identificador do trajeto ao qual essa coordenada pertence
Latitude
Latitude da coordenada (GPS, WGS84)
Longitude
Longitude da coordenada (GPS, WGS84)

ordenado pelo identificador do trajeto (campo denominado ShapeId).
Alm disso, o mesmo no possui linha de cabealho. A cada novo
recebimento de informaes sobre os trajetos, as informaes
armazenadas so apagadas e as novas informaes recebidas so
armazenadas.
Todos esses arquivos so armazenados como Blobs, com o grau de
redundncia desejado. Os arquivos shape_{linha}.txt, stops.txt, stop_{linha}.txt
e lines.txt ficam na pasta csv e os trs primeiros so zipados diariamente para
armazenamento do histrico de evoluo das linhas no formato aaaammdd.zip
dentro desta pasta. Os arquivos {aaammdd}.zip e now.txt ficam na pasta gps.
O arquivo gtfs.zip fica na pasta gtfs, sendo armazenado uma cpia diria com a
data do dia no formato aaammdd.zip dentro desta pasta.
Possivelmente, para testes do processo de coleta, o acesso a estes arquivos
pode ser realizado pela Internet, bastando a configurao da pasta como pblica e
o uso do endereo:
http://{domnio}.blob.core.windows.net/{pasta}/{arquivo}
O procedimento de coleta, possivelmente, pode gerar dados de log, gravados
em banco de dados, conforme a especificao descrita na Tabela 12.
41
Campo
Descrio
DataHora
Timestamp da gravao do registro com preciso de milissegundo
Tipo
Tipo do registro (W Alerta; I Informao; E Erro)
Mensagem
Mensagem com at 250 caracteres
Instncia
Identificador da instncia e da verso do servio
Tabela 12 Campos da tabela de log

3.2
Coleta dos Dados
Com objetivo de coletar os conjuntos de dados disponveis no Portal (vide
Captulo 3) foi desenvolvido um servio que executa de forma cclica o
procedimento abaixo detalhado.
1. Recupera da instncia onde o servio est sendo executado ou, se
necessrio, do armazenamento compartilhado, as ltimas cinco posies
conhecidas de cada nibus, ou seja, o arquivo now.txt apresentado na
seo 3.1. Aloca em memria os dados deste arquivo utilizando uma
lista.
2. Obtm o conjunto de dados com a Posio dos nibus pela Internet em
suas 3 (trs) verses.
3. Para cada linha do conjunto de dados verifica se a posio, data e hora
so diferentes da ltima posio conhecida, que se encontra na lista em
memria. Caso seja diferente, atualiza essa nova posio, descartando a
posio mais antiga dentre as cinco anteriormente conhecidas para este
nibus. Caso o nibus no esteja na lista, insere com a posio recebida.
Alm disso, para toda nova posio, armazena a mesma em um vetor.
4. Ao final da leitura de todas as posies recebidas, utilizando a lista,
salva o novo arquivo now.txt localmente e no armazenamento
compartilhado
e,
utilizando
vetor,
apensa
no
arquivo
{aaaammdd}.txt referente ao dia os dados obtidos, diretamente no

armazenamento compartilhado, incluindo um separador referente
leitura em questo, conforme especificado na seo 3.1.
5. Caso
exista
no
armazenamento
compartilhado
um
arquivo
{aaaammdd}.txt do dia anterior ao atual e nenhum procedimento

dirio em execuo, abre uma nova thread que:
42
a. Compacta o arquivo {aaaammdd}.txt do dia anterior gerando,
assim,
arquivo
{aaaammdd}.zip
no
armazenamento
compartilhado.
b. Apaga o arquivo do dia anterior, que no estava compactado, do
armazenamento compartilhado.
6. Caso faa mais de uma hora que foram obtidos os conjuntos de dados de
trajetos e paradas, abre uma nova thread que:
a. Obtm os dados de linhas a partir do arquivo lines.txt do
armazenamento compartilhado e carrega numa lista em memria.
b. Obtm todas as linhas diferentes em operao a partir do arquivo
now.txt do armazenamento compartilhado e adiciona as linhas
que no existiam na lista anteriormente obtida.
c. Cria um novo arquivo stops.txt localmente.
d. Para cada linha de nibus da lista, obtm o conjunto de dados
Pontos de parada das linhas do nibus da Internet e insere os
pontos de parada, um a um, no final do arquivo local stops.txt.
Cria subconjuntos stops_{linha}.txt. Envia estes arquivos para
o armazenamento compartilhado, subscrevendo o anterior.
e. Para cada linha de nibus da lista, obtm o conjunto de dados
Coordenadas dos trajetos das linhas de nibus da Internet e
deleta o arquivo local shape_{linha}.txt referente a linha e cria
um novo, inserindo as coordenadas de todos os trajetos desta
linha. Envia este arquivo para o armazenamento compartilhado
subscrevendo o anterior.
f. Se ainda no salvou uma verso das linhas e dos paradas para o
dia, salva em shapes.zip e stops.zip, contendo os respectivos
arquivos. Tambm obtm e salva a verso do GTFS para o dia,
assim como estes arquivos de forma compactada referente ao
dia. Envia os arquivos para o armazenamento compartilhado.
7. O procedimento aguarda at completar 40 segundos de execuo, caso
ele no tenha levado este tempo para executar. Lembrando que a
execuo das threads abertas (item 5 e 7) ocorrer em paralelo ao
restante do procedimento. Retorna ao passo 1.
43
Cabe observar que o procedimento implementa um controle de threads
baseado na sinalizao do momento de incio da execuo, que desmarcada aps
seu trmino. Alm disso, o tempo mximo de execuo de cada thread
controlado, permitindo assim, que ela seja reiniciada se no finalizada no tempo
esperado, o que funciona como um sistema de tolerncia a falha.
3.3
Visualizao Bsica dos Dados
Visando compreender um pouco melhor os dados disponveis e validar a
coleta destes, foram desenvolvidas algumas visualizaes bsicas, utilizando a
API (Application Programming Interface) do Google Maps [81] para sobrepor
estes dados em um mapa personalizado disponibilizado pelo Google. Alm disso,
foram desenvolvidos alguns filtros bsicos para que diferentes combinaes
destes dados pudessem ser visualizadas. Para tanto, foram utilizadas as linguagens
PHP5, HTML e Java Script, sendo essa uma pgina Web, que consume a citada
API.
A imagem a seguir apresenta a tela de filtros desenvolvida que alm de
escolher os critrios da visualizao, concentra os principais links para os
arquivos brutos armazenados. Na sequencia so tambm apresentadas
visualizaes obtidas a partir desta ferramenta, com diferentes critrios de filtro
(Veja Figura 6).
Figura 6 Tela de Filtros Desenvolvida para Visualizao Bsica
44
A Figura 7 ilustra a visualizao da ltima posio conhecida de todos os
nibus. Ao clicar em um nibus so apresentados os dados coletados. Em verde
esto os nibus convencionais e em azul os do sistema BRT. Os em vermelho no
possuem linha informada.
Figura 7 Visualizao da ltima posio conhecida

A Figura 8 ilustra a visualizao da ltima posio conhecida de todos os
nibus com at 10 minutos de atraso em relao ao momento de gerao da
visualizao. possvel observar que no momento em que a imagem foi gravada
o sistema BRT estava fora do ar, pois nenhum nibus foi apresentado.
Figura 8 Visualizao da posio com at 10 minutos de atraso
45
A Figura 9 ilustra a visualizao da ltima posio conhecida dos nibus da
linha 125 com at 10 minutos de atraso. Tambm apresenta os trajetos desta linha,
que como fcil perceber, so dois, um em vermelho e outro em azul,
provavelmente representando o trajeto de ida e volta da linha.

As figuras que se seguem variam apenas o nmero da linha em relao a
anterior, sendo agora de interesse a linha 415 (veja Figura 10) e em seguida a 390,
com (veja Figura 12), e sem paradas (veja Figura 11).
46
Figura 12 Visualizao da linha 390 com pontos de parada

Cabe registrar que os dados de parada aparentaram inconsistncia em todas
as linhas, dada a pouca distncia entre eles, no se mostrando teis.
Por ltimo, a Figura 13 apresenta as 5 ltimas posies de um nibus, em
particular, o A48081, da linha 415, cujo trajeto tambm apresentado.
Figura 13 Visualizao das 5 ltimas posies
47
4
A Plataforma
4.1
Objetivo
A Plataforma desenvolvida tem como objetivo facilitar a extrao de
conhecimentos a partir de dados de localizao georeferenciada de mobilidade
urbana, em particular, de dados do servio de transporte pblico via nibus
municipal da cidade do Rio de Janeiro.
4.2
Computao na Nuvem
Visando conferir escalabilidade, elasticidade e estabilidade para Plataforma
desenvolvida, assim como, no se preocupar com sua infraestrutura (e.g.
hardware, sistema operacional, softwares bsicos, etc.), optou-se pela utilizao
de um ambiente de computao na nuvem.
A ideia essencial da computao na nuvem permitir o consumo de
recursos computacionais, e.g., armazenamento, processamento, banda entrada e
sada de dados, sejam realizados atravs de servios, com pagamento baseado
na utilizao dos servio e grande elasticidade, i.e. capacidade de provisionar e
desprovisionar rapidamente grandes quantidades de recursos em tempo de
execuo.
O Windows Azure [58] a proposta da Microsoft para servios de
computao na nuvem. Os principais motivos que conduziram a essa escolha so
resumidos a seguir.
1) Abstrao do sistema operacional, pois, a princpio, no h necessidade
de instalar nada nos servidores, o que no ocorre com outros fornecedores;
2)
IDE
(Integrated
Development
Environment)
exigida
para
desenvolvimento de aplicativos gratuita (Miscrosoft Visual Studio Community

2015) e fornece uma srie de facilidades para o desenvolvedor, tais como
autocompletar, documentao dos mtodos, dentre outras;
3) Fcil instalao dos requisitos e kits para desenvolvimento e testes em
mquina local, reduzindo o tempo e custo de desenvolvimento;
48
4) Disponibilidade de uma grande variedade de artigos, exemplos, livros e
materiais de formao;
5) A escolha da linguagem de programao C#.Net aproveita o
conhecimento da sintaxe do C/C++, que muitos desenvolvedores dominam;
6) Interoperabilidade com outras tecnologias e linguagens de programao,
atravs do WCF (Windows Communication Foundation);
8) Oferece a possibilidade de armazenar arquivos de forma compartilhada,
com redundncia e estabilidade, atravs do servio Azure Blob Store;
9) Dispe do sistema de gerenciamento de banco de dados, relacional, Azure
SQL, que suporta dados espaciais e linguagem padro de consulta;
10) Possui um banco de dados orientado a documentos, Azure
DocumentsBD, que suporta dados semiestruturados;
11) Detm um leque abrangente de configuraes, permitindo a escolha dos
recursos computacionais sob medida para cada situao;
12) Por ltimo, mas no menos importante, oferece suporte a pesquisas
selecionadas (i.e. recursos computacionais gratuitos).
4.3
Estratgia de Armazenamento e Anlise dos Dados
Um dos maiores dilemas enfrentados no desenvolvimento desta Plataforma
foi a definio da melhor estratgia para armazenamento, processamento e anlise
dos dados, uma vez que essa definio influencia significativamente o custo
financeiro e computacional, podendo comprometer a sustentabilidade da soluo
e, especialmente, sua performance.
Abaixo elencamos os principais requisitos no funcionais da Plataforma,
relevantes ao contexto em tela:
1. A Plataforma deve persistir todos os dados obtidos da Prefeitura.
2. A Plataforma deve informar o mais prximo possvel do tempo real.
3. A Plataforma deve minimizar o tempo de resposta a requisies.
4. A Plataforma deve priorizar a otimizao de custos.
5. A Plataforma deve evitar riscos de perda de dados e indisponibilidade.
6. A Plataforma deve ser escalvel.
49
De forma a organizar o raciocnio, dividimos as principais opes

disponveis de armazenamento em grupos, conforme apresentado a seguir.
RAM
Os dados armazenados na memoria principal (Randon Access Memory)
da instncia, sem sombra de dvida, possuem o melhor desempenho
computacional, no entanto, este um espao mais custoso, limitado e
sem persistncia (i.e. os dados so perdidos ao reiniciar a instncia).
Portanto, deve ser usada com parcimnia. Tanto as mquinas virtuais
(VM), quanto os servios de nuvem (CS), disponibilizam este recurso
computacional em diferentes medidas.
BD SQL
Os sistemas de gerenciamento de banco de dados relacionais com
arquitetura integrada com extenses espaciais permite o controle e
manipulao de objetos espaciais, com gerncia de transaes, controle
de integridade, concorrncia e linguagens prprias de consulta.
O PostGIS [59] que estende o PostgreSQL o software livre mais
popular
deste
grupo.
Suas
caractersticas
so
exploradas
em
profundidade na obra [60].

O PostGis no um servio oferecido pelo fornecedor em questo, no
entanto, pode ser instalado em uma mquina virtual, consumindo seu
disco local. Dessa forma, redundncia, segurana, performance e
manuteno ficam por conta do desenvolvedor.
Outra opo deste grupo, o servio do fornecedor, o Azure SQL, uma
vez que contempla garantias de performance, escalabilidade e
redundncia, tambm suportando operaes espaciais.
Um ponto que merece registro, que em ambos os cenrios possvel
particionar tabelas, para melhorar a performance. Alm disso, seus
principais diferenciais so o suporte aos padres do Open Geospatial
Consortium (OGC), o que facilita o intercmbio de informaes
geogrficas, e a possibilidade de definir tipos de dados espaciais,
equipados com operadores especficos (operadores topolgicos e
mtricos).
50
BD NoSQL
Os bancos de dados orientados a documentos so bastante diferentes dos
tradicionais bancos de dados relacionais. Em vez de armazenar dados
em estruturas rgidas, como tabelas, eles os armazenam em documentos
vagamente definidos [61].
O MongoDB [62] o mais populares deste grupo, destacando-se pelo
suporte a operaes espaciais. Segundo [63], este possui desempenho
superior ao PostGIS, mas com um suporte um pouco menor as
operaes espaciais.
Este servio tambm no oferecido pelo fornecedor em questo, de
igual forma, pode ser instalado em uma mquina virtual. Em particular,
existem imagens prontas para sua configurao, tornado fcil configurar
a tecnologia, mas, novamente, questes como segurana, performance,
redundncia e escalabilidade ficam sobre a responsabilidade do
desenvolvedor.
De forma anloga ao grupo anterior, o fornecedor oferece sua tecnologia
similar como um servio, o DocumentBD, com os benefcios claros de
disponibilidade, escalabilidade e redundncia. Esse, como no caso
anterior, obedece um modelo de pagamento por faixas de uso mensal.
Cabe comentar que este grupo foi concebido para funcionamento em
mltiplas instancias e para processamento de grandes volumes de dados
semiestruturados (i.e. a estrutura pode variar entre documentos ou ser
modificada ao longo do tempo).
BLOB
fornecedor
disponibiliza
de
forma
nativa
um
servio
de
armazenamento de blobs (Binary Large OBject), que nada mais so do

que qualquer objeto binrio, como udios, vdeos e documentos,
incluindo-se arquivos no formato TXT e ZIP.
Capacidade e escalabilidade massiva, com o pagamento apenas pelo uso
do espao e transaes realizadas, contando ainda com alta
disponibilidade, redundncia e segurana/criptografia, so algumas das
caractersticas do servio, que intitula-se ideal para armazenar Big Data
para anlise.
51
A grande questo neste servio que os dados precisam ser transferidos
para uma instncia para serem manipulados, uma vez que nenhuma
operao suportada no servio, muito menos operaes espaciais.
Estes grupos foram primeiramente estudados com o enfoque de persistir
todos os dados recebidos da Prefeitura, e em especial, os dos dispositivos de GPS
dos nibus, que so preponderantes em termos de volume, apresentando, ainda,
crescimento significativo diria. Como referncia, somente o dia 02/09/2016
acresceu 6.263.744 de registros distintos enviados pelos equipamentos de GPS.
Na captura de dados descrita no captulo 3, os dados de GPS foram
armazenados no Azure Blob Store. Como referncia, esses dados de 02/09/2016
totalizam 86,18 MB se compactados (formato ZIP), aumentando para 331 MB se
armazenados em texto corrido no compactado (formato TXT). Quando inseridos
no PostGIS, Azure SQL, MongoDB ou DocumentBD, o espao requerido
muitas vezes maior do que para os dados em texto corrido, conforme observado
em todas as manipulaes dos dados dirios nestas tecnologias. Via de regra,
podemos manter em mente a relao de 1 para 10 do arquivo compactado para o
espao requerido nestes banco de dados, ou seja, se projetarmos um espao de 100
GB para o grupo BLOB, teramos que projetar na ordem de 1 TB nos grupos BD
SQL e BD NoSQL. Lembrando que em agosto de 2016 apenas os arquivos
compactados totalizavam mais de 36 GB, o que torna 100 GB uma projeo
adequada para o horizonte de um ano, dado que outras informaes sero
armazenadas.
A Tabela 13 lista as tecnologias supracitadas, adicionado referncias de
custo obtidas em 03/09/2016 do site do fornecedor [58] para uma mesma regio.
Grupo
Tecnologia
Capacidade (GB) x Mensal (R$/ms)
BD SQL
Azure SQL
2 GB por R$18,69/ms
RAM
Azure Cloud Service
0,75 GB por R$55,80/ms
Blob
Azure Blob Storage
1.000 GB por R$90,07/ms (c/ transaes e pago pelo uso)
BD SQL
PostGIS na VM
1.000 GB por R$5.169,87/ms
BD NoSQL
MongoDB na VM
1.000 GB por R$5.169,87/ms
BD NoSQL
Azure DocumentosDB
1.000 GB por R$5.401,50/ms (c/ transaes e pago pelo uso)
BD SQL
Azure SQL
1.024 GB por R$26.253,90/ms
RAM
Azure VM
448 GB por R$26.923,87/ms
Tabela 13 Tecnologias para armazenamento e processamento
52
Fica evidente que a opo de menor custo para armazenamento de grandes
volumes de dados o Blob, mesmo se considerarmos que o espao requerido para
armazenar os dados igual entre os grupos. No entanto, conforme exposto
anteriormente, o espao requerido nos grupos BD SQL e BD NoSQL maior para
os mesmos dados dirios compactados armazenados em BLOB. De forma
complementar, ao utilizarmos o Azure Blob, o fornecedor garante redundncia de
dados e do servio, reduzindo riscos, assim como, assegurando escalabilidade, ou
melhor ainda, elasticidade (i.e. possibilidade de consumir mais ou menos servio
ao longo do tempo). Resta agora avaliarmos a performance (tempo de resposta /
tempo real) deste armazenamento.
Ocorre que, conforme registrado na descrio do grupo RAM, a memria
principal sem dvida a mais rpida, portanto, incuo comparar sua
performance frente ao Azure Blob. No entanto, dado seu custo extremamente
elevado, preciso refletirmos em que situaes essa performance requerida e o
custo associado se justifica.
Nesse sentido, se pretendemos informar em tempo real, ou pelo menos, em
tempo quase real, dado que algum atraso intrnseco ao prprio dado recebido,
justifica-se buscarmos essa velocidade, desde que no se perca de vista a
preocupao com custo. Isto posto, temos que atentar que somente as informaes
mais recentes so relevantes nesse contexto, pois o passado, por definio, no
trata do que ocorre naquele instante na realidade. Dessa forma, o uso da memoria
principal pode ser conveniente, mantendo-se o cuidado com o volume
armazenado na mesma para processamento, buscando assim, uma boa relao de
custo-benefcio. Em particular, podemos implementar um servio na nuvem, a um
custo mnimo, especificamente com essa finalidade de armazenar e manipular em
memria o subconjunto de ltimas informaes recebidas de cada nibus (ex. 10
ltimas posies) e linha (descritizao atual das suas trajetrias e demais
informaes, como tarifa e nome), descartando as informaes na medida que se
distanciem
do
momento
corrente,
assim
como,
relacionando-as
com
conhecimentos previamente extrados do passado. Nessa estratgia, como os

dados utilizados estaro, em sua maioria, em memria principal, e nela sero
processados, ser alcanado, como consequncia, um excelente tempo de resposta.
Em funo desta estratgia, que precisa apenas de um subconjunto enxuto de
53
dados, um servio na nuvem com pouca memria j apresentaria bons resultados.
Vamos aprofundar a definio deste servio na seo 4.4.
Do ponto de vista do processamento/anlise dos dados histricos, tempo real
por definio no uma preocupao. Porm, os servios na nuvem tambm so
interessantes para assegurar tempo de resposta adequado, no entanto, no podem
armazenar a totalidade dos dados histricos, obviamente, em funo do custo,
sendo aceitvel, no mximo, realizar o cache de uma ou outra informao ou levar
um subconjunto para memria em busca de desempenho de processamento.
Combinando esses servios com o armazenamento em BLOB, poderamos extrair
conhecimento destes dados, uma vez que qualquer operao, espacial ou no,
pode ser implementada nos servios, com ampla liberdade. Em outras palavras, os
arquivos dirios podem ser copiados do armazenamento em BLOB para a
instncia do servio na nuvem que o processar, sendo o mesmo descartado
posteriormente, e o conhecimento extrado salvo em armazenamento adequado, a
ser discutido oportunamente. Lembrando que essa transferncia de arquivos
(BLOB) ocorre em rede local de alta velocidade, desde que o servio e
armazenamento sejam configurados na mesma regio. Como referncia, um
arquivo compactado, como o dia 02/09/2016 supracitado, leva menos de 2
segundos para ser transferido do BLOB para a instncia. Alm disso, fica evidente
que o processamento do arquivo se dar de forma sequencial, linha a linha,
portanto, quanto maior o conjunto de conhecimentos que puderem ser extrados
em uma nica passagem, menor ser o nus desta transferncia e leitura.
Em contrapartida, tendo em vista que tempo de resposta a questo em tela,
faz sentido avaliarmos o uso dos grupos BD SQL e BD NoSQL. Conforme estudo
supracitado, podemos considerar que o BD NoSQL seria uma alternativa de maior
desempenho. Em particular, aprofundamos nossos experimentos no DocumentBD,
uma vez que a soluo nativa deste grupo, ou seja, no perderamos a
escalabilidade e ao mesmo tempo no imputaramos riscos adicionais em relao
ao BLOB.
Um nico registro do dispositivo de GPS de nibus enviado pela Prefeitura
pode ser entendido como um documento, como exemplificado na Figura 14.
54
Figura 14 Um registro do dispositivo de GPS.

Imaginando que a coleo intitulada gps agrega estes documentos,
poderamos efetuar consultas sobre esses dados. Na verdade, um ponto
interessante, que essa tecnologia suporta consultas estilo SQL (nem todos os
comandos so suportados, por exemplo, no suporta agregao). Alm disso,
tambm suporta o Open Geospatial Consortium (OGC) para consultas espaciais.
Alguns exemplos de consulta so apresentados a seguir.
SELECT * FROM gps WHERE gps.DataHora >= "2016-0902T03:00:00" AND gps.DataHora < "2016-09-02T04:00:00"
SELECT TOP 1 gps.DataHora FROM gps WHERE gps.Ordem =

"B25512" ORDER BY gps.DataHora DESC
SELECT gps.Ordem FROM gps WHERE gps.Linha = " SV232"
SELECT
FROM
gps
WHERE
gps.Linha
"950"
AND
ST_DISTANCE(gps.Location,{"type": "Point","coordinates": [-22.81, 43.30]}) < 1000 -- (1km)

O tempo de resposta destas consultas extremamente rpido (< 1 segundo),
principalmente se comparada a estratgia anterior com consultas isoladas em
mltiplas datas, dado que envolve transferncia de arquivos e leitura sequencial,
podendo ainda ser reduzindo acrescendo ndices e outros recursos disponveis. No
entanto, precisamos nos questionar se essas so a natureza de consultas que
precisaremos para extrair conhecimento dos dados e se o tempo de resposta as
consultas o que determina o tempo de resposta ao usurio da Plataforma.
Nesse momento, torna-se extremamente relevante extrapolarmos a anlise
isolada dos grupos e voltarmos nossa viso para os processamentos do histrico
55
que sero endereados neste trabalho. Estamos, portanto, frente a uma
conceituao relevante para a sequencia deste trabalho, a Plataforma proposta no
se destina a realizar consultas em um ambiente de Big Data, mas sim, a realizar
Data Science, ou seja, extrair conhecimento a partir destes dados (analisar o Big
Data). Sendo assim, por exemplo, consultas interessadas na situao particular de
um nibus de forma isolada so pouco relevantes em comparao a consultas
sobre a evoluo das trajetrias destes nibus ao longo do tempo (durante uma
hora, um dia ou um perodo qualquer). Cada novo dia de registro de dados
somasse aos demais na viso histrica. Evidentemente, a imensa maioria de
algoritmos a serem implementados apresentaro como caracterstica o
processamento cronolgico e incremental dos dados, ou seja, processamento do
mais antigo para o mais recente, incluindo a cada dia os dados nele recebidos.
Reforamos que no est sendo tratada a discusso da viso do presente, do tempo
real, cuja estratgia de processamento e armazenamento foi definida
anteriormente, no grupo RAM.
Naturalmente,
os
procedimentos
serem
propostos
para
extrair
conhecimento a partir dos dados histricos ocorrem em duas situaes, quando

um procedimento novo definido e toda cronologia de dados precisa passar pelo
procedimento ou, quando este procedimento est estabilizado, ou seja, j
processou todo o passado, sendo necessrio aplicar o procedimento apenas a cada
dia, para os dados novos capturados do mesmo.
Imaginando a primeira situao, ao trazer os dados para a instncia, no caso
do BLOB, estaramos assegurando igual performance para todas as instncias,
permitindo assim, um processamento paralelo eficiente. No DocumentBD, o
nmero de transaes por segundo acessando esta mesma coleo centralizada,
passa a ser um limitador da performance desta paralelizao. O mesmo vale para
segunda situao, mas nesse caso o volume de dados bem menor, mas
precisamos considerar o tempo de insero dos dados no armazenamento, que
tambm relevante, no caso do banco de dados orientado a documentos. Por
exemplo, em um dia com 5 milhes de registros, o que muito comum, a incluso
levaria 27,78 horas, obtidos pela seguinte conta: 5.000.000 x 10kb por documento
x 2 procedimentos (validar se pode inserir e inserir) / 1.000 (unidades de
requerimento por segundo suportadas) / 360 (converso para horas), teramos /
56
3.600. Na prtica, a insero do dia 02/09/2016, sem qualquer ndice, levou mais
de 2 dias. Portanto, dado o menor custo e alta capacidade de paralelizao, faz
todo o sentido o uso do Azure Blob combinado com servios na nuvem para
processar os dados histricos para extrao de conhecimentos.
Corroborando, o tempo de resposta ao usurio final no depende, a priori, da
velocidade de extrao dos conhecimentos, mas sim da velocidade de consulta dos
conhecimentos j extrados, imaginando que idealmente essa extrao ocorrer
previamente, para assegurar um tempo de resposta adequado.
A Tabela 14 resume as percepes e decises.
Tecnologia
Resumo
Azure Cloud
Service
Sero utilizadas instncias pequenas, que tem um custo

extremamente acessvel (vide tabela anterior).
Processamento em paralelo pode ser utilizado para reduzir
tempo de extrao de conhecimento. A memria principal
pode ser utilizada para informaes mais prximas
possveis do tempo real nos casos aplicveis. Pode
implementar estratgias de cache.
Azure Blob
Storage
Armazenar os dados histricos. A priori, tambm

armazenar os conhecimentos extrados. Essa deciso tem
como racional o custo muito mais acessvel e a
possibilidade de processamento prvio em paralelo.
Azure SQL
Apresenta-se como uma boa alternativa para armazenar os

conhecimentos j extrados, oferecendo um bom tempo de
resposta em caso de crescimento do numero de usurios da
Plataforma. Nesse momento, se optou por no utilizarmos,
em funo do uso apenas experimental da Plataforma, no
entanto, introduzir o mesmo extremamente trivial.
Azure
DocumentosDB
Os algoritmos a serem implementados neste trabalho, assim

como, a possibilidade de processamento prvio em
paralelo, no justificaram o uso desta tecnologia. No
entanto, em situaes particulares de outros pesquisadores,
seria fcil migrar parte dos dados histricos para este
servio e efetuar consultas sobre estes dados.
Tabela 14 Resumo das percepes e decises

Diante desta anlise, optamos, por permanecer armazenando os dados no
Azure Blob, levando-os a uma instncia para processamento, sempre que
necessrio. Essa deciso garante custos bem menores e liberdade para implantao
de qualquer algoritmo nas instncias, inclusive algoritmos que assegurem o
57
processamento em paralelo quando necessrio. Se identificada a necessidade, o
SQL Azure poder ser utilizado para manipular os conhecimentos j extrados e o
Azure DocumentDB para consultas para obter informaes que no possam ser
previamente processadas.
Antecipando a apresentao dos algoritmos de extrao de conhecimento, a
ser realizada no captulo 5, o tempo observado para aplicar todos os algoritmos
para um novo dia inferior a cinco minutos, podendo ainda ser o processamento
paralelizado para manter este tempo com um nmero maior de conhecimentos
objetivados, ou seja, a meia noite e cinco minutos todos os conhecimentos
adquiridos a partir do histrica estaro considerando at a data anterior. Com o
BD NoSQL e BD SQL, o tempo de inserir os dados j no permitiria tal tempo de
resposta. Em resumo, o tempo de resposta do ponto de vista do usurio utilizandose o BLOB praticamente
imediato (apenas o tempo de consulta da
informao j processada e salva e sua transmisso a soluo cliente da

Plataforma), assegurando ainda o endereamento dos demais requisitos
supracitados.
4.4
Arquitetura
A Plataforma encontra-se estruturada como um conjunto de servios na
nuvem com papeis especficos, que atuam de forma coordenada para alcanar
bons resultados em termos de performance, disponibilidade, eficcia e eficincia.
A Figura 15 ilustra a arquitetura da Plataforma e na sequencia todos os seus
componentes so detalhados.
Conforme detalhado na seo 2.6, o conjunto de dados disponibilizado
pelo Portal de Dados Abertos da Prefeitura do Rio de Janeiro, que representado
no topo da figura anterior pela imagem de uma tela deste Portal. Esses dados so
coletadas e armazenadas pelo servio denominado Historical. A implantao
deste servio foi detalhada na seo 3.2. O objetivo deste servio assegurar que
todos os dados disponibilizados sejam capturados e armazenados no servio
Storage, formando assim um conjunto de dados histrico, que inclui os dados
apresentados nas sees 2.6 e 3.1. Naturalmente, este servio possui redundncia
e escalabilidade, reduzindo assim, o risco de qualquer perda de dados histrico.
58
Figura 15 Arquitetura da Plataforma na Nuvem

Nenhum acesso externo permitido a estes servios da Plataforma, porm,
cabe resgatar que para as visualizaes bsicas apresentadas na seo 3.3, foi
liberado acesso direto aos arquivos do servio Storage, uma vez que o objetivo na
poca era compreender os dados, mas na implantao definitiva da Plataforma os
acessos foram centralizados, como ser explicado adiante, para garantir a
segurana, escalabilidade e controle da soluo.
No outro lado da arquitetura, temos o servio Real Time, que tem como
misso tambm coletar estes mesmos dados, mas esses no so salvos para
formao de um histrico, pelo contrrio, so manipulados, estruturados e
mantidos em memria principal como uma viso da situao atual das linhas e
nibus, ou seja, do que est acontecendo em tempo quase real. Essa questo foi
discutida anteriormente.
Os servios Historical e Real Time asseguram que no ocorrero acessos
desnecessrios ao Portal. Estes no demandam escalabilidade, uma vez que
apenas uma instncia de cada servio suficiente para manter uma viso
atualizada dos dados, tornando extremamente econmica sua manuteno.
Os servios classificados como Extraction tem o objetivo de extrair
conhecimento a partir dos dados histricos. Esse servio pode ser implementado
com vrias funes (e.g. identificao de trajetrias) e se desejado com
59
processamento em paralelo (e.g. cada instncia processa um segmento). As
implementaes destes servios so discutidas em detalhes no prximo captulo.
Por sua vez, o servio Webservice tem a misso de orquestrar o consumo
dos dados histricos salvos em Storage e das informaes atuais disponibilizadas
pelo servio Real Time, podendo o prprio ser escalado em funo do nmero de
usurios que o consomem, assim como, adotar estratgias de cache. Este servio
tambm responsvel pelo cruzamento das vises histricas e atuais. Este servio
o nico canal de comunicao da Plataforma com o ambiente externo, sendo este
um servio no padro WCF. Portanto, qualquer soluo que implemente SOA
(service oriented architecture) pode consumir este servio.
4.5
Comunicao com a Plataforma
A Plataforma oferece atravs do servio Webservice um conjunto de
mtodos para acesso aos conhecimentos extrados a partir dos dados, so eles:
int HowManyBusesOperating()
int HowManyRoutesOperating()
string[] GetRoutesStatus(int status)
Retorna o nmero de nibus que esto operando naquele instante.

Retorna o nmero de linhas de nibus que possuem pelo menos um
nibus operando naquele instante.
Retorna o identificador (linha), nome, quantidade de nibus operando
naquele instante, quantidade de trajetos conhecidos e tarifa das linhas de
nibus. Os dados so separados por ponto e vrgula, sendo a informao
de cada linha em uma posio do vetor retornado. Se o parmetro
status enviado com 1, retorna apenas as linhas com pelo menos um
nibus operando naquele instante, se com 0, apenas as sem e, se com 2,
todas, independente de possuir ou no nibus operando naquele instante.
string[] GetBusesFromRoute(string linha)
Retorna a ordem dos nibus da linha de nibus cujo identificador

enviado como parmetro linha, sendo uma ordem em cada posio do
vetor retornado.
string[] GetBuses(string[] ordem)
Retorna a latitude e longitude com a ltima posio conhecida dos

nibus cuja ordem so enviadas como parmetro ordem, sendo a
informao de cada nibus em cada posio do vetor retornado e a
latitude e longitude separadas por ponto e vrgula.
60
string[] GetAllBuses(int status)
Retorna a ordem de todos os nibus. Se o parmetro status e nviado

com 1, retorna apenas nibus operando naquele instante, se com 0,
apenas os no operando e, se com 2, todos, independente se esto ou no
operando naquele instante.
string[] GetBusDetails(string ordem)
Retorna a latitude e longitude das ltimas 10 posies conhecidas do

nibus cuja ordem enviada como parmetro ordem, sendo uma
posio em cada linha do vetor retornado e a latitude e longitude
separadas por ponto e vrgula.
string[] GetBusDetailsWithProjection(string ordem)
Retorna a mesma estrutura do mtodo anterior, no entanto, cada

coordenada projetada na trajetria da linha, caso o nibus possua uma.
string[] GetShapesId(string linha)
Retorna o identificador de todos os trajetos da linha (shape_id) cujo

identificador enviado como parmetro linha, estando cada
identificador de trajeto em uma posio do vetor retornado.
string[] GetShape(string shape_id)
Retorna a latitude e longitude de cada ponto que distretiza a trajetria

cujo identificador enviado como parmetro shape_id, sendo um
ponto em cada linha do vetor retornado e a latitude e longitude
string GetShapeLength(int id)
Retorna o comprimento em metros da trajetria da linha cujo

identificador foi enviado no parmetro id.
string[] GetStops(string shape_id)
Retorna a latitude e longitude de cada ponto de parada cujo identificador

da trajetria da linha enviado como parmetro shape_id, sendo um
ponto em cada linha do vetor retornado e a latitude e longitude
string[] GetBusCloser(string
double distance)
latitude,
string
longitude,
Retorna a ordem dos nibus prximos a uma coordenada, que seja

enviada como parmetros latitude e longitude, sendo um nibus em
cada linha do vetor retornado. O parmetro distance define qual a
distncia mxima na qual um nibus deve ser considerado prximo a
coordenada enviada.
string[] GetSegments()
Retorna o identificador e nome de cada segmento monitorado, sendo um

segmento em cada linha do vetor retornado e as informaes em cada
linha separadas por ponto e vrgula.
string GetSegmentRegion(int id)
Retorna a regio do segmento cujo identificador foi enviado como
61
parmetro em id. A regio formada pela latitude mnima, latitude
mxima, longitude mnima e longitude mxima, separadas por ponto e
vrgula.
string GetSegmentPoints(int id)
string GetSegmentLength(int id)
Retorna a coordenada dos pontos que discretizam o segmento cujo

identificador foi enviado como parmetro em id , sendo a latitude e
longitude de cada ponto separados por ponto e vrgula, e cada
coordenada separado por barra vertical.
Retorna o comprimento em metros do segmento cujo identificador foi
enviado no parmetro id.
string GetGPSByDateAndSegment(string date, int segmentid)
string
GetTrajetoriesByDateAndSegment(string
segmentid)
Retorna todas os registros de GPS que se referem a dados utilizados para

monitorar um segmento. O registro contm data e hora, ordem do
nibus, latitude e longitude separados por tabulao, sendo os registros
separados por quebra de linha. O dia a ser considerado enviado no
parmetro date em formato aaaammdd e o identificador do
segmento em segmentid. O algoritmo para filtragem dos nibus no
segmento o mesmo detalhado para o mtodo que se segue.
date,
int
Retorna todas as passagens de nibus pelo segmento cujo identificador

passado no parmetro segmentid, para uma determinada data passada
em date. O algoritmo de descoberta de trajetrias apresentado no
prximo captulo. Essa passagem organizada como se segue: ordem do
nibus que descreve a trajetria, latitude e longitude destes nibus e
tambm a data/hora dos mesmos, total de metros, total de segundos e
velocidade mdia da trajetria, ndices dos nibus em relao aos pontos
que descretizam os segmentos, posio linear de cada ponto em relao
ao segmento, intervalo e de metros entre cada ponto e velocidade mdia
entre cada pontos. Os dados dos vetores so separados por tabulao,
barra e ponto e vrgula nesta ordem de prioridade.
string TrafficSummaryDay(int segmentid, string date)
Retorna a consolidao das trajetrias do segmento cujo identificador

passado no parmetro segmentid, para uma determinada data passada
em date, visando o conhecimento do trfego. Cada linha representa
um horrio, com exceo da ltima que o totalizador. As linhas
possuem as quantidades totais de trajetos, registros de GPS dos nibus,
distncia percorrida em quilmetros e tempo transcorrido em horas,
assim como, velocidade mdia, nesta ordem, separados por tabulao.
string TrafficSummaryPeriod(int segmentid, string dates)
Retorna a estatstica descritiva da consolidao das trajetrias do

segmento cujo identificador passado no parmetro segmentid, para
datas determinadas, passadas em dates, separadas por ponto e vrgula,
visando o conhecimento do trfego no perodo. Cada linha representa
62
um horrio, com exceo da ltima que o totalizador. As linhas
possuem as quantidades totais mdias de trajetos, registros de GPS dos
nibus, distncia percorrida em quilmetros e tempo transcorrido em
horas, assim como, velocidade mdia, nesta ordem, separados por
tabulao.
string TrajectoriesNow(int segmentid)
string TrafficNow(int segmentid)
Retorna as ltimas trajetrias identificadas no segmento passado em

segmentid, da mesma forma que as trajetrias para uma data
referencial so passadas, como explicado anteriormente.
Retorna o trfego atual no segmento passado em segmentid, incluindo
velocidade mdia, velocidade padro, percentual relativo entre elas e
atraso dos dados utilizados para o monitoramento em relao ao
momento corrente.
string GetOverViewDay(string date)
Retorna a consolidao dos registros de GPS capturados na data enviada

no parmetro date. Cada linha representa um horrio, com exceo da
ltima que o totalizador. As linhas possuem o total de registros,
registros sem informao de linha, linhas distintas, nibus distintos,
nibus distintos operando e nibus distintos operando sem linha, nesta
ordem, separados por tabulao. A avaliao da situao do nibus
como operando ou no feita considerando como referncia o trmino
de cada hora e desconsidera um mnimo de registros necessrios, dado
que ao longo de um hora espera-se obrigatoriamente um nmero de
registros suficientes para o nibus ser considerado operando durante a
hora.
string GetOverViewPeriod(string dates)
Retorna a estatstica descritiva da consolidao dos registros de GPS

capturados nas datas determinadas, passadas em dates, separadas por
ponto e vrgula, visando conhecer informaes gerais do servio de
transporte em questo. Cada linha representa um horrio, com exceo
da ltima que o totalizador. As linhas possuem a mdia de registros,
registros sem informao de linha, linhas distintas, nibus distintos,
nibus distintos operando e nibus distintos operando sem linha, nesta
ordem, separados por tabulao. as quantidades totais mdias de trajetos,
registros de GPS dos nibus, distncia percorrida em quilmetros e
tempo transcorrido em horas, assim como, velocidade mdia, nesta
ordem, separados por tabulao.
Obviamente que novos mtodos podem ser implementados neste servio,
para tornar outros conhecimentos disponveis na Plataforma. Considerando que o
acesso aos dados e as tcnicas de manipulao destes esto implementadas em
diversos servios, criar um novo mtodo tem seu desafio concentrado no
algoritmo que se deseja desenvolver para extrair o conhecimento desejado,
63
ficando transparente dificuldades de infraestrutura, capacidade computacional e
outras que normalmente tornariam esse processo muito mais pneroso para o
pesquisador.
Os conceitos que so utilizados em cada mtodo, como nibus operando,
segmento/regio, passagem do nibus pelo segmento, dentre outros, so
explicados aos longos do prximo captulo deste documento.
4.6
Solues Clientes da Plataforma
Ao adotar o padro WCF a Plataforma abre um vasto leque de ambientes e
linguagens de programao para desenvolvimento dos clientes de seus servios.
No decorrer deste trabalho implementamos trs clientes da Plataforma, a saber:
1) Busesinrio.com - Este website foi desenvolvido em PHP, utilizando
diretamente a API do Google Maps, e teve como objetivo primrio permitir
visualizaes bsicas dos dados armazenados, acessando diretamente os arquivos
salvos, mas posteriormente foi adaptado para consumo dos servios da
Plataforma. A seo 3.1 apresentou uma srie de visualizaes suportadas pelo
website.
2) BusesInRio WinDemo Este software foi desenvolvido em C#.Net para
execuo em desktop com sistema operacional Windows, utilizando a biblioteca
GMap.Net do MIT [78], tendo como objetivo demonstrar o consumo das vises
histricas e em tempo real da Plataforma, assim como, os conceitos de regio e
segmento, permitindo a validao dos segmentos escolhidos. Detalhes deste
software e dos conceitos so apresentados no prximo captulo.
3) BusesInRio App Esse aplicativo foi desenvolvimento em Swift para
execuo em dispositivos mveis (smartphones) com sistema operacional iOS,
visando fornecer uma srie de servios ao usurio final, o cidado/passageiro, a
partir do consumo de conhecimentos da Plataforma. Esse aplicativo ser
detalhado em captulo especfico adiante.
64
5
Extraindo Conhecimento dos Dados sobre o Trfego
5.1
Seleo de Segmentos
Em uma viso mais abrangente, os nibus podem ser considerados
sensores que viabilizam a compreenso dos padres e identificao de anomalias
no trfego de veculos nas reas urbanas. Naturalmente, a cobertura destes
sensores se concentra nas principais ruas da cidade, uma vez que os trajetos das
linhas de nibus utilizam prioritariamente vias de transito rpido e arteriais de
maior circulao, evitando em seu planejamento vias menores, como locais e
coletoras. Alm disso, podemos imaginar que algumas ruas principais da cidade
no so cobertas por nenhuma linha de nibus.
A escolha dos segmentos da cidade que sero monitorados, entendendo
segmento como uma rua, avenida ou parte destas, fundamental para se extrair
conhecimento sobre o trfego da cidade a partir destes dados de GPS dos nibus.
Nessa seo, apresentaremos a abordagem adotada para validao de um
segmento, para que o mesmo passe a ser monitorado. Essa abordagem poderia ser
repetido para todas as ruas/avenidas da cidade, para uma malha de segmentos
mais representativa possvel da rea urbana (estratgia dita como gulosa). A
abordagem consiste nos passos abaixo detalhados:
PARTE I Preparao dos dados sobre a cidade
1) Download de mais de 300 MB de informaes do OpenStreetMap [80]
sobre o mapa da Cidade do Rio de Janeiro.
2) Extrao apenas das informaes necessrias e organizao em dois
arquivos, utilizando a ferramenta de QGIS [82], conforme se segue.
65
Campo
Descrio
Id
Identificador nico do polgono que representa parte do mapa da cidade
Nome
Nome da rua ou avenida que o polgono representa
Tabela 15 Campos do arquivo poligonos-nomes.txt

Campo
Descrio
Id
Identificador do polgono que representa parte do mapa da cidade
Latitude
Latitude de uma coordenada do polgono (GPS, WGS84)
Longitude
Longitude de uma coordenada do polgono (GPS, WGS84)
Tabela 16 Campos do arquivo poligonos-coordenadas.txt

PARTE II Delimitando a regio onde o segmento est contido
3) A partir do nome da rua ou avenida contido no arquivo poligonosnomes.txt (veja Tabela 15) possvel selecionar o identificador dos
polgonos candidatos a descrever o segmento com este nome e,
consequentemente,
suas
coordenadas
no
arquivo
poligonos-
coordenadas.txt (veja Tabela 16). Em ambos os casos, uma busca

sequencial, com comparao textual linha a linha, suficientemente
eficiente. A Figura 16 ilustra a projeo desses dados no GoogleMaps
para o nome Rua Jardim Botnico. Desenvolvemos uma ferramenta
para desktop (em C# .Net) especfica para essa visualizao, que
acrescenta um marcador verde na primeira coordenada do polgono e
vermelho na ltima, sem a inteno de indicar qualquer sentido neste
caso. Alm disso, ela liga as coordenadas do polgono com linhas para
facilitar a visualizao. Complementarmente, ao clicar em um
marcador apresentado o identificador do polgono.
Figura 16 Discretizao OpenStreetMap da Rua Jardim Botnico
66
4) Como os dados do OpenStreetMap so cadastrados de forma
colaborativa pelos prprios usurios, possvel que polgonos
incorretos seja desenhados no mapa. Sendo assim, essencial
confrontar visualmente esses polgonos do OpenStreetMap com um
mapa de outra origem, como feito na Figura 16 com o GoogleMaps.
Ao clicar nos marcadores deste polgonos possvel obter seu
identificador, conforme ilustrado na Figura 17. Esses identificadores
podem ser inseridos em uma lista de polgonos a serem
desconsiderados no passo anterior.
Figura 17 Visualizao de polgono inconsistente do OpenStreetMap

5) Considerando apenas os polgonos validados possvel utilizar a
latitude e longitude de menor e maior valor dentre todas as
coordenadas dos polgonos para escolher os pontos que definem a
menor regio retangular que contenha todos estes polgonos (bounding
box), como ilustrado na Figura 18.
6) Deste ponto em diante, passamos a considerar o nome utilizado como o
prefixo do segmento a ser monitorado e a regio caracterizadas pelas
suas latitudes e longitudes mnimas e mximas como seus limites. Com
base no exemplo utilizado anteriormente, teramos ento o segmento
Rua Jardim Botnico com sua regio caracterizada pelos valores:
22.974896;-22.9603236;-43.2263832;-43.2045122.
67
Figura 18 Regio que delimita a Rua Jardim Botnico

PARTE III Busca trajetrias de linhas de nibus da regio
7) Utilizando
uma
coordenada
central
dos
polgonos
validados
anteriormente para a regio, possvel selecionar dentre todas as

trajetrias de linhas de nibus conhecidas quais tem uma coordenada
prxima desta, entendendo como prxima uma distncia linear de 100
metros ou menos entre as coordenadas (coordenada central dos
polgonos da regio x uma coordenada que discretiza uma trajetria de
uma linha de nibus). As trajetrias correntes da linhas de nibus so
disponibilizadas por mtodos apresentados na seo 3.3 deste trabalho,
no cabendo aprofundamento nessa seo. A Figura 19 ilustra as
trajetrias com proximidade a coordenada do segmento Rua Jardim
Botnico, utilizando a mesma ferramenta de visualizao das figuras
anteriores.
8) Se nenhuma trajetria for encontrada, o segmento em questo no
uma boa escolha para ser monitorado, dado que a probabilidade de no
existirem sensores no mesmo alta, ou seja, de no existirem nibus
passando pelo segmento. Caso contrrio, podemos seguir a anlise
considerando apenas as coordenadas das trajetrias que esto contidas
dentro da regio do segmento. A Figura 20 ilustra para o exemplo
Rua Jardim Botnico a regio com as trajetrias contidas. Cabe
observar que como existem coordenadas de incio e fim muito
68
prximas, existe superposio de marcadores, o que dificulta a
visualizao nessa imagem esttica (na figura anterior fcil ver o
marcador de incio de oito trajetrias, mas nessa figura s se destacam
dois, apesar de na realidade existirem todos os oito, pois eles passam
na regio).
Figura 19 Trajetrias prximas ao segmento Rua Jardim Botnico
Figura 20 Trajetrias dentro da regio do Rua Jardim Botnico

9) O passo seguinte trivial, a escolha da trajetria que representa o
segmento. Primeiramente temos que manter em mente o desenho
69
formado pelos polgonos que deram origem ao segmento, como
ilustrado anteriormente no item 5. Esse cuidado evita a escolha de uma
trajetria que no apresenta o mesmo desenho, como o caso da que se
inicia no topo esquerdo superior da Figura 20. Clicando nos
marcadores de incio possvel visualizar o identificador da trajetria e
selecion-la.
10) Em especial, quando existirem trajetrias iniciando em sentidos
opostos do segmento, podemos deduzir que o monitoramento deste
segmento pode ocorrer nos seus dois sentidos. Sendo assim, cabe
dividir o segmento em dois, mantendo a regio e seu prefixo, acrescido
de um sufixo em seu nome para representar o sentido. Mais uma vez,
utilizando o segmento Rua Jardim Botnico, podemos escolher as
trajetrias ilustradas na Figura 21 e na Figura 22 para representar seus
dois sentidos.
Figura 21 Segmento Rua Jardim Botnico (Humait => Gvea)
Figura 22 Segmento Rua Jardim Botnico (Gvea =>Humait)
70
PARTE IV Arquivo de segmentos da cidade
11) Repetindo a PARTE II e III para as ruas/avenidas desejadas formamos
um arquivo com os segmentos a serem monitorados na cidade,
conforme se segue. A Figura 23, que apresenta os dados para o
segmento utilizado como exemplo, permite compreender melhor os
dados contidos no arquivo. A Tabela 17 lista os campos contidos num
arquivo do tipo segmentos.txt.
Campo
Descrio
Id
Identificador nico sequencial do segmento
Nome
Nome do segmento incluindo, se necessrio, seu sentido
Regio
Lat. Mn. ; Lat. Mx. ; Long. Mn. ; Long. Mx. da regio
Coordenadas
Lat.;Lon.|Lat.;Lon.|Lat.;Lon.|Lat.;Lon.|.... do segmento
Tabela 17 Campos do arquivo segmentos.txt
Figura 23 Exemplo de dados de segmentos

Conforme mencionado anteriormente, essa abordagem poderia ser repetida
para todas as ruas/avenidas da cidade, ou seja, todos os nomes distintos do
arquivo poligonos-nomes.txt, para uma malha de segmentos mais representativa
possvel da cidade. No entanto, no mbito deste trabalho tal completude no se
justifica, portanto, optamos pela execuo desta abordagem para as ruas/avenidas
que entendemos representar de forma geral o estado do trfego da Zona Sul da
Cidade do Rio de Janeiro. Um subconjunto ilustrativo apresentado abaixo.
1. Rua Jardim Botnico
4. Rua Barata Ribeiro
2. Rua So Clemente
5. Avenida das Amricas
3. Rua Voluntrios da Ptria
6. Nossa Senhora de Copacabana
71
5.2
Checagem do Segmento Selecionado
Uma vez selecionados os segmentos para monitoramento do trfego da
cidade do Rio de Janeiro, precisamos validar se uma quantidade relevante de
nibus passam nesse segmento ao longo do dia, ou seja, se temos sensores
suficientes para monitorar o segmento. Para tanto, desenvolvemos um software
em C#.Net para execuo em desktop com sistema operacional Windows,
utilizando a biblioteca [78], que apelidamos de BusesInRio WinDemo.
Esse software tem como objetivo demonstrar o consumo das vises
histricas e em tempo real da Plataforma, assim como, os conceitos de regio e
segmento, permitindo a validao dos segmentos escolhidos.
A Figura 24 facilita a explicao do funcionamento deste software. Sua
interface se encontra em Ingls, dado que o mesmo foi utilizado para seo de
demonstrao de artigo apresentado em [75].
Figura 24 Tela inicial do software BusesInRio WinDemo

Na esquerda da interface, de cima para baixo, temos:
a) Na primeira rea, o nmero de nibus e linhas operando na cidade no
instante em que a ltima consulta foi realizada. Esse nmero obtido
com uma simples consulta aos mtodos
HowManyBusesOperating
72
HowManyRoutesOperating
da Plataforma. So essas informaes da
situao corrente (tempo quase real).

b) Na mesma rea, todas as linhas de nibus da cidade listadas,
independente se possuem ou no nibus operando, com diversas
informaes, como seu identificador, nome, nmero de nibus
operando, nmero de trajetrias conhecidas e tarifa. Esses dados so
obtidos com uma simples consulta ao mtodo
GetRoutesStatus
da
Platforma, passando o valor 2 como parmetro.

c) Na outra rea, temos os segmentos monitorados da cidade listados pelo
seu nome. Esses dados so obtidos com uma simples consulta ao
mtodo
GetSegments
da Plataforma. Abaixo deste, ainda na mesma
rea, existe um campo para se filtrar dados histricos por uma data
especfica.
d) A rea seguinte, destina-se a manipular no mapa a exibio dos dados
obtidos, ou seja, ocultar e exibir informaes, de acordo com filtros.
e) Por ltimo, so exibidas informaes consolidadas sobre os dados
obtidos com os filtros, que sero explicados melhor mais adiante.
A Figura 25 apresenta o resultado da seleo de uma linha de nibus e sua
exibio no mapa no lado direito. Repare que linhas coloridas so formadas para
representar os trajetos desta linha, obtidos com a conexo dos pontos que
discretizam cada um dos seus trajetos. Tambm apresentado no mapa a ltima
coordenada de nibus que declara pertencer a linha em questo. Esses dados
podem ser obtidos utilizando os mtodos
GetShape
GetBusesFromRoute, GetShapesId
da Plataforma, a partir do identificador da linha de nibus selecionada.
Na parte do mapa possvel ainda alterar o mapa a ser utilizado entre o

Google, Bing, OpenStreetMap e outros provedores de mapa, o que permite dirimir
qualquer dvida entre as projees, assim como, possvel mudar o zoom
aplicado ou o ponto central do mapa.
73
Figura 25 Visualizao de uma linha de nibus no WinDemo

Na rea explicada na letra d anterior, podemos, por exemplo, para uma
determinada linha de nibus, escolher apenas uma de suas trajetrias para
visualizao. Para ilustrar o uso de diferentes mapas, utilizamos o OpenStreetMap
na Figura 26 (alterando Shapes de ALL SHAPES para o nmero de um dentre os
listados, seria visualizado apenas a rota escolhida).
Figura 26 Visualizao de uma trajetria no WinDemo
74
Retomando a questo central desta seo, podemos escolher um segmento
no lado esquerdo e visualiz-lo no mapa. A Figura 27 apresenta o segmento Rua
Jardim Botnico (Gvea=>Humait) no mapa, exibindo tanto sua regio em
vermelho, quanto sua descritizao conectada em verde.
Esses dados foram
obtidos dos mtodos GetSegmentRegion e GetSegmentPoints da Plataforma.
Figura 27 Visualizao de um segmento no WinDemo

A Figura 28 mantm o campo Historical selecionado (i.e. informa que
deseja exibir todos os registros no mapa), ou seja, todos os nibus que passaram
pelo segmento na data escolhida, no caso, 09/06/2016, sero apresentados no
mapa. Para tornar mais agradvel a visualizao, a regio no apresentada no
mapa (campo Region est desmarcado). O segmento apresentado (campo
Segment est marcado), mas como o volume de nibus enorme, o segmento
completamente coberto. Destacamos que os nibus histricos so apresentados em
cinza, diferentes dos recentes, que foram apresentados em verde. Esses dados
foram obtidos do mtodo
GetGPSByDateAndSegment
da Plataforma. Fica evidente
nesta imagem, pela exploso de dados de GPS dos nibus, que o segmento
aparentemente possui sensores suficientes ao longo do dia para que o mesmo
possa ser monitorado.
75
Figura 28 Dados histricos de GPS em um segmento no WinDemo

Aplicando diferentes filtros por horrio, podemos validar se existem dados
suficientes para o monitoramento do segmento ao longo de todo o dia. A Figura
29 apresenta os dados anteriores filtrados pelo horrio de 23 s 23 horas.
Figura 29 Dados histricos de GPS em uma hora no WinDemo

A simples visualizao de cada segmento selecionado na seo 5.1 permite
validar estas escolhas. Naturalmente, como escolhemos ruas sabidamente de
76
grande cobertura pelas linhas de nibus, todas tendem a ser validadas, ou seja,
nibus suficientes passam nessas ruas ao longo de todo dia. No caso especfico,
todas as listadas no final da seo anterior foram validadas.
Cabe complementar a apresentao do software explicando seus botes:
a) O boto Atualizar permite realizar as consultas a Plataforma com os
parmetros selecionados, atualizando a visualizao no mapa.
b) O boto Data salva todas as informaes recebidas da Plataforma em
um arquivo texto para validao das visualizaes no mapa e para
anlises complementares que forem desejadas.
c) O boto Trajctories apresenta uma anlise da passagem dos nibus
pelo segmento, conforme apresentaremos ainda neste captulo.
d) A ltima caixa, tambm consolida informaes sobre essa passagem.
Os conceitos, algoritmos e vises relativas a essa anlise so tratadas na
prxima seo.
5.3
Identificao das Trajetrias dos nibus pelo Segmento
Uma vez selecionados e validados os segmentos para monitoramento do
trfego da cidade do Rio de Janeiro, podemos fazer uso dos dados histricos
salvos na Plataforma para identificar os padres de trfego deste segmento,
considerando diferentes dias, horrios ou situaes. Essa abordagem foi
inicialmente debatida em [76]. Sendo implementado um algoritmo de extrao de
trajetrias como se segue, aprimorado aps exaustivas testagens.
1) Para cada data, em ordem cronolgica, da mais antiga para a mais
recente (ano aaaa, ms mm e dia dd) copiado o arquivo
storage\gps\aaaammdd.zip para a instncia que processar a
requisio.
2) O arquivo descompactado e lido linha a linha, para cada segmento a
ser monitorado (id do segmento), sendo aplicado o algoritmo descrito
pelo diagrama da Figura 30 para cada registro (linha).
77
Figura 30 Diagrama do algoritmo de descoberta de trajetrias

3) Ao final da extrao das trajetrias do segmento para data, o arquivo
gerado na instncia salvo no armazenamento da Plataforma na pasta
seg com o formato ([yyyymmdd]_seg[id].txt). As trajetrias do dia
anterior, so includas no arquivo respectivo. As trajetrias no
concludas permanecem na memria.
4) Ao final da data, todas as trajetrias que no tenham o ltimo ponto no
dia anterior ao que ser processado so excludas, pois no existir dado
suficiente para conclu-las. Repare que algumas trajetrias podem ser
iniciados em uma data e concludos no dia seguinte, alm, obviamente
das concludas no mesmo dia. Esse processo evita que falhas na
informao dos dados pela Prefeitura resulte em trajetrias invlidas.
78
Esse processamento de limpeza apresentado no lado superior do
diagrama.
Cabe registro que esta abordagem escolhida, que segue a trajetria do
nibus sobre o segmento, mais precisa que outras estratgias mais enxutas, uma
vez que eventuais desvios ou interrupes no stream de dados so detectadas.
O mtodo
GetTrajetoriesByDateAndSegment
da Plataforma permite o
acesso ao resultado do algoritmo apresentado. Alm disso, os resultados deste

mtodo podem ser explorados e at consolidados no software supracitado,
conforme imagem da Figura 31.
Figura 31 Trajetrias da data sobre um segmento no WinDemo

Nessa representao visual podemos entender cada ponto em verde como o
primeiro registro de um nibus no trajeto no segmento e em vermelho como o
ltimo registro de um nibus, portanto, sinalizam o incio e fim de um trajeto. Os
pontos em amarelo so registros intermedirios deste trajeto. A conexo entre os
pontos apenas para facilitar a visualizao, e esta adota diferentes cores.
Cabe observar que a quantidade de segmentos para uma data considervel,
tornando a visualizao extremamente densa. No entanto, o software permite
filtrar as trajetrias individualmente ou pelo horrio de incio, confirme ilustrado
79
na Figura 32, para o horrio de 10 horas e posteriormente na Figura 33 para uma
trajetria em especial.
Esses filtros foram de suma importncia para depurao visual e
aprimoramento do algoritmo supracitado. Alm disso, as funcionalidades
implementadas nesse software podem ser reutilizadas para interaes diversas
com a Plataforma, criando assim um ambiente propcio aos novos pesquisadores.
Figura 32 Trajetrias na data/segmento iniciadas as 10h
Figura 33 Trajetria especfica sobre um segmento no WinDemo
80
A seguir apresentamos uma trajetria individualmente, ocorrida em um
segmento e data especficos, conforme consta na Figura 34, escolhida
especialmente para facilitar a compreenso de questes relevantes, como o clculo
de distncia.
Figura 34 Trajetria no WinDemo ilustrando uma situao

Nessa figura mantivemos a apresentao do segmento (em verde) e da
regio (zona vermelha). Repare que o segmento em questo apresenta uma curva
acentuada e os registros capturados ocorreram antes e depois desta curva. Com
isso, a distncia entre os pontos, uma linha reta, menor que a curva. Isso ocorre
em funo do segmento apresentar uma discretizao mais detalhada.
Outra questo interessante ocorre no segundo registro da trajetria, logo
aps o inicio (verde). Este registro informa que o nibus naquele momento estava
dentro de um prdio, como possvel visualizar. Obviamente que trata-se de
alguma interferncia na preciso do dispositivo de GPS do nibus, que na verdade
estava percorrendo a rua do segmento, como fica evidente ao analisar a trajetria
como um todo.
Dessa forma, fica claro que calcular a distncia entre dois registros no
representa a distncia percorrida pelo nibus naquele tempo. Nesse sentido, se faz
necessrio lanar mo de uma definio importante da geometria.
81
A projeo ortogonal de um ponto P sobre uma reta r o ponto P de r que
est mais prximo de P. Dessa forma, P o ponto de interseo entre a reta r e a
reta s que passa por P e perpendicular a r, conforme ilustrado na Figura 35.
Figura 35 Projeo ortogonal

Considerando que o segmento discretizado por uma sequencia de pontos
georeferenciados (latitude e longitude), conforme exaustivamente tratado na seo
5.2, podemos nomear cada par de pontos sequenciais desta discretizao como P1
e P2, obtendo uma reta r entre estes pontos, atravs de sua interpolao linear.
Por outro lado, o registro de dispositivo de GPS do nibus contm uma
coordenada georeferenciada (latitude e longitude), que seria nosso P, ou seja, o
ponto que se deseja projetar ortogonalmente na reta r. No entanto, nem sempre
essa projeo possvel, como ilustrado na Figura 36 com dois possveis pontos P
distintos. Na situao ilustrada na direita no seria possvel identificar o ponto P,
pois ele no existe.
Figura 36 Projeo ortogonal vivel e invivel

Tentando projetar o registro do nibus em todos os pares de pontos que
discretizam o segmento, encontraremos a projeo ortogonal deste registro no
segmento ou descobriremos que o registro no se encontra no segmento ao final
da testagem de todos os pares. Lembramos que essa testagem foi utilizada em um
82
dos passos da extrao de trajetrias sobre o segmento, conforme detalhado no
diagrama apresentado anteriormente.
O pseudo algoritmo implementado para projeo ortogonal apresentado na
Figura 37.
projection(p1, p2, p3)
{
Se(p1.Latitude == p2.Latitude && p1.Longitude == p2.Longitude)
{
p1. Latitude = p1.Latitude - 0.00001
p1.Longitude = p1.Longitude - 0.00001
}
var a = ((p3.Latitude - p1.Latitude) * (p2.Latitude - p1.Latitude)) +
((p3.Longitude - p1.Longitude) * (p2.Longitude - p1.Longitude))
var b = Pow(p2.Latitude - p1.Latitude, 2) + Pow(p2.Longitude - p1.Longitude, 2)
a = a / b
var p
p.Latitude = p1.Latitude + (a * (p2.Latitude - p1.Latitude));
p.Longitude = p1.Longitude + (a * (p2.Longitude - p1.Longitude));
var minx = Min(p1.Latitude, p2.Latitude;
var maxx = Max(p1.Latitude, p2.Latitude)
var miny = Min(p1.Longitude, p2.Longitude)
var maxy = Max(p1.Longitude, p2.Longitude)
Se ((latitude >= minx && latitude <= maxx) &&
(longitude >= miny && longitude <= maxy))
returna p
else
returna nulo
}

Ainda em relao ao clculo da distncia, no podemos esquecer, apesar
das visualizaes apresentadas serem todas em apenas duas dimenses, queremos
de fato calcular a distncias sobre a superfcie de uma esfera, a Terra. Nesse
sentido, podemos usar a frmula de Haversine [66] para calcular distncias entre
dois pontos de uma esfera a partir de suas latitudes e longitudes, conforme
ilustrado na Figura 38.
Figura 38 Triangulo esfrico resolvido pela lei de Haversine
83
Cabe destacar que esta frmula s uma aproximao quando aplicada
Terra, porque esta no uma esfera perfeita: seu raio varia de 6356,78 km nos
plos at 6378,14 km no equador. Estas pequenas correes so usadas em todo
lugar, devido a leve forma elipsoide do nosso planeta. Alm disso, essa frmula
apresenta um erro muito pequeno para distncias na ordem de quilmetros, no
entanto, para distncias na ordem de centenas de quilmetros outras frmulas
seriam mais adequadas, no entanto, para o contexto deste trabalho optamos pelo
uso desta em funo da sua performance.
O pseudo algoritmo implementado para clculo de distncia apresentado
na Figura 38. O mesmo considera para o retorna o valor absoluta em metros, com
preciso de duas casas decimais, porm fcil imaginar sua adaptao para outras
formas de retorno.
distance (p1, p2)
{
var dLat = (PI / 180) * (p2.Latitude p1.Latitude)
var dLon = (PI / 180) * (p2.Longitude - p1.Longitude)
var a = Sin(dLat / 2) * Sin(dLat / 2) +
Cos((PI / 180) * (p1.Latitude)) *
Cos((PI / 180) * (p2.Latitude)) *
Sin(dLon / 2) * (dLon / 2)
var c = 2 * Asin(Min(1, Sqrt(a))
var d = 6371 * c;
returna Abs(Round(d * 1000, 2))
}

Retornando a figura que motivou essa explicao de projeo ortogonal e
distncia, podemos agora utilizar esses conceitos para calcular efetivamente
quantos metros foram percorridos pelo nibus com base nos registros que
descrevem sua trajetria, ou seja, calcular o cumprimento da trajetria.
Lembrando, conforme destacado no diagrama anteriormente apresentado, que
apenas trajetrias com cumprimento mnimo de 60% do segmento so
consideradas. O clculo deste cumprimento corre da seguinte forma:
1) Localizamos o ponto Pi, para o qual o registro de GPS do nibus do
incio da trajetria (ponto verde) possui projeo ortogonal Pi na reta formada
por Pi-1 e Pi, onde estes so pontos sequenciais que descritizam o segmento.
2) O mesmo feito para encontrar o ponto Pf, para o qual o registro de
GPS do nibus do fim da trajetria (ponto vermelho) possui projeo ortogonal
84
Pf na reta formada por Pf-1 e Pf, onde estes so pontos sequenciais que
descritizam o segmento.
3) Como Pi e Pf so pontos que discretizam o segmento, podemos calcular
a distncia entre eles somando a distncia entte cada par de pontos sequencias
entre os mesmos, incluindo os prprios. Essa distncia chamamos de d.
4) Precisamos considerar que d no inclui a distncia de Pi para Pi e de
Pf para Pf, ou seja, as distncias di = distance(Pi,Pi) e df = distance(Pf,Pf).
5) Dessa forma, a distncia percorrida pela trajetria pode ser obtida
calculando-se d = d - df + di. Repare que as projees so sempre antes de Pi e Pf,
o que implica que deixamos de considerar distncia no incio e consideramos
distncias a mais no fim, por isso a diferena de sinal na frmula apresentada.
Isto posto, somos agora capazes de calcular a distncia percorrida pelo
nibus em uma passagem pelo segmento com base nos dados de seus dispositivos
de GPS. Da mesma forma, somos capazes de calcular o tempo necessrio para
percorrer tal distncia, utilizando o dado temporal de coleta nos dispositivos.
Consequentemente, podemos estimar a velocidade mdia da trajetria. De igual
forma, podemos analisar individualmente pares de dados destas trajetrias.
No software algumas informaes adicionais so apresentadas ao passar o
mouse sobre um registro da trajetria (veja Figura 40).
Figura 40 Informaes adicionais da trajetria no WinDemo
85
Esses informaes so respectivamente: number a posio da sequencia
de registros que descreve a trajetria, sendo o primeiro o zero; Lat/Lon as
coordenadas do registro; Date o momento da coleta do registro no dispositivo
GPS do nibus; index o ndice do ponto que descritiza o segmento seguinte a
projeo ortogonal destas coordenadas no segmento em questo; position o
valor percorrido do segmento em metros; interval (m) o intervalo temporal em
relao ao registro anterior; interval (s) o intervalo em distncia em relao ao
registro anterior; speed (km/h) a velocidade mdia entre o registro e seu anterior
em quilmetros por hora.
No software pode tambm ser obtido um grfico plotando a evoluo das
trajetrias em relao a sua durao em segundos e seu cumprimento em metros,
ao se clicar no boto Trajectories, conforme ilustrado na Figura 41.
Figura 41 Grfico durao x percurso da trajetria no WinDemo

Observe que os mesmos filtros por horrio de incio e de trajetria
individualmente esto tambm disponveis no grfico. Alm disso, possvel
passar o mouse sobre um dos registros (pontos azuis) para visualizar os valores
exatos, conforme ilustrado. Cada linha vermelha representa uma trajetria.
86
5.4
Anlise Descritiva das Trajetrias
Considerando a mdia das velocidades mdias como mdia da velocidade
mdia do horrio, podemos entender o comportamento do trafego no segmento ao
longo do dia, conforme a Figura 42.
Figura 42 Dados das trajetrias por horrio no WinDemo

A primeira coluna apresenta a hora para o qual se realizou a consolidao,
ou seja, foram utilizados dados de todos os trajetos que se iniciaram naquela hora
do dia, do seu primeiro ao ltimo segundo. A segunda coluna totaliza o nmero de
trajetrias que foram utilizadas para consolidao. Naturalmente, em horrios de
maior fluxo temos mais nibus na rua, logo um nmero maior de trajetrias, ou
melhor, sensores. Na sequencia temos o nmero de registros de GPS dos nibus
contidos nestas trajetrias. As colunas seguintes apresentam o total de quilmetros
e horas destas trajetrias. A ltima coluna apresenta a mdia das velocidades
mdias. Salientamos que no a diviso do total de quilmetros percorridos pelo
tempo em horas, mas a mdia das velocidades mdias das trajetrias.
87
Considerado a maior e menor mdia do dia como referncias, podemos
adotar uma escala de cores para avaliar o fluxo em cada horrio, conforme a
Figura 43.
Figura 43 Escala de cores para os segmentos em funo do trfego

O software em questo aplica essa escala e apresenta a velocidade mxima,
mnima e a mdia do horrio no canto esquerdo inferior de sua interface,
conforme ilustrado, quando a opo Traffic selecionada junto a uma hora nas
trajetrias, conforme Figura 44. A Figura 42 pode ser obtida pelo boto Hour.
Figura 44 Escala de cores para o segmento s 10 horas

A abordagem empregada pode ser expandida da viso de apenas um dia
para a comparao entre dias e diferentes horrios destes, permitindo assim, a
identificao de padres e a comparao entre diferentes situaes.
88
5.5
Identificao de Padres para os Segmentos
Conforme demonstrado ao longo do captulo, a Plataforma oferece um
mtodo para acessar as trajetrias dos nibus realizadas sobre um segmento
conhecido em determinada data (i.e. mtodo GetTrajetoriesByDateAndSegment),
conhecimento o qual extrado pelas instncias do servio Extraction da
Plataforma. A partir desses dados possvel consolidar estatsticas descritivas do
trfego do dia, como inicialmente apresentado na seo 5.3. A fim de evitar um
fluxo desnecessrio de dados, apenas esses dados consolidados podem ser
consumidos pelo mtodo chamado TrafficSummaryDay.
A seguir, para alguns segmentos escolhidos, apresentamos a evoluo da
velocidade mdia de cada dia ao longo do tempo junto a um indicador do nmero
de trajetrias, em milhares, utilizadas para este clculo. Os segmentos analisados
so respectivamente Rua Jardim Botnico (Humait => Gvea) no Figura 45, Rua
Jardim Botnico (Gvea => Humait) no Figura 46, Rua So Clemente no Figura
47, Rua Voluntrios da Ptria no Figura 48, Av. Ns. Sra. de Copacabana no
Figura 49 e Rua Barata Ribeiro no Figura 50.
Figura 45 Velocidade Rua Jardim Botnico (Humait => Gvea)
89
Figura 46 Velocidade Rua Jardim Botnico (Gvea => Humait)
Figura 47 Velocidade Rua So Clemente
Figura 48 Velocidade Rua Voluntrios da Ptria
90
Figura 49 Velocidade Av. Ns. Sra. de Copacabana
Figura 50 Velocidade Rua Barata Ribeiro

Uma concluso interessante que podemos chegar ao visualizar esses
grficos que existe uma tendncia na reduo do nmero de nibus passando
pelos segmentos em questo, percebido de forma mais acentuada na Figura 50. Ao
mesmo tempo, percebesse uma leve reduo na velocidade mdia na maioria dos
segmentos, excetuando-se os dois ltimos.
Outra viso interessante o comportamento do transito nos diferentes dias
da semana nestes mesmos segmentos anteriormente citados. Como esperado, final
de semana a velocidade mdia em todos os segmentos superior em relao aos
demais dias, conforme demonstrado no Figura 51.
91
Figura 51 Velocidade ao Longo dos Dias da Semana

A Figura 52 apresenta a variao da velocidade mdia histrica ao longo das
faixas de horrio de um dia, em particular, da mdia das sextas-feiras, adotando a
mesma ordem para os segmentos da figura anterior. Em contraste, o Figura 53
apresenta a variao ao longo dos domingos.
Figura 52 Velocidade ao Longo das Horas das Sextas-feiras
92
Figura 53 Velocidade ao Longo das Horas dos Domingos

As figuras apresentadas, obviamente poderiam subsidiar complexas anlises
estatsticas de cada um destes segmentos e de qualquer outro com sensores
suficientes (questo tratada na seo 5.2), estando essas trajetrias, suas
estatsticas descritivas e as inmeras possveis perspectivas de consolidao
franqueadas aos desenvolvedores que queiram consumir estes mtodos da
Plataforma, por exemplo, para desenvolver ferramentas de anlises de trfego com
propsitos especficos. Nesta seo nos limitamos a consolidar essas estatsticas
utilizando planilhas para ilustrar o poder do conhecimento extrado e, tambm,
que o padro do transito nestes segmentos varia ao longo do tempo (anos, meses,
dia, horas, etc.). Desta forma, a escolha de que datas considerar para composio
do padro extremamente relevante, assim como, a manuteno da subdiviso
dos dados por faixa de horrios para uma melhor sensibilidade.
Diante desta necessidade de selecionar datas especficas, a Plataforma
oferece o mtodo TrafficSummaryPeriod para retornar apenas a mdia das datas
desejadas, mantendo a viso dividia pelo horrio e a total descriminadas. Em
todos os mtodos mencionados nesta seo, o conhecimento base o mesmo que
detalhado na seo 5.4, as trajetrias sobre os seguimentos. O que varia o
perodo para o qual feito a mdia (das trajetrias do dia ou da mdia das
trajetrias dos dias selecionados). A preciso utilizada sempre de duas casas
decimais e o resultado comtempla sempre o total e o detalhamento por faixa de
hora.
93
Analisar o padro do trfego no segmento torna-se ento um simples
exerccio de escolher datas e consumir esse mtodo. No entanto, conforme ficou
claro com as figuras apresentadas nesta seo, essa escolha influencia
significativamente na velocidade mdia esperada como padro para o segmento e
suas faixas de horrio. intuitivo imaginar que o trfego apresente
comportamentos distintos em situaes diferentes, como, por exemplo:
perodo de frias x perodo letivo;
dias teis, x fins de semana x feriados;
perodo com um evento nas proximidades x sem impactos na regio;
acidente no segmento ou nos segmentos seguintes a este x sem acidente;
interveno nas vias do segmento x via normal;
alteraes nas vias do segmento x via sem alterao; e
dentre inmeras outras possibilidades.
Por outro lado, importante acrescentarmos na discusso o ponto de vista

do usurio deste padro de trfego, pois se estivermos falando, por exemplo, de
um profissional que consume essa informao interessado em analisar o impacto
positivo ou negativo de alteraes nos semforos ao longo do tempo, todas essas
variveis so relevantes para uma adequada comparao entre dados recentes e
histricos, mas se estivermos falando de um cidado, morador da rea urbana, que
est interessado em saber se o transito est bom ou ruim, o seu referencial mais
imediato, ou seja, tem maior relao com sua memria recente sobre o
comportamento da via.
Nesse sentido, propormos combinar uma viso histrica com uma viso do
comportamento recente para obter a velocidade padro (VMP) esperada em
um horrio, data e segmento em particular. Portanto, devemos considerar a mdia
de: (a) todos os dados histricos (VMH); (b) todos os dados histricos para o
mesmo dia da semana (VMD); (c) dados apenas dos cinco dias de igual dia da
semana que o antecederam (VM5D); e (d) dados dos ltimos sete dias anteriores
(VM7H).
Tomando o dia 31/08/2016 como de interesse, ou seja, para o qual
desejamos calcular o padro esperado para um determinado segmento, no caso, o
segmento Rua So Clemente, teramos o VMP da Tabela 18, com seus
94
respectivos VMH, VMHD, VM5D e VM7H utilizados na sua mdia. Nesta tabela
foi tambm includo a velocidade mdia dos horrios deste dia, posteriormente
extradas, para que se avalie o decorrer deste dia em relao ao padro calculado,
o que sintetizado na ltima coluna com a diviso deste valor extrado por VMP.
Tabela 18 Clculo Velocidade Mdia Padro para 31/08/2016

Lembramos que a velocidade mdia de um determinado horrio, data e
segmento foi calculada atravs das trajetrias iniciadas neste horrio, conforme
amplamente debatido nas sees 5.3 e 5.4. Alm disso, cabe registrar que nas
mdias valores zerados ou inexistente so desconsiderados, dado que essas
situaes indicam que no existem trajetrias vlidas suficientes sobre o segmento
naquela data e horrio ou mesmo no existem dados deste momento armazenados,
sendo as mdias mencionadas realizadas sem incluir este valor, mas no o
substituindo por um anterior, em todos os casos supracitados.
Em relao a Tabela 18, VMH utilizou todas as velocidades mdias desde
12/06/2014 at 30/08/2016 para calcular a velocidade mdia para cada horrio
deste segmento. Enquanto VMHD utilizou o mesmo perodo, mas apenas datas
que caram em quartas-feiras, dado que 31/08/2016 foi uma quarta-feira.
Raciocnio anlogo ocorreu para selecionar as datas de 24/08, 17/08, 10/08, 03/08
e 27/07/2016, todas quartas-feiras, para calcular VM5D. Por ltimo, apenas as
datas de 30, 29, 28, 27, 26, 25 e 24/08/2016 foram consideradas para calcular
VM7H.
95
Repare que a ltima coluna da Tabela 18 permite sugestionar que o dia em
questo, 31/08/2016, no segmento Rua So Clemente, foi dentro do esperado,
na maioria dos horrio, se considerado que at 80% do padro encontra-se dentro
da normalidade, excetuando-se as faixas de 16 e 17h, que ficaram na ordem de
60%.
Frente ao exposto, a Plataforma pode manter calculada a velocidade media
padro para os horrios da data corrente, no incio deste dia, podendo esses
valores serem nos seus servios, conforme discutiremos na seo que se segue.
Salientamos que a estratgia de clculo adotada no definitiva, uma vez
que analises estatsticas mais profundas podem ser realizadas e at sutilezas
especficas podem ser consideradas, sendo assim implementadas formulas de
clculo mais assertivas do pronto de vista preditivo. No entanto, a presente seo
cumpre com o objetivo de ilustrar o conhecimento que a Plataforma tem a sua
disposio para apoiar essas decises.
5.6
Monitoramento do Trfego em Segmentos
O algoritmo apresentado anteriormente para extrao de trajetrias sobre
segmentos todo baseado no recebimento de registros sequencias dos dispositivos
dos nibus. Portanto, esse pode ser aplicado para processamento de dados
histricos, enviados a partir da leitura de dados armazenados de forma sequencial,
como exaustivamente comentado anteriormente, assim como, tambm pode ser
usado a partir dos ltimos dados capturados, ou seja, pode monitorar o trfego em
tempo quase real.
Ressaltamos o cuidado em destacar que existe um atraso entre a situao
real e a identificao do trfego, oriundo do atraso no recebimento dos dados, de
minuto a minuto, mas tambm pela necessidade de aguardar o nibus finalizar seu
trajeto sobre o segmento para podermos extrair esse conhecimento e avaliar os
indicadores da trajetria.
Outra distino importante que na lgica histrica aguardvamos todos os
trajetos realizados em um segmento, iniciados em determinado horrio, serem
extrados, para consolidarmos indicadores, portanto, particularidades de uma
96
trajetria eram diludas para o horrio. Alm disso, trajetrias que no atendiam
minimamente a alguns critrios eram descartadas.
Diante dos argumentos expostos, julgamos adequado considerar um nmero
mnimo de trajetrias no segmento em determinado perodo para extrair um
indicador. Sendo assim, propomos considerar as ltimas 3 trajetrias satisfatrias
para determinar a situao atual do transito, considerando ainda, que alm das
checagens de trajetria j adotadas, no escolheremos trajetrias com intervalo de
concluso superior a 30 minutos entre elas.
O mtodo
TrajectoriesNow
da Plataforma fornece as trajetrias que
atendem essas caractersticas para um segmento em especfico, nos moldes das

trajetrias extradas do histrico. Assim como, o mtodo
TrafficNow
da
Plataforma fornece a velocidade mdia destas trajetrias. Esse mtodo retorna

tambm a velocidade padro esperada para aquele momento, conforme debatido
na seo anterior. Assim, essas velocidades podem ser comparadas (situao real
x padro) para definio de uma escala de cores ou outras indicaes. No prximo
captulo abordaremos formas de explorar esses conhecimentos visando o usurio
final.
5.7
Anlise Cruzada de Segmentos
Uma perspectiva interessante de ser analisada a relao entre segmentos
que se sucedem de forma direta ou indireta, ou seja, ruas conectadas diretamente
umas as outras no mesmo sentido de trfego ou que sejam conectadas por uma rua
comum entre as mesmas, preservando o sentido entre as trs. Por exemplo, o
segmento Rua So Clemente tem como um dos possveis destinos o segmento
Rua Jardim Botnico (Humait => Gvea), no caso, sendo estes conectados pela
Rua Humait, todos no mesmo sentido. Digamos ento que estes podem ser
apelidados respectivamente de A, C e B, onde de A possvel ir para B e de B
possvel ir para C. Desta forma, intuitivo que uma piora no trfego em C possa
refletir em uma piora A, uma vez que parte dos veculos deste segundo segmento
estaro indo para o primeiro.
A Tabela 18 apresentou a velocidade padro a ser esperada no segmento C
em 31/08/2016, assim como, a velocidade que ocorreu por faixa de horrio nesta
97
data. A mesma metodologia utilizada para construo desta tabela permitiu
elaborar a Tabela 19 para a mesma data em relao a A.
Tabela 19 Clculo Velocidade Mdia Padro para 31/08/2016 em A

Se focarmos a ateno apenas para variaes negativas de mais de 20%
entre a velocidade padro e a constatada, temos um momento especial a ser
analisado, que separamos na Tabela 20, para os segmentos A e C respectivamente.
Tabela 20 Destaque comparao A x C

De fato, a anlise deste destaque demonstra uma lentido perceptvel em C
durante as faixas de horrio de 16 e 17h, na casa de 40% negativa em relao ao
padro de cada horrio, que provavelmente influenciou em uma lentido em A,
que se propagou da faixa de 16 at a de 20 horas, nesta mesma ordem.
Diante do exemplo apresentado, fica evidente que os conhecimentos
extrados para cada segmento podem ser combinados de forma a um
98
conhecimento ainda mais abrangente ser alcanado, permitindo assim, um
entendimento da cidade como um todo. Inclusive, estes podem servir para
abordagens focada na identificao de anomalias no trfego e suas consequncias
nos segmentos anteriores. No entanto, no objetivo deste trabalho aprofundar a
anlise de anomalias e sua propagao pela cidade, mas este um tpico, sem
dvida, muito interessante, que pode ser posteriormente desenvolvido se
utilizando a Plataforma proposta.
5.8
Correo do Erro de GPS e Clculo de Cumprimento
Cabe registro, antes de evoluirmos para outros algoritmos, alguns
conhecimentos que podem ser extrados a partir de tcnicas detalhadas
anteriormente.
Descarte de Registro: Os dispositivos de GPS apresentam uma

margem de erro em geral na ordem de 100 metros. Portanto,
extrapolando, podemos adotar a definio de que um ponto distante em
mais de 200 metros de uma coordenada vlida no pode ser
considerado correto. Entendendo coordenada vlida, por exemplo,
como pontos que discretizam um segmento ou uma linha de nibus,
dado que essas foram visualmente validados frente aos mapas da
cidade. Como o clculo de distncia foi apresentada anteriormente, no
se faz necessrio detalhamento adicional deste raciocnio.
Correo do Erro de GPS: Os pontos no descartados, cuja

discretizao da linha de nibus correspondente conhecida, podem
ser corrigidos, ou seja, o nibus pode ser projetado exatamente para
interpolao destes pontos que a discretizam. Se existe apenas uma
projeo vlida a projeo pode ser adotada para exibio da posio
em questo do nibus. Seno, cabe escolher a mais prxima do ponto
com erro. Como o clculo de projeo ortogonal foi apresentada
anteriormente, no se faz necessrio detalhamento adicional deste
raciocnio.
Esse
conhecimento
GetBusDetailsWithProjection
est
disponvel
da Plataforma.
no
mtodo
99
Clculo
de
Comprimento
Registro:
Conforme
explorado
anteriormente, o cumprimento do segmento pode ser calculado

somando a distncia entre os pares de pontos sequenciais que
discretizam a mesma. Raciocnio idntico pode ser adotado para
calcular para os trajetos de linha de nibus. Esses conhecimentos esto
respectivamente disponveis nos mtodos
GetShapeLength
GetSegmentLength
da Plataforma.
5.9
Identificao da Situao (Operando ou no)
Os nibus sabidamente no operam 24 horas durante todos os dias da
semana, ocorrendo paradas em estacionamentos distribudos ao longo da cidade
ou mesmo interrupes de menor durao em pontos estratgicos da cidade. Nesse
perodo, no temos como afirmar quando os dispositivos de GPS ficam ligados
enviando dados e quando no ficam, ou mesmo se no estacionamento tem ou no
sinal para transmisso dos dados. Portanto, preciso extrair esse conhecimento
(saber se o nibus est ou no operando) a partir dos dados recebidos.
Para tanto, definimos os seguintes critrios para considerar um nibus
operando:
(a) se temos menos de cinco registros recebidos e o ltimo recebido tem
at 15 minutos; ou
(b) se nenhum dos at dez ltimos registros recebidos tem mais de 30
minutos em relao ao presente momento e, em relao ao ltimo, pelo menos um
deles apresenta distncia maior ou igual a 200 metros (deslocamento).
Teoricamente os nibus que atendem ao critrio (b) podem ser ditos como
operando boa probabilidade de acerto, sendo o critrio (a) uma situao transitria
por 15 minutos. Cabe destaque que nibus sem registro de GPS so considerados
no operando, assim como, qualquer situao que no atenda um dos critrios
acima.
De igual forma, podemos considerar uma linha de nibus operando se pelo
menos um dos nibus que informam estar servindo a mesma, no registro do
dispositivo de GPS, estiver operando, dado os critrios acima.
100
Os mtodos
HowManyBusesOperating
HowManyRoutesOperating
fazem
uso deste conceito para totalizar o nmero de nibus e linhas operando. Assim
como, outros mtodos que oferecem algum filtro pela situao (operando x no
operando).
5.10
Nmeros do Servio de nibus
Buscando uma viso geral da evoluo dos servios, implementamos uma
instncia do servio Extracion para analisar de forma geral os dados histricos,
calculando para cada dia os seguintes indicadores:
Nmero de registros de dispositivo de GPS dos nibus
Nmero de nibus distintos que enviaram registros
Nmero de linhas de nibus distintas que enviaram registros
Nmero de nibus distintos que enviaram registros e estavam operando
Nmero de linhas de nibus distintos que enviaram registros e estavam

operando
Nmero de registros sem informao da linha de nibus
Nmero de nibus operando sem informao da linha de nibus
Mesmos sete dados acima separados por cada uma das 24 horas
Anteriormente, utilizamos a hora corrente no mesmo fuso dos dispositivos

de GPS para definir se o nibus est ou no operado no presente momento. No
entanto, para uma viso histrica precisamos considerar o horrio do ltimo
registro ligo como hora corrente. Os conhecimentos extrados neste servio so
salvos no storage, na pasta count, com o seguinte formato de arquivo
yyyymmdd.txt. O mtodo GetOverViewDay da Plataforma permite acessar esses
arquivos para uma data especfica e o mtodo GetOverPeriod para um perodo
(data incio e data fim). No prximo captulo apresentaremos o consumo deste
conhecimento.
Adicionalmente, consolidamos este conhecimento em algumas vises
grficas. Da Figura 54 at a Figura 60 apresentamos a evoluo histrica do total
de linhas de nibus (total x operando) para cada dia da semana. Enquanto a Figura
61 apresenta para todos os dias. Enquanto, da Figura 62 at a Figura 68,
101
apresentamos a evoluo histrica do total de nibus (total x operando) para cada
dia da semana. De igual forma, o Figura 69 inclui todos os dias da semana.
Figura 54 Linhas Total x Operando nas Segundas-feiras
Figura 55 Linhas Total x Operando nas Teras-feiras
102
Figura 56 Linhas Total x Operando nas Quartas-feiras
Figura 57 Linhas Total x Operando nas Quintas-feiras
Figura 58 Linhas Total x Operando nas Sextas-feiras
103
Figura 59 Linhas Total x Operando nos Sbados
Figura 60 Linhas Total x Operando nos Domingos
Figura 61 Linhas Total x Operando com Linha de Tendncia
104
Figura 62 nibus Total x Operando nas Segundas-feiras
Figura 63 nibus Total x Operando nas Teras-feiras
Figura 64 nibus Total x Operando nas Quartas-feiras
105
Figura 65 nibus Total x Operando nas Quintas-feiras
Figura 66 nibus Total x Operando nas Sextas-feiras
Figura 67 nibus Total x Operando nos Sbados
106
Figura 68 nibus Total x Operando no Domingo
Figura 69 nibus Total x Operando com Linha de Tendncia

Uma concluso interessante a partir da Figura 61 e Figura 69, que o
nmero de linhas apresenta uma tendncia de reduo mais acelerada que o
nmero de nibus.
Por ltimo, a Figura 70 demonstra a distribuio mdia dos nibus
operando ao longo das horas do dia.
107
Figura 70 Distribuio nibus Operando nas Horas

5.11
Extrao de Rotas das Linhas de nibus
Como uma quantidade significativa de linhas no possui a discretizao de
seus trajetos, podemos utilizar dados histricos para extrair esse conhecimento.
No entanto, analisando com cuidado os dados, algumas situaes merecem
ateno:
O trajeto das linhas podem apresentar variaes ao longo do dia e ao

longo da semana, como reverses de faixas ou interdio de ruas.
Os motoristas podem adotar percursos distintos ao trajeto da linha para

cortarem caminho ou por erro.
O percurso do motorista at o estacionamento ocorre com frequncia e

esse trecho essencialmente pertence ao trajeto da linha, no entanto, no
ao trajeto em servio, que o que efetivamente interessa ao usurio.
Realizadas essas consideraes, adotamos o seguinte algoritmo

(a) Selecionamos a partir dos registros do dia de ontem (e.g. 20160902.zip,
arquivo compactado com todos os registros do dia 02/09/2016), os que
correspondem a linha que se deseja descobrir a rota (i.e. filtro pelo identificador
108
da linha presente no campo linha, e.g. identificador 432). Nesse processo de
seleo, o dcimo maior e menor valor de latitude e longitude dentre os registros
selecionados so identificados, definindo-se assim uma regio de interesse. Cabe
comentar que so descartados alguns valores (i.e. os nove de cada extremo) para
que excees no sejam consideradas, uma vez que se supe que existam vrios
nibus prximos em coordenadas que efetivamente esto prximas a rota da linha.
A Figura 71 ilustra a regio e os registros selecionados para o dia e linhas citados
como exemplo, ou seja, respectivamente 02/09/2016 e 432, contemplando assim,
21.046 registros (coordenadas de latitude/longitude recebidas do dispositivo de
GPS dos nibus) distintos desta linha ao longo do dia em questo.
Figura 71 Registros selecionados da linha 432 em 02/09/2016

(b) Utilizando dados de arruamento do OpenStreetMap [80], que foram
anteriormente obtidos na seo 5.1, possvel selecionar os pares de pontos que
discretizam arruamentos que esto contidos na regio de interesse, definida no
passo anterior. A Figura 72 apresenta esses pares, que totalizam 41.542 pares,
utilizando cores randmicas, obviamente, dentro da mesma regio.
109
Figura 72 Pares discritizando arruamentos dentro da regio

(c) Para cada registro de GPS selecionado em (a) descobrimos o par obtido
em (b) que tem menor distncia ortogonal para ele e, se essa distncia for inferior
a 100 metros, incrementamos o contador de registros prximos deste par. Os pares
que ao final possurem no mnimo 10 registros prximos contados, so mantidos
como pares candidatos para discretizao da linha. Cabe registro que para evitar
que para cada ponto seja necessrio calcular a distncia para todos os pares,
realizamos uma testagem dos limites de latitude e longitude entre essas
coordenadas de forma a descartar situaes que no possuiro projeo ortogonal.
A Figura 73 apresenta os pares que foram eleitos como candidatos para
discretizao da linha de identificador 432, a partir desta abordagem, obtidos
utilizando-se os registros do dia 02/09/2016 selecionados anteriormente, que
agora totalizam 465 pares.
110
Figura 73 Pares candidatos a discritizar a linha de nibus

(d) Buscando descartar dentre os pares candidatos os que no so
prximos aos demais, testamos a distancia dos pontos de cada par para os demais,
mantendo apenas os que tem pelo menos duas coordenadas at 100 metros de
distncia. A Figura 74 apresenta os 458 pares que atenderam ao critrio.
Figura 74 Pares candidatos aps novo filtro
111
(e) Os pares so ordenados em funo da distncia entre o ltimo e
primeiro ponto de cada um. Posteriormente, so conectados se apresentam essa
menor distncia de at 100 metros. Os pares so quebrados e cada coordenada
passa a fazer parte da descretizao da linha em questo, sendo pontos repetidos
descartados (possivelmente o ponto final de um par era o mesmo do inicial do
prximo par). A Figura 75 apresenta a descritizao final da linha 432.
Figura 75 Descritizao da linha 432

A aproximao em questo poderia ser aprimorada utilizando-se um maior
nmero dados de GPS, dado que existem trechos intuitivamente pertencentes a
rota, como destacado na Figura 76. Outras testagens tambm poderiam ser
includas para buscar maior refinamento, como uma avaliao sequencial de
pontos.
Figura 76 Destaque de trecho que deve pertencer a rota
112
No obstante a essas oportunidades de aprimoramento, podemos concluir
que a disritizao obtida uma aproximao vlida, a partir da observao da
discretizao das rotas da linha 432 informadas pela Prefeitura via arquivo CSV
(veja na seo 3.1), na data de 02/09/2016, apresentada na Figura 77.
Figura 77 Descritizao da linha 432 em 02/09/2016

Comprovasse assim, mais uma vez, a utilidade da Plataforma para se
extrair conhecimento a partir dos dados georeferenciados de mobilidade urbana,
ficando sugestionada a possibilidade de melhorias neste algoritmo de extrao de
conhecimento para trabalhos futuros.
113
6
Tomando Deciso com Dados
6.1
O Aplicativo
No captulo 5 apresentamos como so extrados diversos conhecimentos a
partir de dados de mobilidade urbana georeferenciados utilizando a Plataforma
apresentada. Nesse captulo os servios disponibilizados pela Plataforma so
explorados em uma aplicao (app) para dispositivos mveis, que tem como
objetivo subsidiar decises dirias e informar a populao e os usurios do servio
de nibus da Cidade do Rio de Janeiro.
O app foi desenvolvido em linguagem Swift para o sistema operacional
iOS, ou seja, para uso no Apple iPhone (smartphones). Este no armazena dados
locais no dispositivo e faz o consumo dos servios da Plataforma utilizando um
framework SOA para iOS, o SOAEngine [83]. A Figura 78 apresenta o cone do
app, nomeado como BusesInRio, na tela inicial do dispositivo.
Figura 78 Tela inicial do iPhone com cone do BusesInRio App
114
6.2
Informaes Bsicas
As primeiros telas implementadas no app oferecem aos seus usurios
informaes bsicas sobre o servio de nibus, comeando abaixo com a
quantidade de nibus e linhas de nibus operando naquele instante na Cidade.
Figura 79 Tela inicial do BusesInRio App

Como foi realizada a apresentao detalhada dos mtodos da Plataforma
anteriormente, trivial imaginar qual mtodo consumido para se obter cada
informao disponibilizada, portanto, no voltaremos a citar individualmente cada
mtodo consumido em cada tela.
A partir desta tela apresentada na Figura 45 possvel clicar no nmero de
nibus para abrir seu detalhamento ou mesmo clicar no nmero de linhas para
abrir o detalhamento destas. Alm disso, possvel mudar desta viso geral para
outras vises, utilizando a barra no rodap, no entanto, essas sero exploradas nas
prximas sees.
A Figura 80 apresenta as duas telas que detalham as linhas de nibus,
sendo na esquerda a que apresentada primeiro, contendo todas as linhas em
115
operao naquele instante. Ao clicar no cone verde no canto superior direito
desta, apresentada a tela da direita, contendo a lista das linhas de nibus que no
esto operando naquele momento. Clicando novamente, agora com o cone em
rosa, volta para viso das operando. Em ambas as telas possvel voltar para o
contexto da Figura 79 clicando em Resumo, assim como, aplicar filtros textuais
para localizar uma linha ou mais linhas em especfico.
Figura 80 Telas com lista de linhas de nibus

Repare que nessas telas so apresentadas diversas informaes sobre cada
linha de nibus, como o identificador, nome, quantidade de nibus, quantidade de
trajetos discretizados e tarifa. A lista pode ser rolada para visualizar todas as
linhas na situao em questo.
Em particular, podemos escolher uma linha para obter informaes
adicionais, com um simples clique na mesma. Obviamente que linhas com nibus
e trajetrias discretizadas possuem mais questes a serem exploradas. A Figura 81
apresenta o detalhamento de uma linha, neste caso em particular, da linha 2018,
com seus 11 nibus e 3 trajetos, conforme informado na figura anterior.
116
Figura 81 Tela apresentando detalhes de uma linha

Nessa tela so apresentados os nibus que informam servir a linha de
nibus em questo (vide cabealho com o identificador da linha, no caso, a
2018), sendo em verde os que esto operando e em rosa os no esto operando.
A posio exibida a do ltimo registro recebido do disposto GPS de cada
nibus. Os pontos que discretizam os trajetos (rotas) da linha so apresentados
conectados, formando uma linha colorida para cada trajeto. O boto no canto
superior esquerdo Linhas permite voltar para lista da Figura 81. O nmero da
linha de nibus fica em destaque no cabealho para melhor localizao do usurio.
Nessa viso no possvel ver todos os nibus e trajetos, mas
aproximando se tornar perceptvel a existncia de nibus e trajetos sobrepostos.
Essa sobreposio muito comum dada a existncia de trajetos de ida e volta
pelas mesmas ruas ou ruas muito prximas e pela proximidade de nibus nas
garagens. De qualquer forma, esses detalhes ficaro evidente ao explorarmos a
linha nas figuras que se seguem.
A Figura 82 apresenta o pop-up exibido ao clicarmos em qualquer um dos
nibus do mapa. Nele consta a ordem do nibus (i.e. nmero que consta na lateral
do veculo para identifica-lo de forma nica), a data e hora na qual o registro da
117
posio foi enviado pelo dispositivo de GPS do nibus, alm de um boto para se
obter informaes adicionais.
Figura 82 Telas apresentando um nibus da linha selecionado

Repare que nessas visualizaes, em especial na tela da direita, possvel
observar partes pequenas de outros trajetos em cores azuis e verde, alm do trajeto
em vermelho no primeiro plano. A diferena visual para as telas da Figura 81
devem-se aos recursos de zoom, mover e girar do mapa, lembrando que ambos
so da mesma linha, a 2018, conforme consta no cabealho.
Ao clicar no cone de informao (veja Figura 82), os nibus em rosa e
verde so retirados do mapa e so apresentados os 10 ltimos registros enviados
pelo dispositivo de GPS do nibus selecionado ou os que existirem. O registro
mais recente recebe o nmero 1, o anterior 2 e assim sucessivamente at 4, depois
os registros passam a ser todos em cinza sem numerao. A Figura 83 apresenta
as telas de informaes dos nibus selecionados na figura anterior, os de ordem
C41880 (esquerda) e C41874 (direita). Outra vez foram utilizados os recursos
de manipulao do mapa para melhor a visualizao, sendo mantida os trajetos da
linha de nibus em colorido.
118
Figura 83 Telas com informaes dos nibus selecionados

O boto no canto superior esquerdo 2018 permite voltar para
visualizao dos detalhes desta linha, conforme Figura 82. A ordem do nibus fica
em destaque no cabealho para melhor localizao do usurio.
O nibus C141880 est claramente se deslocando ao longo da linha,
enquanto o nibus C14187 apresenta variao insignificante entre um registro e
outro - aplicamos um zoom considervel para reparar uma variao de posio
entre os registros, natural da impreciso do GPS, o que confirma a informao
inicial de que ele no est operando.
Clicando em um destes registros possvel ainda obter informaes
adicionais sobre o mesmo, mas comentaremos essas informaes adiante, uma vez
que so as mesmas na anlise de um nibus independente da linha que esteja
servindo, que passaremos a tratar.
A Figura 84 apresenta as duas telas que detalham os nibus, sendo na
esquerda a que apresentada primeiro, contendo todos os nibus em operao
naquele instante. Lembrando que essa tela pode ser aberta atravs do clique no
nmero de nibus operando da tela inicial do app (veja Figura 78).
119
Figura 84 Telas com lista de nibus

O funcionamento das telas da Figura 84 e Figura 80 so anlogos.
possvel filtrar ou selecionar um nibus para detalhamento. Alm de filtrar e
trocar entre a visualizaes de nibus operando e no operando. Nessa tela
apresentado como informao adicional o nmero da linha para o qual o nibus
est em servio e zero se a informao desconhecida. Tambm apresentado o
atraso do ltimo registro recebido do dispositivo de GPS deste nibus em relao
ao momento da abertura da tela.
A Figura 85 apresenta exemplos de telas com a seleo de nibus da
Figura 84, no caso os nibus de ordem 10130 e 12707, estando o primeiro
operando e o segundo no. Essas telas tem o mesmo comportamento e recursos da
visualizao de informaes de um nibus a partir da linha, visualizada na Figura
83. Mais uma vez a ordem dos nibus apresentada no cabealho.
Repare que o primeiro nibus informa a linha para a qual est servindo,
apresentada na Figura 85, a Linha 910A, mas esta no possui pontos discretizando
seus trajetos, portanto as linhas no podem ser desenhadas. Da mesma forma, o
segundo nibus no informa nenhuma linha, como tambm possvel visualizar
na Figura 84.
120
Figura 85 Telas com visualizao de nibus operando e no

O percurso visualizado na esquerda est coerente com a situao de
operando do nibus. Enquanto o nibus da esquerda no est operando pelo fato
do ltimo registro do dispositivo de GPS deste nibus ter mais de 70 minutos de
atraso, portanto, possvel que o dispositivo tenha sido desligado.
Essa tela tem comportamento anlogo a visualizao de informaes de
um nibus a partir da visualizao de detalhes da linha de nibus, anteriormente
ilustrada. Em ambos os casos possvel clicar em um registro deste nibus para
obter maiores detalhes.
A Figura 86 ilustra na esquerda o pop-up apresentado ao clicar em um
registro de um nibus. So exibidas a hora do registro e a distncia linear (metros)
e temporal (segundos) deste ponto para o anterior. Lembrando que a distncia
linear no necessariamente a distncia percorrida pelo nibus.
Na tela da direita apresentado a mensagem exibida ao se clicar no cone
de informao deste pop-up da esquerda. O mesmo contm a coordenada (latitude
e longitude) do registro e sua data e hora.
121
Figura 86 Telas com detalhes do registro de um nibus

Destacamos que esse conjunto de informaes disponibilizada permite ao
usurio explorar o servio de nibus ofertado naquele momento, amparando
decises de menor complexidade em relao ao uso dos mesmos.
6.3
Agregando Informaes
As informaes da Plataforma podem ser potencializadas com informaes
externas. De forma natural, como estamos utilizando um dispositivo mvel o
usurio pode estar em diferentes localidades ao usar o app. Com isso, a posio
atual do usurio uma informao relevante, que pode ser utilizada para
potencializar os dados da Plataforma.
A Figura 87 apresenta a tela da perspectiva de Prximos, acessvel pela
barra inferior na tela inicial do app e em outras que apresentam o menu inferior.
Nela todos os nibus em operao cujo ltimo registro recebido est em um raio
de at 1.000 metros da sua posio atual so apresentados no mapa. O crculo azul
tem sua posio como centro e simboliza o raio em questo.
122
Figura 87 nibus prximos da minha localidade atual

A tela apresenta ainda uma barra deslizante para que o raio, inicialmente
definido como 1.000 metros, possa ser aumentado ou diminuindo. Alm disso,
assim como em outras telas onde os nibus so apresentados, possvel clicar em
um nibus para obter informaes adicionais, inclusive abrindo a tela para
visualizao dos 10 ltimos registros conhecidos, a partir do cone de informao.
Alm da posio atual, podemos agregar informaes de outros servios,
como, por exemplo, da Distance Matrix and Directions APIs do Google [77], que
disponibiliza informaes preditivas de tempo de viagem, inclusive via nibus,
que grtis at 2.500 requisies por dia e, tambm, encontra-se disponvel em
diversos planos para volumes maiores. Seu uso extremamente simples, bastando
requisitar um endereo passando coordenadas de origem e destino e outras
configuraes possveis, sendo recebido como retorno a previso de tempo em
JSON ou XML, com outros detalhes adicionais. Um exemplo de endereo
apresentado a seguir. Assim como, um exemplo de retorno na Figura 88.
https://maps.googleapis.com/maps/api/distancematrix/json?units=imperial
&origins=0.00,0.00&destinations=0.0,0.0&key=YOUR_API_KEY
123
{
"status": "OK",
"origin_addresses": [ "" ],
"destination_addresses": [ "" ],
"rows": [ {
"elements": [ {
"status": "OK",
"duration": {
"value": 0,
"text": "0 dias - horas"
},
"distance": {
"value": 0,
"text": "0 km"
}
},{
"elements": [ {
"status": "OK",
"duration": {
"value": 0,
"text": "0 dias - horas"
},
"distance": {
"value": 0,
"text": "0 km"
}
}]
} ]
}
Figura 88 Retorno em JSON da API do Google
6.4
Informaes do Servio
As informaes histricas armazenadas na Plataforma so por ela
sumarizadas para fornecer uma viso geral do comportamento deste servio em
cada dia ao longo do tempo. Em especial, uma informao particularmente
interessante o nmero de nibus e linhas distintas que enviaram dados de seus
dispositivos de GPS a cada dia e, adicionalmente, quantos destes estavam
operaram nestes dias. Incorporamos no App a opo de visualizar os dados
histricos em seu menu inferior, atravs do boto Histrico. A Figura 89
apresenta a tela aberta ao clicar nessa opo, que lista os dias que possuem
124
informaes sumarizadas com essas quatro informaes citadas, permitindo ainda
realizar filtros para localizar com maior agilidade uma data especfica.
Figura 89 Tabela com Dados Histricos no App

Para verificar se um nibus est operando foi considerado como ponto de
testagem as mudanad de hora, utilizando-se a mesma abordagem anteriormente
explicada na seo 5.9, mas substituindo a hora corrente pela hora completa em
questo e utilizando os dados capturados dentro da hora anteriores a essa.
Consequentemente, linhas operando so as que possuem pelo menos um nibus
operando na hora cheia.
A partir desta tela possvel acessar a viso grfica destes dados
histricos, clicando no cone de grfico existente no canto superior direito desta
tela. Tambm possvel selecionar uma data, clicando na mesma, para visualizar
detalhes deste dia em especfico, como, por exemplo, o nmero de nibus sem
linhas. Essas situaes so apresentadas na Figura 90 e Figura 91.
125
Figura 90 Tela com Grficos de Dados Histricos
Figura 91 Dados de Data Especfica no App
126
6.5
Conhecendo o Trfego
Os conhecimentos extrados sobre os padres do trfego nos segmentos
selecionados pode ser confrontado com a situao corrente do trfego, conforme
tratado na seo 5.6. Com base na velocidade corrente do segmento e no seu
padro, podemos novamente adotar uma escala de cores para estabelecem a
situao do trfego no segmento. Esse conhecimento colocado disposio do
usurio no App, atravs da opo Monitor em seu menu inferior. A Figura 92
ilustra essa tela, com os segmentos destacados.
Figura 92 Monitor do Trfego no App

A escala de cores pode ser definida de acordo com o interesse do
desenvolvedor da soluo, realizando a comparao destes valores de velocidade
corrente e padro. Neste App optamos pela seguinte escala: verde para corrente
20% acima do padro, laranja para corrente maior ou igual ao padro, marrom
para corrente at 40% do padro e vermelho para corrente abaixo do padro.
Nessa tela possvel visualizar esses valores de velocidade corrente
padro, assim como, o nome do segmento, simplesmente clicando sobre o mesmo,
conforme ilustrado na Figura 93. Adicionalmente, clicando no boto de
127
informao possvel conhecer o histrico deste segmento para uma data
qualquer, conforme telas da Figura 94.
Figura 93 Velocidade Corrente do Segmento no App
Figura 94 Velocidade do Segmento ao Longo do Dia
128
Cabe registar que essas interfaces so apenas uma pequena amostra das
funcionalidades que podem ser oferecidas aos usurios a partir deste
conhecimento. No entanto, essas telas j permitem apoiar o processo de deciso
do usurio, conforme trataremos na seo que se segue.
6.6
Processo de Tomada de Deciso com o App
A funcionalidade de monitoramento de segmentos, apresentada na seo
anterior, permite apoiar decises do dia a dia dos moradores desta rea urbana,
tais como se o momento ou no oportuno para trafegar sobre os segmentos ou se
um segmento a frente apresenta fluxo mais lento, indicando que o segmento
anterior tem tendncia a se congestionar.
Ao mesmo tempo, a funcionalidade de visualizao da situao geral
permite acompanhar o deslocamento dos nibus, verificar seus trajetos recentes e
at consultar as rotas das linhas, facilitando decises relacionadas a viagens mais
imediatas, que so ainda completadas pela tela de proximidade, que permite
identificar se um veculo est ou no prximo, para que o deslocamento at o
local de embarque seja iniciado.
Por outro lado, a funcionalidade de visualizao do histrico dos nibus e
linhas de nibus empodera a populao, que pode questionar a diminuio,
manuteno ou aumento nas caractersticas do servio (quantidade de veculos e
linhas em operao) ao longo do tempo e horrio.
Alm disso, este App pode ser entendido como um alicerce de evolues
incrementais para os usurios destes servio de transporte, uma vez que muitos
outros conhecimentos esto disponveis, como tratado na seo anterior, ou ainda
podem ser obtidos em trabalhos futuros, em especial, no que se refere a deteco
de anomalias e agregao de outras fontes de informao, com o Twitter.
129
Concluso
7.1
Descobertas e Contribuies
A Plataforma na nuvem para extrao de conhecimentos a partir de dados de
localizao georeferenciada de mobilidade urbana a contribuio central deste
trabalho. Seu funcionamento envolve a descoberta e testagem da melhor estratgia
de armazenamento e processamento deste grande volume de dados.
Alm disso, ficou evidente a conceituao, aplicao e anlise da viso de
que os dados de GPS dos nibus, que so transmitidos de minuto em minuto,
podem representar sensores mveis de trfego na cidade e de que as trajetrias
desses nibus podem ser entendidas como um data stream continuamente gerados
pelos equipamentos dos nibus.
No obstante, algoritmos extremamente importante foram propostos para
seleo de segmentos e para extrao das trajetrias desses nibus sobre os
segmentos em questo. Assim como, consolidaes estatsticas foram realizadas
para entender padres e monitorar o trfego. Sendo ainda vislumbrada a
identificao
de
anomalias
da
propagao
entre
segmentos
de
congestionamentos.
Por ltimo, cabe tambm destaque o software e app apresentados, que
permitem explorar os conhecimentos extrados de forma didtica e acessvel,
suscitando uma infinidade de solues que podem ser desenvolvidas consumindo
a Plataforma.
7.2
Lies Aprendidas
A principal lio aprendida neste trabalho que ao desenvolvermos
solues que transitam entre o mundo real (nibus na rua) e virtual (resultados dos
algoritmos de extrao de conhecimento da Plataforma), em um cenrio de
volumes considerveis e diariamente crescente de dados geogrficos,
indispensvel visualizar dados reais antes e depois da aplicao dos algoritmos
repetidas vezes, para que se compreenda os efeitos reais do que se est na teoria
buscando.
130
Tomando como exemplo a identificao das trajetrias dos nibus sobre os
seguimentos, foi necessrio repensar diversas vezes algoritmos que teoricamente
estavam corretos, mas que na prtica, no entregaram um resultado satisfatrio.
Quem imaginaria de antemo que um GPS poderia ficar sem enviar dados durante
horas e que o ltimo dado recebido e o primeiro, quando retornou a transmisso
de dados do GPS, eram respectivamente prximos ao incio e fim de um
segmento, criando uma falsa impresso de uma trajetria correta, mas na prtica
totalmente equivocada.
Portanto, em sntese, preciso experimentar com dados reais qualquer
proposta terica, preferencialmente em exausto.
7.3
Limitaes
A Plataforma baseasse em servios de tecnologia proprietria da Microsoft,
o Windows Azure, consequentemente, a capacidade de processamento e
armazenamento est diretamente vinculada aos recursos financeiros disponveis,
no entanto, apresenta-se uma relao otimizada de custo-benefcio para a soluo.
Outro ponto que merece destaque, que o foco deste trabalho no foi apurar
algoritmos de predio (e.g. a velocidade mdia esperada em determinado horrio
para um segmento em especfico), portanto, uma testagem de campo e
refinamentos estatsticos so oportunos para os que pretendem usufruir destes
benefcios.
Por ltimo, cabe registro que o clculo de tempo estimado de chegada,
tabela de horrios e identificao de pontos de parada, foram assuntos
inicialmente vislumbrados, que perderam prioridade em funo do foco na
proposio de uma plataforma slida para realizao de Data Science, mas que
podem ser endereados em trabalhos futuros.
7.4
Trabalhos Futuros
Os resultados alcanados neste trabalho motivam a realizao de trabalhos
futuros, a saber:
A estratgia implementada de segmentao da rea urbana tem a

caracterstica de ser gulosa, ou seja, baseasse na repetio extensiva do
131
procedimento para todas as vias da cidade, no entanto, algoritmos mais
refinados poderiam ser propostos para seleo destes segmentos, assim
como, estratgias para particionar esses segmentos em segmentos
menores poderiam ser elaboradas, conforme abordado em [76].
A deteco de trajetrias implementada demonstrou grande potencial

para deteco de anomalias no trfego e estudo da propagao de
anomalias pelos segmentos conectados. Portanto, um estudo mais
aprofundado pode ser conduzido, inclusive relacionando outras fontes de
dados (e.g. Twitter), para implementao de novos servios na
Plataforma e o acesso dos mesmos pelo App para populao das reas
urbanas.
O conhecimento extrado a respeito dos segmentos possibilita um

profundo estudo estatstico destas vias, que certamente podem amparar
um
melhor
planejamento
da
mobilidade
urbana,
ou
mesmo,
questionamentos da sociedade a seus governantes. Assim como, a

anlise de situaes especificas (ex. aumento do tnel X melhorou o
trfego na via Y). Esse estudo tambm permitiria a disponibilizao de
um site (busesinrio.com) com indicadores pblicos do servio de nibus
municipal da Cidade do Rio de Janeiro.
Utilizao da plataforma para desenvolvimento de algoritmos de tempo

estimado de chegada, descoberta de tabela de horrios e identificao de
pontos de parada das linhas de nibus.
Por ltimo, uma proposta interessante seria o uso da Plataforma com

dados de outra cidade, por exemplo, de So Paulo, e de outros modais,
por exemplo, Taxis.
132
Bibliografia
[1] SHI, WENHUAN, QING-JIE KONG, AND YUNCAI LIU. "A GPS/GIS
integrated system for urban traffic flow analysis." 2008 11th International
IEEE Conference on Intelligent Transportation Systems. IEEE, 2008.
[2] ZENG, WEI, CHI-WING FU, STEFAN MLLER ARISONA,
ALEXANDER ERATH, AND HUAMIN QU. "Visualizing mobility of
public transportation system." IEEE transactions on visualization and
computer graphics 20, no. 12 (2014): 1833-1842.
[3] ZHANG, CHA, AND YUNQIAN MA. Ensemble machine learning.
Springer, 2012.
[4] ZHANG, LIANGPEI, LEFEI ZHANG, AND BO DU. "Deep Learning for
Remote Sensing Data: A Technical Tutorial on the State of the Art." IEEE
Geoscience and Remote Sensing Magazine 4.2 (2016): 22-40.
[5] ZHENG, Y., CAPRA, L., WOLFSON, O., YANG, H. Urban computing.
ACM Trans. Intell. Syst.Technol. 5 (2014), 155.
[6] DADOS RIO. Prefeitura da Cidade do Rio de Janeiro. Disponvel em:
<http://data.rio/ >. Acessado em 14/09/2016.
[7] DHAR, VASANT. "Data science and prediction". Communications of the
ACM 56.12 (2013): 64-73.
[8] CAO, LONGBING. "Data science and analytics: a new era." International
Journal of Data Science and Analytics 1.1 (2016): 1-2.
[9] The Economist (2015), Artificial Intelligence, Rise of the machines.
Disponvel
em
<http://www.economist.com/news/briefing/21650526artificial-intelligence-scares-peopleexcessively-so-rise-machines>. Acessado
em 14/09/2016.
[10] ASAMOAH, DANIEL, DEREK DORAN, AND SHU SCHILLER.
"Teaching the Foundations of Data Science: An Interdisciplinary Approach."
arXiv preprint arXiv:1512.04456 (2015).
[11] WALLER, MATTHEW A., AND STANLEY E. FAWCETT. "Data science,
predictive analytics, and big data: a revolution that will transform supply
chain design and management."Journal of Business Logistics 34.2 (2013):
77-84.
[12] GARTNER <www.gartner.com>. Acessado em 14/09/2016.
[13] GUBERFAIN, B.; CRTES VIEIRA, H. A visual analysis of bus GPS data
in Rio. Pontifcia Universidade Catlica do Rio de Janeiro, 2015.
[14] BARBOSA, L.; KORMKSSON, M.; VIEIRA, M. R.; TAVARES, R. L.;
ZADROZNY, B. Vistradas: Visual Analytics for Urban Trajectory Data.
GEOINFO. XV Brazilian Symposium on GeoInformatics.
[15] PU, J., LIU, S., DING, Y., QU, H., AND NI, L. M. (2013). T-watcher: A
new visual analytic system for effective traffic surveillance. In Proc. of
IEEE MDM, pages 127136.
133
[16] LU, C.-T., BOEDIHARDJO, A. P., AND ZHENG, J. (2006). Aitvs:
Advanced interactive traffic visualization system. In Proc. of IEEE ICDE,
pages 167167.
[17] SHEKHAR, S., LU, C. T., LIU, R., AND ZHOU, C. (2002). Cubeview: a
system for traffic data visualization. In Proc. of IEEE Intl. Transp. Sys.,
pages 674678.
[18] GEISLER, S.; QUIX, C.; SCHIFFER, S.; JARKE, M. An evaluation
framework for traffic information systems based on data streams.
Transportation Research Part C: Emerging Technologies, v. 23, p. 2955,
2012.
[19] YAN, Z., SPREMIC, L., CHAKRABORTY, D., PARENT, C.,
SPACCAPIETRA, S., AND ABERER, K. (2010). Automatic construction
and multi-level visualization of semantic trajectories. In Proc. of ACM
SIGSPATIAL, pages 524525.
[20] ZHANG, J.-D.; XU, J.; LIAO, S. S. Aggregating and sampling methods for
processing GPS data streams for traffic state estimation. IEEE Transactions
on Intelligent Transportation Systems, v. 14, n. 4, p. 16291641, 2013.
[21] ALBUQUERQUE, F.C., Environment changes detection: A proactive
system to monitor moving objects. Dissertao de Mestrado, PUC-RJ, 2012.
[22] ZHU, B.; XU, X. Urban Principal Traffic Flow Analysis Based on Taxi
Trajectories Mining. International Conference in Swarm Intelligence. Anais,
2015.
[23] ALBUQUERQUE, F.C., M.C. CASANOVA, H. LOPES, L.R. REDLICH,
J.A.F. MACEDO, M. LEMOS, M.T.M. CARVALHO, C. RENSO. A
methodology for traffic-related Twitter messages interpretation. In
Computers in Industry, Vol. 78, pages 57 - 69, Elsevier, 2016.
[24] REDLICH, L.R. Modelagem de eventos de trnsito com base em clipping de
grandes massas de dados da Web. Dissertao de Mestrado, PUC-RJ, 2013.
[25] KUMAR, P.; RANGANATH, S.; WEIMIN, H.; SENGUPTA, K.
Framework for real-time behavior interpretation from traffic video. IEEE
Transactions on Intelligent Transportation Systems, v. 6, n. 1, p. 4353,
2005.
[26] SUN, D.; LUO, H.; FU, L.; et al. Predicting bus arrival time on the basis of
global positioning system data. Transportation Research Record: Journal of
the Transportation Research Board, n. 2034, p. 6272, 2007.
[27] GUNJAL SUNIL, N.; JOSHI AJINKYA, V.; GOSAVI SWAPNIL, C.;
KSHIRSAGAR VYANKTESH, B. Dynamic Bus Timetable Using GPS.
International Journal of Advanced Research in Computer Engineering &
Technology (IJARCET) Vol, v. 3, n. 3, p. 775778, 2014.
[28] HOU, L.; ZHANG, Z.; LU, B.; XU, R.; ZHANG, Y. Estimation of incidentinduced congestion on signalized arteries using traffic sensor data. Tsinghua
Science and Technology, 2012.
[29] CHEN, C.; ZHANG, D.; CASTRO, P. S.; et al. Real-time detection of
anomalous taxi trajectories from GPS traces. International Conference on
134
Mobile and Ubiquitous Systems: Computing, Networking, and Services.
Anais, 2011.
[30] ARANA, P.; CABEZUDO, S.; PEALBA, M. Influence of weather
conditions on transit ridership: A statistical study using data from Smartcards.
Transportation Research Part A: Policy and Practice, v. 59, p. 112, jan 2014.
[31] KHATTAK, A.; WANG, X.; ZHANG, H. Incident management integration
tool: dynamically predicting incident durations, secondary incident
occurrence and incident delays. IET Intelligent Transport Systems, v. 6, n. 2,
p. 204214, 2012.
[32] CHUNG, Y.-S.; CHIOU, Y.-C.; LIN, C.-H. Simultaneous equation
modeling of freeway accident duration and lanes blocked. Analytic Methods
in Accident Research, v. 7, p. 1628, 2015.
[33] KUANG, W.; AN, S.; JIANG, H. Detecting traffic anomalies in urban areas
using taxi GPS data. Mathematical Problems in Engineering, v. 2015, 2015.
[34] KOETSE, M. J.; RIETVELD, P. The impact of climate change and weather
on transport: An overview of empirical findings. Transportation Research
Part D: Transport and Environment, v. 14, n. 3, p. 205221, 2009.
[35] LI, R. Traffic incident duration analysis and prediction models based on the
survival analysis approach. IET Intelligent Transport Systems, v. 9, n. 4, p.
351358, 2015.
[36] MILLER, M.; GUPTA, C. Mining traffic incidents to forecast impact.
Proceedings of the ACM SIGKDD International Workshop on Urban
Computing.
[37] PAN, B.; DEMIRYUREK, U.; GUPTA, C.; SHAHABI, C. Forecasting
spatiotemporal impact of traffic incidents for next-generation navigation
systems. Knowledge and Information Systems, v. 45, n. 1, p. 75104, 2014.
[38] TAVASSOLI HOJATI, A. Modelling the impact of traffic incidents on
travel time reliability. The University of Queensland, 2014.
[39] WANG, J.; LIU, B. Modeling the duration and queue length of Urban
Expressway incident. 2015 International Conference on Transportation
Information and Safety (ICTIS). IEEE.
[40] XIE, W.; WANG, J. Modelling the impact scope of urban express way
incident. 2015 International Conference on Transportation Information and
Safety (ICTIS). IEEE.
[41] ESTER, M., KRIEGEL, H., SANDER, J., XU, X.. A density-based
algorithm for discovering clusters in large spatial databases with noise. In:
Proceedings of the 2nd International Conference on Knowledge Discovery
and Data Mining, (1996): 226231.
[42] ESTER, M., KRIEGEL, H.-P., SANDER, J., WIMMER, M., XU, X.
Incremental clustering for mining in a data warehousing environment. In:
Proceedings of the 24th International Conference on Very Large Data Bases,
San Francisco, CA, USA, (1998): 323333.
135
[43] FRED, ANA LN, AND ANIL K. JAIN. "Combining multiple clusterings
using evidence accumulation." IEEE transactions on pattern analysis and
machine intelligence 27.6 (2005): 835-850.
[44] RORIZ JUNIOR, M., M. ENDLER, F. SILVA E SILVA, M. A.
CASANOVA AND H. LOPES. A heuristic approach for on-line discovery
of unidentified spatial clusters from grid-based streaming algorithms. 8th
International Conference on Big Data Analytics and Knowledge Discovery DaWaK (2016).
[45] AMINI, A., WAH, T., SABOOHI, H. On density-based data streams
clustering algorithms: a survey. J. Comput. Sci. Technol. 29 (2014), 116
141.
[46] JOSE, D.; PRASAD, S.; SRIDHAR, V. G. Intelligent vehicle monitoring
using global positioning system and cloud computing. Procedia Computer
Science, v. 50, p. 440446, 2015.
[47] ARBOLEDA, M. A.; PARRA, I. F.; ARISTIZBAL, I.; SABOGAL, H.
Estudio dinmico de la movilidad en la ciudad de Santiago de Cali Colombia. X Congreso Latinoamericano de Dinmica de Sistemas. Buenos
Aires, Argentina.
[48] KARGUPTA, H.; SARKAR, K.; GILLIGAN, M. "MineFleet: an overview
of a widely adopted distributed vehicle performance data mining system.
Proceedings of the 16th ACM SIGKDD international conference on
Knowledge discovery and data mining. 2010.
[49] IBGE.
Acessado
em
14/09/2016.
Disponvel
em:
<http://cidades.ibge.gov.br/xtras/temas.php?lang=&codmun=330455&idtema
=16&search=||s%EDntese-das-informa%E7%F5es>.
[50] IPEA.
Acessado
em
14/09/2016.
Disponvel
em:
<http://www.ipea.gov.br/portal/images/stories/PDFs/SIPS/110124_sips_mobi
lidade.pdf>.
[51] Constituio Federal de 1998. Acessada em 14/09/2016. Disponvel em:
<http://www.planalto.gov.br/ccivil_03/constituicao/
constitui%C3%A7ao.htm>.
[52] Lei Federal 12.581. Acessada em 14/09/2016. Disponvel em
<http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2012/lei/l12587.htm>.
[53] DAPP.
Acessado
em
14/09/2016.
<http://dapp.fgv.br/sites/default/files/document.pdf>.
Disponvel
em:
[54] DATABANK FETRANSPOR/RIONIBUS de 13/04/2015, sendo 2003 e

2012 do PDU e 2016 projees. Disponvel em FETRANSPOR.
[55] FETRANSPOR.
Acessado
em
14/09/2016.
Disponvel
em:
<https://www.fetranspor.com.br/mobilidade-urbana-setor-em-numeros>.
[56] IBGE.
Acessado
em
14/09/2016.
Disponvel
em:
<http://www.ibge.gov.br/home/estatistica/populacao/censo2010/sinopse.pdf>.
[57] GTFS.
Acessado
em
14/09/2016.
<https://developers.google.com/transit/gtfs/>.
Disponvel
em
136
[58] Microsofr Azure. Disponvel em <https://azure.microsoft.com/en-us/>.
Acessado 31/08/20-16.
[59] RAMSEY,
P.
PostGIS
manual.
Disponvel
em
<http://postgis.refractions.net/documentation>. Acessado em 14/09/2016.
[60] MARCO ANTONIO CASANOVA, GILBERTO CMARA, CLODOVEU
A. DAVIS JR., LBIA VINHAS E GILBERTO RIBEIRO DE QUEIROZ. "
Bancos de Dados Geogrficos". Disponvel em <http://www.inf.pucrio.br/~casanova/Publications/Books/2005-BDG.pdf>.
Acessado
em
14/09/2016.
[61] CUNHA, T. M. DE A. "Escalabilidade de Sistemas com Banco de Dados
NoSQL: um Estudo de Caso Comparativo com MongoDB e MySQL. 2011."
85 f. Trabalho de Concluso de Curso (Cincia da Computao) Centro
Universitrio da Bahia Estcio, Salvador.
[62] MONGODB. Disponvel em <https://www.mongodb.org/>. Acesso em
14/09/2016.
[63] S. SCHMID, ESZTER GALICZ, WOLFGANG REINHARDT. Performance
investigation of selected SQL and NoSQL databases." AGILE 2015 Lisbon,
June 9-12, 2015. University of the Bundeswehr.
[64] "Performance and scale testing with Azure DocumentDB". Disponvel em
<https://azure.microsoft.com/en-us/documentation/articles/documentdbperformance-testing/>. Acessado em 14/09/2016.
[65] Manual Dados Abertos do Governo Federal. Acessado em 14/09/2016.
Disponvel
em
<http://www.w3c.br/pub/Materiais/PublicacoesW3C
/Manual_Dados_Abertos_WEB.pdf>.
[66] W. GELLERT, S. GOTTWALD, M. HELLWICH, H. KSTNER, AND H.
KSTNER. "The VNR Concise Encyclopedia of Mathematics", 2nd ed., ch.
12 (Van Nostrand Reinhold: New York, 1989).
[67] N. ZUMEL AND J. MOUNT. Practical Data Science with R.Manning
Publications, 2014.
[68] V. MAYER-SCHONBERGER AND K. CUKIER. Big data: A revolution
that will transform how we live, work, and think. Houghton Mifflin
Harcourt, 2013.
[69] Z. KHAN, A. ANJUM, K. SOOMRO, AND T. MUHAMMAD. Towards
cloud based big data analytics for smart future cities, Journal of Cloud
Computing: Advances, Systems and Applications, 2015.
[70] "Cartilha Acesso a Informao." Acessada em 14/09/2016. Disponvel em
<http://www.acessoainformacao.gov.br/central-de-conteudo/publicacoes/
arquivos/cartilhaacessoainformacao.pdf>.
[71] "Definio de Dados Abertos". Disponvel em <http://opendefinition.org/>.
Acessado em 14/09/016.
[72] CMARA, G. Representao computacional de dados geogrficos.In:
CASANOVA.
137
[73] "IT
INDUSTRY
OUTLOOK
2016".
Disponvel
<https://www.comptia.org/resources/it-industry-outlook-2016-final>.
em
[74] FROZZA, A. A. "Plataforma UrbanMob: Infraestrutura para armazenamento

de trajetrias urbanas de objetos mveis." Projeto de IC submetido ao edital
IFC 037/GDG/IFC-CAM/2012. Cambori, 2012.
[75] AMARAL, BRUNO GUBERFAIN DO, RAFAEL NASSER, MARCO
ANTONIO CASANOVA, AND HLIO LOPES. "BusesinRio: Buses as
Mobile Traffic Sensors: Managing the Bus GPS Data in the City of Rio de
Janeiro." 2016. 17th IEEE International Conference on Mobile Data
Management (MDM). Vol. 1. IEEE, 2016.
[76] RODRIGUEZ, KATHRIN, MARCO A. CASANOVA, LUIZ ANDR PAES
LEME, HLIO LOPES, RAFAEL NASSER, AND BRUNO GUBERFAIN
DO AMARAL. "On the Design of a Traffic Observatory Application Based
on Bus Trajectories." 18th International conference on Enterprise
Information Systems (2016).
[77] Google Maps API Distance Matrix. Acessado em 14/09/2016. Disponvel
em <https://developers.google.com/maps/documentation/distance-matrix/>.
[78] GMap.Net do MIT. Acessvel em <https://greatmaps.codeplex.com/>.
[79] RAFAEL NASSER. McCloud Service Framework: Arcabouo para
desenvolvimento de servios baseados em Simulao de Monte Carlo na
Cloud. Defesa de Mestrado. Pontifcia Universidade Catlica do Rio de
Janeiro. 2012.
[80] OpenStreetMap. Disponvel em <http://www.openstreetmap.org/>. Acessado
em 14/09/2016.
[81] Google Maps. Disponvel em <https://www.google.com.br>. Acessado em
14/09/2016.
[82] QGIS. Disponvel em <www.qgis.org>. Acessado em 14/092016.
[83] SOAEngine. Disponvel
Acessado em 14/092016.
em
<https://github.com/priore/SOAPEngine>.

Rnasser

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rnasser

Uploaded by

Copyright:

Available Formats

Rafael Barbosa Nasser

Uma Plataforma na Nuvem para Extrao de

Orientador: Prof. Hlio Crtes Vieira Lopes

Rafael Barbosa Nasser

Prof. Hlio Crtes Vieira Lopes

Rio de Janeiro, 26 de setembro de 2016

Todos os direitos reservados. proibida a reproduo total ou

Rafael Barbosa Nasser

Aos meus pais, Alberto e Mariana,

Computing; Parallel Computing; Geoprocessing; Urban Mobility.

Figura 49 Velocidade Av. Ns. Sra. de Copacabana

Figura 1 Ciclo de atividades envolvidas em projetos de Data Science

Figura 2 Escala de valorizao dos dados (Gartner 2016)

Disponibilizar informaes aos usurios sobre o servio em operao;

Dar transparncia populao das caractersticas histricas do servio;

Descobrir os padres de trfego nas principais vias da Cidade;

Identificar a situao do trfego das principais vias da Cidade.

Certamente o conjunto de conhecimentos extrado apenas uma pequena

Coleta e armazenamento de dados de posies de GPS (mais de 3

Conceituao, aplicao e anlise da viso de que os dados de GPS dos

Proposio, desenvolvimento e validao de uma plataforma na nuvem

Algoritmo para seleo de segmentos que representem as principais vias

Algoritmo para extrao das trajetrias desses nibus sobre os

Algoritmo para monitoramento do trfego cruzando a situao corrente

Desenvolvimento de software desktop para visualizao destes dados

Desenvolvimento de aplicativo mvel para consumo dos servios desta

multiplicidade de usos da Plataforma.

Usurios: utilizam o servio pblico para suprir suas necessidades de

Operadores: encarregados de administrar, operar (financiamento, aquisio,

Poder pblico: responsvel legal pelo transporte pblico; deve regulamentar,

individual em harmonia com a cidade, sem atrasos e completamente acessvel

Figura 3 Evoluo dos Principais Modais do Transporte Coletivo

Figura 4 Diviso Territorial do RJ pelos Consrcios de nibus

ainda se constitui um dos grandes obstculos para a

abertura dos governos.

fornece detalhes especficos do significado do termo, abaixo sumarizados.

Disponibilidade e acesso: o dado precisa estar disponvel por inteiro e

Reuso e redistribuio: o dado precisa ser fornecido em condies que

Participao universal: todos podem usar, reutilizar e redistribuir, no

Corroborando com esta definio enriquecedor elencar os princpios

Acessveis: so disponibilizados para a maior quantidade possvel de

Completos: todos os dados pblicos devem ser disponibilizados. Dado

Primrios: so apresentados tal como colhidos da fonte, com o maior

Compreensveis por mquina: devem estar estruturados de modo

No discriminatrios: Devem estar disponveis para qualquer pessoa,

No proprietrios: Nenhuma entidade ou organizao deve ter

Livres de licenas: No devem estar submetidos a copyrights, patentes,

Dados abertos governamentais so dados produzidos pelo governo e

Posio dos nibus: Conjunto de dados com a posio - coordenadas

Data e hora da coleta do dado

Identificao alfanumrica encontrada na lateral dos nibus

Latitude do nibus na coleta (GPS, WGS84)

Longitude do nibus na coleta (GPS, WGS84)

Velocidade do nibus na hora da coleta do dado

Tabela 1 Posio dos nibus

Pontos de parada das linhas do nibus: Conjunto de dados com a

A Tabela 2 lista a descrio dos campos

Identificador da Linha de nibus

Descrio da Linha de nibus

Posio da Parada de nibus iniciando em zero

Latitude da Parada de nibus (GPS, WGS84)

Longitude do Parada de nibus (GPS, WGS84)

Tabela 2 Pontos de parada das linhas do nibus