evolução da componente algorítmica de cálculo de rotas do

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Evolução da componente algorítmica decálculo de rotas do Move-Me

André Pedro Deus Pinheiro

Mestrado Integrado em Engenharia Informática e Computação

Orientador: João Paulo de Castro Canas Ferreira

24 de Julho de 2017

Evolução da componente algorítmica de cálculo de rotasdo Move-Me

André Pedro Deus Pinheiro

Mestrado Integrado em Engenharia Informática e Computação

24 de Julho de 2017

Resumo

Nos dias que correm os transportes públicos têm vindo a afirmar cada vez mais a sua im-portância no quotidiano da população, seja para evitar as filas de trânsito nas horas de ponta oupara reduzir os custos no final do mês. Surge assim a necessidade de dar uma resposta rápidae eficaz aos utentes dos transportes públicos. É neste contexto que o projeto IMS, desenvolvidopela empresa OPT S.A. foi criado. Este projeto tem como finalidade auxiliar os utentes na es-colha das rotas dentro de uma rede de transportes públicos multimodais. O projeto está divididoem módulos distintos, responsáveis por exercerem funções específicas. O objetivo deste trabalhopassa essencialmente pela sofisticação da componente algorítmica de cálculo de rotas no móduloPADA. O algoritmo atual apresenta tempos de resposta na ordem dos segundos desde o momentoem que a rede de transportes se expandiu para Lisboa. Desse modo, o principal foco deste trabalhoé determinar como se pode reduzir os tempos de resposta tendo em conta critérios que podem serdefinidos pelos utilizadores, como o tempo de chegada mais próximo ao destino final, o menortempo de partida a partir da origem, o menor número de transbordos e o tempo máximo a cami-nhar. É de realçar que o sistema já se encontra em funcionamento, pelo que as restrições atuaisdevem ser respeitadas. Este facto não invalida que a sofisticação do algoritmo atual seja um desa-fio menor já que nos últimos anos se tem investido na área dos algoritmos em redes de transportespúblicos, que culminou na invenção de novos algoritmos como o RAPTOR e o CSA que não sãobaseados em grafos e que podem ser paralelizados, capazes de correr ordens de magnitude maisrápido do que algoritmos baseados no algoritmo de Dijkstra para o caminho mais curto entre doisvértices de um grafo. Simultaneamente também se tem assistido à criação de novas técnicas deaceleração como A* com Landmarks, Arc Flags, Contração e pesquisa bidirecional, no entantotodas requerem uma fase de pré-processamento morosa e dispendiosa em termos de memória,seguida de uma fase de consulta extremamente rápida.

Para este problema, os dados fornecidos correspondem a uma estimativa da hora de chegadadas viaturas de transporte às paragens que fazem parte da rede. Através de outros módulos existen-tes no sistema é possível construir e caracterizar toda a rede de transportes. O módulo responsávelpela gestão da rede de transportes, o BITA, armazena informação relativa a todas as linhas detodos os operadores, às variantes de uma linha, à ordem das paragens de uma linha e às horas depassagem de um veículo numa paragem num determinado dia. Estes dados são cruciais para quese possam obter resultados corretos durante a fase de cálculo de rotas. A sofisticação do móduloPADA tem impacto essencialmente ao nível da experiência do utilizador, uma vez que os utentespoderão ter acesso às rotas de viagens mais convenientes de modo quase imediato.

O algoritmo escolhido foi uma adaptação do algoritmo RAPTOR uma vez que pode ser fa-cilmente paralelizado, tirando assim partido do elevado número de núcleos do servidor onde seráexecutado. Durante os testes, o desempenho do algoritmo de cálculo de rotas foi bastante sa-tisfatório, revelando-se capaz de executar, em média, 100 vezes mais rápido do que o algoritmoatualmente utilizado. Os resultados com o acesso ao tempo real foram igualmente muito satisfa-tórios.

i

Abstract

Nowadays, public transportation have been affirming more and more its importance in the day-to-day life of the general population, whether to avoid traffic queues at rush hours, or to reducecosts at the end of the month. Therefore, there is a need for a rapid and effective response to publictransport users. Is is in this context that the IMS project, developed by OPT S.A, was created.The purpose of this project is to assist choosing routes inside a multimodal public transportationnetwork. The project is divided in several modules, responsible for carrying out specific functions.With the development of this master thesis it is expected to refine the algorithmic component ofroute calculation in the PADA module. The current algorithm presents query times in the order ofseconds since the network has expanded to Lisbon. Thus, the main focus of this master thesis isto determine how the query times can be reduced, taking in account criteria that can be defined byusers, such as the closest time of arrival, numbers of transfers and the maximum walking distance.If should be noted that the system is already in operation, so the current restrictions must berespected. This fact does not invalidate that the sophistication of the algorithm will be a minorchallenge since in the last years large investments were done in the subject of algorithms on publictransportation networks, which culminated in the invention of new algorithms such as RAPTORand CSA, that are not based on graphs and can be easily parallelized, capable of running ordersof magnitude faster than previous algorithm based on Dijkstra for the calculation of shortest pathbetween two vertices of a graph. At the same time, new speed-up techniques such as A* withLandmarks, Arc Flags, Contraction and bidirectional search have been developed, however, all ofthem require a time-consuming pre-processing phase, followed by an extremely fast query phase.

For this problem, the data that is provided corresponds to an estimate of the arrival time of avehicle on a stop of the public transportation network. By accessing other modules it is possible tobuild and characterize the public transportation network. The module responsible for the networkmanagement, BITA, stores information about all the lines of all providers, the variants of a singleline, the order of the stops of a single line and the arrival times of a vehicle in a stop, on a givenday. These data is crucial in order to get the correct results during the route calculation. Thesophistication of the PADA module will impact essentially the user experience as users will haveaccess to the most convenient travel routes almost immediately.

The chosen algorithm was an adaption of RAPTOR because it can be easily parallelized, takingadvantage of the high number of cores of the server where the algorithm will be executed inproduction. During the test phase, the performance of this algorithm was quite satisfactory. It wasable to run, in average, 100 times faster than the current algorithm in production. The results withreal time access were also quite satisfactory.

iii

Agradecimentos

Esta dissertação não teria sido escrita sem o apoio de algumas pessoas pelas quais eu queroaproveitar esta página para expressar a minha gratidão. Em primeiro lugar, agradeço aos meuspais pelo apoio incondicional que me deram não só durante a realização da dissertação, mas du-rante toda a minha vida académica. Em segundo lugar quero agradecer ao Professor Doutor JoãoCanas Ferreira, o meu orientador da dissertação, pela dedicação e pela disponibilidade que sem-pre mostrou ter durante este último ano letivo. Agradeço-lhe também pelo incansável apoio queme concedeu e por me ter introduzido no mundo do planeamento de rotas de uma maneira maisaprofundada. Só assim é que foi possível obter resultados com qualidade.

Quero aproveitar para também agradecer a todos os colegas de trabalho da empresa que meacolheu, a OPT. Agradeço em especial ao Dr. Fernando Vieira e ao Eng. Luís Filipe Ferreira porme terem introduzido o projeto e acompanhado durante toda a realização da dissertação. Agradeçotambém ao Eng. Vasco Agria e ao Eng. Gil Castro pelo apoio e pela paciência inesgotável quetiveram para esclarecer todas as minhas dúvidas técnicas.

A todos um muito obrigado!

André Pinheiro

v

“The only way to do great work is to love what you do.”

Steve Jobs

vii

Conteúdo

1 Introdução 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 A Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Estado da Arte 52.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Algoritmos de caminho mais curto . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Técnicas Básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Pesquisa orientada para um objetivo . . . . . . . . . . . . . . . . . . . . 72.2.3 Técnicas de Aceleração . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Transportes Públicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Algoritmos para cálculo de caminho mais curto . . . . . . . . . . . . . . 132.3.2 Representação dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.3 Aplicações Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Resumo e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Modelação do Problema 233.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Planeamento de viagens numa rede multimodal . . . . . . . . . . . . . . . . . . 25

3.2.1 Modelo tempo-expandido . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Modelo tempo-dependente . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 Modelo baseado em frequências . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1 Criação da Rede de Transportes . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Extração dos Pontos de Interesse . . . . . . . . . . . . . . . . . . . . . . 323.3.3 Indexação de paragens e pontos de interesse . . . . . . . . . . . . . . . . 333.3.4 Criação das ligações a pé . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.5 Agrupamento de paragens . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4 Algoritmo - Cálculo de Rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.1 RAPTOR - Execução do algoritmo . . . . . . . . . . . . . . . . . . . . 383.4.2 Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.3 Seleção das paragens de transbordo . . . . . . . . . . . . . . . . . . . . 44

4 Implementação 474.1 O Sistema IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Arquitetura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ix

CONTEÚDO

4.3 Esforço de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Resultados e Avaliação 535.1 Construção da rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2 Comparação das características entre os algoritmos . . . . . . . . . . . . . . . . 555.3 Avaliação do cálculo de rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.4 Desempenho do algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 Conclusões e Trabalho Futuro 63

Referências 65

x

Lista de Figuras

2.1 Exemplo da desigualdade triangular . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Exemplo da pesquisa de rotas no RAPTOR entre dois vértices . . . . . . . . . . 152.3 Logo da aplicação OpenTripPlanner . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Exemplo do cálculo de rotas no OpenTripPlanner na rede de Lisboa . . . . . . . 182.5 Logo da aplicação Navitia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Exemplo de sugestões para um plano de viagem no serviço itinerarium.net . . . . 192.7 Linhas próximas de uma paragem no serviço itinerarium.net . . . . . . . . . . . 192.8 Todas as paragens de uma linha no serviço itinerarium.net . . . . . . . . . . . . 202.9 Apresentação do resultado do cálculo de caminho mais curto no website do Metro

do Porto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.10 Seleção das paragens de origem e destino no website do Metro do Porto . . . . . 21

3.1 Exemplificação do modelo realístico da versão tempo-expandido . . . . . . . . . 273.2 Exemplificação do modelo realístico tempo-dependente . . . . . . . . . . . . . . 283.3 Exemplo simplificado da linha 205 da STCP . . . . . . . . . . . . . . . . . . . . 303.4 Exemplificação de duas variantes de uma linha . . . . . . . . . . . . . . . . . . 323.5 Extração dos pontos de interesse . . . . . . . . . . . . . . . . . . . . . . . . . . 333.6 Associação de cada paragem às linhas que por ela passam . . . . . . . . . . . . . 343.7 Criação das ligações a pé a partir de uma paragem . . . . . . . . . . . . . . . . . 353.8 Rede de exemplo para o algoritmo RAPTOR. . . . . . . . . . . . . . . . . . . . 403.9 Seleção das viagens a partir da paragem 2. . . . . . . . . . . . . . . . . . . . . . 403.10 Rede de transportes após a análise da linha 205 a partir da paragem 4. . . . . . . 423.11 Rede de transportes após a análise da linha 700 a partir da paragem 3. . . . . . . 433.12 Rede de transportes após a análise da linha 205 a partir da paragem 5 na ronda K

= 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.13 Exemplificação da seleção da paragem de transbordo . . . . . . . . . . . . . . . 44

4.1 Esquematização da arquitetura lógica horizontal do sistema IMS da OPT. . . . . 484.2 Esquematização da arquitetura lógica vertical do sistema IMS da OPT. . . . . . . 50

5.1 Comparação dos tempos de resposta do algoritmo RAPTOR com e sem a restriçãodo tempo limite a caminhar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Comparação dos tempos de resposta do algoritmo RAPTOR com e sem a restriçãodo tempo limite a caminhar, com um número máximo de rondas definido a 2. . . 60

5.3 Resultados da execução de 4 rondas com 1000 pedidos cada da adaptação do al-goritmo RAPTOR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.4 Resultados da execução de 4 rondas com 1000 pedidos cada da adaptação do al-goritmo RAPTOR, para diferentes valores de K. . . . . . . . . . . . . . . . . . . 62

xi

LISTA DE FIGURAS

xii

Lista de Tabelas

3.1 Exemplo de horários para duas viagens distintos. . . . . . . . . . . . . . . . . . 263.2 Exemplo de um conjunto de viagens para a variante principal da linha 205 da STCP. 313.3 Execução da ronda K = 0 do algoritmo RAPTOR. . . . . . . . . . . . . . . . . . 393.4 Resultados após a ronda K = 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5 Resultados após a ronda K = 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.6 Resultados após a ronda K = 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Resultados para os cálculos de rotas realizados com o algoritmo RAPTOR. . . . . 575.2 Resultados para os cálculos de rotas com pontos intermédios. . . . . . . . . . . . 585.3 Comparação entre os tempos de resposta do algoritmo implementado durante a

dissertação e aquele atualmente em utilização. . . . . . . . . . . . . . . . . . . . 59

xiii

LISTA DE TABELAS

xiv

Abreviaturas e Símbolos

ALT A*, Landmarks and Triangle InequalityCSA Connection Scan AlgorithmIMS Information for Mobility SupportOPT Otimização e Planeamento de Transportes S.A.RAPTOR Round-Based Public Transit Routing

xv

Capítulo 1

Introdução

O presente documento tem por objetivo apresentar o trabalho desenvolvido ao longo da tese

de mestrado Evolução da componente algorítmica de cálculo de rotas do Move-Me. Este trabalho

está inserido no Mestrado Integrado em Engenharia Informática e Computação e decorreu sob

orientação do Professor Doutor João Canas Ferreira.

Neste capítulo são abordados os principais aspetos motivacionais, será feita uma apresentação

do projeto e da empresa onde decorreu o trabalho. Para além disso são identificados e definidos os

problemas a tratar. Finalmente também são definidos os objetivos que se pretendem alcançar no

final deste trabalho.

1.1 Contexto

Numa altura em que os transportes públicos afirmam cada vez mais a sua importância no quo-

tidiano das pessoas, é hoje mais importante do que nunca oferecer soluções rápidas e eficazes,

capazes de responder às necessidades crescentes dos utilizadores. Consequentemente, e com as

redes de transportes cada vez mais densas e complexas, a necessidade de criar ofertas de planea-

mento de rotas multimodais tem vindo a aumentar.

Tipicamente é possível encontrar na internet serviços de planeamento de rotas, onde a um uti-

lizador é pedido que selecione um ponto de origem, um ponto de destino e possivelmente critérios

mais específicos como a hora de partida ou horas de chegada desejadas. Como resposta ao pedido

é apresentado o pleaneamento de uma ou mais rotas encontradas. Infelizmente, grande parte des-

ses sistemas tem uma falha em comum: estão centrados apenas numa empresa ou num meio de

transporte específico. Por exemplo, pode ser necessário planear diferentes troços de uma viagem

manualmente, escolhendo por exemplo um troço do percurso que deve ser percorrido de metro até

à interface com os autocarros, outro troço que faz a ligação entre os autocarros e a estação dos

comboios e finalmente um troço que faz a ligação do comboio até ao destino final.

1

Introdução

Para cada um destes troços é necessário selecionar transportes onde as horas de chegada no

transporte atual e partida no transporte seguinte sejam compatíveis. Com a necessidade inerente

de corrigir estas limitações, nos últimos anos têm surgido diversas aplicações que tentam unificar

todos os meios de transporte de maneira a auxiliar os utilizadores na pesquisa de rotas do cami-

nho mais curto. O problema de calcular uma rota de caminho mais curto envolvendo diferentes

meios de transporte é denominado como problema de transportes multimodais. Neste problema

é pedido ao utilizador que forneça um ponto de origem, um ponto de destino e a hora de partida

ou hora de chegada pretendida. Como resultado é mostrado o percurso mais curto tendo em conta

o tempo que demora a ser percorrido e potencialmente o número de transbordos, que deverá ser

minimizado. De realçar que logo aqui se evidencia uma diferença entre as redes de transporte

público e as redes rodoviárias já que nas redes de transporte público o utilizador está dependente

dos horários das empresas transportadoras, enquanto que numa rede de transporte rodoviário o uti-

lizador poderá utilizar o veículo a qualquer hora. Desse modo, nas redes de transporte rodoviários

tipicamente trabalhamos com tempos, idealmente em tempo real, ou quando não for possível ter

acesso a informações em tempo real então deve ser usado o tempo estático fornecido pelas empre-

sas, enquanto que nas redes rodoviárias trabalhamos com distâncias, ou com tempos diretamente

proporcionais à distância, através do limite máximo de velocidade em cada troço.

O desafio passa então por encontrar algoritmos capazes de responder a pedidos de utilizadores

de maneira eficiente.

1.2 A Empresa

A OPT, é uma empresa sedeada no Porto e é o local onde este trabalho será desenvolvido. A

OPT foi formada em 1992 e tem como principal área de desenvolvimento a gestão operacional

do transporte coletivo urbano. Tem como clientes algumas das empresas de transporte com mais

relevo no território nacional, como a STCP, a Carris, a Metro do Porto, a TransDev e a CP.

A empresa prima por oferecer soluções informáticas inovadoras e constantemente atualizadas

nas áreas da gestão, planeamento e otimização de transportes públicos e na geração automática de

informação ao público. Como exemplo, o primeiro sistema desenvolvido pela empresa, o GIST –

Gestão Integrada de Sistemas de Transportes, está hoje presente nas maiores empresas nacionais

de transportes públicos, tendo vindo a sofrer diversas atualizações de modo a acompanhar as mais

recentes evoluções tecnológicas.

Para além do que já foi referido anteriormente, a OPT também desenvolve soluções que têm

como enfoque o apoio em tempo real. De entre essas soluções merecem especial destaque o

sistema SMS e o sistema InfoBoard, que atualmente está instalado em diversas faculdades na zona

do Porto. Também inserido nesta área está o projeto Move-Me, já distinguido a nível nacional

com o prémio de inovação tecnológica. É neste projeto que se enquadra esta dissertação, através

da conceção de um algoritmo capaz de dar resposta às necessidades crescentes por parte dos

utilizadores.

2

Introdução

A OPT procura neste momento internacionalizar-se, explorando mercados emergentes que atu-

almente ainda não possuem soluções tecnológicas sofisticadas. Dessa maneira, a empresa procura

trabalhar nestas oportunidades de modo a potenciar os seus produtos em território estrangeiro.

1.3 Motivação e Objetivos

O foco da OPT são os sistemas de apoio à mobilidade em tempo real. Desse modo, é im-

portante que construam os seus produtos com os algoritmos onde seja possível obter os tempos

de resposta mais rápidos em tempo real. Assim, o objetivo deste trabalho é dar resposta a uma

necessidade presente na empresa. O módulo responsável pelo cálculo do caminho mais curto está

inserido no sistema IMS, e é denominado por PADA. O algoritmo de cálculo de rotas do Move-Me

já está implementado, no entanto é demasiado lento em situações reais, podendo mesmo demorar

mais de um minuto a executar. Consequentemente, é importante que se reduzam os tempos de

resposta do algoritmo para o mínimo possível, idealmente a rondar os milissegundos. Assim, o

objetivo deste trabalho passa pela implementação de um algoritmo eficiente capaz de dar resposta

às necessidades atuais dos utentes que utilizam a aplicação Move-Me. Esse algoritmo deve ser

rápido e capaz de funcionar com dados fornecidos em tempo real uma vez que as redes de trans-

portes públicos não são estáticas, são redes onde os atrasos são uma presença constante. Para

além disso o algoritmo deve ser capaz de responder a múltiplos pedidos em simultâneo para que

os utilizadores não esperem demasiado tempo pelas respostas do servidor.

1.4 Estrutura da Dissertação

No capítulo 2, é descrito o estado da arte e são apresentados trabalhos relacionados dentro da

área do cálculo de rotas em redes de transportes públicos.

No capítulo 3 o problema a tratar é descrito de maneira mais aprofundada e é apresentada a

metodologia seguida para a sua resolução.

No capítulo 4 são apresentadas e descritas as arquiteturas horizontal e vertical do sistema. Para

além disso é feito um breve balanço relacionado com o esforço de desenvolvimento.

No capítulo 5 é feita uma comparação entre o desempenho do algoritmo atual e o algoritmo

implementado durante a dissertação. Para além disso são apresentados resultados detalhados sobre

o novo algoritmo.

No capítulo 6 é feito um balanço final sobre o trabalho realizado durante a dissertação e são

sugeridas algumas melhorias que podem ser realizadas no futuro.

3

Introdução

4

Capítulo 2

Estado da Arte

Este capítulo apresenta a investigação que foi realizada em relação à área onde incide o desen-

volvimento deste projeto. São apresentados diversos métodos para se fazerem cálculos de caminho

mais curto e é também apresentado um método desenvolvido com a intenção de calcular o caminho

mais curto dentro de uma rede de transportes públicos, em tempo real.

2.1 Introdução

O cálculo do caminho mais curto é utilizado em diversas áreas no mundo real, como o plea-

neamento de rotas em redes rodoviárias, ou até mesmo no planeamento de rotas para o transporte

áereo. De um modo geral, o algoritmo de Dijkstra [Som14] é o mais utilizado. É um algoritmo

capaz de calcular o caminho mais curto entre uma origem s e um destino t. O problema dos

transportes multimodais pode ser resolvido através de uma generalização do algoritmo de Dijkstra

[DW09], no entanto quando as redes multimodais tomam proporções grandes o tempo de cálculo

do algoritmo pode estar na ordem dos minutos [DW09], lento demais para aplicações no mundo

real. Desse modo, foi necessário criar técnicas de aceleração, capazes de melhorar o tempo de

resposta do algoritmo diversas ordens de magnitude. São técnicas que numa primeira etapa pas-

sam por uma fase de pré-processamento onde irão ser introduzidos atalhos entre os vértices de

um grafo e onde de um modo geral o tamanho do grafo será reduzido. Esta versão reduzida do

grafo será utilizada para responder a pedidos dos utilizadores. São técnicas que se podem dividir

nas seguintes categorias: pesquisa bidirecional, pesquisa orientada para um objetivo e contração.

Cada uma das técnicas referidas anteriormente será abordada individualmente mais à frente no

documento.

5

Estado da Arte

2.2 Algoritmos de caminho mais curto

Nesta secção será abordada alguma teoria de grafos uma vez que uma grande parte algoritmos

de pesquisa de caminho mais curto trabalha sobre grafos e é a forma mais frequente de modelar

uma rede de transportes. De seguida serão abordadas algumas técnicas básicas de pesquisa e

finalmente algumas técnicas capazes de guiar o algoritmo para um objetivo.

Um grafo G=(V,E) consiste num conjunto de vértices que pertencem a V e um conjunto de

arestas E formadas por dois nós pertencentes a V. Os grafos considerados neste documento são

direcionados, logo uma aresta (i, j) é considerada uma aresta direcionada de i para j. Neste do-

cumento os vértices representam pontos específicos de uma rede rodoviário ou paragens de uma

rede de transporte e uma aresta entre dois vértices representa uma via que liga dois pontos ou uma

conexão entre duas paragens. A cada aresta é atribuído um peso não negativo, que é interpretado

de maneira diferente quando estamos a lidar ou não com horários. No cenário da independência do

tempo é suficiente atribuir um peso constante a uma aresta, que poderá ser por exemplo a distância

entre dois vértices. Já no cenário da dependência de tempo é necessário utilizar uma função de

peso que atribui a uma aresta diferentes pesos durante o dia [DN12]. Os grafos que utilizam estas

funções de custo para calcular o peso de uma aresta são chamados de grafos time-dependent. O

resultado da função de cálculo do peso pode ser entendida como o tempo de viagem entre duas

estações e deve respeitar a propriedade FIFO (First-In-First-Out). Esta propriedade assegura que

um transporte t1 que sai de uma paragem i, representada por vértice do grafo, antes de um trans-

porte t2, não chega mais tarde do que o transporte t2 a uma paragem j. Esta propriedade pode

ser aplicada em quase todas as redes de transporte, no entanto nem sempre é válida nas redes de

transporte rodoviário.

Um caminho em G é composto por uma sequência de vértices, onde dois vértices estão liga-

dos por uma aresta. O comprimento de um caminho é a soma de todos os pesos das arestas que

o compõem. No caso da dependência de horários o comprimento do caminho pode ser interpre-

tado como o tempo total que demora a percorrer um caminho numa determinada hora do dia. O

tempo de uma aresta pode variar durante as várias horas do dia, uma vez que nas horas de ponta

geralmente demorará mais tempo a percorrer o mesmo troço.

2.2.1 Técnicas Básicas

A solução padrão para resolver o problema do caminho mais curto é aplicar o algoritmo de

Dijkstra [BDG+16] a um grafo G. Este algoritmo recorre a uma fila de prioridade Q, onde mantém

os vértices ordenados pela distância até uma origem s. Todas as distâncias são inicializadas a

infinito, excepto a distância da origem até à origem, que é inicializada a 0. Inicialmente, o único

vértice presente na fila de prioridade Q é s. Em cada iteração, é extraído e removido da fila de

prioridade Q o vértice u com menor distância até à origem s, e é calculada a distância para cada um

dos seus vizinhos v. Esta distância pode ser representada por dist(s, u) + length(u, v). Se este custo

melhorar dist(s, v), então o custo é atualizado e o vértice v é adicionado à fila de prioridade Q, com

6

Estado da Arte

custo dist(s, v). No algoritmo de Dijkstra a pesquisa pode parar assim que o vértice objetivo, t, for

analisado.

A complexidade temporal do algoritmo de Dijkstra sem recorrer a uma fila de prioridade é

O(|V |2), em que V representa o conjunto de vértices. A complexidade temporal deste algoritmo

pode ser melhorada recorrendo a uma fila de prioridade e a Fibonacci Heaps [FT87], passando a

ser O(|E|+ |V | log |V |), onde E representa o conjunto das arestas do grafo [Som14].

A forma mais usual de reduzir o espaço de pesquisa é através da pesquisa bidirecional [GW05].

Neste método são executadas duas pesquisas simultaneamente, uma da origem s para o destino t,

e outra do destino t para a origem s. A pesquisa pára quando existe uma intersecção de pelo

menos um vértice no caminho de s para t. Este método pode diminuir o espaço de pesquisa para

cerca de metade, e é mais utilizado em redes rodoviárias. Nas redes de transporte público é mais

difícil utilizar esta técnica uma vez que não se conhece o instante de tempo que deve ser utilizado

para fazer a pesquisa do objetivo t para a origem s. Para se contornar a situação da pesquisa t-s,

pode-se utilizar limites inferiores durante o cálculo desta pesquisa até ao momento onde as duas

se interceptem e a partir daí pode ser calculada a restante parte time-dependent do grafo [DPW15].

2.2.2 Pesquisa orientada para um objetivo

Os métodos de pesquisa orientada para um objetivo, ao contrário do algoritmo de Dijkstra que

apenas seleciona a menor distância entre s e t, tentam guiar o algoritmo em direção ao objetivo,

evitando assim analisar vértices que não estão na direção do objetivo e consequentemente redu-

zindo o espaço de pesquisa. São algoritmos que tentam tirar partido das estruturas das redes em

que estão inseridos.

2.2.2.1 Algoritmo de pesquisa A*

O algoritmo de pesquisa A* [GKW06][GH04] é um dos algoritmos mais utilizados na cate-

goria de pequisa orientada para um objetivo. É uma versão modificada do algoritmo de Dijkstra

na qual a prioridade de um vértice v é colocada a d(s, v) + π(v). A função π(v) representa uma

função potencial dos vértices, que é um limite inferior d(v, t) da distância entre o vértice v e o

vértice objetivo t e pode ser entendido como uma estimativa da distância entre os dois vértices.

Se o valor da função potencial for 0, o algoritmo deixa de ter orientação e comporta-se como o

algoritmo de Dijkstra. Esta função permite que os vértices que estão mais próximos do objetivo

sejam analisados primeiro. O valor da função objetivo nunca deve sobre-estimar o custo real para

chegar ao nó objetivo mais próximo.

Por outro lado, se o valor da função objetivo correspondesse a um limite inferior exato, então

só os vértices que estão no caminho mais curto entre s e t seriam analisados. A qualidade da

pesquisa do A* depende diretamente da qualidade da função potencial utilizada, por isso quanto

mais precisa for a função potencial menor será o espaço de pesquisa do algoritmo.

Nas redes de transporte rodoviário onde se pretende minimizar a distância percorrida, a função

potencial escolhida pode ser a distância geográfica entre os vários pontos, que dará alguns limites

7

Estado da Arte

inferiores razoáveis. O algoritmo A* funciona de maneira eficiente quando o número de vértices

a pesquisar é de tamanho reduzido, no entanto quando se aplica este método de pesquisa a redes

de média e grandes dimensões geralmente obtêm-se tempos de resposta muito altos, que não

são práticos para situações no mundo real. Para se contornar essa situação podem ser utilizados

métodos de pesquisa que tirem partido de técnicas de aceleração antes de passarem à fase de

consulta. Entre esses métodos podem ser destacados o ALT [DW09][EP13][BDG+16] e a técnica

Arc Flags [DW09] [BD10], que apresenta os tempos de consulta mais rápidos de entre as técnicas

de aceleração.

2.2.3 Técnicas de Aceleração

Com a crescente complexidade das redes de transporte, os algoritmos como o Dijkstra e até

mesmo o A* deixaram de conseguir dar respostas rápidas e eficazes no capítulo do planeamento

de rotas. Em redes de larga escala podem demorar vários segundos até conseguirem encontrar

um caminho mais curto entre dois pontos de uma rede. Desse modo foi necessário criar técnicas

de aceleração capazes de correrem ordens de magnitude mais rápido do que algoritmos conven-

cionais. Uma grande parte das técnicas de aceleração tem por base o algoritmo de Dijkstra e o

objetivo destas técnicas é numa primeira fase, denominada de pré-processamento, reduzir o espaço

de pesquisa sem deixar de ter em conta o critério de otimalidade. Numa segunda fase, na fase de

consulta, os dados do espaço de pesquisa mais reduzido são utilizados para responder a pedidos

dos utilizadores.

2.2.3.1 ALT

A técnica ALT é uma técnica de pesquisa orientada para um objetivo e é uma das mais utili-

zadas e mais eficazes na pesquisa em redes rodoviárias. É baseada no algoritmo A*, melhorado

através da introdução de marcos. Os marcos correspondem a um conjunto de vértices do grafo

que são utilizados durante a fase de pré-processamento para se calcular a distância entre estes vér-

tices de referência e todos os outros do grafo, evitando dessa maneira calcular a distância entre

todos os pares de vértices do grafo, o que tornaria esta fase muito custosa. Os cálculos são feitos

recorrendo à desigualdade triangular. No ALT são escolhidos um conjunto de vértices e é a partir

destes vértices que a função potencial do A* é calculada, com o auxílio da desigualdade triangular

(figura 2.1).

Antes da fase de consulta estes algoritmos passam por uma fase de pré-processamento. No

caso do algoritmo ALT, o pré-processamento é feito em dois passos: escolha dos marcos mais

adequados e cálculo da tabela de distância entre todos os marcos. A segunda tarefa pode ser

facilmente resolvida recorrendo ao algoritmo de Dijkstra, uma vez que o número de marcos é

geralmente baixo.

Em relação à escolha dos marcos (em redes rodoviários) existem diversos métodos, como o

Avoid e o Max Cover, que serão explicados mais à frente. Depois de escolhido o conjunto L dos

marcos é necessário calcular a tabela de distância de todos os vértices v até todos os marcos l ∈

8

Estado da Arte

Figura 2.1: Exemplo da desigualdade triangular

L. Dado um marco l ∈ L, um conjunto de vértices l, u e v e a função dist(s, t) que representa

o comprimento do caminho mais curto do vértice s até ao vértice t no grafo G, a desigualdade

triangular pode ser traduzida no seguinte:

dist(u,v)+dist(v, l)≥ dist(u, l)

dist(l,u)+dist(u,v)≥ dist(l,v)

A partir destes dados podemos calcular o limite inferior de dist(u, v) através da seguinte fór-

mula:

R(l) = max(u, l)−dist(v, l),dist(l,v)−dist(l,u)

O valor de R(l) deverá ser igual ou inferior a dist(u, v).

O melhor limite inferior li pode então ser obtido utilizando o marco com o maior limite inferior

de acordo com a seguinte fórmula:

li(l) = max_entre_marcos(dist(u, l)−dist(v, l),dist(l,v)−dist(l,u))

A partir daqui podemos alterar a prioridade de um nó u na fila de prioridade para o seguinte:

dist(s,u)+ li(u)

A heurística Avoid tenta encontrar regiões de um grafo que não estão bem cobertas pelo con-

junto atual de marcos. Isso é feito a partir da construção de uma árvore de caminho mais curto de

um vértice aleatório u. O peso de cada vértice v é a diferença entre dist(v,u) e o limite inferior

dist(v,u) que foi obtido pelos respetivos marcos. O tamanho de um vértice v é a soma do seu peso

e o tamanho dos seus filhos na árvore de pesquisa de caminho mais curto. Se uma subárvore dessa

árvore com raíz em v contém um marco, o tamanho de v é colocado a 0. A árvore de caminho

9

Estado da Arte

mais curto é percorrida com início no vértice de maior tamanho, seguindo os vértices filho com

o maior tamanho. A folha da árvore obtida neste percurso é adicionada ao conjunto dos marcos.

Nesta heurística, a primeira raíz é selecionada aleatoriamente. As seguintes são escolhidas com

uma probabilidde proporcional ao quadrado da distância do marco mais próximo.

A heurística Max Cover tenta colmatar uma desvantagem da heurística Avoid, que é a fase

inicial. A primeira raíz é escolhida aleatoriamente e os seguintes marcos estão muito dependentes

do marco inicial. Desse modo, a heurística Max Cover inicialmente escolhe um conjunto de

marcos candidatos utilizando o Avoid. Os marcos que são utilizados são selecionados do conjunto

dos candidatos através de várias tentativas de pesquisas locais, cada uma começando num vértice

aleatório inicial.

A fase de consulta é muito semelhante ao algoritmo de Dijkstra bidirecional, com a diferença

de que em vez da prioridade de um nó ser calculada apenas recorrendo à distância até s/t, aqui

também utilizamos o valor do limite inferior calculado anteriormente até aos nós t(destino) e

s(origem), respetivamente. Não se deve calcular o limite inferior em relação a todos os marcos

uma vez que produz demasiado overhead durante a fase de consulta. Para resolver esse problema

geralmente é selecionado um conjunto pequeno (normalmente 2) de marcos ativos, dependendo da

consulta em questão. Os marcos ativos vão ser atualizados de k em k iterações se já não produzirem

os melhores limites inferiores para os vértices em questão.

2.2.3.2 Arc Flags

A segunda abordagem para a pesquisa orientada para um objetivo é designada por Arc Flags

[BD10]. Tal como as anteriores, esta técnica é dividida em duas partes: uma fase de pré-processamento

e uma fase de consulta. Durante a fase de pré-processamento o grafo é particionado em k células

equilibradas, isto é, que têm um número semelhante de vértices, e para cada aresta de cada uma

das células são calculados k indicadores, representadas por um vetor de K bits. Cada célula deve

ter um número pequeno de vértices na fronteira, uma vez que calcular as arestas para todos os

vértices levaria demasiado tempo. O bit de índice i é colocado a 1 se a aresta está no caminho

mais curto para qualquer outro vértice da célula i. As arestas que não contêm o bit colocado a 1

para a célula que contém o vértice t são eliminadas. Aqui já se pode inferir sobre uma diferença

importante entre a técnica ALT e a técnica Arc Flags. Enquanto a ALT tenta guiar a pesquisa

em direção ao vértice t, a técnica Arc Flags tenta encontrar caminhos que possam ser eliminados

durante a pesquisa, reduzindo assim ainda mais o espaço de pesquisa em relação à técnica ALT.

A fase de pré-processamento do algoritmo Arc Flags é dividida em duas fases: no particio-

namento do grafo e no cálculo das respetivas Arc Flags. Na fase de cálculo das Arc Flags são

calculados vários subgrafos para cada região e a cada aresta é associado um vector de indicadores

com comprimento igual ao número de regiões. A maneira mais eficiente de se calcular as Arc

Flags recorre apenas aos vértices das fronteiras de cada região. Um caminho mais curto com ob-

jetivo numa região R tem de entrar nessa região em algum ponto, logo é suficiente calcular árvores

de caminho mais curto inversas a partir dos vértices das fronteiras. Isto permite diminuir o tempo

de pré-processamento, no entanto continua a ser bastante alto, podendo mesmo levar algumas

10

Estado da Arte

horas a completar o processo. A abordagem que permite os tempos de pré-processamento mais

rápidos é a Abordagem Centralizada.

A fase de consulta deste algoritmo é muito semelhante ao algoritmo de Dijkstra. Para calcular

o caminho mais curto entre dois vértices s e t, inicialmente é determinada a célula onde está

contido o vértice t e só as arestas que têm o bit colocado a 1 para esta região é que são analisadas.

2.2.3.3 Arc Flags de múltiplos níveis

A técnica de Arc Flags de múltiplos níveis é uma melhoria em relação à técnica descrita ante-

riormente. Aqui, um segundo nível de de arc flags são calculadas para cada uma das células. Cada

célula C vai ser dividida em várias subcélulas e serão novamente calculadas as Arc Flags para

cada subcélula. O pré-processamento em redes de transporte rodoviário, onde não se depende de

horários, é muito semelhante ao processamento no método descrito em cima. Inicialmente, as arc

flags para os níveis superiores são calculadas da mesma maneira em relação ao método anterior.

Para se calcular as arc flags dos níveis inferiores é construída uma árvore de caminho mais curto

para todos os vértices da fronteira do nível inferior. Quando todos os vértices da célula C que

contém um conjunto de subcélulas foram visitados o crescimento da árvore de pesquisa pode ser

terminado. Finalmente, uma arc flag de um nível inferior é colocada a 1 se a aresta fizer parte de

pelo menos uma árvore de caminho mais curto.

2.2.3.4 Contração

Uma das principais técnicas técnicas de aceleração utilizadas nas redes rodoviárias é a contra-

ção [GSSD08][BDS+10]. Nesta técnica o tamanho do grafo é reduzido, quer através dos vértices

quer através das arestas. As duas formas de redução do tamanho do grafo são denominadas como

node-reduction e edge-reduction, respetivamente. Na contração os vértices que não são consi-

derados importantes são removidos e são adicionados atalhos entre os vértices não removidos,

de modo a preservar as distâncias dos nós removidos. Ao contrair vértices menos importantes a

pesquisa para o caminho mais curto só necessita de analisar que são considerados importantes.

Na contração, os vértices são ordenados pelo critério de importância e os vértices são contraí-

dos por ordem crescente de importância, ou seja, do menos para o mais importante. A contração

tem como objetivo tirar partido da hierarquia existente nas redes de transporte rodoviário. O al-

goritmo de Hierarquias de Contração tenta executar uma operação de contração de um vértice

repetidamente. Para se contrair um vértice v, é criado uma aresta entre cada par de vértices vizi-

nhos u e l se o caminho mais curto de u para l for único e contiver v.

É uma técnica que também pode ser combinada com a pesquisa bidirecional na fase de con-

sulta. Nesta fase é executada uma pesquisa no grafo G, e são visitadas as arestas que foram

introduzidas como atalhos na fase de pré-processamento. Esta fase consiste na aplicação da téc-

nica de contração de vértices até que não seja possível contrair mais nenhum vértice, seguida da

aplicação da técnica de contração de arestas no grafo anteriormente obtido. As técnicas referidas

11

Estado da Arte

anteriormente serão explicadas mais à frente em detalhe. Durante a pesquisa só são visitados vér-

tices que levem a vértices com ranking mais alto, isto é, que são considerados mais importantes.

Com a aplicação desta técnica é possível obter caminhos mais curtos em grafos intercontinentais

na ordem dos milissegundos.

2.2.3.5 Contração de vértices

Nesta técnica o objetivo é reduzir o número de vértices no final, contraindo vértices até que

mais nenhum possa ser contraído. Após a aplicação da contração de vértices o grafo é dividido

em duas partes, o núcleo e a component. O núcleo do grafo é constituído por todos os vértices

que não foram removidos durante a fase de contração, uma vez que serão estes vértices serão os

utilizados para fazer os cálculos de caminho mais curto. Já a component do grafo G é constituída

por todos os vértices que foram removidos do grafo durante a contração. Inicialmente é assumido

que todos os vértices pertencem ao núcleo, uma vez que nenhum ainda foi removido.

Para se contrair um vértice v primeiro removemos o vértice v de um grafo G, as suas arestas de

entrada e as suas arestas de saída. Seja o conjunto dos arestas de entrada o conjunto E, e o conjunto

das arestas de saída o conjunto S. Para cada vértice de entrada u e para cada vértice de saída w é

criado uma nova aresta com peso dist(e) = dist(u, v) + dist(v, w). A função dist representa o valor

da distância entre os dois vértices. Se a inserção da nova aresta e levar a múltiplas arestas e2 de

u até w, então colocamos o peso da aresta já existente para o peso mínimo dist(e2) = min[dist(e),

dist(e2)]. De realçar que esta técnica preserva as distâncias corretas entre quaisquer dois vértices

da parte núcleo do grafo G.

2.2.3.6 Contração de arestas

Na técnica de Contração de vértices podem ser introduzidos atalhos que não são necessários

para manter as distâncias corretas na parte core de um grafo. Desse modo, a técnica de Contração

de arestas tem por objetivo remover algumas arestas introduzidas na técnica anterior de modo a

que as pesquisas de caminho mais curto sejam ainda mais eficientes. A contração das arestas é

feita logo após a contração de vértices, na parte core do grafo. Para cada nó v da parte core do grafo

e para cada aresta (v,w) é feita uma pesquisa de caminho mais curto. Se a distância do caminho

mais curto entre o vértice v e o vértice w for inferior ao peso da aresta (v,w), que representa o

atalho entre os dois vértices, então a aresta (v,w) pode ser removida do core.

Uma forma mais eficiente de executar este processo é construir uma árvore de caminho mais

curto a partir do vértice v e parar a pesquisa assim que todos os vizinhos de v forem visitados. De

seguida, para cada vizinho w do vértice v verificamos se o pai do vértice w é o vertice v. Se não

for então podemos remover a aresta (v,w) do grafo porque o caminho mais curto entre estes dois

vértices não inclui a aresta (u,w).

12

Estado da Arte

2.3 Transportes Públicos

Nos últimos anos foram desenvolvidas várias técnicas que depois de passarem por uma fase

de pré-processamento conseguem encontrar o caminho mais curto em redes globais em milisse-

gundos, muito mais rápido do que o algoritmo de Dijkstra. No entanto, nenhuma destas técnicas

funciona com o mesmo grau de eficiência quando aplicada a uma rede de transporte públicos. Os

algoritmos com maior sucesso nas redes de transporte rodoviário são aqueles baseados na contra-

ção.

Nesta secção serão explicados alguns métodos para se calcular os percursos mais rápidos em

redes de transportes públicos, será apresentada uma maneira de se representar os dados de uma

rede de transporte público e serão apresentadas algumas aplicações já existentes no mercado atu-

almente.

2.3.1 Algoritmos para cálculo de caminho mais curto

Os algoritmos apresentados anteriormente são baseados no Dijkstra. Infelizmente todos eles

têm o problema comum de demorarem bastante tempo na fase de pré-processamento. Isto torna-

os difíceis de se adaptarem a redes de transportes públicos, principalmente devido ao carácter

dinâmico inerente às redes de transportes públicos. Se existirem alterações nestas redes será ne-

cessário correr novamente o algoritmo de pré-processamento, o que poderá demorar mais algumas

horas, ou mesmo dias. Além disso, o tempo de chegada ao destino não é geralmente suficiente

para se calcular a melhor solução, uma vez que o número de transbordos também deve ter sido em

conta. Assim, e de modo a colmatar essa limitação, ultimamente têm sido desenvolvidos diversos

algoritmos específicos para redes de transportes públicos.

De seguida será apresentado um dos algoritmos mais eficientes nestas redes, o RAPTOR, e

que ao contrário daqueles apresentados até agora, não é baseado no Dijkstra. Para além do algo-

ritmo que será apresentado também existe o CSA [DPSW13], no entanto este apresenta diversas

limitações, o que não o torna ideal para cenários realistas. O CSA apenas calcula a chegada mais

próxima, no entanto pode existir outra que parta mais tarde e chegue ao destino mais cedo. Além

disso não tem em consideração o número de transbordos e nos caminhos a pé não é considerado o

tempo.

2.3.1.1 RAPTOR

O algoritmo RAPTOR [DPW12] não se baseia no algoritmo de Dijkstra, nem em grafos, nem

em pré-processamento, o que o torna ideal para utilizar em redes totalmente dinâmicas. Para além

disso pode ser facilmente paralelizado pelos vários cores do CPU. Este algoritmo toma sempre

como base os critérios tempo de chegada e número de transbordos, no entanto pode ser facilmente

adaptado para trabalhar com uma quantidade arbitrária de critérios, como por exemplo, as tarifas

em diversas zonas.

13

Estado da Arte

O algoritmo RAPTOR (figura 2.2) opera por rondas e visita uma linha de um transporte pú-

blico no máximo uma vez por ronda. Neste algoritmo cada ronda corresponde a um transbordo e

numa viagem entre uma origem e um destino com i jornadas, sabemos que existem sempre i− 1

transbordos. Como foi dito anteriormente, o algoritmo pode ser paralelizado entre vários cores,

no entanto só podem ser paralelizadas linhas independentes, isto é, linhas que não têm paragens

em comum. Este algoritmo funciona diretamente sobre um horário.

Seja S o conjunto de todos os segundos do dia, P um conjunto de paragens, L um conjunto de

linhas, J um conjunto de jornadas e F um conjunto de ligações a pé entre as diversas estações. As

jornadas correspondem a um conjunto de estações que um veículo visita numa linha. A diferença

fundamental entre as jornadas e as linhas é que as jornadas estão dependentes do tempo, enquanto

que nas linhas apenas são definidas as paragens sem ter em consideração o tempo de passagem

nas paragens. Desse modo, tipicamente existem mais jornadas do que linhas. Uma paragem no

conjunto P corresponde a um local específico onde um veículo pára para que novos passageiros

embarquem ou abandonem o veículo. Cada elemento do conjunto F corresponde a um par de pa-

ragens e entre esse par está associado um tempo, que corresponde ao tempo médio necessário para

se deslocarem de uma paragem até à outra a pé. Esta função é representada por dist_ f (p1, p2). A

cada jornada, em cada paragem, deve estar sempre associado um tempo de chegada e um tempo de

partida, representado pelas funções t_chegada( j, p) e t_partida( j, p). O valor de t_chegada( j, p)

deve ser sempre menor ou igual ao valor de t_partida( j, p).

O resultado do cálculo deste algoritmo é um conjunto de viagens. Cada viagem é definida por

um conjunto de jornadas, bem como ligações a pé que possam ser necessárias fazer no caso dos

transbordos.

Neste algoritmo são pedidos ao utilizador os seguintes dados: uma paragem de origem p_origem,

uma paragem de destino p_destino e uma hora de partida t_partida. A ideia do algoritmo RAPTOR

é calcular em cada ronda k uma viagem até à paragem de destino no menor tempo possível e que

tenha no máximo k jornadas. Cada ronda k deste algoritmo calcula a maneira mais rápida de se

chegar a todas as paragens no máximo com k - 1 transbordos. Em cada ronda é necessário manter

para cada paragem o tempo mais rápido de se chegar a essa paragem com no máximo k jorna-

das. Desse modo, é necessário associar a cada paragem um array, onde o elemento i representa

o tempo mais rápido para se chegar a essa paragem com i jornadas. Seja essa função a função

f _tempo(i, p). Inicialmente todos os valores nestes arrays são colocados a infinito, exceto o valor

f _tempo(0, p), que é colocado a t_partida. Em cada ronda k são executados 3 passos.

No primeiro passo o valor de f _tempo(k, p) é igualado ao da ronda anterior f _tempo(k−1, p),

para todas as paragens. Como o valor do tempo de chegada a cada paragem só pode minimizado,

esta função coloca um limite superior para o menor tempo com k jornadas. Em cada ronda k só

são examinadas as linhas que contêm pelo menos uma paragem em comum com a ronda k - 1.

Para se determinar quais são as linhas a ser examinadas, durante a ronda k - 1 as paragens para o

qual o valor de f _tempo(k−1, p) foi melhorado são marcadas. Assim, durante a ronda k iteramos

por todas as paragens marcadas e descobrimos quais são as linhas que a contêm. Se existir mais

do que uma paragem marcada para uma linha só será visitada a primeira paragem onde se possa

14

Estado da Arte

Figura 2.2: Exemplo da pesquisa de rotas no RAPTOR entre os vértices 1 e 6. A linhas 205 éanalisada na primeira ronda, as linhas 505 e 705 são analisadas na segunda ronda e finalmentea linha 506 é analisada na terceira ronda. A pesquisa das rotas nas linhas começa nos vérticesmarcados a vermelho.

embarcar nessa linha.

A uma linha estão associadas várias jornadas ao longo do dia. Seja a função prox_jornada(r,

p) que representa a próxima jornada na linha r, na paragem p, onde alguém pode embarcar. Isto

quer dizer que queremos encontrar um valor tal que t_chegada(j, p) seja maior ou igual ao valor

de f_tempo(k - 1, p). Quando este valor for encontrado na linha então é necessário colocar um

apontador para esta paragem uma vez que foi aqui onde embarcamos. Este apontador servirá

para no final se reconstruir o caminho. De seguida é necessário atualizar o valor de f_tempo(k,

p) para esta jornada. Pode ser necessário atualizar a jornada k quando um caminho mais rápido

para a paragem p foi encontrado numa ronda anterior. Desse modo é necessário verificar em

todas as paragens se t_chegada(j, p) é maior do que f_tempo(k - 1, p). Se for, então o valor de

prox_jornada(r, p) deve ser calculado novamente.

Finalmente, a última etapa da ronda k tem em consideração os caminhos que podem ser percor-

ridos a pé. Para cada caminho dist_f(p1, p2) o valor de f_tempo(k, p2) é colocado a min[f_tempo(k,

p2), f_tempo(k, p1) + dist_f(p1, p2)]. O conjunto de todas as ligações a pé é transitivo, logo não

é necessário existir ligações diretas entre todos os caminhos. Se um caminho existir a pé exsitir

entre duas quaisquer paragens então é garantido que será encontrado. O algoritmo pode ser parado

quando já nenhum valor f_tempo(k, p) for melhorado.

Este algoritmo pode correr em tempo linear, por ronda. Em cada ronda, uma linha é visitada

no máximo uma vez, ou seja no máximo visitamos todas as paragens da rede no total. Como o

valor de prox_jornada(r, p) está em cache, então visitamos cada jornada de uma linha no máximo

uma vez. Desse modo, a complexidade temporal do algoritmo é O(K(∑r∈R|r|+ |T |+ |F |)), onde

R representa o conjunto de todas as linhas da rede, T representa o conjunto de todas as viagens de

todas as linhas e F representa o conjunto de todas as ligações a pé.

Para se paralelizar o algoritmo, e como já foi dito anteriormente, cada núcleo do CPU tem

15

Estado da Arte

de processar linhas independentes. Para se calcular as linhas independentes deve construir-se um

grafo de conflito, com base no facto de que duas linhas que não têm paragens em comum podem ser

analisadas simultaneamente. Neste grafo, não direcionado, cada vértice corresponde a uma linha

e as arestas entre os vértices correspondem a rotas que partilham pelo menos uma paragem. Neste

algoritmo a ideia é colorir linhas de maneira a que vértices adjacentes não tenham a mesma cor. A

partir daí é sabido que duas linhas que tenham a mesma cor podem ser processadas paralelamente.

O RAPTOR é capaz de correr ordens de magnitude mais rápido do que algoritmos baseados

no Dijkstra. Na rede de Londres, onde existem mais de 20 000 paragens, mais de 2 200 linhas e 5

milhões de partidas distintas, o RAPTOR é capaz de responder a consultas em cerca de 8ms numa

máquina com um CPU Intel Xeon X5680, com 96GB de RAM DDR3-1333.

2.3.2 Representação dos dados

Atualmente, o formato mais comum para se representar os dados é o GTFS (General Tran-

sit Feed Specification) [Goo]. É um formato utilizado para se representar informação como os

horários das diferentes transportadoras e as informações geográficas das paragens e das linhas.

Este formato é composto por um conjunto de ficheiros de texto comprimidos num ficheiro

ZIP, em que cada ficheiro é responsável por modelar um aspeto da rede de transportes públicos.

Os ficheiros são os seguintes: agency.txt, que é o ficheiro onde as transportadoras podem colocar

as suas informações básicas como os contactos, morada e nome; stops.txt que representa a lista

de paragens onde os passageiras podem entrar ou abandonar os veículos. As paragens estão as-

sociadas a uma empresa de transportes. O ficheiro routes.txt é responsável por armazenar todas

as linhas onde uma transportadora opera. Uma linha pode ter um nome curto, um nome longo,

uma descrição, um tipo consoante o veículo que opere na linha e uma cor. O ficheiro trips.txt é

constituído por todas as viagens dentro de uma linha. A diferença entre as viagens e as linhas é

que às viagens também está associado um tempo. Por exemplo, um veículo pode percorrer uma

linha dezenas de vezes durante um dia, por isso normalmente existem muito mais viagens do que

linhas. O ficheiro stop_times.txt é constituído por todos os tempos de chegada e de partida em

cada paragem, por viagem. Finalmente, o ficheiro calendar.txt guarda informação sobre os dias da

semana em que uma viagem está disponível. Por exemplo, os veículos podem ter horários diferen-

tes. Uns podem apenas operar durante os dias de semana e outros apenas aos fins-de-semana, daí

a necessidade de se fazer a distinção entre vários serviços. Estes são os ficheiros que são obrigató-

rios na especificação GTFS. Opcionalmente, pode ainda ser fornecida informação sobre as regras

de tarifas, preço de cada zona e ainda informação sobre a descrição do caminho físico que um

veículo percorre. Esta informação é armazenada através do valor da latitude e longitude de cada

ponto que um veículo percorre.

2.3.3 Aplicações Existentes

Hoje em dia já existem várias soluções construídas especificamente para trabalharem em redes

de transportes públicos. Geralmente são aplicações onde um utilizador pode fornecer um conjunto

16

Estado da Arte

de dados de um ou mais operadores e depois de uma fase de carregamento de dados para a apli-

cação o utilizador pode fazer consultas ao sistema. Regra geral estas aplicações funcionam com

dados estáticos, isto é, não são capazes de retirar informação em tempo real e de fazer os cálculos

de rotas a partir desses dados.

2.3.3.1 OpenTripPlanner

O OpenTripPlanner (figura 2.3) [Ope] é uma plataforma de código aberto para redes de trans-

portes públicos multi-modais e para múltiplas agências. É uma aplicação capaz de correr no Win-

dows, Mac e Linux. Os dados fornecidos à aplicação devem estar no formato GTFS. Segue um

modelo cliente-servidor, fornecendo várias interfaces de mapas para serem utilizados diretamente

na aplicação ou então uma REST API para que possa ser utilizada com aplicações de terceiros.

Figura 2.3: Logo da aplicação OpenTripPlanner

Quando um utilizador abre a aplicação, depois de feito o pré-processamento dos dados, pode

selecionar um ponto de origem e um ponto de destino e será presenteado com um conjunto de

alternativas de rotas onde é informado sobre os veículos onde deve embarcar, até que paragem

deve permanecer nesse veículo e onde deve fazer um transbordo para outro veículo (caso seja

necessário) para que possa prosseguir a sua viagem até ao fim (figura 2.4). As várias alternativas

de rotas geralmente estão ordenadas por hora crescente de ordem de chegada e de número de

transbordos.

Nesta aplicação também é possível selecionar outros critérios como a pesquisa apenas em lo-

cais que podem ser percorridos por cadeiras de rodas, a pesquisa em locais onde as zonas percor-

ridas a pé não sejam muito acentuadas, é possível selecionar a distância máxima que se pretende

percorrer a pé e até mesmo a hora a que se pretende partir ou chegar. Esta aplicação não trabalha

sobre dados em tempo real e o algoritmo de cálculo de rotas é baseado no A* com a heurística de

Tung-Chew [TTLC92].

2.3.3.2 Navitia

Esta aplicação web (figura 2.5) [Nav] é um conjunto completo para quem queira gerir as

rotas de uma empresa de transportes públicos ou fazer o cálculo dentro de caminho mais curto

17

Estado da Arte

Figura 2.4: Exemplo do cálculo de rotas no OpenTripPlanner na rede de Lisboa

dentro dessa rede. Permite calcular o caminho mais curto entre um ponto de origem e um ponto

de destino para todas as formas de viajar: metro, autocarro, bicicleta, carro ou até mesmo a pé.

Esta aplicação também trabalha sobre dados estáticos fornecidos através de ficheiros GTFS. Esta

é a funcionalidade principal da aplicação. Está também disponível uma funcionalidade capaz de

mostrar as próximas partidas e chegadas para um meio específico de transporte numa paragem

selecionada. Também é possível encontrar os diferentes meios de transporte disponíveis perto de

uma localização GPS ou de uma morada. Esta aplicação também se destaca por fornecer diversos

datasets de diversas partes do mundo. Através destes datasets é possível criar novas aplicações ou

até mesmo agregar diferentes datasets. Os datasets são unificados no formato GTFS.

Figura 2.5: Logo da aplicação Navitia

18

Estado da Arte

Figura 2.6: Exemplo de sugestões para um plano de viagem no serviço itinerarium.net

Atualmente a aplicação já conta com cerca de 400 datasets e está presente em cerca de 25

países. No conjunto agregado dos datasets fazem parte cerca de 1600 redes de transportes públicos

a nível global.

2.3.3.3 Itinerarium

O serviço Itinerarium é um sistema nacional e funciona na rede de transportes da STCP, Metro

e CP. Este serviço permite a um utilizador fornecer dois pontos, o ponto de origem e o ponto de

destino, e a partir desses dois pontos são apresentadas diversas alternativas (figura 2.6), ordenadas

pelo tempo de chegada e pelo número de transbordos. Este serviço permite também identificar as

linhas e paragens que se situam perto de uma determinada paragem (figura 2.7) e até mesmo ver

todas as paragens que pertencem a uma linha (figura 2.8).

Figura 2.7: Linhas próximas de uma paragem no serviço itinerarium.net

19

Estado da Arte

Figura 2.8: Todas as paragens de uma linha no serviço itinerarium.net

2.3.3.4 Metro do Porto

O serviço web do Metro do Porto dispõe de uma funcionalidade que permite aos utilizadores

calcular a forma mais rápida de percorrer um percurso entre dois pontos na rede do Metro do

Porto. A um utilizador é pedido a estação de origem e a estação de destino, bem como a hora

a que pretende partir ou a hora a que pretende chegar ao destino. Feito o cálculo, é apresentado

aos utilizadores o percurso mais rápido, a duração, a hora a que vão partir da estação de origem e

chegar à estação de destino e também a tarifa associada a essa viagem (figura 2.9).

2.4 Resumo e Conclusões

Nas secções anteriores foram apresentados alguns algoritmos de cálculo de caminho mais

curto, bem como algumas técnicas de aceleração dos algoritmos que tiram partido da rede onde

estão inseridos. Estes algoritmos de cálculo de caminho mais curto podem ser utilizados para

resolver o mesmo problema dentro de uma rede de transportes. Para além disso foram apresentados

alguns exemplos que são semelhantes em relação ao que se pretende no final, um algoritmo capaz

de calcular rotas em redes de transportes públicos de maneira rápida e eficaz.

Dentro dos algoritmos de cálculo de caminho mais curto começou por ser explicado o algo-

ritmo de Dijkstra, o algoritmo mais simples para este tipo de cálculo, no entanto é este que serve

de base para quase todos os outros. De seguida foi apresentado o algoritmo A*, uma melhoria em

relação ao Dijkstra uma vez que tira partido de uma função potencial e consequentemente é capaz

de guiar a pesquisa em direção ao objetivo pretendido.

Depois de explicados estes dois algoritmos, foram apresentadas algumas técnicas de acele-

ração mais utilizadas hoje em dia. Foi apresentada a pesquisa bidirecional que é o ingrediente

mais básico dentro destas técnicas. Foram apresentadas as técnicas ALT e Arc Flags, que é atual-

mente uma das técnicas que apresenta os tempos de consulta mais rápidos, em virtude do tempo de

pré-processamento muito alto. Foi explicado de que modo as duas técnicas diferem uma da outra;

enquanto a ALT tenta guiar a pesquisa em direção a um vértice objetivo a Arc Flags tenta encontrar

caminhos que possam ser eliminados durante a pesquisa, reduzindo assim o espaço de pesquisa

20

Estado da Arte

Figura 2.9: Apresentação do resultado do cálculo de caminho mais curto no website do Metro doPorto

Figura 2.10: Seleção das paragens de origem e destino no website do Metro do Porto

21

Estado da Arte

posteriormente. De seguida foi apresentada uma extensão da técnica Arc Flags, a Arc Flags de

múltiplos níveis, onde um segundo nível de Arc Flags são calculadas para todas as células. Foi

explicado como se pode proceder ao cálculo das Arc Flags nos diferentes níveis. Finalmente, foi

apresentada uma das técnicas mais populares entre técnicas de aceleração, a contração, bem como

as duas fases, a fase de contração de vértices e a fase de contração de arestas. Infelizmente é

difícil aplicar a maioria destas técnicas aos transportes públicos.

Na contração, a técnica mais popular de entre as técnicas de aceleração, é difícil aplicar a

técnica uma vez que é nas redes de transporte público não existe uma hierarquia definida. Já nas

redes de transporte rodoviário essa hierarquia está presente por exemplo quando se tenta explorar

os vértices que pertencem a uma autoestrada em vez de uma estrada nacional.

Finalmente, foi apresentado um algoritmo construído exclusivamente para cálculo de rotas

em redes de transporte público, o RAPTOR. É um algoritmo que toma uma perspetiva diferente

dos apresentados anteriormente uma vez que não trabalho em grafos, mas antes diretamente em

informação dos horários.

22

Capítulo 3

Modelação do Problema

Encontrar o caminho mais rápido entre dois pontos é um problema familiar para quem está

habituado a utilizar os transportes públicos de uma cidade. Com a presença cada vez mais notável

das tecnologias móveis no quotidiano da população surgem novas formas de apoiar os utentes

dos transportes públicos durante as suas deslocações. O problema do cálculo do caminho mais

curto entre dois pontos é um problema amplamente estudado, com vários algoritmos e técnicas de

aceleração a surgirem nos últimos tempos, capazes de calcularem os caminhos mais curto numa

rede intercontinental numa questão de milissegundos. No entanto, nenhuma destas técnicas de

aceleração é capaz de gerar os mesmos ganhos quando testadas numa rede de transportes públicos.

Tradicionalmente, este problema é resolvido recorrendo a variantes do algoritmo de Dijkstra,

utilizando um modelo de um grafo devidamente adaptado para o efeito. Recentemente, novos

algoritmos foram introduzidos, capazes de trabalharem diretamente sobre os horários, de uma

maneira dinâmica. Assim, é agora possível eliminar a dependência dos grafos. Além disso, e

como às redes de transportes públicos está associado um carácter dinâmico, é possível ter em

conta os cancelamentos de viagens ou alteração de horários de última hora.

No âmbito desta tese de mestrado foi aplicado a uma rede de transportes públicos complexa

um algoritmo capaz de responder rapidamente a pedidos feitos pelos utentes da rede. Esta rede é

constituída por um número arbitrário de operadores. A cada operador está associado um conjunto

de linhas e cada linha é constituída por um conjunto de paragens. Entre as paragens também são

consideradas ligações a pé, independentes dos operadores. Desta rede também fazem parte pon-

tos de interesse. Entre os pontos de interesse e as paragens podem existir ligações a pé. Quando

um utilizador faz um pedido de cálculo de rotas entre dois pontos é devolvido um conjunto de

itinerários sugeridos. Cada itinerário contém as paragens onde um utente deve embarcar e desem-

barcar, a que horas deve embarcar e a que horas irá desembarcar de um veículo, bem como as

linhas que deve seguir até atingir o destino pretendido. Durante o itinerário podem existir pontos

de transbordo, que devem ser devidamente indicados ao utente.

Este algoritmo irá fazer parte do módulo PADA, que é o módulo responsável pelo cálculo de

23


rotas do sistema IMS. É de salientar que neste módulo já se encontra implementado um algoritmo

baseado no algoritmo de Dijkstra e em algumas técnicas de aceleração. O algoritmo atual apre-

senta tempos de respostas que rondam os 30 segundos, e que por vezes podem mesmo atingir 1

minuto. Desse modo, e para responder a uma necessidade crescente dos utentes, foi aplicado o al-

goritmo RAPTOR à rede de transportes, tendo sempre em conta o objetivo principal da dissertação

que passa pela sofisticação do módulo PADA do sistema IMS.

3.1 Introdução

Hoje em dia as aplicações para o cálculo de rotas têm-se tornado cada vez mais populares entre

aqueles que viajam frequentemente de transportes públicos. Estas aplicações de planeamento de

rotas têm vindo a substituir o tradicional método de consulta de horários e linhas pela internet,

garantindo assim que o utente tem acesso ao caminho ótimo até ao destino pretendido e eliminando

eventuais erros de observação que possam acontecer. Ao utilizar um meio digital passa a ser

possível apresentar aos utentes da rede de transportes públicos resultados em tempo real, sendo

assim possível eliminar eventuais erros de observação por parte dos utentes. Assim, neste capítulo

será apresentado um algoritmo capaz de auxiliar os utentes na rede de transportes públicos do

Porto. É de realçar que o problema do cálculo de rotas em redes rodoviárias não é exatamente

igual ao problema de cálculo de rotas mais rápidas numa rede de transportes públicos.

Uma rede de transportes públicos difere muito de uma rede de transportes rodoviários uma vez

que na primeira devem ter sido em contas restrições que não se aplicam nas redes de transporte

rodoviários. Numa rede de transportes públicos deve ser considerado que um veículo apenas

percorre rotas pré-definidas em horas devidamente marcadas, ao contrário de uma rede rodoviária

onde um condutor tem a liberdade de escolher o percurso e a hora em que pretende iniciar uma

viagem. Além disso, há que ter em conta que numa rede de transportes públicos o caminho mais

curto nem sempre é o ideal já que essa rota pode envolver diversos transbordos ou longas distâncias

a caminhar entre diferentes pontos de transbordo.

A um transbordo está geralmente associado um tempo de espera pelo veículo que fará a pró-

xima ligação. Quando se apresenta resultados ao utente este critério deve ter sido sempre em conta.

Uma vez que os utentes geralmente procuram o percurso mais rápido e com menos transbordos,

é importante, sempre que possível, apresentar alternativas com menos transbordos, mesmo que o

tempo total da viagem seja superior. Finalmente, tem de se considerar que um determinado troço

pode ser servido por diversas linhas. É então relevante desenhar um algoritmo capaz de selecionar

a melhor alternativa mesmo nestas condições. Alguns algoritmos escolhem o primeiro veículo a

passar no troço em questão, no entanto essa nem sempre é a melhor opção uma vez que um outro

veículo pode chegar mais rápido ao mesmo ponto.

Ao contrário da maioria das soluções existentes, a solução que aqui será apresentada é capaz

de devolver os resultados tendo em conta o posicionamento das viaturas em tempo real. A rede

de transportes públicos que será considerada é constituída por 29 operadores, todos pertencentes à

área metropolitana do Porto. Desta rede também fazem parte 680 pontos de interesse. Sempre que

24


um utilizador pretender também deve ser possível calcular o caminho mais curto a partir de um

ponto não definido da rede. Esse ponto será identificado pela respetiva latitude e longitude. Esta

rede é multimodal uma vez que será servida por múltiplos meios de transporte, como o metro, os

autocarros e os comboios.

O algoritmo que será apresentado para além de calcular o caminho mais curto entre dois pon-

tos também é capaz de ter em conta critérios que podem ser personalizados por cada utilizador,

como o tempo máximo a pé durante uma viagem completa ou o tempo máximo a pé para comple-

tar um transbordo. Será também explicado como é que o algoritmo pode ser facilmente adaptado

para incluir novas redes de transportes públicos, ou até mesmo como se podem acrescentar crité-

rios adicionais a serem definidos por cada utilizador. Como se está a trabalhar sobre uma rede de

transportes multimodais é necessário ter em conta as estações onde as redes se encontram. Nes-

tas estações devem ser inseridas ligações a pé que correspondem aos pontos de transbordo entre

diferentes redes.

3.2 Planeamento de viagens numa rede multimodal

Antes de passar à explicação do algoritmo implementado é necessário entender como é que os

dados podem numa rede de transportes. Como já foi referido anteriormente, uma rede de trans-

portes públicos é constituída por um conjunto de paragens (representadas pelas estações presentes

na rede de transportes), por um conjunto de linhas e por um conjunto de viagens. A diferença

principal entre uma viagem e uma linha é que a uma viagem está sempre associado um tempo

específico do dia, isto é, numa viagem um veículo percorre as estações de uma linha numa certa

hora do dia (Tabela 3.1).

Para se modelar uma rede de transportes de uma maneira mais correta as viagens devem ser

subdivididas em partes que correspondem às secções em que um veículo não pára. Para cada

secção está associada uma origem e um destino e a respetiva hora de partida e hora de chegada.

Estas secções geralmente são denominadas de conexões elementares. Logo aqui se pode inferir

que uma condição que está associada às redes de transportes públicos é que estas são sempre

tempo-dependentes, já que uma viagem só pode ser percorrida em determinadas horas do dia.

Dessa maneira, um dos primeiro desafios ao modelar uma rede de transportes públicos prende-se

com o desenho correto dos calendários de modo a que seja possível calcular rotas eficientes e

ótimas dentro destas redes.

Tipicamente existem duas maneiras principais para se modelar este tipo de redes tendo em

conta os horários. São designadas como modelo tempo-dependente e modelo tempo-expandido.

De seguida será feita uma breve introdução a cada um destes modelos.

3.2.1 Modelo tempo-expandido

A ideia do modelo tempo-expandido é construir uma rede composta por eventos. Neste mo-

delo é criado um vértice para cada evento que faz parte dos horários da rede de transportes. Os

eventos são conetados na ordem em que acontecem no tempo. Dessa forma, pode ser admitido que

25


Tabela 3.1: Exemplo de horários para duas viagens distintos.

Estação Evento Hora Estação Evento HoraCMP2 Partida 12:00 CSS3 Partida 11:40

PBSS2ChegadaPartida

12:0512:07

HERD2ChegadaPartida

11:4511:50

NDA1ChegadaPartida

12:1512:17

CMP2ChegadaPartida

11:5812:00

IPO5ChegadaPartida

12:3012:32

CQ9 Chegada 12:20

CQ9 Chegada 12:50

trabalhamos com um modelo que representa as dimensões espaço e tempo. Neste modelo, quando

aplicado a um grafo, para cada ligação entre duas paragens na mesma viagem é criado um vértice.

Cada um destes vértices pode ser um vértice de partida ou um vértice de chegada. Assim, a cada

vértice está associado um respetivo tempo de partida ou tempo de chegada. Entre vértices de parti-

das e chegadas consecutivos é criada uma aresta com um peso associado, que neste caso é o tempo

que um veículo leva a percorrer essa ligação. Nas redes de transportes públicos os transbordos

devem ter sido sempre em conta. Para permitir transbordos entre veículos, todos os vértices numa

estação são ligados por arestas de transbordo. Estas arestas significam que é possível fazer um

transbordo entre as duas estações.

Numa situação real é necessário ter em conta o tempo mínimo de mudança entre duas viagens

uma vez que um utente não pode caminhar entre duas estações instantaneamente. Por essa razão

foi criado um novo modelo, o modelo realístico, que já tem em conta os tempos mínimos de

mudança entre diferentes viagens. Este modelo introduz um vértice adicional para cada partida,

o vértice de transbordo. Cada vértice de chegada é ligado a um vértice de transbordo. O vértice

de transbordo escolhido é o primeiro que respeitar a restrição do tempo mínimo de mudança

entre viagens. Este modelo está ilustrado na figura 3.1. A principal desvantagem do modelo

tempo-expandido é o elevado número de vértices e arestas que são geradas, no entanto, a sua

simplicidade é uma vantagem. Para se colmatar o eventual problema relacionado com o grande

número de vértices criados foi inventado um modelo baseado neste, o modelo comprimido, que

tem em conta uma propriedade inerente a quase todas as redes de transportes públicos: um horário

sofre poucas alterações ao longo do ano e por isso em certos casos é desnecessário modelar todas

as semanas, bastando apenas modelar uma semana e ter em consideração apenas esses horários.

3.2.2 Modelo tempo-dependente

Devido ao elevado número de vértices gerado no modelo tempo-expandido foi necessário criar

um modelo capaz de representar a rede de transportes públicos num modelo mais compacto, sem

no entanto, perder informação importante. Foi então criado o modelo tempo-dependente. Neste

modelo cada vértice do grafo corresponde a uma estação. Entre dois vértices u e v do grafo é

adicionada uma aresta se existir pelo menos uma linha a servir estas paragens pela ordem correta.

26


Figura 3.1: Exemplificação do modelo realístico da versão tempo-expandido. As ligações a trace-jado correspondem às viagens, ou seja, os utilizadores terminaram uma viagem para iniciar outra.Os vértices vermelhos correspondem a eventos de chegada, os amarelos correspondem a vérticesde transbordo e os verdes correspondem a vértices de partidas.

O valor que está associado a uma aresta entre dois vértices é uma função do tempo e geralmente

indica o tempo que um veículo leva a percorrer a ligação.

Neste modelo também existe um modelo realístico, em que é possível ter em consideração o

tempo mínimo de mudança entre viagens, adicionando ao grafo um vértice de linha entre cada pa-

ragem p e cada linha que passa em p. Os vértices de linha na paragem p estão conectados ao vértice

que representa a paragem p através de arestas que têm como valor o tempo mínimo de mudança

p, tempo esse que é considerado constante. Uma viagem é modelada através dos vértices de linha

que conetam vértices de paragens consecutivas. As viagens ao longo de um dia podem ser mode-

ladas facilmente atribuindo ao valor das arestas que conetam paragens consecutivas uma função

linear. Essa função retorna o tempo que uma ligação demora a ser percorrida numa determinada

viagem ao longo do dia. Este modelo está exemplificado na figura 3.2.

3.2.3 Modelo baseado em frequências

Este modelo introduzido em 2014 tenta tirar partido da periodicidade dos veículos nas redes de

transportes públicos. Se durante um intervalo de tempo (por exemplo, das 15:00 às 19:00) é sabido

que um transporte público efetua viagens de 15 em 15 minutos então é mais eficiente guardar o

intervalo de tempo e a frequência do que guardar todos os eventos individualmente.

Neste modelo os vértices correspondem a paragens e entre duas paragens u e v é adicionada

uma aresta se estas paragens fizerem parte de uma linha pela respetiva ordem. O valor atribuído

às arestas não é o tempo que um veículo demora a percorrer a ligação, mas antes um conjunto de

tuplos que consistem no tempo de partida dp, num intervalo de tempo ∆ e numa uma frequência f.

27


Figura 3.2: Exemplificação do modelo realístico tempo-dependente. Os vértices amarelos cor-respondem a vértices de paragens e os vértices vermelhos correspondem a vértices de linhas. Asarestas que ligam os vértices de paragens aos vértices de linha representam o tempo mínimo demudança na paragem.

Através destes tuplos é possível comprimir um intervalo de tempo de viagens, tornando a pesquisa

de viagens mais rápida e o programa mais eficiente em termos de consumo de memória. Com

estes valores, todos os horários no intervalos de tempo definido podem ser facilmente construídos,

calculando dp+ fi, mas tendo em conta a restrição imposta pelo intervalo de tempo ∆ através da

fórmula dp+fi≤ dp+∆.

3.3 Metodologia

Depois de se ter identificado e explicado vários métodos genéricos para o cálculo de rotas em

redes de transportes públicos, é possível agora estabelecer uma metodologia capaz de se adaptar à

rede de transportes públicos na área metropolitana do Porto. Como já foi abordado nas secções an-

teriores já existe um sistema de cálculo de rotas em funcionamento. O novo sistema de cálculo de

rotas deve ser mais eficiente e ao mesmo tempo devem ser mantidas as mesmas funcionalidades.

Atualmente, os utentes que utilizam o MOVE-ME têm duas opções de cálculo de rota à sua dispo-

sição, o Route Finder e o Route Builder. A primeira opção, o Route Finder, permite aos utentes

calcularem o caminho mais curto entre diversos pontos da rede de transportes. Estes pontos podem

ser paragens de autocarro, metro ou comboio, e ainda pontos de interesse. Opcionalmente, podem

também selecionar a hora em que desejam partir. Se não quiserem partir imediatamente podem

selecionar uma hora até aos 3 dias seguintes. A segunda opção, o Route Builder, permite fazer

pedidos mais detalhados ao sistema. Nesta opção é possível selecionar o operador e a linha que

se pretende percorrer. Para se completar o pedido deve-se também escolher a paragem de origem

e destino para a linha selecionada. Tal como na opção apresentada anteriormente, aqui também

é possível construir uma viagem com diversos troços, sem que tenham de fazer parte do mesmo

operador. Adicionalmente, também é possível selecionar pontos que não estão definidos na rede

28


de transportes. Como foi referido anteriormente estes pontos GPS são definidos pela latitude e

pela longitude.

De seguida serão apresentados todos os passos que fazem parte da metodologia implementada.

Será explicado como é que a rede de transportes públicos é construída e armazenada em memória,

como é que o algoritmo RAPTOR foi implementado para funcionar corretamente com a rede de

transportes públicos do Porto e como é que no final é aplicado o cálculo com dados em tempo real.

3.3.1 Criação da Rede de Transportes

O primeiro passo do programa de cálculo de rotas é extrair as informações de uma base de

dados da rede de transportes e, uma vez tratados e organizados, reconstruir esses dados utilizando

estruturas de dados apropriadas. Neste programa é possível extrair os dados entre duas datas ar-

bitrárias, desde que a data final seja igual ou superior à data inicial. É também possível escolher

os operadores que se pretende adicionar na rede de transportes. Durante o desenvolvimento do

programa foram utilizados todos os operadores que fazem parte da área metropolitana do Porto,

totalizando 29 operadores. Para cada um dos operadores são extraídas todas as linhas, que sub-

sequentemente serão adicionadas a uma estrutura de dados que armazena as linhas de todos os

operadores. Quando não é importante manter a ordem é preferível utilizar uma estrutura de da-

dos que internamente utiliza hashing, uma vez que permitem identificar rapidamente elementos

numa coleção. Ao contrário das listas, estas estruturas de dados permitem identificar elementos

em O(1), enquanto que as listas identificam os elementos em O(N) no pior caso possível (quando

o elemento está no final da lista).

Na base de dados do sistema da OPT existem dois tipos de linha; a linha circular que só tem

uma direção e as restantes que regra geral têm direção de ida e de volta. A cada linha estão as-

sociadas diversas variantes que podem existir para além da principal. Estas variantes representam

percursos menores de uma linha que só estão em vigência durante certas horas do dia. Por exem-

plo, considerando a linha 205 da STCP é possível ver que o percurso principal em direção ao

Castelo do Queijo começa em Campanhã, passa por São Roque e termina no Castelo do Queijo.

Durante certas alturas do dia algumas viagens começam em São Roque e não em Campanhã como

acontece no caso anterior. São estas pequenas diferenças na mesma linha que representam as va-

riantes (Figura 3.3). No sistema desenvolvido durante a dissertação as variantes de uma linha são

consideradas linhas diferentes uma vez que não partilham exatamente as mesmas paragens. As-

sim, no final existem mais linhas do que originalmente, quando se extraíram os dados do sistema

da OPT. A cada uma destas variantes está associado um conjunto de paragens por uma determi-

nada ordem. É necessário colocar as paragens na ordem correta antes de se adicionar esta variante

ao sistema desenvolvido. Como o número de linhas é muito elevado, o processo de extração de

variantes é executado de forma paralela, tirando assim partido de todos os núcleos do CPU.

O algoritmo escolhido para desenvolver o novo sistema de cálculo de rotas trabalha essenci-

almente sobre horários, logo é necessário criar uma estrutura de dados suficientemente robusta e

eficiente para lidar com toda a complexidade de horários na rede. Depois de se extrair todas as

variantes da rede de transportes é necessário construir os horários para cada uma.

29


Figura 3.3: Exemplo simplificado da linha 205 da STCP. A paragem A representa Campanhã, aparagem C representa São Roque e a paragem F representa o Castelo do Queijo. É possível veri-ficar que na mesma linha existem variantes, representadas pelas ligações e preto e pelas ligações averde, logo as duas variantes devem ser entendidas como sendo duas linhas distintas uma vez quenão partilham exatamente a mesma sequência de paragens.

O sistema atual da OPT já permite extrair os horários para uma determinada linha, e conse-

quentemente para cada variante da linha. A informação retornada nesta chamada à API é bastante

desorganizada uma vez que todas as viagens para um dia são retornadas numa única lista. Uma

vez que cada viagem está identificada por um ID, é necessário criar uma nova lista de listas, onde

as viagens são devidamente agrupadas pelo respetivo ID. Assim, cada elemento dessa lista é uma

lista que contém as horas de passagem de um veículo nas paragens que fazem parte dessa via-

gem. A partir daqui é necessário converter os dados de cada elemento da lista de listas para uma

estrutura de dados interna, utilizada pelo novo sistema. Para cada viagem numa linha são guarda-

das informações como a paragem que se está analisar, a ordem dessa paragem na linha e a hora

chegada e partida nessa paragem.

Ao contrário do sistema da OPT que armazena o número de minutos que se passaram desde

o início do dia, no novo sistema são armazenados elementos de uma estrutura de dados capaz de

lidar com datas e horas. Quando se está a analisar as paragens de uma linha é considerado que na

primeira paragem a hora de chegada é o máximo valor representável e na última paragem a hora

de partida também é considerada como sendo o máximo valor representável pelo sistema (Tab.

3.2). Depois de calculadas todas as viagens estas são associadas às respetivas linhas de que fazem

parte para serem posteriormente utilizadas pelo algoritmo de cálculo de rotas.

Após o passo executado anteriormente é certo que todas as paragens da rede transportes foram

analisadas. Desse modo, todas as linhas da rede são novamente percorridas e as paragens da linha

são adicionadas a uma estrutura de dados baseada em hashing. De seguida é necessário corrigir

erros que foram gerados nos passos anteriores ao criar as horários de cada linha. Por vezes duas

variantes v1 e v2 da linha l1 fazem parte da mesma variante e por essa razão devem ser unificadas.

Não basta apenas unificar todas as viagens dessas variantes já que uma das duas variantes pode

ter viagens que não são partilhadas pela outra. Para se corrigir este erro é necessário iterar por

cada viagem t1 de cada linha da rede de transportes e construir uma nova lista que corresponde

ao conjunto das linhas que têm o mesmo nome da linha l1 (diferente do nome da variante), a

mesma direção e o nome da variante diferente. Para cada uma das viagens t2 desta nova lista é

verificado se o tempo de chegada ao destino da viagem t1 é exatamente igual ao tempo de partida

da viagem t2. É possível fazer esta comparação uma vez que no sistema da OPT é considerado que

30


Tabela 3.2: Exemplo de um conjunto de viagens para a variante principal da linha 205 da STCP.A cada paragem está associado um tempo de chegada e de partida. Na primeira paragem de cadaviagem o tempo é o máximo representável e na última paragem o tempo de partida é o máximorepresentável.

Linha 205 da STCP - Variante 0 (principal)Paragens Viagem 1 Viagem 2 Viagem 3

IPO5Partida: 12:00Chegada: INF

Partida: 12:30Chegada: INF

Partida: 13:00Chegada: INF

ST2Chegada: 12:10Partida: 12:10

Chegada: 12:40Partida: 12:40


AML3Chegada:12:12Partida: 12:12



CPU2Chegada: 12:15Partida: 12:15



CNG2Chegada: 12:20Partida: 12:20



QTL2Chegada: 12:23Partida: 12:23



AV2Chegada: 12:30Partida: INF

Chegada: 13:00Partida: INF

Chegada: 13:30Partida: INF

os tempos de chegada e de partida num ponto intermédio de uma viagem são exatamente iguais.

Se os pontos forem iguais então provavelmente foi encontrado um erro e na verdade estas viagens

correspondem a apenas uma viagem t3 de uma outra variante v3.

Para se confirmar o erro é ainda necessário verificar se a paragem de origem da viagem t2 é

igual à paragem de destino da viagem t1, e ainda que o campo que guarda a ordem da paragem é

igual na paragem de origem da viagem t2 e na paragem de destino da viagem t1. Se todas estas

condições forem verdadeiras então aconteceu um erro e é necessário construir a nova variante

de linha v3 que será constituída pelas paragens da variante v1 e pelas paragens da variante v2

(3.4). Inicialmente, é preenchida uma estrutura de dados composta pelas paragens da variante v1.

A hora de partida da última passagem da viagem t1 necessita de ser atualizada para a hora de

chegada dessa viagem porque na verdade já não vai poder ser considerada o fim da viagem. De

seguida são adicionadas as paragens que fazem parte da variante v2 e a ordem das passagens de

toda a nova viagem é corrigida para se ter a certeza de que as viagens seguem a mesma numeração

do campo que representa a ordem, começando pelo número 0.

Após terminada esta fase inicial de correção é criado um nome temporário para a nova variante

de linha composta pela concatenação do nome das variantes v1 e v2. Se já existir uma variante

composta por esse nome então apenas se adiciona a nova viagem à lista de viagens da variante

com esse nome. Se esta variante de linha ainda não existir é necessário adicionar a nova variante

v3 à lista de todas as variantes. A viagem t3 é adicionada à lista de viagens da variante v3 e as

viagens t1 e t2 são removidas das variantes de onde faziam parte. Finalmente é feita uma última

verificação que adiciona as variantes v1 e v2 a uma lista com variantes marcadas para remoção se

31


Figura 3.4: Aqui é possível observar que existem duas variantes na mesma linha e que a a últimaparagem da variante vermelha é igual à primeira paragem da variante azul. Se a ordem das para-gens na linha e as horas de chegada e partida de duas viagens coincidirem então as duas variantesdevem ser unificadas.

o número de viagens em cada uma das variantes for igual a 0.

Quando todas as variantes da rede têm o horário construído é necessário ordenar as viagens

para cada variante v ∈ V. O critério selecionado para ordenar as viagens foi o tempo de partida

da viagem. De seguida é preenchida uma estrutura de dados que mais tarde será útil durante a

execução do algoritmo. Esta estrutura armazena todas as variantes que passam em cada uma das

paragens da rede de transportes públicos. Os dados relativos às variantes e aos horários são arma-

zenados num ficheiro XML, para caso assim seja pretendido se possa carregar os dados relativos

aos dias especificados a partir dos respetivos ficheiros, tornando assim o carregamento de dados

mais rápido.

3.3.2 Extração dos Pontos de Interesse

Após se terem extraído os horários para todas as variantes e se ter procedido à correção dos

eventuais erros existentes nos horários é agora necessário adicionar à rede de transportes públicos

os pontos de interesse. Estes pontos devem ser ligados à rede através de ligações a pé. O sistema

da OPT não contém um método que permita extrair todos os pontos de interesse da base de dados,

apenas disponibiliza um método capaz de extrair os pontos de interesse num determinado raio a

partir de um ponto fornecido com as respetivas coordenadas GPS. Assim, para se extrair o maior

número de pontos de interesse possível é executado um ciclo que itera por todas as paragens da

rede de transportes. A partir das coordenadas da paragem em questão é possível extrair todos

os pontos de interesse que se encontram num determinado raio. Esse raio pode ser facilmente

personalizado, no entanto foi decidido que um valor razoável rondaria os 500 metros, distância

essa que praticamente qualquer utente está disposto a percorrer até às paragens. De notar que

500 metros seria o valor máximo da distância entre os pontos de interesse e as paragens (Figura

3.5). Uma vez que ao extrair os pontos de interesse de diferentes paragens podem existir pontos

32


Figura 3.5: Extração dos pontos de interesse representados pelos nós de cor verde, partindo doponto D pertencente a uma variante de linha (nós de cor vermelha).

de interesse repetidos, aqui foi novamente utilizada uma estrutura de dados baseada em hashing

que apenas contém um conjunto de objetos únicos.

Este processo é executado somente uma vez, aquando da criação da rede de transportes. Os

objetos desta estrutura de dados serão serializados num ficheiro XML, permitindo assim que nas

próximas vezes o carregamento de dados seja feito de uma forma muito mais rápida. Uma vez

que para se obter os pontos de interesse a partir de uma paragem é necessário fazer uma chamada

à base de dados da OPT, o tempo de carregamento recorrendo a ficheiros XML pode ser reduzido

para cerca de 95%.

3.3.3 Indexação de paragens e pontos de interesse

Depois de se ter extraído todas as paragens e todos os pontos de interesse então é seguro

afirmar que o núcleo da rede está construído. É agora importante indexar cada uma das paragens

e cada um dos pontos de interesse para que durante a pesquisa no algoritmo de cálculo de rotas se

possa ter um acesso rápido ao local pretendido. Para isso foi utilizada uma estrutura de dados que

associa uma chave a um valor. Neste caso foi definido que a chave é o código de cada paragem

s e de cada ponto de interesse p, e o valor é o objeto que tem como código o valor de s para o

caso das paragens e p para o caso dos pontos de interesse. É possível utilizar esta estrutura de

dados eficientemente já que todas as paragens e todos os pontos de interesse têm códigos únicos,

evitando colisões de chaves e tornando assim a pesquisa eminentemente mais rápida. Neste passo

33


Figura 3.6: Associação de cada paragem às linhas que por ela passam. É possível observar que aparagem C é servida pelas linhas vermelha, verde e castanha.

também é utilizada uma estrutura de dados que associa a cada paragem todas as linhas que por ela

passam, que será útil durante a execução do algoritmo implementado (Fig. 3.6).

3.3.4 Criação das ligações a pé

O último passo importante para se ter uma rede de transportes públicos completa é criar todas

as ligações a pé. Neste passo serão criadas ligações a pé entre diferentes paragens, entre os pontos

de interesse e entre pontos de interesse e paragens para se garantir a maior cobertura possível dos

transbordos. Uma vez que pode existir um grande número de paragens, este passo é executado

recorrendo a classes que estejam preparadas para paralelismo, tirando assim partido de todos os

núcleos do processador em que o programa é executado.

Durante a fase de construção de ligações a pé é feita uma pesquisa no espaço de um raio

definido através de um parâmetro. Aqui já não é necessário fazer um pedido à base de dados

uma vez que todos os dados referentes às paragens e aos pontos de interesse já foram extraídos

anteriormente, tornando assim este passo mais rápido. A pesquisa é feita tendo em conta as coor-

denadas geográficas associadas a cada paragem s ou ponto de interesse p. Neste passo é executado

o algoritmo Depth-first search (DFS) a partir de cada paragem ou ponto de interesse. É possível

configurar no programa um parâmetro que indica o tempo máximo a pé entre duas ligações, em

minutos. Este tempo é calculado tendo por base outro parâmetro que indica a velocidade média a

caminhar de um utente, em metros por segundo. Neste caso foi definido um valor razoável para

a velocidade a caminhar como sendo 1 metro por segundo, o que equivale a 3.6 quilómetros por

hora. Aqui, o tempo a caminhar é sempre calculado entre a paragem s ou o ponto de interesse

34


Figura 3.7: Criação das ligações a pé a partir da paragem D. São criadas ligações a pé para para-gens, representadas pelos nós vermelhos, e ligações a pé para pontos de interesse, representadospelos nós verdes.

p e o local atualmente a ser analisado pelo algoritmo Depth-first search (Fig 3.7). Se o tempo a

caminhar entre os dois locais for igual ou inferior ao tempo máximo entre duas ligações então é

criada uma ligação bidirecional a pé entre os dois locais. As ligações a pé estão definidas numa

estrutura de dados que é representada por uma coleção de chaves e valores. A chave é um objeto

paragem ou ponto de interesse e o valor associado é uma estrutura de dados do mesmo tipo, em

que a chave é representada por uma paragem ou pontos de interesse para onde se pode caminhar e

o valor é o tempo a caminhar até esse local. São criadas duas ligações a pé, uma partindo do local

original para o local a ser analisado pelo algoritmo DFS, e outra partindo do local a ser analisado

pelo DFS até ao local original.

Através deste passo é possível assegurar todos os transbordos possíveis, tendo sempre em

conta a restrição do tempo máximo a caminhar. De seguida todas as ligações a pé são armazenadas

num ficheiro XML, possibilitando assim um carregamento de dados mais rápido na próxima vez

em que se carregue a aplicação. Se o ficheiro já existir então os dados são carregados desse ficheiro

e é feita uma verificação adicional. Ao analisar todas os locais representados no ficheiro XML, se

algum já não existir na rede então as ligações a pé para esse local serão removidas, permitindo

assim manter a consistência entre os locais existentes na rede e as ligações a pé.

3.3.5 Agrupamento de paragens

Após se terminado a criação das ligações a pé dentro da rede de transportes, é agora necessário

proceder ao agrupamento das paragens antes de se poder utilizar a rede para cálculo de rotas.

Neste passo as paragens serão agrupadas em clusters, pelo critério de proximidade em metros.

Este critério é um parâmetro, logo pode ser facilmente personalizado. Neste passo poderá ser

considerado um conjunto C que contém as paragens s1, s2, s3, s4. Aqui não é permitido que o

35


conjunto C contenha paragens repetidas. No programa existe uma estrutura de dados capaz de

guardar em que cluster cada paragem se encontra.

Os clusters serão utilizados durante a fase de cálculo de rotas porque permite obter rapida-

mente as paragens que se encontram próximas de outra paragem. Uma vez que o algoritmo imple-

mentado calcula o percurso mais rápido de um local da rede para todos os outros, então se durante

a fase de cálculo de rotas não forem encontrados resultados para a paragem pretendida pode ser

rapidamente verificado se foram encontrados resultados para uma paragem pertencente ao mesmo

cluster, evitando assim que um utilizador não obtenha resposta durante o cálculo de rotas. Com

esta estrutura de dados é possível evitar pedidos adicionais à base de dados, tornando assim todo

o processo mais rápido e eficiente.

Os dados resultantes deste passo são armazenados num ficheiro XML. Quando se executa o

programa numa próxima vez é possível extrair os dados deste ficheiro, com uma verificação adi-

cional. Todas as paragens da rede são verificadas e se alguma não estiver nos clusters carregados

a partir do ficheiro XML então será calculado um novo cluster a partir desta paragem.

3.4 Algoritmo - Cálculo de Rotas

Desde o início do desenvolvimento da dissertação foi tido sempre em conta que a rede de

transportes públicos onde se estava a trabalhar era complexa e bastante densa. O algoritmo atual

consegue retornar bons tempos de resposta quando o número de operadores é reduzido (foi cons-

truído inicialmente para funcionar com a rede da STCP e do Metro do Porto apenas), no entanto

quando o número de operadores aumenta o tempo de resposta do algoritmo também aumenta con-

sideravelmente. O principal desafio era então implementar um algoritmo que fosse capaz de lidar

com uma rede que contenha um número elevado de operadores, mas que ao mesmo tempo não

perdesse ao nível do desempenho. O algoritmo RAPTOR é capaz de trabalhar exclusivamente com

dados em tempo real, no entanto o acesso às próximas passagens em cada paragem em tempo real

é muito custoso. Sendo assim, este algoritmo trabalha inicialmente com dados relativos aos horá-

rios planeados uma vez que podem ser armazenados em memória, e no final tenta encontrar uma

viagem exatamente igual tendo por base os dados em tempo real para a mesma hora do dia. Esta é

a melhor solução para manter os tempos de resposta baixos e ao mesmo tempo não sobrecarregar

a base de dados do sistema.

O algoritmo será executado num CPU com 16 núcleos, logo, desde início foi definido que

seria importante ter em conta um algoritmo capaz de ser paralelizado, ao contrário do algoritmo

atual que apenas é executado num único núcleo do CPU. Não foi implementado um algoritmo

baseado no Dijkstra nem em grafos, mas antes um algoritmo que trabalhar essencialmente sobre o

conceito de horários de uma rede de transportes públicos. O algoritmo escolhido foi o RAPTOR.

A única restrição a respeitar são os webservices atuais, que não podem ser alterados, uma vez que

não estão relacionados com o módulo de cálculo de rotas. Foram implementadas duas variantes

do algoritmo; uma que calcula uma rota que parte depois de uma determinada hora introduzida

pelo utente e uma segunda que calcula uma rota que termine antes da hora introduzida pelo utente.

36


Para a segunda variante o algoritmo é executado a partir do destino e tenta sempre encontrar um

caminho que parta o mais tarde possível. Assim é possível garantir ao utente que chegará ao

destino a horas e que o tempo de espera nos transbordos será minimizado.

O algoritmo implementado apresenta vantagens essencialmente ao nível do tempo de resposta.

Os dois são capazes de retornar o caminho ótimo, no entanto no novo algoritmo é ainda possível

definir parâmetros dinâmicos, tal como o tempo máximo a caminhar durante uma viagem. Esta

opção atualmente ainda não pode ser utilizada pelos utentes, mas poderá ser utilizada logo que as

aplicações do lado do cliente assim o permitam. Este algoritmo também é capaz de devolver ao

utilizador diferentes percursos, tendo em conta o tempo da viagem, o número total de transbordos

e o tempo a caminhar. Tipicamente as viagens são apresentadas por ordem crescente em relação

ao número de transbordos e de seguida em relação ao tempo total da viagem. O parâmetro que

determina o número máximo de transbordos também pode ser facilmente personalizável no servi-

dor, no entanto um número maior de transbordos implica que o tempo de execução do algoritmo

também seja superior.

Durante o desenvolvimento do programa foi inferido que praticamente todas as viagens dentro

da rede do Porto podem ser feitas apenas com 1 ou 2 transbordos. O algoritmo é capaz de cal-

cular o caminho mais curto entre 3 tipos de pontos: paragens, pontos de interesse e coordenadas

geográficas. As coordenadas geográficas são tratadas de um modo diferente no programa. Uma

vez que nenhum objeto do tipo coordenada geográfica faz parte da rede de transportes públicos,

sempre que um utilizador fizer um pedido que contenha objetos desse tipo é criada uma paragem

temporária, justamente com as ligações a pé para paragens próximas. Assim que este ponto tem-

porário fizer parte da rede já é possível executar o algoritmo de cálculo de rotas a partir do ponto

do tipo coordenada geográfica. No final da pesquisa estes pontos e as respetivas ligações a pé

são removidas da rede. Os pontos criados neste passo são adicionados a uma lista que contém

os pontos do tipo coordenada geográfica que podem ser acedidos durante a fase de pesquisa do

algoritmo. Assim, se existirem pedidos a serem executados em paralelo, a pesquisa nesses pe-

didos nunca será expandida para pontos do tipo coordenada geográfica que não estejam na lista

de pontos permitidos. Se essa condição fosse permitida em qualquer pesquisa existiria o risco de

se permitir expandir a pesquisa para um ponto que poderia ser eliminado a qualquer momento da

rede de transportes.

Um aspeto relevante no cálculo de rotas em redes de transportes públicos é a sugestão de per-

cursos alternativos ao mais rápido. A abordagem seguida em relação a essa questão foi simples. Se

o algoritmo for executado uma vez pode retornar até K percursos diferentes, onde K - 1 representa

o número máximo de transbordos permitidos. Para se ter a certeza que são retornados o maior

número de percursos distintos em horas próximas, então o algoritmo é executado N vezes, acres-

centando 5 minutos ao tempo de partida em cada iteração. O parâmetro N é personalizável e tem

como valor padrão 3. Seria possível seguir outras abordagens para se obterem diversos percursos.

Uma delas passava por calcular o algoritmo N vezes a partir de pontos iniciais e finais distintos

mas próximos dos originais, no entanto, como esses geralmente têm ligações a pé para os pontos

inicialmente pedidos então o resultado final iria muito provavelmente ser o mesmo em todas as

37


iterações.

Com vista a suportar a variante Route Finder, o programa que foi implementado também su-

porta pesquisas com um número arbitrário de pontos intermédios. Se um utente se quiser deslocar

entre os pontos A e C, mas pretender passar pelo ponto B antes de terminar a viagem no ponto C,

então será necessário executar o algoritmo de cálculo de rotas duas vezes. Primeiro será executado

entre os pontos A e B e numa segunda vez será executado entre os pontos B e C. Na execução entre

os pontos B e C a hora de partida que será tida em conta pelo algoritmo será a hora de chegada

ao ponto B a partir de A. Os pontos que são passados para o algoritmo não necessitam de ser do

mesmo tipo, podem ser combinados entre pontos de interesse, paragens e coordenadas geográficas.

Após o cálculo do algoritmo o programa tenta extrair os dados em tempo real para cada um

dos percursos retornados. Dos 29 operadores que fazem parte da rede de transportes, apenas

a STCP e o Metro do Porto disponibilizam dados em tempo real. Como na STCP estes dados

sofrem diversas oscilações para pedidos feitos num curto espaço de tempo, então foi decidido que

o tempo real só iria ser extraído para o primeiro segmento do percurso. Os tempos de chegada e

de partida dos restantes segmentos do percurso são ajustados tendo em conta o primeiro segmento

do percurso. De seguida será explicado como é que o algoritmo é executado quando é feito um

pedido de cálculo de rota entre duas paragens apenas.

3.4.1 RAPTOR - Execução do algoritmo

Para se entender melhor o algoritmo implementado, este será exemplificado numa rede de

transportes virtual e mais simples (Figura 3.8). Esta rede é composta apenas por paragens e uma

ligação a pé. Neste exemplo o objetivo é calcular o caminho mais rápido entre os pontos 1 e 6 com

partida às 14:00h. É possível observar que esta rede é constituída por 4 linhas e por uma ligação

a pé entre os pontos 1 e 2. Como foi explicado anteriormente o algoritmo RAPTOR funciona por

rondas, onde K rondas correspondem a K - 1 transbordos. Inicialmente o tempo de chegada é

colocado a infinito em todos os pontos da rede, exceto no ponto de partida, que é colocado no

valor indicado pelo utente no campo hora de partida (14:00h neste caso). Assim é garantido que

só são pesquisadas viagens que partam depois da hora indicada. O algoritmo é iniciado com K =

0. Durante a execução deve ser mantida uma lista MarkedPlaces que guarda os pontos da rede a

serem analisados pelo algoritmo na próxima ronda, uma lista BestArrivalTime que guarda o melhor

tempo de chegada na ronda K para cada um dos pontos da rede e uma lista BestKnownValue que

regista o melhor tempo de chegada global em cada ponto.

Quando K = 0, o único ponto marcado é o ponto de partida. Como o ponto 1 não é uma

paragem, então devem ser calculados os tempos de chegada a outros pontos da rede partindo

do ponto 1. No exemplo, partindo de 1 só é possível alcançar o ponto 2. Deve ser calculado

o tempo a caminhar entre 1 e 2. Assumindo que se demora 2 minutos a caminhar entre 1 e 2

então pode ser afirmado que é possível alcançar 2 às 14:02. Se o melhor tempo na ronda atual

em 2 (infinito) for superior ao tempo calculado (14:02h) então esse valor deve ser atualizado para

o valor calculado (14:02h). Caso este valor também seja inferior ao melhor valor global nesse

ponto então o melhor valor global também tem de ser atualizado. Como o ponto 2 foi analisado e

38


Tabela 3.3: Execução da ronda K = 0 do algoritmo RAPTOR.

Ronda 1 2 3 4 5 6K = 0 Tempo de chegada 14:00 14:02 INF INF INF INF

ainda não está marcado então deve ser adicionado à lista de pontos marcados MarkedPlaces para

serem analisados na próxima ronda. Finalmente é registado que o melhor valor partindo de 2 foi

alcançado a partir de 1. Esta estrutura de dados é útil para no final se conseguir reconstruir o

melhor caminho. Os resultados estão ilustrados na tabela 3.3.

Na próxima ronda, K = 1, os tempos de BestArrivalTime da ronda K - 1 são copiados para a

ronda K para se definir um limite superior para os tempos de chegada. Com este limite definido é

assumido que nas próximas rondas só podem ser pesquisadas viagens que melhorem o tempo em

cada ponto da rede. Agora será repetido um ciclo de instruções até se encontrar um caminho que

leve à paragem de destino. O ciclo é executado entre K = 1 e K = MaxK. O valor de MaxK pode

ser personalizável e corresponde ao número máximo de rondas que o algoritmo pode executar. Em

K = 1 é sabido que o único ponto que faz parte da lista MarkedPlaces é o ponto 2. O primeiro

passo do algoritmo nesta fase é verificar quais são as linhas que passam pelos pontos na lista

MarkedPlaces e registar esses dados numa lista Q. A lista Q associa a cada linha um ponto. Se na

lista MarkedPlaces estiverem marcados 2 pontos que são servidos pela mesma linha L, aquele que

será associado à linha L será aquele que contém o menor valor do campo ordem, ou seja, o que

aparece primeiro na linha. Depois de executado este passo a lista MarkedPlaces poderá ser limpa.

No exemplo apresentado as linhas 204 e 505 estão associadas ao ponto 2.

O próximo passo do algoritmo é iterar por cada par (r, p) ∈ Q, onde r representa uma linha

e p representa um ponto da rede associado a essa linha, e verificar se o tempo em cada uma das

paragens da linha pode ser melhorado. Para isso primeiro é necessário encontrar uma viagem

que faça parte de cada linha. A viagem selecionada é a primeira que tenha como hora de partida

um tempo superior ao que está marcado em p. No caso do ponto 2, terão de ser encontradas

viagens que partam depois das 14:02h. Os resultados das operações estão apresentados na tabela

3.4 e na figura 3.9. Como é possível verificar, o tempo de chegada nas paragens 3 e 4 foram

melhorados, logo são marcadas para serem analisadas nas próximas rondas e são adicionadas à

lista MarkedPlaces. Também é registado que o melhor tempo para se chegar às paragens 3 e 4 foi

alcançado a partir da paragem 2. Estas paragens correspondem aos locais onde é possível fazer

um transbordo.

A próxima ronda é a ronda K = 2 e aqui os procedimentos serão semelhantes aos anteriores.

Nesta ronda a linha 204 e a linha 700 estarão associadas à paragem 3 e as linhas 204 e 205 estarão

Tabela 3.4: Resultados após a ronda K = 1.

Ronda 1 2 3 4 5 6K = 0 Tempo de chegada 14:00 14:02 INF INF INF INFK = 1 14:00 14:02 14:05 14:12 INF INF

39


Figura 3.8: Rede de exemplo para o algoritmo RAPTOR.

Figura 3.9: Seleção das viagens a partir da paragem 2.

40


associadas à paragem 4. A partir da figura 3.9 é possível verificar que a partir da paragem 3 as

paragens da linha 204 nunca irão ser melhoradas. Uma vez que na paragem 3 o melhor tempo

é às 14:05h, o que o algoritmo faria para tentar melhorar os tempos nas paragens seguintes seria

encontrar a próxima viagem da linha que partisse depois das 14:05h. Ora, assumindo que ao

percorrer a mesma linha os veículos nunca se ultrapassam então o tempo 14:10h marcado na

paragem após a 3 na linha 204 nunca iria ser melhorado. Assim, na paragem 3 basta analisar a

linha 700 e na paragem 4 a linha 205. Ao analisar a linha 205 os tempos nas paragens 5 e 6 serão

melhorados desde que uma viagem seja encontrada. Deve ser registado que as paragens 5 e 6

foram alcançadas partindo da paragem 4. Os resultados estão apresentados na figura 3.10.

Nesta altura é possível observar que a paragem de destino já foi alcançada, no entanto não

é garantido que o valor 14:23h seja o melhor nesta ronda uma vez que a linha 700 a partir da

paragem 3 ainda não foi analisada. Os resultados após a análise da linha 700 partindo da paragem

3 estão apresentados na figura 3.11. Como é possível observar, um utente pode embarcar num

transporte na paragem 3 às 14:07h e alcançar a paragem 5 às 14:10h. Este tempo é melhor do

que 14:20h, que estava marcado anteriormente nessa paragem. Como o tempo melhorou então é

necessário indicar que agora o melhor caminho em 5 foi encontrado partindo de 3 e não de 4 como

estava anteriormente indicado. A paragem 5 deve ser novamente marcada para análise na próxima

ronda. Os melhores tempos estão agora indicados conforme os valores apresentados na tabela 3.5.

Atualmente o melhor percurso corresponde à seguinte sequência: 1 -> 2 -> 4 -> 6.

Se não for permitido expandir mais a pesquisa então o melhor percurso com 1 transbordo já

foi encontrado, mas caso seja permitido passar para a próxima ronda então já foi demonstrado que

muito provavelmente será possível encontrar uma solução melhor. Assumindo que é permitido

passar para a próxima ronda, K = 3, partindo agora da paragem 5 e tendo como referência o tempo

14:10h, o objetivo agora é encontrar a próxima viagem da linha 205 que tenha como tempo de

partida na paragem 5 um valor superior a 14:10h. Como é possível observar na figura 3.12, é

possível partir na paragem 5 às 14:12h e alcançar a paragem 6 às 14:15h. O tempo na paragem 6

é melhor do que aquele que estava indicado anteriormente, logo também deve ser atualizado. O

melhor caminho anterior que ligava até à paragem 6 era a paragem 4, no entanto agora esse valor

deve ser atualizado para a paragem 5. O melhor percurso na ronda K = 3 passa agora a ser 1 -> 2

-> 3 -> 5 -> 6. Como a ronda atual é a 3 então o melhor percurso foi obtido com 2 transbordos. De

facto, os transbordos feitos para encontrar a melhor viagem deram-se na paragem 3 entre as linhas

204 e 700 e na paragem 5 entre as linhas 700 e 205. Os melhores tempos para esta ronda estão

apresentados na tabela 3.6. Uma vez que o tempo da paragem 6 foi melhorado nesta ronda então

teria de ser marcada para ser analisada na próxima ronda, no entanto como a paragem 6 apenas é

servida pela linha 205 então é desnecessário passar para a ronda K = 4.

Como é possível observar, o algoritmo RAPTOR calculou o melhor tempo até todas as esta-

ções, partindo do ponto 1. Se for necessário calcular o melhor percurso até à paragem 4 na mesma

hora do dia não é necessário executar o algoritmo novamente já que é possível verificar qual foi

a paragem que se antecede à paragem 4. Assim, o resultado para a paragem 4 seria 1 -> 2 -> 4 e

para a paragem 5 seria 1 -> 2 -> 3 -> 5.

41


Figura 3.10: Rede de transportes após a análise da linha 205 a partir da paragem 4.

Durante a execução do algoritmo é possível correr de forma paralela as iterações pelos pon-

tos que estão na lista MarkedPlaces, tornando assim a pesquisa mais rápida. Como foi referido

no capítulo anterior, uma das abordagens mais corretas para se paralelizar o algoritmo passava

por calcular as linhas independentes, ou seja, linhas que não partilham qualquer paragem entre

si. A abordagem seguida durante o desenvolvimento do trabalho foi diferente. Para se paralelizar

o algoritmo utilizaram-se estruturas de dados preparadas para lidar com programas em paralelo,

evitando assim criar novos métodos para calcular linhas independentes. Dessa forma foi possí-

vel paralelizar o código apenas alterando o tipo da estrutura de dados para uma semelhante que

suportasse paralelismo.

3.4.2 Tempo Real

Após se terem completado todos os cálculos então deve ser extraída a informação em tempo

real para as viagens correspondentes. Para se proceder a este cálculo a primeira coisa que o

programa faz é questionar o servidor sobre os operadores que suportam funcionalidade em tempo

real. De seguida, para cada um dos percursos retornados pelo algoritmo o programa tenta encontrar

um troço de cada percurso onde seja possível utilizar a funcionalidade em tempo real. Se conseguir

encontrar então é feito um pedido ao servidor com as paragens correspondentes a esse troço do

percurso. A resposta retornada pelo servidor tem informações relativas aos veículos, às viagens

e ao destino de cada veículo. Como a resposta retorna informação sobre diversos veículos então


Ronda 1 2 3 4 5 6K = 0 Tempo de chegada 14:00 14:02 INF INF INF INFK = 1 14:00 14:02 14:05 14:12 INF INFK = 2 14:00 14:02 14:05 14:12 14:10 14:23

42


Figura 3.11: Rede de transportes após a análise da linha 700 a partir da paragem 3.

Figura 3.12: Rede de transportes após a análise da linha 205 a partir da paragem 5 na ronda K = 3.


Ronda 1 2 3 4 5 6K = 0 Tempo de chegada 14:00 14:02 INF INF INF INFK = 1 14:00 14:02 14:05 14:12 INF INFK = 2 14:00 14:02 14:05 14:12 14:10 14:23K = 3 14:00 14:02 14:05 14:12 14:10 14:15

43


Figura 3.13: Exemplificação da seleção da paragem de transbordo. A paragem representada pelonó amarelo representa a paragem onde um utente se encontra atualmente. Os nós vermelhosrepresentam uma linha com várias paragens.

é necessário organizar as respostas. O programa começa por agrupar os elementos pelo ID do

veículo, de seguida filtra aqueles que passam nas duas paragens e finalmente ordena os elementos

pela hora de chegada à primeira paragem. Enquanto que a STCP utiliza o campo ID do veículo

para indicar os veículos, o Metro do Porto utiliza outro campo para guardar a mesma informação

no mesmo objeto. Dessa maneira é necessário verificar verificar se o método anterior retornou

resultados. Se não retornar então é aplicado o filtro pelo segundo campo e só após o segundo filtro

é que se obtém o resultado final. Os operadores STCP e Metro do Porto armazenam informação

relativa ao tempo real para uma janela temporal de 60 minutos. Durante este cálculo se o servidor

não responder em menos de 1 segundo então o pedido é cancelado e a resposta é retornada com os

horários constituídos pelo tempo planeado (resposta original ao pedido feito pelo utente). Caso o

servidor responda, então os tempos das viagens são ajustados, como foi referido anteriormente.

Após todos os cálculos estarem terminados, a resposta é apresentada ao utilizador ordenada

pelo tempo de partida. No caso dos pedidos com pontos intermédios o procedimento é igual. Uma

vez que o objeto retornado após o algoritmo de cálculo de rotas ter executado já uniu todos os

troços das viagens então o pedido para os dados em tempo real pode ser executado da mesma

maneira. Neste momento as rotas contêm toda a informação necessária e podem ser exibidas ao

utilizador.

3.4.3 Seleção das paragens de transbordo

No programa desenvolvido durante a dissertação, o algoritmo RAPTOR foi adaptado para

servir os requisitos da OPT. De entre essas adaptações, uma das principais prende-se na seleção

das paragens de transbordo. Para exemplificar esta situação foi desenvolvido um exemplo simples

que está representado na figura 3.13.

44


Neste exemplo as ligações a pé estão representadas a tracejado. Imagine-se que neste caso o

utente se encontra na paragem representada pelo nó amarelo às 11:00h. Considerando que o utente

se desloca à velocidade de 1m/s então é assumido que consegue chegar à paragem A às 11:01h e

à paragem B às 11:08h. Pelas regras do algoritmo RAPTOR, como as paragens A e B pertencem

à mesma linha então só a primeira é selecionada, ou seja, a paragem A. Imagine-se agora que é

possível seguir uma viagem a partir da paragem A às 11:12h. Este autocarro passa na paragem B

às 11:14h. Como o melhor tempo registado nessa paragem é anterior às 11:14h (tempo registado

às 11:08h), então pelas regras do algoritmo RAPTOR o utente deveria embarcar na paragem B

em vez de embarcar na paragem A, garantindo assim que chegaria o mais cedo possível a todas

as paragens. Se o utente embarcar na paragem B irá seguir na mesma viagem que seguiria se

esperasse em A durante mais tempo. Desse modo, o programa verifica se as duas paragens têm

ligação a pé à paragem inicial e caso o utente embarque na viagem com o mesmo ID então é

selecionada a paragem onde o tempo a caminhar é menor.

45


46

Capítulo 4

Implementação

4.1 O Sistema IMS

O sistema IMS desenvolvido pela OPT é constituído por um conjunto de módulos, cada um

com uma função específica, que se interligam para fornecer um serviço aos utilizadores. Aos

utilizadores é possível utilizar a página web da aplicação MOVE-ME ou ainda a aplicação móvel,

que representa módulos distintos do sistema IMS. É a partir do website ou da aplicação móvel do

MOVE-ME que ações nos outros módulos são despoletadas. Nas secções seguintes será abordada

a arquitetura horizontal e vertical do sistema IMS e será explicado como é que todos os módulos

do sistema se interligam entre si.

4.2 Arquitetura do Sistema

O sistema IMS está bem dividido por camadas lógicas. Qualquer pedido feito ao IMS, quer

através do website, quer através da aplicação móvel, é construído e tratado da mesma maneira.

Uma vez feito o pedido, existe um módulo responsável por encaminhar o tipo de pedido para o

módulo correto para que possa ser processado. Todos os dados do sistema estão centralizados

numa base de dados apenas, por isso todos os módulos acedem à mesma base de dados. Existe

apenas a distinção entre o sistema do Porto e o sistema de Lisboa. A interface apresentada aos

utilizadores é muito semelhante e as funcionalidades das aplicações são iguais, no entanto os

servidores correm em máquinas separadas. A máquina do Porto está ligada a uma base de dados

só com dados do Porto e a máquina de Lisboa está ligada a uma base de dados só com dados de

Lisboa. Depois de terminado o processamento do pedido, é retornada uma resposta ao cliente com

os resultados pretendidos. Cada um dos módulos do sistema IMS representa um webservice, não

sendo assim necessário executar todos os módulos na mesma máquina. Assim é possível passar

um módulo que necessite de mais poder de processamento para uma máquina diferente sem que

seja necessário alterar a estrutura dos programas desenvolvidos.

47

Implementação

Figura 4.1: Esquematização da arquitetura lógica horizontal do sistema IMS da OPT.

Relativamente à arquitetura lógica horizontal horizontal, a camada mais baixa é constituída

por uma base de dados Oracle que contém os dados de toda a rede, incluindo dados sobre os ope-

radores, linhas, vigências e zoneamento. A próxima camada (superior) é constituída pela lógica de

negócio na parte do servidor. É nesta camada onde a construção da rede e o algoritmo de cálculo

de rotas será executado. Na camada de lógica de negócio na parte do cliente são recebidos os pe-

didos feitos pelas aplicações e são encaminhados para o servidor. É também nesta camada que os

pedidos são convertidos para formatos que possam ser entendidos pelo servidor e pela aplicação.

Na camada mais superior está a interface (UI), ou a camada de apresentação. Os utilizadores in-

teragem diretamente com esta camada. A parte web está construída em ASP.NET e a parte móvel

está construída em C#. A arquitetura lógica horizontal está esquematizada na figura 4.1.

Em relação à arquitetura lógica vertical, esquematizada na fgura 4.2, o primeiro módulo é o

WebClient, que é aquele com o qual os utilizadores interagem diretamente. É neste módulo que

os utilizadores podem fazer pedidos ao sistema relativos às próximas partidas, ao cálculo de rotas,

aos horários das linhas por operadores e à pesquisa de pontos de interesse num determinado raio,

especificado pelo utilizador. Quando o pedido é executado é reencaminhado para o ProxyService.

Todos os módulos do sistema devem estar ligados a este. Este módulo é responsável por encami-

48

Implementação

nhar os pedidos para os módulos corretos, de acordo com a sua especificidade. Todos os pedidos

feitos pelos utilizadores passam invariavelmente por este módulo.

Todos os outros módulos são responsáveis por fazerem o core das funções do sistema IMS.

Nenhum utilizador das aplicações tem acesso direto a estes módulos. O módulo BITA é utilizado

para se extrair informação relativa à constituição física da rede. É este módulo que dá acesso

à listagem dos operadores, às linhas por operadores, aos horários de cada linha, aos pontos de

interesse, às variantes de cada linha e às horas de passagem em cada paragem, por linha. É a este

módulo que o programa desenvolvido durante a dissertação recorre para construir e armazenar a

rede em memória.

O módulo PADA é o módulo responsável pelo cálculo de rotas. Qualquer pedido do tipo Rou-

teFinder ou RouteBuilder é encaminhado para este módulo através do ProxyService. O módulo

PADA também acede ao BITA mesmo depois de ter armazenado a rede em memória, para fazer

os pedidos relativamente às informações em tempo real. O BITA recorre ao módulo ProviderR-

TAccess para consultar os operadores que disponibilizam informação em tempo real e para extrair

as próximas partidas em tempo real. Estes dados são depois retornados para o PADA através do

módulo BITA, que por sua vez são retornados ao ProxyService, até serem apresentados ao utiliza-

dor. O módulo FARE é responsável por retornar o custo de uma viagem. Recebe como input um

cojunto de paragens que constituem uma viagem e retorna o preço da viagem. Para além disso

ainda é capaz de retornar a assinatura necessária para se completar a viagem.

O módulo MONIT é responsável por gerar logs sobre tudo o que passa pelo ProxyService. Este

módulo pode ser útil para se identificar a origem de erros que eventualmente possam estar a acon-

tecer, ou pode também ser utilizado para validar pedidos feitos pelo PADA, uma vez que todos os

pedidos e respostas deste módulo são registados pelo MONIT. Finalmente, o módulo WebAdmin

é um módulo dedicado à administração do sistema. Neste módulo é possível acrescentar alertas

para serem apresentados aos utilizadores, é possível atualizar a informação da rede de transportes

(informações como os horários e as linhas dos operadores) e é ainda possível consultador infor-

mação relacionada com a estatística dos pedidos. Permite aos operadores carregarem atualizações

de dados, bem como consultar os dados em vigor.

Como foi dito no capítulo anterior o sistema que irá substituir o PADA atual é capaz de guardar

toda a informação da rede em ficheiros XML, com vista a permitir um carregamento mais rápido

dos dados em memória. Quando for necessário é possível renovar a rede em memória, acrescen-

tando novos dias e opcionalmente removendo ficheiros com dias mais antigos. Este processo é

executado num thread à parte uma vez que é o processo mais moroso. Quando a rede para os

novos dias estiver calculada então a execução de pedidos ao algoritmo é interrompida durante uns

segundos para que os novos dados possam ser acrescentados ou removidos do programa. Este

processo evita que o algoritmo tente aceder a uma posição em memória que possa estar a ser

atualizada no momento. O algoritmo não deve estar indisponível durante mais de 1 minuto.

O programa desenvolvido durante a dissertação está preparado para lidar com alterações na

rede. Sempre que tenta fazer a renovação da rede em memória é feito um pedido ao BITA que

retorna todas as linhas que fazem parte da rede de transportes. Se os novos dias que são carrega-

49

Implementação

Figura 4.2: Esquematização da arquitetura lógica vertical do sistema IMS da OPT.

50

Implementação

dos em memória acrescentarem novas linhas que nunca foram utilizadas antes, então o programa

acrescenta as linhas em falta ao conjunto total de linhas e atualiza a estrutura de dados que indica

as linhas que passam em cada paragem. Neste passo também é necessário criar os caminhos a pé

para cada uma das novas paragens acrescentadas à rede. Finalmente, todas as viagens associadas

às novas linhas são guardadas em memória.

4.3 Esforço de desenvolvimento

Desde o início da realização da dissertação, com data efetiva no dia 16 de fevereiro, foram

contabilizadas cerca de 720 horas de trabalho, distribuídas por aproximadamente 90 dias úteis de

trabalho. Em cada dia útil foram contabilizadas, em média, 8 horas de trabalho. Dos 90 dias úteis

de trabalho, cerca de 6 (48 horas) foram reservados para o desenvolvimento de uma bateria de

testes e para a verificação dos resultados. Todos os restantes dias foram repartidos pelo estudo do

sistema IMS e pelo desenvolvimento do algoritmo de cálculo de rotas.

No total foram escritas cerca de 5100 linhas de código, das quais, cerca de 1200 fazem parte

do algoritmo de cálculo de rotas e 2300 fazem parte da construção da rede de transportes.

51

Implementação

52

Capítulo 5

Resultados e Avaliação

Neste capítulo serão apresentados alguns resultados obtidos com o algoritmo implementado

durante a dissertação, uma adaptação do algoritmo RAPTOR. Será feita uma avaliação da eficiência

do algoritmo e serão comparados os tempos de resposta entre o algoritmo atualmente em produção

e o RAPTOR. Todos os testes foram realizados acedendo a uma base de dados Oracle presente

numa máquina apenas utilizada para efeitos de testes. A execução dos testes do algoritmo foram

realizados numa máquina diferente, com as seguintes características:

• Processador Intel Core i7-3610QM @ 2.30GHz (6MB de cache, até 3.30Hz)

• Memória RAM com 8GB @ 1600Mhz

• Sistema operativo Microsoft Windows 10 64-bit

• .NET Framework 4.5

O ambiente de desenvolvimento utilizado durante o desenvolvimento da dissertação foi o Mi-

crosoft Visual Studio 2017 e a linguagem de programação escolhida foi o C#. Todos os testes

que serão apresentados foram realizados com informação relativa a todos os operadores da área

metropolitana do Porto. Os horários que fazem parte da rede de teste dizem respeito aos dias 22 e

23 de maio de 2017, que correspondem a uma segunda e terça feira respetivamente.

5.1 Construção da rede

Como foi descrito nos capítulos anteriores, numa primeira fase é necessário calcular a rede

para que possa ser armazenada em memória e posteriormente para que possa ser utilizada pelo

algoritmo de cálculo de rotas. Este é um processo moroso uma vez que requer que sejam feitos

milhares de pedidos à base de dados para se extrair as linhas, horas de passagem e pontos de inte-

resse. Os dados resultantes deste passo são guardados em ficheiros, evitando assim sobrecarregar

novamente a base de dados e ao mesmo tempo diminuindo o tempo de carregamento do programa.

Após este processo estar concluído a rede de testes tem as seguintes estatísticas:

53


• 29 operadores

• 1546 linhas

• 10830 paragens

• 133794 ligações a pé

• 28486 viagens

• 680 pontos de interesse

O número de ligações a pé aqui apresentado corresponde ao número de ligações únicas, isto é,

uma vez que as ligações a pé são bidirecionais o número aqui apresentado poderia indicar o dobro

das ligações realmente existentes, no entanto tal não acontece neste caso. Se existe uma ligação

a pé de a para b apenas é contabilizada 1 vez. De referir que das 10830 paragens existentes na

rede cerca de 50% pertencem a apenas 3 operadores (STCP, TUB e ETG), estando as restantes

distribuídas por 26 operadores.

Relativamente ao tempo de carregamento da rede para os 2 dias utilizados para efeitos de

testes, os resultados foram os seguintes:

• Extração de todas as variantes das linhas da rede com código paralelizado: ≈ 1min

• Extração dos horários para todas as linhas nos 2 dias (variantes aqui consideradas como

linhas): ≈ 29min

• Criação das ligações a pé: ≈ 9min

• Indexação de todos os locais da rede e associação das paragens às linhas que por elas pas-

sam: ≈ 25seg

• Armazenamento dos dados em ficheiros XML: ≈ 11s

Ao invés dos 40 minutos que são necessários para carregar a rede de transportes públicos a

partir da base de dados, o carregamento a partir de ficheiros XML demora, em média, 20 segundos

a terminar. Esse é o tempo necessário para se ter o programa totalmente funcional, pronto a receber

pedidos de cálculo de rotas quando o carregamento da rede é feito através de ficheiros XML. Este

valor representa uma melhoria de 98% face ao valor do carregamento pela base de dados. Para

se verificar a melhoria face ao sistema atual de cálculo de rotas, foi realizada uma comparação

de tempos de execução entre o PADA atual e o novo algoritmo. É importante referir que os dois

programas não correm sobre a mesma versão do .NET Framework.

54


5.2 Comparação das características entre os algoritmos

Depois de se ter carregado os dados em memória então o programa pode começar a receber

pedidos de cálculo de rota do servidor. O programa desenvolvido suporta todas as funcionalidades

do módulo atual do PADA. Entre elas, estas são as que mais se destacam:

• Suporta para cálculo de viagens recorrendo a horários planeados e a horários em tempo real

• Retorno de múltiplos resultados

• Consideração pelos transbordos a pé

• Suporte para paragens, pontos de interesse e coordenadas geográficas

• Suporte para múltiplos operadores

• Suporte para pesquisas do tipo Route Finder e Route Builder

O módulo desenvolvido durante a dissertação destaca-se do atual por permitir que alguns cri-

térios sejam personalizados pelos utilizadores (implementado mas ainda não suportado nas aplica-

ções MOVE-ME), como o tempo máximo a pé durante uma viagem e o tempo mínimo necessário

para se realizar um transbordo entre duas paragens. O algoritmo atual não tem qualquer suporte

para parâmetros dinâmicos, apenas otimiza as viagens de modo a que seja possível encontrar a

mais rápida.

Os dois algoritmos têm a capacidade de apresentar o custo da viagem a um utilizador, no en-

tanto esse critério não foi tido em conta uma vez que esse cálculo é realizado por um módulo

distinto, que em nada está ligado à etapa de cálculo de rotas. Importa referir que ao contrário

de outros sistemas de cálculo de rotas existentes (Google Maps por exemplo), aqui as ligações a

pé são calculadas pela distância em linha reta. No Google Maps, por exemplo, as ligações a pé

são calculadas tendo em conta as ruas existentes. Enquanto que o PADA atual tem a capacidade

de apresentar várias alternativas de rotas, o novo algoritmo tem a vantagem de poder apresen-

tar percursos com um número diferente de transbordos, ao invés do atual que pode apresentar o

mesmo número de transbordos em todas as viagens. No novo algoritmo é garantido que é sempre

encontrado o caminho mais rápido para viagens com K - 1 transbordos e K rondas.

5.3 Avaliação do cálculo de rotas

Para avaliar a qualidade dos resultados retornados pelo novo algoritmo desenvolvido, foi criada

uma bateria de testes com pontos da rede de diversos tipos. Foram testadas rotas entre paragens

da mesma operadora e paragens de operadores diferentes, foram feitos testes onde o melhor resul-

tado seria certamente apenas um caminho a pé e foram realizados testes que implicavam diversos

transbordos, obrigatoriamente. Também se realizaram testes onde o ponto de partida e o ponto de

chegada se encontravam em linhas com direções opostas. Todos os exemplos que serão apresenta-

dos de seguida foram feitos no mesmo dia e há mesma hora do dia. O último exemplo apresentado

55


mostra os resultados retornados em duas rondas do algoritmo RAPTOR, K = 1 e K = 2. Todos os

outros apresentam apenas o melhor resultado, ou seja, a rota mais rápida até ao destino. Da bateria

de testes desenvolvida foram selecionados os seguintes para servirem como exemplo:

• STCP_IPO4 (Paragem IPO) - STCP_9AG2 (Paragem 9 de Agosto)

• STCP_OUTE4 (Paragem Outeiro) - STCP_ISEP1 (Paragem ISEP)

• STCP_9AG1 (Paragem 9 de Agosto) - STCP_VDAM1 (Paragem Vitorino Damásio)

• STCP_HSJ6 (Paragem Hospital São João) - Consulado Geral do Japão (Ponto de interesse)

• STCP_IPO5 (Paragem IPO) - CP_Aveiro (Paragem da CP em Aveiro)

• Coordenadas geográficas (41.1691144, -8.5940565) - Galeria Fernando Santos (Ponto de

Interesse)

Os resultados do cálculo de rotas estão apresentados na tabela 5.1.

Como é possível verificar aqui foram realizados testes entre diversas paragens, entre paragens

e um ponto de interesse, entre uma coordenada geográfica e um ponto de interesse e entre diversos

operadores. É assumido que todos os testes foram realizados na rede de dia 22 de maio, pelas 10h

da manhã. Todos os resultados apresentados, exceto aqueles referentes ao último pedido, indicam

o melhor resultado retornado pelo algoritmo tendo em conta a restrição do número máximo de

transbordos. O tempo máximo a caminhar numa viagem foi definido como sendo 15 minutos. De

realçar que este valor é parametrizável e pode ser ajustado por qualquer utilizador. Se o algoritmo

RAPTOR se encontrar na ronda K, e na ronda K + 1 a melhor rota for exatamente igual e ainda

existirem paragens a melhorar, então será apresentado o resultado da ronda K. O número de rondas

apenas define o número máximo de transbordos, no entanto é possível que o melhor percurso possa

ser imediatamente encontrado na ronda K = 1 (0 transbordos).

No caso do cálculo de rotas entre a coordenada geográfica e o ponto de interesse foram apre-

sentados dois resultados. Na ronda K = 1 é possível fazer o percurso sem transbordos. Já na

ronda K = 2 o percurso inclui um transbordo na paragem RS_20400. Como o algoritmo RAPTOR

avançou da ronda 1 para a ronda 2 e o percurso retornado foi diferente então isso significa que foi

encontrado um resultado melhor, isto é, o tempo de chegada ao destino foi melhorado. De facto,

na ronda 1 o percurso retornado termina às 10:37 e na ronda 2 o percurso termina às 10:30, mesmo

tendo em conta o transbordo adicional. Para cada etapa da rota o algoritmo indica a paragem onde

o utente deve embarcar e desembarcar, as horas em que vai embarcar e desembarcar e as linhas e

o sentido de cada linha que deve seguir durante a viagem.

Um outro ponto fulcral desta dissertação era a capacidade de calcular rotas com pontos inter-

médios. Da bateria de testes construída para avaliar o desempenho do algoritmo foi selecionado o

seguinte exemplo:

• STCP_CVI2 (Paragem Carvalhido) - STCP_AAL1 (Paragem Av. Aliados) - STCP_IPO5

(Paragem IPO) - STCP_IPO4 (Paragem IPO)

56


Tabela 5.1: Resultados para os cálculos de rotas realizados com o algoritmo RAPTOR.

Partida / Chegada a Hora Linha ab Sentido Tipo e

Percurso STCP_IPO4 - STCP_9AG2SP_IPO4 / SP_HSJ2 10:00 / 10:02 - - CSP_HSJ2 / SP_9AG1 10:15 / 10:51 SP_705 HSJ (Metro) - Valongo VSP_9AG1 / SP_9AG2 10:51 / 10:51 - - C

Percurso STCP_OUTE4 - STCP_ISEP1SP_OUTE4 / MP_Salgueiros 10:00 / 10:03 - - CMP_Salgueiros / MP_IPO 10:08 / 10:13 MP_D Santo Ovidio - HSJ c VMP_IPO / SP_ISEP1 10:13 / 10:21 V

Percurso STCP_9AG1 - STCP_VDAM1SP_9AG1 / SP_9AG2 10:00 / 10:00 - - CSP_9AG2 / SP_MSHP4 10:19 / 10:27 SP_705 Valongo- HSJ (Metro) c VSP_MSHP4 / SP_LW2 10:33 / 10:55 SP_702 Travagem - Bolhão VSP_LW2 / SP_VDAM1 10:55 / 10:58 - - C

Percurso STCP_HSJ6 - Consulado Geral do JapãoSP_HSJ6 / SP_HSJ11 10:00 / 10:00 - - CSP_HSJ11 / SP_BS4 10:03 / 10:27 SP_704 Codiceira - Boavista VSP_BS4 / CGJ 10:27 / 10:28 - - C

Percurso STCP_IPO5 - CP_AveiroSP_IPO5 / MP_IPO 10:00 / 10:05 - - CMP_IPO / MP_São Bento 10:07 / 10:21 MP_D HSJ - Santo Ovidio c VMP_São Bento / CP_Porto 10:21 / 10:22 - - CCP_Porto / CP_Aveiro 11:05 / 12:12 CP_LA São Bento - Aveiro V

Percurso (41.1691144, -8.5940565) - Galeria Fernando Santos (K = 1)PI / SP_OUTE4 d 10:00 / 10:00 - - CSP_OUTE4 / SP_MATR1 10:07 / 10:33 SP_300 HSJ - HSJ c VSP_MATR1 / GFS c 10:33 / 10:37 - - C

Percurso (41.1691144, -8.5940565) - Galeria Fernando Santos (K = 2)PI / MP_Salgueiros d 10:00 / 10:00 - - CMP_Salgueiros / MP_São Bento 10:06 / 10:15 MP_D HSJ - Santo Ovidio c CMP_São Bento / RS_20400 10:15 / 10:22 - - VRS_20400 / RS_20403 10:25 / 10:27 RS_119 Cordoaria - R. Burgos VRS_20403 / GFS c 10:27 / 10:30 - - Ca Na coluna "Partida/Chegada"e "Linha"as paragens iniciadas por STCP referem-se ao operador

STCP, as paragens iniciadas por MP referem-se ao operador Metro do Porto e as paragensiniciadas por RS referem-se ao operador Resende.

b Na coluna "Linha", CP_LA refere-se à linha de Aveiro do operador CP.c HSJ significa Hospital de São João e GFS significa Galeria Fernando Santos.d PI significa Ponto Inicial (presente no último exemplo, nas rondas K = 1 e K = 2.e Na coluna "Tipo", "C"significa caminhar e "V"significa veículo.

57


Tabela 5.2: Resultados para os cálculos de rotas com pontos intermédios.

Partida / Chegada a Hora Linha a Sentido Tipo c

SP_CVI2 / SP_CMIC2 10:03 / 10:08 SP_301 HSJ - HSJ b VSP_CMIC2 / MP_CM 10:08 / 10:09 - - CMP_CM / MP_Trindade 10:11 / 10:14 MP_A Senhora da Hora - Fânzeres VMP_Trindade / SP_TRD5 10:14 / 10:15 - - CSP_TRD5 / SP_AAL3 10:18 / 10:19 SP_304 Trindade - Sta. Lúzia VSP_AAL3 / SP_AAL1 10:19 / 10:19 - - CSP_AAL1 / MP_Aliados 10:19 / 10:19 - - CMP_Aliados / MP_IPO 10:25 / 10:37 MP_D Santo Ovidio - HSJ b VMP_IPO / SP_IPO5 10:37 / 10:42 - - CSP_IPO5 / SP_IPO4 10:42 / 10:43 - - Ca Na coluna "Partida/Chegada"e "Linha"as paragens iniciadas por STCP referem-se ao ope-

rador STCP, as paragens iniciadas por MP referem-se ao operador Metro do Porto.b HSJ significa Hospital de São João.c Na coluna "Tipo", "C"significa caminhar e "V"significa veículo.

O resultado para este percurso está apresentado na tabela 5.2.

Como é possível observar através do resultado obtido para o cálculo da rota exemplificada,

todas as restrições relativas à hora de partida foram cumpridas. Inicialmente foi calculado um

percurso entre as paragens STCP_CVI2 e STCP_AAL1, de seguida foi calculado o percurso entre

STCP_AAL1 e STCP_IPO5, e finalmente foi calculado o percurso entre STCP_IPO5 e STCP_IPO4.

O resultado de cada percurso está indicado pelas cores laranja, lilás e vermelho, respetivamente.

A cada um destes percursos indicados está associada uma instância do algoritmo RAPTOR. Cada

um destes percursos é iniciado com a hora de chegada do percurso anterior. No caso do primeiro

percurso, a hora partida é aquela que inicialmente foi definida (neste caso, 10h do dia 22 de maio

de 2017). No final o programa unifica todos os percursos e retorna para o utilizador o percurso

como um só.

5.4 Desempenho do algoritmo

Visto que o objetivo da dissertação é evoluir os tempos de resposta do algoritmo de cálculo

de rotas, é de todo importante calcular os tempos de resposta do novo algoritmo e verificar se

melhoraram em relação ao tempo do algoritmo atual. Para isso foram executados os mesmos

pedidos apresentados anteriormente, e os tempos de resposta do algoritmo atual e do algoritmo

desenvolvido durante a dissertação foram comparados. Os resultados das melhores rotas nos 2

algoritmos foram iguais, o que representa mais uma segurança que de facto está a ser calculado o

trajeto ótimo pela adaptação do algoritmo RAPTOR. Nestes exemplos, o tempo real não foi tido em

conta, apenas se recorreu aos horários planeados. Ao não considerar o tempo real é possível obter

tempos de resposta dos algoritmos mais corretos, uma vez que o tempo de resposta do servidor

que contém a informação em tempo real não terá influência nos resultados. Foi verificado que

58


Tabela 5.3: Comparação entre os tempos de resposta do algoritmo implementado durante a disser-tação e aquele atualmente em utilização.

Algoritmo RAPTOR (ms) Algoritmo Atual (ms)Percurso STCP_IPO4 - STCP_9AG2

447 23090Percurso STCP_OUTE4 - STCP_ISEP1

221 11130Percurso STCP_9AG1 - STCP_VDAM1

260 11490Percurso STCP_HSJ6 - Consulado Geral do Japão

365 10160Percurso STCP_IPO5 - CP_Aveiro

585 26800Percurso (41.1691144, -8.5940565) - Galeria Fernando Santos

329 12080

por vezes as respostas do servidor em tempo real têm tempos de resposta muito díspares, o que

dificultaria uma interpretação correta dos tempos de resposta dos dois algoritmos. Os tempos de

comparação entre os dois algoritmos estão apresentados na tabela 5.3.

Através da análise da tabela 5.3 é evidente que a adaptação do algoritmo RAPTOR melhora

bastante os tempos de resposta dos pedidos feitos pelos utilizadores. O tempo médio registado

foi de 367 ms para a adaptação do algoritmo RAPTOR e 15792 ms para o algoritmo atualmente

em utilização pelo MOVE-ME. É importante referir que nestes resultados a restrição do tempo

máximo a caminhar foi tida em conta. Uma vez que sempre que o algoritmo RAPTOR melhora

uma estação tem de verificar se o tempo a caminhar até aí desde o início da viagem é menor ou

igual ao tempo máximo permitido a caminhar, então se a restrição não existir, o tempo de execução

ainda pode ser melhorado. A comparação com e sem a restrição do tempo limite a caminhar está

apresentada no gráfico 5.1.

Como é possível observar pelo gráfico, os tempos de execução do algoritmo RAPTOR sem a

restrição do tempo limite a caminhar melhoraram ligeiramente. A média desceu de 367 ms para

336 ms, ou seja, houve uma melhoria de cerca 8.4% em relação à média anterior.

A variável que tem mais influência no tempo de resposta do algoritmo RAPTOR é o número de

rondas permitidas. Se o número de rondas for reduzido para 2 apenas serão calculados os trajetos

a partir de uma dada origem e que contenham, no máximo, 1 transbordo. Foram executados os

mesmos testes com o número máximo de rondas definido a 2. Os resultados estão apresentados

no gráfico 5.2.

Aqui, os tempos médios de resposta com restrição de tempo a caminhar desceram de 367 ms

para 195 ms e sem restrição desceram de 336 ms para 174 ms. As melhorias foram de 46.8% e

48.2%, respetivamente.

Para se avaliar melhor o desempenho da adaptação do algoritmo RAPTOR foram executados

1000 pedidos a partir de pontos (paragens ou pontos de interesse) da rede selecionados aleatori-

59


Figura 5.1: Comparação dos tempos de resposta do algoritmo RAPTOR com e sem a restrição dotempo limite a caminhar.

Figura 5.2: Comparação dos tempos de resposta do algoritmo RAPTOR com e sem a restrição dotempo limite a caminhar, com um número máximo de rondas definido a 2.

60


Figura 5.3: Resultados da execução de 4 rondas com 1000 pedidos cada da adaptação do algoritmoRAPTOR.

amente, com horas de partida também selecionadas aleatoriamente. Para se obterem resultados

mais precisos estes pedidos foram executados 4 vezes, ou seja, foram feitos 4000 pedidos para

cada tipo de pesquisa. Os resultados obtidos com os tempos médios de execução em cada ronda

estão apresentados no gráfico 5.3.

Os resultados apresentados no gráfico 5.3 são melhores do que aqueles apresentados anteri-

ormente porque como as estruturas de dados do algoritmo são utilizadas regularmente então são

colocadas na cache do CPU, diminuíndo assim o tempo de acesso aos valores dessas estruturas de

dados. O tempo máximo obtido no conjunto de todas as rondas foi de 400ms no caso da versão

com restrição e 408 ms no caso da versão sem restrição. Já os tempos mínimos registados ficaram-

se pelos 37 ms para a versão com restrição e 60 ms para a versão sem restrição. Relativamente

aos tempos médios de execução no conjunto das 4 rondas que foram executadas, na versão com

restrição o valor situa-se em 96.5 ms e na versão sem restrição o valor médio obtido foi 81 ms.

Os últimos testes realizados foram igualmente 4 rondas de 1000 pedidos, mas com limite de

várias rondas, de 2 a 4. Neste teste só foi considerada a versão que tem em conta a restrição do

tempo a caminhar, uma vez que aqui o objetivo é testar a influência que a variação do número de

rondas tem no tempo de execução do algoritmo. Os resultados obtidos neste teste, estão represen-

tados no gráfico 5.4.

A principal conclusão que se pode tirar do gráfico 5.4 é que à medida que o número limite

de rondas vai aumentando, o tempo de resposta da adaptação do algoritmo RAPTOR também

aumenta. Este resultado já era previsível dado que o número de linhas analisadas em cada ronda

K aumenta, desde que seja possível expandir a pesquisa e encontrar pontos da rede onde o número

de transbordos seja igual a K - 1. Se não for possível melhorar nenhum ponto da rede então o

61


Figura 5.4: Resultados da execução de 4 rondas com 1000 pedidos cada da adaptação do algoritmoRAPTOR, para diferentes valores de K.

algoritmo RAPTOR retorna imediatamente um resultado.

No conjunto de todas as rondas, o tempo médio obtido para K = 2 foi 116.25 ms, para K = 3 foi

199 ms e para K = 4 foi 437.5 ms. De K = 2 para K = 3 houve um aumento do tempo de execução

de aproximadamente 71.2% e de K = 3 para K = 4 houve um aumento de 119.85%. Durante a

fase de testes reparou-se que na área metropolitana do Porto é possível atingir o caminho ótimo

em quase todos os pedidos com K = 3, ou seja, no máximo com 2 transbordos. São muito raras as

ocasiões em que o algoritmo necessita de atingir a ronda 4 para encontrar o caminho ótimo. Foi

concluído que em quase as situações apenas se deve permitir que o algoritmo execute até à ronda

3. Desse modo, é possível retornar respostas ao utilizador mais rapidamente, ao mesmo tempo que

se executa um maior número de pedidos por segundo.

62

Capítulo 6

Conclusões e Trabalho Futuro

O principal objetivo desta dissertação era a sofisticação do módulo PADA, o módulo responsá-

vel pelo cálculo de rotas numa rede de transportes públicos, que faz parte do sistema IMS. Dessa

maneira, o algoritmo implementado durante a dissertação deveria ser capaz de fazer tudo o que o

atual faz, mas os tempos de execução deveriam ser melhorados. Para se trabalhar neste módulo

teriam de se respeitar algumas restrições uma vez que não era permitido alterar os outros módulos

do sistema. Uma vez que o algoritmo atual apresenta tempos de resposta muito altos e que a docu-

mentação existente é reduzida, foi decidido que não seria viável tentar melhorar o algoritmo atual

partindo do código já existente. Foi então que se desenvolveu um novo módulo PADA, totalmente

reescrito e devidamente documentado. Para se implementar um algoritmo que fosse capaz de re-

tornar resultados corretos e percursos ótimos foi desenvolvida uma metodologia cuidada, tendo

sempre em conta os fatores eficiência e paralelismo.

Foram analisados vários métodos de pesquisa em redes de transportes públicos, desde os

tradicionais que utilizam grafos e que são devidamente adaptados para correrem em redes que

trabalham sobre horários, até aos mais atuais que não são baseados em grafos e que trabalham

diretamente nos horários. Depois de se ter feito esta análise inicial foi possível selecionar um

algoritmo que melhor se adequasse às necessidades, permitindo assim que todos os objetivos fos-

sem cumpridos. Foi escolhido o algoritmo RAPTOR, uma vez que é capaz de trabalhar com dados

exclusivamente em tempo real. Além disso, como o número de núcleos do CPU onde o algoritmo

será executado em produção é elevado então a questão da paralelização foi tida sempre em conta

desde o início da dissertação. Durante a dissertação foi explicado como é que se adaptou e parale-

lizou o algoritmo para se atingir o melhor desempenho possível no IMS. Como atualmente ainda

não é viável utilizar apenas os dados em tempo real porque implicaria um aumento exponencial

no tempo de execução do algoritmo e na sobrecarga da base de dados então foi decidido que os

dados em tempo real só seriam extraídos no final, após já se terem calculado percursos recorrendo

aos horários planeados. O algoritmo pode ser facilmente adaptável para considerar dados apenas

em tempo real, no entanto não será uma funcionalidade utilizada num futuro próximo.

63

Conclusões e Trabalho Futuro

Tendo em conta os objetivos propostos e os resultados apresentados, pode ser afirmado que

a sofisticação da componente algorítmica do módulo PADA foi concluída com sucesso. O novo

algoritmo, para além de executar mais rapidamente do que aquele que está atualmente em produ-

ção, também aceita parâmetros que podem ser personalizados para cada utilizador. Nenhum destes

critérios pode atualmente ser definido pelos utilizadores, no entanto é uma questão de tempo até

que se adapte o website e as aplicações móveis para suportar esses critérios. Este algoritmo, ao

contrário do atual, garante que encontra sempre a rota ótima até ao destino pretendido. As alter-

nativas apresentadas estão ordenadas pelo tempo de viagem e pelo número de transbordos. Tal

como o algoritmo atual, neste também é possível fazer pesquisas entre diversos tipos de pontos

na rede de transportes públicos, nomeadamente entre paragens, pontos de interesse e coordenadas

geográficas.

Apesar dos tempos de resposta serem agora bastante satisfatórios, ainda existem tarefas a fazer

no futuro. Uma vez que o algoritmo permite que os utilizadores o personalizem com diversos cri-

térios, seria interessante adicionar critérios ainda mais específicos. Alguns que foram identificados

passam pela restrição da pesquisa a apenas alguns operadores e pela exclusão de determinadas pa-

ragens. A restrição da pesquisa a apenas alguns operadores é um critério que poderá ser útil para

muitos utilizadores uma vez que assim pode ser permitido que apenas selecionem os operadores

que fazem parte da rede Andante, tirando assim partido do cartão Andante na rede metropolitana

do Porto e evitando pagar diversos bilhetes para completar um percurso.

Um outro aspeto que ainda não está a ser considerado é a minimização do custo da rota entre

dois pontos. O algoritmo RAPTOR permite utilizar múltiplos critérios de otimização para além da-

queles por defeito, o tempo da viagem e o número de transbordos. É possível adaptar facilmente o

algoritmo para lidar com esta situação. Neste caso otimizaria o custo da viagem ao invés do tempo

total da viagem, encontrando assim a viagem mais barata entre dois pontos da rede. Atualmente

apenas é possível questionar o módulo FARE e obter informação relativa ao preço da viagem e à

assinatura da rede Andante necessária para se percorrer o trajeto.

Seria também interessante adaptar o algoritmo para seguir uma abordagem semelhante ao

modelo baseados em frequências. Uma vez que existem poucas alterações na rede ao longo do

ano, seria útil alterar o algoritmo para não trabalhar sobre datas específicas, mas para trabalhar

sobre dias da semana. Assim, sempre que um utilizador fizesse um pedido numa data longínqua

seria possível retornar um resultado. Atualmente se um utilizador fizer um pedido que ultrapasse

a janela temporal que está em memória não é devolvido qualquer resultado. Algumas destas

melhorias devem ser implementadas ainda antes do algoritmo atual entrar em produção. Como

último ponto, as redes de Lisboa e do Porto serão unificadas, passando assim a permitir pedidos

de cálculo de rotas entre Lisboa e Porto. O código terá de ser adaptado para se conetar a duas

instâncias do módulo BITA, uma em Lisboa e outra no Porto, no entanto os horários que são

guardados em memória no novo módulo PADA terão exatamente o mesmo formato. Internamente

apenas serão adicionados mais elementos na rede de transportes.

64

Referências

[BD10] Reinhard Bauer e Daniel Delling. Sharc: Fast and robust unidirectional routing. J.Exp. Algorithmics, 14:4:2.4–4:2.29, January 2010. URL: http://doi.acm.org/10.1145/1498698.1537599, doi:10.1145/1498698.1537599.

[BDG+16] Hannah Bast, Daniel Delling, Andrew Goldberg, Matthias Muller-Hannemann, Tho-mas Pajor, Peter Sanders, Dorothea Wagner e Renato F. Werneck. Route Plan-ning in Transportation Networks, pages 19–80. Springer International Publishing,Cham, 2016. URL: http://dx.doi.org/10.1007/978-3-319-49487-6_2,doi:10.1007/978-3-319-49487-6_2.

[BDS+10] Reinhard Bauer, Daniel Delling, Peter Sanders, Dennis Schieferdecker, DominikSchultes e Dorothea Wagner. Combining hierarchical and goal-directed speed-up techniques for dijkstra’s algorithm. J. Exp. Algorithmics, 15:2.3:2.1–2.3:2.31,March 2010. URL: http://doi.acm.org/10.1145/1671970.1671976,doi:10.1145/1671970.1671976.

[DN12] Daniel Delling e Giacomo Nannicini. Core routing on dynamic time-dependent roadnetworks. INFORMS J. on Computing, 24(2):187–201, April 2012. URL: http://dx.doi.org/10.1287/ijoc.1110.0448, doi:10.1287/ijoc.1110.0448.

[DPSW13] Julian Dibbelt, Thomas Pajor, Ben Strasser e Dorothea Wagner. Intriguingly Simpleand Fast Transit Routing, pages 43–54. Springer Berlin Heidelberg, Berlin, Heidel-berg, 2013. URL: http://dx.doi.org/10.1007/978-3-642-38527-8_6,doi:10.1007/978-3-642-38527-8_6.

[DPW12] Daniel Delling, Thomas Pajor e Renato Werneck. Round-based public tran-sit routing. In Proceedings of the 14th Meeting on Algorithm Engineeringand Experiments (ALENEX’12). Society for Industrial and Applied Mathema-tics, January 2012. URL: https://www.microsoft.com/en-us/research/publication/round-based-public-transit-routing/.

[DPW15] Julian Dibbelt, Thomas Pajor e Dorothea Wagner. User-constrained multimodal routeplanning. J. Exp. Algorithmics, 19:3.2:1–3.2:19, April 2015. URL: http://doi.acm.org/10.1145/2699886, doi:10.1145/2699886.

[DW09] Daniel Delling e Dorothea Wagner. Time-dependent route planning. In Robust andOnline Large-Scale Optimization: Models and Techniques for Transportation Sys-tems, pages 207–230, Berlin, Heidelberg, 2009. Springer Berlin Heidelberg. URL:http://dx.doi.org/10.1007/978-3-642-05465-5_8, doi:10.1007/978-3-642-05465-5_8.

65

http://doi.acm.org/10.1145/1498698.1537599

http://doi.acm.org/10.1145/1498698.1537599

http://dx.doi.org/10.1007/978-3-319-49487-6_2

http://doi.acm.org/10.1145/1671970.1671976

http://dx.doi.org/10.1287/ijoc.1110.0448

http://dx.doi.org/10.1287/ijoc.1110.0448

http://dx.doi.org/10.1007/978-3-642-38527-8_6

https://www.microsoft.com/en-us/research/publication/round-based-public-transit-routing/

https://www.microsoft.com/en-us/research/publication/round-based-public-transit-routing/

http://doi.acm.org/10.1145/2699886

http://doi.acm.org/10.1145/2699886

http://dx.doi.org/10.1007/978-3-642-05465-5_8

REFERÊNCIAS

[EP13] Alexandros Efentakis e Dieter Pfoser. Optimizing landmark-based routing and pre-processing. In Proceedings of the Sixth ACM SIGSPATIAL International Workshop onComputational Transportation Science, IWCTS ’13, pages 25:25–25:30, New York,NY, USA, 2013. ACM. URL: http://doi.acm.org/10.1145/2533828.2533838, doi:10.1145/2533828.2533838.

[FT87] Michael L. Fredman e Robert Endre Tarjan. Fibonacci heaps and their uses in im-proved network optimization algorithms. J. ACM, 34(3):596–615, July 1987. URL:http://doi.acm.org/10.1145/28869.28874, doi:10.1145/28869.28874.

[GH04] Andrew Goldberg e Chris Harrelson. Computing the shortest path: A* se-arch meets graph theory. Technical report, Vancouver, Canada, July 2004.URL: https://www.microsoft.com/en-us/research/publication/computing-the-shortest-path-a-search-meets-graph-theory/.

[GKW06] Andrew V. Goldberg, Haim Kaplan e Renato F. Werneck. Reach for A*: Efficientpoint-to-point shortest path algorithms. In Workshop on algorithm engineering andexperiments, pages 129–143, 2006.

[Goo] Google gtfs specification. https://developers.google.com/transit/gtfs/reference/. Accessed: 2017-02-07.

[GSSD08] Robert Geisberger, Peter Sanders, Dominik Schultes e Daniel Delling. Contractionhierarchies: Faster and simpler hierarchical routing in road networks. In Experimen-tal Algorithms: 7th International Workshop, WEA 2008 Provincetown, MA, USA, May30-June 1, 2008 Proceedings, pages 319–333, Berlin, Heidelberg, 2008. Springer Ber-lin Heidelberg. URL: http://dx.doi.org/10.1007/978-3-540-68552-4_24, doi:10.1007/978-3-540-68552-4_24.

[GW05] Andrew V. Goldberg e Renato F. Werneck. Computing point-to-point shortest pathsfrom external memory. In Proceedings of the Seventh Workshop on Algorithm Engi-neering and Experiments (ALENEX’05), pages 26–40, 2005.

[Nav] Navitia. https://www.navitia.io/features. Accessed: 2017-01-25.

[Ope] Opentripplanner. http://www.opentripplanner.org/. Accessed: 2017-01-24.

[Som14] Christian Sommer. Shortest-path queries in static networks. ACM Comput.Surv., 46(4):45:1–45:31, March 2014. URL: http://doi.acm.org/10.1145/2530531, doi:10.1145/2530531.

[TTLC92] Chi Tung Tung e Kim Lin Chew. A multicriteria pareto-optimal path algo-rithm. European Journal of Operational Research, 62(2):203–209, 1992. URL:http://EconPapers.repec.org/RePEc:eee:ejores:v:62:y:1992:i:2:p:203-209.

66

http://doi.acm.org/10.1145/2533828.2533838

http://doi.acm.org/10.1145/2533828.2533838

http://doi.acm.org/10.1145/28869.28874

https://www.microsoft.com/en-us/research/publication/computing-the-shortest-path-a-search-meets-graph-theory/

https://www.microsoft.com/en-us/research/publication/computing-the-shortest-path-a-search-meets-graph-theory/

https://developers.google.com/transit/gtfs/reference/

https://developers.google.com/transit/gtfs/reference/

http://dx.doi.org/10.1007/978-3-540-68552-4_24

http://dx.doi.org/10.1007/978-3-540-68552-4_24

https://www.navitia.io/features

http://www.opentripplanner.org/

http://doi.acm.org/10.1145/2530531

http://doi.acm.org/10.1145/2530531

http://EconPapers.repec.org/RePEc:eee:ejores:v:62:y:1992:i:2:p:203-209

http://EconPapers.repec.org/RePEc:eee:ejores:v:62:y:1992:i:2:p:203-209

evolução da componente algorítmica de cálculo de rotas do

Documents