veja o trabalho - Coordenação de Projetos
Propaganda
UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE SISTEMAS DE INFORMAÇÃO Um Sistema para Acessar Dados Geográficos do Município de Blumenau via Web Vinícius Barreto Klein FLORIANÓPOLIS 2009 Vinícius Barreto Klein Um Sistema para Acessar Dados Geográficos do Município de Blumenau via Web Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação. Orientador: _________________________________________ Prof. Renato Fileto, Dr. Universidade Federal de Santa Catarina [email protected] Co-Orientador: _________________________________________ Rodrigo Luiz Oliveira. Analista de Sistemas - VisaoGeo [email protected] Banca Examinadora: _________________________________________ Prof. Angelo Augusto Frozza, Dr. Universidade do Planalto Catarinense [email protected] _________________________________________ Professor Frank Siqueira, Dr. Universidade Federal de Santa Catarina [email protected] Conteúdo Um Sistema para Acessar Dados Geográficos do Município de Blumenau via Web .................................................................................................................... 1 Conteúdo ............................................................................................................ 4 Índice de Figuras ................................................................................................ 6 Lista de Acrônimos ............................................................................................. 7 Resumo .............................................................................................................. 8 Palavras-Chave .................................................................................................. 8 1. Introdução ...................................................................................................... 9 1.1 Motivação .................................................................................................. 9 1.2 Objetivos ................................................................................................. 10 Objetivos Específicos .................................................................................... 10 1.3 Justificativa ............................................................................................. 11 1.4 Metodologia ............................................................................................ 11 1.5 Dificuldades ............................................................................................ 11 2. Fundamentos ............................................................................................... 12 2.1 SIG – Sistemas de Informação Geográfica ............................................. 12 Geoprocessamento ....................................................................................... 13 O framework Geoframe ................................................................................. 17 Gerência de Dados Geográficos ................................................................... 18 Arquitetura Dual ............................................................................................ 18 Arquitetura Integrada .................................................................................... 19 2.2 Cartografia .............................................................................................. 19 Mapas ........................................................................................................... 20 3.1 SGBD – PostgreSQL .............................................................................. 21 3.1.2 Gerenciamento de dados Geográficos – PostGis ................................ 22 Operadores Espaciais do PostGis ................................................................ 23 3.3 Servidor de Mapas – MapServer............................................................. 25 3.4 O I3Geo .................................................................................................. 25 4. O SIGDefesa ................................................................................................ 28 4.1 Arquitetura do SIGDefesa ....................................................................... 28 4.2 O Desenvolvimento do SIGDefesa ......................................................... 29 Início do desenvolvimento ................................ Error! Bookmark not defined. Dados disponíveis ............................................ Error! Bookmark not defined. ETC Espacial ................................................... Error! Bookmark not defined. 4.2 A Interface do Sistema ............................................................................ 33 4.2 Manipulação dos Dados Geográficos via Web ....................................... 35 5. Testes e Resultados ..................................................................................... 36 5.1 Consultas Espaciais ................................................................................ 36 5.2 O Módulo “Postos de Abrigo” .................................................................. 46 Modelagem do Módulo Postos de Abrigo ..................................................... 47 6. CONCLUSÕES E TRABALHOS FUTUROS ................................................ 49 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................. 50 Índice de Figuras Figura 1 - Arquitetura de um SIG .................................................................... 13 Figura 2 – Paradigma dos 4 universos. Fonte: PAIVA et al. (2006). ............... 14 Figura 3 - Ponto, Linha e Polígono. Fonte: PAIVA et al. (2006). ...................... 15 Figura 4 – Interface do ArgoCaseGeo .............................................................. 18 Figura 5 - Tipos de dados do PostGis .............................................................. 22 Figura 6 - A coluna "the_geom"........................................................................ 24 Figura 7 – Interface do I3GEO (http://mapas.mma.gov.br/i3geo) ..................... 26 Figura 8 - Arquitetura do SIGDefesa. ............................................................... 28 Figura 9 - Consultas a serem respondidas e os operadores do Postgis a serem usados .............................................................................................................. 30 Figura 10 - Esquema dos dados geográficos ................................................... 32 Figura 11 - Casos de Uso do SIGDefesa ......................................................... 32 Figura 12 – Interface do SIGDefesa com os principais rios de Blumenau ....... 34 Figura 13 - Pontos de segurança mais próximos à bacia do Rio Itajaí ............. 37 Figura 14 - Camadas ativadas ......................................................................... 38 Figura 15 - Bairros em zona perigosa .............................................................. 41 Figura 16 - Área de atuação de um posto da Polícia Militar ............................. 42 Figura 17 - Rios contidos em uma área ........................................................... 43 Figura 19 - Casos de Uso ................................................................................ 47 Figura 20 - Modelo E-R normalizado ................................................................ 48 Lista de Acrônimos ShapeFile – Formato de dados geográficos da ESRI. ESRI – Environmental Systems Research Institute OGC - Open Geospatial Consortium SGBD – Sistema Gerenciador de Banco de Dados GIS – Geographic Information Systems WKT – Well Know Text OGC – Open Geospatial Consortium Resumo O problema de enchentes assola vários municípios de Santa Catarina de tempos em tempos. Recentemente houve uma enchente que deixou a cidade de Blumenau, entre outras do vale do Itajaí, em estado de calamidade pública, ocasionando inclusive várias mortes, grandes danos materiais e deixando milhares de famílias desabrigadas. A Defesa Civil dispunha de pouca informação para auxiliar a organização da resposta a este desastre. Informações georreferenciadas sobre o relevo, solos, hidrografia, distribuição da população e toda a infra-estrutura presente ou danificada são fundamentais tanto para o atendimento emergencial quanto para o planejamento da ocupação do solo, de modo a minimizar os efeitos de fenômenos naturais semelhantes no futuro. Todavia, o custo para o levantamento e a dificuldade de conseguir acesso e efetuar reuso de dados geográficos entravam a construção de sistemas de informação geográfica. O objetivo deste trabalho é reunir dados geográficos existentes em diversas fontes distintas (diferentes órgãos públicos) e disponibilizá-los via Web, dando apoio a Defesa Civil nas tomadas de decisões referentes a prevenção e resposta a desastres naturais, particularmente enchentes e deslizamentos. Palavras-Chave Sistema de Informação Geográfica, Integração de Dados Geográficos, Bancos de Dados Geográficos na Web, Defesa Civil 1. Introdução 1.1 Motivação O município de Blumenau possui um triste histórico de fortes enchentes devido à sua posição geográfica, situada nas margens do rio Itajaí. Em 1983, uma enchente que durou 31 dias atingiu 30% das casas deixando 50.000 pessoas desalojadas. Mais recentemente, em 23 de novembro de 2008, o prefeito de Blumenau declarou estado de calamidade pública. Segundo dados da Defesa Civil, 52.319 pessoas ficaram desabrigadas (Fonte: site da Prefeitura de Blumenau, acessado em Julho de 2009). O órgão responsável para atuar neste tipo de situação é a Defesa Civil. Segundo o Decreto Nº 5.376 de 17 de fevereiro de 2005, as ações da Defesa Civil¹ são: ◦ a prevenção de desastres; ◦ a preparação para emergências e desastres ◦ a resposta aos desastres ◦ a reconstrução e a recuperação após os desastres Sendo um desastre definido como “o resultado de eventos adversos, naturais ou provocados pelo homem sobre um ecossistema vulnerável, causando danos humanos, materiais ou ambientais e conseqüentes prejuízos econômicos e sociais”² ¹ Fonte: Presidência da República, Casa Civil. ² Fonte: Decreto nº 5.376 de 17 de fevereiro de 2005 da Presidência da República, Casa Civil. A Defesa Civil dispunha de pouca informação no momento da enchente de novembro de 2008. Conforme relatos de pessoas envolvidas nos resgates, os pilotos de helicóptero sobrevoavam com mapas na mão, contendo poucas informações (e pouco precisas) sobre as áreas atingidas. 1.2 Objetivos Este trabalho visa desenvolver um sistema para acesso a dados geográficos do município de Blumenau via Web. Este sistema utilizará uma única base com dados oriundos de diversas fontes (atualmente os dados estão espalhados em diversos órgãos) e permitirá o acesso via interface gráfica na Web e usando padrões para suportar a interoperabilidade de dados geográficos sempre que possível. O resultado esperado é gerar informações estratégicas que auxiliem a Defesa Civil de Blumenau na prevenção, resposta e reparação de desastres. Objetivos Específicos Os objetivos específicos deste TCC são: 1. Integrar em um único repositório dados geográficos relevantes para o escopo do trabalho da Defesa Civil, incluindo dados de hidrologia, altimetria, rede de distribuição de energia elétrica, malha viária, arruamentos e edificações públicas. 2. Construir uma interface Web para disponibilizar as informações extraídas destes dados e oferecer a solução de consultas úteis para apoiar os trabalhos da defesa civil e do governo, tanto em planejamento visando evitar desastres quanto na organização da logística necessária ao atendimento emergencial. 1.3 Justificativa Os diversos dados do ambiente físico reunidos em um único repositório podem ser combinados para gerar informações estratégicas valiosas para a Defesa Civil. Os objetos do ambiente físico têm formas de representação espacial (dados geográficos). Mapas digitais podem facilitar a visualização e o entendimento das informações extraídas de um banco de dados geográficos. 1.4 Metodologia A metodologia de desenvolvimento deste trabalho consiste na seguintes fases realizadas seqüencialmente: (i) análise das necessidades de acesso e processamento de informação geográfica para a Defesa Civil; (ii) definição dos casos de uso e das consultas a serem suportadas; (iii) busca e seleção de fontes de dados; (iv) integração dos dados geográficos e (v) projeto, implementação, testes e validação da interface Web. As consultas devem retornar informações úteis com um tempo de resposta satisfatório. Para visualização dos dados geográficos com interface Web foi utilizado o I3Geo. 1.5 Dificuldades Como os dados são de diversas fontes distintas (diferentes órgãos públicos e privados), importá-los e integrá-los num único repositório é um desafio. Estes dados têm diferentes formatos e projeções cartográficas. Além disso, não há dicionário de dados, o que dificulta a interpretação dos mesmos. Foi necessário também obter a liberação de uso dos dados, pois alguns deles possuem restrições de uso. 2. Fundamentos 2.1 SIG – Sistemas de Informação Geográfica Segundo Câmara (CÂMARA, 2001), o termo Sistemas de Informação Geográfica (SIG) é aplicado a sistemas que realizam o tratamento computacional de dados geográficos. “Um Sistema de Informação Geográfica é um sistema de hardware, software, informação espacial e procedimentos computacionais, que permite e facilita a análise, gestão ou representação do espaço e dos fenômenos que nele ocorrem. [...] O termo Sistema de Informações Geográficas – SIG – é aplicado para sistemas que realizam o tratamento computacional de dados geográficos e armazenam a geometria e os atributos dos dados que estão georeferenciados, isto é, localizados na superfície terrestre e representados numa projeção cartográfica”. (CÂMARA, 2001, p. 1). SIGs usam como base dados alfanuméricos combinados a dados georeferenciados, originários de processos cartográficos. Os dados geográficos trazem informações sobre entidades geográficas como casas, rios, regiões etc. Cabe ao SIG tratar estes dados para que se possa combiná-los a outros dados ou camadas de informações e gerar novas informações. A Figura 1 ilustra a arquitetura de um SIG. Os dados alfanuméricos e os dados geográficos são armazenados no banco de dados geográficos. O módulo de gerência de dados espaciais é responsável pelo acesso e manipulação dos dados geográficos no nível mais baixo de abstração, ocupando-se dos detalhes da representação desses dados. Os módulos do nível intermediário provêem recursos para entrada e integração de dados, consulta e análise espacial, além de visualização e plotagem dos dados em mapas. A interface com o usuário permite acessar a funcionalidades do SIG e avaliar os resultados de maneira interativa. Figura 1 - Arquitetura de um SIG ¹ ¹ (fonte: Câmara, 2005) Geoprocessamento Geoprocessamento é o conjunto de técnicas matemáticas e computacionais para tratar dados georreferenciados (dados com atributos geográficos, que descrevem sua forma e ou localização por exemplo). “Se ‘onde’ é importante para seu negócio, então Geoprocessamento é sua ferramenta de trabalho. Sempre que o ‘onde’ aparece, dentre as questões e problemas que precisam ser resolvidos por um sistema informatizado, haverá uma oportunidade para considerar a adoção de um SIG. (CÂMARA et al, 2001, p. 1)”. Segundo Gomes e Velho (1995) apud Câmara et al. (2002), para abordar o problema fundamental do entendimento das representações computacionais do espaço, há um arcabouço conceitual para entender o processo traduzir do mundo real para o ambiente computacional: o “paradigma dos quatro universos”, Figura 2 – Paradigma dos 4 universos. Fonte: PAIVA et al. (2006). a. O universo do mundo real, que inclui as entidades da realidade a serem modeladas no sistema; b. O universo matemático (conceitual), que inclui uma definição matemática (formal) das entidades a serem representadas; c. O universo de representação, onde as diversas entidades formais são mapeadas para representações geométricas e alfanuméricas no computador; d. O universo de implementação, onde as estruturas de dados e algoritmos são escolhidas, baseadas em considerações como desempenho, capacidade do equipamento e tamanho da massa de dados. É neste nível que acontece a codificação. Para Câmara et al. (2001), no universo de representação, definem-se as possíveis representações geométricas que podem estar associadas às classes do universo conceitual. Consideram-se duas grandes classes de representações geométricas: Representação Vetorial e Representação Matricial. Na representação vetorial, o elemento ou objeto é uma tentativa de reproduzi-lo o mais próximo da realidade. Qualquer entidade ou elemento gráfico de um mapa é reduzido a três formas básicas: pontos, linhas, áreas ou polígonos. A representação matricial consiste no uso de uma malha quadriculada regular sobre a qual se constrói célula a célula, o elemento que está sendo representado. Ainda a representação matricial supõe que o espaço pode ser tratado como uma superfície plana, onde cada célula está associada a uma porção do terreno. A resolução do sistema é dada pela relação entre o tamanho da célula no mapa ou documento e a área por ela coberta no terreno. “O Objeto vetorial é codificado usando um ou mais pares de coordenadas, o que permite determinar sua localização” (PAIVA et al. 2006 apud DAVIS JUNIOR, 1997). Um Sistema de Informações Geografias trata a informação vetorial, conforme algumas definições fundamentais, visualizados na figura 3. Figura 3 - Ponto, Linha e Polígono. Fonte: PAIVA et al. (2006). a) Ponto: um ponto é um par ordenado (x, y) de coordenadas espaciais. b) Reta: e segmento de reta: Sejam p1 e p2 dois pontos distintos no plano, a combinação linear de pontos ordenados (x, y) formando um segmento, sendo a definição de reta e segmento é estritamente geométrica. 22 c) Poligonal: que é composta por uma seqüência de segmentos de reta. O mais comum, no entanto, é definir a linha poligonal através da seqüência dos pontos extremos de seus segmentos, ou seja, seus vértices. Segundo Paiva et al. (2006) em conceito para geoprocessamento, dada uma região geográfica R, pode-se definir tipo de dados conforme segue: a) Coordenada 2D - Uma coordenada 2D é um objeto composto por uma b) Coordenada 3D - Uma coordenada 3D é um objeto composto por uma c) Ponto 2D - Um ponto 2D é um objeto que possui atributos descritivos e uma coordenada 2D; d) Linha 2D - Uma linha 2D possui atributos e inclui um conjunto de coordenadas 2D; e) Isolinha - uma isolinha contém uma linha 2D associada a um valor real (cota) e ainda para Câmara et al. (2001), são linhas às quais estão associados valores numéricos. As isolinhas não se cruzam, e são entendidas como estando “empilhadas” umas sobre as outras. f) Arco Orientado - um arco orientado contém uma linha 2D associada a uma orientação de caminho; g) Nó 2D 2D (trata-se da conexão entre duas ou mais linhas, utilizada para manter a topologia da estrutura); h) Nó Rede - um nó de rede contém um nó 2D e uma lista de arcos orientados, onde a cada instância associa-se uma impedância (resistência) e um custo para percorrer este caminho. i) Nó 3D - um nó 3D instância desta classe contém uma coordenada 3D (xi, yi, zi) e uma lista L de linhas 2D (tratam-se da conexão entre três ou mais linhas de uma grade triangular); j) Polígono - um polígono contém uma lista de linhas 2D e uma lista de nós 2D que descrevem as coordenadas da área externa e das áreas internas que compõem o polígono. O framework Geoframe Segundo Lisboa Filho (2001), “GeoFrame é um framework conceitual que fornece um diagrama de classes básicas para auxiliar o projetista nos primeiros passos da modelagem conceitual de dados de uma nova aplicação de SIG”. O Geoframe adiciona os elementos geográficos à notação UML tradicional. Graficamente, quando uma entidade é geográfica ela recebe dois pictogramas no canto superior direito, um informando que é uma entidade geográfica e outro informando o tipo (polígono, linha ou ponto). O ArgoCASEGEO (http://www.dpi.ufv.br/projetos/argocasegeo/) é uma ferramenta CASE de código aberto que auxilia na modelagem de banco de dados geográficos com base no modelo conceitual UML-GeoFrame, Esta ferramenta tem como base o software ArgoUML e está sendo desenvolvida no Departamento de Informática da Universidade Federal de Viçosa (UFV). Figura 4 – Interface do ArgoCaseGeo Na figura 4 é possível ver que um município é representado por um polígono, os rios principais por linhas e ETA (estação de tratamento de água) por um ponto. Neste caso, as relações entre as classes foram omitidas. Gerência de Dados Geográficos Basicamente existem três arquiteturas de gerenciamento de dados geográficos: Arquitetura Dual, Integrada baseada em SGBDs relacionais e Integrada baseada em extensões espaciais sobre SGBDs objeto-relacionais. Arquitetura Dual Em um SIG implementado nessa arquitetura os dados alfa-numéricos são armazenados no SGBD e os atributos geográficos são armazenados em sistemas de arquivos. Os dados alfa-numéricos (tabulares ou nãodimensionais) e os geográficos (ou espaciais) são ligados logicamente através de um atributo identificador de relação. As desvantagens dessa arquitetura são resumidas no fato de não se poder aplicar as funcionalidades de um SGBD (controle de transações, integridade , índices sobre as consultas etc.) sobre os dados geográficos. Arquitetura Integrada As arquiteturas integradas armazenam dentro do SGBD os dados alfanuméricos e geográficos, aproveitando assim todos os recursos nativos de um SGBD. Estas são subdivididas em dois tipos: Baseada em SGBD Relacional e a Baseada em SGBD Objeto-Relacional. A primeira utiliza campos longos (BLOB) para guardar os atributos espaciais dos registros. Porém possui como desvantagem o fato de não ter uma SQL voltada para consultas espaciais nem índices espaciais, o que torna a manipulação destes dados muito lenta. Já a arquitetura Objeto-Relacional estende a tradicional SQL implementando operadores topológicos e índices espaciais necessários. Possui como um ponto fraco a falta de padronização na implementação destes operadores espaciais, porém, é a melhor maneira de se tratar os dados geográficos. O PostGis, usado neste trabalho, é um exemplo de extensão espacial de um SGBD Objeto-Relacional (o PostgreSQL). 2.2 Cartografia Resumidamente a Cartografia (do grego chartis = mapa e graphein = escrita) é a ciência que se preocupa na representação de objetos geográficos seja em mapas ou outras formas de representação (como cartas entre outras). “O vocábulo CARTOGRAFIA, etimologicamente - descrição de cartas, foi introduzida em 1839, pelo segundo Visconde de Santarém - Manoel Francisco de Barros e Souza de Mesquita de Macedo Leitão, (1791 1856). A despeito de seu significado etimológico, a sua concepção inicial continha a idéia do traçado de mapas. No primeiro estágio da evolução o vocábulo passou a significar a arte do traçado de mapas, para em seguida, conter a ciência, a técnica e a arte de representar a superfície terrestre”. (IBGE, 1998, p. 9). Com o avanço da tecnologia, a Cartografia evoluiu também, tanto na coleta dos dados geográficos (com o uso de fotografias aéreas e sensoriamento remoto por exemplo) como na representação destes dados, usando de mapas digitais. Mapas Os mapas são representações geográficas da superfície curva do planeta terra sobre uma superfície plana. As projeções cartográficas são o processo de sistematicamente transformar partes da terra esférica para que sejam representadas em uma superfície plana, mantendo as relações espaciais. Elas podem ser geográficas (as medidas são representadas em graus) ou planas (as medidas são representadas em metros). 3. Ferramentas e Padrões para Dados Geográficos 3.1 SGBD – PostgreSQL O PostgreSQL (http://www.postgresql.org/) é o mais popular sistema gerenciador de banco de dados objeto relacional (SGBDOR) de código aberto.Foi escrito em C, Perl e Sh ( continua a ser desenvolvido) e é multiplataforma. Implementa todas as funcionalidades que um SGBD de grande porte deve ter, como : - consultas complexas -chaves estrangeiras -integridade transacional - controle de concorrência multi-versão -suporte ao modelo híbrido objeto-relacional -Triggers (gatilhos) -Views (visões) - Linguagem Procedural em várias linguagens (PL/pgSQL, PL/Python, PL/Java, PL/Perl) - Indexação por texto Resumo histórico O PostgreSQL é a evolução do projeto Ingres, desenvolvido na Universidade de Berkeley, Califórnia. Inicialmente o Ingres foi desenvolvido por Michael Stonebraker, um dos pioneiros dos bancos de dados relacionais na época. Em 1985, Stonebraker começou um projeto pós-Ingres com o objetivo de resolver problemas com o modelo de banco de dados relacional. O principal problema era a incapacidade de o modelo relacional compreender “tipos” (atualmente, chamados de objetos), ou seja, combinações de dados simples que formam uma única unidade. Então nasceu o Postgres. 3.1.2 Gerenciamento de dados Geográficos – PostGis O PostGIS é uma extensão do sistema de banco de dados objetorelacional PostgreSQL e inclui funções para armazenamento, análise e processamento de objetos espaciais. Abaixo estão listadas os principais fatores que justificam a sua escolha: Suporta os padrões de Simple Features Specification for SQL do Open Geospatial Consortium (OGC) Compatível com ESRI SDE e Oracle Spatial Possui licença GNU Figura 5 - Tipos de dados do PostGis (FONTE: http://www.dpi.inpe.br/cursos/ser303) O PostGIS foi desenvolvido por Refractions Research Inc, como uma tecnologia de banco de dados espacial no projeto de pesquisa. Refractions é uma companhia de consultoria em GIS e banco de dados localizada em Victoria, British Columbia, Canadá, especializada em integração de dados e desenvolvimento de software customizado. Ele possui certificação da OGC para compatibilidade de dados. Serve como backend para qualquer aplicação de publicação de mapas. Operadores Espaciais do PostGis Segue abaixo uma lista com alguns dos principais operadores espaciais do PostGis (http://webgis.com.br/postgis): Funções de Relacionamento entre Geometrias: • Distance(geometry,geometry) : Retorna a distancia cartesiana entre duas geometrias em unidades projetadas. • Equals(geometry,geometry): Retorna1 (VERDADEIRO) se esta geometria é espacialmente igual ("spatially equal" ) a uma outra geometria. • Intersects(geometry,geometry): Retorna 1 (VERDADEIRO) se esta geometria cruza espacialmente outra geometria. • Touches(geometry,geometry): Retorna 1 (VERDADEIRO) se esta geometria toca espacialmente de outra geometria. • Crosses(geometry,geometry): Retorna 1 (VERDADEIRO) se esta geometria cruza outras geometrias. • Within(geometry A,geometry B): Retorna 1 (VERDADEIRO) se a geometria A é está dentro da geometria B. • Overlaps(geometry,geometry): Retorna 1 (VERDADEIRO) se Geometria sobrepõe espacialmente. • Contains(geometry A, geometry B): Retorna 1 (VERDADEIRO) se a geometria A contém espacialmente a geometria B. • Relate(geometry,geometry, intersectionPatternMatrix): Retorna 1 (VERDADEIRO) se esta geometria é espacialmente relacionada com outra geometria, testando a interesecção entre o interior, o limite e o exterior de duas geometrias como especificado pelos valores em uma matriz da padrões de interseção. Funções de Processamento de Geometrias: • Buffer(geometry,double): Retorna uma área resultante que representa todos os pontos que distanciam em um valor x (segundo parâmetro da função) de uma determinada geometria (primeiro parâmetro). O Postgis oferece também um operador (shp2pgsql) para a transformar arquivos ShapeFiles em tabelas.Estas tabelas contêm uma coluna espacial (the_geom, do tipo geometry) que descreve os atributos geográficos originais, no formato WKT (Well Know Text, do OGC – Open Geospatial Consortium), informando basicamente a forma (ponto, linha, polígono, poliedros etc.), Sistema de projeção (cônica, cilíndrica etc.) e Sistema de Coordenadas (2D, 3D e até 4D) do dado. Este operador pode ser acessado via prompt de comando do PostgreSQL.A sintaxe dele é a seguinte: Shp2pgsql “caminho do shape” “nome da tabela” >”nome do arquivo.sql” O arquivo .sql gerado contém comandos SQL para criar e popular uma tabela com os dados transformados do ShapeFile original. Figura 6 - A coluna "the_geom"(FONTE: SIGDefesa) 3.3 Servidor de Mapas – MapServer O MapServer (http://mapserver.org/) é uma plataforma Open Source para a publicação de dados espacias e interação de mapas via Web que roda dentro do Apache (http://www.apache.org/). Foi criado em meados dos anos 90 na Universidade de Minessota e, atualmente, é um projeto da Open Source Geospatial Foundation (OSGeo). O seu uso é justificado por ter licença gratuita (MIT License) e pela larga documentação disponível na Web, o que facilita a implementação deste TCC. Um caso de sucesso onde o MapServer foi usado é o I3Geo (http://pt.wikibooks.org/wiki/I3geo). Outros aplicativos que poderiam ser escolhidos, como o GeoServer (http://geoserver.org/) por exemplo, porém ele ainda é um projeto recente, com poucas implementações no Brasil. O MapServer roda em Linux/Unix, Windows e Mac OS X. Ele pode se conectar a diferentes sistemas como PostGreSQL/PostGIS, Oracle, ArcSDE, ERDAS etc.; e usa o módulo Proj4 (também opensource) para que possa realizar a transformação dos diferentes tipos de dados geográficos em imagens resultantes, em tempo de execução e sem a necessidade de programações adicionais por parte do desenvolvedor.Os formatos resultantes são:GIF, PNG,JPEG, TIFF, BMP e SVG. A conexão entre o MapServer e o dado geográfico é configurada através de um arquivo de extensão .map. As consultas espaciais solicitadas ao MapServer passam por este arquivo, que verifica as configurações como o formato, dimensões e cor da imagem resultante, rótulos das formas (labels) etc.O acesso aos dados pode ser diretamente a um ShapeFIle (é necessário informar o caminho dele), através de, string de conexão com algum SGBD Espacial, ou ainda via WMS (Web Map Service). 3.4 O I3Geo O I3Geo (Interface Integrada para Internet de Ferramentas de Geoprocessamento) é um software desenvolvido para o acesso e análise de dados geográficos via Web. Foi criado pelo Governo Federal, através do Ministério do Meio-Ambiente, que em meados de 2006 o lançou com o objetivo de difundir entre os órgãos públicos o uso de ferramentas de geoprocessamento. O I3Geo possui licença GPL e implementa várias funcionalidades como: Navegação básica (zoom, lupa,busca e seleção de dados adição geográficos), de novas camadas, reordenação das camadas,edição de Dados geográficos via Web, download de dados, acesso a imagens de satélite, shapes, GML, KML etc., acesso via WMS, geração de relatórios e gráficos entre outras. O I3Geo foi desenvolvido com várias tecnologias livres (PHP, PHPMapscript), e roda sobre o MapServer. Figura 7 – Interface do I3GEO (http://mapas.mma.gov.br/i3geo) Abaixo seguem alguns links que apontam para sistemas baseados no I3GEO: MMA - Ministério do Meio Ambiente - http://mapas.mma.gov.br/i3geo INPA - Instituto de Pesquisas da Amazônia - http://siglab.inpa.gov.br/pfnm OTCA - Organização do Tratado de Cooperação Amazônica http://200.184.168.121:8083/i3geo MEC - Ministério da Educação - http://mapas.mec.gov.br/ MS - Ministério da Saúde - http://svs.aids.gov.br/atlas Presidência da República - https://geopr2.planalto.gov.br/geopr/ O seu manual de uso e instalação pode ser visualizado em http://pt.wikibooks.org/wiki/I3geo/. 4. O SIGDefesa 4.1 Arquitetura do SIGDefesa A Figura 8 ilustra a arquitetura do sistema proposto. A interface do sistema executa sobre um servidor de aplicações Web, o Apache, que funciona como um container para hospedar o MapServer, um servidor de mapas com funcionalidades para consultas, análise e visualização espacial. O MapServer transforma os dados geográficos vindos do servidor de dados em imagens, passando-as para o I3Geo que implementa a interface gráfica para visualização da informação geográfica no browser Web do cliente. I3GEO Figura 8 - Arquitetura do SIGDefesa. O servidor de dados alfanuméricos e geográficos roda no back-end, para prover maior robustez, desempenho e segurança. O servidor de dados é o PostgreSQL com a extensão PostGIS para o gerenciamento dos dados espaciais. Dados de diversas instituições são carregados no servidor do SIGDefesa através de um processo de extração, transformação e carga de dados geográficos. 4.2 O Desenvolvimento do SIGDefesa Inicio do Desenvolvimento Na fase de levantamento das necessidades da Defesa Civil, foi simulada uma entrevista com um agente da Defesa Civil, que descreveu as funcionalidades que gostaria de ter neste sistema. O entrevistado foi uma pessoa com experiência na área militar, o ex-bombeiro Rodrigo Luiz Oliveira, co-orientador deste trabalho. Como resultado da entrevista foi gerado um diagrama de casos de uso. Os requisitos foram solicitados com base nos dados geográficos que teríamos para uso. Figura 9 - Consultas a serem respondidas e os operadores do Postgis a serem usados Dados Disponíveis Na fase de busca e coleta dos dados buscou-se as fontes de dados geográficos disponíveis. A empresa VisaoGeo – Soluções em Inteligência Geográfica, forneceu shapefiles originalmente baixados do site do IBGE (ftp://geoftp.ibge.gov.br/mapas/malhas_digitais/municipio_2005/E500/Proj_Geo grafica/ArcView_shp/) e Epagri (http://ciram.epagri.sc.gov.br:8080/mapoteca/), e Aneel (http://www.aneel.gov.br). Também foi fornecido pela Prefeitura de Blumenau, através da pessoa de Ana Paula Zanete, os dados geográficos do município, produzidos pelo setor de Planejamento Urbano.Estes também estavam no formato ShapeFile e foram fornecidos sob restrições de uso (estes não pode ser repassados a terceiros). Segue abaixo a lista de dados: ◦ Shapes de Estações de Tratamento de Água (IBGE). ◦ Shape de Linhas de transmissão de energia (IBGE) ◦ Shape de Linhas de transmissão de energia (Aneel) ◦ Shape de Universidades (Pref. Blumenau) ◦ Shape de eixos (ruas, Pref. Blumenau) ◦ Shape de Centros de Educação Infantil (Pref. Blumenau) ◦ Shape de pontos de segurança (Polícia Militar, Bombeiros etc.) (Pref. Blumenau) ◦ Shapes de Bairros e Municípios (Pref. Blumenau) ◦ Shape de ANEAS (Áreas não edificáveis e não aterráveis) (Pref. Blumenau) ◦ Shape de vias (meio-fio) (Pref. Blumenau) ◦ Shape de Rios Principais e Secundários (Pref. Blumenau). ◦ Shape de Curvas de Nível 5m em 5m (Pref. Blumenau). ◦ Shape de Hidrografia do Estado de SC (Epagri) Figura 10 - Esquema dos dados geográficos Com base nos dados acima e nos requisitos simulados foi gerado o seguinte diagrama UML de casos de uso: Figura 11 - Casos de Uso do SIGDefesa ETC Espacial Foi preciso reunir os diversos dados geográficos em um único repositório. Todos os dados obtidos estavam no formato Shapefile (.shp). Para importá-los foi usado o operador shp2pgsql, via prompt de comando do PostgreSQL. Como a quantidade de formas é grande esta etapa foi bem morosa. Foi preciso também ajustar as projeções cartográficas das formas, para que estes pudessem ser visualizados corretamente no navegador Web. Para isso foi usado o software Udig (http://udig.refractions.net/). Abaixo segue a sintaxe do comando “shp2pgsql”: Shp2pgsql “caminho do arquivo.shp” “nome da tabela”>”nome do arquivo.sql” O arquivo .sql gerado contém o código de criação e população de tabelas com os dados georreferenciados. Cada tabela (shape importado) funciona como uma camada de informação (layer). Com o MapServer é possível visualizar estas camadas via Web, que podem ser ativadas conforme a necessidade do usuário e sobrepostas para combinar informações. Esta sobreposição das camadas pode trazer muitas informações interessantes para o usuário. A interface do sistema usa o I3Geo. Foi preciso adaptar e configurar o I3Geo para acessar os dados do Postgre/Postgis, sendo necessário ter o Apache instalado no servidor. O acesso aos dados passa pelo MapServer, e depois chega ao SGBD. 4.2 A Interface do Sistema A interface do sistema usa o I3Geo. Foi preciso adaptar e configurar o I3Geo para acessar os dados do PostgreSQL/Postgis. Figura 12 – Interface do SIGDefesa com os principais rios de Blumenau No servidor, para configurar o I3Geo é necessário ter o Apache. O acesso aos dados passa pelo MapServer, e depois chega ao SGBD. Com o I3Geo é possível fazer diversas análises geográficas. A simples combinação de camadas de informação (layers) já aumenta muito a quantidade de informações a serem extraídas do sistema. A figura 10 mostra a camada de município combinada à camada de rios principais. É possível ver o caminho dos rios dentro da cidade de Blumenau. Poderiam ainda ser ativada a camada de ruas por exemplo, para se visualizar as que se aproximam mais dos rios (formando uma área de risco por exemplo). Esta operação ainda poderia ser exportada para download , no formato shapefile, importado para o PostgreSQL e plotado de novo na Web. O resultado deste processo seria uma nova camada de informação com as informações já filtradas. Poderia ter sido criado (antes da exportação) um ponto no mapa, indicando um ponto de abrigo por exemplo. Um usuário com conhecimentos cartográficos e treinamento no I3Geo seria de grande utilidade para a Defesa Civil. 4.2 Manipulação dos Dados Geográficos via Web Para visualização dos dados geográficos, conforme a estrutura do MapServer, foi utilizado um arquivo de extensão .map. Através deste arquivo, o MapServer faz uma conexão com o PostgreSQL/PostGis e retorna com resultado uma imagem das formas geográficas selecionadas. Nele são configurados os parâmetros de conexão com o SGBD, dimensões e formato das imagens resultantes, fator de escala, cor de fundo, rótulos (labels) etc. Uma informação interessante é que este arquivo pode ser configurado para acessar diretamente um Shapefile, o que é comum em arquiteturas dual (citadas no capítulo de Fundamentação Teórica). O I3Geo plota o resultado retornado pelo MapServer no navegador Web. 5. Testes e Resultados 5.1 Consultas Espaciais Para extrair informações estratégicas dos dados foram implementadas as consultas abaixo, todas explorando os operadores espaciais do PostGis ( para evidenciar a utilidade dos atributos geográficos). Cada uma foi testada e visualizada via interface Web (I3Geo) . 1 – Localizar os postos de auxílio militar e civil (Polícia, Bombeiros, Defesa Civil, Exército e Guarda Municipal) a uma certa distância de um dado local. Objetivo : permitir a Defesa Civil ter um controle sobre as distâncias entre pontos estratégicos de auxílio militar e civil. Neste caso, usou-se como referência a bacia do Rio Itajaí, mas poderia ser medida a distância a qualquer outro objeto da base. O operador espacial do Postgis usado foi o “Distance”. SELECT p.* FROM tbpontosseguranca p, tbriosprincipais rios WHERE distance(rios.the_geom, p.the_geom) < 100 AND rios.gid=3; O valor “100” corresponde a 100 unidades de distância. A consulta acima retorna 8 pontos com sua descrição (Polícia, Bombeiros etc.) e endereço. Porém, destes 8 pontos, apenas 7 aparecem no mapa abaixo.Isso deve ocorrer devido a algum erro na criação da forma de pontos e pode ser corrigido com alguma ferramenta de edição de dados geográficos.Neste caso, o ponto deve estar aparecendo fora do mapa de município. A Figura 13 mostra a visualização no mapa via interface Web. Figura 13 - Pontos de segurança mais próximos à bacia do Rio Itajaí Figura 14 - Camadas ativadas Na Figura 14 vemos a mesma consulta porém agora com rótulos identificando os pontos retornados. Também foi ativada a camada dos rios principais para melhor entendimento da situação. Porém apenas 4 dos pontos retornados possuem rótulos visíveis no mapa, devido a algum problema na configuração da interface (entre o MapServer e o I3Geo) ainda não resolvido até o momento. 2 - Mapear uma zona de risco de alagamento potencial, mostrando as ruas e bairros que o Rio Itajaí e seus afluentes atravessam: Objetivo: Auxiliar a Defesa Civil a projetar no mapa as áreas com maior risco de alagamento, com o uso do operador espacial “Intersects”. Primeiro foi necessário descobrir qual registro na tabela “tbriosprincipais” (oriunda do shape “Rios Principais” cedido pela prefeitura de Blumenau) correspondia ao Rio - Itajaí. Para isso foi identificado qual geometria possuía a maior área nesta tabela, com a seguinte consulta espacial : SELECT rios.gid, area(the_geom)/ 1000 AS area, perimeter(the_geom) as perimtero FROM tbriosprincipais rios GROUP BY rios.gid,rios.the_geom ORDER BY area DESC LIMIT 1 ou através do perímetro: SELECT rios.gid, perimeter(the_geom) AS perimetro FROM tbriosprincipais rios GROUP BY rios.gid,rios.the_geom,perimetro ORDER BY perimetro DESC LIMIT 1 Ambas as consultas retornaram o mesmo resultado. Com o Rio-Itajaí e seus afluentes identificados, foi possível mapear os bairros e as ruas que são interseccionadas pelos rios: Bairros: SELECT b.the_geom AS the_geom,b.gid as gid,b.bairro FROM tbriosprincipais r , tbbairros b WHERE r.gid=3 AND intersects(r.the_geom,b.the_geom) Ruas: SELECT ruas.the_geom as the_geom,ruas.gid as gid FROM tbriosprincipais r , tbeixos ruas WHERE r.gid=3 AND intersects(r.the_geom,ruas.the_geom) Porém a diferença de desempenho entre as duas consultas é extremamente alta.Enquanto que para os bairros a consulta levou 2606 ms para retornar 27 linhas, para as ruas 624795 ms (10 minutos aproximadamente). Esta diferença se dá devido ao fato de que o shape de bairros, que originou a tabela de bairros, possui poucas geometrias (poucos polígonos) para serem interseccionados com o polígono dos rios principais, enquanto que o shape de ruas possuía muitas geometrias, pois cada rua é representada em forma de uma linha, aumentando o número de registros na tabela de ruas (8241, contra 35 linhas na tabela de bairros). Logo, somente o resultado dos bairros é apresentado abaixo: Bairros retornados: Salto, Itoupava Central, Vila Nova, Itoupava Seca, Valparaiso, Itoupava Norte, Vila Formosa, Centro, Victor Konder, Garcia, Boa Vista, Jardim Blumenau, Ponta Aguda, Nova Esperança, Vorstadt, Testo Salto, Itoupavazinha, Fortaleza, Salto do Norte, Fidelis, Progresso. O mapa visualizado via interface Web é mostrado na Figura 15. Figura 15 - Bairros em zona perigosa É possível perceber que há um bairro (e possivelmente outros) que não são interseccionados, porém estão muito próximos da bacia do rio Itajaí. Logo, esta consulta pode ser incrementada com o uso do operador buffer, que determina uma área de abrangência a ser retornada, e não apenas as intesecções (que representam os casos mais críticos). É importante ressaltar que a consulta não leva em conta a altimetria das formas geométricas, que poderia ser comparada à cota de enchente. 3- Definir uma área de abrangência X de trabalho para algum posto militar de auxílio Objetivo: Auxiliar a Defesa Civil a visualizar a área de atuação de um determinado posto da Polícia Militar (ou qualquer outro ponto), através do uso do operador espacial “Buffer”. SELECT buffer(ps.the_geom,3000) FROM tbpontosseguranca ps WHERE ps.gid=10 Onde o valor “3000” corresponde a unidade de distância.. Figura 16 - Área de atuação de um posto da Polícia Militar A área pintada em vermelho corresponde a sua área de atuação simulada do 10º Batalhão da Polícia Militar (no centro do círculo). 4 – Quais rios estão contidos na área de atuação de um Posto Militar? Objetivo: Visualizar os rios que estão dentro da área de atuação abrangida pelo 10º Batalhão da Polícia Militar, usado no exemplo anterior, através da combinação dos operadores “Buffer” e “Contains”. SELECT r.the_geom AS the_geom,r.gid FROM tbriosprincipais r,tbpontosseguranca ps WHERE ps.gid=10 and contains(buffer(ps.the_geom,3000),r.the_geom) Resultado: Figura 17 - Rios contidos em uma área A consulta espacial acima retorna apenas os rios cuja geometria está completamente contida dentro da área de abrangência definida, excluindo do resultado o rio Itajaí por exemplo, que tem apenas parte de sua forma contida nesta área. Como a composição de um rio é representada por uma ou mais linhas, a consulta retorna as linhas ( ou trechos dos rios) que estão contidas na área. Os rios estão em azul, e a camada de ruas (em vermelho) foi habilitada.Os rótulos mostram os bairros vizinhos. O mesmo resultado poderia (e foi) ser obtido com outro operador, o “Within”: SELECT r.the_geom as the_geom,r.gid FROM tbriosprincipais r,tbpontosseguranca ps WHERE ps.gid=10 AND within(r.the_geom,buffer(ps.the_geom,3000)) Configuração do MapServer O arquivo de extensão “.map” recebe os parâmetros deconfiguração necessários para informar basicamente ao MapServer qual consulta espacial e em que formato de imagem resultante será representada a geometria.Outros fatores de cunho visual como escala, cores , rótulos etc. também são configuradas neste arquivo. Para os resultados de cada consulta espacial foram criadas camadas de informação (layers) e configuradas no arquivo “.map”.Segue abaixo o exemplo de uma camada com uma consulta espacial: LAYER #código da camada NAME ZonaPerigoo #tipo de representação TYPE polygon #status de visibilidade off|default STATUS default #endereço do shape file, se for arquivo desse tipo #DATA /opt/www/html/brasil/limitespol/muni2001 #tipo de conexão se for postgis CONNECTIONTYPE postgis #parâmetros de conexão com o banco CONNECTION "" DATA "the_geom FROM (select b.the_geom as the_geom,b.gid as gid,bairro from tbriosprincipais r , tbbairros b where r.gid=3 and intersects(r.the_geom,b.the_geom)) as zonaperigo USING UNIQUE gid" LABELITEM "bairro" #deixe sempre assim TEMPLATE "none.htm" #inicio da definição de metadados METADATA #lista dos itens existentes na tabela de atributos da camada #e que serão mostrados nas opções de identificação ITENS "gid,classe,bairro" #descrição dos itens, um para cada item ITENSDESC "Código,Classe,Bairro" #opcional. lista de links que serão incluídos ITENSLINK ",,,,,http://www.ibge.gov.br/home/geociencias/areaterritorial/area.php?codigo=[g eocodigo]" #opcional. Item que será utilizado como etiqueta TIP "Rios Itajaí e Afluentes" #nome que será mostrado na legenda TEMA "Zona Perigos Bairros" #o tema possuí classes? CLASSE "SIM" #opcional. Escala da fonte dos dados ESCALA "250000" #opcional. Será mostrado um ícone ao lado do tema permitindo seu download DOWNLOAD "nao" #opcional. Define se o tema ficará escondido, não aparecendo nas listagens e legenda #ESCONDIDO "sim" #fim da definição do metadado END #início da definição de uma classe CLASS SYMBOL 0 COLOR 128 128 0 OUTLINECOLOR 0 0 0 NAME "Barro Names" LABEL COLOR 0 0 0 FONT arial TYPE TRUETYPE POSITION CC PARTIALS TRUE SIZE 7 BUFFER 1 OUTLINECOLOR 255 255 255 END END #fim da definição da camada END 5.2 O Módulo “Postos de Abrigo” No momento em que se finalizava este projeto, quando a arquitetura do SIGDefesa já estava melhor elaborada e já era possível saber quais dados teríamos disponíveis para acesso e a como seria a sua manipulação via Web; somando o fato de que o SIGDefesa será disponibilizado à Defesa Civil ao término deste TCC, e que enquanto se desenvolvia este trabalho as chuvas já voltavam a assolar fortemente o município, percebeu-se a oportunidade de levantar alguns requisitos reais junto à Defesa Civil de Blumenau ( sendo que no primeiro momento apenas simulamos alguns requisitos para estudar a base e o uso dos operadores espaciais do Postgres/Postgis).Sendo assim nasceu o módulo “Postos de Abrigo”. Logo foi feita uma reunião, em Blumenau, com o chefe da Defesa Civil o sr. José Corrêa Negredo. Foi descrito para ele quais dados geográficos estariam integrados e disponíveis via Web e o que seria possível fazer com o sistema. O mesmo mostrou muito entusiasmo e interesse no sistema. Levantou-se então a necessidade de se ter no sistema o controle dos Postos de Abrigo. Estes são postos localizados próximos às áreas atingidas, que servem de abrigo às famílias desabrigadas. Eles ficam sobre a responsabilidade de algum agente civil ou militar. Este módulo será implementado na forma de um trabalho voluntário e tem também como objetivo dar suporte à Defesa Civil na geração de informações importantes até mesmo para a captação de recursos junto ao Governo (já que a Defesa Civil alegou não receber verba para investimentos nesta área). Segue abaixo a modelagem para este módulo. Após a conclusão da implementação, o sistema será instalado no servidor da Prefeitura de Blumenau e serão disponibilizados os manuais do sistema e uma apresentação do mesmo. Modelagem do Módulo Postos de Abrigo Requisitos: Funcionais: Cadastrar e editar via Web os dados (ver modelo de dados) dos postos de abrigo. Não-Funcionais: Apenas o responsável pelo posto de abrigo deve ter permissão para cadastrar os dados Apenas o Administrador (Chefe da Defesa Civil) deve poder cadastrar um responsável por um posto. Figura 18 - Casos de Uso Modelo de dados: Figura 19 - Modelo E-R normalizado 6. CONCLUSÕES E TRABALHOS FUTUROS O SIGDefesa, sistema apresentado neste trabalho, auxilia a Defesa civil e outras instituições de utilidade pública a efetuar planejamentos de modo a evitar ou minimizar os impactos causados por eventuais desastres naturais. Ele também poderá atender algumas demandas de informação geográfica em futuros estados de emergência ou de calamidade pública. Várias outras consultas podem ser implementadas neste sistema, agora que a integração dos dados já foi feita e também o estudo dos operadores espaciais mais importantes. Foi muito gratificante em termos acadêmicos e pessoais desenvolver este trabalho. Primeiro pelo fato do meu interesse pessoal em estudar os operadores espaciais do Postgis, a representação espacial dos dados geográficos entre outros temas. Segundo, mas definitivamente não menos importante, por se tratar de uma implementação útil para uma causa nobre, sendo que o módulo Postos de Abrigo realiza um desejo pessoal meu de se fazer um trabalho voluntário. Para trabalhos futuros recomendo a integração de imagens de satélite, dados em gml, kml, e outros formatos e o seu acesso via WMS; além da integração com dados meteorológicos. Também seria interessante implementar um módulo que use o algoritmo Djikstra, disponível para o PostgresSQL, para efetuar a rota do melhor caminho entre dois pontos (um ponto de abrigo e um ponto obstruído, sendo que pode haver rotas obstruídas no meio do caminho, por exemplo). REFERÊNCIAS BIBLIOGRÁFICAS DAVIS, Clodoveu; MONTEIRO, Antônio; CÂMARA, Gilberto, Introdução à Ciência da Geoinformação, 2001. Disponível em < http://www.dpi.inpe.br/gilberto/livro/introd/index.html>, acesso 24/03/2009. IBGE - Noções Básicas de Cartografia, Rio de Janeiro, 1998. Disponível em < http://www.ibge.gov.br/home/geociencias/cartografia/manual_nocoes/indice.htm > acessado em 16/03/2009. LISBOA FILHO, Jugurta. Projeto de Banco de Dados para Sistemas de Informação Geográfica. Revista Eletrônica de Iniciação Científica - REIC/SBC, 1(2), Universidade Federal de Viçosa, 2001. MapServer. Disponível em < http://mapserver.org/index.html/>, acessado em 24/03/2009 OLIVEIRA, Rodrigo, Roteamento de Veículos Utilizando o Algoritmo de Menor Caminho DIJKSTRA, 2006, Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) – Faculdade de Ciências da Computação, Centro de Ensino Superior de Foz do Iguaçu, Foz do Iguaçu. OpenGeo. Disponível em < http://www.opengeo.com.br/>, acessado em 24/03/2009 OpenGeospatialConsortium (OGS). Disponível em < Disponível em http://www.opengeospatial.org/ogc/>, acessado em 24/03/2009 OpenSourceGeospatial Foundation (OSGeo). <http://www.osgeo.org/content/foundation/about.html>, acessado em 24/0 PAIVA, João Argemiro; CASANOVA, Marco; CARTAXO, Ricardo; CÂMARA, Gilberto, Modelagem de Banco de Dados Geográficos, 2005. Disponível em <www.dpi.inpe.br/gilberto/livro>, acesso 14/03/2009. POSTGIS.Disponível em <http://postgis.refractions.net/>, acessado em 16/03/2009. POSTGIS, Manual de uso. Disponível em <http://webgis.com.br/postgis/>, acessado em 16/03/2009 Presidência da República. Casa Civil. Disponível em <http://www.planalto.gov.br/ccivil_03/_Ato20042006/2005/Decreto/D5376.htm>>. Acessado em 13/03/2009 Prefeitura de Blumenau SC, Defesa Civil. Disponível em <http://www.blumenau.sc.gov.br/novo/site/conteudo/index.php?IDSECAO=2276 &IDPAI=2275> acessado em 16/03/2009.
