Levantamento de Requisitos e Decisões de Desenho

O primeiro passo na conceção da aplicação foi definir os requisitos principais para a aplicação: (1) representar uma cidade real num ambiente virtual; (2) existência de um sistema de coordenadas para representar os dados; (3) existência de mo- dos de visualização alternativos desses mesmos dados para o utilizador escolher o modo de visualização que mais lhe agradasse; (4) existir um placar virtual com um gráfico da evolução dos dados ao longo do dia, que seria chamado pelo utilizador; (5) ter autocarros guiados a percorrer rotas pré definidas.

Como analisado na revisão bibliográfica, optou-se pela utilização do OSM2World para gerar as cidades em 3D. Com o uso do OSM2World, surgiu o problema de o utilizador conseguir identificar os locais vistos na aplicação com os locais físicos. Este problema surge devido ao facto de o mundo gerado pelo OSM2World repre- sentar o mundo utilizando formas simples e sem relevo do terreno. A solução aqui encontrada foi de fornecer informação adicional ao utilizador, através do nome de um ponto de referência, utilizando o sistema de coordenadas desenvolvido para a representação dos dados como forma de obter as coordenadas geográficas do utili- zador. Tendo as coordenadas do utilizador, recorre-se ao ficheiro .osm para obter o nome do ponto de referência (e.g. nome de uma rua ou nome de um edifício) a ser apresentado ao utilizador, ajudando-o a fazer a ponte entre o local visto na aplicação e o local físico.

A segunda decisão tomada foi relativa aos modos de visualização. Pretendeu-se desenvolver uns modos de visualização mais tradicionais (por exemplo através do valor do poluente em cada ponto), uns mais dinâmicos (por exemplo recorrendo a forma gráficas integradas na cena que alteravam em função dos valores dos poluen- tes) e outros mais ligados a fenómenos naturais que estivessem ligados à poluição (por exemplo o fumo ou a chuva). O modo simples, que apresenta apenas o valor do poluente registado na posição em que o utilizador se encontra no canto inferior direito, foi desenvolvido com intensão de ser o modo representativo dos modos de visualização tradicional. Os modos de textura, barra, cubos coloridos e em altura

Levantamento de Requisitos e Decisões de Desenho

foram os modos desenvolvidos com vista a proporcionar maior dinamismo para o utilizador. Por fim o modo de nevoeiro e o modo de chuva, foram os modos desen- volvidos que se ligavam a fenómenos naturais. O modo nevoeiro está diretamente ligado à poluição, enquanto o modo de chuva está mais adequado para representar dados de precipitação.

Tendo os modos de visualização definidos, surgiu a necessidade de se desenvolver uma funcionalidade que permitisse ao utilizador saltar para uma dada localização sem ter de percorrer o caminho todo, à semelhança das ferramentas baseadas em mapas, de forma a otimizar o processo de busca. A funcionalidade desenvolvida baseia-se na informação presente no ficheiro .osm, listando para o utilizador todas as localizações encontradas nesse ficheiro.

A terceira decisão é relativa à forma de integração dos autocarros guiados. Pretendia- se ter autocarros virtuais a percorrer rotas pré-definidas que teriam sido obtidas a partir dos autocarros reais, de forma similar com o que acontece na realidade. A integração podia ser feita de duas formas: (1) escolher no menu inicial se se pre- tendia entrar no modo de condução livre ou no modo de condução guiado, sendo que ao entrar no modo de condução guiado escolhia-se logo a rota que se queria realizar, ou (2) ter os autocarros guiados a circular no mesmo mundo virtual que o autocarro livre. Optou-se pela segunda opção, sendo a que fazia mais sentido para o utilizador, uma vez que este não tinha de sair do mundo virtual para entrar no modo de condução guiado.

O planeamento da conceção e desenvolvimento da funcionalidade dos autocarros guiados requereu certas considerações. A primeira foi a existência de erros nas posições geográficas dos dados recolhidos pelos autocarros em que foi montada a rede de sensores. Isto pode acontecer devido a uma má obtenção das coordena- das causada por obstáculos, como é o caso dos prédios, levando a que alguns dos pontos se encontrem fora da estrada onde o autocarro que tinha montado o sensor passou. Este fenómeno acontece porque as velocidades de propagação das ondas do sinal de GPS são diferentes no ar e nos objetos, causando um ligeiro erro na triangulação da posição do sensor uma vez que os cálculos da posição do sensor são

Mundo virtual e Funcionalidades

este problema, foi colocado na frente dos autocarros guiados dois sensores virtuais com vista a ajustar a rota dos autocarros de forma a se manterem na estrada vir- tual. Além desses dois sensores, existem mais quatro responsáveis por identificar obstáculos no percurso do autocarro de forma a permitir que o autocarro se possa desviar automaticamente destes.

A segunda consideração foi a possibilidade da existência de erros na geração do mundo virtual por parte da ferramenta utilizada, tendo, por exemplo, sido iden- tificado em testes a existência de túneis subterrâneos que erradamente surgem representados à superfície do mundo virtual e carris a obstruírem a passagem do autocarro. Mesmo tendo-se optado por não representar os túneis subterrâneos que eram gerados de forma incorreta, optou-se por ignorar as colisões entre os auto- carros guiados e os elementos da cidade, evitando que erros na geração do modelo 3D não detetados obstruíssem o autocarro. Desta forma, garantia-se que mesmo que não houvesse forma do autocarro virtual guiado contornar o obstáculo, este não iria ficar preso e iria continuar o seu percurso.