Integração do Global Name Service a uma aplicação móvel de transporte público

(1)

Universidade Federal Fluminense

Instituto de Computa¸

c˜

ao

Departamento de Ciˆ

encia da Computa¸

c˜

ao

Juan Lucas do Ros´

ario Vieira

Integra¸c˜

ao do Global Name Service a uma aplica¸c˜

ao

m´

ovel de transporte p´

ublico

Niter´

oi-RJ

2017

(2)

ii Juan Lucas do Ros´ario Vieira

Integra¸cão do Global Name Service a uma aplica¸cão móvel de transporte público

Trabalho submetido ao Curso de

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

Orientador: Prof. Dr. Antonio Augusto de Arag˜ao Rocha

Niter´oi-RJ 2017

(3)

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

V658 Vieira, Juan Lucas do Rosário

Integração do Global Name Service a uma aplicação móvel de transporte público / Juan Lucas do Rosário Vieira. – Niterói, RJ : [s.n.], 2017.

40 f.

Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.

Orientador: Antonio Augusto de Aragão Rocha.

1. Mobilidade urbana. 2. Transporte público. 3. Aplicativo móvel. 4. Dispositivo móvel. I. Título.

(4)

iii Juan Lucas do Ros´ario Vieira

Integra¸cão do Global Name Service a uma aplica¸cão móvel de transporte público

Trabalho submetido ao Curso de

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

Aprovado por:

Prof. Dr. Antonio Augusto de Arag˜ao Rocha - Orientador UFF

Prof. Dr. C´elio Vinicius Neves de Albuquerque UFF

Prof. Dr. Marcos de Oliveira Lage Ferreira UFF

Niter´oi-RJ 2017

(5)

iv

Agradecimentos

Agrade¸co a Deus pela perseveran¸ca que me proporcionou durante toda minha jor-nada acadˆemica.

Aos meus pais, Fatima e Antônio, e ao meu irmão Jean Felipe, figuras essenciais para que me tornasse quem sou, sempre me apoiando, dando todo o suporte necessário em cada fase de minha vida, contribuindo para minha forma¸cão moral, pessoal e profissional, e acreditando sempre que eu poderia chegar cada vez mais longe.

Ao orientador Antonio Augusto por sua disponibilidade e conselhos que viabiliza-ram o desenvolvimento e conclus˜ao desse projeto.

Aos professores Marcos Lage e Celio Albuquerque que participaram da banca exa-minadora, contribuindo para o enriquecimento deste trabalho.

Aos professores que fizeram parte da minha forma¸c˜ao e que tornam a Universidade Federal Fluminense cada vez melhor.

A todos os colegas da UFF que tamb´em contribu´ıram para o meu crescimento pessoal e profissional.

(6)

v

Resumo

O uso de dispositivos móveis no cotidiano das pessoas está em constante cresci-mento. Cada vez mais, usuários deixam de lado seus computadores e realizam suas tarefas com o aux´ılio de smartphones que representam uma alternativa mais conveniente e prática com aplicativos móveis como Uber, Lyft e Cabify que ganharam grande importância no cenário da mobilidade urbana, apresentando uma forma objetiva de utilizar transportes sem grandes custos.

A medida que o número de usuários desses servi¸cos aumenta, os aplicativos respon-sáveis pelos servi¸cos precisam ser capazes de continuar lidando com o crescente número de requisi¸cões, sem que haja a interrup¸cão do servi¸co. Portanto, é necessário que esses aplicativos sejam escaláveis para que dispositivos móveis, que possuem um poder de pro-cessamento e memória inferior, sejam capazes de executar o aplicativo de forma flu´ıda e sem travamentos.

O objetivo desse projeto é a utiliza¸cão de uma base de dados em nuvem, deno-minada Global Name Service (GNS), a fim de prover escalabilidade a uma aplica¸cão de transporte urbano desenvolvida para dispositivos móveis Android. O contexto de mobi-lidade adotado foi o de transporte público via ônibus, mais especificamente o sistema de transporte público da cidade do Rio de Janeiro, por representar bem o problema abordado e devido à facilidade de acesso aos dados.

No âmbito do transporte público, ônibus, pontos, rotas e horários de parada repre-sentam uma grande quantidade de dados. Para proporcionar a escalabilidade, pretende-se retirar a responsabilidade do processamento desses dados da aplica¸cão móvel transferindo-a ptransferindo-artransferindo-a transferindo-a btransferindo-ase de dtransferindo-ados em nuvem.

(7)

vi

Abstract

The use of mobile devices in people’s daily lives grows every day. Users frequently put personal computers aside and use their smartphones to get tasks done, as they repre-sent a more convenient and practical alternative in the daily basis. In addition, mobile applications such as Uber, Lyft and Cabify have gained great importance in the urban mobility scenario, presenting a convenient way to move around the city, without great costs.

As the number of users of these services increases, the applications responsible for providing these services must deal with the increasing number of requests without interrupting of service. Therefore, these applications need to be scalable, so that mobile devices that have less processing power and memory can run the application smoothly, without crashing.

The main objective of this project is to use a cloud database, called Global Name Service (GNS), to provide scalability to an urban mobility application, developed for An-droid mobile devices. The context adopted was public transportation via buses, more specifically the public transportation system of the city of Rio de Janeiro, since it repre-sents well the problem addressed and due to the ease of access of this data.

In the field of public transport, buses, points, routes and stop times represent a large amount of data. To provide scalability, it is intended to remove the responsibility of processing of these data from the mobile application by transferring it to the cloud database.

(8)

Sum´

ario

Resumo v Abstract vi Lista de Figuras ix Lista de Tabelas x 1 Introdu¸cão 1 1.1 Motiva¸cão . . . 1 1.2 Objetivo . . . 2 1.3 Organiza¸cão . . . 2

2 Coleta e Armazenagem de Dados 4 2.1 Global Name Service . . . 4

2.1.1 Introdu¸cão . . . 4 2.1.2 Contas . . . 5 2.1.3 Consultas . . . 5 2.2 Dados Utilizados . . . 7 2.2.1 Data.Rio . . . 7 2.2.2 Coleta de Dados . . . 8 2.3 Pré-processamento . . . 8 2.4 Estrutura de Dados . . . 9 3 BusFinder 13 3.1 Introdu¸cão . . . 13 3.2 Configura¸cão Inicial . . . 14 vii

(9)

viii

3.3 Tela Principal . . . 15

3.4 Visualiza¸c˜ao das paradas de ˆonibus . . . 16

3.5 Alertas . . . 17

3.6 Linhas de ˆonibus favoritas . . . 18

4 Desenvolvimento 21 4.1 Arquitetura . . . 21

4.2 Tecnologias utilizadas . . . 22

4.2.1 Google Maps Android API . . . 22

4.2.2 Google Play Services Location API . . . 23

4.3 Detalhes de Implementa¸cão . . . 23 4.3.1 Cache . . . 23 4.3.2 Alertas . . . 24 5 Conclusão 27 5.1 Contribui¸cões . . . 27 5.2 Limita¸cões . . . 27 5.3 Trabalhos futuros . . . 28

(10)

ix

Lista de Figuras

2.1 Etapas da requisi¸c˜ao da informa¸c˜ao contida em um documento. . . 6

3.1 Lista de sele¸c˜ao de linhas. . . 14

3.2 Tela principal do BusFinder. . . 15

3.3 Lista de paradas de ˆonibus. . . 16

3.4 Tela de cria¸c˜ao de alertas. . . 17

3.5 Notifica¸cão de proximidade de um ônibus em rela¸cão à uma parada. . . 18

3.6 Tela de gerenciamento de alertas. . . 19

3.7 Tela de gerenciamento de linhas. . . 20

4.1 Vis˜ao geral da arquitetura desenvolvida. . . 22

4.2 Representa¸cão da área de busca de um alerta em rela¸cão a uma parada N. 25 4.3 Cálculo de uma caixa delimitadora a partir da localiza¸cão de uma parada de ônibus. . . 26

4.4 Notifica¸cão que mostra se o servi¸co de alertas está em execu¸cão. . . 26

(11)

x

Lista de Tabelas

2.1 Estrutura de dados GTFS da base 1 . . . 8

2.2 Estrutura de dados da base 2 . . . 8

2.3 Estrutura de dados dos ˆonibus . . . 10

2.4 Estrutura de dados das linhas de ˆonibus . . . 10

2.5 Estrutura de dados das viagens . . . 11

2.6 Estrutura de dados das paradas de ˆonibus . . . 11

2.7 Estrutura de dados dos hor´arios de paradas dos ˆonibus . . . 11

(12)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Motiva¸

c˜

ao

O uso de aparelhos móveis para acesso à Internet vem crescendo diariamente. Se-gundo uma pesquisa realizada pelo IBGE [1], no Brasil em 2014, computadores perderam o posto de dispositivo mais utilizado para acessar à web, para telefones celulares que to-maram a primeira posi¸cão. Isso evidencia que os usuários estão gradativamente deixando seus computadores de lado e utilizando aparelhos móveis para realizarem suas tarefas, sendo esta uma alternativa mais prática.

`

A medida que os aparelhos celulares vão substituindo os computadores no cotidi-ano do brasileiro, smartphones devem ser capazes de realizar tarefas que eram, em sua maioria, realizadas em computadores pessoais. Por isso, aplica¸cões móveis devem ser ca-pazes de lidar com tarefas relativamente complexas poupando recursos computacionais, já que aparelhos celulares têm capacidades de processamento e memória inferiores, quando comparados a computadores.

No âmbito da mobilidade urbana, empresas como Uber e Cabify têm ganhado espa¸co por oferecerem servi¸cos de transporte pessoal, de forma oportuna e prática, a um custo acess´ıvel. Esse tipo de servi¸co concentra uma grande quantidade de dados, onde parte dessas informa¸cões precisam ser acessadas através de aplicativos móveis, sem que haja um comprometimento quanto à qualidade do servi¸co oferecido. Geralmente, esse tipo de servi¸co não depende apenas da aplica¸cão móvel. Usualmente, as informa¸cões necessárias para o funcionamento do servi¸co estão armazenadas em uma base de dados em nuvem. Assim, a aplica¸cão móvel é utilizada somente como uma forma de intera¸cão

(13)

2 e visualiza¸cão dessas informa¸cões, sem que elas estejam necessariamente armazenadas no celular. Aplicativos de transporte público também podem se beneficiar da utiliza¸cão de uma base de dados em nuvem, reduzindo o uso de recursos do celular pela aplica¸cão.

Softwares, que auxiliem a implanta¸cão de uma base de dados em nuvem e infor-ma¸cões de mobilidade urbana dispon´ıveis ao público, tornam poss´ıvel o desenvolvimento de um aplicativo leve, ainda que lide com grandes quantidades de dados.

1.2 Objetivo

O objetivo desse projeto é desenvolver uma aplica¸cão para dispositivos móveis An-droid que utilize o Global Name Service (GNS) como uma base de dados em nuvem, a fim de prover escalabilidade à essa aplica¸cão. O GNS foi escolhido por possuir caracter´ısti-cas favoráveis para o desenvolvimento de aplicativos de mobilidade urbana, que utilizam consultas baseadas em contexto e envolvem uma grande quantidade de dados.

O contexto adotado ao projeto foi o de mobilidade urbana. Dentro desse escopo, foi escolhido o sistema de transporte público, via ônibus da cidade do Rio de Janeiro, de-vido à facilidade de acesso a essas informa¸cões. Neste âmbito, ônibus, paradas, horários, linhas e viagens, representam uma quantidade significativa de dados. Essas informa¸cões, quando armazenadas em um dispositivo móvel, podem causar perdas vis´ıveis de desempe-nho já que precisam ser processadas em um ambiente onde os recursos computacionais são mais escassos. Devido a essa limita¸cão, pretende-se retirar a responsabilidade de armaze-namento e processamento dessas informa¸cões sempre que poss´ıvel, transferindo-a para a base de dados em nuvem, que tem maiores recursos quando comparado a um telefone.

Ainda que o desenvolvimento de um aplicativo para o GNS seja o objetivo prin-cipal deste projeto, pretende-se criar uma aplica¸cão móvel de mobilidade urbana que, de fato, apresente funcionalidades úteis e simule um servi¸co onde o GNS poderia ser real-mente empregado como uma base de dados. Tais funcionalidades envolverão tarefas mais essenciais em um aplicativo desse tipo, como a visualiza¸cão de linhas e pontos de ônibus.

1.3 Organiza¸

c˜

ao

Este trabalho est´a dividido em cinco cap´ıtulos, organizados como descrito a seguir. O Cap´ıtulo 2 aborda a fonte dos dados utilizados no projeto, assim como sua coleta e

(14)

3 pré-processamento. Este cap´ıtulo também aborda brevemente o GNS e seus conceitos de armazenagem e consulta de informa¸cões. O Cap´ıtulo 3 apresenta a aplica¸cão móvel desen-volvida e suas principais funcionalidades. O Cap´ıtulo 4 aborda questões de arquitetura e detalha o desenvolvimento do aplicativo criado. Finalmente, o Cap´ıtulo 5 aborda as limita¸cões e contribui¸cões realizadas no desenvolvimento do projeto, assim como solu¸cões futuras que podem ser adotadas para sua melhoria.

(15)

Cap´ıtulo 2

Coleta e Armazenagem de Dados

2.1 Global Name Service

2.1.1 Introdu¸

c˜

ao

Pensando em uma alternativa para lidar com os problemas de mobilidade oriundos da arquitetura da Internet atual, pesquisadores da University of Massachussets Amherst desenvolveram um servi¸co de resolu¸c˜ao de nomes intitulado Global Name Service (GNS) [2].

O GNS foi criado para solucionar o problema em traduzir identificadores de redes que estão sob situa¸cões de alta mobilidade. Similarmente ao DNS (Domain Name Service), que traduz endere¸cos da web para endere¸cos IPs, o GNS associa um pseudônimo a um GUID (Globally Unique Identifier ). Porém, ao contrário dos endere¸cos IP, nos GUIDs não há um associa¸cão entre o identificador e a localiza¸cão.

Segundo seus criadores, o GNS pode ser utilizado como uma solu¸cão de mobilidade fim-a-fim completa, permitindo comunica¸cão baseada em contexto, ao invés de basear-se em nomes ou endere¸cos, com as vantagens de oferecer baixa latência de resolu¸cão de nomes, baixo custo de atualiza¸cão, alta disponibilidade e escalabilidade.

Devido às suas caracter´ısticas de busca por contexto, que permitem a requisi¸cão de documentos baseados em suas geolocaliza¸cões, e sua escalabilidade, o GNS se aplica muito bem a aplicativos de mobilidade urbana, onde é necessário lidar com grandes quantidades de dados e usuários, e onde consultas baseadas em geolocaliza¸cão são realizadas frequen-temente. Por isso, o Global Name Service foi escolhido para a armazenagem e requisi¸cão

(16)

5 das informa¸c˜oes de transporte utilizadas pelo aplicativo de mobilidade desenvolvido.

Nesse projeto, o GNS será usado como uma base de dados em nuvem a ser im-plantada em um servidor. As informa¸cões relacionadas ao transporte público serão ar-mazenadas e atualizadas nesta base, para serem, posteriormente, requisitadas através de consultas realizadas na parte cliente do GNS, que está integrada ao aplicativo de mobi-lidade urbana desenvolvido. Embora haja suporte nativo à cria¸cão de múltiplas réplicas da base de dados, em um ambiente distribu´ıdo, julgou-se suficiente a utiliza¸cão de uma ´

unica instˆancia do GNS para este projeto.

2.1.2 Contas

Para armazenar informa¸cões no GNS, é necessário a cria¸cão de uma conta para cada registro a ser guardado. No momento da cria¸cão de conta, é preciso informar um pseudônimo e um password. A partir da´ı, são geradas as chaves públicas e privadas res-ponsáveis pela criptografia da comunica¸cão entre servidor e cliente. Nessa etapa, também é gerado um GUID que está associado ao pseudônimo informado. As informa¸cões de uma conta são representadas através de um objeto JSON que, inicialmente, está vazio. É pos-s´ıvel armazenar informa¸cões na conta a partir da utiliza¸cão de comandos na biblioteca cliente do GNS, que permite a cria¸cão de campos e atualiza¸cão de seus valores. Também é poss´ıvel sobrescrever diretamente as informa¸cões de uma conta, utilizando um comando de substitui¸cão do objeto JSON. Durante o desenvolvimento do projeto, este comando foi preposto em rela¸cão aos anteriores por permitir que todos os campos e valores de uma conta fossem criados ou atualizados com uma única requisi¸cão ao servidor.

No que se refere ao que foi desenvolvido nesse projeto, para cada objeto de trans-porte público, como um ônibus espec´ıfico ou uma parada, foi criada uma conta que o representasse. Um script foi responsável pela tarefa de criar uma conta para cada regis-tro da base de dados de transporte utilizada, atualizando as informa¸cões dessa conta de acordo com as informa¸cões do objeto representado.

2.1.3 Consultas

O GNS disponibiliza, em sua biblioteca cliente, comandos [3] para facilitar a in-tera¸cão entre o cliente e o servidor. Como exemplo, temos as fun¸cões de sele¸cão das informa¸cões que estão armazenadas em sua base de dados. Essas fun¸cões envolvem

(17)

retor-6 nar registros que satisfa¸cam uma rela¸cão de campo e valor ou que satisfa¸cam um critério de localiza¸cão (estar próximo a uma coordenada ou sua localiza¸cão estar dentro da área de um pol´ıgono especificado). Há também uma fun¸cão que permite a cria¸cão de uma consulta de acordo com a sintaxe [4] estabelecida no protocolo do GNS, que é baseada nas consultas do MongoDB [5], mas apresenta sutis diferen¸cas. No desenvolvimento do aplicativo, foi usada somente a fun¸cão de cria¸cão de consultas personalizadas para pro-porcionar uma maior flexibilidade quanto ao que pode ser consultado, permitindo, por exemplo, a concatena¸cão de múltiplas consultas.

Embora seja viável criar consultas personalizadas, para que seja poss´ıvel fazer requisi¸cões baseadas em geolocaliza¸cão no GNS, a localiza¸cão de um dado deve ser es-pecificada como um campo de nome geoLocationCurrent, cujo valor é um ponto de co-ordenada em formato de um objeto GeoJSON [6]. O GeoJSON é um formato, definido pela RFC7946, de troca de dados geoespaciais baseado em JSON, usando o sistema de referência de coordenadas geográficas WGS84. Este requerimento foi cumprido por meio do uso de um script de pré-processamento dos dados armazenados no GNS.

Figura 2.1: Etapas da requisi¸c˜ao da informa¸c˜ao contida em um documento.

O GNS não permite que as informa¸cões dos registros que satisfazem os critérios de uma consulta sejam retornadas diretamente como resposta da consulta, limitando-se a disponibilizar somente os identificadores (GUIDs) deslimitando-ses registros. Por isso, para acessar as informa¸cões neles contidas, é necessário seguir algumas etapas. Como descrito

(18)

7 na Figura 2.1, primeiro é preciso realizar uma consulta, receber como resposta os GUIDs que satisfazem os critérios da requisi¸cão, e em seguida requisitar a leitura das informa¸cões do registro, recebendo as informa¸cões do GUID especificado.

2.2 Dados Utilizados

No projeto, foram utilizados os dados do sistema de transporte p´ublico via ˆonibus da cidade do Rio de Janeiro que foram obtidos por meio do site Data.Rio.

2.2.1 Data.Rio

O Data.Rio [7] é um portal criado, em abril de 2014, pela Prefeitura do Rio de Janeiro em parceria com o Instituto Pereira Passos que concentra dados e informa¸cões rela-cionadas à cidade do Rio de Janeiro. O website disponibiliza informa¸cões sobre transporte público, habita¸cão e urbanismo, seguran¸ca pública e infraestrutura da cidade, reunidos em mais de 2 mil arquivos atualizados frequentemente. Em outubro de 2017, o website passou por uma reformula¸cão visual e de conteúdo [8].

Dentre o conjunto de dados disponibilizados pelo portal, foram utilizadas no pro-jeto duas bases de dados referentes ao transporte coletivo via ônibus: uma contendo informa¸cões acerca dos pontos de ônibus, linhas, horários de parada, viagens e trajetos (B1); e a base de dados em rela¸cão à localiza¸cão dos ônibus em tempo real (B2).

A base B11 está organizada de acordo com a especifica¸cão GTFS (General Tran-sit Feed Specification) [9], que define um padrão comum para informa¸cões de transporte público, por meio de arquivos texto, onde cada arquivo representa um conjunto de infor-ma¸cões espec´ıfico, como mostrado na Tabela 2.1.

Já a base B22 é estruturada como um conjunto de dados JSON [10]. Cada campo representa uma informa¸cão acerca de um ônibus, em um determinado instante, como pode ser visto na Tabela 2.2, retirada da documenta¸cão3 dessa base dispon´ıvel no Data.Rio.

1_{http://www.data.rio/dataset/onibus-gtfs. Acesso em: 7 jul 2017}

2_{http://dadosabertos.rio.rj.gov.br/apiTransporte/apresentacao/rest/index.cfm/obterTodasPosicoes} 3_{http://dadosabertos.rio.rj.gov.br/apitransporte/apresentacao/pdf/documentacao gps.pdf}

(19)

8

Arquivo Descri¸c˜ao

routes.txt Conjunto de linhas de ˆonibus

trips.txt Conjunto de viagens para cada linha

stops.txt Conjunto de paradas de ˆonibus

stop times.txt Hor´arios de parada de cada viagem

shapes.txt Conjunto de pontos que representam o trajeto de cada viagem Tabela 2.1: Estrutura de dados GTFS da base 1

Campo Descri¸c˜ao

DataHora Data e hora da coleta do dado

Ordem Identifica¸cão alfanumérica encontrada na lateral dos ônibus

Linha Linha do ˆonibus

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 2.2: Estrutura de dados da base 2

2.2.2 Coleta de Dados

Como os dados da base B1 representam informa¸cões que não são atualizadas com frequência, a obten¸cão desses dados ocorreu pelo download de uma pasta compactada contendo os arquivos da Tabela 2.1, sendo, posteriormente processados por um script e transferidos para o sistema de arquivos do servidor da base de dados. Contudo, o mesmo não poderia ser feito com dados em tempo real, como os da base B2. Por isso, um outro script foi desenvolvido para obter esse tipo de dado através de uma requisi¸cão HTTP ao Data.Rio, cuja resposta é estruturada como um objeto JSON contendo as informa¸cões da Tabela 2.2. Após a obten¸cão da resposta, esses dados são pré-processados e cadastrados ou atualizados no GNS.

2.3 Pr´

e-processamento

A fim de eliminar inconsistências, campos vazios e dados não utilizados, além de organizar as informa¸cões de maneira a cumprir os requisitos das consultas baseadas

(20)

9 em localiza¸cão, estipulados pelo GNS, foram criados dois scripts para realizar o pr´ e-processamento dos dados de transporte utilizados no desenvolvimento do aplicativo. Esses scripts foram responsáveis pelas seguintes fun¸cões:

a) eliminar campos opcionais dos arquivos GTFS que n˜ao foram preenchidos; b) representar latitude e longitude dos dados no formato requerido pelo GNS;

c) eliminar registros que não são referenciados em outras tabelas; d) eliminar registros que continham redundâncias;

e) estruturar as informa¸c˜oes como objetos JSON;

f) adicionar campo que explicita o tipo de dado representado;

g) adicionar campo que representa a data e hora de coleta do dado em formato EPOCH.

O primeiro script foi responsável por pré-processar os dados da base B1, que re-presenta as informa¸cões geográficas associadas ao transporte público. O segundo script foi responsável por pré-processar os dados da base B2, que representa as informa¸cões de geolocaliza¸cão dos ônibus em tempo real. Essa separa¸cão em dois scripts foi necessária, pois, na base B1, os dados não mudam com frequência e, portanto, não precisam ser processados em tempo real. Já a base B2 requer que os dados sejam processados imedia-tamente antes de serem enviados à base de dados em nuvem. O segundo script também é responsável pela requisi¸cão dos dados de GPS dos ônibus ao website do Data.Rio e pela transferência de todos os dados necessários para a base de dados.

2.4 Estrutura de Dados

Após o pré-processamento dos dados, as informa¸cões de mobilidade urbana cole-tadas apresentam uma estrutura ideal para o uso no projeto. Os dados relacionados às localiza¸cões em tempo real dos ônibus possuem a estrutura indicada na Tabela 2.3.

O campo EPOCH foi adicionado para facilitar consultas de data e hora de coleta do dado com operadores lógicos no GNS. Ele representa a data e a hora em que o dado foi coletado no formato Unix Time. Esse formato é definido como o número de segundos que

(21)

10

Campo Descri¸c˜ao

Data Data de coleta do dado

Hora Hora de coleta do dado

Ordem Identifica¸cão alfanumérica encontrada na lateral dos ônibus

Linha Linha do ˆonibus

geoLocationCurrent Localiza¸cão do ônibus em formato GeoJSON Velocidade Velocidade do ônibus na hora da coleta do dado

EPOCH Data e hora da coleta do dado em formato EPOCH

data type Tipo de dado

Tabela 2.3: Estrutura de dados dos ˆonibus

se passaram desde às 0h00 de 1 de janeiro de 1970 do UTC (Universal Time Coordinated ). Dessa maneira, pode-se facilmente comparar se um timestamp é mais recente, verificando se o número de segundos é maior que o outro. O campo geoLocationCurrent foi adicionado para cumprir um requisito do GNS, como explicado na Se¸cão 2.1.3 e o campo data type foi criado para diferenciar os diferentes tipos de dados de transporte existentes na base. As estruturas dos dados que representam as informa¸cões das linhas de ônibus, viagens e paradas de ônibus podem ser observadas nas Tabelas 2.4, 2.5 e 2.6 respectivamente.

Campo Descri¸c˜ao

route id Identificador de rota route short name N´umero da linha

route long name Nome da linha

Tabela 2.4: Estrutura de dados das linhas de ˆonibus

O conjunto de dados que representa os horários das paradas de cada viagem foi modificado, eliminando as informa¸cões de horários que não seriam utilizadas no projeto. Para esse conjunto, foram mantidos somente os campos que relacionavam as viagens e a sequência das paradas de ônibus. Essa nova estrutura pode ser observada na Tabela 2.7. Finalmente, as informa¸cões acerca dos pontos de um trajeto estão estruturadas de acordo com a Tabela 2.8.

(22)

11

Campo Descri¸c˜ao

trip id Identificador de viagem

route id Identificador de rota

trip headsign Descri¸c˜ao da viagem

direction id Identificador de dire¸c˜ao (0 - Ida / 1 - Volta)

shape id Identificador de forma

Tabela 2.5: Estrutura de dados das viagens

Campo Descri¸c˜ao

stop id Identificador de parada de ˆonibus

stop code C´odigo de parada de ˆonibus

stop name Nome da parada de ˆonibus

stop desc Descri¸c˜ao da parada de ˆonibus

geoLocationCurrent Localiza¸c˜ao da parada de ˆonibus em formato GeoJSON

location type Tipo da parada de ˆonibus

Tabela 2.6: Estrutura de dados das paradas de ˆonibus

Campo Descri¸c˜ao

trip id Identificador de viagem

stop id Identificador de parada de ônibus stop sequence Número de sequência da parada de ônibus

(23)

12

Campo Descri¸c˜ao

shape id Identificador da forma de um trajeto shape pt sequence Número de sequência do ponto de um trajeto geoLocationCurrent Localiza¸cão do ponto em formato GeoJSON

(24)

Cap´ıtulo 3

BusFinder

3.1 Introdu¸

c˜

ao

Como discutido anteriormente, o propósito do projeto é a elabora¸cão de uma apli-ca¸cão móvel integrada ao GNS como prova de conceito. A disponibilidade de dados de transporte público via ônibus tornou poss´ıvel a cria¸cão de um aplicativo que permitisse a visualiza¸cão e intera¸cão com essas informa¸cões, denominado BusFinder.

O requisito de funcionalidades do BusFinder foi baseado em um projeto desenvol-vido por estudantes da Universidade Federal Fluminense: o TrackBus [11]. Nesse projeto, foi realizada uma análise de quais funcionalidades seriam as mais desejadas pelos usuários de um aplicativo de transporte público. Usando essa análise, chegou-se a um conjunto de funcionalidades que seriam oferecidas pelo BusFinder. Embora o requisito das fun¸cões do aplicativo desenvolvido tenha sido baseado em outro projeto, a implementa¸cão dessas funcionalidades foi feita de forma totalmente independente, pensando na integra¸cão com o GNS.

O BusFinder possui uma identidade visual que se assemelha a outros aplicativos de transporte público dispon´ıveis na loja de aplicativos da Google, como o ”Vá de Ônibus”, desenvolvido pela Fetranspor. Essa semelhan¸ca foi adotada a fim de proporcionar uma familiaridade dos usuários de aplicativos de mobilidade urbana com o aplicativo criado nesse projeto.

Este cap´ıtulo tem como objetivo apresentar as principais funcionalidades e telas do aplicativo desenvolvido. Detalhes sobre a implementa¸c˜ao e arquitetura do BusFinder podem ser encontradas no Cap´ıtulo 4.

(25)

14

3.2 Configura¸

c˜

ao Inicial

Quando o BusFinder é aberto pela primeira vez, é necessária uma breve configu-ra¸cão inicial para que o aplicativo funcione corretamente.

Como medida de seguran¸ca, aplicativos desenvolvidos para dispositivos Android precisam de permissão para realizar algumas fun¸cões. Por isso, na tela de abertura, é preciso que o usuário autorize o acesso da aplica¸cão a informa¸cões de localiza¸cão e ao sistema de arquivos do dispositivo. Em seguida, o aplicativo tentará se conectar com o servidor GNS e, caso obtenha sucesso, criará uma conta para o dispositivo móvel, usando como pseudônimo um identificador único gerado.

Após a cria¸cão da conta, é exibido uma tela introdutória que apresenta as principais funcionalidades do aplicativo, como cria¸cão de alertas e visualiza¸cão de paradas de ônibus. Depois da tela de introdu¸cão, o aplicativo mostra uma lista de linhas de ônibus, como mostrado na Figura 3.1. Nesta tela, o usuário deverá selecionar suas linhas de interesse, a fim de personalizar a experiência de uso do aplicativo de acordo com suas necessidades, como explicado na Se¸cão 3.6.

(26)

15 Ao término dessas etapas, o aplicativo estará pronto para uso. A configura¸cão da aplica¸cão só precisa ser realizada uma vez, já que as escolhas feitas pelo usuário são armazenadas para a próxima vez que ele for aberto.

3.3 Tela Principal

Após a configura¸cão inicial, o aplicativo exibe a sua tela principal, que dispõe de um mapa, onde é poss´ıvel visualizar as informa¸cões de transporte público, e um menu lateral, que pode ser acessado ao deslizar o dedo da esquerda para a direita.

No mapa, são exibidos as posi¸cões dos ônibus em tempo real, sendo atualizadas a cada 30 segundos. Para cada ônibus, é atribu´ıdo um marcador cuja cor representa a linha a qual ele pertence. Quando um ônibus é selecionado, é exibido na parte inferior da tela um painel que contém o código encontrado na lateral do ônibus, o número e nome da sua linha e as op¸cões dispon´ıveis para o marcador selecionado, como pode ser visto na Figura 3.2.

(27)

16

3.4 Visualiza¸

c˜

ao das paradas de ˆ

onibus

Uma das informa¸cões mais importantes no âmbito do transporte público é saber em quais pontos da cidade um usuário pode embarcar ou desembarcar. Além de exibir informa¸cões dos ônibus em tempo real, o BusFinder também permite a visualiza¸cão das paradas de ônibus de uma linha, no mapa.

Ao selecionar um ônibus, é poss´ıvel visualizar as paradas por onde esse ônibus trafega ao clicar na op¸cão ”Show Stops”. Após o carregamento das paradas, elas serão exibidas em uma lista, ordenadas de acordo com o in´ıcio e o fim do trajeto da linha a qual o ônibus selecionado pertence, assim como suas respectivas localiza¸cões, representadas através de ´ıcones no mapa, como pode ser visto na Figura 3.3.

Figura 3.3: Lista de paradas de ˆonibus.

O modo de intera¸cão com as paradas foi pensado de forma a facilitar sua descoberta, tanto pelo nome quanto pela sua localiza¸cão, visto que ao selecionar uma parada da lista, fará com que o mapa seja direcionado ao ´ıcone que a representa e vice-versa.

(28)

17

3.5 Alertas

Uma das funcionalidades presentes em aplicativos de mobilidade urbana, como o Uber, é informar ao usuário quando seu transporte está chegando. Seria igualmente ´

util, em um aplicativo de transporte público, que houvesse uma notifica¸cão de quando um ônibus estivesse próximo a uma determinada parada. Dessa maneira, ele poderia se planejar para ir em dire¸cão ao ponto assim que o transporte se aproximasse, reduzindo o risco de ter que aguardar indefinidamente a chegada do ônibus.

O BusFinder oferece essa funcionalidade de criar alertas que notifiquem ao usuário quando um ônibus está próximo. Para criar um alerta, basta selecionar um coletivo no mapa e clicar no botão ”Create Alert”. Em seguida, o usuário tem a op¸cão de escolher ser alertado quando o ônibus selecionado se aproximar, ou outro da mesma linha, como mostrado na Figura 3.4. O segundo caso foi pensado para cobrir a situa¸cão em que o usuário deseje pegar o primeiro ônibus da linha que se aproximar, já a primeira op¸cão permite uma escolha mais espec´ıfica.

(29)

18 A segunda escolha a ser feita é se a notifica¸cão deve ser gerada quando o ônibus se aproximar da localiza¸cão atual do usuário ou de uma parada de ônibus espec´ıfica. Caso a segunda op¸cão seja selecionada, uma lista de paradas de ônibus aparecerá, similarmente `

a apresentada na Se¸cão 3.4, onde o usuário deverá selecionar a parada pretendida. O aplicativo irá gerar a notifica¸cão quando o ônibus selecionado estiver até 3 paradas de distância, em rela¸cão à parada selecionada. Um exemplo de notifica¸cão pode ser visto na Figura 3.5.

Figura 3.5: Notifica¸cão de proximidade de um ônibus em rela¸cão à uma parada.

Após a cria¸cão dos alertas, é poss´ıvel verificá-los acessando a op¸cão Alerts do menu, como mostra a Figura 3.6. Nessa tela, também é poss´ıvel ativar, desativar ou excluir alertas. Quando um ônibus se aproxima e uma notifica¸cão é gerada, o alerta referente é desativado. Caso um usuário necessite reutilizar um alerta, é poss´ıvel simplesmente reativá-lo em vez de passar pelos procedimentos da cria¸cão novamente. Se o alerta se tornar irrelevante, é poss´ıvel deletá-lo.

Embora notifique o usuário corretamente na maioria das vezes, a funcionalidade de alertas apresenta algumas limita¸cões, abordadas na Se¸cão 5.2.

3.6 Linhas de ˆ

onibus favoritas

O BusFinder possibilita escolher de quais linhas de ônibus um usuário deseja re-ceber informa¸cões. Essa funcionalidade foi desenvolvida com base na premissa de que seria irrelevante exibir dados sobre ônibus e paradas de linhas que o usuário não possui interesse.

Quando o usuário escolhe suas linhas favoritas, o aplicativo deixa de requisitar ao servidor informa¸cões sobre outras linhas. Por isso, somente os ônibus das linhas selecio-nadas serão mostradas no mapa, reduzindo um poss´ıvel excesso de dados a serem exibidos que poderia causar confusão.

(30)

19

Figura 3.6: Tela de gerenciamento de alertas.

na Figura 3.7. É poss´ıvel a personaliza¸cão da cor de uma linha ou fazer com que o mapa exiba somente ônibus da linha selecionada, omitindo coletivos de outras linhas. Ambas op¸cões foram implementadas com a finalidade de facilitar a visualiza¸cão dos transportes no mapa.

Apesar de restringir a exibi¸cão de informa¸cões de linhas que não foram escolhidas pelo usuário, o aplicativo permite que linhas favoritas sejam adicionadas ou removidas a qualquer momento. Nessa tela de modifica¸cão, cuja aparência é similar a tela mostrada na Figura 3.1, todas as linhas armazenadas na base de dados são exibidas.

(31)

20

(32)

Cap´ıtulo 4

Desenvolvimento

4.1 Arquitetura

A arquitetura do projeto desenvolvido ´e constitu´ıda pelo aplicativo de mobilidade urbana para dispositivos m´oveis e uma base de dados em nuvem.

O aplicativo BusFinder foi desenvolvido de forma nativa para dispositivos móveis com o sistema operacional Android e é compat´ıvel com a versão 4.1 Lollipop ou superior. O desenvolvimento h´ıbrido foi descartado para evitar eventuais problemas de compatibi-lidade entre as bibliotecas do GNS e os frameworks de desenvolvimento multiplataforma, e pelo fato de o desenvolvimento nativo ser suficiente para a prova de conceito abordada. Devido à incompatibilidade entre o desenvolvimento Android e a versão 8 da lin-guagem Java, que é a linguagem a qual o GNS é desenvolvido, a versão do cliente GNS escolhida para ser integrada ao aplicativo foi a 1.19.11. Essa versão é a mais recente dispon´ıvel portada para versão 7 do Java.

Durante a cria¸cão do aplicativo, além do GNS, foram utilizadas bibliotecas para possibilitar a visualiza¸cão em mapa, cálculos de distância entre pontos e facilitar o acesso a geolocaliza¸cão do dispositivo móvel.

A base de dados em nuvem consiste em uma instância do servi¸co AWS EC21 executando o sistema operacional Ubuntu Server, a aplica¸cão servidor do GNS e os scripts de coleta, pré-processamento e armazenagem de dados. Uma visão geral da arquitetura pode ser visualizada na Figura 4.1.

1_{Amazon Web Service Elastic Compute Cloud}

(33)

22

Figura 4.1: Vis˜ao geral da arquitetura desenvolvida.

4.2 Tecnologias utilizadas

Al´em da biblioteca cliente do GNS, foram utilizadas outras tecnologias para desem-penhar algumas das tarefas necess´arias para o desenvolvimento do aplicativo BusFinder.

4.2.1 Google Maps Android API

O Google Maps Android API foi a interface utilizada no desenvolvimento do Bus-Finder para a visualiza¸cão e intera¸cão do mapa e de seus respectivos marcadores, além de apresentar um suporte nativo para a exibi¸cão da localiza¸cão do dispositivo em tempo real. Essa biblioteca foi escolhida por apresentar uma melhor integra¸cão com o Android e pela similaridade que traria entre o aplicativo do Google Mapas e o aplicativo desenvolvido, proporcionando uma experiência de uso mais amigável à usuários que já utilizaram o Go-ogle Mapas em seus celulares. Essa API de mapas do GoGo-ogle é de uso gratuito e ilimitado para aplicativos Android disponibilizados gratuitamente. É necessário apenas a obten¸cão e configura¸cão de uma chave para o uso através do aplicativo. A biblioteca de utilitários dessa API também foi utilizada no projeto para o cálculo de caixas delimitadoras.

(34)

23

4.2.2 Google Play Services Location API

Embora seja poss´ıvel utilizar a API do framework de localiza¸cão do Android para requisitar as leituras do GPS de um dispositivo, foi preferido o uso da Google Play Services Location API pela maior facilidade de manter a geolocaliza¸cão do usuário atualizada no aplicativo. Essa interface necessita que a biblioteca do Google Play Services esteja presente no dispositivo, o que normalmente acontece, pois ela geralmente vem instalada por padrão nos smartphones Android que possuem a loja de aplicativos do Google.

4.3 Detalhes de Implementa¸

c˜

ao

4.3.1 Cache

O aplicativo desenvolvido faz uso de diversas consultas e leituras de GUIDs junto ao servidor GNS em nuvem. Essas consultas à base de dados podem levar vários se-gundos. Com a finalidade de agilizar ou eliminar o tempo de espera de uma resposta para a requisi¸cão das informa¸cões necessárias, foram implementados dois tipos de cache no projeto, eles evitam que novas consultas sejam realizadas ao servidor para dados que já foram consultados previamente. O primeiro leva em considera¸cão os identificadores ´

unicos dos dados de transporte. Já o segundo está relacionado aos GUIDs associados a essas informa¸cões, que são gerados pelo GNS no momento de cria¸cão das contas.

4.3.1.1 Cache de identificadores

O cache de identificadores guarda, em um arquivo tempor´ario, as informa¸c˜oes de um dado previamente consultadas associando-as com seus respectivos identificadores.

Quando um dado de transporte é necessário, como informa¸cões sobre uma parada de ônibus espec´ıfica, antes que esse dado seja requisitado, é verificado se ele existe nos arquivos temporários, fazendo uma correspondência entre os identificadores. Caso o dado seja encontrado, nenhuma consulta é realizada ao servidor e as informa¸cões são recupera-das diretamente do arquivo.

O objetivo desse cache é evitar que múltiplas requisi¸cões sejam feitas ao servidor, pois, para cada dado, seria necessário recuperar seu GUID e, em seguida, requisitar a leitura das informa¸cões contidas no objeto JSON daquele dado, como explicado na Se¸cão

(35)

24 2.1.3.

4.3.1.2 Cache de GUIDs

O cache de identificadores criados pelo GNS (GUIDs) foi desenvolvido para agilizar consultas cujos dados de transporte não possuem um identificador, como as informa¸cões de horários de parada, e consultas que não envolvem a requisi¸cão de um dado a partir de seu identificador, mas sim a partir de uma informa¸cão secundária. No cache de GUIDs, as informa¸cões de um registro são associadas ao GUID do próprio registro. Ao fazer uma requisi¸cão ao servidor, os respectivos GUIDs dos registros que satisfazem aos critérios da consulta são retornados. Em seguida, é verificado se os dados desses GUIDs estão armazenados em cache. Caso estejam, as informa¸cões desses registros são recuperadas diretamente do arquivo. Isso evita que seja necessário a requisi¸cão de leitura dos objetos JSON contidos nos dados.

Dados de geolocaliza¸cão dos ônibus não são armazenados em cache, já que são informa¸cões que são frequentemente atualizadas no servidor. Por isso, as informa¸cões re-lacionadas aos ônibus sempre serão consultadas diretamente ao servidor. Para os demais dados que representam informa¸cões que não são atualizadas com tanta frequência, o cache apropriado é ativado, dependendo do tipo de consulta. Arquivos de cache são eliminados um mês após sua data de cria¸cão, para evitar que dados já não existentes, ou que foram modificados no servidor, continuem sendo utilizados pelo aplicativo. Esses arquivos tam-bém podem ser apagados por gerenciadores de memória do Android quando o sistema detectar que a memória dispon´ıvel do dispositivo está acabando. Porém, a elimina¸cão desses arquivos não causará nenhum problema ao aplicativo, pois este fará uma consulta ao servidor para qualquer dado que não esteja presente em cache.

4.3.2 Alertas

Como especificado no Cap´ıtulo 3, o BusFinder dispõe de uma funcionalidade que notifica ao usuário quando um ônibus está perto dele ou se aproxima de uma parada. Essas duas situa¸cões de uso da funcionalidade apresentam referenciais distintos, portanto, mostrou-se necessário o uso de duas abordagens diferentes.

(36)

25 4.3.2.1 Alerta de proximidade em rela¸c˜ao ao usu´ario

Na primeira abordagem, é verificado se um determinado ônibus, ou uma linha espec´ıfica, está próximo à localiza¸cão do dispositivo. Essa verifica¸cão se dá por meio de uma consulta de geolocaliza¸cão do GNS, que retorna o ônibus, ou linha, especificado, cuja localiza¸cão está próximo ao usuário.

4.3.2.2 Alerta de proximidade em rela¸cão à uma parada de ônibus

Na segunda abordagem, quando um alerta em rela¸cão a uma parada de ônibus é criado, além das informa¸cões da parada especificada, são salvas as localiza¸cões de três paradas anteriores a ela, caso existam. Essa abordagem foi criada para reduzir o problema de o usuário não ser notificado caso o ônibus passe pela parada, durante as atualiza¸cões do mapa. Ao aumentar a área de busca, reduz-se a possibilidade desse problema acontecer, portanto, é verificado se o ônibus em questão está próximo à parada espec´ıfica ou às três anteriores. O usuário será notificado assim que o ônibus for detectado e a quantos pontos ele está em rela¸cão a parada selecionada, durante a cria¸cão do alerta.

A deteçcão do ônibus se dá por meio de uma requisi¸cão ao GNS que busca por coletivos com código ou linha especificados, cuja localiza¸cão está dentro da área de uma das caixas delimitadoras que são geradas a partir das latitudes e longitudes das paradas salvas na cria¸cão do alarme, como mostrado na Figura 4.2. Caso um ônibus seja detectado, são calculadas as distâncias em linha reta entre o ônibus e as paradas envolvidas para determinar qual a parada mais próxima do ônibus.

Figura 4.2: Representa¸cão da área de busca de um alerta em rela¸cão a uma parada N.

Usando uma fun¸cão da biblioteca de utilitários da Google Maps Android API que calcula uma latitude e longitude a partir de um centro, uma distância e um ângulo em rela¸cão ao norte, a caixa delimitadora foi gerada a partir do cálculo dos quatro cantos da

(37)

26 caixa em rela¸cão ao centro, que é a geolocaliza¸cão de uma parada.

Como pode ser visto na Figura 4.3, a caixa delimitadora é calculada usando-se como parâmetro uma parada de ônibus P e uma distância r entre a parada e os lados da caixa. Aplicando conceitos de trigonometria, calcula-se a distância d entre a parada P e o vértice V1 da caixa. Com essas informa¸cões, é poss´ıvel calcular a latitude e longitude do vértice V1 a partir do ângulo formado entre a reta, que compreende a parada P e o vértice V1, e o Norte, utilizando a fun¸cão computeOffset. As mesmas etapas são feitas com os vértices V2, V3 e V4, a fim de obter o pol´ıgono que define a caixa delimitadora.

Figura 4.3: C´alculo de uma caixa delimitadora a partir da localiza¸c˜ao de uma parada de ˆ

onibus.

Para que não seja necessário que o aplicativo continue aberto a fim de checar os alertas ativos, a verifica¸cão de proximidade dos ônibus foi implementada como um servi¸co em segundo plano, sendo uma parte da aplica¸cão que continua em execu¸cão mesmo com o encerramento do aplicativo. A execu¸cão do servi¸co é evidenciada através de uma notifica¸cão persistente, como pode ser visto na Figura 4.4.

Figura 4.4: Notifica¸cão que mostra se o servi¸co de alertas está em execu¸cão.

Com a finalidade de poupar recursos do dispositivo móvel, o servi¸co é interrompido sempre que detecte que não existem alarmes ativos. Caso um novo alarme seja criado ou ativado, o servi¸co volta a executar as verifica¸cões dos alertas.

(38)

Cap´ıtulo 5

Conclus˜

ao

5.1 Contribui¸

c˜

oes

A principal contribui¸cão do projeto é o uso do Global Name Service como uma base de dados, para prover escalabilidade ao BusFinder, que auxiliará a descoberta de poss´ıveis melhorias e funcionalidades a serem implementadas nas versões futuras do GNS, que está em desenvolvimento.

Além disso, a utiliza¸cão dos dados do portal Data.Rio para a cria¸cão de aplicativos voltados à popula¸cão, contribui para o desenvolvimento da plataforma. À medida em que é percebido que essas informa¸cões vêm sendo utilizadas em pesquisas pela comunidade acadêmica, estimula-se a cria¸cão e manuten¸cão de iniciativas de transparência e acesso à informa¸cão da cidade do Rio de Janeiro.

5.2 Limita¸

c˜

oes

A utiliza¸cão uma base de dados para a armazenagem das informa¸cões utilizadas pelo aplicativo, reduz a dependência da disponibilidade dos dados de transporte, consi-derando dados estáticos de trânsito fornecidos pelo Data.Rio, porém o BusFinder ainda dependerá da disponibilidade das informa¸cões de ônibus em tempo real providos pelo Data.Rio. Devido à essa dependência, caso o portal restrinja o acesso a essas informa¸cões, o aplicativo desenvolvido deixará de desempenhar suas fun¸cões corretamente.

Além da dependência da disponibilidade, dados do Data.Rio estão sujeitos a in-consistências. Durante o desenvolvimento do projeto, notou-se um número significativo

(39)

28 de ônibus que não possu´ıam informa¸cões sobre sua linha. A fim de evitar problemas decorrentes da falta desses dados, ônibus que não continham suas informa¸cões de linha foram ignorados durante a etapa de pré-processamento dos dados. Como consequência, alguns ônibus existentes não serão mostrados pelo aplicativo. Porém, é poss´ıvel minimizar este problema aplicando um algoritmo que deduza a linha de um ônibus baseado no seu histórico de localiza¸cão que poderia ser aplicado durante o pré-processamento.

No que concerne às funcionalidades implementadas no BusFinder, o servi¸co de alertas possui uma limita¸cão que pode acarretar em falsos positivos. Considerando a situa¸cão mostrada na Figura 5.1, em que um alerta tenha sido configurado para notificar ao usuário quando um ônibus chegar à parada N, caso dois trajetos, de dia e volta, estejam muito próximos um do outro e caso um ônibus estiver passando pelo trajeto contrário, mas sua localiza¸cão está dentro da área de busca da parada N, o aplicativo irá notificar a proximidade erroneamente, já que o ônibus, apesar de próximo à parada em questão, está em dire¸cão oposta ao trajeto ao qual a parada pertence.

Figura 5.1: Situa¸c˜ao de falso positivo do servi¸co de alertas.

Este problema poderia ser resolvido caso a informa¸cão da dire¸cão do ônibus es-tivesse dispon´ıvel ou fosse descoberta através de um algoritmo que deduza a dire¸cão a partir do histórico de localiza¸cão do ônibus. Sabendo a dire¸cão do ônibus, seria poss´ıvel ignorar aqueles cuja dire¸cão fosse diferente do trajeto da parada, durante a verifica¸cão do alerta.

5.3 Trabalhos futuros

Considerando as capacidades do GNS no que concerne consultas de geolocaliza¸c˜ao e baseadas em contexto, e as informa¸c˜oes dispon´ıveis no Data.Rio, o BusFinder poderia

(40)

29 ser facilmente expandido para englobar outros tipos de transporte terrestre da cidade do Rio de Janeiro, como BRTs e VLTs.

Ainda que seja poss´ıvel saber a próxima parada de um ônibus através da visuali-za¸cão em mapa do aplicativo desenvolvido, seria interessante a inclusão de uma funcio-nalidade que exibisse essa informa¸cão de maneira automática. Apesar de alguns ônibus possu´ırem letreiros ou avisos sonoros que fornecem essa informa¸cão ao usuário, a maioria deles não possui tal recurso, devido a isso, muitos usuários de transporte público acabam por recorrer à ajuda do motorista, expondo os viajantes a risco de acidentes causados por distra¸cões ao volante. Considerando que as paradas de ônibus de uma linha e as localiza¸cões dos coletivos já são informa¸cões conhecidas, o único empecilho para o desen-volvimento dessa funcionalidade seria detectar em qual dire¸cão o ônibus está viajando.

(41)

Referˆ

encias Bibliogr´

aficas

[1] IBGE, Acesso à internet e à televisão e posse de telefone móvel celular para uso pessoal : 2015. Coordena¸cão de Trabalho e Rendimento, 2016.

[2] A. Sharma, X. Tie, H. Uppal, A. Venkataramani, D. Westbrook, and A. Yadav, “A global name service for a highly mobile internetwork,” SIGCOMM Comput. Commun. Rev., vol. 44, pp. 247–258, agosto 2014.

[3] D. Westbrook, “GNS Client Commands.” https://gns.name/wiki/index.php? title=GNS_Client_Commands, 2016. ´Ultimo acesso em 15/11/2017.

[4] D. Westbrook, “Query syntax.” https://gns.name/wiki/index.php?title=Query_ Syntax. ´Ultimo acesso em 15/11/2017.

[5] Mongo DB, “Query and projection operators.” https://docs.mongodb.com/manual/ reference/operator/query. ´Ultimo acesso em 15/11/2017.

[6] H. Butler, S. Gillies, and T. Schaub, “The GeoJSON Format.” https://tools.ietf. org/html/rfc7946, 2016. ´Ultimo acesso em 15/11/2017.

[7] R. Albuquerque, “Prefeitura lan¸ca portal de servi¸cos personalizado e abre base de dados do munic´ıpio para o cidad˜ao.” http://www.rio.rj.gov.br/web/guest/ exibeconteudo?id=4669376. ´Ultimo acesso em 15/11/2017.

[8] Prefeitura do Rio, “Rio de Janeiro ganha novo portal de informa¸c˜oes.” http: //www.rio.rj.gov.br/web/ipp/exibeconteudo?id=7437398. Ultimo acesso em´ 15/11/2017.

[9] Google, “O que ´e GTFS.” https://developers.google.com/transit/gtfs/?hl= pt-br. ´Ultimo acesso em 15/11/2017.

(42)

31 [10] JSON, “Introducing JSON.” https://www.json.org. Último acesso em 15/11/2017. [11] M. C. da Rocha Vaz and R. P. Amaral, “Trackbus: um aplicativo de apoio aos usuários de ônibus na cidade do Rio de Janeiro,” Trabalho de Conclusão de Curso, Universidade Federal Fluminense, Niterói, 2017.