AUTOMAÇÃO DO TRÁFEGO DE VEÍCULOS: SISTEMA DE BUSCA DE CAMINHO DE MENOR CUSTO ENTRE DOIS PONTOS

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO AUTOMAÇÃO DO TRÁFEGO DE VEÍCULOS: SISTEMA DE BUSCA DE CAMINHO DE MENOR CUSTO ENTRE DOIS PONTOS RICHARD BEYER SCHROEDER BLUMENAU /1-26

2 RICHARD BEYER SCHROEDER AUTOMAÇÃO DO TRÁFEGO DE VEÍCULOS: SISTEMA DE BUSCA DE CAMINHO DE MENOR CUSTO ENTRE DOIS PONTOS Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação Bacharelado. Prof. Aurélio Faustino Hoppe, Mestre - Orientador BLUMENAU /1-26

3 AUTOMAÇÃO DO TRÁFEGO DE VEÍCULOS: SISTEMA DE BUSCA DE CAMINHO DE MENOR CUSTO ENTRE DOIS PONTOS Por RICHARD BEYER SCHROEDER Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Aurélio Faustino Hoppe, Mestre Orientador, FURB Prof. Antonio Carlos Tavares, Mestre FURB Profa. Joyce Martins, Mestre FURB Blumenau, 11 de julho de 2012.

4 Dedico este trabalho a minha mãe, Ruth Beyer Schroeder e ao meu pai, Wilfrido Schroeder.

5 AGRADECIMENTOS Ao professor, Aurélio Faustino Hoppe, pela orientação, incentivo, dedicação e acima de tudo por ter acreditado no potencial de desenvolvimento deste trabalho. À namorada Luana, pela paciência, compreensão, motivação e apoio. A meus pais, por terem me guiado e mostrado o caminho dos estudos, que mesmo longe sempre me apoiaram nas decisões certas, e sempre me ajudaram a suportar o peso das consequências nas decisões erradas. Aos meus amigos, pela motivação, empurrões e cobranças. A Deus, pela proteção, seu imenso amor e graça.

6 A arte de programar consiste em organizar e dominar a complexidade. Edsger W. Dijkstra

7 RESUMO Este trabalho apresenta o protótipo de um sistema de busca de rotas de menor custo em uma malha viária baseando-se nas condições reais de tráfego para determinar a rota que levará menos tempo para ser percorrida. Para a obtenção das condições reais de tráfego a coleta de dados geográficos foi desenvolvida baseando-se em dispositivos celulares com sistema operacional Android. A modelagem dos dados geográficos coletados foi feita utilizando grafos o que permite a aplicação de teorias computacionais conhecidas para essas estruturas. Para o cálculo da rota de menor custo foi utilizado o algoritmo de Dijkstra que de acordo com pesquisas demonstrou ser o mais eficiente. Os resultados obtidos demonstram a eficiência da utilização do sistema quanto à capacidade de determinar as condições de tráfego reais das vias e, consequentemente, obter a rota que levará o usuário mais rapidamente ao seu destino. Palavras-chave: Caminho mínimo em grafos. Dados georreferenciados. Geoprocessamento. Malha viária urbana.

8 ABSTRACT This paper presents a prototype system for finding lower-cost routes in a road network based on the actual conditions of traffic to determine the route that will take less time being covered. To obtain the actual conditions of traffic the collection of geographic data has been developed based on mobile devices with Android operating system. The modeling of spatial data collected were analyzed using graphs which allow the application of computational theories known to those structures. To calculate the least cost route the system used the Dijkstra algorithm, which in accordance to research has proved being the most efficient. The results demonstrate the efficiency of system usage and the ability to determine actual traffic conditions of roads and consequently obtaining the route that will take the user to his destination faster. Key-words: Shortest path in graphs. Georeferenced data. Geoprocessing. Urban road network.

9 LISTA DE ILUSTRAÇÕES Quadro 1 Algoritmo de inicialização dos atributos de estimativa de caminho mais curto Quadro 2 Algoritmo de relaxamento de atributos de estimativas de caminho mais curto Quadro 3 Algoritmo de Dijkstra Figura 1 Google Maps e Google Maps Navigation Figura 2 Google Maps exibindo em cores as ruas congestionadas Figura 3 Representação da arquitetura de um sistema GATI Figura 4 GPS Airis exibindo as condições do tráfego Figura 5 Exibição do relatório de tráfego Quadro 4 Características dos trabalhos relacionados Figura 6 Diagrama de casos de uso Figura 7 Diagrama de classes do protótipo executado no dispositivo móvel Figura 8 Diagrama de classes do servidor Figura 9 Diagrama de classes do servidor Figura 10 Diagrama de classes do servidor Figura 11 Diagrama de sequência coleta de dados Figura 12 Diagrama de sequência enviar dados Figura 13 Diagrama de sequência do cálculo das estatísticas no servidor Figura 14 Diagrama de sequência complementar do cálculo de estatísticas no servidor Figura 15 Diagrama de sequência obter rota de menor custo Figura 16 Diagrama de sequência do web service Figura 17 Diagrama de classes do padrão malha viária urbana Quadro 5 Registro do gerenciador de localização Quadro 6 Recebendo atualizações de localização Quadro 7 Algoritmo de montagem da malha viária e geração de estatísticas Quadro 8 Código do método ProcessarPrimeiraEUltimaCoordenadaRua Figura 18 Demonstração da eliminação da primeira e última rua Quadro 9 Código do método ProcessarCoordenadasRuaSemCruzamentosInicialOuFinal Figura 19 Percorrendo a rua Almirante Barroso que foi já processada Figura 20 Percorrendo a rua Rio de Janeiro que já foi processada Quadro 10 Código do método BuscarCruzamentoInicial... 62

10 Quadro 11 Código do método ProcessarCoordenadasRuaAPartirDeCruzamentoInicial Figura 21 Trajeto do primeiro usuário Figura 22 Trajeto do segundo usuário Figura 23 Resultado do processamento das coordenadas geográficas do segundo usuário.. 67 Figura 24 Trajeto do primeiro usuário Figura 25 Trajeto percorrido pelo segundo usuário Figura 26 Resultado do processamento das coordenada geográficas do segundo usuário Quadro 12 Código do método BuscarCruzamentoFinal Quadro 13 Código do método ProcessarCoordenadasRuaAPartirDeCruzamentoFinal 73 Figura 27 Representação do grafo gerado através da coleta de coordenadas geográficas Quadro 14 Implementação do algoritmo de Dijkstra Figura 28 Tela inicial do protótipo Figura 29 Tela de coleta de coordenadas geográficas Figura 30 Acesso a opção de configurações Figura 31 Configuração da URL do web service Figura 32 Tela de busca da rota de menor custo Figura 33 Botões para informar ponto de origem ou destino Figura 34 Ponto de origem e destino Figura 35 Resultado do cálculo da rota de menor custo Figura 36 Trecho percorrido via Av. Presidente Castelo Branco representando a primeira rota Figura 37 Trecho percorrido via rua das Missões representando a segunda rota Figura 38 Demonstração da geração de um novo cruzamento Figura 39 Definindo o ponto de origem e destino e obtendo a rota de menor custo Figura 40 Demonstração de tráfego de veículos intenso representado pela cor vermelha Figura 41 Resultado do cálculo da rota de menor custo indicado a segunda rota como sendo a mais viável Figura 42 Trecho percorrido em teste efetuado em ambiente real Figura 43 Diferença na coleta de dados Figura 44 Demonstração da coordenada geográfica no (a) Google Maps, (b) Bing Mapas e (c) Yahoo Mapas Figura 45 Pontos coletados na primeira rota Figura 46 Pontos coletados na segunda rota... 95

11 Quadro 15 Relação das características dos trabalhos correlatos e do protótipo desenvolvido Figura 47 Demonstração do trajeto percorrido por dois usuários LISTA DE TABELAS Tabela 1 Resultado do processamento das coordenadas geográficas coletadas do primeiro trecho Tabela 2 Resultado do processamento das coordenadas geográficas coletadas do segundo trecho Tabela 3 Resultado do processamento das coordenadas geográficas simulando tráfego intenso Tabela 4 Demonstração do resultado do processamento das coordenadas geográficas dos testes realizado em ambiente real... 96

12 LISTA DE SIGLAS ADT Android Development Tools API Application Programming Interface BHTrans - Empresa de Transportes e Trânsito de Belo Horizonte CET Companhia de Engenharia de Tráfego CTA Controle de Tráfego por Área DENATRAN DEpartamento NAcional de TRÂNsito FM Frequência Modulada FTP File Transfer Protocol GATI Google-map-based Arterial Traffic Informatian GPS Global Positiong System HTTP HyperText Transfer Protocol IDE Integrated Development Environment Km/h Kilômetros por hora LVV Linhas de Viagens Virtuais M/s Metros por segundo RDS Radio Data System RF Requisito Funcional RNF Requisito Não Funcional SDK - Software Development Kit SIG Sistemas de Informações Geográficas UC Use Case UML Unified Modeling Language URL Uniform Resource Locator

13 XML extensible Markup Language

14 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA CARACTERIZAÇÃO DE CONGESTIONAMENTOS GEOCODIFICAÇÃO REVERSA PADRÃO DE REPRESENTAÇÃO: MALHA VIÁRIA URBANA ALGORITMO DE BUSCA DE CUSTO MÍNIMO TRABALHOS CORRELATOS DESENVOLVIMENTO REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Diagrama de casos de uso Diagrama de classes Diagrama de classes do aplicativo cliente Diagrama de classes do aplicativo servidor Diagrama de sequência Coleta de dados Envio dos dados Cálculo das estatísticas Obter rota de menor custo Modelagem de dados geográficos geocodificados IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Coleta, envio e recebimento das coordenadas geográficas Geração da malha viária e das estatísticas de tráfego com base nas coordenadas coletadas Processamento inicial considerando uma nova base sem dados Processamento considerando dados já coletados anteriormente Representação das ruas percorridas através de um grafo Obtendo a rota de menor custo... 74

15 3.3.2 Operacionalidade da implementação Coleta de dados Busca da rota de menor custo RESULTADOS E DISCUSSÃO Testes realizados com dados hipotéticos Testes realizados em ambiente real Relação do trabalho atual com os trabalhos correlatos CONCLUSÕES LIMITAÇÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS

16 15 1 INTRODUÇÃO Mobilidade, eis uma palavra que nos tempos atuais é cada vez menos relacionada à facilidade de locomoção de uma origem ao seu destino através de algum veículo automotor. E isso não se dá apenas a facilidade que os meios de comunicação alternativos proporcionam, mas é uma consequência da dificuldade encontrada para tornar tal ação possível levando em consideração o grande volume de veículos em circulação. O DEpartamento NAcional de TRÂNsito (DENATRAN) aponta para um crescimento de 119% da frota brasileira nos últimos dez anos, de acordo com Moreira (2011). Visto que existe uma necessidade de otimização da circulação viária das grandes cidades, a gestão municipal do tráfego exerce um papel importante para o aumento de produtividade das atividades sociais e econômicas, melhorando assim conseqüentemente a qualidade de vida da população urbana. Para promover uma gestão mais eficiente e eficaz do deslocamento viário, algumas cidades como São Paulo, Rio de Janeiro e Fortaleza, estão implantando sistemas de Controle de Tráfego por Área (CTA) (BOARNET; KIM; PARKANY, 1998 apud MENESES; LEANDRO; LOUREIRO, 2007, p. 1). Tais sistemas promovem o monitoramento e a otimização da circulação viária. Mas como avalizar a eficiência de tais sistemas? E o que pode ser feito em cidades que ainda não fazem o uso deste para controle de congestionamentos? A mensuração do nível de congestionamento do tráfego urbano ainda é feita de forma pouco satisfatória (BOARNET; KIM; PARKANY, 1998 apud MENESES; LEANDRO; LOUREIRO, 2007, p. 1). O grande volume de dados gerados a partir de sistemas CTA não o torna um indicador ideal. A especificação de um indicador ideal deve atender os seguintes critérios: facilidade de compreensão; definição formal; consistência; aplicabilidade a múltiplos modais de transporte urbano; baixo custo de determinação; procedimentos simples de coleta de dados; viabilidade de determinação para múltiplas entidades geográficas; períodos temporais e níveis de detalhe. (BOARNET; KIM; PARKANY, 1998 apud MENESES; LEANDRO; LOUREIRO, 2007, p. 2). Sendo assim é possível verificar que existe uma demanda pela obtenção de indicadores ideais para a correta aferição dos níveis de congestionamento e consequentemente para avaliação dos sistemas CTA. Tal demanda também pode ser observada em ferramentas que informem ao usuário as condições de tráfego atuais em determinadas vias e identifiquem qual o trecho com mais fluidez para chegar ao seu destino.

17 16 Diante do exposto, o presente trabalho aborda o desenvolvimento de um protótipo de aplicação para celulares com sistema Android que a partir de um endereço de origem e de destino informa ao usuário qual a rota que levará menos tempo para percorrer o trajeto. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho foi desenvolver um protótipo que apresente a rota de menor tempo entre dois pontos em uma malha viária. Os objetivos específicos são: a) coletar coordenadas geográficas a partir de um aparelho celular com sistema operacional Android; b) construir computacionalmente a representação de ruas de uma cidade através de coordenadas geográficas coletadas por usuários das vias de tráfego considerando as estatísticas das condições de tráfego; c) calcular uma rota de menor custo dado um ponto de origem e um ponto de destino através da representação computacional das ruas e das estatísticas de tráfego. 1.2 ESTRUTURA DO TRABALHO No capítulo 2 é apresentada a revisão bibliográfica que foi utilizada para dar suporte ao desenvolvimento do protótipo. Neste capítulo são apresentados conceitos e técnicas referente a caracterização de congestionamentos e algoritmo de busca de custo mínimo. O capítulo 3 mostra as etapas de desenvolvimento do protótipo. Primeiramente são apresentados os requisitos da aplicação, após isso são mostrados os diagramas utilizados para especificação da ferramenta. Na sequência são descritas as ferramentas e técnicas utilizadas na implementação do protótipo e sua operacionalidade. Por fim são apresentados os resultados e discussão. No capítulo 4 é feita a conclusão do trabalho e são apresentadas sugestões para trabalhos futuros.

18 17 2 FUNDAMENTAÇÃO TEÓRICA Na seção 2.1 é feita a caracterização dos congestionamentos. Na seção 2.2 é explicado geocodificação reversa. Na seção 2.3 é explicado o padrão malha viária urbana. Na seção 2.4 são abordados algoritmos de busca de custo mínimo. Na seção 2.5 são descritos quatro trabalhos correlatos. 2.1 CARACTERIZAÇÃO DE CONGESTIONAMENTOS Segundo Thurgood (1995 apud MENESES; LEANDRO; LOUREIRO, 2007, p. 2), um congestionamento pode ser definido como a deterioração da qualidade do fluxo de tráfego em condições de operação da pista além do nível aceitável pelo usuário, resultando em um aumento do tempo de viagem e do atraso, emissão de poluentes, número de acidentes, poluição sonora, etc. Um congestionamento pode então ser caracterizado por quatro componentes básicos: a duração que indica o período de tempo que o congestionamento afeta de alguma forma a rede viária, a extensão que estima o número de veículos afetado pelo congestionamento, a intensidade que indica a severidade do congestionamento e a periodicidade que indica com que frequência existe a formação de congestionamento (THURGOOD, 1995 apud MENESES; LEANDRO; LOUREIRO, 2007, p. 2). Resende e Souza (2009, p. 2) explicam que não existe uma definição universal de congestionamento. Contudo, se a velocidade média de uma via estiver abaixo da velocidade média para qual ela foi projetada então ela pode ser considerada congestionada. A capacidade da via e o nível de serviço, para Carapito (2002 apud COELHO, 2009, p. 32), são outros dois termos associados à palavra congestionamento, sendo o primeiro termo de caráter quantitativo o qual se refere à quantidade máxima de veículos que determinada via pode suportar, e o segundo, qualitativo. O fluxo de tráfego e o congestionamento têm comportamento flutuante ao longo do dia em função da demanda. O padrão de comportamento da sociedade é refletido por esta demanda, sendo a principal relação com o trabalho, o período em que as pessoas vão e voltam para o trabalho. Para estes casos o congestionamento é considerado previsível, ocorrendo

19 18 sempre nos mesmos períodos (COELHO, 2009, p. 35). Resende e Souza (2009, p. 2) afirmam ainda que o congestionamento pode variar em função do tipo de coordenação semafórica, da eficácia da fiscalização, ou ainda das condições topográficas. Segundo Coelho (2009, p. 30), a incapacidade de absorção do crescente volume de veículos por parte do sistema viário atual é o grande formador de congestionamentos. Sendo assim, três regimes de comportamento do tráfego podem ser definidos: regime de não saturação, regime de saturação e regime de super-saturação. A característica destes três regimes é a taxa de saturação do tráfego que é a relação do volume de veículos sobre a capacidade viária (v/c), de forma que quanto maior for a taxa de saturação, maior será a utilização das vias. Quanto mais o valor da taxa de saturação se aproximar de zero, o regime do comportamento de tráfego de não saturação é identificado. Tendo a relação v/c próxima ao valor de 1, o regime é de saturação, contudo se a relação v/c ultrapassar o valor de 1 o regime é de super-saturação (COELHO, 2009, p. 30). Coelho (2009, p. 31) explica que a capacidade das vias tem relação direta ao fluxo de saturação representado pela quantidade de veículos capaz de trafegar em um período de tempo, normalmente sendo determinado o período de uma hora para estimar o fluxo de saturação por faixas. A engenharia de tráfego propõe uma serie de medidas com a finalidade de aumentar a capacidade das vias sem intervenções físicas de médio e grande porte, sendo que diversas estratégias vem sendo executadas no mundo inteiro com o objetivo de combater o congestionamento e seus efeitos. A estratégia de controle de tráfego é uma das técnicas mais utilizadas e eficazes no combate ao congestionamento, com o objetivo de melhorar a operação semafórica, a circulação, sentido das vias, entre outros (COELHO, 2009, p. 33). 2.2 GEOCODIFICAÇÃO REVERSA O termo geocodificação se refere a tradução de um endereço legível para humanos em coordenadas geográficas que podem ser exibidas em um mapa georreferenciado. O processo inverso de conversão, ou seja, a tradução de uma coordenada geográfica em um endereço legível para humanos é conhecido como geocodificação reversa (API de geocodificação do Google, 2012).

20 PADRÃO DE REPRESENTAÇÃO: MALHA VIÁRIA URBANA Segundo Lisboa, Iochpe e Borges (2001), as aplicações baseadas em Sistemas de Informações Geográficas (SIG) podem usar técnicas que permitam a reutilização de componentes de software através da definição de padrões, aonde sua especificação deve conter no mínimo, os seguintes itens: problema, contexto, forças e solução. O problema trata de quais elementos pertencem a malha viária de uma cidade aplicado a um contexto de vias de locomoção do Brasil que determina um conjunto de trechos de vias e seus cruzamentos como sendo parte de uma rede viária urbana. Lisboa, Iochpe e Borges (2001) definem as forças como sendo cada via de locomoção uma instância de logradouro que deve possuir um código de identificação e um nome, estando normalmente dividido em trechos que são segmentos de via compreendidos entre duas conexões, em sequência, deste com outros logradouros que o cruzam ou interceptam. Sendo assim, um conjunto formado pelas conexões e pelos trechos e logradouros constituem a malha viária urbana. A possibilidade da realização de operações comuns a estruturas de redes como cálculo de caminho ótimo é observada devido a estrutura do padrão de malha viária urbana abstrair o padrão de modelo de estrutura de rede composta por arcos e nós, grafo. 2.4 ALGORITMO DE BUSCA DE CUSTO MÍNIMO Segundo Davis (1997, p. 3), existem basicamente dois algoritmos para resolver problemas de caminho mínimo com origem e destino, sendo o mais famoso deles o algoritmo de Dijkstra proposto em 1959 e constantemente aperfeiçoado principalmente pelo uso de estruturas de dados mais eficientes. Este algoritmo apenas funciona se os custos associados às arestas forem não negativos. Outro algoritmo proposto por Bellman e Ford admite o caso mais geral de custos negativos. De maneira geral, as grandezas físicas associadas às arestas são naturalmente não negativas, sendo que, o algoritmo de Dijkstra acaba sendo o método de solução de problemas de caminho mínimo mais utilizado na prática. O algoritmo considera um grafo G, composto por um conjunto de nós, denominado N, e um conjunto de arcos denominado A. Além disto, são conhecidos dois nós pertencentes a N, denominados o e d, que são respectivamente a origem e o destino.

21 20 Os nós são divididos em três grupos: os já visitados (conjunto V), os candidatos ou de fronteira (conjunto F) e os nunca visitados ou desconhecidos (conjunto D). O conjunto V é inicializado para conter apenas o nó o. Os vizinhos imediatos de o são colocados no conjunto F, sendo registrados os custos para atingi-los a partir de o, e os demais inicialmente pertencem ao conjunto D. A cada passo do algoritmo, os nós de F são verificados para determinar qual seria a melhor opção para expandir a pesquisa. Será escolhido e transferido para V aquele nó cujo custo acumulado seja a menor dentre os candidatos, e seus vizinhos serão então transferidos do conjunto D para o conjunto F. A pesquisa para quando o nó D for alcançado ou quando não houver mais nós a percorrer (neste caso, não existe caminho viável entre o e d). (DAVIS, 1997, p. 3). De acordo com Santos (2006, p. 30), o algoritmo de Dijkstra calcula o custo mínimo de um vértice raiz aos demais vértices de um grafo. Seu funcionamento parte de uma estimativa inicial para o custo mínimo e vai sucessivamente ajustando esta estimativa. O algoritmo de Dijkstra tem seu funcionamento de maneira que para cada vértice v pertencente a V, mantém-se um atributo d[v], que é um valor superior ao valor do custo mínimo desde a origem s até v (SANTOS, 2006 p. 31). Este atributo é chamado por Cormen (2002 apud SANTOS, 2006, p. 31), de estimativa de caminho mais curto e são inicializados com o algoritmo do Quadro 1. INITIALIZE-SINGLE-SOURCE(G,s) 1 for each vertex v V[G] 2 do d[v] 3 π[v] NIL 4 d[s] 0 Fonte: Santos (2006, p. 31). Quadro 1 Algoritmo de inicialização dos atributos de estimativa de caminho mais curto O algoritmo de Dijkstra mantém um conjunto S de vértices cujos pesos finais de caminhos mais curtos desde a origem s já foram determinados. O algoritmo seleciona repetidamente o vértice u V - S com a estimativa mínima de caminhos mais curtos, adiciona u a s e relaxa todas as arestas que saem de u. Na implementação a seguir, manteremos uma fila de prioridade mínima Q de vértices, tendo como chaves seus valores de d. (CORMEN, 2002 apud SANTOS, 2006, p. 31). O algoritmo de inicialização de atributos utiliza a técnica de relaxamento (Quadro 2). Segundo Cormen (2002 apud SANTOS, 2006, p. 31): O processo de relaxamento de uma arresta (u, s) consistem em testar se é possível melhorar o caminho mais curto para v encontrado até agora pela passagem de u. RELAX(u,v,w) 1 if d[v] > d[u] + w(u,v) 2 then d[v] d[u] + w(u,v) 3 π[v] u Fonte: Santos (2006, p. 31). Quadro 2 Algoritmo de relaxamento de atributos de estimativas de caminho mais curto O algoritmo de Dijkstra é apresentado através do Quadro 3. A explicação do algoritmo por Cormen (2002 apud SANTOS, 2006, p. 31) se da seguinte forma: a linha 1 é responsável pela inicialização dos valores de d e r, a linha 2 inicializa o conjunto S com um conjunto

22 21 vazio. DIJKSTRA(G,w,s) 1 INITIALIZE-SINGLE-SOURCE(G,s) 2 S 3 Q V[G] 4 while Q 5 do u EXTRACT-MIN(Q) 6 S S {u} 7 for each vertex v Adj[u] 8 do RELAX(u,v,w) Fonte: Santos (2006, p. 30). Quadro 3 Algoritmo de Dijkstra O algoritmo mantém o invariante de Q = V-S no início de cada iteração da estrutura de repetição das linhas 4 e 8. A fila de prioridade mínima Q é inicializada na linha 3 para conter todos os vértices em V. Sendo s = ø, a cada passagem pelo laço while das linhas 4 a 8, um vértice u é extraído de Q = V-S, e inserido no conjunto S. Sendo assim, o vértice u tem a menor estimativa de caminhos mais curtos em comparação com qualquer vértice em V-S. Nas linhas 7 e 8 relaxam cada aresta (u, v) que saem de u, atualizando a estimativa d[v] e o predecessor π[v] se o caminho mais curto até v pode ser melhorado mediante a passagem por u. 2.5 TRABALHOS CORRELATOS Esta seção destina-se a investigar na literatura alguns trabalhos que envolvem processamento de informações baseadas principalmente na localização dos veículos na via de tráfego com a finalidade de demonstrar ou estimar a situação do tráfego em determinada via. Os estudos analisados são Google Maps Navigation (2011), Google Maps (2011), GPS Airis (2011) e Mobile Millennium (AMIN, 2008). O aplicativo Google Maps Navigation (2011) está disponível para dispositivos com sistema Android e o aplicativo Google Maps disponível para celulares com os principais sistemas operacionais do mercado como Android, IOS e Symbian. A diferença entre os dois aplicativos é que o Google Maps Navigation é um complemento do Google Maps, este complemento funciona como um co-piloto narrando o trajeto a ser seguido. A Figura 1 exibe do lado esquerdo o aplicativo Google Maps e do lado direito o aplicativo Google Maps Navigation.

23 22 Figura 1 Google Maps e Google Maps Navigation A principal função destes aplicativos é exibir na tela do dispositivo um mapa das ruas das principais cidades do mundo, mas eles vão além exibindo as rotas congestionadas, identificando o nível de congestionamento através de cores, sendo verde para trânsito livre, amarelo para trânsito pesado e vermelho para trânsito parado (QUINTELLA, 2009), conforme pode ser visto na Figura 2.

24 23 Figura 2 Google Maps exibindo em cores as ruas congestionadas. Caso seja utilizado em modo de navegação, é capaz de fornecer uma rota alternativa ao encontrar um congestionamento. Segundo Barth (2009), ao utilizar a aplicação no modo de navegação, informações são enviadas anonimamente para os servidores da Google para servir como parâmetro para realizar o cálculo das condições de tráfego. De acordo com Wu (2007, p. 1), este tipo de sistema é conhecido como Google-mapbased Arterial Traffic Informatian (GATI). A arquitetura deste tipo de sistema pode ser observada na Figura 3, que é aplicada para cidade de Bellevue.

25 24 Fonte: WU (2007, p. 4). Figura 3 Representação da arquitetura de um sistema GATI Basicamente a arquitetura é dividida em três partes: servidores na cidade de Bellevue, servidores de laboratório STAR e aplicativos cliente (WU, 2007, p. 4). Wu (2007, p. 4) explica que os dados brutos de tráfego da cidade em questão são obtidos através das unidades de comunicação de controladores de sinais e são processados no servidor de dados. O trabalho de processamento é periodicamente repetido e os dados de tráfego processados são armazenados em um servidor File Transfer Protocol (FTP) para consumo do laboratório STAR. O objetivo do laboratório STAR é criar uma ponte de comunicação entre o servidor de dados e o servidor HyperText Transfer Protocol (HTTP) traduzindo o conteúdo de maneira que a camada de aplicativos cliente possa consumi-la. Recentemente a empresa Airis lançou o serviço Navtec Traffic que transmite informações por ondas de rádio de Frequência Modulada (FM) ao Global Positiong System (GPS) que exibe informações de trânsito dos grandes centros metropolitanos da região sudeste. Os dados de trânsito em tempo real possibilitam mais precisão no cálculo do tempo dos trajetos e o cliente pode escolher rotas alternativas baseando-se na condição atual do trânsito (GPS AIRIS, 2011). Segundo Freitas (2011), para que o GPS possa receber as informações de trânsito ele precisa estar conectado a outro dispositivo denominado de Easy Way. Por sua vez este recebe informações através de ondas de rádio conhecido como Radio Data System (RDS). As fontes do Easy Way são diversas e incluem companhias de trânsito como a Companhia de Engenharia de Tráfego (CET) e Empresa de Transportes e Trânsito de Belo Horizonte (BHTrans), e rastreadores de veículos. O sistema depende da disponibilidade e alcance de estações de rádio para transmitir os pontos engarrafados. A maneira com o GPS Airis exibe o mapa e a rota é semelhante ao Google Maps Navigation conforme Figura 4.

26 25 Fonte: GPS Airis (2011). Figura 4 GPS Airis exibindo as condições do tráfego Mobile Millennium é um projeto de pesquisa que conta com um sistema de monitoramento de tráfego que utiliza telefones celulares com GPS para coletar e processar informações de trânsito e as retornar aos usuários. O projeto surgiu do experimento chamado Mobile Century que é um protótipo de serviço baseado em localização que foi criado com o objetivo de demonstrar a viabilidade de um serviço de estimativa de tráfego em tempo real utilizando dados de GPS a partir de telefones celulares (AMIN, 2008, tradução nossa). O experimento Mobile Century possui uma arquitetura que tem por objetivo reunir dados dos veículos de sondagem em um ambiente de privacidade reservada utilizando conceitos de Linhas de Viagens Virtuais (LVV) que são marcos geográficos armazenados no cliente (telefones celulares). Somente ao passar com seu veículo por estes marcos é que a posição e velocidade são atualizadas. Uma maior privacidade é obtida ao utilizar amostragem no espaço através de linhas LVV em vez de amostragem no tempo (AMIN, 2008, tradução nossa). A arquitetura do experimento Mobile Century é composta por quatro entidades: telefones celulares com GPS, um operador de rede celular, um servidor de proxy, e um sistema de monitoramento e reconstrução de tráfego (AMIN, 2008, tradução nossa). Os dados coletados são usados para estimar a velocidade e tempo de viagem. Um servidor recebe os dados enviados dos telefones celulares e executa algoritmos de reconstrução de fluxo de tráfego. Estes algoritmos se baseiam em modelos de fluxo não lineares que descrevem a evolução da velocidade do tráfego e podem reproduzir com precisão

27 26 as ondas de choque criadas a partir de acidentes ou pontos de estrangulamento na estrada. Tais modelos são usados por um algoritmo inverso de modelagem de estimação e as estimativas produzidas pelo algoritmo são enviadas de volta para um servidor de visualização que por sua vez transmite o estado do tráfego através da internet conforme mostra a Figura 5. Fonte: Amin (2008). Figura 5 Exibição do relatório de tráfego O experimento Mobile Century demostrou que telefones celulares com GPS podem ser usados como sensores de monitoramento de tráfego preservando a privacidade das pessoas quanto a coleta de dados. O experimento demonstrou também que a reconstrução do tráfego é possível mesmo que apenas cerca de 5% dos veículos esteja utilizando os telefones celulares para coleta de dados. O Quadro 4 mostra de forma resumida as principais características dos trabalhos correlatos. As informações dispostas em colunas representam os trabalhos correlatos analisados e as linhas representam as características de cada trabalho. Características / trabalhos correlatos Google Maps (2011) Google Maps Navigation (2011) GPS Airis (2011) Mobile Century (2008) Obtenção de rota de menor custo - X X - Envio de informações de condições de tráfego - X - X Visualização das condições de tráfego das vias X X X X Quadro 4 Características dos trabalhos relacionados Através do Quadro 4 é possível verificar o Google Maps e o Mobile Century são capazes de visualizar as condições de tráfego das vias porém não permitem a obtenção da rota de menor custo, característica esta que os sistemas Google Maps Navigation e GPS Airis

28 27 atendem. Para o sistema Google Maps não faz sentido o envio de informações das condições do tráfego, pois normalmente este sistema é utilizado em computadores, mesmo sendo disponível em celulares com sistemas Android, IOS ou Symbian. Diferentemente do Google Maps Navigation que é disponibilizado apenas para celulares com sistema Android porém envia informações das condições de tráfego, alias o único sistema que atinge todas as características. Para todos os sistemas é possível observar um baixo nível de adesão de novas cidades, este processo não é claro ou declarado, o que deixa uma lacuna aberta sobre como realmente são consideradas as condições do tráfego para exibição do mesmo ou ainda para obtenção da rota de menor custo. Visando suprir tais demandas, o protótipo apresentado neste trabalho foi desenvolvido guiado por estes requisitos.

29 28 3 DESENVOLVIMENTO Neste capítulo são abordadas atividades relacionadas ao projeto e desenvolvimento do protótipo proposto neste trabalho. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO O protótipo deve: a) disponibilizar uma interface para informar os endereços de origem e destino através de coordenadas geográficas (Requisito Funcional - RF); b) enviar informações de coordenadas geográficas para um servidor na web (RF); c) exibir no dispositivo uma rota de menor custo que será calculada no servidor entre as coordenadas geográficas de origem e de destino informadas (RF); d) ser desenvolvido utilizando programação orientada a objetos com a linguagem de programação C# para o servidor e Java para o dispositivo móvel com sistema Android (Requisito Não Funcional - RNF); e) ser implementado utilizando o ambiente de programação Microsoft Visual Studio 2010 para a linguagem C# e Eclipse Indigo para Java (RNF); f) ser compatível com no mínimo a versão 2.1 do Android (RNF). 3.2 ESPECIFICAÇÃO O protótipo foi especificado utilizando diagramas da Unifild Modeling Language (UML) usando a metodologia de orientação a objetos. Foi utilizada a ferramenta Microsoft Visio para o desenvolvimento dos diagramas de caso de uso, de classe e de sequência.

30 Diagrama de casos de uso A Figura 6 exibe o diagrama de casos de uso para o protótipo sendo executado no dispositivo móvel do usuário. Figura 6 Diagrama de casos de uso No caso de uso UC 1 Coletar dados, o usuário utilizará o seu dispositivo para fazer a coleta de dados enquanto percorre determinado trecho da via com seu veículo, sendo que estes dados serão utilizados na concepção da malha viária e suas estatísticas de tráfego contribuindo no cálculo da rota de menor custo. No caso de uso UC 2 Enviar dados, o usuário enviará os dados coletados para um servidor na web. No caso de uso UC 3 Obter rota de menor custo, a partir das coordenadas geográficas obtidas pelo caso de uso UC 4 Informar coordenadas geográficas de origem e de destino, o protótipo envia estas informações ao um servidor na web que lhe retornar a rota de menor custo. No caso de uso UC 4 Informar coordenada geográfica de origem e destino, o usuário informará as coordenadas geográficas de origem e de destino ao qual pretende obter a rota de menor custo Diagrama de classes Para facilitar o entendimento da representação da estrutura de classes, as mesmas

31 30 foram subdivididas em duas subseções sendo a primeira referente ao diagrama de classes do aplicativo cliente e a segunda referente ao diagrama de classes do aplicativo servidor Diagrama de classes do aplicativo cliente A Figura 7 apresenta o diagrama das principais classes que compõem o aplicativo cliente que é executado no dispositivo móvel do usuário.

32 31 Figura 7 Diagrama de classes do protótipo executado no dispositivo móvel A classe Coordenada representa um ponto no sistema de localização terrestre que é utilizada por algumas classes do protótipo, tais como ThreadSalvarCoordenadas, WsProvider e Repositorio. Para realizar a coleta das coordenadas pelo caminho ao qual o usuário percorreu a classe ColetaDeDadosActivity é usada. A implementação da interface LocationListener permite receber atualizações de localização do dispositivo através do método

33 32 onlocationchanged que contém o parâmetro Location com as informações de precisão, velocidade, latitude e longitude. O método onlocationchanged ao receber as atualizações de localização cria uma instância de ThreadSalvarCoordenadas passando como parâmetro um objeto Location. Então esta coordenada é convertida para um objeto do tipo Coordenada e salva através do método SalvarCoordenadas de uma instância do tipo Repositorio. A classe AsyncTask permite criar uma tarefa assíncrona e informar ao usuário o status do envio das coordenadas através de uma barra de progresso. Esta classe é especificada através da classe EnviarWebService que é responsável por proporcionar a interação com o usuário. Já a classe WsProvider tem a responsabilidade de enviar as coordenadas salvas ao servidor na web. A classe MapActivity do Framework Android é responsável por possibilitar a exibição de um mapa do tipo Google Maps. Sendo assim a classe MapaObterEnderecoActivity estende essa característica e possibilita que o usuário veja e navegue em um mapa. Através de uma sobreposição representada pela classe MapaOverlay é possível criar botões sobre o mapa a fim do usuário informar seus pontos de origem e de destino. O método ontap representa a ação de toque no mapa e através do parâmetro GeoPoint é obtida a informação de latitude e longitude do ponto. O método OnClick é executado quando o usuário clica no botão para calcular a rota de menor custo. O método CalcularRota através de uma instância da classe WsProvider é chamado passando os pontos de origem e de destino como parâmetros. O retorno é um texto contendo a rota de menor custo calculada no servidor Diagrama de classes do aplicativo servidor As classes envolvidas no recebimento das coordenadas geográficas coletadas pelo aplicativo cliente estão representadas pela Figura 8. A classe ATV é a porta de entrada do aplicativo servidor e representa o web service. Para que a aplicação cliente possa enviar as coordenadas geográficas coletadas, antes ela deve obter um identificador único através do método PegarIdDispositivo.

34 33 Figura 8 Diagrama de classes do servidor O método EnviarCoordenada recebe um objeto do tipo CoordenadaDispositivo que contém além das informações de localização também o identificador do dispositivo. Através da classe SalvarDados a coordenada é salva no banco de dados para depois ser processada. Quando a aplicação cliente termina de enviar todas as coordenadas o método ConcluirSessaoDispositivo é chamado e marca a sessão de envio de coordenadas como encerrada para que o servidor possa processar todas as coordenadas do dispositivo ao qual foi concluído. A execução do método ConcluirSessaoDispositivo garante que todas as coordenadas foram enviadas, permitindo que o servidor processe o percurso total efetuado pelo usuário. Caso ocorra alguma falha no envio das coordenadas e o método ConcluirSessaoDisitivo não seja executado, então estas coordenadas não serão consideradas pelo servidor para os cálculos de estatísticas. As classes envolvidas no cálculo da rota de menor custo estão representadas pela Figura 9. O cálculo é solicitado pelo aplicativo cliente ao aplicativo servidor através da classe ATV do método CalcularRotaMenorCusto.

35 34 Figura 9 Diagrama de classes do servidor A classe Grafo é responsável pelo cálculo da rota de menor custo. O método CalcularRotaMenorCusto é o método principal e através das coordenadas geográficas passadas por parâmetro visa obter os cruzamentos mais próximos e acionar o método CaminhoMinimo que por sua vez utiliza-se do método MontarGrafo e DijkstraRecursivo para obter a rota de menor custo.

36 35 Para obter as estatísticas para realizar o cálculo da rota a classe Grafo utiliza-se da classe LerDados para obter dados necessários para montar o grafo que representa a malha viária. Esta classe não foi representada no diagrama por tratar-se de uma classe auxiliar e sua adição comprometeria o espaço de classes mais importantes para o entendimento da problematização. A Figura 10 representa o diagrama de classes que contém as classes envolvidas na construção da estrutura que representa a malha viária e nas estatísticas de condições de tráfego das vias.

37 36 Figura 10 Diagrama de classes do servidor A classe SecaoRua representa um trecho de uma determinada rua a partir de um cruzamento de origem até um cruzamento de destino. Esta classe contém informações como a

38 37 distância em metros deste trecho e a velocidade média em metros por segundo que o condutor do veículo levou para percorrer o trecho. Uma rua conterá tantos objetos do tipo SecaoRua quantos cruzamentos tiver. A classe Cruzamento representa o cruzamento entre duas ou mais ruas e é identificado como um ponto no sistema geográfico através de informações de latitude e longitude. Através da classe Processos é dado início ao processamento dos dados coletados pelos dispositivos. Este processamento tem o objetivo de formar a estrutura que representa as ruas e calcular as estatísticas das mesmas. A partir dos dispositivos que tiveram a sessão de coletada de dados marcada como concluída, as coordenadas são obtidas através do método LerCoordenadasDispositivosConcluidos da classe LerDados. A partir disso, as coordenadas são processadas, sendo obtido o nome da rua através de geocodificação reversa, implementada pela classe ReveserGeo no método NomeRuaPelaCoordenda. O método RemoverRuasInvalidas da classe Negocio é responsável por verificar a lista de coordenadas e identificar uma falha na coleta das coordenadas causada pela baixa precisão do GPS que devido a uma distorção na coleta pode retornar uma ou mais coordenadas que representam uma rua adjacente que não foi percorrida. Na classe Negocio o método CalcularEstatisticaRuas recebe então uma lista de objetos do tipo CoordenadaRua que contem o trajeto ao qual o usuário percorreu identificado por valores de latitude e de longitude e também pelo nome da rua obtida antes através de geocodificação reversa. De posse das informações do trajeto percorrido, o método CalcularEstatisticaRuas percorre a lista de coordenadas agrupadas pela rua e então se obtém a distância total percorrida na rua. Subtraindo o tempo da última coordenada pelo tempo da primeira se obtém o tempo que o usuário levou para percorrer este caminho. De posse da distância do trecho e do tempo que levou para ser percorrido um cálculo é realizado para obter a velocidade média. Então uma instância da classe SecaoRua é criada com estas informações e adicionada a uma lista de seções geradas que tem o objetivo de no final da execução do algoritmo ser percorrida e gerar os cruzamentos entre uma seção da rua e outra.

39 Diagrama de sequência Os diagramas de sequência mostram como os grupos de objetos colaboram em algum comportamento ao longo do tempo registrando assim as trocas de mensagens entre os objetos envolvidos em um caso de uso. A seguir são mostrados os diagramas de sequência dos casos de uso do protótipo Coleta de dados A Figura 11 mostra o diagrama de sequência que permite visualizar o caso de uso UC 1 Coletar dados, que foi descrito na seção Figura 11 Diagrama de sequência coleta de dados O processo de coleta de dados é iniciado a partir do método onlocationchanged que é acionado toda vez que a localização do dispositivo é alterada. Este método por sua vez cria o objeto ThreadSalvarCoordenadas passando como parâmetro para o seu construtor o objeto contento as informações de localização que foram alteradas. O objeto ThreadSalvarCoordenadas é um thread e sua execução ocorre paralelamente através do método run. Este método converte a coordenada recebida no construtor para um objeto do tipo Coordenada e aciona o método SalvarCoordenada do objeto Repositorio passando o objeto convertido como parâmetro. O método SalvarCoordenada do objeto Repositorio salva então esta coordenada em um banco de dados.

40 Envio dos dados A Figura 12 mostra o diagrama de sequência que permite visualizar o caso de uso UC 2 Enviar dados, que foi descrito na seção Figura 12 Diagrama de sequência enviar dados O processo de envio das coordenadas salvas para o servidor se inicia a partir do momento que o usuário aciona o método btenviarcoordenadasservidoronclick. Uma instância da classe EnviarWebService é então criada e o método CarregarCoordenadas é executado. Então as coordenadas salvas no banco de dados são lidas através do método LerCoordenadas. O método Execute inicia o processo de envio das coordenadas para o servidor na web chamando o método PegarIdDispositivo, o retorno deste método é usado para alimentar a

41 40 propriedade Dispositivo do objeto Coordenada antes deste ser passado como parâmetro no método EnviarCoordenada dentro do loop que itera sobre as coordenadas salvas no banco de dados, capturadas anteriormente através do método LerCoordenadas. Após iterar sobre todas as coordenadas o método FinalizarSessaoDispositivo é acionado passando o identificador do dispositivo obtido anteriormente. Assim o web service tem a confirmação de que o envio das coordenadas foi encerrado e que estas estão prontas para ser processadas. Por fim o método ApagarCoordenadas é executado, ele é responsável por apagar todas as coordenadas salvas no banco de dados deixando-o pronto para receber uma nova série de coordenadas representando um novo trecho percorrido Cálculo das estatísticas A Figura 13 mostra o diagrama de sequência do cálculo das estatísticas sobre as coordenadas coletadas dos usuários.

42 Figura 13 Diagrama de sequência do cálculo das estatísticas no servidor 41

43 42 O processo de cálculo das estatísticas tem inicio pelo método ProcessarDadosColetados que é responsável por controlar todo fluxo de métodos que envolve o cálculo de estatísticas. Inicialmente as coordenadas dos dispositivos com sessão concluída são lidas através do método LerCoordenadasDispositivosConcluidos. As coordenadas dos dispositivos de seção concluída são então agrupadas por dispositivo. Em seguida para cada coordenada do grupo correspondente a um dispositivo o método NomeRuaPelaCoordenada do objeto ReverseGeo é acionado. Este método tem por objetivo transformar uma coordenada em um endereço, neste caso retornando o nome da rua a qual a coordenada representa. ReverseGeo utiliza-se da API (Application Programming Interface) de geocodificação do Google para obter esta informação. Tendo obtido o nome da rua ao qual a coordenada representa, o objeto do tipo Coordenada é convertido para um objeto do tipo CoordenadaRua que contém além da informação de localização também o nome da rua. No processo de coleta de dados pelo dispositivo do usuário devido a sua baixa precisão e da proximidade entre as ruas pode ocorrer que algumas coordenadas passem sobre ruas que o usuário não esta percorrendo. Para resolver este problema o método RemoverRuasInvalidas é utilizado. Este método é capaz de identificar estes casos de identificação de ruas as quais o usuário não percorreu e removê-las. Removidas as coordenadas inválidas, o grupo de coordenadas agora identificadas é salvo no banco de dados através do método SalvarCoordenadasRuas. Depois o método MarcarDispositivoComProcessado é acionado para que fique registrado que as coordenadas deste dispositivo já foram processadas. O método CalcularEstatisticasRuas é então acionado passando a lista de coordenadas como parâmetro. Devido a este método ser consideravelmente complexo o seu diagrama de sequência foi feito separadamente e pode ser visto na Figura 14.

44 43 Figura 14 Diagrama de sequência complementar do cálculo de estatísticas no servidor A lista de coordenadas passadas por parâmetro são agrupadas pela rua e então é feito um loop no grupo de ruas. No loop de ruas é verificado se trata-se da primeira ou da última

45 44 rua, caso seja a primeira ou a última rua então o método ProcessarPrimeiraEUltimaCoordenadaRua é acionado. Este método é responsável por processar a primeira e última rua percorrida de um trecho. Neste caso o processamento é feito em separado, pois não será gerada estatística para estas ruas devido as elas mesmas terem sido percorridas a partir de um cruzamento de origem até um cruzamento de destino. Estas ruas não podem ser descartadas, pois no caso da primeira rua ela será responsável por criar o cruzamento de origem da próxima rua e no caso da última rua ela será responsável por criar o cruzamento de destino da penúltima rua. Se a rua que está sendo iterada no momento não for nem a primeira e nem a última então tenta-se obter um cruzamento inicial desta rua através do método BuscarCruzamentoInicial passando a primeira coordenada da rua como parâmetro e um identificador único da rua. Este método irá buscar todas as seções de rua salvas que tenham o mesmo identificador de rua que foi passado por parâmetro e então a partir do cruzamento de origem destas seções de rua irá tentar encontrar o cruzamento mais próximo da coordenada que foi passada por parâmetro com uma distância máxima de 35 metros. Caso tenha-se encontrado um cruzamento inicial o método ProcessarCoordenadasRuaAPartirDeCruzamentoInicial é acionado. Este método tem o objetivo de processar as estatísticas das coordenadas atuais levando em consideração que esta rua já foi percorrida anteriormente por outro usuário. Se um cruzamento inicial não for encontrado então tenta-se buscar um cruzamento final através do método BuscarCruzamentoFinal que tem a mesma dinâmica do método BuscarCruzamentoInicial com a diferença de que serão usados os cruzamentos de destino das seções das ruas com o mesmo identificador da rua atual invés de usar os cruzamentos de origem. Caso um cruzamento final seja encontrado então o método ProcessarCoordenadasRuaAPartirDeCruzamentoFinal é acionado. Cruzamentos finais são gerados a partir de seções de rua temporárias que não puderam ter suas estatísticas apuradas devido a não terem sido coletadas coordenadas geográficas até um outro cruzamento, estas seções temporárias são geradas pelo método ProcessarPrimeiraEUltimaCoordenadaRua que foi explicado anteriormente. Portanto a partir deste cruzamento final, a seção de rua que possuir este cruzamento como sendo o seu cruzamento de origem terá sua estatística agora inserida, pois com base nas coordenadas geográficas atuais é possível determinar o final desta seção com um cruzamento de destino. Se um cruzamento final não for encontrado o método

46 45 ProcessarCoordenadasSemCruzamentoInicialOuFinal é acionado. Isto significa que nenhum usuário passou anteriormente por essa rua então não há dados a serem atualizados e sim apenas inseridos. Por fim, o método GerarCruzamentos é acionado. Este método tem a responsabilidade de gerar os cruzamentos entre as ruas. Como as coordenadas estão na mesma ordem em que elas foram coletadas a geração dos cruzamentos sempre ocorre na mudança de uma rua para outra Obter rota de menor custo A Figura 15 mostra o diagrama de sequência que permite visualizar o caso de uso UC 3 Obter rota de menor custo e o caso de uso UC 4 Informar coordenada geográfica de origem e de destino, que foi descrito na seção Figura 15 Diagrama de sequência obter rota de menor custo Para obter a rota de menor custo o usuário antes deve informar o ponto de origem e destino ao qual ele quer obter a rota. Isto é feito através do método ontap na classe MapaObterEnderecoActivity que exibe um mapa para o usuário. Quando o usuário pressiona um ponto do mapa, o método ontap é acionado, sendo exibidos ao usuário o botão Origem e o botão Destino. Ao pressionar um dos dois botões, o

47 46 método onclick do objeto MapaOverlay é acionado passando como parâmetro o botão pressionado. De acordo com o botão que foi pressionado, a coordenada de origem ou de destino é então mapeada. Após definir os pontos de origem e de destino o mesmo pressiona o botão de cálculo de rota menor custo que aciona o método onclick do objeto MapaObterEnderecoActivity. Este método por sua vez aciona o método CalcularRota do objeto WsProvider passando as coordenadas do ponto de origem e do ponto de destino como parâmetro. O objeto WsProvider tem a responsabilidade de enviar estas informações ao web service e retornar a rota de menor custo calculada pelo servidor. O processo de obtenção da rota de menor custo no web service é mostrado pelo diagrama de sequência que pode ser visualizado na Figura 16.

48 47 Figura 16 Diagrama de sequência do web service O web service é executado para obter a rota de menor custo, então o método CalcularRotaMenorCusto é acionado passando como parâmetros as coordenadas de origem

49 48 e de destino. Para as coordenadas de origem e de destino, o objeto Grafo busca obter o cruzamento mais próximo através do método ObterCruzamentoMaisProximo do objeto CalculoCoordenadas. O método ObterCruzamentoMaisProximo utiliza-se do método NomeRuaPelaCoordenada do objeto ReverseGeo para obter o nome da rua a qual aquela coordenada representa. De posse desta informação o método LerRuaByNome do objeto Repositorio é acionado para verificar se esta rua foi mapeada anteriormente e também para buscar o identificador desta rua. Encontrada a rua, o método LerSecaoRuaByIDRua é acionado para obter todas as seções mapeadas desta rua. Tendo as seções da rua a qual a coordenada representa é possível obter o cruzamento de origem e destino destas seções e acionar o método CruzamentoMaisProximoDaCoordenada passando a lista de cruzamentos e a coordenada como parametro. O método CruzamentoMaisProximoDaCoordenada verifica qual cruzamento da lista de cruzamentos passada como parâmetro está mais próximo da coordenada passada como parâmetro. Para saber qual é o cruzamento mais próximo um cálculo é feito tendo as coordenadas de latitude e longitude do cruzamento e as coordenadas de latitude e longitude do ponto. A partir disso é possível obter a distância entre estas coordenadas e então determinar qual o cruzamento está mais próximo. Tendo o cruzamento mais próximo da coordenada de origem e o cruzamento mais próximo da coordenada de destino, o método CaminhoMinimo é acionado passando estas informações como parâmetro. Este método tem o objetivo de montar um grafo das ruas e cruzamentos já mapeados pelo servidor através do método MontarGrafo que lê do banco de dados através do método LerCruzamentos do objeto Repositorio todos os cruzamentos já mapeados, itera sobre estes cruzamentos e para cada cruzamento as seções das ruas são carregadas através do método LerSecaoRuaByCruzamento. Desta forma o grafo é montado tendo os cruzamentos como sendo os vértices e as seções das ruas como sendo as arrestas. De posse do grafo o vértice raiz referente a coordenada de origem é definido e então o método DijkstraRecursivo é acionado passando o grafo e o vértice raiz como parâmetro. O método DijkstraRecursivo irá percorrer todo grafo a partir do vértice de origem e determinar o menor custo baseado na distância e na velocidade média de cada aresta para com os demais vértices, definindo assim a rota de menor custo do vértice de origem para com todos os demais. Ao final do cálculo o grafo terá em cada vértice a informação de qual vértice anterior deve ser percorrido a fim de se estabelecer a rota de menor custo.

50 49 Com o resultado do processamento do método DiskstraRecursivo o vértice de destino dentro do grafo é localizado e então o caminho inverso é feito até o vértice de origem percorrendo apenas os vértices que tiveram o menor custo, para cada vértice percorrido o nome da rua é armazenado em uma lista que representará quais ruas devem ser percorridas em ordem para se chegar do cruzamento de origem ao cruzamento de destino com o menor custo Modelagem de dados geográficos geocodificados Esta seção mostra como foram modelados os dados geográficos coletados de maneira a representarem a malha viária de uma cidade. Tendo a modelagem destes dados, foi possível determinar o algoritmo de busca de menor caminho. Para a geocodificação reversa das coordenadas geográficas enviadas pelo cliente foi utilizada a API de geocodificação do Google (2012). Esta API permite que a partir de uma coordenada geográfica seja possível obter o endereço aproximado representado por esta coordenada. Neste trabalho esta funcionalidade é utilizada para obter-se o nome da rua em que o usuário percorreu. A API é de uso simples bastando apenas fazer uma requisição para o endereço da API passando como parâmetros a latitude e longitude e um extensible Markup Language (XML) é retornado contendo as informações do endereço. Para a modelagem dos dados geográficos coletados será utilizada a metodologia de orientação a objetos aliada à abordagem de representação da malha viária de Lisboa, Iochpe e Borges (2001) conforme pode ser visto na Figura 17.

51 50 Fonte: Lisboa, Iochpe e Borges (2001, p. 110). Figura 17 Diagrama de classes do padrão malha viária urbana Nesta abordagem cada via de locomoção deve possuir um código de identificação e um nome, além de estar normalmente dividida em diversos trechos, denomina-se assim um logradouro. Um trecho de logradouro corresponde ao segmento de via compreendido entre duas conexões em sequência deste com outros logradouros que o cruzam ou interceptam. Neste trabalho tal abordagem será empregada no desenvolvimento do web service que tem a responsabilidade de receber as coordenadas geográficas e montar uma estrutura de maneira que represente a malha viária para depois sobre esta estrutura poder encontrar a rota de menor custo. A representação da malha viária será feita através do conceito de rede que são construídos através da topologia arco-nó, de forma que as ruas serão representadas por arcos e os cruzamentos entre as ruas por nós. Tal representação nada mais é do que um grafo, onde são armazenadas as informações sobre recursos de cada trecho ou nó da rede. Para identificar a rota de menor custo é necessário definir um valor de impedância para cada arco. Segundo Freitas (2004 apud SANTOS, 2006, p. 28), em redes viárias as impedâncias podem ser representadas pelas mais variadas grandezas, seja pela distância linear dos arcos, ou até mesmo por valores específicos aos atributos de cada trecho em particular. Tendo o objetivo de percorrer um determinado trecho em um menor tempo, a impedância dos arcos deve representar então a condição de tráfego ali presente. Desta forma a impedância de cada arco será representada pelo tempo médio necessário para percorrê-lo. Tendo a modelagem da malha viária tornado-se um grafo, é possível aplicar técnicas ou algoritmos da área de teoria dos grafos onde normalmente é utilizado o algoritmo de

52 51 Dijkstra para obter o menor caminho entre dois vértices do grafo. No problema a ser resolvido neste trabalho o algoritmo de Dijkstra será utilizado para estabelecer a rota de menor caminho entre a origem e o destino, aonde nestas condições interpreta-se a rota de menor caminho como sendo a que levará o menor tempo para ser percorrida se comparada com as demais existentes. O algoritmo de Dijkstra foi escolhido, pois levou-se em consideração a pesquisa de Santos (2006, p. 56), onde o mesmo se mostrou nitidamente mais eficiente perante outros algoritmos principalmente com uma entrada maior de dados. 3.3 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da implementação Técnicas e ferramentas utilizadas Para o desenvolvimento do protótipo cliente que é executado no dispositivo móvel do usuário foi utilizada a linguagem de programação Java no ambiente de desenvolvimento Eclipse Indigo Service Release 2, como o aplicativo é executado sobre o sistema Android, foi utilizado o Software Development Kit (SDK) revision 19. Para integração entre o SDK e o Eclipse foi utilizado o Android Development Tools (ADT) na versão Para o consumo do web service foi utilizada a biblioteca ksoap2. O desenvolvimento do web service foi feito na linguagem de programação C#, com suporte a versão 3.5 do.net Framework. Nestas condições, o Integrated Development Environment (IDE) Microsoft Visual Studio 2010 foi selecionado para realizar a implementação Coleta, envio e recebimento das coordenadas geográficas dados para determinar a extensão da malha viária e as estatísticas de tráfego.

53 52 O processo de coleta de coordenadas é executado pelo aplicativo cliente e esta concentrado na classe ColetaDedadosActivity. Esta classe implementa a interface LocationListener do Android que permite receber notificações de localização através do método onlocationchanged, que é chamado pelo Android sempre que a localização GPS for alterada. Para que o Android avise sobre alterações de localização é necessário chamar o método requestlocationupdates através de um objeto do tipo LocationManager passando como parâmetro o tipo de provedor de localização ao qual deseja receber atualizações. Neste caso um provedor de localização de GPS, o tempo mínimo em milissegundos representando o intervalo mínimo de tempo em que a aplicação deve receber atualizações sobre localizações, baseada em um gerente de localização ao qual solicita ao sistema Android atualizações de localização, a distância mínima em metros necessária a ser percorrida para a aplicação receber atualizações sobre as localizações, e por fim, uma implementação da interface LocationListener que receberá as atualizações das coordenadas pelo método onlocationlistener, neste caso a própria classe ColetaDeDadosActivity. A execução deste método requestlocationupdates pode ser visto no Quadro 5, no método InicializarLocationMananger que é executado no método onresume da classe ColetaDeDadosActivity private void InicializarLocationMananger() { final LocationManager manager = (LocationManager) getsystemservice( Context.LOCATION_SERVICE ); if (manager.isproviderenabled( LocationManager.GPS_PROVIDER )) { if (lmgerenciadordelocalizacao == null) lmgerenciadordelocalizacao = (LocationManager) getsystemservice(location_service); lmgerenciadordelocalizacao. requestlocationupdates(locationmanager.gps_provider, 0, 0, this); } else ConstruirMensagemAlertaGPSNaoAtivado(); } Quadro 5 Registro do gerenciador de localização Sendo assim, de acordo com o registro da intenção de receber atualizações de localização o método onlocationchanged será chamado sempre que a localização do dispositivo for alterada. A implementação deste método pode ser visto no Quadro 6.

54 public void onlocationchanged(location prlocation) { boolean podesalvar = false; preenchervaloresdatela(prlocation); if (prlocation.hasaccuracy() && prlocation.getaccuracy() <= 15 && prlocation.hasspeed() && prlocation.getspeed() > 0) { if (ultimalocationsalva == null) { podesalvar = true; } else { long diferenca = prlocation.gettime() - ultimalocationsalva.gettime(); } if (diferenca > 5000) podesalvar = true; if (podesalvar) { ultimalocationsalva = prlocation; preenchelistadecoordenadastela(prlocation); Runnable thread = new ThreadSalvarCoordenadas(prLocation); new Thread(thread).start(); } } } Quadro 6 Recebendo atualizações de localização Ao receber uma atualização de localização o método onlocationchanged recebe como parâmetro um objeto do tipo Location que contém as informações de latitude, longitude, tempo global, precisão do GPS e velocidade. Sendo assim, sua execução consiste em atualizar os valores de velocidade e precisão exibidos na tela através da execução do método preenchervaloresdatela (linha 3) passando como parâmetro o objeto de localização recebido. Depois é necessário verificar se a localização retornada possui precisão através do método hasaccuracy (linha 5) da localização, e se seu retorno for verdadeiro então verificase se esta precisão é igual ou inferior a 15 metros (linha 5), verifica-se também se esta localização possui velocidade através do método hasspeed (linha 6), e se seu retorno for verdadeiro então verifica-se se a velocidade é superior a 0 (linha 5). Tendo as verificações de precisão e velocidade realizadas é possível agora salvar esta informação de coordenada geográfica, mas somente se o intervalo de tempo entre a última coordenada geográfica salva for maior que 5 segundos. A thread ThreadSalvarCoordenadas é então criada (linha 21) passando como parâmetro a instância do objeto Location, então esta thread é executada (linha 23), para paralelamente salvar esta coordenada no banco de dados local da aplicação. Trabalhar com valores de precisão superiores a 15 metros poderia fazer com que a localização retornada acabasse representando uma rua pela qual o usuário não percorreu o que invalidaria as estatísticas de tráfego, já que as condições de tráfego enfrentadas em uma rua

55 54 estariam sendo representadas por outra rua. Não é necessário atualizar as informações de localização caso não haja velocidade. Salvar informações de localização nestas circunstâncias só iria gerar dados desnecessários para o servidor. Um valor mínimo de 5 segundos foi estabelecido entre a atualização de informações de localização. Este valor tem por objetivo diminuir o elevado número de informações de localização que são geradas caso este tempo não fosse controlado Geração da malha viária e das estatísticas de tráfego com base nas coordenadas coletadas A geração da malha viária consiste em criar um conjunto de informações que represente de maneira computacional a malha viária de uma cidade contendo as seções das ruas, as ruas e os cruzamentos. E a geração das estatísticas de tráfego nada mais é do que representar as condições de tráfego reais sobre o conjunto de informações que representam a malha viária. A abordagem de representação da malha viária de Lisboa, Iochpe e Borges (2001). descrita na seção foi utilizada como base para criação da malha viária no aplicativo servidor e pode ser vista no diagrama de classes definido na seção representada pelas classes Rua, SecaoRua e Cruzamento. Desta forma, o algoritmo que pode ser visto no Quadro 7 foi modelado de maneira que através dos dados geográficos coletados pelos clientes a malha viária fosse construída dinamicamente e também assim as estatísticas de tráfego geradas, o algoritmo está localizado na classe Negocio e é representado pelo método CalcularEstatisticaRuas.

56 public static void CalcularEstatisticaRuas(CoordenadasRuas prcoordenadasrua) { var ruascustogeradas = new List<SecaoRua>(); var coordenadasruas = prcoordenadasrua; var coordenadasruasagrupadas = coordenadasruas.groupby(cordruas => cordruas.rua.id); foreach (var coordenadasrua in coordenadasruasagrupadas) { if (coordenadasrua.key == coordenadasruasagrupadas.first().key coordenadasrua.key == coordenadasruasagrupadas.last().key) { ProcessarPrimeiraEUltimaCoordenadaRua(ruasCustoGeradas, coordenadasrua, coordenadasruasagrupadas); } continue; Cruzamento cruzamentoinicio = BuscarCruzamentoIncial(coordenadasRua.First()); if (cruzamentoinicio.id > 0) { ProcessarCoordenadasRuaAPartirDeCruzamentoInicial( cruzamentoinicio, coordenadasrua, ruascustogeradas); } else { Cruzamento cruzamentofinal = BuscarCruzamentoFinal(coordenadasRua.Last()); if (cruzamentofinal.id > 0) { ProcessarCoordenadasRuaAPartirDeCruzamentoFinal( cruzamentofinal, coordenadasrua, ruascustogeradas); } else { ProcessarCoordenadasRuaSemCruzamentosInicialOuFinal( ruascustogeradas, coordenadasrua); } } } } GerarCruzamentos(ruasCustoGeradas, prcoordenadasrua); Quadro 7 Algoritmo de montagem da malha viária e geração de estatísticas Para facilitar o entendimento do algoritmo a explicação dos métodos executados foi dividida em subseções. A subseção Processamento inicial considerando uma nova base sem dados, explica os métodos ProcessarPrimeiraEUltimaCoordenadaRua (linha 17), ProcessarCoordenadasRuaSemCruzamentosInicialOuFinal (linha 44) e GerarCruzamentos (linha 49). A subseção Processamento considerando dados já coletados anteriormente, explica os métodos BuscarCruzamentoInicial (linha 24),

57 56 ProcessarCoordenadasRuaAPartirDeCruzamentoInicial (linha 28), BuscarCruzamentoFinal (linha 34) e ProcessarCoordenadasRuaAPartirDeCruzamentoFinal (linha 38) Processamento inicial considerando uma nova base sem dados Esta seção explica o processamento das coordenadas geográficas considerando que são as coordenadas do primeiro usuário a utilizar o protótipo, a explicação se dá desta forma para facilitar o entendimento do funcionamento do algoritmo. A partir do Quadro 7 (linha 7) as coordenadas são agrupadas pela rua a qual pertencem, sendo identificada antes através de geocodificação reversa como pode ser visto no diagrama de sequência na Figura 13. Depois disso é feita a iteração por cada rua, para processar individualmente as coordenadas capturadas de cada rua. Caso seja a primeira ou última rua então o método ProcessarPrimeiraEUltimaCoordenadaRua é executado para tratar separadamente estas ruas. O Quadro 8 mostra o código deste método private static void ProcessarPrimeiraEUltimaCoordenadaRua(List<SecaoRua> ruascustogeradas, IGrouping<int, CoordenadaRua> coordenadasrua, IEnumerable<IGrouping<int, CoordenadaRua>> coordenadasruasagrupadas) { bool podesalvarsecaorua = false; List<SecaoRua> secaoruasencontradas = LerDados.LerSecaoRuasByIDRua(coordenadasRua.Key); 0)) if ((secaoruasencontradas!= null) && (secaoruasencontradas.count > { if (coordenadasrua.key == coordenadasruasagrupadas.first().key) {...Caso for a primeira rua } else {...Caso for a última rua } } else podesalvarsecaorua = true;... Salva a seção de rua caso habilitado } Quadro 8 Código do método ProcessarPrimeiraEUltimaCoordenadaRua Este tratamento é necessário, pois estas ruas não terão suas estatísticas apuradas porque não fazem parte de uma seção de rua válida. Para uma seção de rua ser considerada válida

58 57 deve ser possível determinar sua origem e seu destino através de coordenadas geográficas definidas em um cruzamento, em outras palavras isto significa que uma seção de rua sempre deve fazer fronteira com outras duas seções de rua para pode determinar a sua origem e o seu destino. A Figura 18 mostra uma simples coleta de dados passando por apenas três ruas. Os pontos em azul são as coordenadas geográficas coletadas. Figura 18 Demonstração da eliminação da primeira e última rua Neste exemplo o percurso é iniciado na Rua Rio de Janeiro e termina na Rua Almirante Barroso. Com base nesses dados não é possível determinar o correto tamanho da Rua Rio de Janeiro e nem da Rua Almirante Barroso sendo assim não é possível considerar estas ruas no cálculo de estatísticas. Porém, a primeira e a última rua são de suma importância para a criação dos cruzamentos. No exemplo dado acima também não é possível determinar o tamanho total da

59 58 Rua Engenheiro Paul Werner, porém é possível determinar o tamanho da seção de Rua Engenheiro Paul Werner que tem origem no cruzamento com a Rua Rio de Janeiro e destino no cruzamento com Rua Almirante Barroso. Uma seção de rua corresponde a um segmento de via compreendido entre dois cruzamentos em sequência deste com outras ruas que a cruzam ou interceptam. A criação de cruzamentos entre estas ruas cria uma ligação entre elas, e permite depois que o algoritmo de busca de menor caminho saiba que é possível chegar da Rua Rio de Janeiro até a Rua Almirante Barroso se utilizando da Rua Engenheiro Paul Werner. Continuando com o algoritmo principal CalcularEstatisticaRuas tendo passado pela primeira rua o processamento do método prossegue e a seguir nas linhas 27 e 35 tenta-se encontrar algum cruzamento inicial ou final baseando-se na primeira ou na última coordenada da rua respectivamente. Tratando-se deste exemplo aonde o processamento atual se dá em um ambiente que ainda não tem nenhuma informação referente a malha viária em sua base, estes métodos não retornarão informação de cruzamentos, esta parte será mais bem explicada nas seções seguintes, antes é necessário explicar como a malha viária inicial é criada. Então não foram encontrados cruzamentos iniciais e nem finais, pois a base de dados está vazia, logo o processamento executa o método ProcessarCoordenadasRuaSemCruzamentosInicialOuFinal que é mostrado pelo Quadro 9 e que tem um simples objetivo, o de através de todas as coordenadas geográficas que esta rua representa calcular o seu tamanho total, e também o tempo total que foi necessário para se percorrer da coordenada geográfica inicial até a coordenada geográfica final, isto pode ser visto na (linha 7) aonde as estatísticas são calculadas. Tendo executado este cálculo cria-se um objeto do tipo SecaoRua (linha 9) e preenche-se o valor da estatística calculada, no caso a velocidade média na propriedade VelocidadeMedia e a distância desta seção na propriedade Distancia, este objeto é inserido em uma lista e também salvo no banco de dados como pode ser visto na linha 16.

60 private static void ProcessarCoordenadasRuaSemCruzamentosInicialOuFinal(List<SecaoRua> ruascustogeradas,igrouping<int, CoordenadaRua> coordenadasrua) { double distanciasomada = 0; double custo = GerarEstatisticasCoordenadasRua( coordenadasrua.tolist(), out distanciasomada); var secaorua = new SecaoRua { Rua = new Rua { ID = coordenadasrua.key }, VelocidadeMedia = custo, Distancia = distanciasomada }; SalvarDados.SalvarSecaoRua(secaoRua); AtualizarCoordenadasRuaComSecaoRuaGerada(coordenadasRua.ToList(), secaorua); } ruascustogeradas.add(secaorua); Quadro 9 Código do método ProcessarCoordenadasRuaSemCruzamentosInicialOuFinal Com o algoritmo passado por todas as ruas inclusive a última, o resultado será uma lista contendo todas as ruas que foram percorridas com sua informação de distância e tempo total de percurso calculada (exceto para primeira e última rua), restando apenas realizar a ligação entre estas ruas através dos cruzamentos. No Quadro 7 (linha 49) o método GerarCruzamentos é executado e tem a responsabilidade de criar os cruzamentos entre as ruas. Como a lista de ruas geradas está na mesma ordem em que estas foram percorridas, isto torna-se uma tarefa fácil. O cruzamento gerado deve conter uma informação de localização que é obtida através da primeira coordenada geográfica da rua. Este foi o processamento de um caminho que não havia sido percorrido anteriormente, portanto não teve a influência dos dados que já estavam salvos. Mas é comum que usuários percorram as mesmas ruas, os mesmos trajetos em determinados trechos e nestas condições novos cruzamentos podem surgir e novas estatísticas devem ser calculadas Processamento considerando dados já coletados anteriormente Esta seção explica o processamento das coordenadas geográficas considerando que o protótipo já tenha dados de algumas ruas da cidade. O objetivo desta seção é mostrar como o protótipo atualiza a malha viária de acordo com a utilização do mesmo por novos usuários. É sobre a condição de o protótipo já ter dados salvos de outros usuários que percorreram determinadas ruas que os métodos BuscarCruzamentoIncial e

61 60 BuscarCruzamentoFinal retornaram informações. A Figura 18 mostrou o percurso efetuado por um usuário e processado pelo protótipo, caso outro usuário venha a fazer o percurso mostrado na Figura 19, que se inicia na Rua Engenheiro Paul Werner, passa pela Rua Almirante Barroso e termina na Rua Gustavo Salinger, no momento do processamento da Rua Almirante Barroso um cruzamento inicial será encontrado pelo método BuscarCruzamentoiInicial, este cruzamento representa a intersecção entre a seção de rua Engenheiro Paul Werner e Almirante Barroso, e foi salvo no processamento do usuário anterior. Esta é uma situação diferenciada aonde se sabe que este trecho já foi percorrido e então um tratamento diferenciado é necessário, sendo explicado na subseção Figura 19 Percorrendo a rua Almirante Barroso que foi já processada Da mesma forma ocorre se outro usuário percorresse o caminho mostrado pela Figura 20, passando pela Rua São Paulo, depois pela Rua Rio de Janeiro e em seguida pela Rua Engenheiro Paul Werner, nesta situação também é observada a condição de que já há informações salvas para a seção de Rua Rio de Janeiro. Sendo assim, ao processar a Rua Rio de Janeiro deste outro usuário, o método BuscarCruzamentoFinal encontrará o cruzamento entre as ruas Rio de Janeiro e Engenheiro Paul Werner, pois este trecho já foi percorrido anteriormente, caracterizando novamente a necessidade de um tratamento diferenciado que é

62 61 explicado pela subseção Figura 20 Percorrendo a rua Rio de Janeiro que já foi processada Encontrando um cruzamento inicial Ao processar uma rua está já pode ter sido percorrida por outro usuário anteriormente, para saber se esta rua já foi percorrida anteriormente tenta-se encontrar um cruzamento inicial a partir da primeira coordenada desta rua através do método BuscarCruzamentoIncial mostrado pelo Quadro 10. O cruzamento inicial será o cruzamento de origem de qualquer seção de rua que seja da mesma rua a qual se está processando e que esteja a no mínimo 35 metros de distância da primeira coordenada da rua processada, nestas condições havendo mais de um cruzamento será considerado o que mais se aproximar.

63 private static Cruzamento BuscarCruzamentoIncial(CoordenadaRua prcoordenadasrua) { var latitude = prcoordenadasrua.latitude; var longitude = prcoordenadasrua.longitude; var rua = prcoordenadasrua.rua.id; var cruzamentomaisproximo = LerDados.LerCruzamentoOrigemMaisProximo( latitude, longitude, rua); } return cruzamentomaisproximo; Quadro 10 Código do método BuscarCruzamentoInicial Encontrando um cruzamento inicial significa que o usuário percorreu a mesma seção de rua que já foi percorrida por outro usuário anteriormente. Sendo assim o método ProcessarCoordenadasRuaAPartirDeCruzamentoInicial é executado e mostrado através do Quadro private static void ProcessarCoordenadasRuaAPartirDeCruzamentoInicial(Cruzamento cruzamentoinicio, IGrouping<int, CoordenadaRua> coordenadasrua, List<SecaoRua> ruascustogeradas) { var distanciatotal = CalculoCoordenadas.DistanciaTotal( coordenadasrua.tolist()); var secaorua = LerDados.LerSecaoRuaByRuaECruzamentoOrigem( coordenadasrua.key, cruzamentoinicio.id); if (secaorua.distancia == 0) {... Encontrou uma seção de rua parcial então atualiza os dados } else if (((secaorua.distancia - 10) < distanciatotal) && (secaorua.distancia + 10) > distanciatotal) {... Trata-se da mesma seção de rua então apenas atualiza as estatísticas } else if (distanciatotal > secaorua.distancia) {... A rua foi percorrida alem das informações já mapeadas } else {... A rua foi percorrida até um cruzamento anterior a rua mapeada } } Quadro 11 Código do método ProcessarCoordenadasRuaAPartirDeCruzamentoInicial Este método tem a responsabilidade de atualizar esta seção de rua com base nestas informações de coordenadas geográficas mais atuais. Porém, nem sempre um usuário irá percorrer a via da mesma maneira que o usuário anterior a percorreu, ele pode ter entrado em uma rua antes ou depois do usuário anterior. Pode ocorrer ainda que a rua em que o usuário anterior percorreu ser uma rua sem estatística porque era uma via final do trecho percorrido. Sendo assim, este método além de atualizar estas estatísticas pode subdividir esta seção de

64 63 rua, ou ainda, acrescentar uma nova seção de rua ao seu final. O método ProcessarCoordenadasRuaAPartirDeCruzamentoInicial identifica e trata os seguintes casos: a) Situação 1 O usuário percorre de maneira completa, de um cruzamento de origem até um cruzamento de destino uma rua que antes apenas havia sido percorrida de maneira parcial (o caso da rua final explicado anteriormente pela Figura 18). Na linha 10 é identificada a seção de rua que tem o cruzamento de origem, então verifica-se na linha 13 se esta seção possui uma distância, caso não possuir distância então significa que trata-se de uma seção de rua sem estatísticas e este caso é explicado na subseção b) Situação 2 O usuário percorre a mesma seção de rua que já foi percorrida e mapeada por outro usuário. Nas linhas 17 e 18 é feita a comparação para verificar se a distância percorrida atualmente está 10 metros a mais ou a menos diferente da seção de rua salva. Caso estiver dentro deste intervalo então significa que o usuário passou pela mesma seção de rua que outro usuário antes havia passado e então mapeada esta seção. Neste caso a atualização das estatísticas desta seção de rua é feita com base nas coordenadas geográficas atuais. c) Situação 3 O usuário percorre uma rua já salva além do seu limite, esta situação ocorre quando o usuário inicial não percorre a rua até o seu final entrando em alguma outra rua, e depois um usuário secundário percorre esta rua além deste cruzamento. Caso não for nenhuma das situações anteriores, a distância percorrida atualmente é comparada a distância da seção de rua encontrada conforme pode ser visto na linha 23, se a distância atual percorrida for maior, a situação 3 é identificada e é explicada na subseção d) Situação 4 O usuário entrar em uma outra rua antes de percorrê-la até o final a rua que já havia sido percorrida antes. Não sendo atendidas nenhumas das condições das situações anteriores a situação 4 é assim identificada (linha 29) e é explicada na subseção Situação 1 O usuário percorrer em totalidade uma rua que antes apenas havia sido percorrida de maneira parcial Tomando como exemplo a Figura 18, aonde o primeiro usuário percorre as Ruas Rio de Janeiro, Engenheiro Paul Werner e Almirante Barroso respectivamente. Neste caso apenas a Rua Engenheiro Paul Werner terá estatísticas, as outras ruas não foram percorridas a partir

65 64 de um cruzamento de origem até um cruzamento de destino logo serão ruas sem informações de estatísticas. Outro usuário percorre o trajeto ilustrado pela Figura 19, passando pelas Ruas Engenheiro Paul Werner, Almirante Barroso e Gustavo Salinger. Quando o algoritmo executar a linha 10 que visa identificar a seção de rua que tem o cruzamento de origem como sendo o cruzamento mais próximo da primeira coordenada atualmente percorrida a seção de rua representada pela Rua Almirante Barroso será retornada, porém o primeiro usuário não a percorreu em totalidade e logo na linha 13 ao verificar a sua distância o seu valor será zero. Neste caso, o que o algoritmo faz é atualizar as estatísticas desta seção de rua já que agora ela foi percorrida de um cruzamento de origem (Rua Engenheiro Paul Werner) até um cruzamento de destino (Rua Gustavo Salinger), e então esta seção de rua é adicionada a uma lista para que se possa gerar o seu cruzamento de destino como sendo o da próxima rua na sequência, neste caso a Rua Gustavo Salinger. Neste exemplo observa-se ainda a geração de outra rua sem estatísticas que é a Rua Gustavo Salinger, observa-se a importância dela em determinar que esta possua um cruzamento com a Rua Almirante Barroso, assim caso um terceiro usuário venha a percorrê-la de forma total, é possível calcular as suas estatísticas assim como ocorreu com a Rua Almirante Barroso Situação 3 O usuário percorrer uma rua já salva além do seu limite Se a distância da seção de rua encontrada não for igual a zero então significa que esta seção de rua que possui estatísticas, então a distância atual percorrida é comparada com a distância desta seção de rua na linha 23 e se a distância atual for maior, significa que o usuário atual percorreu esta rua além do trajeto percorrido pelo usuário anterior. Neste caso deve-se atualizar as estatísticas desta seção de rua somente até o cruzamento de destino, ou seja, as estatísticas deverão ser calculadas sobre as coordenadas geográficas atuais coletadas porém somente até a coordenada geográfica que se aproximar mais do cruzamento de destino e não o transpor. Tendo então estas estatísticas atualizadas uma nova seção de rua é gerada contendo o seu cruzamento de origem como sendo o cruzamento de destino da seção de rua percorrida pelo usuário anterior. Logo as estatísticas desta seção de rua somente podem ser calculadas com coordenada geográficas coletadas a partir deste cruzamento. A Figura 21 ilustra o primeiro usuário percorrendo a Rua Almirante Barroso em seguida a Rua Engenheiro Paul Werner e depois a Rua Clara Persuhn, e seu trajeto é

66 65 representado pela cor azul. Figura 21 Trajeto do primeiro usuário A Figura 22 ilustra um segundo usuário percorrendo a Rua Almirante Barroso, em seguida a Rua Engenheiro Paul Werner e depois a Rua São Paulo, e seu trajeto é representado pela cor verde.

67 66 Figura 22 Trajeto do segundo usuário Nas Figuras 21 e 22 os pontos pretos representam os cruzamentos entre as ruas. A Figura 23 representa o processamento das coordenadas geográficas do segundo usuário levando em consideração os dados do usuário anterior.

68 67 Figura 23 Resultado do processamento das coordenadas geográficas do segundo usuário Observa-se então nesta figura que a seção da Rua Engenheiro Paul Werner percorrida anteriormente pelo primeiro usuário teve suas estatísticas atualizadas e no seu cruzamento de destino, que é o cruzamento com a Rua Clara Persuhn teve uma nova seção de rua adicionada cujo cruzamento de destino é o cruzamento de origem da Rua São Paulo. Nesta figura ainda é possível observar a predominância da cor verde sobre a cor azul, demonstrando que as estatísticas do primeiro usuário em cor azul foram atualizadas pelas do segundo usuário em cor verde, exceto pela Rua Clara Persuhn que não foi percorrida pelo segundo usuário Situação 4 O usuário entrar em outra rua antes de percorrê-la até o final a rua que já havia sido percorrida antes Porém se a distância percorrida atualmente for menor que a distância da seção rua do

69 68 usuário anterior, significa que o usuário entrou em uma rua antes do final desta. Neste caso uma nova seção rua é gerada a partir do cruzamento de origem e seu cruzamento de destino será criado com base na última coordenada geográfica dessa rua. Este cruzamento de destino será então o cruzamento de origem da seção de rua que o usuário anterior havia percorrido. A seção de rua que já havia sido percorrida anteriormente teve seu cruzamento de origem modificado e foi diminuída, então é necessário que suas estatísticas sejam recalculadas a partir deste cruzamento, isto só é possível porque as coordenadas geográficas que geraram cada seção de rua são salvas e podem ser recuperadas nesta situação, para a partir do cruzamento de origem encontrar a coordenada geográfica que mais se aproxime e a partir desta até a última coordenada geográfica desta seção de rua as suas estatísticas podem ser recalculadas. Este caso é inverso ao caso anterior e pode ser representado utilizando-se das mesmas figuras, porém de forma invertida aonde na Figura 24 observa-se o primeiro usuário percorrendo as ruas Almirante Barroso, Engenheiro Paul Werner e São Paulo, e seu trajeto é representado pela cor verde.

70 69 Figura 24 Trajeto do primeiro usuário E na Figura 25, o segundo usuário percorre a Rua Almirante Barroso, em seguida a Rua Engenheiro Paul Werner e depois a Rua São Paulo, e seu trajeto é representado pela cor Azul.

71 70 Figura 25 Trajeto percorrido pelo segundo usuário A Figura 26 representa o processamento das coordenadas geográficas do segundo usuário levando em consideração os dados do usuário anterior.

72 71 Figura 26 Resultado do processamento das coordenada geográficas do segundo usuário O resultado do processamento é a divisão da seção de rua que representava a Rua Engenheiro Paul Werner aonde a primeira seção terá suas estatísticas recalculadas baseadas nas condições de tráfego enfrentadas pelo segundo usuário representadas pela cor azul. Já a seção posterior da Rua Engenheiro Paul Werner também deve ter suas estatísticas atualizadas, pois ela foi encurtada, antes tinha seus limites como sendo os cruzamentos da Rua Almirante Barroso e São Paulo, porém agora seu cruzamento de origem é com a sua própria seção de rua devido a adição deste cruzamento com a Rua Clara Persuhn. Observe que ainda não é possível determinar se a Rua Clara Persuhn tem uma saída para Rua Engenheiro Paul Werner, por isso não é possível determinar que a segunda parte da seção da Rua Engenheiro Paul Werner faz cruzamento com ela, pois não tem um cruzamento aonde a seção de rua de origem é a Rua Clara Persuhn e a seção rua de destino é a Rua

73 72 Engenheiro Paul Werner Encontrando um cruzamento final Se um cruzamento inicial não for encontrado tenta-se então buscar um cruzamento final. A busca pelo cruzamento final ocorre a partir da última coordenada desta rua através do método BuscarCruzamentoFinal que pode ser visto no Quadro 12. O cruzamento final será o cruzamento de destino de qualquer seção de rua que seja da mesma rua a qual se está processando e que esteja a no mínimo 35 metros de distância da última coordenada da rua processada, nestas condições havendo mais de um cruzamento será considerado o que mais se aproximar. A distância mínima de 35 metros para buscar os cruzamentos foi definida verificando a natural diferença entre a coleta de dados geográficos de dois usuários diferentes. A identificação de um cruzamento ocorre quando a rua pela qual se estava percorrendo muda, ficando assim registrada no cruzamento a primeira coordenada geográfica da rua que mudou. Desta forma é possível encontrar este cruzamento novamente e garantir que um determinado usuário percorreu a mesma seção de rua que outro usuário private static Cruzamento BuscarCruzamentoFinal(CoordenadaRua prcoordenadasrua) { var latitude = prcoordenadasrua.latitude; var longitude = prcoordenadasrua.longitude; var rua = prcoordenadasrua.rua.id; var cruzamentomaisproximo =LerDados.LerCruzamentoDestinoMaisProximo( latitude, longitude, rua); } return cruzamentomaisproximo; Quadro 12 Código do método BuscarCruzamentoFinal Encontrando um cruzamento final significa que o usuário percorreu a mesma seção de rua que já foi percorrida por outro usuário anteriormente conforme foi mostrado na introdução desta seção pela Figura 20. Sendo assim o método ProcessarCoordenadasRuaAPartirDeCruzamentoFinal é executado e mostrado através do Quadro 13.

74 private static void ProcessarCoordenadasRuaAPartirDeCruzamentoFinal(Cruzamento cruzamentofinal, IGrouping<int, CoordenadaRua> coordenadasrua, List<SecaoRua> ruascustogeradas) { var secaorua = LerDados.LerSecaoRuaByRuaECruzamentoDestino( coordenadasrua.key, cruzamentofinal.id); if (secaorua.distancia > 0) {...Atualiza a seção de rua adicionando um novo cruzamento } else { double distanciasomada = 0; double custo = GerarEstatisticasCoordenadasRua( coordenadasrua.tolist(), out distanciasomada); secaorua.distancia = distanciasomada; secaorua.velocidademedia = custo; SalvarDados.AtualizarSecaoRua(secaoRua); SalvarDados.LimparSecaoRuaDasCoordenadasRua(secaoRua.ID); AtualizarCoordenadasRuaComSecaoRuaGerada( coordenadasrua.tolist(), secaorua); } } ruascustogeradas.add(secaorua); Quadro 13 Código do método ProcessarCoordenadasRuaAPartirDeCruzamentoFinal Este método tem a responsabilidade de atualizar esta seção de rua com base nas informações de coordenadas geográficas mais atuais. Como anteriormente não foi encontrado um cruzamento inicial e agora foi encontrado um cruzamento final, a seção de rua a qual pertence este cruzamento não possui um cruzamento de origem, ou seja, é uma seção de rua sem estatísticas que apenas foi incluída para gerar o cruzamento com as próximas ruas assim como foi explicado na seção Neste caso sua estatística é atualizada baseando-se nas coordenadas geográficas do usuário atual, esta seção de rua também é incluída em uma lista para que depois o seu cruzamento de origem possa ser referenciado Representação das ruas percorridas através de um grafo A modelagem dos dados coletados depois de georreferenciados submete a representação da malha viária percorrida como sendo um grafo. As ruas e suas seções representam as arestas e os cruzamentos são representados através de vértices.

75 74 A classe SecaoRua possui as propriedades CruzamentoOrigem e CruzamentoDestino que definem a direção de tráfego e consequentemente a direção da aresta, tornando assim o grafo dirigido. Através da Figura 27 é possível verificar um trecho percorrido e ao lado após o processamento efetuado pelo web service o grafo gerado com as ruas e cruzamentos representado o caminho efetuado. Figura 27 Representação do grafo gerado através da coleta de coordenadas geográficas A representação das ruas percorridas através de um grafo possibilita a utilização de técnicas e algoritmos conhecidos na área de grafos, o que facilita a resolução do problema que consiste em encontrar a rota de menor custo Obtendo a rota de menor custo O Quadro 14 apresenta o código responsável pela implementação do algoritmo de Dijkstra no servidor.

76 private static void DijkstraRecursivo(List<VerticeCalculo> prgrafo, VerticeCalculo prverticeraiz) { var verticesadjacentes = new List<VerticeCalculo>(); foreach (var verticedografo in prgrafo.where( vert => vert.perm == false)) { foreach (var arresta in prverticeraiz.vertice.arrestas) { if (arresta.destino == verticedografo.vertice) verticesadjacentes.add(verticedografo); } } foreach (var verticeadjacente in verticesadjacentes) { double custo = prverticeraiz.tempo + prverticeraiz.vertice.arrestas.single( ar => ar.destino == verticeadjacente.vertice).tempo; } if (verticeadjacente.tempo > custo) { verticeadjacente.tempo = custo; verticeadjacente.path = prverticeraiz; } if (prgrafo.count(vert =>!vert.perm) > 0) { var menortempo = prgrafo.where(ve =>!ve.perm).min( v => v.tempo); var menor = prgrafo.first(vert => (!vert.perm) && (vert.tempo == menortempo)); } } menor.perm = true; if (prgrafo.count(vert =>!vert.perm) > 0) DijkstraRecursivo(prGrafo, menor); Quadro 14 Implementação do algoritmo de Dijkstra Inicialmente se obtém uma lista de vértices adjacentes ao vértice raiz passado como parâmetro a partir da linha 9, um vértice é considerado adjacente ao vértice raiz se alguma aresta do vértice raiz faz ligação com um vértice que ainda não foi processado que é controlado pela propriedade Perm. Após encontrar os vértices adjacentes, no bloco de código compreendido entre as linhas 16 e 27 para cada vértice adjacente é necessário calcular o seu custo, que neste caso é determinado pelo tempo que se levou para percorrer a aresta. Este tempo é obtido através do cálculo divisão da distância pela velocidade média que é abstraído pela propriedade Tempo da classe VerticeCalculo. A linha 22 verifica se o tempo do vértice adjacente é maior que o tempo para percorrer da raiz até o vértice adjacente, então o tempo do vértice adjacente é atualizado e o seu caminho Path é definido como sendo o vértice raiz. Na linha 29 é verificado se ainda possuem vértices a processar, e então na linha 31

77 76 dentre os vértices adjacentes que não estão marcados como Perm onde Perm representa todos os vértices para os quais já foram determinados os menores caminhos, busca-se o que tem o menor custo e este é marcado como pertencente a Perm na linha 33. Novamente na linha 38 é verificado se o grafo ainda possui vértices não processados, caso afirmativo então um novo processamento se inicia na linha 39 passando como parâmetros o grafo e o vértice que representa a escolha do caminho de menor custo. Caso não tenha mais vértices a processar o algoritmo se encerra Operacionalidade da implementação A operacionalidade do protótipo executado no dispositivo móvel do usuário é mostrada nesta seção. A Figura 28 mostra a tela inicial do protótipo com a possibilidade de escolha da função de coleta de dados ou busca da rota. Figura 28 Tela inicial do protótipo

78 Coleta de dados A coleta de dados é acessada através do botão Coleta de dados que exibe a tela mostrada pela Figura 29. Figura 29 Tela de coleta de coordenadas geográficas Nesta tela é apresentado ao usuário a velocidade atual em km/h (quilômetros por hora), a precisão do GPS em metros, uma lista com as últimas 10 coordenadas capturadas e um botão para o envio das coordenadas capturadas para o servidor, no caso web service. Ao acessar esta tela inicia-se o processo de coleta das coordenadas geográficas, cada coordenada assim coletada é salva em um banco de dados interno da aplicação. Para uma melhor precisão na construção da malha viária, apenas coordenadas com precisão menor ou igual a 15 metros são consideradas. Antes de enviar as coordenadas ao web service é necessário configurar o endereço do servidor pressionando no dispositivo o botão menu do dispositivo móvel e então selecionado a opção Configurações conforme mostrado pela Figura 30.

79 78 Figura 30 Acesso a opção de configurações Ao acessar a opção de configurações pode-se então informar o endereço da Uniform Resource Locator (URL) do web service conforme é mostrado na Figura 31.

80 79 Figura 31 Configuração da URL do web service Após coletadas as coordenadas geográficas e definida a configuração de endereço URL do web service o envio dos dados para o servidor pode ser feito através do botão Enviar coordenadas ao servidor, estes dados serão então enviados para o servidor e serão utilizados para construção e complementação da malha viária Busca da rota de menor custo A busca da rota de menor custo é acessada a partir da tela inicial através do botão Calcular rota que exibe a tela mostrada pela Figura 32.

81 80 Figura 32 Tela de busca da rota de menor custo A tela para busca da rota de menor custo possui um campo para informar uma coordenada geográfica de origem, outro campo para informar uma coordenada geográfica de destino, um botão para executar o cálculo e um mapa para poder selecionar os pontos de origem e destino manualmente, o que é mais trivial. Ao tocar em qualquer local do mapa dois botões são exibidos para determinar se este ponto é referente a origem ou destino do trecho que se deseja obter a rota de menor custo. A exibição destes botões pode ser conferida na Figura 33.

82 81 Figura 33 Botões para informar ponto de origem ou destino Ao pressionar o botão Origem um ponto de cor azul é adicionado ao mapa no exato local em que foi pressionado e a coordenada geográfica referente a este ponto é informada no campo origem. Semelhante ao botão Origem o botão Destino insere um ponto vermelho ao mapa no exato local em que foi pressionado, a coordenada geográfica correspondente a este ponto é informada no campo destino. A marcação dos pontos em azul e vermelho pelos botões pode ser vista na Figura 34.

83 82 Figura 34 Ponto de origem e destino Após informar o ponto de origem e destino a rota de menor custo pode ser calculada através do botão Calcular rota, a ação do botão é enviar as coordenadas de origem e de destino para o servidor que irá processar a rota de menor custo baseando-se nos dados geográficos coletados como explicado na seção sendo que estes dados podem também ser enviados por outros usuários de maneira colaborativa. A Figura 35 mostra o resultado da busca da rota de menor custo contendo uma lista de ruas as quais, baseadas nas estatísticas, têm o tempo de percurso mais rápido para chegar da origem ao destino solicitados.

84 83 Figura 35 Resultado do cálculo da rota de menor custo 3.4 RESULTADOS E DISCUSSÃO Nesta seção são feitos testes para comprovar o funcionamento da coleta de dados geográficos e da busca do caminho de menor custo. Esta seção foi então separada em três subseções, na seção é descrito como foram feitos os testes em ambiente controlado e os resultados obtidos, na seção é descrito como foram feitos os testes em ambiente real e os resultados obtidos e na seção o trabalho atual é confrontado com os trabalhos correlatos.

85 Testes realizados com dados hipotéticos O objetivo deste teste é simular as condições de tráfego a fim de validar a coleta de dados geográficos e a busca pelo caminho de menor custo. Para o teste da coleta de dados foi simulado o percurso que um usuário normal faria, inserindo manualmente estas coordenadas na base de dados do aplicativo servidor. Foram definidos uma origem e um destino e então duas rotas traçadas com diferença entre as ruas utilizadas, visando simular dois usuários diferentes percorrendo estes caminhos. A primeira rota pode ser vista abaixo na Figura 36, sua distância total aproximada é de 5060 metros em uma velocidade média de 30 km/h, o que resulta em um tempo aproximado de locomoção de 10 minutos e 6 segundos.

86 85 Figura 36 Trecho percorrido via Av. Presidente Castelo Branco representando a primeira rota Após realizar a coleta das coordenadas geográficas as mesmas foram inseridas manualmente no banco de dados do aplicativo servidor, simulando o recebimento destas pelo web service através de algum dispositivo. Com as coordenadas coletadas e inseridas na base foi executado o algoritmo de processamento das coordenadas para gerar a malha viária e as estatísticas das ruas, o resultado pode ser visto na Tabela 1.

87 86 Tabela 1 Resultado do processamento das coordenadas geográficas coletadas do primeiro trecho Id da seção Rua Velocidade média da Distância da seção Id do cruzamento Id do cruzamento de destino seção de rua de rua de origem 845 R. Itapema R. Itajaí 10, , R. Quinze de Novembro 9,06 244, Av. Pres. Castelo Branco 8,3 1418, Av. Martin Luther 9,26 888, R. Abacateiro 9,85 640, R. Papanduva 2, R. São Paulo 5,89 447, R. Antônio da Veiga A Tabela 1 representa a concepção da malha viária vista através dos dados salvos no servidor. Os dados estão listados por seção de rua, mostrando o identificador único da seção de rua, o nome da rua a qual a seção de rua faz parte, a velocidade média da seção de rua em m/s (metros por segundo), a distância da seção de rua em metros e os identificadores dos cruzamentos de origem e destino da seção de rua. Observando a Tabela 1, os nomes das ruas traduzidos no processamento das coordenadas geográficas, é possível ver através da Figura 36 que a tradução ocorreu corretamente, conforme os nomes são demonstrados. O caminho efetuado nos testes da segunda rota pode ser visto na Figura 37, sendo a distância total aproximada desta rota de 7621 metros, a uma velocidade média de 40 km/h com um tempo aproximado de 11 minutos e 24 segundos.

88 87 Figura 37 Trecho percorrido via rua das Missões representando a segunda rota Da mesma forma como ocorreu com o primeiro trecho, os dados geográficos da coleta são inseridos manualmente no banco de dados do aplicativo servidor. E então novamente o algoritmo de processamento das coordenadas para gerar a malha viária e estatística das ruas é executado, aonde seu resultado pode ser visto na Tabela 2.

89 88 Tabela 2 Resultado do processamento das coordenadas geográficas coletadas do segundo trecho Id da seção Rua Velocidade média da Distância da seção Id do cruzamento Id do cruzamento de destino seção de rua de rua de origem 845 R. Itapema R. Itajaí 11,07 830, R. Quinze de Novembro 9,06 244, Av. Pres. Castelo Branco 8,3 1418, Av. Martin Luther 9,26 888, R. Abacateiro 9,85 640, R. Papanduva 2, R. São Paulo 3,81 91, R. Antônio da Veiga R. Itajaí 7,79 179, Ponte dos Arcos 8,92 205, R. República Argentina 11,88 546, R. Paraguay 8, R. Bolívia 5,78 52, Acesso para Av Brasil 5,32 47, Av. Brasil 13,45 309, R. das Missões 18, , R. Dois de Setembro 11,8 1593, R. Gustavo Kirsten 3,99 11, Acesso para R Gustavo 6 120, Kirsten 865 Via Paul Fritz Kuehnrich 6,83 648, R. Trinta de Outubro 5,63 50, Acesso para Via Paul Fritz 5,63 67, Kuehnrich 868 R. Iguaçu 10,2 234, R. Eng. Paul Werner 7,95 254, R. São Paulo 11,06 342, Observando a Figura 36 e Figura 37 é possível verificar que na simulação de percurso dos trechos existem ruas em comum, sendo elas a Rua São Paulo e Rua Antônio da Veiga. Relacionando a Tabela 2 com a Tabela 1, é possível constatar que a seção de rua de identificador 852 teve o seu cruzamento de destino trocado de 620 para 622. Isto significa que antes esta seção de rua fazia cruzamento com a Rua Antônio da Veiga e agora faz cruzamento com a seção de Rua de identificador 870, que representa a mesma rua, porém, é um trecho diferente. A troca do cruzamento de destino da seção de rua de identificador 852 ocorreu, pois o algoritmo identificou que houve a passagem por um trajeto em comum, porém a origem deste trajeto era diferente, neste caso originou a criação de mais um cruzamento que é identificado pela Figura 38.

90 89 Figura 38 Demonstração da geração de um novo cruzamento Tendo os dados geográficos destas duas rotas coletados e processados é possível fazer um teste da busca da rota de menor custo pelo dispositivo móvel. A Figura 39 abaixo mostra os passos do teste efetuado e o resultado, definindo um ponto de origem na Rua Itajaí, um ponto de destino na Rua São Paulo próximo à esquina da Rua Antônio da Veiga e após calcular a rota de menor custo o resultado é exibido. Figura 39 Definindo o ponto de origem e destino e obtendo a rota de menor custo A busca da rota de menor custo obteve então o resultado com o trecho passando pelas ruas Itajaí, Quinze de Novembro, Presidente Castelo Branco, Martin Luther, Abacateiro, Papanduva e São Paulo. Observa-se que esta rota é a primeira rota mostrada pela Figura 36 e

91 90 que corresponde a rota que tem o menor tempo de percurso sendo 10 minutos e 6 segundos contra 11 minutos e 24 segundos da segunda rota. Visando comprovar o funcionamento do algoritmo em caso de atualizações por outros usuários uma nova coleta de dados foi feita simulando tráfego de veículos intenso na Avenida Presidente Castelo Branco e Avenida Martin Luther, sendo assim o trajeto mostrado pela Figura 40 foi percorrido em uma velocidade média de 20 km/h. Figura 40 Demonstração de tráfego de veículos intenso representado pela cor vermelha Após efetuada a coleta dos dados geográficos os mesmos foram processados pelo algoritmo que gera e atualiza as estatísticas da malha viária. A Rua Quinze de Novembro e a Rua Abacateiro são ruas iniciais e finais respectivamente, portanto não tem suas estatísticas atualizadas. Na tabela 3 é mostrada as estatísticas das Avenidas Presidente Castelo Branco e Martin Luther atualizadas.

92 91 Id da seção Tabela 3 Resultado do processamento das coordenadas geográficas simulando tráfego intenso Rua Velocidade Distância Id do Id do média da seção da seção de cruzamento cruzamento de rua rua de origem de destino 848 Av. Pres. Castelo Branco 5, , Av. Martin Luther 5,85 888, Relacionando a Tabela 3 com a Tabela 2 é possível verificar que para a seção de rua que representa a Avenida Presidente Castelo Branco a velocidade média teve uma redução de 8,3 m/s para 5,24 m/s, e para seção de rua que representa Avenida Martin Luther a velocidade média teve uma redução de 9,26 m/s para 5,85 m/s. Esta redução da velocidade média resulta em um aumento do tempo de percurso da primeira rota em 2 minutos e 34 segundos, fazendo com que a segunda rota se torne então a rota com o menor tempo de percurso com 11 minutos e 24 segundos contra 12 minutos e 40 segundos da segunda rota. Desta forma a rota de menor custo foi novamente solicitada partindo da mesma origem e destino mostrados no teste anterior pela Figura 39 e então observa-se pela Figura 41 que a rota de menor custo retornada agora é a segunda rota. Figura 41 Resultado do cálculo da rota de menor custo indicado a segunda rota como sendo a mais viável

93 92 Com o retorno da segunda rota pelo cálculo da rota de menor custo é possível comprovar o funcionamento do protótipo baseado na atualização de coordenadas geográficas de novos usuários e do algoritmo de geração e atualização da malha viária, e de Dijkstra Testes realizados em ambiente real Esta seção demonstra como foram feitos os testes da coleta de dados geográficos pelo dispositivo móvel em um ambiente real com o objetivo de comprovar a eficácia e precisão dos dados coletados e da geração da malha viária através dos mesmos. As rotas efetuadas para coleta de dados geográficos são as mesmas rotas dos testes efetuados com dados hipotéticos. A Figura 42 mostra os pontos coletados pela passagem do usuário pela primeira rota. Figura 42 Trecho percorrido em teste efetuado em ambiente real Observando os pontos coletados e comparando com a Figura 36 é possível verificar

94 93 que em vários momentos que houve uma discrepância na determinação da coordenada, e que alguns pontos estão localizados sobre ruas que não contemplam a rota efetuada pelo usuário. Ao aproximar a Figura 42, é possível observar que alguns pontos que deveriam estar sobre a Avenida Presidente Castelo Branco, estão mais próximos da Rua Quinze de Novembro, como pode ser observado pela Figura 43. Figura 43 Diferença na coleta de dados Ao processar estas coordenadas no servidor, a identificação da rua destas coordenadas geográficas se dá de forma incorreta, mostrando que o usuário passou pela Rua Quinze de Novembro quando na verdade estava trafegado pela Avenida Presidente Castelo Branco. Investigando o problema a fim de solucioná-lo, verificou-se que os pontos foram corretamente coletados, pois ao analisar os pontos coletados em outros mapas os mesmos não apresentaram o problema. A Figura 44 mostra a análise da coordenada de latitude -26, e longitude -49, , que representam um ponto coletado pelo dispositivo do

95 94 usuário. Observa-se que na representação desta coordenada no Google Maps (Figura 44 item a) o ponto aparece próximo a Rua Quinze de Novembro, e na análise feita no Bing Mapas (Figura 44 item b) e Yahoo Mapas (Figura 44 item c) o ponto é corretamente posicionado sobre a Avenida Castelo Branco. Desta forma, conclui-se que para a cidade de Blumenau a camada de mapas do Google Maps está levemente descalibrada em relação ao mundo real. Figura 44 Demonstração da coordenada geográfica no (a) Google Maps, (b) Bing Mapas e (c) Yahoo Mapas A API de geocodificação reversa do Google usa os mapas do Google Maps como referência para retornar o endereço a partir de uma coordenada geográfica, desta forma observou-se que os testes efetuados nestas condições não teriam um resultado que representase as condições reais de trânsito pois coordenadas geográficas seriam identificadas incorretamente e desta forma apresentaria um trajeto que o usuário não percorreu. Analisando locais próximos a cidade de Blumenau, observou-se que na cidade de Gaspar o problema não ocorre, ou seja, as ruas dos mapas do Google Maps representam exatamente a rua no mundo real, desta forma optou-se por executar os testes nesta cidade. Os testes na cidade de Gaspar foram efetuados de maneira que o ponto de origem está localizado na Rua Renato M. Peixoto e o ponto de destino está localizado na Rua Anfilóquio Nunes Pires, tendo duas rotas possíveis sendo a primeira pela Rua Itajaí e a segunda pela Avenida Deputado Francisco Mastela. A Figura 45 representa os pontos coletados como sendo os do primeiro trecho percorrido.

96 95 Figura 45 Pontos coletados na primeira rota A primeira rota representada pela Figura 45 tem início na Rua Renato M. Peixoto passa pelas Ruas Itajaí, Cel. Aristiliano Ramos, Dr. Nereu Ramos e por fim a Rua Anafilóquio Nunes Pires. A segunda rota representada pela Figura 46 tem início na Renato M. Peixoto e passa pelas Ruas Itajaí, Avenida Deputado Francisco Mastela, Dq. De Caixas, Avenida das Comunidades, Dr. Nereu Ramos e por fim a Rua Anafilóquio Nunes Pires. Figura 46 Pontos coletados na segunda rota Depois de ter as coordenadas geográficas coletadas das duas rotas, as mesmas foram processadas pelo servidor e o resultado deste processamento que é a malha viária pode ser visto na Tabela 4.

97 96 Tabela 4 Demonstração do resultado do processamento das coordenadas geográficas dos testes realizado em ambiente real Rua Velocidade Distância Id do Id do média da da seção cruzamento cruzamento seção de rua de rua de origem de destino Id da seção 904 R. Renato M Peixoto R. Itajaí 12, , R. Cel. Aristiliano Ramos 5,82 745, R. Dr. Nereu Ramos 11,43 479, R. Anfilóquio Nunes Pires R. Itajaí 12, , Av. Dep. Francisco Mastela 19,6 3749, R. Duque de Caxias 4,83 700, Av. das Comunidades 4,72 509, R. Dr. Nereu Ramos 11,59 486, A análise da Tabela 4 nos permite verificar que as duas rotas descritas pela Figura 45 e pela Figura 46 foram corretamente processadas gerando assim dois caminhos possíveis da Rua Renato M Peixoto até a Rua Anfilóquio Ramos Relação do trabalho atual com os trabalhos correlatos Após os resultados obtidos, reformulou-se o quadro das características dos trabalhos relacionados (Quadro 4 - seção 2.5) adicionando-se o protótipo desenvolvido, para fins de comparação com aquelas características. O Quadro 15 apresenta um panorama geral das características dos trabalhos correlatos juntamente com as características deste trabalho. Características / sistemas Schroeder (2012) Google Maps (2011) Google Maps Navigation (2011) GPS Airis (2011) Mobile Century (2008) Obtenção de rota de menor custo X - X X - Envio de informações de condições de tráfego X - X - X Visualização das condições de tráfego das vias - X X X X Malha viária construída dinamicamente X Quadro 15 Relação das características dos trabalhos correlatos e do protótipo desenvolvido O presente trabalho possui um diferencial em relação aos demais sistemas, que é construir a malha viária dinamicamente conforme os usuários utilizam o mesmo. Desta forma independe de um número mínimo necessário de usuários para poder ter uma malha viária definida.

98 97 Os sistemas mais comuns em uso hoje são o Google Maps e o Google Maps Navigation que infelizmente apenas possuem dados de grandes cidades como São Paulo, Rio de Janeiro, Curitiba e Belo Horizonte. Desta forma o presente trabalho permite que qualquer cidade possua suas ruas mapeadas e suas estatísticas geradas, deste que, pelo menos um usuário venha a percorrê-la. A característica de visualização das condições de tráfego das vias não foi considerada como uma característica fundamental para este trabalho, pois o objetivo é prover ao usuário uma rota de menor custo, visualizar a condição de tráfego da via não garante que o mesmo faça a melhor escolha da rota.

99 98 4 CONCLUSÕES O presente trabalho propôs o desenvolvimento de um protótipo capaz de enviar informações de localização de um usuário no trânsito através de um telefone celular com sistema operacional Android para um servidor que constrói a malha viária de acordo com o percurso feito pelos usuários e armazena estatísticas de condições de tráfego baseado na velocidade média dos dispositivos. Uma rota pode ser solicitada ao servidor informando um ponto de origem e um ponto de destino, e baseada nas condições de tráfego o servidor retorna a rota de menor custo para o cliente. Para os testes da coleta de dados geográficos em ambiente real foi utilizado dispositivo Samsung Galaxy S II com sistema Android versão 4.0.4, que demonstrou grande precisão nas coordenadas obtidas sendo possível determinar assim através da API de geocodificação reversa do Google a rua pela qual está se percorrendo. Apesar dos testes em ambiente real terem identificado um problema de calibragem na API de geocodificação reversa do Google, pode-se observar que este problema ocorre de acordo com o local e assim o teste pode ser direcionado a outra cidade e executado com sucesso. A implementação do algoritmo de Dijkstra no método que calcula a rota de menor custo foi utilizada e segundo os testes efetuados apresentou de maneira assertiva a rota que tem um menor gasto de tempo necessário para efetuar o seu percurso. O sistema operacional Android dispôs de informações importantes para a administração da coleta de coordenadas geográficas sem assim ter a necessidade de implementar controles externos. O protótipo pelo lado do servidor foi desenvolvido com a linguagem de programação C# e banco de dados SQL Server o que permitiu o uso de facilidades da linguagem como o recurso LINQ to SQL para implementação da comunicação entre a aplicação e o banco de dados. O desenvolvimento do presente trabalho permite que mesmo pequenas cidades possam ter informações de tráfego consideradas, e que usuários de futuros sistemas baseados neste trabalho possam se beneficiar destas informações para deslocar-se de maneira mais eficiente.

100 LIMITAÇÕES Durante o desenvolvimento do protótipo alguns problemas puderam ser verificados e são agora relacionados, tratando-se de um protótipo, este trabalho foi desenvolvido de maneira a atender os objetivos propostos. Portanto nem todas as situações esperadas na construção do grafo da malha viária são tratadas. Os testes na cidade de Blumenau apontaram para uma imprecisão na obtenção do nome das ruas pela coordenada geográfica devido a descalibragem apresentada na API de geocodificação reversa conforme foi explicado na seção Este problema poderia ser tratado utilizando-se de um vetor de orientação de deslocamento, porém não foi feito devido a não tratar-se da problemática principal deste trabalho. Na seção 4.2 de extensões este caso é abordado como uma melhoria ampliando a integração com APIs de geocodificação reversa. Ao realizar os testes em ambiente real constatou-se um problema ao deslocar-se primeiramente saindo de uma rua e adentrando em outra tomando a direção da esquerda, e depois outro usuário percorrendo o mesmo caminho, porém adentrando-se a direita, caracterizando assim a rua como mão dupla (independe da ordem dos usuários). Este problema não interferiu no desenvolvimento dos testes hipotéticos e nem dos testes reais, pois, usou-se de situações em que o mesmo não esteve presente. A Figura 47 mostra este problema em questão. Figura 47 Demonstração do trajeto percorrido por dois usuários Na Figura 47 os traços em azul representam o caminho efetuado pelo primeiro usuário