Desenvolvimento de uma plataforma baseada em serviços para suporte à simulação de tráfego
Full text
FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Desenvolvimento de uma Plataforma Baseada em Serviços para Suporte à Simulação de Tráfego Pedro Borges Alves Mestrado Integrado em Engenharia Informática e Computação Orientador: António Pereira (Prof) e Rosaldo Rossetti (Prof) Junho de 2013
© Pedro Borges Alves, 2013 Desenvolvimento de uma Plataforma Baseada em Serviços para Suporte à Simulação de Tráfego Pedro Borges Alves Mestrado Integrado em Engenharia Informática e Computação Aprovado em provas públicas pelo Júri: Presidente: José Magalhães Cruz (Prof) Vogal Externo: Luis Paulo Reis (Prof) Orientador: António Pereira (Prof) ____________________________________________________ 17 de Junho de 2013
Resumo A simulação de tráfego tem um papel fundamental na projeção e otimização das redes de transporte. Os simuladores de tráfego recebem ficheiros de entrada que contêm um conjunto de informações relativas à topologia da rede, aos intervenientes e outros parâmetros que definem o sistema. A construção destes ficheiros pode ser um trabalho penoso para os utilizadores de simuladores de tráfego. Além disso, cada simulador requer um conjunto de ficheiros específico que contêm a informação num formato aceite pela aplicação. O formato desta informação varia entre os vários simuladores de tráfego. Neste documento é apresentado o desenvolvimento de uma plataforma baseada em serviços para suporte à simulação de tráfego. Esta plataforma permite aos utilizadores trabalhar de forma colaborativa na construção da informação necessária para os simuladores de tráfego. A necessidade de trabalhar sobre dados georreferenciados implicou a adoção de um conjunto de aplicações, o OpenGeo Suite. Este conjunto de aplicações contém um servidor de mapas que disponibiliza serviços que permitem a edição e visualização de mapas. O desenvolvimento de uma aplicação baseada nas aplicações OpenGeo Suite permite a edição e visualização de mapas e dados. A plataforma dispõe também de um serviço REST que permite a importação de informação do fornecedor de mapas OpenStreetMap, auxiliando o utilizador na construção de topologias já existentes. O desenvolvimento de outro serviço REST tem o propósito de possibilitar a geração de ficheiros aceites nos simuladores de tráfego tendo como base o conjunto de dados editados na plataforma.
Abstract Traffic simulation has a key role in designing and optimizing transport networks. Traffic simulators receive input files which contain a set of information about network topology, actors and other parameters that define the system. The construction of these files can be a painful work to the users of traffic simulation applications. In addition, each simulator requires a specific set of files that contain formatted information to be accepted by simulator. The syntax of this information varies between several traffic simulators. This document presents the development of a service-based framework to support traffic simulation. This platform allows users to work collaboratively in the construction of required information for traffic simulators. Working on georeferenced data implies the adoption of a set of applications, the OpenGeo Suite. This set of applications contains a map server that provides services that allow map editing and visualization of maps. The development of an application based on OpenGeo Suite allows users to manage maps and data. The platform also provides a REST service that allows the import of OpenStreetMap data, assisting the user in the construction of existing topologies. The development of another REST service has the purpose of enabling the generation of files accepted by traffic simulators based on edited data. .
Agradecimentos Gostaria de agradecer: À minha mãe, ao meu pai e à minha irmã pelo apoio incondicional que me têm dado. Pretendo também agradecer a compreensão e por estarem disponíveis sempre que precisei no meu percurso académico. À minha namorada Mafalda, por estar ao meu lado e apoiar-me durante o desenvolvimento deste trabalho. Ao meu orientador, Prof. António Pereira, por todo apoio e acompanhamento prestado, em especial nesta fase final. Ao meu orientador, Prof. Rosaldo Rossetti, que me proporcionou esta experiência de trabalho e aprendizagem. Quero agradecer também o acompanhamento e apoio prestado na fase inicial do projeto. A todos os que me ajudaram e apoiaram para que conseguisse chegar aqui. Pedro Borges Alves
Figura 26 - Estado do simulador após carregar o ficheiro de configuração. 72 Figura 27 – Ecrã de um cruzamento da simulação no instante 54. 73
Abreviaturas e Símbolos API Application Programming Interface CAD CSCW Computer-Aided Design Computer Supported Cooperative Work CSV Comma-separated values FEUP Faculdade de Engenharia da Universidade do Porto FTP File Transfer Protocol GML Geography Markup Language GPS Global Positioning System HTTP Hypertext Transfer Protocol KML Keyhole Markup Language LAN Local Area Network NASA National Aeronautics and Space Administration OGC Open Geospatial Consortium PHP Hypertext Preprocessor REST Representational State Transfer SCG Sistema de Coordenadas Geográficas SCP Sistema de Coordenadas Projetadas SIG Sistema de Informação Geográfica SOAP Simple Object Access Protocol SMTP Simple Mail Transfer Protocol UTM Universal Transverse Mercator WAN Wide Area Network WCS Web Coverage Services WMS Web Map Service WFS Web Feature Service WFS-T Transactional Web Feature Services WSDL Web Services Definition Language XML Extensible Markup Language
Introdução 1 Capítulo 1 Introdução 1.1 Identificação dos Problemas A construção ou alteração de redes de transporte requerem um estudo minucioso das especificidades das mesmas. O fracasso ou imprecisão da implantação de uma rede de transportes tem uma repercussão imediata na qualidade de vida da população e a sua correção pode ter custos elevadíssimos. O estudo das redes de transporte recorre a modelos matemáticos que tentam prever o comportamento da rede tendo como base determinados parâmetros de entrada. Devido ao avanço da tecnologia, foram desenvolvidos sistemas computacionais que incorporam estes modelos produzindo resultados de uma forma mais célere e menos propensos a erros de cálculo. Estes sistemas computacionais são denominados simuladores de tráfego e nos dias de hoje têm um papel fundamental na projeção e otimização de redes de transporte. Existem dezenas de simuladores de tráfego e este número tem tendência a aumentar. Estas aplicações recebem ficheiros de entrada que contêm um conjunto de informações referentes à topologia da rede, aos intervenientes e seu comportamento e outros parâmetros. Alguns elementos desta informação podem ser georreferenciados, ou seja podem ter atributos que definem a localização destes no espaço. A representação desta informação nos ficheiros varia entre os simuladores tornando difícil ou mesmo impossível usar o mesmo conjunto de informações em aplicações diferentes. Os utilizadores destas ferramentas defrontam-se com um problema, como utilizar o mesmo conjunto de dados de entrada em vários simuladores? Os novos conceitos impulsionados pela internet apelam a uma cultura de colaboração e cooperação na realização de tarefas. A utilização de software colaborativo proporciona às organizações novos princípios competitivos, tais como o trabalho com pares, partilha e abertura. Os utilizadores de simuladores de tráfego confrontam-se com outra necessidade, como trabalhar de forma colaborativa os dados de entrada necessários para os simuladores? A solução para este
Introdução 2 problema, devido a alguns dados serem georreferenciados passa por recorrer a mapas que sejam acessíveis na internet. Os mapas disponíveis na internet não podem ser manipulados e não é possível construir algo realmente interessante, isto porque os fornecedores de mapas barram o acesso a algumas funcionalidades e informações. Por exemplo, não é possível mapear uma determinada informação, combinar mapas ou fazer alguma análise com essa informação (Erle, Gibson, & Walsh, 2005). 1.2 Motivação Nos dias de hoje, as redes de transporte são um dos principais problemas da vida quotidiana, sobretudo nas grandes cidades. Estes problemas bem conhecidos são: os congestionamentos de trânsito, a poluição ambiental e sonora, o consumo de recursos entre outros. O recurso a aplicações de simulação de tráfego quando utilizadas corretamente, podem ter um impacto extraordinário na qualidade de vida das pessoas. A possibilidade deste projeto contribuir para um melhor bem-estar da sociedade é o principal fator de motivação. Ao nível tecnológico, a principal motivação está relacionada com o crescimento sem precedentes da quantidade de informação georreferencia na web. O desenvolvimento de muitas aplicações neste ramo ajudam a resolver problemas ambientais; são aplicações que ajudam a compreender o nosso mundo; são aplicações que ajudam a deixar o mundo melhor do que quando o encontrámos. O desenvolvimento de aplicações baseadas em serviços é outra tendência que está em crescimento devido às suas potencialidades. Os assuntos relacionados com o projeto e sua literatura são extremamente interessantes, como por exemplo a simulação de tráfego, a geografia ou a computação. 1.3 Objetivos O objetivo principal deste trabalho consiste em desenvolver uma plataforma baseada em serviços que permita a gestão de informação relacionada com a simulação de tráfego e que seja capaz de produzir informação aceite por vários simuladores de trânsito. Assim sendo, os objetivos deste trabalho são: Adoção de um servidor de mapas que sirva como base da plataforma. Desenvolvimento de uma aplicação que permita a visualização e a edição colaborativa de mapas e que suporte também a gestão de dados não georreferenciados relacionados com a simulação de tráfego.
Introdução 3 Desenvolvimento de um serviço que permita a importação de informação do OpenStreetMap, por forma a auxiliar os utilizadores na construção de informação. Desenvolvimento de um serviço capaz de produzir ficheiros aceites por vários simuladores. 1.4 Estrutura da Dissertação Este documento está estruturado em seis capítulos. Neste primeiro capítulo é feita uma introdução ao trabalho apresentando os problemas identificados, os fatores de motivação para a realização deste trabalho e os objetivos. O segundo capitulo tem como objetivo apresentar as caraterísticas das aplicações com arquiteturas orientadas a serviços. Este capítulo inicia-se com uma abordagem aos sistemas distribuídos, discutindo várias definições e são apresentadas as caraterísticas destes sistemas. De seguida é feita uma introdução à computação orientada a serviços, onde são apresentados os objetivos deste método e os benefícios da sua utilização. São também abordados os diferentes tipos de arquiteturas orientadas a serviços assim como as diferentes formas de implementação. No terceiro capítulo é realizada uma análise aos diferentes tipos de sistemas de informação geográfica. A primeira parte deste capítulo descreve a evolução dos mapas e sua importância na sociedade. São apresentados os sistemas de mapeamento da Terra, nomeadamente os sistemas de coordenadas geográficas e os sistemas de coordenadas projetadas. Na última parte são apresentadas aplicações de sistemas de informação geográfica. O capítulo quatro apresenta conceitos relacionados com a simulação e em particular a simulação de tráfego. Em primeiro é apresentada uma definição de simulação e as principais aplicações deste tipo de tecnologia. Neste capítulo é também destacada a importância da simulação na engenharia de tráfego, no que diz respeito ao ambiente, segurança, sustentabilidade e qualidade de vida da população. São reveladas as principais categorias de simuladores de trânsito mostrando as vantagens e desvantagens de cada uma. Na parte restante do capítulo são apresentados vários simuladores de trânsito evidenciando características únicas ou aspetos gerais sobre o funcionamento destas aplicações. No quinto capítulo são apresentados os requisitos funcionais e não funcionais da aplicação. É apresentada uma solução genérica para o problema e é descrito o procedimento para a conceção de uma solução específica. Este procedimento inclui a avaliação e adoção de software livre para várias componentes desta solução específica. Este capítulo conclui-se com a apresentação das várias componentes do projeto, descrevendo para cada delas: os procedimentos tomados no desenvolvimento, as funcionalidades que estas oferecem e os resultados obtidos. No sexto e último capítulo são apresentadas as conclusões gerais deste trabalho, analisando os resultados obtidos. São também propostos futuros desenvolvimentos das componentes.
Arquitetura Orientada a Serviços 4 Capítulo 2 Arquitetura Orientada a Serviços 2.1 Sistemas Distribuídos Nos dias de hoje assistimos a uma revolução nos sistemas de computadores. Desde o meio da década de 40 até à década de 80, os computadores eram uma ferramenta que apenas algumas empresas tinham oportunidade de usufruir, não só devido às grandes dimensões mas também pelo preço ser muito elevado. Após esta era, dois desenvolvimentos na tecnologia mudaram esta situação. Em primeiro, o desenvolvimento de potentes microprocessadores, que tinham a mesma potência dos computadores de grandes dimensões, mas o seu preço era mais reduzido. O outro desenvolvimento foi a invenção de redes de computadores de alta velocidade (LAN/WAN), permitindo a comunicação entre centenas de computadores num edifício ou mesmo entre milhões de máquinas dispersas por todo o mundo. O resultado destas evoluções resulta no interesse pelo desenvolvimento de sistemas informáticos compostos por vários computadores ligados por redes de alta velocidade, designados por sistemas distribuídos. Na literatura podem encontrar-se várias definições de sistema distribuído porém nenhuma delas é satisfatória pois não existe uma que seja unânime. Segundo Tanenbaum, "um sistema distribuído é uma coleção de computadores independentes que se apresenta aos utilizadores como um sistema único e consistente". Perante esta definição podem ser identificadas várias características de um sistema distribuído. Pode afirmar-se que um sistema distribuído é um sistema composto por vários componentes, que são autónomos e a comunicação entre os componentes é transparente ao utilizador (Tanenbaum & Van Steen, 2007). Uma definição mais recente sugere que "um sistema distribuído é uma aplicação que executa uma coleção de protocolos para coordenar múltiplos processos numa rede, tal que todos os componentes cooperem em conjunto para realizar uma tarefa ou um pequeno conjunto de tarefas” (Google Code University, 2013). Nesta segunda definição, a estrutura interna de um sistema distribuído é abordada com mais rigor, afirmando que existem regras na comunicação entre os componentes. Também é
Arquitetura Orientada a Serviços 5 mais explicito a possibilidade de existir cooperação entre os componentes, ou seja, um conjunto de tarefas pode ser distribuído por vários componentes. Existem vários objetivos no desenvolvimento de sistemas distribuídos que se tornam potenciais vantagens e quando comparados com os sistemas tradicionais centralizados marcam a diferença. O principal objetivo é manter os recursos facilmente acessíveis para os utilizadores e aplicações, disponibilizando-os de uma forma controlada e eficiente. A partilha de recursos torna mais fácil a colaboração e troca de informação e um exemplo claro desta vantagem é a troca de informação na internet através de ficheiros, correio eletrónico, documentos, som e vídeo. Nos dias de hoje assistimos à supressão das barreiras geográficas, através das aplicações de software que comunicam através da internet. Existem inúmeras aplicações que contribuem para este facto, desde a teleconferência ao software de edição colaborativa. Um outro objetivo, já mencionado anteriormente é a transparência. O conceito de transparência é aplicado a diversos níveis num sistema distribuído. A transparência no acesso está relacionada com a forma de representação dos dados e como os recursos são acedidos. Os recursos podem estar disponíveis em várias máquinas que podem ter arquiteturas e sistemas operativos diferentes não sendo percetível ao utilizador. A transparência da localização é outra característica dos sistemas distribuídos. Recorrendo ao serviço de nomes é possível mascarar a verdadeira localização dos recursos mesmo quando existe migração ou realocação. A transparência também está presente quando ocorrem replicações, quando um recurso é partilhado por vários utilizadores ou quando ocorrem falhas e existe recuperação do recurso. Outro objetivo na implementação destes sistemas é garantir a facilidade da sua escalabilidade e expansão, ou seja o aumento do número de utilizadores, recursos e entidades computacionais deve ser possível e facilitado. Esta possibilidade permite o desenvolvimento de sistemas com maior potencial devido ao aumento da capacidade de processamento e cooperação entre componentes, o que torna estes sistemas mais económicos em comparação com sistemas tradicionais. Um sistema distribuído deve também ser aberto, ou seja deve ser possível a implementação em diferentes formas regido por regras que descrevem a sintaxe e a semântica dos serviços. Normalmente, os sistemas distribuídos são descritos sob interfaces onde é especificado o nome das funções disponíveis e respetivos tipos parâmetros de entrada, valores de retorno e possíveis exceções. Uma definição mais pessimista de Leslie Lamport define um sistema distribuído como "um sistema no qual a falha de um computador que nem sequer sabíamos existir, pode tornar o nosso computador não usável". Esta definição está relacionada com as falhas que podem existir num sistema distribuído e as estratégias aplicadas no caso de estas ocorrerem. As falhas podem ser ao nível do hardware ou ao nível de software. Os rápidos avanços tecnológicos ao nível do hardware aumentaram significativamente a fiabilidade destes, estando os erros mais frequentes associados a ligações de rede e a dispositivos mecânicos.
Arquitetura Orientada a Serviços 6 No desenvolvimento de um sistema distribuído é necessário assumir que “as falhas estão sempre a ocorrer”, porque estas podem de facto acontecer a qualquer instante e o sistema tem de estar preparado para reagir. O maior desafio no desenvolvimento de um sistema distribuído para além de construir um sistema útil é que este seja fiável mesmo quando ocorre uma falha (Tanenbaum & Van Steen, 2007). 2.2 Orientação a Serviços A computação orientada a serviços representa uma recente plataforma da computação distribuída, possuindo certas características ao nível de design, linguagens e modelo de arquitetura em conjunto com determinados conceitos, tecnologias e frameworks. A orientação a serviços é um paradigma que tem o objetivo de criar unidades lógicas que são modeladas individualmente e quando utilizadas coletivamente e repetidamente permitem a concretização de objetivos e benefícios estratégicos (Erl, SOA with REST, 2013). A orientação a serviços como paradigma de design da computação distribuída teve grandes influências do paradigma da orientação a objetos. Apesar de existirem diferenças, estas podem ser comparadas ao nível de objetivos, conceitos e princípios (Erl, Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts, 2008). 2.2.1 Objetivos A computação orientada a serviços emergiu como um método formal para dar suporte a alcançar os seguintes objetivos (Erl, SOA with REST, 2013): Aumentar interoperabilidade intrínseca – Os serviços são desenhados para serem naturalmente compatíveis e podem ser desenvolvidos e reconfigurados de acordo com mudanças nos requisitos de negócio. Os clientes projetados podem ser desenvolvidos em diversas linguagens de programação e aceder aos serviços de uma forma transparente. Aumentar a federação – Os serviços estabelecem uma camada de contrato que é federada permitindo a governação individual dos serviços e a sua evolução. Aumentar as opções de diversificação – Um ambiente orientado a serviços é baseado num modelo arquitetónico que funciona com qualquer plataforma utilizada pelos fornecedores. Aumentar o alinhamento de negócio e tecnologia – Alguns serviços são desenhados com um contexto funcional centrado no negócio permitindo espelhar e evoluir o negócio da organização.
Arquitetura Orientada a Serviços 7 Os objetivos descritos acima são também associados com a arquitetura orientada a serviços como é descrito no manifesto SOA (Service-Oriented Architecture, em português significa Arquitetura Orientada a Serviços) (Erl, Anotação do Manifesto SOA, 2013). Estes objetivos quando alcançados podem proporcionar às organizações três benefícios estratégicos (Erl, SOA with REST, 2013): Aumentar o ROI – Alguns serviços são entregues e vistos como ativos em que se espera que ofereçam um valor repetido que supera o custo de entrega e propriedade. Aumentar a agilidade organizacional – As alterações dos requisitos de negócio podem ser desenvolvidas mais rapidamente através do ambiente estabelecido que permite um menor esforço devido à reutilização e interoperabilidade dos serviços existentes. Reduzir a carga de tecnologia – A empresa como um todo é mais simplificada, devido aos resultados dos objetivos e benefícios descritos anteriormente, permitindo que a tecnologia dê um melhor suporte à organização fornecendo mais valor, reduzindo os custos e carga em geral. 2.2.2 Princípios O paradigma de design de orientação a serviços baseia-se essencialmente em oito princípios específicos (Erl, SOA with REST, 2013): Contrato de Serviço Padronizado – Os serviços incluídos no mesmo inventário estão regidos pelo mesmo contrato de design. O contrato especifica o comportamento dos serviços e as obrigações das partes envolvidas. Serviços têm baixo acoplamento – Os serviços com baixo acoplamento têm capacidade de realizar as suas tarefas de forma independente, não necessitando de outros serviços. Os serviços devem ter esta característica, não só para respeitar o padrão utilizado dentro do ambiente corporativo mas também para potenciar a reutilização do conjunto de serviços. Abstração de serviço – Os contratos de serviço contêm apenas informação essencial e a informação sobre os serviços é limitada à publicada nos contratos dos serviços. Reutilização do serviço – Os serviços não são desenhados para uma função do negócio específica. Estes são genéricos o suficiente para poderem ser integrados noutros projetos.
Arquitetura Orientada a Serviços 14 e middleware, pois o tipo de mensagens é sempre o mesmo. O facto de as aplicações não terem estado, é também uma contribuição para a simplicidade pois nos pedidos não é necessário fazer referência a mensagens anteriores. As restrições de cliente-servidor e sistema em camadas resultam em lógicas bem definidas ao nível do serviço, cliente e middleware. Modificabilidade A modificabilidade está relacionada com a facilidade de fazer mudanças na arquitetura. Em grandes arquiteturas distribuídas é importante que seja fácil modificar partes da aplicação sem ser necessário reconstruir toda a aplicação. Visibilidade Neste tipo de aplicações, a visibilidade passa pela existência de agentes de serviços de middleware que têm como função monitorizar e otimizar a interação entre os serviços e os clientes. As funcionalidades destes agentes incluem a partilha da cache de respostas, melhorar a escalabilidade através de camadas que agregam pedidos e reduzindo o impacto direto nos serviços, melhorar a confiança dos serviços assegurando a entrega de pedidos e melhorar a segurança aplicando politicas e filtros de interações. Portabilidade O objetivo da portabilidade é permitir que os serviços possam ser executados em vários tipos de plataformas. Deve ser considerado o nível de compatibilidade entre sistemas, a portabilidade que pode ser cedida a uma dada aplicação e a facilidade de manter agrupados os dados e a lógica. Confiabilidade A confiabilidade de uma arquitetura distribuída está relacionada com a possibilidade de uma solução ou os serviços serem suscetíveis a falhas. A confiabilidade de uma arquitetura pode ser melhorada, evitando pontos únicos de falha utilizando mecanismos de failover. O processo de failover ocorre quando uma máquina assume os serviços de outra, quando ocorre uma falha da última. Também podem ser utilizados mecanismos de monitorização que podem dinamicamente antecipar e responder aos problemas (Erl, SOA with REST, 2013).
Arquitetura Orientada a Serviços 15 2.5 Conclusões Devido ao facto da plataforma ser baseada em serviços é importante estudar os principais conceitos e características da computação orientada a serviços. É igualmente importante compreender a diferença entre os vários tipos de arquiteturas orientadas a serviços, para que na fase de design exista uma especificação bem definida dos serviços a serem implementados. Neste capítulo os serviços REST têm um estudo mais profundo porque são este tipo de serviços que são utilizados no projeto. Este capítulo não tem como objetivo apresentar uma visão detalhada sobre a computação orientada a serviços, mas sim, apresentar os assuntos relevantes para o desenvolvimento deste projeto.
Capítulo 3 Sistemas de Informação Geográfica 3.1 Mapas Os mapas são m odelos que contêm precisam de ser semelhantes à realidade ou ter as mesmas relações espaciais. Há muitos anos que se usam mapas para representar a localização das coisas. O primeiro mapa conhecido (Figura 2) foi descoberto no ano de 1961 durante umas O mapa encontrado representa o sítio antiquíssimo de Çatalhöyük, uma colonização neolítica datada aproximadamente de 6500 a.C. O mapa consiste de uma parte pres de parede, representando uma comunidade e no fundo um vulcão (Hasan Dag) em atividade (Kropla, 2005). Figura 2 - Plano da cidade de Çatalhöyük com o vulcão no fundo Outro mapa conhecido é também uma pintura de parede do ano de 1600 a.C, da civilização Minoan (atual ilha de Creta), retratando a comunidade numa perspetiva oblíqua. cartografia, usando o globo como forma e també construídas no século III a. C por Eratosthenes de Cirene e Hiparco. Sistemas de Informação Geográfica 16 Sistemas de Informação Geográfica odelos que contêm representações do mundo. Estas representações não precisam de ser semelhantes à realidade ou ter as mesmas relações espaciais. Há muitos anos que se usam mapas para representar a localização das coisas. O primeiro foi descoberto no ano de 1961 durante umas escavações na Turquia O mapa encontrado representa o sítio antiquíssimo de Çatalhöyük, uma colonização neolítica datada aproximadamente de 6500 a.C. O mapa consiste de uma parte preservada de uma pintura de parede, representando uma comunidade e no fundo um vulcão (Hasan Dag) em atividade Plano da cidade de Çatalhöyük com o vulcão no fundo (Kropla, 2005) Outro mapa conhecido é também uma pintura de parede do ano de 1600 a.C, da civilização Minoan (atual ilha de Creta), retratando a comunidade numa perspetiva oblíqua. cartografia, usando o globo como forma e também o sistema de latitudes e longitudes, foram construídas no século III a. C por Eratosthenes de Cirene e Hiparco. Sistemas de Informação Geográfica representações do mundo. Estas representações não Há muitos anos que se usam mapas para representar a localização das coisas. O primeiro escavações na Turquia . O mapa encontrado representa o sítio antiquíssimo de Çatalhöyük, uma colonização neolítica ervada de uma pintura de parede, representando uma comunidade e no fundo um vulcão (Hasan Dag) em atividade (Kropla, 2005) . Outro mapa conhecido é também uma pintura de parede do ano de 1600 a.C, da civilização Minoan (atual ilha de Creta), retratando a comunidade numa perspetiva oblíqua. As bases da m o sistema de latitudes e longitudes, foram
Sistemas de Informação Geográfica 17 Foi durante os Descobrimentos que os mapas tiveram uma grande evolução, devido à necessidade de representar grandes áreas com grande precisão para reduzir os riscos na navegação. No século XVII, a Cartografia separou-se da Geografia, tornando-se estas ciências autónomas. Os geógrafos lidam com a superfície de um esferoide num espaço tridimensional, por outro lado os cartógrafos representam as coisas do mundo real num plano de duas dimensões, ou seja em mapas (Francischett, 2004). Na época dos descobrimentos eram utilizados compassos, sextantes e relógios, hoje em dia, a cartografia e mapas são representados por mapas digitais, sistemas de informação geográfica (SIG), e serviços baseados em localização usando como ferramentas os computadores, a internet e o GPS (Global Position System) (Kropla, 2005). Na internet podem ser encontrados vários mapas históricos. Um exemplo é a coleção de mapas históricos David Rumsey (Rumsey, 2013) que representam várias zonas do globo. Estes mapas sobrepõem-se aos conhecidos Mapas Google, permitindo analisar facilmente a diferença entre os mapas antigos e os mapas recentes. Nos dias de hoje os mapas são usados no dia-a-dia em diversas situações – de manhã observamos a informação sobre o estado do tempo em mapas meteorológicos, recebemos indicações de trânsito através de sistemas de navegação automóvel, consultamos mapas na internet. Mais recentemente, as redes sociais, tais como o Facebook, Foursquare permite que todos os eventos sejam georreferenciados: os sítios visitados, fotografias e muito mais (Kropla, 2005). 3.2 Sistemas de Coordenadas Geográficas Um sistema de coordenadas geográficas (SCG) define localizações na terra usando uma superfície esférica tridimensional. Um SCG incluí uma unidade de medida angular, um meridiano principal e um datum. A localização de um objeto pode ser definida pela sua latitude e longitude. A latitude e longitude são ângulos medidos desde o ponto central da terra até um ponto na superfície da terra. Estes valores são medidos em graus decimais ou no formato: graus, minutos e segundos. A latitude é medida relativamente ao equador e pode tomar valores compreendidos entre -90º no polo Sul e + 90º no Polo Norte. A longitude é medida em relação ao meridiano principal considerado e pode assumir valores positivos até 180º quando movimentado para este e negativos até -180º para oeste. Num sistema esférico, as linhas horizontais ou paralelos são linhas que têm a mesma latitude e as linhas verticais ou meridianos têm a mesma longitude.
Sistemas de Informação Geográfica 18 Para a maioria dos SCG o meridiano principal é a longitude que passa em Greenwich, na Inglaterra mas existem outros sistemas em que o meridiano principal passa em Berna, Bogotá ou Paris. A forma e tamanho de um SCG é definido por uma esfera ou um esferoide. Apesar da melhor representação do planeta Terra ser um esferoide, por vezes, em mapas de pequena escala a forma da Terra é considerada como se fosse uma esfera. Por causa da gravidade e das irregularidades da superfície terrestre a terra não é uma esfera perfeita nem um esferoide perfeito. Por exemplo, o Pólo Sul está mais próximo do equador do que o Pólo Norte. Normalmente, é escolhido um esferoide que se enquadre melhor num país ou numa área particular. A alteração de um esferoide num sistema de coordenadas implica novos cálculos de todos os valores medidos anteriormente e por isso as organizações não mudam frequentemente para esferoides mais recentes e mais precisos. O datum define a posição do esferoide relativamente ao centro da Terra, definindo a origem e orientação das linhas de latitude e longitude. O sistema de coordenadas geográficas padrão e mais utilizado é o World Geodetic System de 1984 (WGS84). Quando se muda o SCG, os valores de latitude e longitude de um determinado ponto na superfície terrestre alteram, pois as referências são diferentes (Kennedy, 2000). 3.3 Sistemas de Coordenadas Projetadas O sistema de coordenadas projetadas (SCP) é uma representação plana de duas dimensões, onde as distâncias, os ângulos e as áreas são constantes. Um SCP é sempre baseado num SCG, mas utiliza medidas lineares e com o mesmo espaçamento para coordenadas sendo mais fácil o cálculo de distâncias e áreas. As coordenadas de latitude e longitude são convertidas em coordenadas x,y num referencial, sendo a origem no centro deste. Cada posição tem dois valores que definem a posição horizontal e vertical em relação à origem. A transformação de uma superfície tridimensional num mapa plano é realizada usando fórmulas matemáticas e é designada por projeção de mapas. As projeções podem causar distorções na forma, área, distância ou direção da informação. Estas projeções são desenhadas para minimizar uma ou duas destas distorções e também para diferentes tipos de escalas. Por exemplo, para dados de pequena escala são baseados em sistemas de coordenadas geográficas esféricas em vez dos sistemas esferoides. Uma analogia feita a este problema, passa por tentar coincidir a casca de uma laranja com a superfície plana de uma mesa. Para que haja contacto total entre as duas superfícies, a casca de laranja tem de ser distorcida. As projeções podem ser classificadas segundo diversos tipos e características: Quanto ao método: geométricas, analíticas;
Sistemas de Informação Geográfica 19 Quanto à superfície de contacto: planas, cónicas e cilíndricas; Quanto às propriedades: equidistantes, conformes, equivalentes; Quanto ao tipo de contacto entre a superfície de projeção e a referência: tangentes ou secantes. A classificação mais utilizada é em função da forma geométrica da superfície de contato usada na projeção. O primeiro passo na projeção é criar um ou mais pontos de contato entre as duas superfícies. Este contato é denominado de ponto ou linha de tangente. No caso de ser usado um plano, a projeção é tangencial ao globo apenas num ponto. Nos casos do cilindro e do cone a tangente toca no globo ao longo de uma linha. Caso a superfície da projeção intersecte o globo em vez de o tocar, o resultado é uma secante em vez da tangente. Estes pontos de contacto são muito importantes em ambos os casos, pois definem as localizações onde não existe distorção. 3.3.1 Projeções Cónicas As projeções cónicas são aquelas em que a superfície da Terra é representada sobre um cone imaginário. A projeção mais simples é a que cria uma tangente ao longo de uma linha de latitude, sendo esta a linha onde existe menor distorção. A distorção aumenta proporcionalmente com a distância à linha tangente. Nestas projeções, as linhas paralelas de latitude são projetadas no cone como anéis. Normalmente, as projeções cónicas são usadas em zonas de latitude média que têm uma orientação este para oeste. Existem outras variações deste tipo: as projeções cónicas secantes que geram contacto com a superfície em duas localizações; as projeções cónicas obliquas em que o eixo do cone não coincide com o eixo polar do globo; as projeções cónicas equidistantes que produzem uma distorção mínima quando usada em pequenas áreas. Uma outra projeção é a projeção cónica conforme de Lambert em que o espaçamento entre os paralelos centrais é mais pequeno no centro do que os paralelos perto da fronteira permitindo manter as formas geométricas tanto para mapas de pequena e grande escala. Por último, a projeção cónica de área equivalente de Albers que produz áreas equivalentes. 3.3.2 Projeções Cilíndricas As projeções cilíndricas são aquelas em que o esferoide ou parte deste é projetado sobre um cilindro tangente ou secante. A projeção de Mercator é a projeção cilíndrica mais conhecida. Nesta projeção, normalmente o equador é a linha de tangencia e as restantes linhas de latitude e longitude são projetadas na superfície do cilindro, criando segmentos de reta perpendiculares
Sistemas de Informação Geográfica 20 entre si. Existem projeções cilíndricas mais complexas, onde existe a rotação do cilindro imaginário, alterando as linhas de tangência e secantes. A projeção transversa de Mercator é uma dessas projeções, onde a principal diferença é que o cilindro é perpendicular ao eixo de rotação da Terra elipsoidal e na projeção de Mercator o cilindro é paralelo ao eixo de rotação da Terra esférica. A projeção cilíndrica transversa secante de Mercator é utilizada no Sistema Universal Transverso de Mercator (UTM, do inglês Universal Transverse Mercator). O sistema UTM foi desenvolvido nos anos 1940 pelas forças armadas Norte Americanas. O sistema UTM divide a terra em 120 zonas, entre o paralelo sul 80º e o paralelo norte 84º em 60 fusos distintos, cada um com amplitude de 6º permitindo abranger toda a superfície terrestre. Estes fusos são numerados a partir do anti meridiano de Greenwich, de 1 até 60, de oeste para leste. Vários aparelhos recetores de GPS têm a opção de obter as coordenadas neste formato. 3.3.3 Projeções Planares As projeções planares, normalmente tocam na superfície terrestre em apenas um ponto, mas estas também podem ser secantes. Os pontos de contacto podem ser o polo norte, o polo sul, um ponto no equador ou outro ponto qualquer, sendo este ponto o foco da projeção (Kennedy, 2000). 3.4 Sistemas de Informação Geográfica Um sistema de informação, geográfico ou não, tem como objetivo suportar os utilizadores de alguma forma num determinado trabalho, ajudando a concretizá-lo mais depressa ou a obter resultados mais consistentes e aumentar a confiança nestes resultados. Estes sistemas são desenvolvidos ou adotados em função das necessidades das pessoas que trabalham numa determinada organização. Um sistema de informação geográfica é composto por: Pessoas – os utilizadores do sistema Aplicações – os processos e aplicações que usam para trabalhar Dados – a informação necessária para suportar estas aplicações Software – o núcleo do software SIG Hardware – as componentes físicas que o sistema é executado
Sistemas de Informação Geográfica 21 O desenvolvimento e implementação de um SIG tem como base as necessidades das pessoas que trabalham e termina nas aplicações que estas utilizam para concretizar o trabalho. O sistema como um todo existe para suportar as pessoas e as suas tarefas. As aplicações são desenvolvidas em função da missão e objetivos da organização e suportam os utilizadores a criar relatórios, tomar decisões e fundamentalmente ajudam a aplicar os conhecimentos para que o trabalho seja concluído. Estas aplicações lidam com informação que normalmente está organizada sob a forma de tabelas numa base de dados. Esta informação é gerida, acedida e manipulada através de software e utilizada pelas aplicações para que estas possam gerar um produto final útil. O hardware é o elemento menos importante, porém como faz parte do sistema deve ser apresentado (Harmon & Anderson, 2003). O objetivo de qualquer SIG é permitir ao utilizador questionar e analisar informação espacial, podendo ter várias finalidades, como por exemplo apoio na tomada de decisões, produção de informação e outras. A primeira ideia que surge sobre estes sistemas são os mapas que produzem. Além desta informação, estes sistemas produzem outros tipos de informação que pode ser bastante útil, como por exemplo uma simples tabela de dados relativos a uma localização geográfica. Existem quatro capacidades que um sistema de informação geográfica deve ter: Manipulação de dados - A manipulação de dados é realizada através das bases de dados e as ferramentas tradicionais, estendidas para suportar informação espacial. Este conjunto de aplicações permite questionar a base de dados, integrar informação de diferentes fontes para uma base de dados espacial, corrigir atributos ou dados espaciais, remover ou adicionar dados espaciais e outras funcionalidades. Capacidade analítica - A principal funcionalidade um SIG é permitir ao utilizador questionar sobre as relações geográficas entre elementos dos dados. Os elementos dos dados têm informação sobre as suas caraterísticas e suas localizações. Referenciamento espacial da informação de um atributo - O referenciamento espacial é o processo de atribuir coordenadas do mundo real aos elementos. Os elementos quando são inseridos com base em imagens digitalizadas ou fotografias aéreas podem conter vários tipos de distorção e erros de localização. São necessárias ferramentas para escalar, rodar e transladar as imagens para remover esta distorção. Entrada e saída de dados gráficos - Os SIG normalmente têm a opção de ter como imagem de fundo: imagens georreferenciadas, imagens aéreas ou de satélite. Em alguns casos, estas imagens auxiliam a construção de mapas, pois permitem ao utilizador ter uma contextualização do espaço em que estão a trabalhar. Por exemplo, na construção de uma estrada numa zona verde o auxílio de imagens aéreas podem
Sistemas de Informação Geográfica 22 ajudar a diminuir o impacto ambiental. Por outro lado, os SIG permitem também a saída de dados gráficos, gerando mapas baseados na seleção de atributos. Esta informação gráfica pode ajudar a compreender melhor a informação tabular (Kropla, 2005). Os softwares SIG podem ser agrupados em sete categorias principais: aplicações desktop, sistemas de gestão de base de dados espaciais, servidor de mapas web, servidores SIG, clientes web de mapas, aplicações móveis e livrarias e extensões (Steiniger & Hunter, 2012). Neste capítulo são apresentadas algumas destas categorias e aplicações que ajudam a descrever cada tipo de software. Antes da apresentação destas categorias, são descritos alguns fornecedores de mapas que permitem a exportação de dados para uso posterior. 3.5 Fornecedores de Mapas Os mapas digitais disponibilizados na internet são um conceito relativamente recente. O primeiro mapa incorporado numa página da internet foi apresentado no navegador Mosaic em 1993. No início os mapas digitais eram mapas em papel digitalizados e apresentados como uma imagem. No final dos anos 90 os mapas começaram a ser armazenados em grandes centros de dados. A utilização de mapas em dispositivos móveis surgiu com a introdução do iPhone da Apple em 2007. (Peterson, 2012) Nos dias de hoje, normalmente os mapas são uma mistura de informação livre com informação comercial. Os maiores fornecedores de informação comercial são a NAVTEQ (NAVTEQ, 2003) e a Tele Atlas propriedade da TomTom (TomTom, portable GPS car navigation systems, 2013). Estes oferecem um serviço que tem um preço muito elevado, a informação cobre áreas específicas e é facilmente desatualizada. O OpenStreetMap (OpenStreetMap, 2013) é um projeto que aborda a construção de mapas de outra forma, tendo como objetivo a construção de uma base de dados de mapas gratuita e construída pelos utilizadores. Alguns fornecedores importantes de mapas, como por exemplo a MapQuest (MapQuest, 2013) e os mapas Bing da Microsoft têm vindo a adotar o OpenStreetMap como base para os seus mapas. Estes grandes fornecedores por sua vez oferecem ferramentas para contribuir no projeto OpenStreetMap (Schmidt & Weiser, 2012). Alguns destes fornecedores de mapas permitem a exportação de dados, normalmente no formato XML, que podem ser posteriormente analisados e usados para a construção de um conjunto de dados estruturados da forma desejada. 3.5.1 Google Maps O Google conhecido pelo seu motor de busca foi a empresa que mais impacto teve nos mapas digitais disponibilizados na internet através do Google Maps. O Google Maps vieram
Sistemas de Informação Geográfica 23 revolucionar os serviços de mapas incluindo um motor de pesquisa e mudando também a forma de interação que os utilizadores tinham com este tipo de aplicações. O Google Maps também inovou na forma de rentabilizar o serviço de mapas. Em vez de apresentar publicidade nas páginas, a Google cobra às empresas para que estas apareçam nas pesquisas feitas pelos utilizadores. Os mapas são divididos e entregues em várias imagens, como se a imagem fosse composta por vários azulejos, permitindo a transferência de dados mais rápida. Por serem vários ficheiros e mais pequenos demoram menos tempo a serem entregues porque podem tomar rotas diferentes até ao destino. No fim, todas as imagens são agrupadas e apresentadas na localização apropriada da página web. Utilizando boas ligações de internet o utilizador raramente se apercebe que o mapa é composto por várias imagens. Em 2005, após a introdução do Google Maps, surge a API deste serviço que consiste num conjunto de funções relacionadas com os mapas. A principal funcionalidade é tornar possível a incorporação de mapas em páginas web e permitir a possibilidade de adicionar informação de outras fontes. Além disso, é possível controlar a aparência dos mapas, alterando a escala, posição ou adicionar informação na forma de pontos, linhas ou áreas. O uso da API do Google Maps é gratuito mas limitado a 25000 pedidos por dia, no entanto existe uma versão comercial chamada Google Maps Premier sem limites de pedidos e que tem algumas funcionalidades adicionais. (Peterson, 2012) Em 2008, a Google introduz uma nova ferramenta chamada Map Maker que permite aos utilizadores contribuir na construção de mapas. Esta ferramenta apenas está disponível para zonas do globo onde há pouca cobertura de dados comerciais, como por exemplo na India, Paquistão e Islândia, mas este conceito deve ser alargado a todas a zonas do planeta. (Schmidt & Weiser, 2012) Em Junho de 2009, a Google lança o serviço Fusion Tables. O Google Fusion Tables é um serviço de gestão de dados e integração desenhada para organizações que pretendem disponibilizar dados na internet e em situações que os utilizadores necessitam de colaborar na gestão da informação entre empresas e organizações. O Google Fusion Tables permite a importação de informação até 100 MB na forma de tabela, nos formatos comuns deste tipo como por exemplo em CSV. Esta informação pode conter vários tipos de informação geográfica como por exemplo pontos, linhas e polígonos e pode ser exportada para o formato KML (Keyhole Markup Language), por forma a ser visualizada no Google Earth. A informação pode ainda ser apresentada sob a forma de gráficos, mapas ou linhas temporais. O sistema disponibiliza várias funcionalidades de gestão de acesso, comentários à informação, suporte de filtros e consulta de dados e ainda a integração de informação de diferentes fontes (Gonzalez, et al., 2010) .
3.8.2 OpenJUMP O OpenJUMP (OpenJUMP, 2013) grupo de voluntários de todo o mundo. Inicialmente esta aplicação foi desenhada pela Vivid Solutions (Solutions, 2013) e era conhecida por JUMP GIS. Esta aplicação permite a leitura e escrita de ficheiros shapefile e GML. A aplicação suporta também as especificações WFS e WMS, permitindo a visualização e edição de geometr seus atributos. O OpenJUMP permite exportar as visualizações para SVG. Esta aplicação tem algumas limitações em carregar ficheiros de dados muito grandes e nas projeções cartográficas suportadas 3.9 Clientes Web de Mapas Os clientes web de mapas são aplicações que têm um papel importante em portais de dados espaciais que podem ser acedidos na internet utilizando um navegador web. Estas aplicações permit em a visualização, consulta e análise de informação georreferenciada que pode ser obtida de diferentes fontes através dos serviços web OGC. Figura 6 - Ecrã exemplo da aplicação Sistemas de Informação Geográfica 30 (OpenJUMP, 2013) é uma aplicação livre desenvolvida em grupo de voluntários de todo o mundo. Inicialmente esta aplicação foi desenhada pela Vivid e era conhecida por JUMP GIS. Esta aplicação permite a leitura e escrita de ficheiros shapefile e GML. A aplicação suporta também as especificações WFS e WMS, permitindo a visualização e edição de geometr seus atributos. O OpenJUMP permite adicionar estilos aos dados mapeados na aplicação e permite exportar as visualizações para SVG. Esta aplicação tem algumas limitações em carregar ficheiros de dados muito grandes e nas projeções cartográficas suportadas (OpenJUMP, 2013) Clientes Web de Mapas Os clientes web de mapas são aplicações que têm um papel importante em portais de dados espaciais que podem ser acedidos na internet utilizando um navegador web. Estas aplicações em a visualização, consulta e análise de informação georreferenciada que pode ser obtida de diferentes fontes através dos serviços web OGC. Ecrã exemplo da aplicação OpenJUMP. é uma aplicação livre desenvolvida em Java por um grupo de voluntários de todo o mundo. Inicialmente esta aplicação foi desenhada pela Vivid Esta aplicação permite a leitura e escrita de ficheiros shapefile e GML. A aplicação suporta também as especificações WFS e WMS, permitindo a visualização e edição de geometr ias e permite adicionar estilos aos dados mapeados na aplicação e permite exportar as visualizações para SVG. Esta aplicação tem algumas limitações em carregar (OpenJUMP, 2013) . Os clientes web de mapas são aplicações que têm um papel importante em portais de dados espaciais que podem ser acedidos na internet utilizando um navegador web. Estas aplicações em a visualização, consulta e análise de informação georreferenciada que pode ser obtida
3.9.1 Geoide O Geoide (Geoide, 2013) pela IDgis, uma empresa especializada em SIG com base de dados e internet. O Geoide foi desenhado existindo uma integração perfeita entre estas duas aplica disponibilizar uma aplicação através da internet. A aplicação também permite adicionar e edição de elementos georreferenciados no mapa. Ao nível de acesso, a apli autorização de acesso aos mapas e opções do menu Figura 7 - Ecrã exemplo da aplicação Sistemas de Informação Geográfica 31 (Geoide, 2013) é um cliente web de mapas livre e de código aberto dese pela IDgis, uma empresa especializada em SIG com base de dados e internet. O Geoide foi desenhado para interagir com o servidor de mapas Deegree existindo uma integração perfeita entre estas duas aplicações. O principal objetivo é disponibilizar uma aplicação user friendly que permita a pesquisa e apresentação de dados SIG através da internet. A aplicação também permite adicionar e edição de elementos georreferenciados no mapa. Ao nível de acesso, a aplicação permite definir vários níveis de autorização de acesso aos mapas e opções do menu (Geoide, 2013). Ecrã exemplo da aplicação Geoide. é um cliente web de mapas livre e de código aberto dese nvolvido para interagir com o servidor de mapas Deegree (Deegree, 2013) ções. O principal objetivo é que permita a pesquisa e apresentação de dados SIG através da internet. A aplicação também permite adicionar e edição de elementos cação permite definir vários níveis de
3.9.2 GPAAMP O Global Protected Areas Assessment and Monitoring Pilot Viewer (GPAAMP) 2013) é uma aplicação que faz parte de um conjunto de ferramentas desenvolvidas pela Global Biodiversity Facility. O GPAAMP é um cliente web de mapas livre que suporta a visualização de dados de diferentes servidores utilizando os serviços WMS, WFS, GeoR permite também a adicionar, editar e apagar dados utilizando o serviço web WFS 3.9.3 GeoExplorer O GeoExplorer é uma aplicação web baseada na publicação de mapas. A aplicação é um cliente we aplicações OpenGeo Suite podendo facilmente utilizar dados provenientes do GeoServer ou qualquer servidor de mapas que siga as especificações OGC. Figura 8 - Ecrã exemplo da aplicação Sistemas de Informação Geográfica 32 O Global Protected Areas Assessment and Monitoring Pilot Viewer (GPAAMP) é uma aplicação que faz parte de um conjunto de ferramentas desenvolvidas pela Global O GPAAMP é um cliente web de mapas livre que suporta a visualização de dados de diferentes servidores utilizando os serviços WMS, WFS, GeoRSS e dados KML. Esta aplicação permite também a adicionar, editar e apagar dados utilizando o serviço web WFS O GeoExplorer é uma aplicação web baseada na framework GeoExt, para a composição e publicação de mapas. A aplicação é um cliente web de mapas que faz parte do pacote de aplicações OpenGeo Suite podendo facilmente utilizar dados provenientes do GeoServer ou qualquer servidor de mapas que siga as especificações OGC. Ecrã exemplo da aplicação GPAAMP. O Global Protected Areas Assessment and Monitoring Pilot Viewer (GPAAMP) (Tools, é uma aplicação que faz parte de um conjunto de ferramentas desenvolvidas pela Global O GPAAMP é um cliente web de mapas livre que suporta a visualização de dados de SS e dados KML. Esta aplicação permite também a adicionar, editar e apagar dados utilizando o serviço web WFS -T. GeoExt, para a composição e b de mapas que faz parte do pacote de aplicações OpenGeo Suite podendo facilmente utilizar dados provenientes do GeoServer ou
Além de permitir a edição de dados é possível também editar os esti contidos nos mapas. O conjunto de aplicações OpenGeo permite desenvolver aplicações de raiz semelhantes ao GeoExplorer, utilizando o OpenGeo SDK. Por vezes, estas aplicações de raiz são referidas como GeoExplorer, pois podem ter as mesmas 3.10 Conclusões A utilização e configuração de sistemas de informação geográfica requer o conhecimento e compreensão de um conjunto de conceitos relacionados com os sistemas de coordenadas geográficas. A necessidade de trabalhar com coordenad coordenadas projetada s, mais concretamente a compreensão dos diferentes tipos de projeções e as distorções que estas produzem. Os sistemas de informação geográfica por serem muito versáteis são aplicados em di áreas. Neste projeto, existe a necessidade de trabalhar com elementos que têm informação espacial e por isso existe a possibilidade de tirar partido da maturidade destas aplicações. Figura 9 - Ecrã ex emplo da aplicação GeoExplorer. Sistemas de Informação Geográfica 33 Além de permitir a edição de dados é possível também editar os estilos dos elementos O conjunto de aplicações OpenGeo permite desenvolver aplicações de raiz semelhantes ao GeoExplorer, utilizando o OpenGeo SDK. Por vezes, estas aplicações de raiz são referidas como GeoExplorer, pois podem ter as mesmas funcionalidades. A utilização e configuração de sistemas de informação geográfica requer o conhecimento e compreensão de um conjunto de conceitos relacionados com os sistemas de coordenadas A necessidade de trabalhar com coordenadas cartesianas implica o estudo de sistemas de s, mais concretamente a compreensão dos diferentes tipos de projeções e as distorções que estas produzem. Os sistemas de informação geográfica por serem muito versáteis são aplicados em di áreas. Neste projeto, existe a necessidade de trabalhar com elementos que têm informação espacial e por isso existe a possibilidade de tirar partido da maturidade destas aplicações. emplo da aplicação GeoExplorer. los dos elementos O conjunto de aplicações OpenGeo permite desenvolver aplicações de raiz semelhantes ao GeoExplorer, utilizando o OpenGeo SDK. Por vezes, estas aplicações de raiz são referidas A utilização e configuração de sistemas de informação geográfica requer o conhecimento e compreensão de um conjunto de conceitos relacionados com os sistemas de coordenadas as cartesianas implica o estudo de sistemas de s, mais concretamente a compreensão dos diferentes tipos de projeções e Os sistemas de informação geográfica por serem muito versáteis são aplicados em di versas áreas. Neste projeto, existe a necessidade de trabalhar com elementos que têm informação espacial e por isso existe a possibilidade de tirar partido da maturidade destas aplicações.
Sistemas de Informação Geográfica 34 No capítulo 5 é realizada uma comparação mais aprofundada sobre as aplicações abordadas neste capítulo, nomeadamente as aplicações apresentadas como servidores de mapas e clientes web de mapas. O estudo dos fornecedores de mapas está principalmente relacionado com a informação que estes serviços disponibilizam no sentido de auxiliarem os utilizadores na construção de informação. As políticas de funcionamento do fornecedor de mapas OpenStreetMap permitem que este serviço possa ter informação mais atualizada do que os outros fornecedores de mapas. Devido a disponibilizar a informação gratuitamente, este serviço é uma opção com viabilidade superior quando comparado com os outros serviços. Estas e outras características do OpenStreetMap fazem com que este serviço seja integrado em vários projetos tecnológicos.
Simuladores de Tráfego 35 Capítulo 4 Simuladores de Tráfego 4.1 Simulação Os desenvolvimentos tecnológicos, nomeadamente a invenção e evolução de microprocessadores tiveram um papel fundamental na evolução da simulação, principalmente na simulação por computador. O desenvolvimento computacional foi também essencial para o programa espacial da NASA, onde a simulação tem um papel muito importante e é utilizada para estudar o lançamento e reentrada de projeções poupando vidas e dinheiro que seriam perdidos em testes de lançamento. Nos dias de hoje, a simulação e a modelação são usadas extensamente não só para verificar se um sistema funciona mas também para saber qual o melhor numa determinada situação (Guizani, Rayes, Khan, & Al-Fuqaha, 2010). Segundo Jerry Banks, a simulação é a imitação de uma operação de um processo do mundo real ou de um sistema ao longo do tempo. A simulação envolve a geração de uma "história artificial" de um sistema e sua observação para retirar conclusões sobre as características de funcionamento do sistema real que é representado. A simulação é uma metodologia indispensável na resolução de problemas da vida real, usada para descrever e analisar o comportamento de sistemas, permitindo realizar questões “what-if” e verificar exceções. As simulações podem ser executadas em sistemas já existentes ou em sistemas conceptuais. Um modelo de simulação é a representação do sistema. Depois de concebido e validado este permite o estudo de questões feitas ao sistema ou avaliar o comportamento do sistema em diferentes cenários. Existem vários tipos de modelos: modelos de eventos discretos-contínuos, matemáticos, descritivos, estatísticos e entrada-saída. O modelo de eventos discretos-contínuos tenta representar os componentes de um sistema e suas interações para uma extensão que os objetivos de estudo são conhecidos. Os modelos de eventos discretos-contínuos são dinâmicos em que o tempo tem grande relevância. Contrastando com estes, os modelos matemáticos, estatísticos e
Simuladores de Tráfego 36 de entrada-saída são normalmente estáticos, representam um sistema de entrada e saída mas a estrutura interna do modelo varia entre relações matemáticas e estatísticas (Banks, 1998). 4.2 Simulação de Tráfego Normalmente a simulação é utilizada em sistemas complexos, em que o problema não é facilmente resolvido usando simples cálculos, métodos analíticos ou experiências diretas. Uma das áreas que recorre à simulação devido à sua complexidade é a engenharia de tráfego. Os modelos utilizados na simulação de tráfego são formados por várias entidades (veículos, controladores de tráfego, pedestres) que atuam no sistema de forma diferente (em competição, cooperação) sob modelos matemáticos. A simulação de tráfego permite a comparação entre infraestruturas e controlos ou a criação de situações hipotéticas sem interferir com o sistema real e sem despender recursos. Através dos simuladores de tráfego, o transporte de pessoas e bens torna-se um problema mais consciente no que diz respeito ao ambiente, acessibilidade, segurança e sustentabilidade de recursos. (Kokkinogenis, Sanchez Passos, Rossetti, & Gabriel, 2011) Na simulação um dos aspetos fundamentais de caracterização é a forma de evolução do modelo de simulação em função do tempo. Na simulação existem duas abordagens metodológicas para lidar o tempo: tempo assíncrono e tempo síncrono. Nas simulações com tempo síncrono, utilizadas nas principais abordagens, existe uma unidade de tempo que dita cada passo na simulação. Nas simulações assíncronas o tempo avança em quantidades variáveis, correspondendo a instantes de tempo nos quais ocorrem eventos que alteram o estado do modelo (Barceló J. , 2010). As aplicações de simulação de tráfego podem ainda ser classificadas em três categorias principais: microscópica, macroscópica e mesoscópica (Figura 10). Figura 10 - Diferentes categorias dos modelos de simulação (da esquerda para a direita: macroscópico, microscópico, nanoscópico; dentro do circulo: mesoscópico) (Krajzewicz, Hertkorn, Wagner, & Rössel, 2002).
Simuladores de Tráfego 37 Os simuladores microscópicos modelam entidades individuais (veículo, condutor) e permitem considerar as características de vários tipos de veículos e estilos de condução. Os modelos microscópicos requerem dois conjuntos de dados principais: um conjunto que descreve a geometria da rede de transporte incluindo semáforos, detetores, painéis de mensagens variáveis; e um conjunto que descreve detalhadamente o comportamento do tráfego reproduzindo a dinâmica de cada veículo, permitindo distinguir o tipo de veículo e a possibilidade de considerar vários aspetos no comportamento dos condutores (Barceló, Ferrer, García, & Grau). Normalmente, são usados para estudar o tráfego detalhado, em áreas pequenas, como por exemplo o tráfego em rampas, afunilamentos e interseções ou avaliar medidas na otimização de tráfego. Estes modelos podem ser construídos usando autómatos celulares, simulação multiagentes, simulação de sistemas de partículas. Um dos problemas que pode surgir neste tipo de simuladores é o consumo de CPU devido à utilização de um elevado número de variáveis (Helbing, 1998). A eficiência computacional pode ser alcançada por simuladores macroscópicos. Estes lidam com grupos de veículos, como se deslocassem todos na mesma direção e tivessem o mesmo comportamento. Os simuladores macroscópicos modelam o fluxo de tráfego usando modelos matemáticos de alto nível derivados da dinâmica de fluídos e dispersão estatística. Esta abordagem não é muito realista porque no mundo real existem vários tipos de veículos e diferentes estilos de condução (Kokkinogenis, Sanchez Passos, Rossetti, & Gabriel, 2011). Os modelos mesoscópicos abrangem aspetos dos simuladores microscópicos e macroscópicos, preenchendo o espaço entre a abordagem de nível agregado dos modelos macroscópicos e as interações individuais dos modelos microscópicos. Estes modelos são aplicados em situações em que é desejável o detalhe da simulação microscópica mas é inviável devido às grandes dimensões da rede ou os recursos disponíveis para a codificação e depuração da rede são limitados (Burghout, 2004). Existem também modelos híbridos que combinam dois ou três tipos de simuladores mencionados anteriormente. Estes têm o objetivo de combinar as potencialidades e diminuir as fraquezas dos tipos de modelos envolvidos. Outro tipo de modelos de simulação emergente conhecido como modelos nanoscópicos, permite uma modelação mais detalhada do que a modelação microscópica em três componentes básicas: modelação dos veículos, modelação do movimento dos veículos e modelação do comportamento dos condutores. Nas seguintes secções são apresentados vários simuladores de tráfego e evidenciadas caraterísticas destas aplicações que podem ser relevantes para o projeto apresentado neste documento.
4.3 SUMO O SUMO ( Simulation of Urban MObility mic roscópico. O desenvolvimento da aplicação começou no ano de 2000, uma colaboração entre o ZAIK ( Center for Applied Informatics Cologne (ITS) no DLR ( German Aerospace Center continuado apenas pelo DLR, com a contribuição de organizações externas e contribuições individuais. O SUMO é uma aplicação livre sob a licença GNU em que o código fonte e a aplicação estão disponíveis para múltiplas plataformas Windows e Linux. A fonte permite que a aplicação seja a base de trabalho para investigadores, diminuindo assim o número de projetos que não são concluídos devido aos vários problemas que têm de ser resolvidos nestes projetos. A aplicação SUMO não te conjunto de ferramentas que facilitam a importação de dados para a aplicação. As ferramentas permitem o processamento e enriquecimento de ficheiros que contêm informação de redes de estradas e p osteriormente sejam usados como dados de entrada para simulação. Figura 11 - Ecrã exemplo da aplicação SUMO Simuladores de Tráfego 38 Simulation of Urban MObility) é uma aplicação de simulação de tráfego roscópico. O desenvolvimento da aplicação começou no ano de 2000, uma colaboração Center for Applied Informatics Cologne ) e o ITS ( Institute of Transport Systems German Aerospace Center). Desde 2004, o trabalho desenvolvido no continuado apenas pelo DLR, com a contribuição de organizações externas e contribuições O SUMO é uma aplicação livre sob a licença GNU em que o código fonte e a aplicação estão disponíveis para múltiplas plataformas Windows e Linux. A disponibilidade do código fonte permite que a aplicação seja a base de trabalho para investigadores, diminuindo assim o número de projetos que não são concluídos devido aos vários problemas que têm de ser A aplicação SUMO não tem incluído um editor de redes de estradas. No entanto, tem um conjunto de ferramentas que facilitam a importação de dados para a aplicação. As ferramentas permitem o processamento e enriquecimento de ficheiros que contêm informação de redes de osteriormente sejam usados como dados de entrada para simulação. Ecrã exemplo da aplicação SUMO . ) é uma aplicação de simulação de tráfego roscópico. O desenvolvimento da aplicação começou no ano de 2000, uma colaboração Institute of Transport Systems ) ). Desde 2004, o trabalho desenvolvido no SUMO é continuado apenas pelo DLR, com a contribuição de organizações externas e contribuições O SUMO é uma aplicação livre sob a licença GNU em que o código fonte e a aplicação disponibilidade do código fonte permite que a aplicação seja a base de trabalho para investigadores, diminuindo assim o número de projetos que não são concluídos devido aos vários problemas que têm de ser m incluído um editor de redes de estradas. No entanto, tem um conjunto de ferramentas que facilitam a importação de dados para a aplicação. As ferramentas permitem o processamento e enriquecimento de ficheiros que contêm informação de redes de osteriormente sejam usados como dados de entrada para simulação.
Simuladores de Tráfego 39 A ferramenta do SUMO para importar redes de estradas chama-se “NETCONVERTER” e permite leitura de redes VISUM, TIGER, shapefiles ArcView, Vissim, pastas Robocup Rescue League, OpenStreetMap e redes de estradas representadas no formato XML. A informação contida nestes ficheiros não é suficiente para que possa ser usada no simulador de tráfego. Por exemplo, não existe informação sobre regras de prioridade em cruzamentos, qual a faixa da via se deve usar para seguir uma estrada e até informação sobre a posição dos semáforos. Caso esta informação não exista, o NETCONVERT aplica heurísticas que adicionam essa informação. Estas heurísticas incluem: Computação de mudança de direção em cada rua Computação de ligações entre vias Computação do tipo de intersecções (direita antes de esquerda, intersecções com ruas de alta prioridade) Computação da regra de cedência de passagem à direita para ruas que participam numa intersecção. Computação das estradas e da geometria das intersecções O NETCONVERT contém também heurísticas para determinar a posição dos semáforos e para os programas destes, para determinar onde devem ser adicionadas rampas de entrada e saída de vias rápidas. Normalmente uma execução da aplicação NETCONVERT produz uma rede realista, no entanto é necessário uma inspeção manual e alguns ajustamentos posteriores (Krajzewicz, Traffic Simulation with SUMO - Simulation of Urban Mobility, 2010). 4.4 DRACULA O DRACULA (Dynamic Route Assignment Combining User Learning and Microsimulation) é um simulador de redes microscópico que tem sido desenvolvido pelo ITS (Institute for Transport Studies), na Universidade de Leeds. O DRACULA é composto por um modelo de procura e de oferta por forma a implementar os conceitos na tomada de decisões do dia-a-dia e dinâmicas entre dias. Na fase de procura prevê o nível de procura num determinado dia tendo como base uma população de potenciais condutores. No lado da oferta os veículos movem-se individualmente nas redes para os seus destinos, e os condutores são capazes de recolher informação sobre as condições de viagem para melhorar as decisões a tomar. As principais escolhas disponíveis são a rota e o horário de partida, no entanto a modularidade permite o desenvolvimento de outras escolhas (Rossetti & Liu, 2005).
Simuladores de Tráfego 46 4.7.2 Verificação, Calibração e Validação do Modelo Antes de proceder à calibração do modelo, ou seja modificar os parâmetros deste, o utilizador deve verificar todos os dados inseridos durante a fase de construção do modelo. Na verificação é também importante assegurar que a descrição do modelo corresponde aos objetivos de estudo. A calibração é um processo iterativo que consiste na alteração dos parâmetros do modelo e na comparação dos dados de saída com os dados reais até que exista uma sintonia entre os dois conjuntos de dados. Os dados que devem ser comparados dependem do tipo de modelo, do objetivo de estudo e o tipo de rede. Por exemplo, no caso de estudo de um modelo de uma via rápida, devem ser medidos os valores de velocidade, fluxo, densidade, utilização das vias e propagação do congestionamento. No fim da calibração, o modelo deve ser validado, comparando os valores de saída com um conjunto de dados reais não utilizado durante a fase de calibração. No caso da comparação entre os dois conjuntos atingir um nível definido previamente, o modelo pode ser considerado válido e adequado para o estudo de cenários futuros até que não haja mudanças no mundo real que invalidem as suposições feitas no modelo. 4.7.3 Análise dos Dados de Saída Os dados produzidos variam consoante o tipo de modelo. Os modelos dinâmicos produzem séries de tempo em que cada valor é a agregação de dados coletados durante um intervalo definido pelo utilizador. As simulações mesoscópicas, para cada secção produzem os seguintes dados: fluxo (disponível também para viragens), densidade, velocidade, tempo de viagem e tempo de atraso, tamanho da fila. As simulações microscópicas produzem: fluxo, densidade, velocidade e velocidade harmónica, tempo de viagem e tempo de atraso, tamanho da fila, paragens e tempos de paragens, poluição e consumo de combustível e dados de trajetória (Casas, Ferrer, Garcia, Perarnau, & Torday, 2010). 4.8 Conclusões Os simuladores de tráfego quando utilizados corretamente, podem ter um impacto extraordinário na qualidade de vida de pessoas. Além disso, estas aplicações têm um papel fundamental na projeção e otimização das redes de transporte, permitindo a criação de situações hipotéticas sem interferir com o sistema real e sem despender recursos.
Simuladores de Tráfego 47 Sendo um dos objetivos do trabalho a produção de ficheiros para os simuladores de tráfego, o estudo destes é inevitável. Essencialmente, é necessário identificar quais as entidades e as variáveis que podem ser descritas nestes ficheiros. Esta informação varia consoante o tipo de simulador mas também entre simuladores de tráfego que pertencem a um determinado tipo de simuladores. Neste capítulo foram apresentados alguns simuladores de tráfego e possíveis entidades que devem ser modeladas na plataforma.
Solução Proposta e Resultados 48 Capítulo 5 Solução Proposta e Resultados 5.1 Introdução Neste capítulo, em primeiro será apresentada uma possível solução genérica para o problema. A identificação dos requisitos do sistema é uma tarefa indispensável na elaboração de uma hipótese, pois só assim é possível reconhecer as necessidades existentes. Após a definição de uma solução genérica, procede-se à identificação de projetos já desenvolvidos que podem contribuir para uma solução específica. Existem várias vantagens na adoção de projetos: desperdício de recursos a tentar “reinventar a roda”, a maturidade dos projetos, o suporte que as comunidades oferecem e outras vantagens. Perante as possibilidades, é necessário avaliar quais as melhores soluções e quais as soluções que preenchem melhor os requisitos identificados, por forma a tomar uma decisão responsável e consciente. As soluções de software a adotar normalmente podem ser livres ou comerciais. O software livre tem vários benefícios bem conhecidos, tais como licenças gratuitas, não tem restrições de utilização (como por exemplo limites de instalações), obrigatoriedade de atualização, suporte de normas abertas, suporte de vários fornecedores e customização ao nível da API. Este tipo de aplicações pode requerer conhecimentos informáticos para a instalação. Dependendo do nível de conhecimentos dos utilizadores e da complexidade da aplicação, pode ser necessário formação para a utilização das aplicações que pode implicar em custos para a organização. As aplicações comerciais, normalmente incluem na licença a garantia de que as componentes da aplicação funcionam em conjunto. Normalmente estas aplicações são muito bem documentadas. Este tipo de aplicações pode ter custo de aquisição, manutenção e de formação. A manutenção das aplicações pode ser vinculada a empresas específicas e a customização das aplicações pode não ser possível devido aos recursos dos fornecedores (Steiniger & Bocher, 2008).
Solução Proposta e Resultados 49 A adoção de projetos já existentes, apenas contribui para uma parte da solução, ou seja, não resolve por completo a solução. É necessário uma adaptação destes projetos aos requisitos identificados, podendo ser necessário a alteração destes projetos ou mesmo a construção de novas componentes. A apresentação das componentes constituí uma descrição dos procedimentos tomados no desenvolvimento, uma descrição detalhada das funcionalidades da aplicação e os resultados obtidos. 5.2 Identificação dos Requisitos Os requisitos funcionais identificados apresentados são descritos a alto nível, sintetizando as componentes que o sistema deve ter. As componentes identificadas são essenciais para que o sistema funcione como um todo e realmente permita aos utilizadores solucionar os problemas identificados. Requisito "Sistema de Gestão de Dados Georreferenciados" - Pretende-se que o sistema possua uma base de dados e uma arquitetura que permita manter e gerir a informação relacionada com a simulação de tráfego. Este sistema deve também permitir dados georreferenciados. Requisito "Editor e visualizador que permita edição colaborativa" - A plataforma deve permitir a gestão colaborativa dos dados contidos na base de dados. Estes dados podem ser georreferenciados ou dados não georreferenciados. Requisito "Aplicação que permita a importação de dados de fornecedores de mapas" - A plataforma deve disponibilizar um serviço web que permita a importação de dados de fornecedores de mapas para a base de dados. Requisito "Geração de Ficheiros para simuladores de Tráfego" - A plataforma deve disponibilizar um serviço web que produza ficheiros aceites por simuladores de tráfego usando a informação contida na base de dados. 5.3 Solução Proposta A solução proposta apresentada na Figura 15 consiste em: Um servidor de mapas, Um visualizador e editor de dados,
Solução Proposta e Resultados 50 Uma base de dados com suporte para dados georreferênciados, Um serviço que funciona como webcrawler permitindo importar informação de fornecedores de mapas, Um serviço que permite gerar ficheiros aceites em simuladores de tráfego Figura 15 - Solução genérica para o problema 5.4 Processo de Seleção de aplicações SIG a adotar no projeto O processo de seleção de uma aplicação livre GIS a adotar, tanto numa situação empresarial, investigação ou educação deve ser baseado num processo de avaliação. Na literatura existem vários processos de seleção, todos muito similares. A escolha de um destes processos deve ser feita em função do caso em estudo. Em algumas situações pode ser necessário um processo de seleção mais exigente implicando uma análise mais profunda ao software. O processo de seleção escolhido para avaliar o software é baseado no processo definido por Sveen (Sveen, Use of free and open source GIS in commercial firms, 2008) e consiste nos seguintes passos:
Solução Proposta e Resultados 51 1. Definir os requisitos 2. Definir quais os projetos candidatos 3. Criar uma tabela de avaliação 4. Avaliar e selecionar o projeto. Os critérios de avaliação usados no processo de seleção são baseados num conjunto de critérios apresentados por Steiniger e Hunter (Steiniger & Hunter, 2012). Neste processo são considerados os seguintes critérios: Funcionais: Funcionalidade requerida, Funcionalidades desejáveis, Opções de customização. Técnico: Sistemas Operativos suportados, Linguagem de Programação Organizacional: Tamanho da comunidade de desenvolvimento, Drivers do projeto e liderança Suporte: Documentação, Listas de Emails, Fóruns, Wikis Económica: Custos de Treino, Custos de Manutenção Legal: Tipo de Licença (GPL, LGPL, BSD) 5.4.1 Avaliação das Aplicações de Servidores de Mapas A melhor solução para preencher o primeiro requisito funcional descrito anteriormente, "Sistema de Gestão de Dados Georreferenciados" é adotar um projeto já existente. Para solucionar este problema é necessário uma base de dados com suporte de dados georreferenciados e um servidor de mapas que facilite o acesso à informação contida na base de dados. As soluções comerciais de servidores de mapas têm um custo de aquisição muito elevado e têm o mesmo desempenho que as soluções de software livre, por estas razões as soluções comerciais não são consideradas neste processo. As melhores soluções de software livre referentes a servidores de mapas e que têm uma performance semelhante são o GeoServer e o MapServer (Steiniger & Hunter, 2012).
Solução Proposta e Resultados 52 5.4.1.1 Critérios Funcionais Funcionalidade requerida - Ambas as soluções apresentam as funcionalidades requeridas, exceto para a especificação WFS-T. O MapServer não suporta a especificação WFS-T. É necessário a instalação da aplicação TinyOWS no servidor. Funcionalidades desejáveis - Neste aspeto, o GeoServer destaca-se devido ao Editor e Visualizador web existente no pacote OpenGeo, o GeoExplorer. Esta aplicação apresenta uma interface muito apelativa e aparenta ter um potencial maior quando comparada com outras aplicações. Opções de Customização - O OpenGeo Suite permite o desenvolvimento de raiz de um editor e visualizador web utilizando o OpenGeo SDK e possibilita a fácil integração de scripts existentes no GeoExplorer. O OpenGeo permite também o fácil desenvolvimento e integração de aplicações REST. 5.4.1.2 Critérios Técnicos Sistemas Operativos Suportados - Ambas as aplicações são suportados nos sistemas operativos mais comuns: GNU/Linux, MS-Windows, Mac OS X. O GeoServer é executado num servidor Jetty ou Apache Tomcat. O MapServer é executado num servidor normal Apache ou IIS. Linguagem de programação - No OpenGeo Suite, o GeoServer é desenvolvido na linguagem Java. Quanto ao MapServer é desenvolvido em C. 5.4.1.3 Critérios Organizacionais Tamanho da Organização - O número de colaboradores nos projetos é difícil de determinar, porém no projeto GeoServer existem três organizações envolvidas, a OpenGeo, a GeoSolutions e a Refractions Research.
Solução Proposta e Resultados 53 5.4.1.4 Critérios de Suporte Documentação - O OpenGeo dispõe de uma extensa documentação orientada para vários tipos de utilizadores: utilizadores comuns do sistema, administradores ou programadores. Na página web do OpenGeo estão também disponíveis workshops gratuitos, sobre as várias componentes deste pacote de software: OpenGeo Suite, PostGIS, GeoServer, GeoWebCache, OpenLayers e GeoExt. Estes workshops práticos, têm instruções para a instalação e utilização das aplicações de uma forma simples e clara. Fóruns - A página stackexchange.com é uma comunidade de suporte em várias áreas onde os utilizadores podem fazer perguntas a outros utilizadores. Esta página tem uma secção de assuntos relacionados com SIG, com o endereço gis.stackexchange.com, onde podem também ser feitas questões sobre estes projetos. Existe grande probabilidade das perguntas serem respondidas e em tempo aceitável. No caso de os utilizadores contactarem diretamente as empresas e administração dos projetos existe uma alta probabilidade do suporte profissional ser pago. Existem também sessões de formação disponibilizadas pelas empresas, no entanto estas também são pagas. No caso do OpenGeo Suite, existia outra página de suporte que permite questionar funcionários da empresa. Este serviço já não funciona nesta página mas o arquivo das questões feitas pode ser consultado. Este serviço está alojado no website GetSatisfaction.com. 5.4.1.5 Critérios Legais Tipo de Licença - A licença do GeoServer é GPL, sendo esta a mais usada em software livre e garante a permissão aos utilizadores finais de poderem usar, estudar, partilhar e modificar o software. Quanto ao MapServer a licença é X/MIT, que é também uma licença de software livre, permitindo a reutilização dentro de um software proprietário. 5.4.2 Seleção do Projeto de Servidores de Mapas As duas soluções de servidores de mapas são muito semelhantes, oferecendo as mesmas funcionalidades. Uma revisão recente sugere que o GeoServer é mais fácil para adicionar componentes e segue as normas de mapeamento com mais rigor. Por outro lado, o MapServer é preferível em termos de performance, escalabilidade e estabilidade (Ballatore, Tahir, McArdle, & Bertolotto, 2011).
Solução Proposta e Resultados 54 O facto de o GeoServer pertencer a um conjunto de aplicações completo, incluindo uma base de dados espaciais e um visualizador e editor de mapas, teve relevância no projeto escolhido, o GeoServer. 5.4.3 Avaliação das Aplicações de Edição e Visualização de Mapas Existem várias aplicações que se enquadram com o requisito "Editor e visualizador que permita edição colaborativa". Devido a vários fatores nem todas as aplicações preenchem os requisitos necessários para serem adotadas. As aplicações livres e de código aberto são uma vez mais prioritárias em relação às aplicações comerciais. A necessidade de customização e adicionar novas funcionalidades é o motivo decisivo de optar por aplicações livres e de código aberto. Na categoria de aplicações livres que permitem a edição e visualização de mapas existem dois tipos de aplicações: as aplicações web e as aplicações desktop. Os dois tipos de aplicações apresentam vantagens e desvantagens. As aplicações web não necessitam de ser instaladas, são executadas num navegador de internet e em princípio podem ser executas em qualquer sistema operativo, mesmo em dispositivos móveis. No entanto, as aplicações web podem funcionar de forma diferente entre vários navegadores requerendo testes em vários ambientes. As aplicações desktop são mais estáveis mas requerem atualizações quando existem modificações. A aplicação adotada tem de suportar a especificação OGC WFS-T para permitir a edição de dados. A especificação básica WFS permite apenas a consulta e recuperação de elementos. Um estudo sobre as aplicações livres desktop realizado por Steiniger e Bocher (Steiniger & Bocher, 2008) apresenta uma seleção e avaliação das melhores aplicações nesta categoria. Deste grupo de aplicações as que suportam a especificação WFS-T são o uDig e o OpenJUMP. Quanto ao grupo de aplicações livres web de edição e visualização de mapas, um interessante estudo comparativo realizado por Carrillo (Carrillo, 2013), apresenta a relação entre o MapServer, algumas bibliotecas e os clientes web de mapas. Estas aplicações interagem com os servidores através das especificações OGC, por isso estas aplicações podem interagir com qualquer servidor de mapas, incluindo o GeoServer. Também para estas aplicações, existe o requisito de suportarem a especificação WFS-T para permitir a edição, criação e eliminação de dados. Os clientes web apresentados neste documento que suportam tal especificação são: Flamingo, Geoide, GPAAMP, Mapbender, Mapbuilder. Outra aplicação que não está referida neste documento é o GeoExplorer. O GeoExplorer funciona em conjunto com o servidor de mapas GeoServer e ambas as aplicações fazem parte do conjunto de software OpenGeo Suite. Devido às vantagens das aplicações web, a aplicação adotada para o projeto deverá pertencer a este grupo de aplicações. As aplicações selecionadas para a realização de uma avaliação são: GeoExplorer, GPAAMP e Geoide.
Solução Proposta e Resultados 55 5.4.3.1 Critérios Funcionais Funcionalidade requerida - Todas as aplicações suportam os serviços OGC requeridos: WMS, WFS e WFS-T. Funcionalidades desejáveis - O GPAAMP e o GeoExplorer têm uma aparência muito semelhante. Em relação às funcionalidades, o GeoExplorer tem mais funcionalidades do que o GPAAMP. O Geoide tem um vasto conjunto de funcionalidades. Opções de Customização - Através do OpenGeo SDK é possível desenvolver aplicações de raiz semelhantes ao GeoExplorer, tanto a nível visual como funcional. 5.4.3.2 Critérios Técnicos Linguagem de programação - A aplicação GPAAMP é desenvolvida nas linguagens JavaScript, ExtJS e PHP. A linguagem de programação utilizada na aplicação Geoide é ActionScript. O GeoExplorer é desenvolvido usando várias tecnologias: JavaScript, ExtJS e OpenLayers. 5.4.3.3 Critérios Organizacionais Tamanho da Organização - Existe alguma dificuldade em determinar o número de colaboradores nos projetos em estudo. 5.4.3.4 Critérios de Suporte Tipo de Licença - Geoide GNU LGPL, GPAAMP Apache License v2.0, GeoExplorer GNU GPL 5.4.4 Seleção do Projeto de Edição e Visualização de Mapas O projeto escolhido para o projeto como editor e visualizador de mapas é o GeoExplorer. Esta escolha foi baseada em vários motivos: o GeoExplorer ao conjunto de aplicações OpenGeo que também contém o servidor de mapas GeoServer; é possível construir uma aplicação de raiz utilizando o OpenGeo SDK permitindo desenvolver uma aplicação igual ao GeoExplorer.
Solução Proposta e Resultados 62 “velocidadeMaxima” com valor 120 e o atributo “velocidadeMinima” com valor 10. Ao nível visual, o plugin desenvolvido tem um aspeto parecido com a aplicação OpenGeo SDK. A interface do conteúdo de uma tabela está apresentada na Figura 19. A aplicação permite a navegação nos registos quando existem muitos elementos na tabela. 5.5.3 Webcrawler Uma funcionalidade bastante útil e presente em vários simuladores de tráfego é a importação de informação de fornecedores de mapas tais como o OpenStreetMap. Esta funcionalidade torna-se vantajosa para o utilizador quando este está a trabalhar numa rede de tráfego já existente, poupando tempo na produção desta informação. Os fornecedores de mapas não só contêm informação sobre a topologia das redes de transporte mas também outro tipo de informação que pode ser utilizada nos simuladores de tráfego, como por exemplo a localização de estações de transportes públicos, semáforos, passadeiras e outros elementos. Um dos requisitos identificados neste projeto é permitir que o utilizador possa usufruir desta funcionalidade, ou seja, a importação para a base de dados de informação oriunda de fornecedores de mapas. 5.5.3.1 Desenvolvimento Na internet podem ser encontradas várias aplicações que têm como objetivo esta funcionalidade. A integração no projeto de uma aplicação que preencha esta funcionalidade requer várias condições: a aplicação tem de ser livre e de código aberto, desenvolvida em Java e deve cumprir os principais requisitos. O projeto que se aproxima mais das necessidades é o OSM2PostGIS. O objetivo do projeto OSM2PostGIS é desenvolver um processador de dados OpenStreetMap que pode importar qualquer quantidade de dados de ficheiros XML para uma base de dados PostGIS, e criar topologias de redes para navegação (OSM2PostGIS, 2013). O funcionamento correto da aplicação implicou vários desenvolvimentos e alterações. Por exemplo a aplicação não suportava elementos representados como pontos apenas suportava elementos representados como linhas. No OpenStreetMap, existem vários elementos que são representados como pontos, tais como passadeiras, semáforos, estações de transportes públicos e outros. Outra modificação que teve ser feita na aplicação está relacionada com o tipo de aplicação. Sendo esta uma aplicação Java, executada na linha de comando, modificou-se a aplicação para que funcionasse como um serviço REST. O desenvolvimento de serviço como serviço REST é devido ao GeoServer apenas suportar este tipo de serviços.
Solução Proposta e Resultados 63 A aplicação requer que seja disponibilizado um ficheiro OpenStreetMap que contém a informação do mapa. O processo de obter o ficheiro era moroso, pois era necessário que este fosse descarregado e disponibilizado no sistema de ficheiros local. Procederam-se a desenvolvimentos no serviço REST para que o ficheiro seja descarregado da página do OpenStreetMap automaticamente, através da passagem de argumentos com as coordenadas de latitude e longitude de dois pontos. 5.5.3.2 Funcionamento Na Figura 20, é descrito um resumo da estrutura de funcionamento da aplicação. A primeira função representada é responsável por interpretar os argumentos de entrada, que permite definir alguns parâmetros na execução da aplicação. A segunda função representada na imagem recebe um ficheiro de configuração JSON. Este ficheiro permite definir o comportamento da aplicação em relação à base de dados e também definir quais os dados importados do OpenStreetMap é que devem ser interpretados pela aplicação. Figura 20 - Fluxo de funcionamento do Webcrawler.
Solução Proposta e Resultados 64 Em relação à base de dados é possível definir o modelo relacional de dados incluindo tabelas e seus atributos. No caso de as tabelas não existirem na base de dados a aplicação cria-as automaticamente. Por exemplo a definição de uma tabela para semáforos podia ter a seguinte representação: "public.traffic_signal" : { type: point, name: "traffic_signal" } Nesta instrução, “traffic_signal” corresponde ao nome da tabela, o prefixo “public” define a tabela como sendo pública. O tipo de dados é definido na segunda parte através do parâmetro “type” que pode assumir um dos seguintes valores: “point”, “bound”, “route”. O último parâmetro da instrução define o nome que a tabela é reconhecida nesta aplicação. Na segunda parte deste ficheiro são definidas regras sobre as tags do OpenStreetMap que devem ser interpretadas pela aplicação e quais as tabelas que a informação deve ser inserida. O bloco em baixo exemplifica como podem ser definidas essas regras. [ { "highway" : "primary"}, "line", [ "human_built", "highway", "primary" ], [ "network" ] ] O primeiro conjunto de dados está relacionado com as tags do OpenStreetMap. A informação proveniente do OpenStreetMap é composta por uma tag principal e uma tag secundária. Neste caso, a tag principal é “highway” e tag secundária é “primary”, ou seja todas as estradas primárias são tratadas neste bloco de dados. De seguida, o valor “line” refere-se ao tipo de geometria que deve ser gerada, podendo assumir um dos seguintes valores: “line”, “ring” ou “area”. No terceiro argumento é definida a simbolização do mapa. Por último, são definidas as tabelas onde a informação é inserida. A terceira instrução representada na figura gere as ligações à base de dados recebendo como parâmetros o endereço da base de dados e as credenciais de autenticação. A quarta e última instrução cria um objeto que insere a informação na base de dados. Nesta classe, PostGISBuilder devem ser desenvolvidas heurísticas que tratam a informação proveniente do OpenStreetMap ou produzem informação que é necessária para o modelo com base em regras predefinidas. As heurísticas desenvolvidas no projeto apenas definem valores para os atributos. Por exemplo, a perceção no mapa do sentido das vias requer um atributo que indica qual o sentido através das simbologias “->” e “<-“. Esta informação é produzida segundo regras que operam em função da informação proveniente do OpenStreetMap.
Solução Proposta e Resultados 65 Existem outras heurísticas que devem ser desenvolvidas por forma a tornar o processo de construção de informação menos penoso para os utilizadores. 5.5.4 Gerador de Ficheiros para Simuladores de Tráfego O último requisito identificado é um serviço REST que tenha como funcionalidade a "Geração de Ficheiros para Simuladores de Tráfego". O formato dos ficheiros aceites varia de simulador para simulador. Em alguns simuladores, estes são ficheiros de texto regidos por uma determinada sintaxe. Noutros simuladores essa informação é gerida pela própria aplicação sendo armazenada em ficheiros binários ou encriptados de alguma forma. Neste projeto apenas são tomados em consideração os ficheiros de texto. Estes normalmente têm um formato baseado em XML. A aplicação deve ter alguma flexibilidade na construção e alteração destes ficheiros devido a duas razões. Primeiro, os projetos de software estão em constante evolução, originando mudanças na forma de funcionamento das aplicações. Essas mudanças podem abranger os ficheiros aceites pelos simuladores implicando a alteração ou a criação de ficheiros. O segundo motivo é a possibilidade de surgirem novos projetos de simulação de tráfego e a necessidade de construir ficheiros para estas aplicações. A solução encontrada para permitir esta flexibilidade e facilidade de criar e modificar ficheiros tem como base o motor de modelos Apache Velocity. O Velocity é desenvolvido em Java e pode ser facilmente integrado em aplicações. Este permite o uso de uma linguagem de modelos para referenciar objetos definidos em linguagem Java (Apache Velocity Site - The Apache Velocity Project, 2013). A principal característica destas aplicações é o modelo de desenvolvimento MVC (Modelo, Vista, Controlador) existindo uma divisão clara da aplicação em três componentes: o controlador, o modelo e a visão. O Velocity tem também uma linguagem de modelos que permite apresentação de informação dinâmica aos utilizadores. Estes modelos possibilitam a produção de ficheiros HTML mas também outro tipo de conteúdo, como por exemplo código, SQL ou XML (Gradecki & Cole, 2003). 5.5.4.1 Modelos Para exemplificar a criação dos modelos, assumimos que o ficheiro onde são representados os nós da aplicação SUMO tem a seguinte sintaxe, conforme o exemplo apresentado na documentação do simulador (Tutorials/Hello_Sumo - SUMO - Simulation of Urban Mobility, 2013):
Solução Proposta e Resultados 66 <nodes> <node id="1" x="-500.0" y="0.0" /> <node id="2" x="+500.0" y="0.0" /> <node id="3" x="+501.0" y="0.0" /> </nodes> Os modelos são descritos em ficheiros com extensão “vm”, utilizando a linguagem de modelos do Velocity. O modelo utilizado para criar um ficheiro de nós aceite pelo SUMO, contém o seguinte formato: <nodes> #foreach( $node in $nodes ) <node id="$node.id" x="$node.x_utm" y="$node.y_utm"> #end </nodes> Na segunda linha, a instrução “#foreach”, corresponde ao tradicional ciclo for que é concluído na quinta linha pela sintaxe “#end”. O bloco de instruções contido entre a instrução “#foreach e a instrução #end vai ser repetido para cada objeto contido na variável $nodes. Esta variável é manipulada no controlador e contém informação sobre todos os nós que devem ser incluídos no ficheiro final. 5.5.4.2 Controlador Existem vários pormenores na base de dados que devem ser evidenciados. A informação dos elementos que são representados geometricamente por linhas podem ter como tipo de geometria “linestring”. Caso o tipo de geometria utilizado seja este, cada elemento pode conter várias linhas. Os simuladores requerem que sejam definidas todas as linhas da rede e por isso foi necessário o desenvolvimento de um algoritmo que tenha esta funcionalidade. Outra característica que deve ser referida é o formato dos pontos, estes são descritos pelas coordenadas de latitude e longitude. Em alguns simuladores pode ser necessário trabalhar num referencial cartesiano, em vez das coordenadas de latitude e longitude. Por esse motivo, a aplicação disponibiliza as coordenadas nos dois formatos, para que essa decisão possa ser tomada na construção dos modelos. O controlador é a parte da aplicação responsável pela manipulação dos dados. Esta componente deve produzir todos os dados possíveis e em todos formatos necessários para que haja alguma flexibilidade na construção de modelos. A Figura 21 descreve a estrutura de funcionamento do controlador.
Solução Proposta e Resultados 67 Primeiro, a aplicação faz a ligação à base de dados, obtendo de seguida a informação das redes e dos pontos destas, assim como todos os pontos envolvidos. A informação da localização de cada ponto tem o formato latitude/longitude. Por este não ser um formato de leitura fácil e porque este formato pode não ser aceite pelos simuladores, as coordenadas são convertidas no sistema UTM, obtendo assim coordenadas do tipo x,y. Os valores obtidos da conversão para o sistema UTM são valores muito elevados devido à localização dos eixos de referência. Por forma a trabalhar com valores mais pequenos é necessário aplicar uma translação ao conjunto de dados. O processo é simples e consiste em determinar no conjunto de pontos qual a coordenada x com valor mais baixo e subtrair esse valor a todas as coordenadas x de todos os pontos. Este processo repete-se para os valores da coordenada y. Como foi referido anteriormente, foi necessário o desenvolvimento de um algoritmo que descrevesse todas as linhas existentes num elemento do tipo “linestring”. Além disso, também é necessário recriar todas as redes com a informação das coordenadas dos pontos obtida anteriormente. Figura 21 - Estrutura de funcionamento do controlador do gerador de ficheiros.
Solução Proposta e Resultados 68 Por último, é necessário obter toda a informação das outras tabelas que não têm dados georreferenciados para que possam ser utilizados no modelo. 5.5.4.3 Vista O resultado da informação gerada pelo controlador e definida no modelo é apresentada na vista. Para exemplificar o resultado da aplicação, assumimos que o utilizador está a utilizar um navegador web para comunicar com a aplicação. Como a aplicação é um serviço REST, estes dados podem ser acessíveis de outra forma, porém a comunicação com a aplicação é sempre realizada através do protocolo HTTP. Para que a aplicação permita a produção de informação para vários simuladores e que para cada simulador produza vários ficheiros, existe a necessidade da definição de parâmetros quando se realiza um pedido ao serviço REST. Um pedido ao serviço REST tem o seguinte formato: http://<servidor>:<porta>/geoserver/rest/generator/<simulador>/<template> O parâmetro <servidor> é a localização do GeoServer, ou seja é o endereço onde o serviço está alojado. O parâmetro <porta> é a porta em que a aplicação está a ser executada. Os parâmetros referidos anteriormente são definidos em “<simulador>” e “<template>”. Por exemplo, se o utilizador pretende um ficheiro que define os nós da rede para o simulador SUMO, a parâmetro “<simulador>” deve assumir o valor “sumo” e o parâmetro “<template>” o valor “nodes”. Os parâmetros, “<simulador>” e “<template>” dão indicação ao controlador da localização do modelo que deve carregar. Neste caso o modelo a assumir encontra-se na diretoria sumo e o ficheiro do modelo é o nodes.vm. 5.6 Resultados A apresentação dos resultados é realizada utilizando um pequeno caso prático, em que o objetivo é gerar ficheiros que sejam aceites pelo simulador SUMO. A região utilizada para este caso é a zona envolvente à Faculdade de Engenharia da Universidade do Porto (FEUP). O primeiro passo é obter as coordenadas da região que se pretende importar. De seguida, através de um navegador web, é executado o serviço que faz a importação dessa informação para a base de dados (serviço webcrawler) através do seguinte endereço: http://localhost:8080/geoserver/rest/webcrawler/41.179817/-8.600997/- 8.597006/41.177213 Posteriormente, é necessário importar a informação para o GeoServer através da interface web desta aplicação. Existe a possibilidade do desenvolvimento de código que realize esta ação.
Estando esta informação georreferenciada através de qualquer aplicação que suporte o protocolo WFS Para visualizar e editar a informação é utilizada a aplicação dese Nesta aplicação é realizada uma importação da camada pretendida, ficando esta apresentada no mapa da aplicação, d estacada na cor laranja como é demonstrado n Uma simulação básica no simulador de veículos, veículos e rotas. Neste caso prático foram criados dois tipos de veículos: carros e autocarros. As características definidas várias variáveis referentes à aceleração, tamanho e velocidade. Em relação às rotas, apenas é necessário especificar os identificadores dos segmentos de cada rota. Os identificadores devem estar separados por um espaço em branco apresentado na Figura 24. Por último, são definidos vários veículos e para cada um é especificado o instante em que iniciam a simulação, a rota e o tipo de veículo Figura 22 – Resultado da i Solução Proposta e Resultados 69 Estando esta informação disponível no GeoServer, é possível aceder a esta informação georreferenciada através de qualquer aplicação que suporte o protocolo WFS - T. Para visualizar e editar a informação é utilizada a aplicação desenvolvida OpenGeo SDK. Nesta aplicação é realizada uma importação da camada pretendida, ficando esta apresentada no estacada na cor laranja como é demonstrado n a Figura 22 . Uma simulação básica no simulador SUMO requer a definição de várias entidades: tipos de veículos, veículos e rotas. Neste caso prático foram criados dois tipos de veículos: carros e características do tipo de veículo “Carro” são apresentadas na definidas várias variáveis referentes à aceleração, tamanho e velocidade. Em relação às rotas, apenas é necessário especificar os identificadores dos segmentos de cada rota. Os identificadores devem estar separados por um espaço em branco Por último, são definidos vários veículos e para cada um é especificado o instante em que iniciam a simulação, a rota e o tipo de veículo (Figura 25). Resultado da importação de dados utilizando o serviço webcrawler. no GeoServer, é possível aceder a esta informação T. nvolvida OpenGeo SDK. Nesta aplicação é realizada uma importação da camada pretendida, ficando esta apresentada no . SUMO requer a definição de várias entidades: tipos de veículos, veículos e rotas. Neste caso prático foram criados dois tipos de veículos: carros e são apresentadas na Figura 23, sendo Em relação às rotas, apenas é necessário especificar os identificadores dos segmentos de cada rota. Os identificadores devem estar separados por um espaço em branco , como é Por último, são definidos vários veículos e para cada um é especificado o instante em que mportação de dados utilizando o serviço webcrawler.
Figura 23 – Definição do tipo de veículo “Carro”. Figura 24 – Definição das rotas. Solução Proposta e Resultados 70 Definição do tipo de veículo “Carro”. Definição das rotas.
Com os elementos pretendidos ficheiros aceites pelo simulador SUMO. O primeiro ficheiro define os nós e a posição destes. O segundo define as ligações entre os nós, representando a rede viária. O terceiro define as rotas que os veículos tomam durante a simulação, assim como os tipos de veículos e os veículos. Para gerar o ficheiro de nós utiliza http://localhost:8080/geoserver/rest/generator/sumo/nodes Para gerar o ficheiro das ligações utiliza http://localhost:8080/geoserver/rest/generator/sumo/networks Para gerar o ficheiro das rotas utiliza http://localhost:8080/geoserver/rest/generator/sumo/routes A informação gerada por este ser relativa aos nós foi inserida no ficheiro “MyNodes.nod.xml” (anexo 1). A informação das ligações foi inserida no ficheiro “MyEdges.edg.xml” (anexo 2). E por último, a informação das rotas ficou armazen ada no ficheiro “routes.rou.xml” (anexo 3). Para construir a rede aceite no SUMO é necessário juntar estes dois ficheiros na pasta bin da aplicação SUMO e executar a aplicação “netconvert” através da linha de comando. Figura 25 – Definição dos veículos. Solução Proposta e Resultados 71 pretendidos definidos, resta aceder ao serviço REST que produz os ficheiros aceites pelo simulador SUMO. O primeiro ficheiro define os nós e a posição destes. O segundo define as ligações entre os nós, representando a rede viária. O terceiro define as rotas que os veículos tomam durante a simulação, assim como os tipos de veículos e Para gerar o ficheiro de nós utiliza -se o seguinte endereço: http://localhost:8080/geoserver/rest/generator/sumo/nodes o ficheiro das ligações utiliza -se o endereço: http://localhost:8080/geoserver/rest/generator/sumo/networks Para gerar o ficheiro das rotas utiliza -se o endereço: http://localhost:8080/geoserver/rest/generator/sumo/routes A informação gerada por este serviço deve ser inserida em três ficheiros. A informação relativa aos nós foi inserida no ficheiro “MyNodes.nod.xml” (anexo 1). A informação das ligações foi inserida no ficheiro “MyEdges.edg.xml” (anexo 2). E por último, a informação das ada no ficheiro “routes.rou.xml” (anexo 3). Para construir a rede aceite no SUMO é necessário juntar estes dois ficheiros na pasta bin da aplicação SUMO e executar a aplicação “netconvert” através da linha de comando. Definição dos veículos. definidos, resta aceder ao serviço REST que produz os ficheiros aceites pelo simulador SUMO. O primeiro ficheiro define os nós e a posição destes. O segundo define as ligações entre os nós, representando a rede viária. O terceiro e último ficheiro define as rotas que os veículos tomam durante a simulação, assim como os tipos de veículos e viço deve ser inserida em três ficheiros. A informação relativa aos nós foi inserida no ficheiro “MyNodes.nod.xml” (anexo 1). A informação das ligações foi inserida no ficheiro “MyEdges.edg.xml” (anexo 2). E por último, a informação das Para construir a rede aceite no SUMO é necessário juntar estes dois ficheiros na pasta bin da aplicação SUMO e executar a aplicação “netconvert” através da linha de comando.
Anexo A 78 <node id="37" x="1057.46" y="143.42"/> </nodes> 7.2 Ficheiro de redes gerado pelo serviço <edges> <edge id="1_0" from="0" to="1"/> <edge id="1_1" from="1" to="2"/> <edge id="1_2" from="2" to="3"/> <edge id="1_3" from="3" to="4"/> <edge id="1_4" from="4" to="5"/> <edge id="1_5" from="5" to="6"/> <edge id="1_6" from="6" to="7"/> <edge id="2_7" from="7" to="8"/> <edge id="3_8" from="8" to="9"/> <edge id="4_9" from="9" to="10"/> <edge id="4_10" from="10" to="11"/> <edge id="4_11" from="11" to="12"/> <edge id="5_12" from="9" to="13"/> <edge id="6_13" from="13" to="14"/> <edge id="6_14" from="14" to="15"/> <edge id="6_15" from="15" to="16"/> <edge id="6_16" from="16" to="17"/> <edge id="6_17" from="17" to="18"/> <edge id="7_18" from="8" to="19"/> <edge id="8_19" from="19" to="20"/> <edge id="9_20" from="20" to="21"/> <edge id="9_21" from="21" to="22"/> <edge id="9_22" from="22" to="23"/> <edge id="9_23" from="23" to="24"/> <edge id="9_24" from="24" to="25"/> <edge id="9_25" from="25" to="26"/> <edge id="10_26" from="7" to="27"/> <edge id="10_27" from="27" to="28"/> <edge id="10_28" from="28" to="29"/> <edge id="10_29" from="29" to="30"/> <edge id="10_30" from="30" to="31"/> <edge id="10_31" from="31" to="32"/> <edge id="10_32" from="32" to="33"/> <edge id="10_33" from="33" to="34"/> <edge id="10_34" from="34" to="35"/> <edge id="10_35" from="35" to="36"/> <edge id="10_36" from="36" to="37"/> <edge id="10_37" from="37" to="38"/> <edge id="11_38" from="19" to="39"/> </edges>
Anexo A 79 7.3 Ficheiro de rotas gerado pelo serviço <routes> <vType id="Carro" accel="1.0" decel="5.0" length="2.0" sigma="0.0"/> <vType id="Autocarro" accel="0.5" decel="3.0" length="5.0" sigma="0.0"/> <route id="route1" edges="1_0 1_1 1_2 1_3 1_4 1_5 1_6 2_7 3_8 4_9 4_10 4_11 "/> <route id="route2" edges="1_0 1_1 1_2 1_3 1_4 1_5 1_6 2_7 3_8 5_12 6_13 6_14 6_15 6_16 6_17 "/> <route id="route3" edges="1_0 1_1 1_2 1_3 1_4 1_5 1_6 2_7 7_18 8_19 9_20 9_21 9_22 9_23 9_24 9_25 "/> <vehicle id="vehicle1" depart="1" route="route1" type="Carro"/> <vehicle id="vehicle2" depart="5" route="route1" type="Carro"/> <vehicle id="autocarro1" depart="6" route="route1" type="Autocarro"/> <vehicle id="autocarro2" depart="7" route="route1" type="Autocarro"/> <vehicle id="vehicle3" depart="9" route="route2" type="Carro"/> <vehicle id="vehicle4" depart="11" route="route3" type="Carro"/> <vehicle id="vehicle5" depart="13" route="route3" type="Carro"/> <vehicle id="autocarro3" depart="14" route="route3" type="Autocarro"/> <vehicle id="vehicle6" depart="15" route="route3" type="Carro"/> <vehicle id="vehicle7" depart="18" route="route2" type="Carro"/> <vehicle id="vehicle8" depart="20" route="route2" type="Carro"/> <vehicle id="vehicle9" depart="22" route="route1" type="Carro"/> <vehicle id="vehicle100" depart="50" route="route2" type="Carro"/> <vehicle id="vehicle200" depart="80" route="route1" type="Carro"/> </routes> 7.4 Ficheiro de configuração <?xml version="1.0" encoding="iso-8859-1"?> <configuration xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocation="http://sumo.sf.net/xsd/sumoConfiguratio n.xsd"> <input> <net-file value=" name.net.xml"/> <route-files value="routes.rou.xml"/> </input> <time> <begin value="0"/> <end value="100"/> </time> <time-to-teleport value="-1"/> </configuration>
80 Referências Apache Velocity Site - The Apache Velocity Project. (15 de Junho de 2013). Obtido de Apache Velocity Site - The Apache Velocity Project: http://velocity.apache.org/ Saturn Manual Chapters. (Março de 2013). Obtido de Atkins SATURN: http://www.saturnsoftware.co.uk/downloads/pdfs/Section%201.pdf TomTom, portable GPS car navigation systems. (16 de Junho de 2013). Obtido de TomTom: http://www.tomtom.com/whytomtom/subject.php?subject=10 Tutorials/Hello_Sumo - SUMO - Simulation of Urban Mobility. (15 de Junho de 2013). Obtido de SUMO - Simulation of Urban MObility: http://sumo.sourceforge.net/doc/current/docs/userdoc/Tutorials/Hello_Sumo.html Ballatore, A., Tahir, A., McArdle, G., & Bertolotto, M. (2011). A comparison of open source geospatial technologies for web mapping. International Journal of Web Engineering and Technology, 354-374. Balmer, M., Rieser, M., Meister, K., Charypar, D., Nicolas, L., & Nagel, K. (2009). MATSimT: Architecture and Simulation Times. In A. Bazzan, & F. Klügl, Multi-Agent Systems for Traffic and Transportation Engineering (pp. 57-78). IGI Global. Banks, J. (1998). Principles of Simulation. In J. Banks, Handbook of Simulation - Principles, Methodology, Advances, Applications, and Practice (pp. 3-30). John Wiley & Sons, Inc. Barceló, J. (2010). Models, Traffic Models, Simulation, and Traffic Simulation. In J. Barceló, Fundamentals of Traffic Simulation (pp. 1-62). Springer. Barceló, J., Ferrer, J., García, D., & Grau, R. (s.d.). Microscopic Traffic Simulation for Att Systems Analysis a Parallel Computing Version. Barry, D. K. (2013). Web Services, Service-Oriented Architetures, and Cloud Computing. Elsevier Inc. Bennett, J. (2010). OpenStreetMap - Be your own Cartographer. Packt Publishing. Bertini, R. L., Lindgren, R., & Tantiyanugulchai, S. (2002). Application of PARAMICS Simulation at a Diamond Interchange. Oregon: Oregon Department of Transportation. Burghout, W. (2004). Hybrid microscopic-mesoscopic traffic simulation. Stockholm, Sweden.
Referências 81 Carrillo, G. (15 de Junho de 2013). Web mapping client comparison v.6. Obtido de GeoTux: http://geotux.tuxfamily.org/index.php/en/geo-blogs/item/291-comparacion-clientesweb-v6 Casas, J., Ferrer, J. L., Garcia, D., Perarnau, J., & Torday, A. (2010). Traffic Simulation with Aimsun. In J. Barceló, Fundamentals of Traffic Simulation (pp. 173-233). Springer. Deegree. (16 de Junho de 2013). Deegree. Obtido de Deegree: http://www.deegree.org/ Erl, T. (2008). Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts. SOA Magazine Issue XV. Erl, T. (16 de Junho de 2013). Anotação do Manifesto SOA. Obtido de Manifesto SOA: http://www.soa-manifesto.com/annotated_portuguese.htm Erl, T. (2013). SOA with REST. Prentice Hall. Erle, S., Gibson, R., & Walsh, J. (2005). Mapping Hacks - Tips & Tools for Electronic Cartography. O'Reilly. ESRI. (16 de Junho de 2013). GIS Dictionary - ESRI Support. Obtido de ESRI: http://support.esri.com/en/knowledgebase/GISDictionary/search Francischett, M. N. (2004). A cartografia no ensino-aprendizagem da geografia. GeoExplorer. (16 de Junho de 2013). Examples. Obtido de Example: http://dev.openlayers.org/sandbox/opengeo/geoexplorer/examples/ Geoide. (16 de Junho de 2013). Geoide. Obtido de Geoide - user friendly GIS software: http://www.geoide.nl/en/ Gonzalez, H., Halevy, A. Y., Jensen, C. S., Langen, A., Madhavan, J., Shapley, R., et al. (2010). Google Fusion Tables: Web-Centered Data Management and Collaboration. SIGMOD. Indianapolis, Indiana, USA: ACM. Google Code University. (16 de Junho de 2013). Google Code University. Obtido de Google Code University - Introduction to Distributed System Design: http://www.hpcs.cs.tsukuba.ac.jp/~tatebe/lecture/h23/dsys/dsd-tutorial.html GPAAMP. (16 de Junho de 2013). GBIF Geospatial Services. Obtido de GBIF Geospatial Services: https://code.google.com/p/gbif-geospatial/w/list Gradecki, J. D., & Cole, J. (2003). Mastering Apache Velocity. Indianapolis: Wiley Publishing, Inc. Guizani, M., Rayes, A., Khan, B., & Al-Fuqaha, A. (2010). Network Modeling and Simulation - A Practical Perspective. John Wiley & Sons Ltd. Harmon, J. E., & Anderson, S. J. (2003). The Design and Implementation of Geographic Information Systems. New Jersey: John Wiley & Sons, Inc. Helbing, D. (1998). From Microscopic to Macroscopic Traffic Models. A Perspective Look at Nonlinear Media. From Physics to Biology and Social Sciences, 122-139. Herzum, P. (2002). Web Services and Service-Oriented Architectures. Cutter Distributed Enterprise Architecture Advisory Service.
Referências 82 Kennedy, M. (2000). Understanding Map Projections. Environmental Systems Research Institute, Inc. Kokkinogenis, Z., Sanchez Passos, L., Rossetti, R., & Gabriel, J. (2011). Towards the nextgeneration traffic simulation tools: a first evaluation. 6th Iberian Conference on Information Systems and Technologies, (pp. 15-18). Chaves. Krajzewicz, D. (2010). Traffic Simulation with SUMO - Simulation of Urban Mobility. In J. Barceló, Fundamentals of Traffic Simulation. Springer. Krajzewicz, D., Hertkorn, G., Wagner, P., & Rössel, C. (2002). An Example of Microscopic Car Models Validation using the open source Traffic Simulation SUMO. 14th European Simulation Symposium, (pp. 23-26). Dresden, Deutschland. Kropla, B. (2005). MapServer: Open Source GIS Development. Apress. Lienert, C., Jenny, B., Schnabel, O., & Hurni, L. (2012). Current Trends in Vector-Based Internet Mapping: A Technical Review. In M. P. Peterson, Lecture Notes in Geoinformation and Cartography (pp. 23-36). Berlin: Springer. Liu, R. (2010). Traffic Simulation with DRACULA. In J. Barceló, Fundamentals of Traffic Simulation (pp. 295-322). Springer. MapQuest. (16 de Junho de 2013). Map Editor, Maker & OSM - MapQuest Open. Obtido de Map Editor, Maker & OSM - MapQuest Open: http://open.mapquest.com/ MySQL. (13 de Junho de 2013). Introduction to MySQL Spatial Support. Obtido de MySQL 5.0 Reference Manual: http://dev.mysql.com/doc/refman/5.0/en/gis-introduction.html NAVTEQ. (16 de Junho de 2003). NAVTEQ Maps. Obtido de NAVTEQ Maps: http://www.navteq.com/ OpenGeo. (16 de Junho de 2013). Creating and deploying apps with the Client SDK. Obtido de OpenGeo: http://suite.opengeo.org/opengeo-docs/apps/clientsdk.html OpenGeo. (12 de Junho de 2013). OpenGeo : Introduction to GeoServer : 3.1. Server Basics. Obtido de OpenGeo: http://workshops.opengeo.org/geoserverintro/overview/server.html OpenGeo. (12 de Junho de 2013). OpenGeo : Introduction to GeoServer : 3.3. Web Feature Service (WFS). Obtido de OpenGeo: http://workshops.opengeo.org/geoserverintro/overview/wfs.html OpenGeo. (12 de Junho de 2013). OpenGeo : Introduction to the OpenGeo Suite. Obtido de OpenGeo: http://workshops.opengeo.org/suiteintro/ OpenGeo. (12 de Junho de 2013). OpenGeo: Introduction to GeoServer: 3.2. Web Map Service (WMS). Obtido de OpenGeo: http://workshops.opengeo.org/geoserverintro/overview/wms.html OpenJUMP. (16 de Junho de 2013). OpenJUMP GIS. Obtido de OpenJUMP GIS: http://www.openjump.org/ OpenStreetMap. (16 de Junho de 2013). OpenStreetMap. Obtido de OpenStreetMap: http://www.openstreetmap.org/
Referências 83 OSM2PostGIS. (16 de Junho de 2013). OSM2PostGIS. Obtido de OSM2PostGIS Project Web: http://osm2postgis.sourceforge.net/ Peterson, M. P. (2012). Online Mapping with APIs. In M. P. Peterson, Online Maps with APIs and WebServices (pp. 3-10). Springer. Potti, P. K., Ahuja, S., Umapathy, K., & Prodanoff, Z. (2012). Comparing Performance of Web Service Interaction Styles: SOAP vs. REST. Proceedings of the Conference on Information Systems Applied Research. New Orleans. Resin. (15 de Junho de 2013). Caucho Resin: Reliable, Open-Source Application Server. Obtido de Caucho Resin: Reliable, Open-Source Application Server: http://quercus.caucho.com/ Rossetti, R. J., & Liu, R. (2005). A Dynamic Network Simulation Model Based on Multi-Agent Systems. Applications of Agent Technology in Traffic and Transportation, pp. 181-192. Rumsey, D. (16 de Junho de 2013). David Rumsey Historical Map Collection. Obtido de David Rumsey Historical Map Collection: rumsey.geogarage.com Schmidt, M., & Weiser, P. (2012). Web Mapping Services: Development and Trends. In M. P. Peterson, Online Maps with APIs and WebServices (pp. 13-22). Springer. Solutions, V. (16 de Junho de 2013). Business Solutions Experts - Vivid Solutions Inc. Obtido de Business Solutions Experts - Vivid Solutions Inc.: http://www.vividsolutions.com/ Steiniger, S., & Bocher, E. (2008). An Overview on Current Free and Open Source Desktop GIS Developments. International Journal of Geographical Information Science. Steiniger, S., & Hunter, A. J. (Outubro de 2012). The 2012 Free and Open Source GIS Software Map – A Guide to facilitate Research, Development and Adoption. Computers, Environment and Urban Systems. Sveen, A. F. (2008). Use of free and open source GIS in commercial firms. Trondheim: Norwegian University of Science and Technology. Sveen, A. F. (2008). Use of Free and Open Source GIS in Commercial Firms. Trondheim: Norwegian University of Science and Technology. Tanenbaum, A. S., & Van Steen, M. (2007). Distributed Systems Principles and Paradigms (Second Edition). Pearson Prentice Hall. Tools, G. (16 de Junho de 2013). GBIF Tools. Obtido de GBIF Tools: http://tools.gbif.org/ uDig. (16 de Junho de 2013). uDig User-friendly Desktop Internet GIS. Obtido de uDig Userfriendly Desktop Internet GIS: http://udig.refractions.net/
Referências 84