10
Embora a maior parte das sugestões possíveis sejam detetadas com as soluções apresentadas, existem ainda 3 situações (que são extensões das anteriores) que não o são.
12
(a) Situação 1 (b) Situação 2 (c) Situação 3
Figura 4.15: Situações não detetáveis com a solução atual
Na verdade, a situação ilustrada na Figura4.15aé detetada com a solução implementada. No entanto, o que acontece é que no caso dos utilizadores seguirem em sentido oposto a sugestão
14
também é feita. Ou seja, como não há nenhum local significativo partilhado pelas duas rotas, com a informação armazenada na base de dados, não é possível saber a direção que está a ser seguida
por ambos os utilizadores. É detetado que a rota é partilhada e no caso da hora da realização das
viagens ser semelhante é feita a sugestão. 2
A solução para o problema fica acessível a partir do momento em que cada segmento de viagem passe a ter associada a orientação que o utilizador está a seguir naquele momento (Norte, 4
Oeste, etc). Assim, só utilizadores com segmentos de viagens com centróides próximos e com a mesma orientação passariam a ser considerados vizinhos. 6
Já as situações das Figuras4.15be4.15cacabam por ser a junção das duas soluções propostas (Secções4.3.1e4.3.2). No entanto, estas sugestões acabaram por não ser implementadas, como 8
já era previsto e devidamente enunciado aquando da “Preparação da Dissertação”, devido a falta
de tempo. 10
4.5
Sumário
De forma a tornar a procura de sugestões de partilha de veículo viável do ponto de vista tem- 12
poral começou-se pela determinação de padrões de viagem vizinhos. Este conceito consiste, basi- camente, na procura de pares de padrões de viagem que tenham parte (ou total) da rota partilhada 14
pois apenas nesses casos é possível a sugestão de partilha de veículo.
Tendo então por base os padrões de viagem vizinhos, seguiu-se a determinação de sugestões 16
de partilha de veículo propriamente dita. Foram identificadas as duas principais formas que as rotas de padrões de viagem vizinhos podem tomar (Figura4.7) e elaboradas soluções para ambos 18
os casos.
No caso em que uma das rotas é totalmente sobreposta pela outra, a solução passou pelo 20
estudo de cada uma das rotas para se perceber se alguma delas se aproximava de ambos os locais significativos da outra. Se assim for, conclui-se que essa rota tem início antes ou no mesmo local 22
que a outra e termina depois ou no mesmo local. Daqui resulta uma sugestão de partilha de veículo. Já no caso em que existe uma bifurcação nas rotas, a solução passou pelo desenho e imple- 24
mentação de um novo algoritmo, o algoritmo ShapeDetector. Este algoritmo é baseado na ideia dos algoritmos de clustering baseados em densidade e no funcionamento de um neurónio de uma 26
rede neuronal artificial. A combinação destas duas ideias resultou num algoritmo que tem como intuito a deteção de formas em enormes conjuntos de dados espaciais e parte do pressuposto de 28
que o conjunto de dados sobre o qual vai atuar é constituído por dois tipos de dados distintos.
O funcionamento do algoritmo consiste na procura de core points à semelhança do algoritmo 30
DBSCAN. No entanto, à definição já conhecida de core point foi adicionada uma restrição que está relacionada com a obrigação de haver uma determinada distribuição espacial dos dados. Para 32
todos os core points é calculada a distância média aos pontos do outro tipo, neste caso, aos pontos do outro utilizador. Depois de calculado esse valor, ele é aplicado a uma função de ativação. Esta 34
função de ativação serve, exatamente como nos neurónios das redes neuronais artificiais, para limitar a amplitude do valor calculado. Por fim, com os pontos com valor da função de ativação 36
dados e onde. No caso de ser detetada uma bifurcação, ou mais, é feita a sugestão de partilha de veículo.
Implementação
2
Esta dissertação foca-se essencialmente no desenvolvimento e aplicação de técnicas e algorit-
4
mos de forma a possibilitar a sugestão de partilha de veículo aos utilizadores. Embora aquando da apresentação da solução já tenham sido detalhados os algoritmos e a forma como foram usados,
6
nesta secção são dados a conhecer outros detalhes técnicos.
Note-se que a plataforma de recolha de dados não é detalhada na medida em que já se encon-
8
trava desenvolvida quando foi iniciada a dissertação. A recolha de dados é feita para uma base de dados relacional MySQL (ver Secção2.5.1.1para mais detalhes) e não faz uso de nenhuma das
10
funcionalidades atualmente existentes nos SGBDs de forma a obter uma melhoria de desempenho tendo em conta que o tipo de dados guardados são geográficos. Devido a esse entrave, os dados
12
foram migrados para uma base de dados SQLServer onde é feito uso de tipos de dados adequados para o efeito (tipo de dados SQLGeography, por exemplo).
14
5.1
Servidor
O servidor é responsável pela migração dos dados da base de dados MySQL para a base de
16
dados SQLServer. Para além disso, toda a computação inerente ao cálculo dos pontos de estadia, segmentos das viagens, locais significativos e padrões de viagem de cada utilizador e padrões de
18
viagem vizinhos é também desempenhada pelo servidor. Para o seu desenvolvimento recorreu-se à tecnologia C#.
20
Na Figura5.1são visíveis três “áreas” de atuação por parte do servidor. Foi feita esta separação porque as tarefas desempenhadas pela caixa identificada com o número 1 seriam, idealmente,
22
feitas aquando da recolha de dados com baixo custo computacional para o dispositivo móvel e minimizaria o do servidor como já foi referido nas Secções3.1e3.3), as tarefas desempenhadas
24
na caixa identificada com o número 2 são desempenhadas automaticamente com um intervalo de tempo definido (de 15 em 15 dias, por exemplo) e, por fim, as tarefas na caixa identificada com o
26
Figura 5.1: Ilustração simplificada do servidor
Figura 5.2: Interface gráfica da aplicação servidor
De forma a tornar mais fácil a alteração dos parâmetros dos algoritmos que executam no servidor foi desenvolvida uma interface gráfica (Figura5.2). 2
Base de Dados A base de dados é o que suporta a computação do servidor pois é lá que estão
Figura 5.3: Esquema completo da base de dados
Devido à grande quantidade de dados inerente ao próprio problema, a base de dados foi sendo apetrechada ao longo do tempo com uma série de índices de forma a possibilitar um desempenho
2
em termos de acesso aos dados aceitável (Tabela5.1). Sem eles, seria, obviamente, impossível obter sugestões de partilha de veículo em tempo útil.
4
Tabela(s), campo(s) Clustered Nonclustered Composto Spatial Unique
Todas, chave(s) primária(s) X - - - -
Todas, chave(s) estrangeira(s) - X - - -
GPS, DateTime - X - - -
GPS, GeoCoord - - - X -
MeaningfulPlace, Centroid - - - X -
Segment, DateTimeStart e DateTimeEnd - X X - -
Segment, Centroid - - - X -
StayPoint, DateTimeArrive e DateTimeLeave - X X - -
StayPoint, GeoCoord - - - X -
TripPattern, Centroid - - - X -
User, Email - - - - X
Tabela 5.1: Índices criados na base de dados
A base de dados usada foi a Microsoft SQLServer 2008, versão R2. Esta escolha recaiu essencialmente pelo facto da mesma possibilitar o uso de índices espaciais para a indexação dos
6