Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM ALGORITMO PARA ANÁLISE ESPAÇO-TEMPORAL DE DADOS DE CAPTURA PESQUEIRA E GERAÇÃO
DE MAPAS TEMÁTICOS PARA VISUALIZAÇÃO VIA WEB
Área de Matemática Computacional
por
Fernando Simon
Rodrigo Becke Cabral, Dr Orientador
Rafael Medeiros Sperb, Dr Co-orientador
Itajaí (SC), dezembro de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM ALGORITMO PARA ANÁLISE ESPAÇO-TEMPORAL DE DADOS DE CAPTURA PESQUEIRA E GERAÇÃO
DE MAPAS TEMÁTICOS PARA VISUALIZAÇÃO VIA WEB
Área de Matemática Computacional
por
Fernando Simon Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Rodrigo Becke Cabral, Dr
Itajaí (SC), dezembro de 2005
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS.................................................................................v
LISTA DE EQUAÇÕES ...........................................................................vi RESUMO...................................................................................................vii ABSTRACT..............................................................................................viii 1. INTRODUÇÃO......................................................................................1
1.1. OBJETIVOS ........................................................................................................ 4 1.1.1. Objetivo Geral ................................................................................................... 4 1.1.2. Objetivos Específicos ........................................................................................ 4 1.2. METODOLOGIA................................................................................................ 4 1.2.1. Etapas realizadas durante o TCC I................................................................. 5 1.2.2. Etapas realizadas durante o TCC II ............................................................... 5 1.3. ESTRUTURA DO TRABALHO ....................................................................... 6
2. FUNDAMENTAÇÃO TEÓRICA........................................................7
2.1. DADOS GEOESPACIAIS.................................................................................. 7 2.1.1. Feições Geoespaciais ......................................................................................... 9 2.1.2. Objeto Geoespacial ........................................................................................... 9 2.1.3. Elaboração do Objeto ..................................................................................... 10 2.2. OPEN GEOSPATIAL CONSORTIUM.......................................................... 11 2.2.1. Documentação OGC ....................................................................................... 11 2.2.2. OPENGIS Specifications ................................................................................ 12 2.3. BANCO DE DADOS GEOESPACIAIS.......................................................... 12 2.3.1. Arquitetura dual ............................................................................................. 14 2.3.2. Arquitetura Integrada .................................................................................... 15 2.3.3. Acesso aos dados.............................................................................................. 16 2.3.4. PostgreSQL...................................................................................................... 17 2.3.5. Oracle ............................................................................................................... 20 2.4. ANÁLISE ESPACIAL ...................................................................................... 26 2.4.1. Estatística Geoespacial ................................................................................... 27 2.4.2. Estatística Pesqueira....................................................................................... 31 2.5. WEB MAPPING................................................................................................ 34 2.5.1. UMN Mapserver ............................................................................................. 36 2.5.2. Mapserver Guarani ........................................................................................ 47 2.6. CONSIDERAÇÕES .......................................................................................... 51
3. DESENVOLVIMENTO......................................................................54
3.1. PROJETO .......................................................................................................... 54 3.1.1. Sistema de Informação Para Suporte À Gestão Pesqueira......................... 54
3.1.2. Análise GeoEspacial........................................................................................ 54 3.1.3. Modelagem....................................................................................................... 55 3.1.4. Diagrama de Caso de Uso............................................................................... 55 3.1.5. Diagrama de Seqüência .................................................................................. 57 3.1.6. Diagrama de Atividades ................................................................................. 61 3.1.7. Diagrama de Classe......................................................................................... 63 3.1.8. Diagrama de Componentes ............................................................................ 68 3.1.9. Protótipo de Tela............................................................................................. 70 3.2. IMPLEMENTAÇÃO ........................................................................................ 71 3.2.1. Introdução........................................................................................................ 72 3.2.2. Gradiente de cores .......................................................................................... 72 3.2.3. Mapfile ............................................................................................................. 73 3.2.4. Mapserver Guarani ........................................................................................ 77 3.2.5. Cadastro de camada ....................................................................................... 79 3.2.6. Grid dinâmico.................................................................................................. 82 3.2.7. Objetos espaciais ............................................................................................. 83 3.2.8. Objeto Célula................................................................................................... 86 3.2.9. Cálculo da Métrica.......................................................................................... 87 3.2.10. Análise Kernel .......................................................................................... 88 3.2.11. Fluxo PrinciPal De Execução.................................................................. 90 3.2.12. Resultados ................................................................................................. 95
4. CONCLUSÃO ......................................................................................98
REFERÊNCIAS BIBLIOGRÁFICAS .................................................100
GLOSSÁRIO...........................................................................................103
Apêndice A – Modelagem do Sistema.......................................................1
Apêndice B – Código Fonte .......................................................................1
Anexo I – Modelagem Mapserver Guarani .............................................1
Artigo ciêntífico...........................................................................................1
LISTA DE ABREVIATURAS
AML ARC Macro Language API Application Programming Interface CGI Common Gateway Interface CCGIS Consulting Center für Geographische Informationssisteme FEAT Faculdade de Educação, Administração e Tecnologia de Ibaiati GEP Grupo de Estudos Pesqueiros GIST Generalized Search Trees GML Geography Markup Language GNU GNU Project HTML Hyper Text Markup Language IIS Servidor web Microsoft, Internet Information Services ISO International Organization for Standardization LCA Laboratório de Computação Aplicada MBR Minimal Bounding Rectangles MNDNR Minessota Department of Natural Resources NASA National Aeronauitcs and Space Administration OCG Open Geoespatial Consorcium PDF Portable Document Format Perl Practical Extraction and Report Language PHP HyperText Processor SDE Spatial Data Engine SGBD Sistema Gerenciador de Banco de Dados SGBDR Sistema Gerenciado de Banco de Dados Relacional SHP Acrônimo para ShapeFile SIG Sistema de Informação Geográfica SLD Styled Layer Descriptor SQL Structure Query Language SWF Shockwave Flash SWIG Simplified Wrapper and Interface Language TCC Trabalho de Conclusão de Curso TCL Tool Command Language UML Unified Modeling Language UMN University of Minessota UNIVALI Universidade do Vale do Itajaí W3C World Wide Web Consorcium WCS Web Coverage Service WEB World Wide Web WFS Web Feature Service WKB Well Know Binary WKT Well Know Text WMS Web Map Service XHTML Extensible Hypertext Markup Language XML Extensible Markup Language
LISTA DE FIGURAS
Figura 1. Exemplo de WEBGIS para aquacultura. ..............................................................................2 Figura 2: Representação esquemática do Objeto Geoespacial.............................................................8 Figura 3. Exemplo de arquitetura dual ...............................................................................................14 Figura 4. Relações entre os tipos de pesquisa espacial ......................................................................24 Figura 5: Curva de análise do método................................................................................................29 Figura 6: Curva para a distância definida...........................................................................................29 Figura 7: Classificação dos tipos de mapas........................................................................................32 Figura 8: Exemplo de gradiente. ........................................................................................................34 Figura 9: Trecho de um arquivo Mapfile. ..........................................................................................40 Figura 10: Exemplo de objeto layer. ..................................................................................................42 Figura 11. Árvore organizacional do UMN Mapserv. .......................................................................43 Figura 12: Cálculo de distância. .........................................................................................................49 Figura 13: Análise espacial sobre dados de rodovias da região de Itajaí. ..........................................50 Figura 14: Diagrama de caso de uso proposto para o algoritmo. .......................................................57 Figura 15: Diagrama de seqüência proposto para o algoritmo...........................................................60 Figura 16: Diagrama de seqüência interno ao Mapserver Guarani ....................................................61 Figura 17: Diagrama de atividade especificado para o algoritmo proposto.......................................63 Figura 18: Diagrama de classe. ..........................................................................................................67 Figura 19: Diagrama de classe do pacote Mapserver Guarani...........................................................68 Figura 20: Diagrama de componentes................................................................................................69 Figura 21: Protótipo de tela ................................................................................................................71 Figura 22: Exemplo de objeto layer com a definição de células. ......................................................74 Figura 23: Grid gerado pelo UMN Mapserver...................................................................................74 Figura 24: Camada utilizada para gerar o grid...................................................................................75 Figura 25: Células expressas em gradiente de cores. .........................................................................76 Figura 26: Em (a) é apresentado o menu original, substituído pela funcionalidade implementada (b)
....................................................................................................................................................78 Figura 27: Módulo de configuração de camadas para o Mapserver Guarani.....................................80 Figura 28: Grid visualizado através do Mapserver Guarani. .............................................................81 Figura 29: Exemplo de execução dnção para cálculo dos limites......................................................82 Figura 30: Função responsável por cirar os objetos espaciais no UMN Mapserver. .........................84 Figura 31: Função para identificar a classe a qual célula pertence. ...................................................84 Figura 32: Chamada a função de criação dos objetos espaciais.........................................................85 Figura 33: Atributos da classe Celula. ...............................................................................................86 Figura 34: Chamada a função para o cálculo da métrica. ..................................................................88 Figura 35: Codificação da função de cálculo do método Kernel. ......................................................90 Figura 36: Instância do objeto da classe de análise............................................................................91 Figura 37: Função que identifica os valores do grid. .........................................................................92 Figura 38: Função pra identificar a qual célula o lance pertence.......................................................92 Figura 39: Cálculo de células adjacentes. ..........................................................................................93 Figura 40: Resultado da análise. ........................................................................................................95 Figura 41: Resultado da análise. ........................................................................................................96 Figura 42: Resultado da análise. ........................................................................................................97
LISTA DE EQUAÇÕES
Equação 1 ...........................................................................................................................................28
RESUMO
Simon, Fernando. Desenvolvimento de um algoritmo para análise espaço-temporal de dados de captura pesqueira e geração de mapas temáticos para visualização via WEB. Itajaí, 2005. 120. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005. Atualmente muitos projetos na área do meio ambiente contam com o suporte de tecnologias geoespaciais. Estas tecnologias estão intimamente ligadas a conceitos como matemática computacional, análises estatísticas, e banco de dados geoespaciais. É nesta linha de desenvolvimento tecnológico que este projeto de graduação encontra-se inserido, ao realizar o desenvolvimento de um algoritmo para a definição dinâmica de quadrantes para consulta e análise de dados da indústria pesqueira. Esta ferramenta disponibiliza aos especialistas na área de gestão pesqueira, especialmente os do Grupo de Estudos Pesqueiros do Centro de Ciências Tecnológicas da Terra e do Mar da Universidade do Vale do Itajaí, um meio de definição dinamica da resolução de consultas e análises geoespaciais. Os produtos gerados através desta ferramenta são cartas para a visualização de temas, como o esforço de pesca por unidade de área ou a abundância de espécies. Adicionalmente, o trabalho faz o emprego da internet como meio de visualização das cartas temáticas, buscando a distribuição da informação entre diferentes atores envolvidos com a gestão pesqueira. A manipulação dos dados geoespaciais via internet se constituiu num desafio ao presente estado da arte em geotecnologias. Além das limitações tecnológicas, a cultura de coleta de dados sobre as atividades pesqueiras sem o devido georreferenciamento contribui para o lento desenvolvimento de aplicações nesta área. Para atender ao proposto, o algoritmo foi desenvolvido em linguagem PHP, utilizando o módulo PHP Mapscript do UMN Mapserver para leitura e manipulação de objetos geoespaciais oriundos do banco de dados PostGIS. Para a análise foi empregado o método de Kernel, largamente utilizado em análises geoespaciais em sistemas de informação geográfica residentes. O resultado deste trabalho foi incorporado ao Mapserver Guarani, como uma nova funcionalidade. Os testes realizados indicam a viabilidade deste tipo de análise geoespacial via internet, abrindo novas perspectivas para a manipulação e visualização de dados geográficos através da Web. Palavras-chave: Análise Geoespacial, Análise Pesqueira, UMN Mapserver, PostgreSQL/PostGIS.
ABSTRACT
Nowadays a considerable number of projects in the environmental area have support of geospatial
technologies. These technologies are closely linked to concepts such as computacional
mathematics, statistical and geospatials analyses and geospatial data base. This work is based on
these technologies for implementing an algorithm for the dynamic definition of quadrants for
quering and data analysis of fisheries industry. The aim of this algorithm is to provide to fisheries
management specialists, especially to the Fisheries Study Group of the Centro de Ciências
Tecnológicas da Terra e do Mar at the Universidade do Vale do Itajaí, a tool capable of
dynamically define the spatial resolution for queries and geospatials analyses. The outcome of this
tool shall be maps for thematic visualization such as capture effort per unit of area or abundance of
species. The algorithm is based upon internet and might be considered a innovative approach since
the most of the web based GIS applications only run simple queries and visualization. The proposed
algorithm employs the Kernel Method for geospatial analysis. A relatively common method in
desktop applications. The algorithm was developed in PHP language, using PHP Mapscript
module of the UMN Mapserver for manipulation of geospatial objects from the PostGis data base.
It was incorporated as a new functionality to the Mapserver Guarani Framework for tests.The
results indicate that it is feasible to use such geoespacial analysis through internet, pointing to new
development perspectives in WebGIS applications.
Keywords: Geospatials Analysis, Fishing Analysis, UMN Mapserver, PostgreSQL/PostGIS.
1. INTRODUÇÃO
Existe uma crescente preocupação em relação ao futuro dos estoques pesqueiros dos
oceanos, outrora considerados inesgotáveis fontes de proteínas. Este cenário deriva da exploração
não sustentável dos recursos pesqueiros, fato que indica a necessidade de dimensionamento de seu
potencial de exploração, seja por espécie ou por área.
O emprego de análises estatísticas constitui uma das principais fontes de informação sobre
as atividades pesqueiras. Elas geram subsídios para o planejamento e apoio à tomada de decisões
relacionadas ao manejo da atividade. Estas decisões englobam as mais diversas áreas, desde
financeiras até estratégicas, e visam, em primeira instância, a manutenção da pesca em níveis de
equilíbrio por vários anos. Deste modo, gerar informações e manter estatísticas atualizadas sobre a
indústria pesqueira é de suma importância (GEP, 2001; FIS, 2004; NMFS, 2004).
Para colaborar com esta demanda internacionalmente reconhecida, o Grupo de Estudos
Pesqueiros (GEP) do Centro de Ciências Tecnológicas da Terra e do Mar da Universidade do Vale
do Itajaí vem desenvolvendo, desde outubro de 2000, a captura de dados da indústria pesqueira
nacional, através de convênios firmados com o Governo Federal (GEP, 2000; GEP 2001). Os dados
gerados ao longo destes anos encontram-se sistematizados em banco de dados, o que facilita o
trabalho de análise estatística que, anualmente, é apresentado no Boletim de Estatística da Pesca
Industrial de Santa Catarina. Nestes boletins os resultados encontram-se sumarizados em tabelas
e gráficos, e disponíveis ao público através de um portal1, a exemplo do procedimento adotado por
outros países (FIS, 2004; NMFS, 2004; OCAD, 2004; WADF, 2004).
O emprego de Sistema de informação Geográfica (SIG) e de análises geoespaciais são
tendências que vem se estabelecendo no cenário pesqueiro internacional (FIGIS, 2004; AQUAGIS,
2004), conforme ilustrado na Figura 1. Ao considerar a dimensão geográfica, as análises
possibilitam que mapas temáticos possam ser gerados a partir da base de dados, apresentando
resultados estatísticos por área ou região. Além disso, é possível que seja explorada a relação de
vizinhança existente entre a distribuição/abundância de uma espécie e os atributos geoespaciais que
possam influenciá-las, como por exemplo, profundidade e temperatura.
1 http://www.univali.br/gep
Figura 1. Exemplo de WEBGIS para aquacultura.
Fonte: AQUAGIS (2004)
Este tipo de enfoque abre uma nova fronteira nos estudos pesqueiros ao atribuir importância
aos dados geocodificados. As análises de vizinhança com potencial de utilização dependem do
problema abordado e do meio ambiente em que se aplica. Por exemplo, Carneiro e Santos (2003)
utiliza este enfoque para detecção de áreas de risco aplicado à saúde pública; Brandão (2000) se
beneficia da análise espacial para identificar potenciais áreas de mineração; Rodriguez (2000) aplica
análises espaciais para identificar padrões de distribuição de violência em São Paulo. Na área
específica de estudos pesqueiros, cabe mencionar estatísticas geradas e disponibilizadas pelo Reino
Unido (DEFRA, 2004; SFS, 2004), e por instituições de pesquisa que realizam análises estatísticas
em nível global (FAO, 2004). Estudos estes realizados sobre dados de pesca, com estatísticas que
permitem traçar uma evolução da atividade no cenário mundial, demonstrando uma tendência de
grande preocupação com os recursos pesqueiros, bem como seu manejo eficaz.
Apesar do esforço de coleta e sistematização que o GEP vem conduzindo no Brasil, ainda
não existe uma estrutura estabelecida para o desenvolvimento de análises geoespaciais. Assim, este
documento propõe o desenvolvimento de uma ferramenta para que análises espaço-temporais sejam
conduzidas a partir da base de dados existente. Ampliando o horizonte destas análises, a ferramenta
proposta visa também à geração de mapas temáticos a partir dos resultados obtidos.
Acredita-se que o uso de mapas temáticos venha a contribuir qualitativamente na
compreensão dos fenômenos que regem a pesca, possibilitando que ações estratégicas coerentes e
eficazes possam ser estabelecidas. Eventualmente, os mesmos mapas temáticos poderão evidenciar
o sucesso ou não das ações estratégicas.
Atualmente uma das ferramentas com potencial para a geração de mapas temáticos a partir
de bancos de dados é o UMN Mapserver, que vem sendo desenvolvida através de uma parceria
entre Minnesota Department of Natural Resources (MNDNR), a Universidade de Minessota (UMN)
e a North America Space Agency (NASA). Não é somente este ponto que contribui para o sucesso
do UMN Mapserver, mas a capacidade de entrega de mapas via web que permite que dados possam
ser visualizados e disponibilizados a usuários conectados a grande rede.
A manipulação de dados geoespaciais através do UMN Mapserver pode ser feita através de
diversas interfaces, dentre elas arquivos Mapfiles e scripts de programação. O arquivo Mapfile
permite criar a base de objetos geoespaciais interpretáveis pelo UMN Mapserver. É neste arquivo
que ficam armazenados os valores padrões para o mapa (configurações). A manipulação dinâmica
dos objetos geoespaciais para visualização pode ser feita através de uma interface que aceita
inúmeras linguagens de programação, dentre elas Hypertext Preprocessor (PHP). Tal interface
recebe o nome de MapScript e permite a visualização dos objetos espaciais como estruturas de
dados.
Outro ponto forte presente no UMN Mapserver é a sua capacidade de comunicação com
inúmeras bases de dados, permitindo a integração/interoperabilidade de diferentes sistemas. Assim,
a utilização de UMN Mapserver como ambiente-base de desenvolvimento de um algoritmo de
análise espaço-temporal dinâmico se justifica com as funcionalidades citadas anteriormente, pois
atualmente nenhum outro aplicativo consegue prover tal ambiente de forma robusta, muito menos
de forma integrada. Assim, o desenvolvimento deste algoritmo torna viável a união entre a
estatística pesqueira e análise geoespacial, com potencial recurso de integração de distintas bases de
dados.
É sob este contexto de integração de tecnologias e métodos geoespaciais que reside, e se
justifica, a atividade proposta neste Projeto de Graduação. Encontram-se disponíveis para este
trabalho dados brutos de captura pesqueira que devem ser analisados através da ótica geoespacial.
De fato, existe a necessidade/demanda de tal enfoque junto ao GEP, o qual permitirá o surgimento
de uma nova gama de análises, aumentando a percepção da atividade pesqueira na costa brasileira.
O conhecimento adquirido pelo Laboratório de Computação Aplicada (LCA) sobre sistemas
de informação com suporte geoespacial permite que o assunto seja abordado sob a perspectiva
exploratória. Ou seja, não apenas se tratando da implementação de um sistema, mas sim da
prospecção e emprego de novas concepções metodológicas e tecnológicas.
1.1. OBJETIVOS
1.1.1. Objetivo Geral
O objetivo geral deste trabalho é desenvolver um algoritmo para análise espaço-temporal
dinâmica de dados de captura pesqueira e geração de mapas temáticos para visualização via web.
1.1.2. Objetivos Específicos
Os objetivos específicos deste projeto são:
• Pesquisar as análises passíveis de representação geoespacial de interesse específico
da indústria pesqueira;
• Definir, a partir do levantamento e junto aos pesquisadores do GEP, as análises
geoespaciais a serem representadas em mapas temáticos;
• Desenvolver a modelagem dos requisitos e funcionalidades necessários à realização
de consulta dinâmica por quadrantes ao banco de dados geoespacial;
• Desenvolver algoritmos para a geração de análises geoespaciais por quadrantes, a
partir do levantamento conduzido junto ao GEP;
• Integrar em um único aplicativo algoritmos necessários para o cumprimento dos
objetivos específicos, incluindo a visualização de cartas temáticas geradas, via web;
• Testar e validar os algoritmos desenvolvidos e o aplicativo e;
• Documentar o desenvolvimento do projeto.
1.2. METODOLOGIA
A metodologia utilizada neste TCC divide-se em: etapas pertinentes ao TCC I e etapas
referemtes ao TCC II.
O desenvolvimento do TCC, bem como sua fundamentação teórica, consiste na análise da
situação problema para permitir o desenvolvimento de métodos de análise espaciais aplicados sobre
dados de esforços de pesca. Para tal solução fez-se necessária a divisão do TCC por atividades, que
partiram desde a identificação do problema até a modelagem e implementação.
1.2.1. Etapas realizadas durante o TCC I
O estudo para a definição do problema para este TCC partiu do conhecimento de
especialistas do GEP e do LCA na identificação da dificuldade de realização de análises
geoespaciais sobre dados de recursos pesqueiros.
Partindo da necessidade constatada identificaram-se os objetivos a serem sanados, os quais
serviram de foco para a pesquisa realizada na fundamentação teórica. A fundamentação teórica
realizada durante o TCC I e presente neste texto está organizadas visando conter uma ordem
evolutiva de idéias de conceitos, abordando desde:
• Origem de dados geoespaciais;
• Construção de objetos geoespaciais;
• Padronização para objetos geoespaciais;
• Armazenamento em banco de dados para objetos geoespaciais;
• Análise de objetos geoespaciais, e;
• Tecnologias utilizas no desenvolvimento de SIG.
A modelagem do algoritmo proposto foi realizada aplicando-se os conceitos pesquisados
durante a fundamentação teórica e necessários para o cumprimento dos objetivos. A modelagem foi
realizada seguindo a metodologia Unified Modeling Language (UML) para especificação de
projetos em ciência da computação.
Portanto, as etapas realizadas durante o TCC I foram:
• Introdução ao problema;
• Identificação dos objetivos;
• Fundamentação teórica, e;
• Modelagem.
1.2.2. Etapas realizadas durante o TCC II
As etapas realizadas durante o TCC II encontram-se organizadas em:
• Desenvolvimento e implementação: etapa responsável pela implementação do
algoritmo proposto seguindo a modelagem definida durante o TCC I. Os
componentes identificados foram integrados a fim de provêr a base para o
desenvolvimento seguindo os conceitos identificados durante a fundamentação
teórica;
• Validação: etapa responsável pela execução dos testes necessários para a validação
do algoritmo. Os resultados dos testes realizados foram avaliados e repassados aos
especialistas do GEP, e;
1.3. ESTRUTURA DO TRABALHO
Este TCC encontra-se organizado através da seguinte estrutura: (i) introdução sobre o
problema observado e objetivos delineados; (ii) fundamentação teórica abordando os conceito
utilizados para a solução do problema e desenvolvimento da solução proposta através de análise
espacial; (iii) modelagem do sistema a fim de atender os objetivos e que permita a integração entre
os conceitos vislumbrados na fundamentação teórica; (iv) desenvolvimento e implementação da
solução; (v) conclusão e perspectivas sobre o TCC.
2. FUNDAMENTAÇÃO TEÓRICA
Este capítulo agrupa em tópicos as referências consideradas importantes para o estudo e
desenvolvimento deste Trabalho de Conclusão de Curso. Estão ordenados logicamente para que
cada item subseqüente seja complementar ao anterior, permitindo assim um encadeamento da linha
de pensamento que evolui ao modelo e implementação.
Desta forma a Seção 2.1 apresenta a introdução sobre dados e constituição de objetos
espaciais, sendo que sua padronização é contextualizada na Seção 2.2. A utilização de bancos de
dados espaciais está descrita através de suas arquiteturas na Seção 2.3, para que a sua utilização
permita a criação de objetos espacias. Já a análise destes mesmos objetos está descrita na seção
através de métodos apresentados na Seção 2.4. As ferramentas que permitam a visualização de
objetos espaciais, bem como os resultados de análise espaciais, através da internet são apresentados
na Seção 2.5.
2.1. DADOS GEOESPACIAIS
Segundo Günther (1998), antes de qualquer processamento de dados, computacionalmente
ou não, os dados de mundo real devem ser identificados e representados através de entidades ou
objetos associados ao tema de estudo, e que possam ser analisadas de modo a alterar a percepção
que se tem do geoespaço. Existem diversas formas de representação das entidades reais. As
civilizações antigas tentavam encontrar meios viáveis para representação e comunicação entre si.
Este é o caso das inscrições rupestres encontradas em diversas cavernas. Subseqüentemente, o
emprego de mapas passou a representar um importante aspecto no desenvolvimento da civilização
moderna, determinando o sucesso ou não dos detentores da habilidade de compreender e analisar as
entidades geográficas, ou atributos geoespaciais, notadamente presente nas conquistas oceânicas.
Com o advento do computador, a sociedade contemporânea se instrumentalizou com uma
gama maior de meios de representar e até mesmo analisar tais entidades, como é o caso do
sensoriamento remoto ou do sistema de informação geográfica. Adicionalmente, a utilização de
meio digital possibilitou que a troca de informação aumentasse consideravelmente, com isso a
forma como os dados estão armazenados e representados passou a ser de extrema importância para
que esse compartilhamento fosse possível.
Buscando uma padronização coerente de entidades reais, principalmente entidades
geoespaciais, surgiu a padronização Information Vierpoint do consórcio Open Gis Consortium
(OGC) (veja Seção 2.2) para representação geoespacial de dados em meio digital. Segundo
Percivall (2003) esse padrão concentra-se na representação semântica da informação geoespacial e
no seu processamento. Esse padrão define os esquemas conceituais para dados geoespaciais, além
de estabelecer os métodos para seu tratamento em aplicações. Os esquemas conceituais, ou de base,
são uma descrição formal do modelo de qualquer informação geoespacial. Os métodos responsáveis
pelo tratamento de dados geoespaciais são definidos através de modelos e esquemas construídos a
partir dos modelos conceituais (PERCIVALL, 2003). A representação corrente na área de
geotecnologias compreende feições geoespaciais, objeto geoespacial, e atributos e representação
geoespacial e metadados (Figura 2). Estes elementos são apresentados a seguir.
Feição Geoespacial (Observada e extraída do mundo real)
Objeto Geoespacial
Representação Geoespacial
Ponto Linha
Polígono Coordenadas
Atributos
Metadados
Satélite Sensor de Satélite
Ano Combinação de
bandas Tamanho de pixel
Algoritmo de tratamento da imagem
Figura 2: Representação esquemática do Objeto Geoespacial.
2.1.1. Feições Geoespaciais
Segundo Percivall (2003), o ponto inicial para a modelagem de dados geoespaciais são as
feições geoespaciais. Uma feição é uma abstração de qualquer fenômeno do mundo real. Já uma
feição geoespacial é associada a uma localização espacial no globo terrestre. A representação em
meio digital do mundo real pode ser constituída de um conjunto de feições. Estas fei’~oes podem
ser divididas em dois níveis:
• Features instances: são feições geoespaciais que representam um fenômeno
associado à coordenadas geoespaciais, e;
• Features types: são feições espaciais agrupadas por características comuns.
Ainda segundo Percivall (2003), qualquer feição pode ter um certo conjunto de
propriedades, que podem ser operações, atributos ou associações. Além disso, cada feição pode ter
um conjunto de atributos, que podem ser geométricos espaciais.
2.1.2. Objeto Geoespacial
Uma feição geoespacial não é definida como uma simples geometria, mas sim como um
objeto geoespacial, onde uma ou mais de suas propriedades ou atributos são geoespaciais
(PERCIVALL, 2003, p. 9). Ou seja, um objeto geoespacial é um composto de atributos,
representação geoespacial e, metadados como representado na Figura 2. Em geral, um objeto
geoespacial pode ser composto por um ou mais pontos espaciais (PERCIVALL, 2003, p. 13).
Segundo Percivall (2003) as características principais de tais objetos são:
• Apresentam um único indicador persistente para acesso, cada objeto é identificado
através de uma chave única;
• São compostos por atributos devidamente identificados por nome, tipo, valor, e
opcionalmente sua descrição e;
• Contém informação geoespacial.
2.1.2.1. Representação Geoespacial
A representação geoespacial fornece meios para uma descrição quantitativa, através de
coordenadas e funções matemáticas, das características geoespaciais da feição, incluindo dimensão
tamanho, forma, e orientação (PERCIVALL, 2003, p. 13).
As coordenadas são um conjunto de valores que definem a posição espacial de um simples
ponto em um sistema de coordenadas. São compostas de uma, duas, ou três ordenadas, onde estas
devem ser mutuamente independentes e seu número deve ser igual à dimensão do sistema de
coordenadas. Portanto, devem expressar grandezas geoespaciais distintas (PERCIVALL, 2003, p.
18).
Já um sistema de coordenadas é composto por um conjunto métrico conhecido de eixo de
coordenadas, apresentando assim o conceito de “espaço métrico de coordenadas”, que consiste em
um conjunto de regras matemáticas que definem as relações entre as coordenadas (PERCIVALL,
2003, p. 18).
No padrão (OPENGIS) o datum define a origem, orientação, e escala do sistema de
coordenadas associado à superfície da Terra, assegurando que a abstração métrica do sistema de
coordenadas possa ser utilizada para a solução de problemas existentes e na representação de pontos
da superfície terrestre (PERCIVALL, 2003, p. 18).
2.1.3. Elaboração do Objeto
Segundo Günther (1998) a criação do objeto geoespacial pressupõe quatro elementos
distintos:
1. Aquisição: esta etapa concentra-se em mapear e identificar as entidades que serão
utilizadas. A captura dos dados geralmente envolve a agregação, onde os dados
recolhidos são condensados na menor estrutura passível de representar a entidade.
2. Armazenamento: após a aquisição dos dados, a escolha pelo método de armazenamento
é utilizada para assegurar que os dados sejam armazenados na forma mais otimizada
para a leitura pelo sistema.
3. Análise: nesta etapa os dados armazenados são preparados e analisados para servir de
suporte para tomada de decisões. Geralmente a análise de objetos geoespaciais é
composta por complexos métodos estatísticos e de análise espacial.
4. Metadados: é um conjunto de informação sobre os dados. Segundo Percivall (2003)
metadados são dados sobre os dados, os quais visam dar consistência e perenidade à sua
existência.
2.2. OPEN GEOSPATIAL CONSORTIUM
O OGC é um consórcio internacional formado em agosto de 1994 pelas maiores empresas
de software do mundo, como Microsoft, Oracle, IBM e NASA, bem como por empresas de
hardware e universidades responsáveis por estudar e definir os padrões para armazenamento,
transmissão, visualização e manipulação de dados geoespaciais. Essa padronização, definida pelo
padrão OPENGIS, assegura que as análises desenvolvidas por diferentes sistemas sejam iguais, e
que haja a compatibilidade no compartilhamento de dados entre diferentes aplicativos (OGC, 2005).
O consórcio tem sob sua responsabilidade o gerenciamento do padrão OPENGIS, o que
inclui a sistematização e análise das propostas de padrões, bem como a eventual homologação dos
mesmos. A criação de tais especificações segue a mesma linha de procedimentos adotados pelo
padrão International Organization for Standardization (ISO), e inclui duas etapas associadas aos
seguintes documentos (OGC, 1999):
• Abstract Specifications: tem a finalidade apresentar uma especificação
conceitualmente viável para análise dos grupos de trabalho do OGC, e;
• Implementation Specifications: são as especificações aprovadas e homologadas pelos
grupos de trabalho, que passam a ser referência aos membros do consórcio, bem
como para quem aderiu ao padrão OPENGIS.
2.2.1. Documentação OGC
Além das especificações existem outros documentos providos pelo OGC. Através da leitura
destes documentos é possível acompanhar a evolução das especificações, as quais englobam as
últimas novidades de hardware, software e protocolos. Como exemplo pode-se destacar a evolução
constante da especificação do protocolo GML (Geography Markup Language).
Os documentos estão divididos em áreas:
• Adopted Document Baseline;
• OpenGIS® Specifications;
• Abstract Specifications;
• Recommendation Papers;
• Discussion Papers;
• Requests (RFP's, RFQ's...);
• OGC Reference Mode, e;
• Schemas.
2.2.2. OPENGIS Specifications
Os documentos de especificação (OpenGIS Specifications) são gratuitos, e podem ser
obtidos na página web do consórcio2. Segundo Crispino (2001) esses documentos encontram-se
divididos em três grupos:
• Open Geodata Model: especificações voltadas à representação e análise de dados
geoespaciais;
• Information Communities Model: especificações responsáveis por permitir troca de
dados geoespaciais, e;
• Services Architecture: especifica os serviços que possibilitam acesso e
compartilhamento de dados entre aplicativos.
2.3. BANCO DE DADOS GEOESPACIAIS
A utilização de sistemas gerenciadores de bancos de dados em sistemas de informação
geográfica surgiu da necessidade de armazenamento de grandes quantidades de dados, não somente
dados espaciais, mas também atributos não espaciais associados ao objeto geoespacial. Os primeiros
SIGs possuíam limitada capacidade de armazenamento, necessitando evoluir para comportar o
aumento da disponibilidade de dados geoespaciais. As mudanças que se seguiram para atender a
2 http://www.opengeoespatial.org
esta necessidade envolveram não somente a forma de leitura de tais dados, mas também a própria
lógica dos SIG. Assim surgiu o conceito de banco de dados geoespaciais, o qual é utilizado quando
os dados a serem armazenados possuem características espaciais, ou seja, possuem propriedades
que descrevem a sua localização no espaço e a sua forma de representação (SILVA, 2002).
O uso da geoinformação começou a tomar formar ainda na década passada com a
compreensão mais exata e o estabelecimento de padrões para tratamento de dados geoespaciais.
Segundo Silva (2002), as distinções existentes entre dados espaciais e dados não espaciais, que, até
então, eram considerados complexos para as estruturas de dados convencionais vigentes,
implicaram a necessidade de concepções diferentes para o processamento e armazenamento dos
mesmos. Por resultado estabeleceu-se que os bancos de dados geográficos devem permitir o total
controle sobre objetos geoespaciais, e meios de manipular eficientemente tais objetos. Para que esta
característica seja possível de ser agregada aos modelos existentes, muitos conceitos precisaram
mudar profundamente. Alterações necessitaram ser feitas em funções, armazenamento, leitura e
linguagens de consulta. Além disso, novos métodos chamados de indexação geoespacial foram
implementados especialmente para dados geoespaciais, como a indexação KD-tree, Quad-trees e R-
trees.
Na evolução que se seguiu, o armazenamento de objetos geoespaciais, através de bancos de
dados espaciais, passou a adotar dois tipos específicos de arquitetura (SILVA, 2002):
• Arquitetura dual, e;
• Arquitetura integrada.
As arquiteturas podem ser vistas como mecanismos de estruturação da informação. Já
modelos de dados são responsáveis por implementarem a estrutura lógica da arquitetura (SILVA,
2002).
Independente da arquitetura utilizada o conceito para armazenamento de dados geoespaciais
está ligado à capacidade dos sistemas de trabalharem com vários tipos do dado, sendo atributos
textuais ou geoespaciais.
2.3.1. Arquitetura dual
Como citado anteriormente, banco de dados geográficos divide-se em duas grandes
arquiteturas de organização, sendo que a primeira e mais antiga destas arquiteturas é a arquitetura
dual. Ela utiliza um Sistema Gerenciador de Banco de Dados (SGBD) relacional para armazenar os
atributos convencionais dos objetos geoespaciais, e arquivos para armazenar as representações
geoespaciais desses objetos, restando um identificador comum responsável por realizar a ligação
entre os atributos espaciais e os não espaciais, como representado pela Figura 3.
Figura 3. Exemplo de arquitetura dual
Fonte: Casanova (2005)
Esta arquitetura foi muito utilizada na elaboração dos primeiros sistemas, pois a sua
implementação não apresentava grandes dificuldades técnicas. Muitos sistemas ainda utilizam esta
arquitetura, como ARCINFO, ARCVIEW, MGE e SPRING. O padrão Shapefile (SHP), atualmente
difundido e usado como formato de troca entre diferentes organizações, consiste no formato mais
utilizado, demonstrando que esta arquitetura apresenta como principal vantagem à capacidade de
trabalhar com SGBD’s já existentes.
Para Casanova et al. (2005), esta arquitetura apresenta enormes desvantagens. Primeiro, ela
não garante o controle adequado dos dados geoespaciais, a integridade dos objetos geoespaciais.
Segundo, as consultas realizadas sobre esta arquitetura tornam-se lentas, pois são processadas
separadamente. Terceiro, apresentam como principal entrave à falta de interoperabilidade entre os
dados, pois cada SIG desenvolveu seu arquivo geoespacial sem seguir nenhuma padronização3,
dificultando a integração de dados oriundos de sistemas diferentes.
2.3.2. Arquitetura Integrada
Esta arquitetura se caracteriza pelo uso exclusivo do banco de dados para o armazenamento
de todos os dados dos objetos geoespaciais. Ou seja, o armazenamento de dados geoespaciais ocorre
no formato nativo do SGDB, junto com os atributos não espaciais. O próprio SGBD provê os
métodos de acesso e controle sobre todos os dados, cabendo assim ao SIG somente a manipulação
do objeto geoespacial.
Esta arquitetura se divide em duas estratégias: a integrada baseada em SGBD’s relacionais e
a integrada baseada em SGBD’s objetos-relacionais (CASANOVA et al., 2005). Silva (2002)
argumenta que estas estratégias diferem quanto à forma como os dados geoespaciais são associados
aos atributos não espaciais.
2.3.2.1. Estratégia baseada em SGBDS relacionais
Esta estratégia se baseia no uso de SGBD’s relacionais com suporte para campos longos4.
Fisicamente, o SGBD armazena em uma única tabela todos os atributos do objeto geoespacial. Esta
estratégia surgiu como primeira evolução frente à abordagem dual, e foi desenvolvida com o intuito
de sanar seus problemas.
As vantagens desta abordagem residem na capacidade de armazenamento de grandes objetos
geoespaciais, feito em um único local de todos os atributos do objeto geoespacial; o acesso a todos
os dados espaciais através de linguagem Structure Query Language (SQL); e o controle mais
efetivo e eficaz sobre a integridade dos dados. Esta forma de armazenamento também possibilita a
interoperabilidade entre sistemas, pois os dados estão armazenados em formato binário nativo do
próprio banco e não do SIG.
Apesar destas vantagens, esta arquitetura apresenta incapacidade de identificar e trabalhar
com a semântica do dado geoespacial. Também faltam métodos de tratamento de dados
armazenados em campo longo, e bem como limitações para a leitura dos registros, pois os dados em
campo longo são integralmente lidos (CASANOVA et al., 2005).
3 Esta situação contribuiu para o estabelecimento do Open Geospatial Consortium – OGC apresentado no item 2.2. 4 Um campo longo é uma cadeia binária de dados.
O banco de dados MySQL, e a extensão Spatial Data Engine (SDE) disponibilizada pela
ESRI5 para o ARC/INFO são exemplos desta arquitetura.
2.3.2.2. Estratégia baseada em SGBD’s objeto relacionais
A diferença entre esta estratégia e a baseada em SGBD’s puramente relacionais é a
capacidade de armazenar a informação geoespacial na forma de vetores, como objetos no banco de
dados. Por esta estratégia utilizar como base a arquitetura orientada a objetos, os objetos
geoespaciais e seus atributos espaciais podem ser armazenados diretamente em banco. Assim,
conceitos como polimorfismo, herança e agregação passaram a estar disponível para os objetos
geoespaciais.
Com o uso desta estratégia as características de cada objeto geoespacial passaram a serem
relevantes no esquema interno do banco. O armazenamento vetorial permitiu melhorias no
armazenamento, análise, recuperação e visualização dos dados, que passaram a ser implementadas
diretamente no banco de dados. Desta forma, um objeto geoespacial de forma poligonal apresenta
atributos e funções diferentes de objetos lineares, e estes, por sua vez, dos pontuais.
Além de agregar todas as vantagens da estratégia puramente relacional, esta apresenta
algumas características próprias (CASANOVA et al., 2005).
• Armazenamento de dados geoespaciais utilizando o conceito de orientação a objetos;
• Suporte a tipos geoespaciais complexos;
• Suporte a criação de novos tipos de dados, e;
• Funções geoespaciais armazenadas no próprio banco.
Alguns SGDB’s já fornecem esta capacidade de tratamento de dados geoespaciais através de
objetos. As iniciativas mais importantes ocorrem através do suporte geoespacial do Oracle Spatial,
para banco de dados Oracle, e o PostGis, para banco de dados PostgreSQL.
2.3.3. Acesso aos dados
Com a utilização de bancos de dados geoespaciais, as formas como os dados são acessados
também sofreram mudanças, independente da arquitetura adotada, dual ou integrada, métodos antes
5 Empresa especializada em soluções SIG.
existentes somente em banco de dados puderam ser utilizados para o acesso aos objetos
geoespaciais.
Segundo Casanova et al. (2005) as consultas aos objetos geoespaciais em bancos de dados
geográficos podem ser efetuadas através de mecanismos de seleção, sendo basicamente de dois
tipos:
• Atributos descritivos: a consulta realizada depende somente dos atributos não
geoespaciais do objeto geoespacial, e;
• Restrições geoespaciais: a consulta leva em consideração as relações geoespaciais
existentes entre os objetos geoespaciais.
Além destas formas de consultas aos dados, o modo como estes são apresentados ao usuário
também permite que novas características sejam abordadas. Abordagens estas que não seriam
possíveis sem a utilização de bancos de dados geográficos. Casanova et al. (2005) divide estas
formas de apresentação em:
• Combinação de resultados de consulta: capacidade de agrupar (somar) duas ou mais
consultas executadas separadamente;
• Controle dos objetos representados: capacidade de armazenar e recuperar uma
determinada consulta, e;
• Apresentação do contexto geoespacial: capacidade de apresentar somente os objetos
que atendem a uma determinada consulta.
2.3.4. PostgreSQL
O PostgreSQL é um Sistema Gerenciador de Banco de Dados Relacional (SGBDR), com
suporte a trigers, funções, procedures, e gerenciamento de diversos tipos de dados. Desenvolvido
inicialmente pela Universidade de Berckley, a partir de 1986, teve suas primeiras versões chamadas
de Postgres, quando ainda não apresentava suporte à linguagem SQL. Este suporte foi adicionando
em 1995, quando seu código-fonte foi disponibilizado sobre a filosofia GNU Project (GNU), ou
seja, passou a ser opensource6. Atualmente o PostgreSQL encontra-se na versão 8.0 com suporte
aos padrões SQL ANSI 92, 96, e 99, sendo considerado como o melhor banco de dados opensource
6 Seu código-fonte encontra-se disponível para download via web na página http://www.postgresql.org.
disponível (NETO PEREIRA, 2003, p. 25). No cenário atual, muitas empresas utilizam o
PostgreSQl como banco de dados padrão, com um consistente feedback sobre o seu estado de
desenvolvimento.
O PostgreSQL alcançou esta reputação por ser extremamente robusto, estável e seguro, e por
seguir o padrão ANSI SQL para interpretação da linguagem e do modelo relacional dos dados. Uma
de suas grandes vantagens é a sua dinamicidade, que permite a criação e manipulação de novos
tipos de dados, linguagens pré-compiladas, como C, C# e Java. Permite ainda que novos módulos
sejam adicionados a ele, sem perda de performance.
2.3.4.1. PostGIS
É através do PostGIS que o suporte a manipulação de dados geoespaciais é provido ao
PostgreSQL. Pelo fato do próprio banco suportar orientação a objetos, o PostGIS é considerado
como banco de dados geoespacial de arquitetura integrada e estratégia objeto relacionals. É um
módulo de extensão ao PostgreSQL, acoplado diretamente ao servidor (REFRACTIONS
RESEARCH, 2005).
O módulo de extensão PostGis não vem como padrão no código-fonte do PostgreSQL,
sendo necessário compilá-lo. O módulo é desenvolvido pela equipe da Refractions Research Inc,
sediada no Canadá, e especializada na integração de dados com sistemas sob demanda.
2.3.4.1.1. Armazenamento Geoespacial
Internamente, o PostGis utiliza o padrão definido pela OGC para a manipulação de dados
espaciais, Simple Features Specifications for SQL, que define o padrão para armazenamento,
manipulação e gerência de objetos espaciais por qualquer banco de dados (REFRACTIONS
RESEARCH, 2005).
Por seguir o padrão OGC e por estar baseado no PostgreSQL, o módulo PostGis suporta a
criação de novos tipos de dados geoespaciais, armazenamento de objetos espaciais complexos,
criação dinâmica de índices espaciais, funções espaciais no próprio banco.
O padrão OGC define duas maneiras para o armazenamento espacial dos dados, o
armazenamento através de Well-Know Binary (WKB) e Well-Know Text (WKT). Ambos são
suportados pelo PostGIS. Devido a esta característica, o PostGis pode ser utilizado como um banco
de dados com estratégia relacional ou objeto relacional, conforme a necessidade do usuário.
O armazenamento dos dados geoespaciais no banco de dados segue o mesmo padrão OGC
que especifica os objetos geoespaciais. Segundo Refractions Research (2005) esse padrão define as
formas necessárias para o manipulação e armazenamento dos dados geoespaciais através do uso de
tabelas de metadados. No PostGIS existem duas tabelas para este fim:
• Spatial_Ref_System: tabela utilizada para armazenar as definições dos sistemas de
coordenadas suportadas pelo banco. É utilizada por algumas funções para ter acesso
rápido para as definições do sistema de coordenada utilizada pelo objeto geoespacial,
e;
• Geometry_Columns: tabela utilizada para o armazenamento das definições do objeto
geoespacial. Nesta tabela fica armazenado o tipo do objeto espacial, a tabela a qual
pertence, o usuário a qual pertence, o número de grandezas utilizadas no objeto, e o
identificador do sistema de coordenada utilizado.
Estas duas tabelas compõem o núcleo do PostGIS. Qualquer tabela utilizada para armazenar
dados espaciais apresentará uma coluna específica para dados espaciais, responsável por armazenar
os atributos espaciais do objeto. O núcleo do módulo executa de forma automática uma integração
entre os dados armazenados e as definições do objeto a cada requisição.
2.3.4.1.2. Consulta Geoespacial
As consultas geoespaciais realizadas sobre os dados geoespaciais são definidas através do
padrão SQL definido pelo OGC para dados geoespaciais. Pode-se utilizar qualquer sintaxe presente
no padrão SQL 92 para pesquisar e restringir dados espaciais através de atributos não espaciais
(REFRACTIONS RESEARCH, 2005). Para executar restrições sobre dados espaciais existem
operadores específicos. A definição dos operadores pode ser encontrada no manual do usuário do
PostGIS.
2.3.4.1.3. Indexação Geoespacial
Desenvolvida no PostGIS com o intuído de agilizar as pesquisas geoespaciais, evitando que
o banco de dados PostgreSQL execute uma pesquisa seqüencial em todos os registros. A indexação
no PostgreSQL, e conseqüentemente pelo PostGIS pode ser feita de três maneiras (REFRACTIONS
RESEARCH, 2005):
• B-Trees: é o índice utilizado quando os dados estão dispostos através de eixos. Este
tipo de índice utiliza árvores binárias para realizar seus cálculos, não sendo utilizado
para dados geoespaciais, mas para os identificadores únicos de cada objeto
geoespacial.
• R-Trees: quebra os dados geoespaciais dividindo-os nos menores retângulos
passíveis de armazenar objetos geoespaciais. Infelizmente a implementação deste
índice para dados geoespaciais não é robusta o suficiente para apresentar uma
performance razoável.
• GIST (Generalized Search Trees): este tipo de índice agrupa os dados através de
suas inter-relações geoespaciais. Os dados podem ser organizados através de relações
como o que esta perto do que?, o que toca em quem?, ou quem esta inserido em
quem?. É o tipo de índice que apresenta a melhor performance sobre dados espaciais
Segundo Refractions Research (2005) o módulo PostGIS utiliza para objetos espaciais
índices do tipo R-Tree sobre dados indexados através de GIST.
2.3.5. Oracle
Segundo Sarin (2000), o servidor Oracle é um sistema gerenciador de banco de dados objeto
relacional que fornece uma abordagem aberta, abrangente, e integrada para o gerenciamento de
informações. Um servidor Oracle consiste em um banco de dados Oracle e uma instância do
servidor Oracle. Este SGBD é mantido pela Oracle Corporation, empresa especializada em banco
de dados.
A partir desta arquitetura o Oracle permite entre inúmeras características uma arquitetura
cliente servidor, segurança gerenciável, integridade de dados, portabilidade, replicação, e sistemas
distribuídos.
O Oracle encontra-se na versão 10G e pode ser obtido através da página da Oracle
Corporation: www.oracle.com. É disponibilizado através de licença de uso e por número máximo
de usuários conectados. Para acadêmicos, o Oracle pode ser obtido gratuitamente para fins
educacionais e desenvolvimento.
Para permitir a iteração entre o usuário o Oracle disponibiliza o acesso aos dados através do
padrão SQL, todas as definições presentes nesse padrão são suportadas pelo SGBD. A SQL
implementada pela Oracle Corporation é compatível com a linguagem de dados SQL padrão
ANSI/ISO (SARIN, 2000).
A estrutura interna do Oracle é dividida em duas formas: uma estrutura física e outra lógica.
A estrutura física corresponde aos dados do próprio aplicativo, e a estrutura lógica é composta pelos
arquivos responsáveis pelo armazenamento dos dados dos usuários.
Para permitir um acesso coerente e rápido aos dados, o Oracle implementa diversos tipos de
indexação: árvores binárias, árvores R, índices bitmap e, índices hash. Os índices são independentes
dos dados tanto física quanto logicamente, podendo ser criados e destruídos a qualquer momento
sem nenhum reflexo aos dados (SARIN, 2000). Na versão mais atual do banco de dados os índices
são utilizados internamente pelo SGBD durante qualquer consulta realizadas sobre os dados
armazenados.
Diferentemente da organização adota por outros SGBDS como o MySQL, o Oracle é
organizado através de multi-processos, isto quer dizer que quando uma instância do Oracle é
iniciada existem mais de um processo associado à mesma. Os processos associados ao Oracle
podem ser divididos em duas categorias: processos de servidor e processos de segundo plano.
2.3.5.1. Oracle Spatial
Segundo Murray et. al. (2003) Oracle Spatial é um conjunto de funções e procedimentos que
permitem o armazenamento, acesso, e análise de dados espaciais através do banco de dados Oracle.
Ainda segundo Murray et. al. (2003) o Oracle Spatial pode ser dividido nos seguintes componentes:
• Um esquema chamado MDSYS responsável por prover o armazenamento, sintaxe, e
semântica para armazenamento de tipos geométricos;
• Sistema de indexação espacial;
• Operadores e funções responsáveis por realizar a pesquisa e manipulação de dados
espaciais, e;
• Funções administrativas.
O armazenamento dos dados espaciais é realizado através do modelo objeto relacional,
implementando a estratégia de SGBD objeto relacional. O armazenamento e tratamento dos dados
espaciais seguem o modelo definido pelo OGC (Murray et. al., 2003).
2.3.5.1.1. Armazenamento espacial
Para a implementação da estratégia objeto relacional os objetos geoespaciais podem ser
armazenados em qualquer tabela que apresente uma coluna do tipo SDO_GEOMETRY e com uma
chave única de identificação. Sendo realizado o acesso à coluna do tipo SDO_GEOMETRY através
de consultas puramente relacionais, mas internamente o banco de dados faz referências aos objetos
geoespaciais (veja Seção 2.3.5.1.2).
Objetos com diversos tipos de representações geoespacial podem ser armazenados, inclusive
permitindo a criação de novos tipos. Os padrões disponibilizados pelo esquema podem ser pontos,
linhas, arcos, polígonos compostos, linhas compostas, círculos, e retângulos otimizados. A
definição de cada tipo de dado pode ser encontrada no manual do usuário do Oracle Spatial.
2.3.5.1.2. Representação Geoespacial
O objeto espacial utilizado pelo esquema Oracle Spatial para armazenamento é organizado
hierarquicamente em elemento, geometria, e camada (layer). Segundo Murray et. al. (2003) um
elemento é a estrutura básica que suporta o objeto espacial interno no banco. Este elemento pode ser
de três tipos: pontos, linhas e polígonos. Geometria ou objeto geométrico é a representação espacial
do objeto através dos tipos básicos possíveis para os elementos. Uma geometria pode ser composta
por um ou mais elementos.
Segundo Silva (2002) uma layer corresponde a uma tabela que contêm uma coluna do tipo
espacial, onde uma geometria corresponde a cada linha desta tabela. Segundo Murray et. al. (2003)
uma layer é um conjunto de geometrias que apresentam os mesmos atributos.
Além destes atributos básicos do objeto outros são necessários para completar o objeto
geoespacial conforme os padrões estabelecidos. Todo o objeto geoespacial, no esquema Oracle
Spatial, está associado a um sistema de coordenadas. Isso é necessário, pois dependendo do sistema
de coordenadas alguns cálculos especiais devem ser realizados sobre os objetos, tais como projeção.
É a partir da correta definição do tipo de sistema de coordenadas utilizada que a qualidade
sobre os dados pode ser provida. Utilizando um padrão adequado para o sistema de coordenadas o
próprio esquema interno do banco irá realizar o controle espacial sobre os dados manipulados. O
Oracle Spatial irá automaticamente caso seja necessário, converter, e gerenciar os dados
corretamente entre o sistema de coordenadas utilizadas, sem que este trabalho seja implementado
pelo usuário.
Como citado anteriormente, os dados espaciais são armazenados através do objeto
SDO_GEOMETRY definido como tipo de coluna de qualquer tabela do usuário. Esse objeto é
definido com os atributos: SDO_GTYPE responsável por definir o tipo de geometria armazenada
pelo objeto; SDO_SRID armazena o identificador do tipo de sistema de coordenada utilizada;
SDO_POINT é outro objeto responsável por armazenar as grandezas X, Y e Z de um ponto, sendo
esse somente utilizado quando tipo do dado for ponto; SDO_ETYPE é o atributo responsável por
armazenar as relações necessárias para a interpretação dos dados espaciais; SDO_ORDINATES é o
responsável por armazenar as coordenadas do objeto espacial.
2.3.5.1.3. Pesquisa Espacial
O Oracle Spatial utiliza dois modos internos na realização de suas pesquisas espaciais.
Segundo Murray et. al. (2003) esses podem ser:
• Filtro primário: permite realizar pesquisas rápidas sobre os dados armazenados no
banco através de comparações ente a geometria da pesquisa e as geometrias
armazenadas, e.
• Filtro secundário: realiza comparações entre as relações dos dados espaciais
retornados pelo filtro primário com os dados existentes na consultas.
A escolha entre o tipo de pesquisa espacial realizada pode ser definida pelo usuário em
tempo de execução através das funções utilizadas na pesquisa. Um ponto interessante a ser
destacado é que os tipos de relações utilizadas no filtro secundário também podem ser definidos
pelo usuário.
Figura 4. Relações entre os tipos de pesquisa espacial
Fonte: Murray (2004)
2.3.5.1.4. Indexação Espacial
Para prover melhor desempenho no momento da pesquisa aos dados espaciais o Oracle
Spatial provê duas formas distintas de indexação. Por ser um esquema fortemente associado ao
banco de dados, o índice espacial trabalha com as mesmas tabelas internas do banco para realizar
seus cálculos de estimativas.
Segundo Murray et. al. (2003) a indexação espacial do Oracle Spatial existe para:
• Encontrar os objetos em um espaço indexado que se relacionam com um ponto de
interesse, e;
• Encontrar pares de objetos que estejam em um espaço indexado, definido por
marcadores espaciais.
Um índice espacial é considerado como um índice lógico, e os atributos internos do índice
são dependentes da localização espacial do objeto geoespacial no sistema de coordenadas. Segundo
Murray et. al. (2003) o índice espacial é a base para a realização da indexação geoespacial.
O índice espacial pode ser de dois tipos:
• R-tree: este tipo de índice considera como base para análise o menor retângulo que
envolve cada geometria no banco. Este tipo de índice permite o acesso mais rápido
aos dados. Este índice implementa o conceito de pesquisa por Minimum Bounding
Rectangle (MBR), e;
• Quad-tree: esta forma de indexação visualiza o ambiente onde os dados estão
inseridos em pequenos blocos. O tamanho de cada bloco pode ser fixo ou variável
para todo o ambiente. Por depender de um parâmetro pré-definido para o tamanho
este índice necessita ser constantemente atualizado para refletir a atual citação do
banco Este índice implementa o conceito de pesquisa através de Tesselation.
Segundo Murray et. al. (2003) na última versão do Oracle Spatial não se recomenda o uso
de índices do tipo Quad-tree, pois o núcleo interno do Spatial sofreu melhorias que dispensam o uso
deste tipo de índice.
2.3.5.1.5. Operadores Espaciais
O Oracle Spatial provê diversos operadores e funções espaciais, disponíveis a qualquer
usuário, permitindo que pesquisas espaciais mais refinadas possam ser elaboradas.
Segundo Murray et. al. (2003) operadores espaciais permitem pesquisas otimizadas
espacialmente porque internamente utilizam índices espaciais como base. Também possibilitam
uma melhor performance, pois permitem que o usuário restrinja o campo espacial onde a pesquisa
será realizada.
Funções espaciais são funções ou procedimentos escritos em linguagem própria para
manipulação e retorno de objetos espaciais. Podem ser utilizadas tanto em cláusulas restritivas
como em subconsultas. Apresentam uma performance não tão boa quanto à dos operadores, pois
não utilizam índice espacial mesmo que este esteja definido para o objeto espacial.
Segundo Murray et. al. (2003) os principais operadores espaciais são:
• SDO_FILTER;
• SDO_JOIN;
• SDO_NN;
• SDO_NN_DISTANCE;
• SDO_RELATE, e;
• SDO_WITHIN_DISTANCE.
Tanto operadores como funções espaciais podem ser utilizados de maneira conjugada.
Operadores podem ser empregados para restringir o espaço de análise antes da utilização de uma
função espacial.
Muitos softwares utilizam o Oracle Spatial como base de dados espacial, podemos citar
ArcSDE/ArcInfo, Spring, e UMN Mapserver.
2.4. ANÁLISE ESPACIAL
Segundo Carneiro e Santos (2003) a análise espacial pode ser definida como uma técnica
que busca descrever padrões existentes nos objetos geoespaciais, e estabelecer, preferencialmente
de forma quantitativa, os relacionamentos entre as diferentes variáveis geográficas. Em termos
tecnológicos, tais análises dispõem de um variado arsenal de ferramentas computacionais que
permitem que análises cada vez mais complexas sejam desenvolvidas com objetos geoespaciais.
Dentre estas ferramentas se destacam os sistemas de informação geográfica, que desde décda de
sessenta vem se estabelecendo, primeiramente no meio científico, e posteriormente, comercial.
Segundo Meaden e Chi (1996) as funções de análise providas pela maioria dos SIGs
trabalham tanto com os atributos geoespaciais ou não do objeto geoespacial. Geralmente os
resultados obtidos pelas análises espaciais permitem observar e determinar se os eventos contêm
algum padrão sistemático ou relacionamento, ao invés de estarem distribuídos aleatoriamente.
Dentre as análises mais comuns, destancam-se (MEADEN e CHI, 1996):
• Conectividade: são análises aplicadas para determinar como os objetos geoespaciais
estão conectados ou como se relacionam. Essas análises consideram relações como
custo ou tempo;
• Proximidade: permitem determinar e indicar a distância entre os objetos, ou mostrar
os níveis adjacência entre objetos vizinhos. Como exemplo pode-se citar a análise
através de buffer;
• Modelos digitais: análise que permite traçar um modelo, geralmente 3D, dos objetos,
e;
• Localização: são análises responsáveis por identificar a localização exata onde
ocorreu o evento.
As análises espaciais são geralmente providas de duas maneiras pelos SIGs: diretamente
pelo Kernel do aplicativo ou através de métodos acessíveis. Normalmente a segunda alternativa é
disponibilizada através de linguagens específicas, como ARC Macro Language (AML) da ESRI
(GÜNTHER, 1998, p. 141).
2.4.1. Estatística Geoespacial
Segundo Meaden e Chi (1996) uma grande variedade de análises geoespaciais provêem
inúmeras funções estatísticas. Usualmente, tais análises não são fornecidas pelo SIG, mas por
pacotes específicos que são utilizadas para descrever medidas de precisão, freqüência, ou medidas
de dispersão baseadas na dimensão geoespacial da análise, e na representação desejada para os
resultados.
Segundo Bailey (1994) os métodos de análise geoespacial comumente utilizados são:
• Variogramas: método que representa quantitativamente a variação e ocorrência de
um evento geoespacial;
• Krigagem: método que utiliza pesos associados aos objetos geoespacial, podendo ser
atribuidos através de várias métricas;
• Correlações Espaciais: método que utiliza as relações existentes entre os objetos
geoespacias para a realização da análise;
• Funções Baesianas: métodos que utilizam o teorema de Bayes para análise espacial
através de suas características locais e por correlações entre seus atributos;
• Análise por método K: método que explora a localização espacial da ocorrência de
um evento geoespacial, utilizando métodos para comparação evento por evento.
Método utilizado para análise de dados pontuais e representação precisa através de
mapas de isolinhas, e;
• Análise pelo método Kernel: método que utiliza um grid sobre a área desejada,
permite analisar quantitativamente a ocorrência de um evento em uma determinada
área, além de permitir a comparação entre diferentes áreas ou entre a mesma área em
períodos diferentes. Permite a análise de dados pontuais.
2.4.1.1. Análise de Padrões Pontuais
Os padrões pontuais consistem em um conjunto de dados que compreendem uma série de
localizações pontuais, as quais indicam a ocorrência de eventos de interesse em uma área de estudo
(CÂMARA et al., 2001 apud KREMPI, 2004). Para Krempi (2004) o objetivo da análise
geoespacial através de pontos consiste na verificação da existência de algum tipo de padrão
sistemático ou aleatório de eventos, buscando determinar em qual escala ele ocorre.
2.4.1.1.1. Método Kernel
Segundo Carneiro e Santos (2003), a estimação por Kernel para análise pontual é um
método freqüentemente utilizado em diversas áreas de pesquisas, especialmente em banco de dados
geo-referenciados. O método Kernel apresenta ainda como objetivo analisar o comportamento de
padrões pontuais, ajustando uma função dimensional sobre os eventos considerados, sendo muito
útil para mostrar uma visão geral da distribuição de primeira ordem dos eventos (KREMPI, 2004).
Segundo Bailey e Gatrell (1995) o método Kernel foi desenvolvido inicialmente para
obtenção de uma estimativa suavizada da probabilidade de ocorrência de eventos observados, em
outras palavras, um histograma suavizado. Ainda segundo Bailey e Gatrell (1995) a estimação
através do método Kernel pode ser facilmente aplicada em cálculos para identificar a intensidade de
ocorrência do evento.
Tendo s representando uma localização em qualquer região R e s1,...,sn sendo a localização
de n eventos, então a intensidade, λ(s), sobre s pode ser calculada através da Equação 1. Onde k() é
uma função que se enquadra para uma análise bivariada de probabilidade sobre a densidade,
conhecida como kernel, a qual é simétrica em relação a origem. O parâmetro t, utilizado com a
relação t > 0 é conhecido como bandwidth e determina o quanto de suavização. Essencialmente é o
raio de um disco centrado em s com si pontos, que contribui significativamente para o cálculo de
λt(s) (BAILEY e GATRELL, 1995).
ii
n
i
t yt
ssks
−=∑
=
1
λ Equação 1
A Figura 5 demonstra como o método Kernel realiza a análise através de um cone sobre os
eventos ocorridos, utilizando como curva a função k() onde o bandwidth define a largura máxima
até onde os eventos são considerados para o cálculo.
Figura 5: Curva de análise do método
Fonte: Bailey e Gatrell (1995)
A Figura 6 apresenta a curva utilizada para estimar o peso do evento sobre a posição
estimada s, quanto mais próximo esta se encontrar da origem maior será o seu valor durante a
análise. Já eventos que ocorram no limiar da distância apresentam o peso baixo e pouco influenciam
no resultado do cálculo.
Figura 6: Curva para a distância definida.
Fonte: Bailey e Gatrell (1995)
O volume dentro da curva para Kernel centrado em s define quais os eventos que
provavelmente não esteja dentro de R. Sendo que para qualquer Kernel ou bandwidth escolhido,
valores de λt(s), podem ser examinados como localizações em um grid definido sobre R para
disponibilização de uma indicação visual da variação da intensidade, λt(s), sobre a área de estudo
(BAILEY e GATRELL, 1995).
Segundo Bailey e Gatrell (1995) na prática, o valor da estimação Kernel pode ser calculado
com diferentes valores de t, explorando assim toda a superfície de λt(s) utilizando diferentes graus
de suavização para observação da variação de λt(s) em diferentes escalas.
Ainda segundo Bailey e Gatrell (1995) existem vários métodos que procuram otimizar o
valor de t através da observação dos padrões da disposição dos eventos. Ajustando o valor de t
localmente para diferentes pontos de R na tentativa de aperfeiçoar a estimativa Kernel. Em áreas
onde a ocorrência de eventos é mais freqüente uma informação mais detalhada sobre a variação da
intensidade pode estar disponível. Isso permite que, localmente, para estas regiões um valor menor
para bandwidth t pode ser mais apropriado para evitar uma suavização com muitos detalhes. Em
outras palavras, definindo um bandwitdth apropriado para áreas esparsas, o mesmo t pode
obscurecer o retorno dos detalhes em áreas densas.
Como citado anteriormente o método Kernel permite calcular uma estimativa da densidade a
partir de uma amostra de dados. Para realizar esta tarefa, o método gera uma grade em que cada
célula representa o valor da intensidade, densidade e razão entre os atributos, considerados
individualmente ou em conjunto (CARNEIRO e SANTOS, 2003).
O método Kernel utiliza métodos para a pesquisa de vizinho mais próximo na grade gerada.
Nesta os pontos de referência para a busca de vizinhos são determinados pela grade sobre a região
de estudo. Cada nó da grade é analisado até que todos tenham sido percorridos. Conseqüentemente,
parte da eficiência da análise está ligada ao mecanismo de busca de vizinhos mais próximos, os
quais foram agrupados por Carneiro e Santos (2003) em:
• Busca Exaustiva;
• Hashing e Indexação;
• Particionamento estático do espaço;
• Particionamento dinâmico do espaço, e;
• Algoritmos aleatorizados;
Considerando este modo de operação, a função do método Kernel consiste, na realidade, de
um interpolador do valor encontrado em cada célula da grade. Este valor é obtido a partir de uma
função simétrica, a qual realiza o cálculo até uma certa distância do centro da célula.
O método Kernel pode ser aplicado sobre uma área de estudo através de diversas técnicas.
Teoricamente cada área deveria ter seu próprio fator de kernel e bandwidth para retornar o máximo
de informação possível, infelizmente ainda não existem métodos capazes de realizarem tais ajustes
para cada área da análise por demandar diversas iterações do método até encontrar um fator
condizente. Muitas vezes cabendo ao usuário a definição do fator desejado. (BAILEY e GATRELL,
1995).
2.4.2. Estatística Pesqueira
Segundo Meaden e Chi (1996) sistemas de estatística pesqueira são a melhor maneira para o
auxílio no controle pesqueiro. A situação dos estoques de pesca é controlada de forma mais
coerente através da gerencia estratégica definida com base em análises e projeções estatísticas, que
incluem, por exemplo, medidas para esforço associadas ao:
• Tamanho do peixe pescado: permite identificar qual a média do tamanho do peixe
retirado do estoque;
• Quantidade pescada por tempo: identifica qual a relação entre o que foi extraído e o
tempo empregado para a exploração;
• Quantidade por esforço de pesca: permite identificar a relação entre a quantidade
pescada e o número de eventos de pesca em determinada área de estudo, e;
• Custo operacional por quantidade pescada: identifica qual o custo para a extração de
determinada quantidade.
É importante ressaltar que tais medidas dependem exclusivamente dos dados
disponibilizados para análise. Eles delimitam os resultados possíveis, o que por si só representa um
empecilho ao bom desempenho das medidas de gestão dos recursos. Além disso, a complexidade
relacionada ao próprio ambiente marinho, devido à sua dinamicidade, pode gerar um grande grau de
incerteza. A redução da incerteza vem sendo abordada através do mapeamento das variáveis que
apresentam influência sobre a distribuição e abundância das espécies, sendo três os tipos de mapas
atualmente empregados para este fim (MEADEN e CHI, 1996):
• Dot Map: os objetos geoespaciais que estão inclusos no mapa são representados
utilizando-se somente pontos como entidade representativa;
• Choropleth Map: os objetos geoespaciais estão divididos através de células, onde
cada uma apresenta, baseado nos atributos da célula, uma densidade em sua
coloração de preenchimentos e;
• Isoline Map: esta forma de representação apresenta uma divisão por áreas no mapa
baseada na densidade em que os objetos geoespaciais ocorrem no mapa. Criando
assim limites curvilíneos para a ocorrência dos objetos geoespaciais;
A Figura 7 apresenta um exemplo da representação das três formas possíveis citadas acima
para a mesma área de seleção.
Figura 7: Classificação dos tipos de mapas.
Fonte: Meaden e Chi (1996)
Segundo Meaden e Chi (1996) de um ponto de vista prático, SIGs para pesca usam
geralmente as técnicas isoline ou celular para definição de seus mapas. Entretanto segundo Meaden
e Chi (1996) a primeira técnica é utilizada para mapear os esforços de pesca através de sua
densidade, mas é difícil qualquer estatística sobre esse método.
A escolha por dividir o ambiente em um grid por células quadrangulares é segundo Meaden
e Chi (1996) a melhor forma para análise estatística de dados pesqueiros. A escolha por tais células
está relacionado ao fato de serem ótimas para cálculos de vizinhança, na realidade os algoritmos
que as utilizam podem analisar qualquer diversos tpos de dados (MEADEN e CHI, 1996).
Como citado anteriormente, dados de pesca apresentam uma dinamicidade intrínseca e isso
ocasiona, segundo Meaden e Chi (1996), uma pobre resolução temporal. Por exemplo, um mapa de
pesca fica rapidamente antigo se este não suportar a iteração por tempo de ocorrência.
Portanto, segundo Meaden e Chi (1996) para que um mapa de análise estatística pesqueira
seja preciso, o SIG que o provê deve suportar a visualização e análise de dados através de períodos
de tempo. Dessa forma é que mapas gerados por tais sistemas deixam de ser estáticos e atemporais e
passam a refletir informações de um período de tempo.
Ainda segundo Meaden e Chi (1996) outro fator é de extrema importância, as escalas
utilizadas no grid, o nível de detalhe utilizado, interferem na qualidade da análise. É a escala que
define o nível de precisão em que a análise é gerada. A escolha de uma escala coerente viabiliza
uma melhor compreensão da área analisada e auxilia ao especialista na validação do resultado
estatístico.
Um ponto importante está relacionado ao fato do tamanho da base de dados dos pontos de
esforço e captura de pesca se tornar imensa, gerando grandes problemas no momento da análise
geoespacial dos dados. Segundo Meaden e Chi (1996) SIGs utilizam a divisão do espaço a ser
analisado em áreas de interesse para reduzir e restringir os eventos dentro do universo.
Ainda segundo Meaden e Chi (1996) o espaço a ser analisado pode ser dividido seguindo
alguns padrões, geralmente, a posição espacial onde o ponto de coleta encontra-se pode ser
considerado um fator restritivo.
O controle sobre esforços e capturas de pesca vem segundo, Meaden e Chi (1996), de
inúmeras razões. A razão mais obvia é pelo simples fato de manter os estoques em um nível
sustentável de exploração. O controle também se torna necessário para evitar uma competição
desenfreada por somente poucas áreas de pesca.
Tal nível de controle é válido e necessário do ponto de vista econômico, pois assegura uma
distribuição equilibrada dos recursos. Do ponto de vista social, o controle assegura que as pequenas
comunidades de pescadores possam ser mantidas, além dessa forma de controle proteger a saúde da
população (MEADEN e CHI, 1996, p. 165).
2.4.2.1. Gradiente de cores
Um gradiente de cores é composto basicamente por progressão de cores onde uma transição
destas é observada, podendo ser suave ou não. Existem inúmeros esquemas de cores que podem ser
utilizados para a elaboração de tal gradiente, geralmente são elaborados para fins específicos. Como
exemplos da utilização de gradiente de cores para expressão de grandezas ou visualização temos:
luminosidade, temperatura, densidade e, saturação.
A Figura 8 apresenta alguns exemplos de transição de cores que podem ser utilizados em
gradientes.
Figura 8: Exemplo de gradiente.
Em SIG’s os gradientes de cores são utilizados através de mapas temáticos para representar
informações sobre relações entre diversos atributos dos objetos geoespaciais, possibilitando uma
melhor compreensão do ambiente e facilitando a análise por parte do especialista. Como exemplos
de usos existem: a representação da densidade populacional, elevação de terrenos, dentre inúmeras
outras finalidades.
2.5. WEB MAPPING
A utilização de ferramentas para o auxílio na navegação web remonta desde o início da
Internet, os desenvolvedores sempre buscaram maneiras de permitir que o usuário consiga encontrar
o que deseja.
Com a explosão do número de usuários conectados em rede, outras formas de pesquisa
foram desenvolvidas, como ferramentas de busca que vasculhavam a Internet atrás de qualquer
informação. A partir da evolução destes conceitos permitiu-se ao usuário encontrar o que desejava e
onde tal informação pode ser encontrada.
O conceito que define Web Mapping é um conjunto das definições citadas acima, a
capacidade que o usuário tem de navegar através das informações disponíveis e de localizar
espacialmente onde tal está localizada. A diferença entre a navegação tradicional através de links e a
navegação através de mapas é o tipo da informação utilizada como base.
No uso de mapas as informações espaciais, marcos espaciais são utilizados como forma de
referência para auxilio na navegação, e podem ser de diversos tipos: pontos, linhas, e polígonos.
Também podem ser abstratos como códigos postais e telefones. A definição dos marcos espaciais
refletirá no tipo de informação disponibilizada.
No uso de mapas para a Internet o detalhe mais importante a ser analisado é a informação
que se deseja expressar. O contexto ao qual o resultado está inserido deve ser muito bem definido
para que o usuário possa assimilar tal informação. Segundo McCurley (2001) o contexto é baseado
em entidades representadas.
Em Web Mapping, o usuário, além de navegar pelo mapa, pode também escolher quais
informações deseja consultar, esta capacidade que torna esse conceito interessante. O usuário pode
gerar as mais diversas associações entre os dados sem que estas sejam previamente implementadas.
Por exemplo, o usuário pode associar ao resultado de sua pesquisa uma imagem de satélite sem que
essa esteja inclusa por padrão no resultado.
A forma padrão utilizada para possibilitar a interação no mapa por parte do usuário é a
navegação espacial através de requisições, disponibilizando ao usuário diversas funcionalidades,
como: a mudança de escala de visualização dos objetos, navegação (sem mudança de escala) pelo
mapa, pesquisa de objetos geoespaciais e, a análise os dados retornados. Essas seriam as
características importantes relacionadas com Web Mapping, permitindo que mapas sejam entregues
sobre demanda ao usuário.
Dentre as características listadas as desejáveis em qualquer sistema Web Mapping são:
• Visualização: o usuário pode escolher quais as informações que deseja visualizar,
quais dados devem ser expressos no mapa e;
• Navegação: o usuário pode navegar espacialmente através do mapa, aproximar,
afastar, movimentar, sua visualização dos dados.
O desenvolvimento de sistemas Web Mapping pode ser aplicado nas mais diversas áreas, e
são essas que definem quais as características que podem ser adicionadas além da navegação e
visualização.
O uso de SIGs com interface Web Mapping adiciona uma característica específica, a análise
espacial sobre os dados. Através de requisições do usuário resultados das análises podem ser
entregues através de mapas.
Agora, além da simples visualização de dados, o usuário pode também analisar
espacialmente os dados. Encontrando relações que seriam difíceis de serem observadas através de
simples dados expressos na forma tabular. O usuário pode organizar os dados exibidos no mapa
através de diversas restrições e posteriormente identificar as relações espaciais entre os diversos
objetos geoespaciais visualizados, traçando as dependências entre eles.
Esta é uma característica importante que o conceito Web Mapping absorve quando utilizado
em projetos SIG, agregando além da visualização dos dados espaciais a análise de tais dados para a
compozição do sistema. Portanto um sistema SIG Web Mapping também deve permitir gerar análise
sobre seus dados.
Inúmeros sistemas servem de base para prover tais características. A maioria dos sistemas
geradores de mapas provém uma grande gama de possibilidades, e os mais sofisticados permitem
que os objetos espaciais possam ser manipulados diretamente pelo SIG.
Esse acesso aos objetos espaciais acontece de duas formas distintas: o acesso, manipulação
dos objetos espaciais puros e, o acesso aos dados já prontos para serem disponibilizados. É através
da primeira forma de acesso aos dados que a maioria dos SIGs para Web Mapping é desenvolvida,
pois esta viabiliza que os objetos espaciais possam ser manipulados antes que o mapa seja entregue
ao usuário.
2.5.1. UMN Mapserver
UMN Mapserver é um aplicativo que permite o desenvolvimento de sistemas espaciais
voltados à Internet. É licenciado sobre o padrão opensource, e utiliza o acesso a inúmeras
bibliotecas como: Shapelib, FreeType, Proj. 4, GDAL/OGR. Por estar sobre a licença GNU não
esteja atrelado exclusivamente a uma instituição ou pessoa.
Seu desenvolvimento foi iniciado por Sthepen Lime em 1994 como parte do projeto ForNet
entre a NASA e a Universidade Minessota. Apesar desse desenvolvimento inicial, hoje é mantido
por diversas instituições como: UNM, NASA, DM Solutions, Universidade do Vale do Itajaí
(UNIVALI). Cada uma responsável por partes específicas do código, cabendo à UNIVALI e ao
LCA o desenvolvimento do driver de comunicação com o Oracle Spatial.
Atualmente, sua arquitetura é modular apesar de seu núcleo não ser desenvolvido seguindo a
metodologia de orientação a objetos. UMN (2004a) apresenta como principais características:
• Leitura de dados vetoriais;
• Leitura de dados raster;
• Índices espaciais (através de shapefiles);
• Suporte a pesquisas por objetos espaciais;
• Projeções em tempo real;
• Suporta a bancos de dados espaciais e;
• Mapscript.
Um ponto importante a ser destacado é o suporte às especificações OGC, permitindo o
suporte a: WMS (cliente e servidor), WFS não transacional (cliente e servidor), WCS (servidor),
WMC, SLD, e GML;
O suporte a banco de dados espaciais presente no UMN Mapserver possibilita o acesso a
dados armazenando em diversos SGBD’s. Existem duas formas de acesso a esses bancos através do
UMN Mapserver: suporte nativo ou através de OGR.
O suporte nativo a SGBD’s apresenta o melhor desempenho. Isto acontece pois o acesso é
feito diretamente as interfaces disponibilizadas pelo banco. Como exemplo de suporte nativo
podemos citar: Shapefile (arquiteura dual), MyGis (estratégia relacional), PostGIS e Oracle Spatial
(estratégia orientada a objetos).
Por apresentar tais características é considerado o melhor aplicativo de base para
desenvolvimento de SIG via Internet. Provendo a base para o desenvolvimento de mapas web que
podem ser direcionados as necessidades do usuário. Portanto, o UMN Mapserver não pode ser
considerado um aplicativo SIG, não disponibiliza nenhuma ferramenta para análise espacial ou
qualquer funcionalidade SIG complexa (UMN, 2004a).
O UMN Mapserver permite que aplicativos SIG possam manipular objetos espaciais de
forma simples, possibilitando que mapas dinâmicos sejam gerados a partir da iteração entre o
usuário e a aplicação. Não há restrição à utilização de tais objetos espaciais. Seu uso fica
direcionado ao foco do sistema desenvolvido. Ao UMN Mapserver cabe a função de prover estes
objetos espaciais.
Dentre as características identificadas cabe ressaltar duas em especial:
• Acesso a SGBD’s: o UMN Mapserver pode comunicar-se diretamente com o
SGBD’s (Oracle e PostgreSQL) permitindo a leitura de objetos espaciais, não
somente a leitura de atributos espaciais como também de atributos não espaciais.
Permite que o usuário possa utilizar e escolher quais os operadores espaciais que
deseja utilizar e;
• Mapscript: é através deste módulo que o UMN Mapserver disponibiliza o acesso aos
objetos espaciais. Este módulo será abordado em um capítulo especifico adiante.
Essas duas características serão amplamente utilizadas no desenvolvimento do projeto,
Mapscript permitindo manipulação de objetos espaciais e Oracle Spatial provendo seu
armazenamento. A utilização do UMN Mapserver pode ser de duas formas principais: como
gerador de mapas geográficos ou como provedor de objetos espaciais. Como gerador de mapas
geográfico a principal funcionalidade é entregar mapas completos (mapa, legenda, escala). A partir
de requisições do usuário o UMN Mapserver entrega um mapa contendo todas as informações
selecionadas pelo usuário: camadas, símbolos, e organização. Neste caso trabalhando em modo
CGI.
Utilizado como provedor de objetos espaciais permite que sistemas SIG possam utilizar seus
objetos espaciais para diversos fins, principalmente geração de análises espaciais. A elaboração de
um mapa no final do processo passa a não ser mais obrigatório. Essa forma de trabalho pode ser
feita através do uso de Mapscript (veja Seção 2.5.1.1).
Independente da forma de utilização, para que seja possível gerar tanto mapas quanto os
objetos espaciais um requisito importante deve ser provido: a criação do Mapfile. É neste arquivo
que os parâmetros básicos serão definidos: estilo, fontes, acesso aos dados, e cores. Todos estes
culminam para completar o objeto espacial, esse definido pelo bloco identificado por layer no
arquivo. O UMN Mapserver montará o objeto espacial através dos parâmetros definidos no Mapfile
para a layer.
Um detalhe importante a ser ressaltado é que nas últimas versões do UMN Mapserver é
possível que parâmetros do Mapfile possam ser definidos dinamicamente via Mapscript, mas sua
presença ainda é obrigatória.
Como citado anteriormente, tanto sistemas SIGs voltados para web quanto sistemas de Web
Mapping desenvolvidos a partir do UMN Mapserver permitem que o usuário possa interagir
diretamente com o mapa. Desta forma, mapas dinâmicos são criados e entregues a partir de
requisições do usuário. Por exemplo, o usuário pode escolher a qualquer momento quais serão os
objetos visualizados ou quais serão os parâmetros da análise a serem geradas.
A utilização do UMN Mapserver, através do Mapscript, será à base de desenvolvimento do
algoritmo proposto, provendo a melhor métodos para visualização, manipulação, criação de objetos
geoespaciais.
2.5.1.1. Arquivo Mapfile
O arquivo Mapfile é utilizado pelo Mapserver como base para a apresentação de mapas
temáticos, é neste onde estão presentes às configurações de cores, formas, estilos e, origem dos
dados a serem representados.
Em sistemas que utilizam o Mapserver através de seu modo CGI a presença do arquivo
Mapfile é indispensável, pois este modo permite que somente poucos parâmetros sejam
modificados dinamicamente através de uma requisição CGI. Aplicativos que utilizam o modo
Mapscript ainda necessitam um arquivo Mapfile, mas este pode ser extremamente enxuto se
comparado com o do modo CGI, contendo poucos parâmetros definidos. Isto se deve ao fato de que
através do Mapscript podem-se adicionar dinamicamente inúmeros atributos do arquivo.
O arquivo Mapfile é estruturado a partir da definição de um objeto map que contêm
definições de atributos do próprio objeto map e de outros objetos. Os principais atributos do objeto
map são:
• EXTENT: define os limites iniciais de representação do mapa, apresenta os limites
inferiores e superiores do mapa;
• UNIT: atributo que especifica qual o sistema métrico no qual o mapa está definido, a
unidade de medida para o mapa;
• FONTSET: armazena qual a localização do arquivo com as configurações das fontes
a serem utilizadas no mapa;
• SYMBOLSET: atributo que armazena, da mesma forma que o anterior, o caminho
onde se localizam as definições de símbolos utilizados no mapa;
• SIZE: armazena o tamanho em que o mapa será criado, qual o tamanho da imagem a
ser gerada.
Na elaboração do arquivo Mapfile todos os objetos definidos necessariamente terminam
com o parâmetro end. E todos os atributos que aceitam caracteres como parâmetro podem ser
definidos com o uso de aspas duplas. A Figura 9 apresenta um trecho das definições dos atributos
de um arquivo Mapfile, utilizando conceitos e definições explanados nesta mesma seção.
map extent 0 0 41 41 units dd size 555 555 imagetype png transparent true symbolset ".\simbolos.txt" fontset ".\fontes.txt" end
Figura 9: Trecho de um arquivo Mapfile.
Associado ao objeto map outros objetos podem ser definidos como parâmetros, os principais
objetos são:
• SCALEBAR: objeto que define através de seus atributos qual a escala do mapa,
especificando qual o sistema métrico e, o estilo da escala;
• LEGEND: definição da legenda a ser utilizada, pode especificar fonte, tamanho de
fonte e, posição da legenda no mapa;
• WEB: objeto que contêm as especificações sobre a forma como o mapa será salvo,
qual o caminho a ser utilizado, nome do arquivo e, informações para possível
depuração;
• OUTPUTFORMAT: objeto onde estão definidos os parâmetros para o formato da
imagem utilizada no mapa, qual o driver que será utilizado para a construção da
imagem, por exemplo: GIF, PNG, JPEG e, BMP;
• LAYER: objeto que contem todas as informações sobre como os dados espaciais são
desenhados no mapa, qual a origem do dado, metadados, entre outros. Um objeto
MAP pode ter mais de um objeto do tipo LAYER.
2.5.1.1.1. Objeto Layer
Através deste objeto que os parâmetros para definição do objeto geoespacial a serem
gerados são definidos, os parâmetros podem ser:
• NAME: atributo que define qual o nome da camada a ser gerada. No arquivo Mapfile
cada objeto layer é identificado através de seu nome, portanto este atributo deve ter
um parâmetro único como definição;
• STATUS: atributo que define se o objeto será desenhado no mapa;
• TYPE: define qual o tipo do dado a ser representado, podendo ser principalmente
point, line ou polygon;
• CONNECTIONTYPE: atributo que define qual o tipo de origem do dado, qual a
forma de acesso ao dado. Pode apresentar como principais valores: Shapefile,
OracleSpatial, PosGis ou, OGR;
• CONECTION: caso o atributo anterior identifique conexão com banco de dados é
neste parâmetro onde se deve definir a conexão;
• DATA: neste atributo define-se qual a origem dos dados, qual a consulta a ser
realizada no banco de dados (caso a origem seja banco de dados) ou qual o caminho
ao arquivo de dados (acesso através de arquivo Shapefile);
Associado ao objeto layer existem outros dois importantes objetos que podem ser definidos
e atuam diretamente nos objetos visualizados no mapa. Os objetos são:
• CLASS: este objeto apresenta diversos atributos que tem por finalidade aplicar
alterações ou restrições sobre os dados da layer. Pode manipular qual a fonte a
utilizada para o dados, o símbolo que representará o dado e, escala de visualização.
Suas definições implicam em alterações nos dados ou em parte dos dados do objeto
layer;
• FEATURE: objeto que permite definir dinamicamente as coordenadas espaciais a
serem visualizadas no mapa, este objeto pode ser definido em tempo de execução
através do Mapscript. Apresenta um atributo e um objeto, respectivamente text e
ponts que definem o texto associado ao ponto e as coordenadas do ponto espacial.
A Figura 10 apresenta um trecho do arquivo Mapfile com uma definição simplificada de um
objeto layer. Neste está exemplificada a estrutura de como pode estar organizado um objeto layer,
pode-se visualizar a definição de alguns atributos descritos acima bem com dos objetos class e
feature.
layer name "Camada" status on type polygon class name "Classe" style color 255 0 0 size 2 end end feature text "Dado Dinâmico" points 10 10 15 10 end end end
Figura 10: Exemplo de objeto layer.
O objeto feature através do objeto points permite que qualquer objeto geoespacial seja
definido, desde simples pontos até polígonos complexos. A definição deste objeto pode ser feita
através do modo Mapscript, permitindo que objetos espaciais possam ser gerados e adicionados ao
mapa.
Desta forma pode-se criar grids dinâmicos através do Mapscript e desenhá-los através de um
mapa sem que eles tenham sido previamente definidos, esta forma de definição de dados espaciais
será utilizada neste TCC para a definição das células do grid. Onde cada célula será representada e
ira gerar um único objeto do tipo feature. Onde a união de todos os objetos em uma layer irá gerar
grid com células únicas.
Um objeto feature pode ter definido mais de um objeto points, desta forma objetos
geoespaciais complexos podem ser gerados, objetos com partes que não estão unidas, ou objetos de
tipos múltiplos.
2.5.1.2. MapScript
Segundo UNM (2004a) Mapscript é uma interface disponibilizada pelo UMN Mapserver
que permite a criação de scripts em diversas linguagens. Disponibilizando ao desenvolvedor uma
Application Programming Interface (API) mais simples do que a existente em C, além de permitir o
acesso via orientação a objetos.
Atualmente, existe módulo Mapscript para diversas linguagens, estes divididos em dois
padrões: PHPMapcript e SwigMapscript. Ambos disponibilizam as mesmas funcionalidades de
acesso aos objetos permitindo assim que sejam desenvolvidos aplicativos SIG para os mais diversos
fins.
Figura 11. Árvore organizacional do UMN Mapserv.
Fonte: UMN (2004b)
Através da Figura 11 pode-se notar a divisão dos padrões do MapScript, e que o suporte a
diferentes linguagens é provido através da interface disponibilizada pelo Simplified Wrapper and
Interface Generator (SWIG).
Portanto, é através do SWIGMapScript que linguagens como Java, Perl, Python, Ruby, e Tcl
acessam os objetos espaciais disponibilizados pelo UMN Mapserver. Segundo Gillies (2004) o que
ambas linguagens têm em comum neste caso é o acesso ao módulo SWIG, chamado de
SWIGMapScriptAPI e escrito em C, que disponibiliza o acesso aos objetos e funções internas da
API Mapserver.
PHPMapScript é o módulo MapScript mais amigável e há mais tempo desenvolvido. Foi
disponibilizado para acesso através do PHP versão 3.0.14 e atualmente é compatível com as
diversas versões do PHP. A sua interface herda todas as características da linguagem PHP
adicionando o suporte à manipulação de objetos espaciais. As funcionalidades providas pela
linguagem PHP serão discutidas posteriormente. As principais características do MapScript são:
• Manipulação dinâmica de definições do arquivo MapFile;
• Criação de mapas temáticos;
• Suporte a pesquisas espaciais usando pontos, linhas, e polígonos;
• Suporte à pesquisa aos atributos não espaciais dos objetos e;
• Suporte à leitura e gravação de shapefiles (arquitetura dual).
Independente do padrão utilizado, PHP ou SWIG, o acesso aos dados é feito através de
objetos e funções disponibilizadas pelo MapScript. O usuário poderá manipular os objetos somente
pelo acesso disponibilizado por esses, dessa forma o usuário não tem acesso irrestrito e direto à, por
exemplo, o banco de dados definido no arquivo MapFile.
Os objetos e funções disponibilizadas pelo MapScript são inúmeras, a lista completa pode
ser encontrada na página do próprio UMN MapServer. As funções disponíveis estão associadas aos
objetos utilizados, por exemplo, as funções para alteração de cor somente estão disponíveis para
acesso através do objeto ColorObj.
Um ponto importante a ser destacado é que o objeto espacial do MapScript, contendo todos
os seus parâmetros, esta disponível através do LayerObj, é através deste que é possível realizar:
pesquisa e acesso a dados espaciais, pesquisa e acesso a atributos não espaciais, configuração de
atributos, além de acesso a objetos agregados a este.
Portanto, é possível utilizar o conceito dowcast de orientação a objetos e acessar objetos que
compõe o LayerObj. Por exemplo, podemos acessar o ColorObj e seus parâmetros através de um
objeto LayerObj. As funções passíveis de serem utilizadas por objetos do tipo LayerObj são
inúmeras, podemos destacar como principais as funções de pesquisa a atributos e de retorno de
dados do objeto. O acesso aos atributos que compõe o objeto espacial (atributos espaciais e não
espaciais) está disponível através do objeto ShapeObj.
É a partir do acesso disponibilizado pela interface MapScript aos objetos espaciais que SIGs
podem ser desenvolvidos através do UMN Mapserver, pois é este que disponibiliza o objeto
espacial já devidamente formatado, assim ao SIG basta somente utilizar os objetos.
É este nível de abstração que será utilizado no desenvolvimento do algoritmo. É a partir dos
objetos disponibilizados pelo MapScript que a análise será gerada. O UMN Mapserver irá
disponibilizar os objetos espaciais padronizados e com os parâmetros definidos. No
desenvolvimento do projeto serão utilizados principalmente os objetos: LayerObj e ShapeObj.
2.5.1.3. PHP
Segundo Bakken e Schmid (2004) PHP é uma linguagem de programação de ampla
utilização, interpretada, utilizada para o desenvolvimento de aplicações para Internet que pode ser
marcada dentro do código HTML.
A linguagem PHP sucede a PHP/FI criada por Rasmus Lerdorf em 1995, escrita
inicialmente em Perl e portada para C. A linguagem PHP como é conhecida hoje surgiu em 1998
com a versão 3.0 e em 2000 com a versão 4.0. Atualmente, o PHP encontra-se licenciado sobre a
GNU, e seu código fonte está disponível sem custos na Internet.
A sintaxe para uso do PHP é extremamente parecida como a linguagem C, Java, e Perl. O
principal objetivo é gerar páginas que possam ser carregadas dinamicamente e entregues de forma
rápida ao usuário.
Mas o PHP, não está limitado somente à geração de Hyper Text Markup Language (HTML),
permite também a criação de diversos tipos e formatos de arquivo, Suportando arquivos como: BZ2,
Gzip, PDF, SWF, XML, XHTML, entre outros.
Segundo Bakken e Schmid (2004) as características mais marcantes do PHP são:
• Suporte à ampla variedade de bancos: dBase, Oracle, PostgreSQL, IBM DB2,
Sybase, entre outros;
• Suporte a paradigmas de programação: estruturado e orientado a objetos;
• Suporte a eXtensible Markup Language (XML): permite manipulação de arquivos
XML através dos padrões World Wide Web Consortium (W3C) e;
• Suporte a criptografia: permite que dados sejam entregues de forma segura através
de criptografia security shell.
Por ser uma linguagem interpretada, o PHP ao ler um código simplesmente analisa
seqüencialmente o arquivo a procura por trechos entre delimitadores da linguagem. Após encontrar
a tag inicial começa a interpretar todo o texto seguinte como código PHP até encontrar a tag de
fechamento.
Os tipos suportados pela linguagem PHP são oito:
• Quatro tipos básicos: booleano, inteiro, ponto flutuante e string;
• Dois tipos compostos: array e object e;
• Dois tipos especiais: NULL e resource.
As variáveis são todas compostas pelo cifrão ($) seguido do nome da variável, sendo que os
nomes das variáveis não apresentam distinção entre maiúsculas e minúsculas. As funções
disponibilizadas pelo PHP são inúmeras, sendo relacionadas com o escopo da página desenvolvida.
Estão agrupadas por tipo, sendo aproximadamente 150 tipos de funções diferentes. Englobando
desde funções para comunicação com o servidor Apache até funções para envio de e-mail.
Diferentemente das variáveis as funções não apresentam nenhum caractere especial a sua
frente e podem ser utilizadas desde que o suporte a estas tenha sido adicionado ou habilitado na
linguagem. Um ponto importante na utilização do PHP é que, diferentemente do JavaScript, é
executado totalmente no servidor, assim o usuário recebe somente o resultado da execução do script
PHP. Para isso é necessário ter instalado no servido web a linguagem PHP.
Atualmente, pode ser utilizado nas mais diversas plataformas, desde Windows até Unix e
nos mais diversos servidores web existentes: Apache, IIS, Xitame, entre outros.
Como citado anteriormente, existe o suporte ao paradigma de orientação a objetos, desta
forma é possível aplicar a metodologia UML para a criação de páginas PHP. Assim, a execução do
script deixa de seguir a lógica seqüencial e passa a uma lógica com ações e operações mais
controladas.
Existe por parte do PHP a possibilidade de inclusão de novas bibliotecas à linguagem, e
desta forma é possível adicionar o suporte a novas características diretamente na linguagem. É
dessa forma que o módulo PHPMapScript trabalha: uma biblioteca é adicionada e carregada
dinamicamente ao PHP permitindo a manipulação de objetos espaciais.
É a partir da linguagem PHP que o algoritmo do projeto, bem como o aplicativo final, será
desenvolvido. O PHP irá prover a base para o desenvolvimento, disponibilizando, além de uma
linguagem de programação voltada a Internet que suporte a modelagem UML de orientação a
objetos, uma linguagem com suporte à leitura e manipulação de objetos espaciais providos pelo
UMN Mapserver.
2.5.2. Mapserver Guarani
Framework para UMN Mapserver desenvolvido e mantido pelo LCA que permite a
elaboração de sistemas com ênfase em web mapping. Permitindo que o usuário possa interagir
diretamente com o mapa através das funcionalidades disponibilizadas.
Funcionalidades portadas de sistemas SIG desktop para plataforma web, permitindo que
múltiplos usuários possam compartilhar das mesmas ferramentas a partir de um único sistema.
Dentre estas funcionalidades destaca-se:
• Conexão com banco de dados: permite a conexão com o PostgreSQL e Oracle,
inclusive com as extensões espaciais;
• Entrega de mapas: permite a entrega de mapas, gerados pelo UMN Mapserver,
através das requisições do usuário;
• Navegação: permite aos usuários meios de navegar no mapa através de funções
simples, como: zoom aleatório, aproximação do mapa (zoom in), afastamento (zoom
out) e, movimentação (pan);
• Cálculo de distância: permite ao usuário definir dinamicamente pontos e calcular as
distâncias entre esses em diversos sistemas métricos, como demonstrado pela Figura
12;
• Análise espacial: disponibiliza a capacidade do usuário definir uma área de interesse
no mapa e pesquisar quais as informações dos objetos geoespaciais inclusos nessa
área, como demonstrado na Figura 13;
• Análise de vizinhança: permite ao usuário do sistema escolher um objeto geoespacial
aleatório do sistema e definir um raio para busca dos vizinhos a esse que se
encontram inclusos dentro do perímetro e;
• Query Builder: método de análise espacial que permite ao usuário definir
dinamicamente qual a pesquisa, as restrições, que serão aplicadas sobre os objetos
geoespaciais, demonstrando o resultado de tal pesquisa através do mapa.
Figura 12: Cálculo de distância.
Figura 13: Análise espacial sobre dados de rodovias da região de Itajaí.
Desenvolvido de forma modular possibilita que novas funcionalidades sejam adicionadas ou
removidas do sistema sem alterações em outros módulos do aplicativo. Desta forma, por exemplo,
uma nova funcionalidade como análise geoespacial não influência no funcionamento de outra,
como query builder.
Atualmente na terceira versão é desenvolvido nas linguagens PHP e JavaScript, o que
facilita sua manutenção por serem linguagens de conhecimento público. Isso permite que o tempo
para aprendizado por parte do desenvolvedor seja reduzido se comparado com linguagens
proprietárias.
O Mapserver Guarani utiliza como engine geradora de mapas o UMN Mapserver, sendo este
utilizado através de sua API PHPMapscript. Desta forma, os objetos geoespaciais podem ser
manipulados antes que o mapa a ser entregue ao usuário seja gerado. Assim, novas informações ou
análises podem ser extraídas desses objetos.
Diversos projetos desenvolvidos pelo LCA já utilizam o framework como interface para web
mapping, como: Pesca Tijucas, Sistema de Monitoramento de Mamíferos Marinhos (SIMMAM),
BioEnsaios, Sistema de Rastreamento de Embarcações e, Sistema Rastreador Geográfico.
Como citado, o framework permite que novas funcionalidades sejam adicionadas às diversas
já existentes, neste TCC o algoritmo para geração de análise geoespacial através de quadrantes será
adicionada ao Mapserver Guarani, e esse por sua vez servirá de comunicação com o usuário do
sistema Pesca Tijucas e representará o ator na modelagem do algoritmo.
2.6. CONSIDERAÇÕES
Como destacado na Seção 2.4.2 existem diversas formas para representação de mapas para
dados pesqueiros, dentre estes se destaca o uso da técnica choropleth map para representação do
espaço visualizado dividido por quadrantes.
Meaden e Chi (1996) bem como especialistas do GEP identificaram pontos importantes que
devem ser levados em consideração para a escolha de tal método para realização de análises sobre
dados de pesca. Pode-se citar:
• Área de análise: a divisão por quadrantes permite que o espaço da análise seja
dividido em espaços iguais, todas as áreas são análisadas tendo como base o mesmo
tamanho. Esta característica inviabiliza outros métodos, como Voronoih que não
considera a mesma área para todas as regiões de análise;
• Precisão das amostras: dados geoespaciais sobre pesca tendem a ser imprecisos por
diversos motivos, como: momento da realização da leitura do dado, movimento do
barco pelas correntes marítimas e, entre outros diversos fatores. Características estas
que tendem a tornar o dado impreciso, inviabilizando o uso do método isoline map,
que necessita de dados extremamente precisos para representação. O uso de
quadrantes permite a análise tanto do dado com localização espacial precisa quanto
dado com a localização imprecisa;
• Analise por período: uma característica importante para a análise de dados de pesca é
o uso do fator tempo para análise, a comparação de resultado de análises para a
mesma área ao longo de um período de tempo. O uso de quadrantes permite que a
mesma área seja analisada em diversas épocas, possibilitando avaliar a evolução dos
recursos pesqueiros para uma determinada área;
• Dinamicidade das amostras: dados de pesca tendem a variar a localização espacial ao
longo de um período. Por exemplo: um cardume de atum pode estar associado à
ocorrência de certo nível da temperatura da água, e essa variar a localização entre
períodos. A utilização de quadrantes neste caso permite avaliar a mesma área e com
os mesmos dados em períodos diferentes, e;
• Dados pontuais: as amostras de pesca são comumente representadas através de dados
pontuais. A representação através de quadrantes permite agrupar e analisar os pontos
através de características comuns, obtendo assim a melhor representação das
amostras.
Além destes, fatores técnicos também necessitam serem destacados para permitir a
utilização de análises através de quadrantes. Dos métodos para análise geoespacial (Seção 2.4.1.1)
somente o método Kernel (Seção 2.4.1.1.1) permite o uso de grid para analise de objetos
geoespaciais. Dentre as diversas funcionalidades o método Kernel permite:
• Utilização de grid: permite a definição de um grid que pode ser aplicado sobre a área
de análise para realização da análise geoespacial;
• Análise pontual: a utilização de dados de pesca expressos através de pontos necessita
de um método que permita realizar tal leitura, o método Kernel permite a análise de
objetos geoespaciais com representação geoespacial do tipo pontual;
• Integração com banco de dados geoespaciais: o método Kernel pode ser integrado
em sistemas para análise de objetos geoespaciais oriundos diretamente de banco de
dados geoespaciais;
• Tipo de análise: o método Kernel segundo Bailey (1994) permite analisar objetos
geoespaciais utilizando além da localização espacial do objeto os atributos não
espaciais que o compõem. Desta forma relações entre atributos e a localização
espacial podem ser identificados com mais eficiência, e;
• Áreas de ricos: segundo Bailey (1994) o método Kernel permite identificar áreas de
risco para ocorrência de fenômenos. Permite identificar e quantificar a intensidade da
ocorrência de tal evento no espaço estudado.
Como identificado na Seção 2.4.2 e nos tópicos anteriores a utilização de quadrantes para
análise geoespacial de dados da indústria pesqueira apresentam uma das melhores formas de
representação dos resultados. Além de ser a forma comumente utilizada por especialistas, como os
do próprio GEP, para representação das análises geoespaciais para a indústria pesqueira. Para a
realização desta análise o método Kernel apresenta a melhor estrutura para o tipo de análise
utilizado.
Dentre as diversas análises geoespaciais a serem representadas através de mapas temáticos,
os especialistas do GEP identificaram como principais:
• Quantidade por tempo de arrasto: permite mensurar qual a quantidade que foi
retirada do estoque pesqueiro dividido pelo tempo de arrasto da rede;
• Quantidade por espécie por período: permite identificar quanto foi retirado do
estoque pesqueiro de determinada espécie em um período específico;
• Tempo de arrasto por período: identifica em quanto tempo foi realizado o arrasto de
uma rede de pesca em um determinado período;
• Quantidade por metro quadrado de arrasto: permite identificar a quantidade de
recurso extraído por metro quadrado de arrasto realizado;
• Numero de lances por área e por tempo: permite quantificar o número de lances que
ocorreram em uma determinada área e em um determinado período, e;
• Número de barcos por área: permite mensurar o número de barcos que extraem
recursos de determinada área, permitindo identificar possíveis gargalos e futuras
áreas de estresse para obtenção de recursos pesqueiros.
No próximo capítulo é descrita a abordagem em ciência da computação que modelará, na
forma de um sistema computacional, os conceitos expostos no Capítulo II.
3. DESENVOLVIMENTO
3.1. PROJETO
A terceira etapa deste TCC aborda os aspectos técnicos necessários para realização dos
objetivos gerais e específicos definidos. O projeto proposto está dividido em: modelagem,
desenvolvimento, e validação. Ambas as atividades desenvolvidas nesta etapa apresentam uma
continuidade e aplicação dos conceitos abordados em etapas anteriores, visando atender os
objetivos deste TCC.
3.1.1. Sistema de Informação Para Suporte À Gestão Pesqueira
A idéia de que os recursos pesqueiros são inesgotáveis levou ao desenvolvimento de
sistemas para gerenciamento dos estoques pesqueiros. Tais sistemas, conforme apresentado
anteriormente, visam o suporte ao planejamento e tomada de decisão em relação ao uso sustentável
dos recursos pesqueiros. É neste contexto que o presente TCC se enquadra ao propor o
desenvolvimento de ferramentas para auxiliar a análise sobre bancos de dados de captura da
indústria pesqueira.
Especificamente, este trabalho irá proporcionar ao banco de dados do GEP, e por extensão a
seus pesquisadores, uma ferramenta capaz de gerar cartas temáticas orientadas a gestão pesqueira.
Nesta linha de atuação o GEP apresenta vários projetos, destacando-se:
• Estatística Pesqueira7;
• Avaliação dos Estoques8;
• Programa dos Observadores de Bordo9;
3.1.2. Análise GeoEspacial
Será empregado o método Kernel (veja Seção 2.4.1.1.1) para a análise geoespacial proposta
neste TCC. Ela permite que os objetos geoespaciais sejam analisados através de quadrantes,
conforme os atributos que se busca compreender.
7 http://siaiacad04.univali.br/index_apr.php?id=7 8 http://siaiacad04.univali.br/index_apr.php?id=9 9 http://siaiacad04.univali.br/index_apr.php?id=13
O fato destas análises terem origem em dados de captura de pesca, os quais são obtidos com
regularidade, atribui um potencial dinâmico para as cartas temáticas a serem geradas.
Adicionalmente, a análise geoespacial pelo método Kernel permitirá a geração de grades em tempo
de consulta, e com resolução a ser definida pelo usuário. Esta possibilidade permitirá a geração de
cartas temáticas com a escala de análise apropriada a série de dado temporal.
3.1.3. Modelagem
A modelagem do sistema foi especificada com o intuito de apresentar os diagramas
necessários para a aplicação dos conceitos abordados durante a fundamentação teórica e para a
implementação do algoritmo proposto. Os diagramas foram criados seguindo os conceitos UML.
Para este projeto foram utilizados os diagramas de Caso de Uso, Atividade, Seqüência,
Classe, e Protótipo de Tela. Todos os diagramas, bem como sua documentação, encontram-se no
Apêndice A. As próximas seções apresentam uma breve explanação dos principais diagramas
encontrados no apêndice.
3.1.4. Diagrama de Caso de Uso
Segundo FEAT (2001), a modelagem através de casos de uso (Use Case) é uma técnica
utilizada para descrição e definição dos requisitos funcionais de sistemas. Esta apresenta a ordem
lógica das etapas e processos que envolvem o algoritmo.
A Figura 14 apresenta o diagrama de caso de uso do algoritmo proposto. A existência de
somente um cenário caracteriza o cerne do TCC: a elaboração de um algoritmo para análise
geoespacial através do UMN Mapserver, conseqüentemente integrada a um SIG já existente.
O caso de uso Analise GeoEspacial proposto na Figura 14 apresenta como único ator
usuário do sistema Pesca Tijucas, o qual utilizará o sistema e irá prover os dados necessários para a
execução da análise geoespacial.
O fluxo principal para este caso de uso é, a partir de uma requisição do usuário, onde os
dados serão inseridos através da tela na Figura 21 validados e enviados ao Mapserver Guarani,
sendo que este realizará a comunicação com o algoritmo proposto através de seu núcleo Mapscript.
As relações estão demonstradas no diagrama de classe exposto na Figura 19.
O fluxo alternativo ocorre quando os dados inseridos pelo usuário são inconsistentes,
impossibilitando que a análise seja realizada. Caso alguma das validações abaixo seja verdadeira
este fluxo alternativo será realizado:
• Limites do grid inválidos: O usuário deve inserir todos os valores mínimos e
máximos do eixo de coordenadas X e Y, sendo que os pontos do limite mínimo
devem ser menores e diferentes do ponto definido como limite máximo;
• Granularidade inferior a zero: Caso o usuário defina uma granularidade para o grid
inferior a zero o fluxo será executado. Somente granularidades superiores a zero
serão válidas;
• Número de células adjacentes: Para o cálculo pelo método Kernel o usuário pode
inserir o número de células adjacentes que deseja utilizar para a análise, somente
serão válidos valores iguais ou superiores a zero, e;
• Período de análise inválido: O período de análise torna-se inválido quando o usuário
informa datas com valores errados, por exemplo, 31 dias para o mês de fevereiro.
A pré-condição deste caso de uso é a existência de um banco de dados contendo dados
georeferenciados de pesca e o ambiente Mapserver Guarani devidamente configurado para a
arquitetura utilizada, neste caso PostgreSQL/PostGIS. Além da existência de permissão de uso do
Mapserver Guarani no sistema Pesca Tijucas, o usuário já deverá estar logado no sistema Pesca
Tijucas. Como uma pré-condição intrínseca ao uso do banco de dados, para que a análise
geoespacial possa ser obtida, os dados de pesca que compõem objeto geoespacial devem refletir o
diagrama de classe do Apêndice I.
Figura 14: Diagrama de caso de uso proposto para o algoritmo.
3.1.5. Diagrama de Seqüência
O diagrama de seqüência apresentado na Figura 15 visa um detalhamento do caso de uso
apresentado na Figura 14. A partir deste diagrama é possível visualizar como o método de análise
espacial pode ser utilizado pelo usuário do sistema através do Mapserver Guarani, constituindo
assim a ordem lógica das trocas de mensagens necessárias.
A primeira e única mensagem trocada entre o algoritmo proposto e o Mapserver Guarani
inicia-se através de uma requisição simples do usuário ao Mapserver Guarani. Sendo que a
mensagem síncrona Realiza_Analise_GeoEspacial inicia a execução do fluxo principal, desta
forma, para que o método possa ser executado, serão passados os seguintes parâmetros:
• Um array contendo o extent em que a análise será realizada, este caracterizando
como primeiro parâmetro;
• Um float representando a granularidade a qual será gerada cada célula do grid, este é
o segundo parâmetro a ser passado na mensagem;
• Os terceiro e quarto parâmetros definem e permitem ao algoritmo identificar qual a
janela de tempo em que à análise será realizada;
• O quinto parâmetro define qual a métrica utilizada como base na análise geoespacial.
Podendo ser de cinco tipos diferentes. Os tipos possíveis estão descritos no Apêndice
I;
• O sexto parâmetro especifica qual o número de células adjacentes que serão
utilizadas no método Kernel;
• O sétimo parâmetro define qual o código da espécie a ser pesquisada. Este parâmetro
é necessário quando a métrica definida é específica para uma única espécie, em
outras métricas esse parâmetro, mesmo que informado, será desconsiderado, e;
• O oitavo e último parâmetro informa qual o objeto mapa do UMN Mapserver que
terá a camada do grid adicionada.
As duas mensagens seguintes a primeira são internas do algoritmo e são utilizadas para
identificar quantas linhas e colunas o grid contém. Sendo a mensagem Cria_Janelas_Grid sendo
executada para verificar se os dados para o valor máximo em X e mínimo em Y necessitam ser
recalculados a fim de uma maior precisão do método.
As próximas três mensagens pertencem a um único fluxo de dados, a mensagem
Busca_Lances_Total, permite através de uma pesquisa espacial executada pelo PostGIS identificar
todos os lances que estejam contidos dentro dos limites do grid. Após isso a mensagem
Calcula_Celula_Lance e Retorna_Dados_Lance pode ser executada.
Sendo que Calcula_Celula_Lance permite, através de seus dois parâmetros: coordendas do
ponto nos planos x e y, identificar a qual célula o lance pertence. Desta forma os dados do lance
retornados pela classe Lance, através da próxima mensagem, podem ser direcionados para a célula
correta.
Como apresentado na Figura 15 o acesso aos dados utilizados para análise, fonte externa,
será realizada através da função Retorna_Dados_Lance disponibilizada pela classe Lance. Após a
pesquisa de todos os objetos que pertencem ao grid esta mensagem juntamente com a do cálculo da
célula serão executadas em um laço de repetição até que todos os lances tenham sido pesquisados e
terem suas células identificadas.
As mensagens Celulas_Inclusas_Tau e Calcula_Celulas_Tau somente serão
executadas caso o usuário escolha um número de células adjacentes maior que zero. Desta forma o
algoritmo retorna um array com todas as células adjacentes a aquela definida pelo parâmetro, e
contidas dentro dos limites estipulado pelo usuário.
As próximas mensagens são necessárias para instanciar o objeto Celula com os dados
necessários, bem como de analisar, pelo método Kernel, as células, sendo que as oito mensagens
deste fluxo são executadas a fim de instanciar a célula com todos os dados necessários, desta forma
cada célula do grid terá um objeto Celula associado.
O método chamado pela mensagem CalculaValorMetrica é responsável por calcular, para
os dados de cada objeto célula enviado, o resultado da métrica definida. Desta forma o valor da
métrica para todas as células são calculados e definidos.
A próxima seqüência de mensagens é responsável por realizar a análise geoespacial da
célula, para a célula informada a análise espacial através do método Kernel, será executada. Uma
distinção durante o fluxo é realizada para identificar se o usuário especificou se deseja realizar a
análise dos dados ou somente uma plotagem dos valores encontrados como métrica para a célula.
Caso ele deseja utilizar a análise os pontos centrais da célula e os seus dados são
requisitados e a análise pode ser realizada, é neste fluxo da mensagem
Analise_Geoespacial_Da_Janela que o método de análise Kernel é executado. Caso o usuário
não opte por realizar a análise somente serão plotados no grid as células com os seus respectivos
valores de métrica.
A mensagem setValorKernelCelula atribui o valor de análise, ou métrica, para a célula.
Desta forma todas as células apresentam um mesmo atributo com o valor da análise associado, valor
que será utilizado para calcular em que faixa de intensidade a célula está contida.
Todas as mensagens do fluxo de Analise_Geoespacial_Da_Janela serão executados em
um laço de repetição até que todas as células tenham sido instanciadas e analisadas. Somente após a
execução destes fluxos é que o grid pode ser adicionado ao objeto mapa do Mapserver Guarani,
criando assim um grid com todas as células divididas por classes de intensidades e visualizadas
através de cloropeth map. Sendo após essa execução o fluxo retornado ao Mapserver Guarani.
Intrínseco à seqüência das mensagens descritas na Figura 15 existe a seqüência descrita na
Figura 16, a qual apresenta as mensagens internas do Mapserver Guarani até que o algoritmo
proposto seja executado.
A seqüência descrita na Figura 21 inicia-se com o envio dos dados por parte do usuário
através da tela disponibilizada, a qual envia seus parâmetros através da mensagem
Realiza_Analise_Geoespacial pelo núcleo do Mapserver Guarani.
A terceira e última mensagem executada neste fluxo é responsável por enviar os dados ao
núcleo Mapscript do Mapserver Guarani, permitindo assim que dados informados pelo usuário na
tela sejam visíveis UMN Mapserver e manipulados como objetos espaciais.
Figura 15: Diagrama de seqüência proposto para o algoritmo.
Figura 16: Diagrama de seqüência interno ao Mapserver Guarani
3.1.6. Diagrama de Atividades
A Figura 17 apresenta a especificação do diagrama de atividades para o algoritmo,
representando o fluxo lógico das atividades realizadas. O diagrama de atividades estende as
definições do diagrama seqüência e conseqüentemente do diagrama de caso de uso. Conforme
descrito na Figura 17 apresenta sete grandes atividades.
As atividades a serem executadas pelo algoritmo podem ser divididas em dois grandes
fluxos .O primeiro contempla as atividades:
• Busca de Lances: esta atividade é responsável por pesquisar no banco de dados todos
os lances de pesca que estão contidos dentro dos limites do grid. Para a realização
desta pesquisa utilizam-se funções de pesquisa espacial em banco de dados, e;
• Cálculo de Célula: atividade responsável por identificar a qual célula do grid o lance
pertence. Esta atividade será executada até que todos os lances identificados na
atividade anterior tenham suas células calculadas.
O segundo fluxo de execução contempla:
• Criação da célula: nesta atividade será instanciada o objeto Celula com os dados de
todos os lances que pertencem a esta. O objeto Celula está descrito na Seção 3.1.7;
• Cálculo da métrica: para cada célula instanciada o valor da relação da métrica
escolhida pelo usuário será calculado e associado ao objeto Celula, e;
• Análise Espacial; esta atividade será executada caso o usuário informe um número
de células adjacentes maiores que zero, caso o usuário informe um valor igual zero
as células terão somente a métrica calculada. Nesta atividade é realizada a análise
espacial através do método Kernel.
Este fluxo será executado até que todas as células do grid sejam instanciadas. Somente após
estes dois fluxos os dados serão inseridos no objeto de mapa disponibilizado pelo Mapserver
Guarani, os dados serão inseridos no objeto na última atividade. O resultado da execução completa
do algoritmo contém um grid passível de ser visualizado no UMN Mapserver.
Figura 17: Diagrama de atividade especificado para o algoritmo proposto.
Conforme descrito no diagrama de atividades o fluxo alternativo só é executado caso ocorra
um erro na pesquisa dos lances, assim finalizando de forma abrupta o fluxo principal do algoritmo e
parando a execução com uma mensagem de erro e sem o grid calculado.
3.1.7. Diagrama de Classe
O diagrama de classe especificado na Figura 18 apresenta as classes implementadas para a
elaboração do algoritmo, demonstrando as relações existentes entre as classes que provêm à base
para o fluxo proposto na Figura 15. Neste diagrama também aparecem às classes já providas pelo
sistema Pesca Tijucas e que serão utilizadas como fonte externa ao algoritmo.
Associado às classes a serem implementadas existe o pacote Mapserver Guarani ao qual o
sistema será integrado, este pacote será explanado com maiores detalhes posteriormente no decorrer
desta seção.
As classes a serem implementadas pelo algoritmo:
• Algoritimo_Analise_Geoespacial: Classe responsável por controlar a realização
da análise geoespacial, implementa o fluxo de para a realização da análise através do
método Kernel. Provê a interface de acesso para o Mapserver Guarani realizar
análises geoespaciais, e;
• Celula: Classe responsável por prover o objeto célula a ser utilizado pelo algoritmo
para representar a célula gerada pelo resultado da análise geoespacial, posteriormente
e visualização através do Mapserver.
Através destas classes foi implementado o fluxo especificado pelo diagrama de atividades. A
classe Celula é responsável por armazenar o resultado da análise geoespacial, além de estar
associada à fonte externa de dados utilizada.
Classes providas pelo Sistema Pesca Tijucas:
• Dados_Controle_Lance: Classe responsável por prover uma abstração dos dados do
banco de dados referentes à embarcação e ao observador;
• Dados_Produto: Classe responsável por prover a abstração dos dados sobre os
produtos pertencentes ao lance. Sendo que cada lance pode ter nenhum ou vários
produtos associados a ele;
• Rede_Pesca: Classe responsável por prover uma abstração das informações
referentes à rede de pesca utilizada em cada lance, e;
• Lance: Classe responsável pro prover a abstração dos lances armazenados no banco
de dados. As informações referentes ao lance estão disponíveis através dos métodos
desta classe, sendo que cada lance está ligado a um objeto da classe
Dados_Controle_Lance.
O esquema interno de organização das classes do sistema Pesca Tijucas a serem utilizadas
pelo algoritmo está demonstrado na Figura 18. As classes a serem utilizadas estão organizadas
tendo como principal a classe Lance. Sendo essa associada à Dados_Produto, Rede_Pesca e
Dados_Controle_Lance.
A ligação entre as classes a serem implementadas e aquelas já existentes no projeto é
realizada através da associação entre a classe Celula e a classe Lance. Sendo que a classe Lance
disponibiliza seus dados através do método Retorna_Dados_Lance. Para a realização da análise
geoespacial através de quadrantes os dados necessários são oriundos de Lances, o único método
necessário para retornar todas as informações é Retorna_Dados_Lance, tendo como parâmetro o
número do lance requisitado.
A classe Algoritmo_Analise_Geoespacial, como citado anteriormente, será responsável
pelo método de análise geoespacial ao Mapserver Guarani, este acesso será realizado através do
método Realiza_Análise_Geoespacial (veja Seção 3.3.2). O Mapserver Guarani poderá utilizar
o método e ter acesso, somente para leitura, aos atributos: aArrExtent e aStrMansagemOperaçao.
O primeiro responsável por armazenar os limites da pesquisa, e o segundo as mensagens internas
decorrentes de interrupções abruptas ou erros durante a execução da análise geoespacial.
O pacote Mapserver Guarani associado ao Algoritmo_Analise_Geoespacial representa o
framework Mapserver Guarani utilizado para o desenvolvimento deste TCC. Na Figura 19 pode-se
observar quais são as classes a serem alteradas para integração com o framework.
A classe Tela representa o esquema, em forma de uma classe, da tela a ser implementada,
demonstrando quais são seus atributos, e seus procedimentos. Como demonstrado no esquema ela
foi desenvolvida para ser integrada ao Mapserver Guarani e permitir que o usuário insira os dados
para análise.
Existem duas classes que foram modificadas para permitir a integração:
• Selecao: esta classe representa o script selecao.js que permite que os dados de
formulários sejam lidos e enviados a classe Mapscript, e;
• Mapscript: classe responsável por abstrair a estrutura do arquivo mapscript.mphp que
realiza a comunicação com a biblioteca PHPMapscript utilizada pelo Mapserver
Guarani, é este arquivo que será modificado para adicionar a chamada à classe
Algoritmo_Analise_Geoespacial;
Essas classes foram modificadas para permitir que os dados inseridos pelo usuário na tela
sejam lidos pelo Mapserver Guarani e repassados ao algoritmo proposto. As classes especificadas
pela Figura 19 constituem a base para que o fluxo do diagrama de seqüência proposto na Figura 16
seja possível de ser implementado.
Atualmente o projeto Pesca Tijucas, ao qual o algoritmo foi incluso, não apresenta a
modelagem de banco de dados homologada, desta forma eventuais alterações nas classes de
disponibilizadas pelo sistema pode ocorrer e acarretar em mudanças nas especificações das classes.
As especificações das classes foram implementadas e baseadas nas existentes no sistema
Pesca Tijucas e de informações de especialistas do GEP. A especificação completa do diagrama de
classe do sistema está completamente descrita no Apêndice I, contendo as informações completas
para classes, métodos e, atributos.
Figura 18: Diagrama de classe.
Figura 19: Diagrama de classe do pacote Mapserver Guarani
3.1.8. Diagrama de Componentes
O diagrama de componentes especificado na Figura 20 demonstra a dependência entre os
diversos componente utilizados pelo sistema. Tal dependência está ligada à forma como o algoritmo
foi implementado.
Figura 20: Diagrama de componentes.
O componente Algoritmo Proposto está representando o algoritmo implementado neste TCC
o qual disponibiliza, como demonstrado no digrama acima, a funcionalidade ao Mapserver Guarani,
permitindo assim que requisições de análises espaciais sejam realizadas, além de acessar dados de
classes disponibilizadas pelo sistema Pesca Tijucas.
O sistema Pesca Tijucas está representado através de um componente, de mesmo nome, o
qual utiliza o Mapserver Guarani como interface web mapping e realiza a abstração de dados do
banco de dados oriundos do PostgreSQL através de classes. O armazenamento de objetos
geoespaciais também é realizada no componente PostgreSQL.
O componente PostgreSQL representa o SGBD PostgreSQL utilizado pelo sistema Pesca
Tijucas como fonte de dados. Suas características já foram descritas na seção 2.3.4. O
armazenamento em banco de dados da representação geoespacial do objeto é realizada através do
componente PostGIS o qual está incluso ao PostgreSQL.
A elaboração de cartas temáticas para o sistema Pesca Tijucas é realizada através do
componente Mapserver Guarani, o qual é composto pelo componente UMN Mapserver. Estendendo
desta forma as funcionalidades disponibilizadas pelo UMN Mapserver (veja Seção 2.5.2). O
algoritmo proposto disponibiliza ao Mapserver Guarani a funcionalidade para permitir a realização
de análises geoespaciais através de quadrantes.
Ambos os componentes estão dispostos na estrutura do diagrama da Figura 20 a fim de
servir como base para o desenvolvimento do algoritmo e para os demais diagramas especificados.
3.1.9. Protótipo de Tela
Para permitir que o usuário possa inserir os dados para a análise existe a necessidade de uma
tela para tal função, desta forma prototipou-se a tela demonstrada na Figura 21. Esta tela, como
demonstrada na Figura 19 foi implementada diretamente no Mapserver Guarani, tornando-se uma
das telas do sistema.
Para a entrada de dados disponibiliza-se:
• Limites do grid: O usuário deve inserir quais as coordenadas que limitam o espaço e
definem as posições iniciais e finais do grid;
• Dados do grid: especifica quais serão os dados utilizados pela criação da célula, o
usuário através da Granularidade pode definir o intervalo de espaço entre as células,
e através de “Celulas Adjacentes” quantas células vizinhas serão utilizadas para a
análise Kernel;
• Período de análise: permite ao usuário definir através de datas quais os períodos
iniciais e finais de análise, os limites definidos pelo usuário serão utilizados como
restrição aos dados de lance, e;
• Métrica: o usuário poderá escolher qual a métrica (relação) a ser utiliza para a
análise, permitindo ao usuário escolher as definidas no Apêndice I, o usuário
também poderá especificar qual a espécie que deseja pesquisar, caso a métrica utilize
essa informação para o processamento.
Como descrito anteriormente esta tela foi integrada ao Mapserver Guarani e ficará
disponível em sua interface, a comunicação entre ela e as demais classes do Mapserver Guarani
estão demonstradas através das relações existentes no diagrama de classe da Figura 19.
Figura 21: Protótipo de tela
3.2. IMPLEMENTAÇÃO
Esta etapa destaca os aspectos técnicos envolvidos durante a codificação do algoritmo
proposto, demonstrando como os modelos propostos na Seção 3.1 para o projeto foram
implementados. Apresenta ainda a aplicação do conceitos identificados durante a fundamentação
teórica no desenvolvimento da solução.
3.2.1. Introdução
O desenvolvimento deste TCC foi realizado de maneira e seqüencial, partindo de conceitos
teóricos apresentados durante a fundamentação teórica (Capítulo 2. ) e da aplicação dos modelos
elaborados no projeto deste TCC (Capítulo 3. ).
O primeiro dos tópicos apresentados está relacionado com a elaboração de mapas temáticos
que tem uma associação entre gradientes de cores e divisão do espaço visualizado em grid de
células para a que apresentação dos resultados.
3.2.2. Gradiente de cores
A utilização de gradiente de cores em mapas temáticos está intimamente ligado à função
dada à representação a qual o resultado que se deseja expressar. Mapas temáticos podem utilizar
gradientes de cores através de seus três tipos básicos (Seção 2.4.2), sendo que os tipos Isoline e
Choropleth apresentam os melhores modelos para utilização de gradientes, através destes dois tipos
é possível visualizar nuances expressas pelo gradiente.
Como destacado durante a fundamentação teórica, o método de análise provido por este
TCC utiliza um grid para permitir a visualização de mapas do tipo choropleth. A associação entre
grids e gradientes de cores permite uma melhor representação dos resultados da análise geoespacial
e conseqüentemente das relações existentes entre os atributos, quantificando através de cores a
intensidade da ocorrência dos eventos em cada célula do grid.
A Figura 25 apresenta um exemplo desta associação entre mapas do tipo cloropleth com
gradiente de cores, utilizando para isto conceitos apresentados na Seção 2.4.2. Para a elaboração do
mapa temático demonstrado na imagem utilizou-se o UMN Mapserver.
A utilização desta associação possibilita que o grid gerado possa ser utilizado em duas
etapas importantes, para a pesquisa e divisão do espaço, e para a representação dos resultados.
Desta forma evita-se a necessidade da geração de um grid específico para cada situação.
Como citado anteriormente, a Figura 25, juntamente com a Figura 23, foram geradas através
do UMN Mapserver. Desta forma alguns conceitos já podem ser avaliados, como por exemplo, a
geração de células com limites pré-definidos. Os conceitos relacionados à criação de um grid
através do UMN Mapserver serão abordados na próxima seção. Além destes, a aplicação dos
conceitos apresentados na Seção 2.5.1.1 também serão demonstrados.
Por permitir que células sejam geradas dinamicamente o uso do UMN Mapserver como
ferramenta base torna-se válido, pois pode prover os meios de suporte a tal funcionalidade. Além
disto, o UMN Mapserver é a ferramenta que permite com que o framework Mapserver Guarani
possa manipular objetos espaciais.
3.2.3. Mapfile
O uso do arquivo Mapfile torna-se necessário por ser utilizado pelo UMN Mapserver na
definição dos parâmetros utilizados para a criação do mapa temático. O arquivo Mapfile utilizado
por este TCC foi baseado no arquivo já utilizado pelo sistema Pesca Tijucas, apresentando somente
as definições adicionais necessárias para que o mapa com a análise possa ser gerado.
Apesar de o Mapserver Guarani utilizar o Mapserver através do modo Mapscript ainda
existe a necessidade na existência do arquivo Mapfile. Desta forma o arquivo contêm somente as
definições que não sofrerão alteração com a execução do algoritmo proposto, definições como:
cores, tipos de objetos, escala, e unidades do mapa. Esta forma de acesso e parametrização permite
uma simplificação do algoritmo, pois além de utilizar um objeto já funcional com o Mapserver
Guarani não existe a necessidade de definir parâmetros estáticos para o mapa no código do
algoritmo.
Desta forma, para o desenvolvimento deste TCC, foi adicionado ao arquivo Mapfile já
existente uma camada que servirá de base para permitir que células sejam adicionadas de maneira
dinâmica através do Mapserver Guarani para a criação do grid. Assim todas as células utilizam à
mesma base e somente uma única camada é necessária para armazenar os limites de cada célula.
Para a criação de mais de uma célula por camada foi utilizado o objeto FEATURE (Seção
2.5.1.1.1). A Figura 22 apresenta uma versão mais simplificada do mesmo exemplo utilizado na
Figura 10. Através do exemplo abaixo se visualiza que os vários objetos FEATURE são definidos
utilizando somente uma única camada.
A definição demonstrada na Figura 22 foi baseada nas definições apresentadas por Cabral
(2004) para a criação de uma camada no UMN Mapserver que permita a criação de um grid
dinâmico.
layer name "Camada" status on type polygon feature text "Dado Dinâmico 1" points 10 10 15 10 end end feature text "Dado Dinâmico 2" points 15 10 20 10 end end end
Figura 22: Exemplo de objeto layer com a definição de células.
A partir das definições apresentadas na Figura 9, Figura 10, Figura 22, e Seções 2.5.1.1
2.5.1.1.1 criou-se um arquivo Mapfile para ser utilizado em testes realizados com uma camada
objetos do tipo FEATURE. A Figura 23 apresenta a imagem obtida como resultado obtido através
deste teste. Para a geração da Figura 23 o acesso ao UMN Mapserver foi realizado através do modo
CGI.
Figura 23: Grid gerado pelo UMN Mapserver.
Na Figura 23 se pode verificar o grid gerado pela imagem. Cada célula deste apresenta os
limites distintos, mesmo as células que possuem um dos lados idênticos cada uma apresenta suas
próprias definições para os pontos. Assim cada célula pode ser analisada separadamente, não
necessitando da existência de outra célula.
LAYER name "grid" status default type line class name "Grid" style outlinecolor 0 0 0 size 2 end end FEATURE POINTS 0 0 0 40 END END ... END
Figura 24: Camada utilizada para gerar o grid.
A Figura 24 apresenta a camada utilizada para a geração da Figura 23, a partir destas
definições pode-se analisar os parâmetros utilizados, os quais são utilizados para a criação das
células do grid.
Desta destaca-se para a camada da Figura 23:
• Um grid definido com os pontos distanciando-se entre si em cinco, em uma unidade
métrica não específica;
• Um objeto FEATURE para cada célula, tornado cada célula independente, cada
célula é representada através de um objeto FEATURE, desta forma para a acriação
de quarenta células é necessário quarenta objetos feature;
A Figura 25 apresenta uma imagem com a mesma camada demonstrada anteriormente, mas
agora com um gradiente de cores associado. As cores utilizadas foram baseadas nos esquemas de
cores já utilizados pelo sistema Pesca Tijucas, e que já está em uso pelos especialistas.
Figura 25: Células expressas em gradiente de cores.
Desta forma demonstra-se que através do UMN Mapserver células podem ter seus valores
expressos através de cores de um gradiente. Assim possibilitando que as mesmas células criadas
durante a execução do algoritmo para a análise possam ter o resultado de sua análise expresso
através de cores.
Com a realização do teste de criação de um grid com células independentes e que
apresentem valores dinâmicos verificou-se que o UMN Mapserver pode ser utilizado para tal fim.
Permitindo assim a base para o desenvolvimento da classe e objeto Celula especificada no
diagrama de classe (Seção 3.1.7), assim cada objeto Celula terá algumas definições especificadas
diretamente no arquivo Mapfile. Também a partir deste teste pode-se avaliar e validar o UMN
Mapserver, um dos componentes utilizados neste TCC, como definido no diagrama de componentes
(Seção 3.1.8). O arquivo Mapfile utilizado para testes está disponível no Apêndice II.
A próxima seção irá complementar as definições apresentadas nesta seção, discutindo as
aplicações práticas dos conceitos apresentados durante a fundamentação teórica. Especificamente, a
próxima seção, irá abordar aspectos práticos do Mapserver Guarani, acesso via Mapscript e da
integração entre o Mapserver Guarani e o sistema Pesca Tijucas.
3.2.4. Mapserver Guarani
Atualmente, o sistema Pesca Tijucas utiliza o Mapserver Guarani como interface geradora
de mapas temáticos, separando desta forma os módulos de cadastro do módulo webgis utilizados no
sistema. Toda a comunicação realizada entre os módulos de cadastro e de visualização webgis é
realizada através de banco de dados, compartilhando assim a mesma fonte de dados.
Desta forma, as alterações realizadas durante este TCC foram focadas diretamente na
interface webgis, não fazendo parte do escopo e nem da modelagem deste TCC alterações em
módulos de cadastro do sistema e modelos de dados.
Como citado na Seção 2.5.2 o Mapserver Guarani utiliza o UMN Mapserver pelo seu modo
Mapscript, através da linguagem PHP e codificado de forma estruturada, sem seguir a modelagem
de orientação a objetos. Apesar disto, à implementação das funções pertinentes a este TCC foram
realizadas, em sua grande maioria, utilizando conceitos de orientação a objetos. As implementações
a realizadas no modulo Mapscript do Mapserver Guarani serão explicadas em seções posteriores.
As alterações realizadas na interface web do Mapserver Guarani são referentes à adição da
nova funcionalidade análise espacial de esforço de pesca, como demonstrado pelo protótipo de tela
na Figura 21. Modificações estas pertinentes à forma como tal funcionalidade será disponibilizada
ao usuário, qual o módulo do Mapserver Guarani será alterado para permitir tal função.
Dentre as funcionalidades apresentadas na Seção 2.5.2 e através da análise da Figura 12
identifica-se que estas estão agrupadas em:
• Legenda;
• Carta Temática;
• Temas;
• Pesquisa;
• Análise Espacial, e;
• Calcular Distâncias.
A geração de análise espacial de esforço de pesca apresenta-se como um subconjunto de análise espacial, optando-se assim pela modificação do módulo Análise Espacial disponibilizado pelo
Mapserver Guarani, a
Figura 26 apresenta um recorte do menu do framework com a disposição original de tal
módulo e a mudança na interface para suportar a geração da análise pesqueira, e permitir que a tela
prototipada durante a modelagem possa ser implementada.
Desta forma, através do novo menu de Análise Espacial, o usuário pode inserir os
parâmetros desejados e necessários para a geração do grid e da análise. Para permitir tal integração
entre o modelo e o Mapserver Guarani ocorreu a alteração do script PHP tree.php e também do
script Javascript selecao.js. Ambas as alterações refletem as classes propostas no diagrama de classe
da Figura 19.
Para permitir que os parâmetros sejam repassados conforme modelado o usuário ao clicar no
botão “Enviar Dados”, disponível na tela, dispara a execução do fluxo modelado através da função
VerificaDadosKernel. Função esta responsável por validar os parâmetros informados e realizar a
comunicação com o script selecao.js através da função EnviaDadosKernel.
(a) (b)
Figura 26: Em (a) é apresentado o menu original, substituído pela funcionalidade implementada (b)
A alteração necessária ao Mapserver Guarani está demonstrada na
Figura 26 permitirá ao usuário especificar os parâmetros necessários. Os campos de envio de
dados disponíveis na tela de análise são os mesmos que os demonstrados no protótipo proposto na
Seção 3.1.9 e com as mesmas ações propostas para o diagrama de seqüência da Figura 16.
Para permitir que os dados informados pelo usuário possam ser enviados ao Mapscript existe
a necessidade da alteração do código fonte de scripts internos do Mapserver Guarani. Desta forma
as alterações devem ser:
• Script selecao.js: As modificações neste arquivo englobam as necessárias para
permitir que os dados inseridos sejam enviados ao Mapscript. A função que permite
tal funcionalidade é baseada na função DesenhaMapa, acrescida dos parâmetros para
o envio dos dados. A função DesenhaMapa também foi alterada para permitir ao
usuário utilizar todas as funcionalidades do Mapserver Guarani sem perder o grid
gerado, e;
• Script mapscript.mphp: Este arquivo realiza todas as manipulações com os objetos
espaciais para a geração do mapa temático no Mapserver Guarani. Para a integração
com as classes a serem implementadas nesse TCC este script terá adicionada à
instância da classe Algoritmo_Analise_Geoespacial e a chamada ao seu método que
permite a análise pelo método Kernel.
O código fonte modificado destes dois arquivos encontra-se no Apêndice II e segue o
modelo especificado no capítulo 3. Bem como dos conceitos identificados durante a fundamentação
teórica.
3.2.5. Cadastro de camada
Para permitir que qualquer camada definida no arquivo Mapfile seja visível na interface web
é necessário realizar o cadastro da mesma no módulo administrativo do Mapserver Guarani. Desta
forma, mesmo que a camada do grid esteja definida no arquivo Mapfile, ela deve ser cadastrada no
sistema para que se torne visível e passível de ser manipulada pelo Mapscript.
Para a verificação da visualização de grid através do Mapserver Guarani a mesma camada
demonstrada na Figura 24 foi configurada e disponibilizada para a interface através do módulo de
configuração de camadas. A Figura 27 apresenta quais foram os parâmetros passados ao módulo
para que tal camada fosse disponível.
Figura 27: Módulo de configuração de camadas para o Mapserver Guarani
A configuração foi realizada seguindo os seguintes passos:
• Adição da camada da Figura 24 no arquivo Mapfile utilizado pelo sistema Pesca
Tijucas;
• Configuração via modulo do Mapserver Guarani, para disponibilização da nova layer
através do menu Camadas (em amarelo), como demonstrado através da Figura 27, e;
• Visualização da camada através do Mapserver Guarani, demonstrado na Figura 28.
Figura 28: Grid visualizado através do Mapserver Guarani.
A Figura 28 demonstra a mesma camada da Figura 23 e Figura 24 visualizada através do
Mapserver Guarani, como demonstrado na Figura 28 a camada referente ao grid está disponível
através da aba Temas. Configuração esta realizada automaticamente pelo módulo de administração
de camadas do Mapserver Guarani, não necessitando de alteração em código para tal disposição.
Para a visualização do grid com o resultado da análise espacial a camada Grid deverá estar
configurada no sistema, como já realizado e demonstrado na Figura 27, e habilitada antes de se
realizar a estatística pesqueira na aba Análise Espacial.
Na próxima seção será realizada a continuidade dos conceitos abordados durante esta seção,
demonstrando a manipulação da layer disponibilizada através do módulo Mapscript, permitindo
assim a criação do grid de forma dinâmica e não mais de maneira estática como realizado até o
momento. Tal manipulação seguirá as especificações propostas pelos diagramas da modelagem
UML deste TCC, principalmente pelo diagrama de atividades (Seção 3.1.6).
Nesta seção demonstrou-se como foi realizada a integração do algoritmo proposto com o
sistema Pesca Tijucas e sua interface webgis: Mapserver Guarani, além da visualização através da
Figura 26 de como foi disponibilizada no sistema o acesso à análise de estatística pesqueira.
Os testes para esta etapa somente podem ser validados quando o algoritmo já estiver
completamente implementado. Pois é a partir os dados enviados pela tela que o grid será gerado.
Caso os valores estejam sendo enviados corretamente eles poderão ser lidos no Mapserver Guarani
e utilizados para a geração do grid. Como citado anteriormente nesta seção os códigos estão
disponíveis no Apêndice II.
3.2.6. Grid dinâmico
Durante a seção anterior demonstrou-se à integração e visualização de uma camada com um
grid no Mapserver Guarani. Tal camada apresentava um grid definido de maneira estática, tendo
seus valores definidos diretamente no arquivo Mapfile, como demonstrado na Figura 24.
Como especificado na modelagem do sistema, o algoritmo deste TCC deverá prover a geração dinâmica do grid através dos parâmetros informados pelo usuário através do menu apresentado na
Figura 26, para permitir tal funcionalidade foi desenvolvido uma função que permita gerar tal grid com os parâmetros enviados
.... for ($f = 0; $f < ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna); $f++) { /* Instanciando a célula com os dados encontrados. */ $this->Instancia_Celula( $this->Cria_Janelas_Grid($f), $this->aArrDadosLanceCel[$f]); } ...
Figura 29: Exemplo de execução dnção para cálculo dos limites.
A Figura 29 apresenta um trecho de código retirado da classe
Algoritmo_Analise_Geoespacial, o qual apresenta a chamada a função responsável por gerar a
célula do grid.
A função responsável por gerar as células do grid é Cria_Janelas_Grid que apresenta como
parâmetro qual o índice da célula que se deseja calcular os limites. Para a realização de tal cálculo
utilizou-se aritmética simples para calcular as posições dos pontos limites da célula a partir da
origem do grid. A movimentação baseia-se na relação existente entre o número de linhas e colunas,
juntamente com os limites definidos do grid.
A partir da análise da Figura 29, destaca-se que para calcular quais os limites da célula
somente é necessário passar o índice da mesma, sendo que as células são identificadas
seqüencialmente da esquerda para a direita começando do canto superior direito. Todas as células
são geradas pelo método utilizando-se a mesma granularidade.
O retorno desta função é um array contendo cinco elementos, pontos espaciais. Sendo que o
primeiro e o último ponto são idênticos a fim de criar-se um polígono fechado, conceito
especificado pelo consórcio OGC. Optou-se pelo retorno desta função ser somente os limites da
célula e não o objeto célula em si, pois o resultado esperado para esta função são os limites da
célula e não um objeto.
O código fonte da função está disponível no Apêndice II sendo a linguagem PHP utilizada
pra desenvolvimento. Esta função serve de base para o desenvolvimento de todo o grid proposto
para este TCC, bem como de todas as células a serem utilizadas na análise espacial.
Na seção seguinte será demonstrado como esta função foi integrada ao fluxo de execução da
classe principal do algoritmo proposto, além de abordar como o algoritmo proposto foi integrado ao
script Mapscript do Mapserver Guarani.
3.2.7. Objetos espaciais
Nesta seção serão discutidos a aplicação dos conceitos sobre manipulação de objetos
espaciais através do UMN Mapserver, de sua biblioteca PHPMapscript, e do banco de dados
PostGIS.
Para a manipulação de objetos espaciais, como citado na seção 2.5.1, optou-se por adicionar dinamicamente as células ao objeto da camada a ser adicionada ou alterada no Mapscript. Através da Figura 30 pode-se visualizar a forma como os objetos são criados e adicionados através da função Cria_Celula_Correspondente_Mapserver
.... private function Cria_Celula_Correspondente_Mapserver(Celula $pObjCelula, $pObjCelulaMapserver, $pStrTexto) { /* Calculando o índice da célula. */ $lIntIndice = $this->Calcula_Indice_Celula($pObjCelula->getDblValorKernel()); $lArrExtentCelula = $pObjCelula->getExtentCelula(); /* Criando um polígomo fechado para a célula. */ $lObjPoligono = ms_newShapeObj(MS_SHAPE_POLYGON); $lObjLinha = ms_newLineObj(); for ($f = 0; $f < sizeof($lArrExtentCelula); $f++) { $lObjLinha->addXY($lArrExtentCelula[$f][0], $lArrExtentCelula[$f][1]); } $lObjPoligono->add($lObjLinha); /*Setando a qual classe pertence a célula. */ $lObjPoligono->set("classindex", $lIntIndice);
/* Limpando objetos não mais utilizados. */ $lObjLinha->free(); /* Adicionando a célula a objeto do Mapserver guarani. */ $pObjCelulaMapserver->addFeature( $lObjPoligono ); /* Limpando objetos não mais utilizados. */ $lObjPoligono->free(); } ...
Figura 30: Função responsável por cirar os objetos espaciais no UMN Mapserver.
O trecho de código acima foi extraído do arquivo Algoritmo_Analise_Geoespacial que se
encontra no Apêndice II. A análise da Figura 30 permite identificar a comunicação entre as classes
como proposto no diagrama de seqüência da Figura 15. Desta forma implementando a troca de
mensagens entre as classes como proposto no modelo.
Para a adição dos limites das células foi necessária a criação de um objeto do tipo shapeObj,
disponibilizado pelo PHPMapscript específico para dados espaciais e instanciado de maneira a
permitir a criação de polígonos. Sendo que os pontos foram adicionados em um objeto do tipo
lineObj, através da chamada a função addXY.
Após a adição de todos os pontos que compõem o limite estes foram adicionados ao objeto lObjPoligono, criando assim um objeto espacial no UMN Mapserver. Através da função set para o valor classindex pode-se definir a que classe o objeto pertence, podendo assim dividir célula a célula qual a classe que pertencem
.... private function Calcula_Indice_Celula($pDblvalor) { if (is_null($this->aDblValorKernelMaximo)) $this->aDblValorKernelMaximo = 0; if (is_null($this->aDblValorKernelMinimo)) $this->aDblValorKernelMinimo = 0; if ($pDblvalor != 0) { if ($this->aDblValorKernelMaximo != $this->aDblValorKernelMinimo) { $lIntValor = ($pDblvalor - $this->aDblValorKernelMinimo) / ($this->aDblValorKernelMaximo - $this->aDblValorKernelMinimo) * ($this->aIntNumeroClasses - 1); $lIntValor = round($lIntValor, 0); $lIntValor += 1; } else $lIntValor = 1; } else $lIntValor = $pDblvalor; return $lIntValor; } ...
Figura 31: Função para identificar a classe a qual célula pertence.
A Figura 31 apresenta a implementação da função responsável por identificar a qual classe a
célula pertence, esta função é necessária, pois é ela que define em qual intensidade a célula está
inclusa. Para este cálculo utilizam-se dois atributos da classe Algoritmo_Analise_Geoespacial
responsáveis por armazenar os maiores e menores valores calculados para o Kernel, sendo
aDblValorKernelMaximo e aDblValorKernelMinimo respectivamente. O valor calculado por esta
função será utilizado, como demonstrado na Figura 30, na definição de qual classe a célula
pertence.
Depois que todos os pontos foram adicionados ao objeto e este já ter tido sua classe base
definida ele pode ser adicionados ao objeto lObjCelulaMapserver responsável por adicionar os
objetos espaciais à camada do grid.
A Figura 32 demonstra como a função responsável por criar as células no UMN Mapserver pode ser chamada, além de demonstrar como é o acesso aos objetos existentes no arquivo Mapfile. Desta a chamada a todas as células do grid acarreta na passagem dos limites de todas as células analisadas a camada no UMN Mapserver, bem como de sua classificação
.... /* Retornando a camada para a representação do GRID no objeto do Mapserver Guarani. */ $lObjCamadaGrid = $this->aObjMapa->getLayerByName($this->aStrNomeCamadaGridMapserver); for ($f = 0; $f < ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna); $f++) { /* Criando a célula para a visualizacão no Mapserver Guarani. */ $this->Cria_Celula_Correspondente_Mapserver($this->aArrCelulas[$f], $lObjCamadaGrid, $f); } ...
Figura 32: Chamada a função de criação dos objetos espaciais.
A camada grid ao qual as células serão adicionadas e que é acessível através da função
getLayerByName está definida no Apêndice II. Esta camada (layer) foi baseada na apresenta na
seção 3.2.3, onde as alterações necessárias para a camada já definida foram as definições de 11
classes para a definição das corres específicas para cada intensidade, sendo a primeira destas classes
responsável por representar todas as células que apresentaram valor zero retornado pela função da
Figura 31.
O gradiente utilizado para a definição das intensidades foi baseado nas definições
apresentadas nas seções 3.2.3 e 2.4.2.1. As cores foram definidas através do padrão adotado pelo
UMN Mapserver, utilizando as cores vermelho, verde, e amarelo.
3.2.8. Objeto Célula
Para permitir que o objeto Celula proposto na modelagem através do diagrama de classe
demonstrado na Figura 18 fosse criado implementou-se uma classe em linguagem PHP que
provesse tal estrutura. Desta forma os atributos e funções propostos no modelo foram
implementados.
Através este objeto é possível representar e armazenar os objetos de cada célula do grid. Desta forma cada célula do grid pode ser expressa através de um único objeto do tipo Celula, contendo seus limites, valores, e dados de lances
.... private $aIntIndiceClasse; private $aDblArea; private $aDblPosicao_X; private $aDblPosicao_Y; private $aDblPosicao_Z = 0; private $aDblValorKernel; private $aTmpDataInicialAnalise; private $aTmpDataFinalAnalise; private $aArrExtent_Celula; private $aArrDados_Celula; private $aArrValorMetrica; ...
Figura 33: Atributos da classe Celula.
A Figura 33 apresenta os atributos da casse célula, sendo estes encapsulados como privados
para não permitem serem visíveis a outras classes, bem como modificados. Desta forma todo e
qualquer acesso a estes atributos é realizado através de funções específicas para cada um destes.
Pode-se destacar para cada atributo:
• aIntIndiceClasse: atributo responsável por armazenar a qual classe da camada do
grid no UMN Mapserver o objeto está associado;
• aDblArea: atributo que armazena a área da célula;
• aDblPosicao_X, aDblPosicao_Y, aDblPosicao_Z: atributos responsável por
armazenar a posição nos três eixos do ponto central (centróide) da célula. Apresar de
da existência do atributo para o eixo Z o seu valor é automaticamente zero para todos
os objetos;
• aDblValorMetrica: Atributo responsável por armazenar o valor calculado da métrica
para os dados da célula;
• aTmpDataInicialAnalise, aTmpDataFinalAnalise: Atributos para o armazenamento
do período de pesquisa em que se realizou a análise na qual a célula foi instanciada;
• aArrExtent_Celula: atributo responsável por armazenar os limites da célula, os
limites estão armazenados seguindo-se o padrão OGC para definição de limites de
polígonos;
• aArrDados_Celula: atributos que armazena os dados de todos os lances que estão
associados à célula, desta forma é possível implementar a relação modelada no
diagrama de classes, e;
• aArrValorMetrica: atributo responsável por armazenar os valores utilizados para a
relação do cálculo da métrica, os valores das dimensões envolvidas na métrica.
3.2.9. Cálculo da Métrica
Esta seção visa descrever como foi implementado o cálculo da métrica utilizada como base
para a análise Kernel. O cálculo da métrica baseia-se na relação existente entre a célula e os lances
que a pertencem.
Desta forma o cálculo da métrica é realizado para cada célula e leva em consideração
somente os lances que estão contidos nela, ou caso o usuário defina, os lances contidos nas células
adjacentes a atual.
A Figura 34 apresenta a chamada para a função de cálculo de métrica, este trecho de código
foi retirado da função responsável por instanciar o objeto célula. Assim para cada célula instanciada
calcula-se o valor da métrica definida pelo usuário.
Para o cálculo da métrica utilizou-se cálculos matemáticos simples sobre os valores para os
objetos Lance retornados, e estes objetos apresentam a estrutura com os dados organizados através
das seguintes estruturas:
• Array com dados da embarcação: esta primeira estrutura é composta com as
definições do código do lance, nome da embarcação, nome do observador, página
inicial, e página máxima da planilha do lance. São dados que identificam o lance;
• Array com dados do lance: segunda estrutura que contêm as informações referentes à
data e hora inicial de ocorrência do lance, profundidade inicial, velocidade inicial,
profundidade final, velocidade final, quantidade total pescada no lance, e
coordenadas inicial e final do lance. Dados estes que compões as informações do
lance;
• Array com dados de produtos: terceira estrutura que contêm os dados dos produtos
do lance: nome do produto, quantidade do produto, e código do produto, e;
• Array com dados da rede: quarta e última estrutura que apresenta as definições da
rede utilizada no lance: código da rede, número da rede, numero da rede, e constante
da rede.
Todas as definições acima compõem um objeto do tipo lance, e seguem as relações descritas
no diagrama de classe da Figura 18 para a classe Lance, Dados_Controle_Lance, Dados_Produto, e
Rede_Pesca.
A definição completa para a função CalculavalorMetrica está presente no Apêndice II, sendo que as métricas implementadas foram as definidas e presentes na modelagem do sistema
.... /* * Executando a funcão responsável por retornar o valor para os dados da célula * este valor se baseia na métrica estipulada pelo usuário. */ $this->aArrValoresMetrica = $this->CalculaValorMetrica($lObjCelula, $this->aIntMetrica); /* Setando o valor para a célula. */ $lObjCelula->setValorMetricaCelula($this->aArrValoresMetrica); ...
Figura 34: Chamada a função para o cálculo da métrica.
3.2.10. Análise Kernel
A análise Kernel, como destacado na Seção 2.4, realiza o cálculo através de um grid sobre a
área desejada, sendo as células utilizadas como áreas distintas de análise, compondo objetos
distintos e com propriedades diferentes.
Para permitir que tal análise fosse gerada através do UMN Mapserver foi necessário
desenvolver um método que possibilitasse gerar células de maneira dinâmica, com parâmetros
dinâmicos. O método utilizado para a geração das células do grid foi descrito na Seção 3.2.6. Desta
forma o resultado retornado por este pode ser utilizado diretamente na criação da célula do grid.
O desenvolvimento do código responsável por gerar a análise foi iniciado a partir da relação
que pode ser extraída entre os dados de esforço de pesca, e área de pesca (célula). Desta forma
relações que utilizam à localização espacial podem ser identificadas e visualizadas de maneira mais
precisa. Permitindo ao especialista identificar através do mapa áreas de risco ou que estão
apresentando algum padrão anormal.
A partir da equação apresentada na seção 2.4.1.1.1 o código fonte da Figura 35 foi desenvolvido, e a partir de sua análise é possível identificar que este apresenta como único parâmetro um objeto do tipo célula. Sendo necessariamente este objeto já ter sido instanciado com os valores de lances e da relação da métrica utilizadas
.... private function Analise_Geoespacial_Da_Janela(Celula $pObjCelula) { if ($this->aIntTau > 0) { $lDblKDimensao1 = 0; $lDblKDimensao2 = 0; $lDblKTotal = 0; $lDblKFinal = 0; $lDblKSoma = 0; $lArrDados = array(); /* Contante FatorU. */ $lDblFatorU = 3/pi(); /* Calculando o Tau para a célula. */ $lDblTau = sqrt( pow(($this->aDblGranularidade_Grid)/2,2) + pow(($this->aDblGranularidade_Grid)/2,2) ); $lDblTau *= ($this->aIntTau+1); /* Retornando o ponto central da célula. */ $lArrPosicoes = $pObjCelula->getCoordenadaPontoCelula(); $lDblPosicaoX = $lArrPosicoes[0]; $lDblPosicaoY = $lArrPosicoes[1]; /* Retornando os registros para a célula. */ $lArrDados = $pObjCelula->getArrDadosCelula(); for ($f = 0; $f < sizeof($lArrDados); $f++) { if ($lArrDados[$f][1][9] != null && $lArrDados[$f][1][10] != null) { /* Calculando a posicão relativa de X em relacao a celula. */ $lDblDX = $lDblPosicaoX-$lArrDados[$f][1][9]; /* Calculando a posicão relativa de X em relacao a celula.*/ $lDblDY = $lDblPosicaoY-$lArrDados[$f][1][10]; /* Calculando a lozalizacão do dado, basedado em TAU. */ $lDblSSi = sqrt( pow($lDblDX,2) + pow($lDblDY,2) )/$lDblTau; if ($lDblSSi <= 1) $lDblK = pow( 1-$lDblSSi*$lDblSSi, 2)*$lDblFatorU; else $lDblK = 0; $lDblKDimensao1 += $lDblK*$lArrDados[$f][4][1]; $lDblKDimensao2 += $lDblK*$lArrDados[$f][4][2]; $lDblKTotal += $lDblK*$lArrDados[$f][4][0]; } } if ($lDblKDimensao2 != 0) { $lDblKFinal = $lDblKTotal; $lDblLambda = $lDblKFinal; } else {
$lDblLambda = 0; } return $lDblLambda; } else { return $pObjCelula->getDblValorMetricaPos(0); } } ...
Figura 35: Codificação da função de cálculo do método Kernel.
Como demonstrado na Figura 35 a primeira execução realizada pelo método é responsável
por verificar se o usuário deseja aplicar ou não a análise espacial sobre os dados ou somente uma
plotagem dos valores no grid.
Através da análise do trecho de código demonstrado é possível verificar a necessidade de
pesquisar o ponto central da célula, apresentando a dependência existente entre a análise Kernel a
célula. Isso pode ser observado através da chamada a função getCoordenadaPontoCelula. Bem
como dos array de dados que compõem a célula.
As funções para cálculo de tau e das relações espaciais foram baseadas na equação já
demonstrada para o método. Sendo que para o cálculo da relação espacial utilza-se no cálculo as
posições relativas às coordenadas dos lances de pesca com o centro da célula, desta forma é
possível identificar a sua distância em relação ao centro da célula de qual seu peso em relação à
célula. Desta forma pontos que estejam mais afastados da célula apresentam um peso menor em
relação aos mais próximos. A função apresentada na Figura 25 foi baseada na Equação 1 além de
conceitos apresentados na Seção 2.4.1.1.1.
Após o cálculo da relação para todos os lances que compõem a célula é possível retornar o
resultado para a análise Kernel. Sendo este posteriormente utilizado como meio de classificação da
classe a qual pertence à célula, como demonstrado na seção anterior.
3.2.11. Fluxo PrinciPal De Execução
Esta seção descreve o fluxo principal de execução do algoritmo proposto nos diagramas de
seqüência e atividades das Figura 16, Figura 15, e Figura 17 foi implementado neste projeto,
demonstrando também como conceitos teóricos e de seções anteriores foram aplicados.
As três primeiras mensagens do fluxo principal de execução são responsáveis por:
• VerificaDadosKernel: mensagem que representa a interação do usuário com a tela,
apresentado o envio de dados para a tela. Esta mensagem está implementada através
da função VerificaDadosKernel, presente no código fonte da tela;
• EnviaDadosKernel: mensagem que representa a comunicação entre a tela
implementada e o script selecao.js provido pelo Mapserver Guaraní, após esse envio
o fluxo passa a ser independente do usuário. A função que provê esta mensagem está
implementada no código fonte do script selecao através de EnviaDadosKernel, e esta
sendo chamada internamente na tela implementada, e;
• EnviaDados: mensagem de comunicação entre o script selecao.js e o PHPMapscript
do Mapserver Guarani, esta mensagem é responsável por enviar os dados ao código
que apresenta a iteração como Mapserver. A implementação desta mensagem está
presente no código fonte do script selecao.js, na função EnviaDadosKernel, a qual
adiciona os parâmetros a serem enviados ao Mapscript.
Estas mensagens são necessárias para que os dados enviados pelo usuário sejam enviados ao
Mapscript e assim passíveis de serem enviadas ao algoritmo implementado. Estas três mensagens
descritas acima implementam o fluxo do diagrama seqüência presentes na Figura 16, e representa o
pacote Mapserver Guarani no digrama da Figura 15. Os conceitos para a implementação destas
mensagens foram descritos na Seção 3.2.4.
Somente após estas mensagens serem executadas o fluxo principal da Figura 15 pode ter
continuidade através da mensagem Realiza_Analise_Geoespacial. Esta sendo responsável por
enviar os dados à classe Algorítmo_Analise_Geoespacial. O recebimento dos dados no a
instância desta classe no script mapscript.mphp estão descritas na Figura 36.
... $lIntMetrica = $kernelmetrica; $lIntTau = $kerneltau; $lDblGranularidade = $kernelgranularidade; $lTmpDataInicial = $kerneldataini; $lTmpDataFinal = $kerneldatafim; $lArrExtent = array($kernelminx, $kernelminy, $kernelmaxx, $kernelmaxy); $lObjAnaliseGrid = new Algoritmo_Analise_Geoespacial(); $lObjAnaliseGrid->Realiza_Analise_Geoespacial($lArrExtent, $lDblGranularidade, $lTmpDataInicial, $lTmpDataFinal, $lIntMetrica, $lIntTau, $lIntCodEspecie,$mapa); ...
Figura 36: Instância do objeto da classe de análise.
A mensagem Identifica_Dados_Grid, executada posteriormente, é responsável por calcular
os valores para a criação do grid. Esta mensagem está implementada na classe
Algoritmo_Analise_Geoespacial através da função privada Identifica_Dados_Grid. Sendo esta
descrita na Figura 37 e responsável por calcular o número de linhas e colunas passíveis de serem
criadas dentro dos limites definidos pelo usuário.
Esta função também calcula a correção necessária para o valor máximo em X e mínimo em Y do grid, evitando assim que células incompletas sejam criadas. Para isto é necessária à execução da função Cria_Janelas_Grid tendo como parâmetro a última célula para identificação dos limites da última célula do grid, desta execução está representando a mensagem Cria_Janelas_Grid descrita no digrama de seqüência da Figura 16
.... private function Identifica_Dados_Grid() { /* Inicializando as variáveis com os dados de célula e coluna do GRID. */ $this->aIntNumeroCelulaColuna = ceil(abs($this->aArrExtent[0] - $this->aArrExtent[2])/$this->aDblGranularidade_Grid); $this->aIntNumeroCelulaLinha = ceil(abs($this->aArrExtent[1] - $this->aArrExtent[3])/$this->aDblGranularidade_Grid); /* Verifiando a última célula para correcão ddo Xmax e Ymin do GRID. */ $lArrJanela = $this->Cria_Janelas_Grid(($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna)-1); if ( $lArrJanela[1][0] > $this->aArrExtent[2] ) $this->aArrExtent[2] = $lArrJanela[1][0]; if ( $lArrJanela[2][1] < $this->aArrExtent[1] ) $this->aArrExtent[1] = $lArrJanela[2][1]; } ...
Figura 37: Função que identifica os valores do grid.
Em seqüência a estas duas existe a mensagem Busca_Lances_Total e implementada através
de função de mesmo nome, a qual é responsável por identificar todos os lances que estejam
contidos dentro dos limites do grid. Para tal pesquisa utiliza-se diretamente o PostGIS através de
pesquisa espacial.
Internamente a esta função, após o retorno de todos os lances de banco de dados, é necessária a identificação de qual célula pertence o lance. Esta identificação é realizada através de um cálculo simples de deslocamento em matriz na função Calcula_Celula_Lance. A implementação da função para a
realização deste cálculo na Figura 38.... private function Calcula_Celula_Lance($pDblX, $pDblY) { $lDblPosRelY = ( ($pDblY)-($this->aArrExtent[1]) )/( ($this->aArrExtent[3])-($this->aArrExtent[1]) ); $lDblPosRelY = min( floor( (1 - $lDblPosRelY)*$this->aIntNumeroCelulaLinha ), $this->aIntNumeroCelulaLinha-1 ); $lDblPosRelX = ( ($pDblX)-($this->aArrExtent[0]) )/( ($this->aArrExtent[2])-($this->aArrExtent[0]) ); $lDblPosRelX = min( floor( $lDblPosRelX*$this->aIntNumeroCelulaColuna ), $this->aIntNumeroCelulaColuna-1 ); $lDblPosRel = $lDblPosRelY * $this->aIntNumeroCelulaColuna + $lDblPosRelX; return $lDblPosRel; }
Figura 38: Função pra identificar a qual célula o lance pertence.
Caso o usuário informe um número de células adjacentes maior que zero o algoritmo
necessita identificar o número de células adjacentes que devem ser utilizadas para o cálculo do grid
a ser utilizado no Kernel. Este fluxo está identificado dentro do fluxo principal través das funções
presentes na Figura 39.
... private function Calcula_Celulas_Tau($pIntIndice) { $lStrCelulas = ""; for ($f = 1; $f < $this->aIntTau; $f++) { $lIntIndCelula1 = $pIntIndice - ( $f * $this->aIntNumeroCelulaColuna); $lIntIndCelula2 = $pIntIndice + ( $f * $this->aIntNumeroCelulaColuna); if ($lIntIndCelula1 >= 0 && $lIntIndCelula1 < ($this->aIntNumeroCelulaColuna*$this->aIntNumeroCelulaLinha)) $lStrCelulas .= " ".$lIntIndCelula1; if ($lIntIndCelula2 >= 0 && $lIntIndCelula2 < ($this->aIntNumeroCelulaColuna*$this->aIntNumeroCelulaLinha)) $lStrCelulas .= " ".$lIntIndCelula2; } return $lStrCelulas; } private function Celulas_Inclusas_Tau($pIntIndOrig) { /* Encontrando qual a linha atual que está a célula de origem. */ $lIntLinhaAtual = floor($pIntIndOrig/$this->aIntNumeroCelulaColuna); $lStrCelulas = $pIntIndOrig; $lArrCelulas = array(); /* Verificando as celulas adjacentes a de origem. */ $lStrCelulas .= $this->Calcula_Celulas_Tau($pIntIndOrig); for ($l = 1; $l < $this->aIntTau; $l++) { $lIntIndeColAtual = $pIntIndOrig - $l; /* Verificando se a célula se encontra fora dos limites. */ if (floor($lIntIndeColAtual/$this->aIntNumeroCelulaColuna) == $lIntLinhaAtual) { $lStrCelulas .= " ".$lIntIndeColAtual; $lStrCelulas .= $this->Calcula_Celulas_Tau($lIntIndeColAtual); } $lIntIndeColAtual = $pIntIndOrig + $l; /* Verificando se a célula se encontra fora dos limites. */ if (floor($lIntIndeColAtual/$this->aIntNumeroCelulaColuna) == $lIntLinhaAtual) { $lStrCelulas .= " ".$lIntIndeColAtual; $lStrCelulas .= $this->Calcula_Celulas_Tau($lIntIndeColAtual); } } return ( explode(" ", $lStrCelulas) ); } ...
Figura 39: Cálculo de células adjacentes.
As células contidas no grid são instanciadas e analisadas individualmente em um único
fluxo, como demonstrado na Figura 15 e Figura 17. Desta forma calcula-se a métrica para cada
célula, sendo este valor utilizado para o método Kernel ou servindo de base caso o usuário informe
um número de células adjacentes igual à zero.
A análise espacial através do método Kernel pode ser visualizada através da função
Análise_Geoespacial_Da_Janela do diagrama de sequência da Seção 3.1.5 e de sua implementação
como demonstrado na Figura 35.
Através da função apresentada é possível identificar a condição que verifica a necessidade
ou não da geração da análise, como descrito no diagrama de seqüência. Sendo que quando o usuário
deseja realizar a análise o cálculo é executado, seguindo como base a fórmula apresentada na seção
2.4.1.1.1. Caso contrário somente o valor calculado para a métrica é utilizado. A implementação da
fórmula para o método Kernel pode ser identificada na Figura 35, identifica-se que o cálculo leva
em consideração a distância entre a ocorrência do evento e o centro da célula, desta forma quanto
mais afastado menor o peso deste no resultado acumulado para a célula.
Depois do valor de Kernel calculado para cada célula é possível representá-las no UMN
Mapserver, adicionando-as na camada do grid através do PHPMapscript. Para que tal representação
fosse possível e a mensagem Cria_Celula_Correspondente_Mapserver fosse implementada criou-se
uma função de mesmo nome que a partir da leitura dos limites do objeto da célula fosse possível
criá-la para a camada do grid.
A chamada a esta função pode ser identificada na Figura 32 e a sua implementação na
Figura 30. Desta forma através de conceitos apresentados na Seção 3.2.3 podem-se criar os objetos
espaciais para cada célula e adicioná-los a camada do grid. Os objetos para cada célula são
representados por polígonos, como observado na chamada a função ms_newShapeObj da Figura 30.
Desta forma após todas as células terem sido repassadas ao UMN Mapserver o fluxo retorna
ao Mapserver Guarani que pode desenhar o mapa temático com o resultado da análise Kernel. Este
retorno ocorre ao finalizar-se o laço de iterações da Figura 32, e assim também o fluxo principal do
algoritmo, da mesma maneira como proposto nos diagramas de seqüência e atividades.
A execução completa desse fluxo apresenta como resultado um grid gerado para os limites
definidos pelo usuário e que expressa a análise Kernel sobre os dados de lance (esforço) de pesca
disponíveis.
3.2.12. Resultados
Esta seção apresenta alguns resultados obtidos com a execução do algoritmo, resultados
estes visualizados através do Mapserver Guarani e com base nos valores existentes no sistema Pesca
Tijucas.
A Figura 40 apresenta o resultado da análise pelo método Kernel obtido através da execução
do algoritmo. Os valores informados para esta análise foram:
• Limites: os limites mínimos foram 33 no eixo X e 19 no eixo Y, os limites máximos
foram 57 no eixo X e 31 no eixo Y;
• Grid: para a granularidade foi 0.5 para a geração e um número de 10 para células
adjacentes consideradas na análise;
• Período: a data inicial para análise foi 01/01/2005 e a final foi 01/09/2005;
• Métrica: a métrica utilizada para este resultado foi a quantidade pescada dividida
pelo tempo de arrasto do lance, e:
• Dados: foram utilizados 70 registros existentes no banco de dados do sistema Pesca
Tijucas para teste.
Figura 40: Resultado da análise.
A Figura 41 representa o resultado de outra análise sobre os mesmos dados, onde as únicas
variações com os dados utilizado na Figura 40 foram os limites do grid e o número de células
adjacentes utilizadas na análise. Porém o foco desta figura não está no resultado e sim na integração
do resultado com as outras funcionalidades do Mapserver Guarani, desta forma é possível utilizar as
outras funcionalidades sem perder a o resultado gerado.
Figura 41: Resultado da análise.
Mais testes poderão ser realizados quando os dados passíveis de análise forem inseridos no
sistema Pesca Tijucas, por hora é possível analisar a capacidade do UMN Mapserver e do
Mapserver Guarani como ferramentas que possibilitam a geração de mapas temáticos que
expressem o resultado da análise espacial pelo método Kernel.
O resultado da aplicação do método depende de outros fatores além da ocorrência espacial,
os parâmetros definidos pelo usuário na tela para a criação do grid influenciam a análise gerada. O
conjunto de valores para a granularidade (utilizado para geração das células) e do número de células
adjacentes (valor considerado para a análise) quando aplicados podem apresentar resultados
diferentes para o mesmo espaço de análise.
A Figura 42 apresenta o resultado da análise Kernel sobre os mesmos dados da Figura 41,
sendo que as diferenças existentes entre ambas estão relacionadas ao número de células adjacentes
utilizadas para análise, enquanto na Figura 42 definiu-se o valor 2 para células adjacentes o
resultado da Figura 41 foi calculado-se utilizando 1 para o mesmo dado.
Isso ocorre devido à possibilidade do usuário definir a largura de banda desejável, mesmo
que esta não reflita na ideal para os dados existentes. Desta forma cabe ao usuário informar o valor
desejado e a partir dos resultados avaliar se estes são válidos. Os conceitos relacionados a largura de
banda foram abordados na Seção 2.4.1.1.1.
Figura 42: Resultado da análise.
4. CONCLUSÃO
Este projeto de TCC teve como enfoque no desenvolvimento de um algoritmo para análise
geoespacial via internet, baseada no método de Kernel. Tal ferramenta visa permitir uma melhor
análise dos estoques pesqueiros para efeito de gestão e sustantabilidade em seu uso. Ou seja, para
gerar subsídeos aos especialistas no momento do planejamento e tomada de decisão.
Durante a pesquisa para identificação dos conceitos que fundamentaram este TCC percebeu-
se um número relativamente reduzido de projetos orientados a análise geoespacial da atividade
pesqueira. Muitos dos textos encontrados citavam apenas aplicativos desktop para a cundução deste
tipo de análise, apontando para uma deficiência no desenvolvimento de aplicações web orientadas
ao compartilhamento de dados e infromações. Parte desta deficiência vem da própria ausência de
georreferenciamento da atividade de captura pesqueira, e parte devido a dificuldade de manipulação
de objetos geoespaciais via web. Tal dificuldade se deve em parte as limitações impostas pela banda
de acesso à internet, no momento sendo derrubada; pela limitada capacidade de processamento dos
servidores, principalmente frente à grande quantidade de registros de dados meio ambiente, de
modo geral; e finalmente ao estado da arte em geotecnologias que somente a pouco mais de cinco
anos passou a empregar a internet como meio de operação.
Assim, para atender a objetivo do trabalho forma avaialadas as tecnologias disponíveis para
manipulação de objetos, quais as arquiteturas de banco de dados para objetos geoespaciais e quais
os métodos que permitem a leitura otimizada dos mesmos. Estes elementos foram abordados e
detalhados durante a fundamentação teórica, e eventualmente aplicados durante a modelagem e
implementação do algoritmo. O uso de ferramentas como UMN Mapserver, Mapserver Guarani,
PHP, PostgreSQL e PostGIS foram fundamentais para o desenvolviemto deste trabalho. A forma
como a integração entre estas ferramentas foi realizada permitiu que a implementação ficasse
inteiramente focada com a manipulação dos objetos geoespaciais via Web e em grid dinâmico, já
que métodos de visualização e armazenamento estavam disponíveis nas ferrametas.
Este tipo de análise geoespacial, frente as dificuldades de operação via web anteriormente
apresentadas, não possui registro na literatura, sendo, portanto, uma nova abordagem em WebGIS.
O método Kernel constituiu-se numa das alternativas de análise geoespacial, escolhido pelo
largo emprego em sistemas residentes e pela facilidade de representação em grid das análises. No
entanto, apesar dos resultados alcançados indicarem o potencial uso deste tipo de análise via web,
fazem-se necessários testes não apenas com grandes volumes de dados, mas também com outras
alternativas, como por exemplo os métodos K, de Krigagem, multivariogramas, entre outros.
Sugere-se o monitoramento e avaliação do desempenho de aplicações de WebGIS munidas destes
métodos de análise, bem como prós e contras a sua disseminação aberta entre usuários da internet.
Em outras palavras, uma avaliação das restrições que se aplicam.
Em termos da análise propriamente dita, o algoritmo incoporado ao Mapserver Guarani
atendeu ao objetivo proposto pelo trabalho. O banco de dados do Projeto Pesca Tijucas irá ser
utilizado para ajustes e finalização do algoritmo ora desenvolvido. Após esta fase o método será
disponibilizado como open source junto ao Mapserver Guarani.
REFERÊNCIAS BIBLIOGRÁFICAS
AQUAGIS. Aquaculture GIS: aquaculture information and mapping. 2004. Disponível em: <http://www.aquagis.com/aquamap.asp>. Acesso em: 07 nov. 2004.
BAILEY, T. C. A review of spatial analysis in geographical information systems. In: FOTHERINGHAM, S.; ROGERSON, P. (Ed). Spatial analysis and GIS. London: Taylor & Francis, 1994. p. 13-44.
BAILEY, T. C.; GATRELL, A. C. Interactive spatial data analysis. London: Longman, 1995.
BAKKEN, S. S.; SCHMID, E. (Ed.). PHP Manual. PHP Group, 27 abr. 2004. Disponível em: <http://www.php.net/docs.php>. Acesso em: 23 abr. 2005.
BRANDÃO, W. Utilização de métodos geoestatísticos de Krigeagem ordinária e Krigeagem por indicação na interpolação de dados geoquímicos de solos. 2000. Disponível em: <http://www.dpi.inpe.br/cursos/ser301/trabalhos/pojuca.pdf>. Acesso em: 06 nov. 2004.
CABRAL, R. B. Webmaping with MapServer. PHP Architect, jul. p. 25-35, 2004. Disponível em: <http://www.phparch.com>. Acesso em: 15 set. 2005.
CARNEIRO, E. O.; SANTOS, R. L. Análise espacial aplicada na determinação de áreas de risco para algumas doenças endêmicas (calazar, dengue, diarréia, d.s.t. – doenças sexualmente transmissíveis e tuberculose), no bairro de campo limpo – Feira de Santana (BA). Revista Sitientibus, Feira de Santana, n. 28, p. 51-75. jan./jun. 2003.
CASANOVA, M.; DAVIS, C.; VINHAS, L.; QUEIROZ, G. R. de.; CÂMARA, G. Banco de dados geográficos. Curitiba: MundoGEO, 2005. 506 p.
CRISPINO, F. Reconfiguração de redes primárias de distribuição de energia elétrica utilizando o sistema de informações geográficas. 2001. Dissertação (Mestrado em Engenharia) – Ecola Politécnica da Universidade de São Paulo, São Paulo, 2001.
DEFRA. UK sea fisheries statistics. 2003 Disponível em: <http://statistics.defra.gov.uk/esg/publications/fishstat/uksfs03.pdf>. Acesso em: 09 nov. 2004.
FAO. Fishery statistics: reliability and policy implications. 2004. Disponível em: <http://www.fao.org/DOCREP/FIELD/006/Y3354M/Y3354M00.HTM>. Acesso em: 08 nov. 2004.
FEAT. Index of/ material/sistema de informação/4º semestre/analise e projeto de sitema I. Faculdade de Educação, Administração e Tecnologia de Ibaiati, 2001. Disponível em: <http://www.feati.com.br/material/Sistemas%20de%20Informa%e7%e3o/4%ba%20Semestre/Analise%20e%20Projeto%20de%20Sistemas%20I/>. Acesso em: abr. 2005.
FIGIS. – Fisheries Global Information System .Disponível em: <http://www.fao.org/figis/servlet/static?dom=root&xml=index.xml>. Acesso em: 07 nov. 2004.
FIS. What is the fisheries information system (FIS)?. 2004. National Marine Fisheries Service (NMFS), Office of Science and Technology. Disponível em: <http://www.st.nmfs.gov/fis/index.html>. Acesso em: 07 nov. 2004.
GEP. Boletim estatístico da pesca industrial de Santa Catarina - Ano 2000. 2000. Disponível em: <http://gep.cttmar.univali.br/download/pdf/boletim_2000.pdf>. Acesso em: 07 nov. 2004.
GEP. Estatística pesqueira industrial de Santa Catarina (Meta 1 do convênio MAPA-UNIVALI – MAPA/SARC/DPA/03/2001). 2001. Disponível em: <http://gep.cttmar.univali.br/download/pdf/Meta_01_2001.PDF>. Acesso em: 06 nov. 2004.
GEP. Grupo de estudos pesqueiros – CTTMAR. Universidade do Vale do Itajaí, 2005. Disponível em: <http://gep.cttmar.univali.br/>. Acesso em: mar. 2005.
GILLIES, S. SWIGMapScript. University of Minnesota, 26 maio 2004. Disponível em: <http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?SWIGMapScript>. Acesso em: 15 abr. 2005.
GÜNTHER, O. Environmental information systems. Berlim: Springer, 1998. 224 p.
KREMPI, A. P. Explorando recursos de estatística espacial para análise da acessibilidade da cidade de Bauru. 2004. Dissertação (Mestre em Engenharia Civil) – Escola de Engenharia de São Carlos Universidade de São Paulo, São Paulo, 2004.
MCCURLEY, K. S. Geospatial mapping and navegation of the web. IBM Almaden Research Center, San Jose, p. 221-229. 1 maio 2001.
MEADEN, G. J.; CHI, T. D. Geographical information systems: applications to machine fisheries. FAO fischeries technical paper. n. 356. Rome: FAO, 1996. 335 p.
MURRAY, C.; ABUGOV, D.; ALEXANDER, N.; BLACKWELL, B.; BLOWNEY, J.; GERINGER, D.; GODFRIND, A.; KOTHURI, R.; PITTS, R.; RAVADA, S.; WANG, J.; XIE, J. Oracle Spatial User’s Guide and Reference, 10g Release 1 (10.1). Redwood Shores: Oracle, 2003. 602 p.
NETO PEREIRA, A. PostgreSQL: técnicas avançadas – versão open source 7.x. São Paulo: Érica, 2003. p. 25.
NMFS. Fisheries statistics division(ST1) mission. NOAA Fisheries, 2004. Disponível em: <http://www.st.nmfs.gov/st1/mission.html>. Acesso: 09 nov. 2004.
OCAD. Disponível em: <http://ocad-bcda.gc.ca/elinksresearch.html>. Acesso: 09 nov. 2004.
OGC, Open Geospatial Consortium. [S.l.]: OGC, 2005. Disponível em: <http://www.opengeospatial.org>. Acesso em: 08 abr. 2005.
OGC. The OpenGIS™ Abstract Specification Topic 0: Abstract Specification Overview. Open GIS Consortium, Wayland, p. 1-36. 1999.
PERCIVALL, G. OpenGIS® reference model. Open Geospatial Consortium Incorporation, Wayland, p. 1-108. 16 set. 2003.
REFRACTIONS RESEARCH. PostGIS Manual. Refraction Research, 2005. Disponível em: <http://postgis.refractions.net/docs/index.html>. Acesso em: 15 abr. 2005.
RODRIGUEZ, J. L. Análise Espacial da Distribuição da Violência em São Paulo: 1996-1999. 2000. Disponível em: <http://www.dpi.inpe.br/cursos/ser301/trabalhos/zeluiz_violencia.pdf>. Acesso em: 07 nov. 2004.
SARIN, S. Oracle DBA tips & techniques. Berkeley: Osborne/McGraw-Hill, 2000. 740 p.
SFS. Scottish fisheries statistics 2001. Scottish Executive, 2001. Disponível em: <http://www.scotland.gov.uk/library5/fisheries/sfs01.pdf>. Acesso em: 08 nov. 2004.
SILVA, R. Banco de dados geográficos: uma análise das arquiteturas dual (spring) e integrada (oracle spatial). 2002. Dissertação (Mestrado em Engenharia) – Escola Politécnica da Universidade de São Paulo, São Paulo, 2002.
UNM. MapServer. University of Minnesota, 1 dez. 2004a. Disponível em: <http://mapserver.gis.umn.edu >. Acesso em: 17 abr. 2005.
UNM. MapScript. University of Minnesota, 1 dez. 2004b. Disponível em: <http://mapserver.gis.umn.edu/cgi-bin/wiki.pl?MapScript>. Acesso em: 17 abr. 2005.
WADF. Fisheries Research Reports. 2004. Department of Fisheries. Disponível em: <http://www.fish.wa.gov.au/res/broc/frr/>. Acesso em: 07 nov. 2004.
GLOSSÁRIO
Apache Servidor web, Apache HTTPD Server Bz2 Algoritmo para compressão de dados Datum Nível referencial horizontal utilizado para medir as alturas do terreno
(hipsometria); normalmente é usado o nível médio de altura do mar Free Type Padrão para tipo de fontes, biblioteca que permite a manipulação de fontes GDAL/OGR Biblioteca que disponibiliza o acesso a múltiplas base de dados Gzip Padrão de compactação utilizado pela GNU para compactação de arquivos KD-Tree KD-Tree (K Dimensional Tree) é uma árvore binária de pesquisa para
processamento em várias dimensões Layer Camada a qual agrupa objetos geoespaciais Mapfile Arquivo de configuração e definição de cartas temáticas no Mapserver OpenGis Padrão definido e adotado pelos participantes do consorcio OGC Opensource Metodologia de desenvolvimento que prega a disponibilização do código
fonte do aplicativo sobre domínio público Oracle Spatial Módulo do Bando de Dados Oracle que permite a manipulação de objetos
geoespaciais ao Oracle PostGis Módulos do Banco de Dados PostgreSQL que permite a manipulação de
objetos geoespaciais ao PostgreSQL Proj 4 Biblioteca que permite a projeção de pontos espaciais em diferentes
sistemas métricos de coordenadas em tempo real Python Linguagem de programação interpretada Quad-Tree Método para divisão do espaço em quadrantes para indexação espacial,
detecção de colisão, e modelagem de terrenos Raster Sistema de arquivo que armazena informações espaciais através de imagens.
Cada pixel da imagem é referenciado de maneira única R-Tree Método que utiliza árvores R criadas a partir do método de Guttman Ruby Linguagem de programação orientada a objetos Shapefile Formato de arquivo para de dados vetoriais utilizado em SIG que permite o
armazenamento de informações espaciais associadas a atributos não espaciais
Shapelib Biblioteca que permite a manipulação de arquivos no formato shapefile Triggers Funções desenvolvidas em linguagem nativa do banco de dados que
executam comandos automaticamente sem a interação do usuário a partir de ações realizadas sobre objetos do próprio banco de dados
Unix Especificações para o desenvolvimento de sistemas operacionais Web Mapping SIG que permite a visualização de manipulação de informações espaciais
via web
APÊNDICE A – MODELAGEM DO SISTEMA
As seções abaixo apresentam a modelagem do sistema.
Caso de Uso
Análise GeoEspacial
ud Análise GeoEspacial
Algorítmo de Análise Geoespacial
Realiza Análise Geoespacial
Usuário
Mapserver GuaraniUtiliza
Figura 1: Análise GeoEspacial
Usuário
Type: public Actor Status: Proposed. Version 1.0. Phase 1.0. Package: Análise GeoEspacial Details: Created on 03/11/2005 23:27:28. Modified on 16/11/2005 00:25:32. Author: Fernando Simon Usuário do sistema Pesca Tijucas representando o acesso via web
Connections
� Uses usecase Mapserver Guarani
Mapserver Guarani
Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Análise GeoEspacial Details: Created on 04/11/2005 12:52:57. Modified on 16/11/2005 00:23:42.
Framework Mapserver Guarani representando o aplicativo Mapserver. É o framework ao qual o algoritmo será adicionado.
Connections
� Association link to usecase Realiza Análise Geoespacial � Used by actor Usuário
Scenarios
Erro {Alternate}. Caso o usuário informe algum valor inválido o sistema retornará uma mensagem de erro ao usuário, sem realizar a chamada ao método kernel. Os casos a serem validados são: Valores invalidos de limites. Granularidade inferior a zero. Número de células adjacentes inferior a zero. Período de análise inválido. (Datas erradas) Caso o erro ocorra o usuário deverá inserir valores válidos para realizar a análise. Realiza Análise Kernel {Basic Path}. O usuário irá informar os valores descritos no protótipo da aba de Anális Espacial. Informando os valores de mínimos e máximos do limite do grid, da granularidade desejada, das datas iniciais e finais do período de análise, além de definir a métrica utilizada. Caso os valores inseridos sejam válidos, estes serão enviados ao núcleo Mapscript do Mapserver Guaraní o qual se comunicará com o algoritmo proposto.
Realiza Análise Geoespacial
Type: public UseCase Status: Proposed. Version 1.0. Phase 1.0. Package: Análise GeoEspacial Details: Created on 28/05/2005 23:01:10. Modified on 16/11/2005 00:24:20. Author: Fernando Simon Caso de uso provido pelo algoritmo, responsável por prover a interface de acesso ao método de análise. Sendo a partir desta interface que a análise será disponibilizada.
Connections
� Association link from usecase Mapserver Guarani Scenarios
Alternativo {Alternatívo}. O usuário não realiza nenhuma requisição de análise geoespacial. Portanto, o algortítmo não realiza nenhuma ação. Pós Condição {Pós Condição}. Não existe nenhuma pós condição para esta use case. Pré Condição {Pré Condição}. O usuário deve estar logado no sistema para realizar qualquer tipo de análise geoespacial.
Principal {Principal}. A partir de requisicao do usuario a análise geoespacial será gerada para os atributos requisitados que estiverem dento do extent informado. O retorno será um objeto contendo o resultado da análise geoespacial.
Dinâmica
Atividades
ad Diagrama de Ativ idades
Mapserver Guaraní
Calcula as informações
para a criação do grid
Fim Erro
Mensagem Erro
Fim do Algoritmo
Busca os lances para o
grid
Calcula Celula do Lance
Sucesso
Mais lances
Retorna Dados ao
Mapserver Guarani
Instanciar a Célula com
os dados
Calcula os valores de
métrica para a célula
Análise Geoespacial da
Celula Realiza Análise Kernel
Mais Células
Não
Não
Sim
Sim
Realiza Analise Geoespacial
Sim
Não
Sim
Não
Figura 2: Diagrama de Atividades
Análise Geoespacial da Celula
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 04/11/2005 01:19:42. Modified on 05/11/2005 10:17:49.
Atividade responsável por analisar geoespacialmente (através do método Kernel) os objetos geoespaciaisl que pertencem a Celula.
Connections
� Stateflow link to synchronization � Stateflow {Sim} link from decision Realiza Análise Kernel
Busca os lances para o grid
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 21/06/2005 21:26:19. Modified on 05/11/2005 10:17:49. Atividade que pesquisa no banco de dados através de funcao espacial quais sao os lances que estao contidos entro dos limites do grid.
Connections
� Stateflow link to decision Sucesso � Stateflow link from activity Calcula as informações para a criação do grid
Calcula as informações para a criação do grid
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 13/06/2005 23:25:46. Modified on 05/11/2005 10:17:49. Atividade responsável por calcular o numero de linhas e colunas existentes dentros dos limites informados pelo usuário. Utiliza para especificar a celula a granularidade utilizada pelo usuário.
Connections
� Stateflow link to activity Busca os lances para o grid � Stateflow link from statenode Mapserver Guaraní
Calcula Celula do Lance
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 21/06/2005 21:26:38. Modified on 05/11/2005 10:17:49. Atividade responsável por calcular a qual célula o Lace está contido, a qual célula o Lance pertence.
Connections
� Stateflow link from decision Sucesso � Stateflow {Sim} link from decision Mais lances � Stateflow link to decision Mais lances
Calcula os valores de métrica para a célula
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0.
Package: Atividades Details: Created on 04/11/2005 01:18:00. Modified on 05/11/2005 10:17:49. Atividade que representa o fluxo de execução responsável por calcular os valores da relacao para a métrica no conjunto de lances da célula.
Connections
� Stateflow link to decision Realiza Análise Kernel � Stateflow link from activity Instanciar a Célula com os dados
Instanciar a Célula com os dados
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 04/11/2005 01:15:19. Modified on 05/11/2005 10:17:49. Fluxo responsável por instanciar os objetos do tipo célula com seus dados e com seu o conjunto de lances.
Connections
� Stateflow {Sim} link from decision Mais Células � Stateflow link to activity Calcula os valores de métrica para a célula � Stateflow {Não} link from decision Mais lances
Mensagem Erro
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 15/06/2005 20:26:16. Modified on 05/11/2005 10:17:49. Atividade responsável por gerar uma mensagem de erro a ser retornada ao Mapserver Guaraní caso aconteça qualquer erro na execução do algorítmo.
Connections
� Stateflow link from decision Erro � Stateflow link to statenode Fim Erro � Stateflow link from decision Sucesso � Stateflow link from decision Erro � Stateflow {Não} link from decision Sucesso
Retorna Dados ao Mapserver Guarani
Type: public Activity Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 22/06/2005 00:08:26. Modified on 05/11/2005 10:17:49. Atividade responsável por retornar os dados ao Mapserver Guarani através de objetos passiveis de serem utilizados para visualização via Mapserver
Connections � Stateflow link to statenode Fim do Algoritmo � Stateflow {Não} link from decision Mais Células � Stateflow link from decision Mais celulas
Choice
Type: public Choice Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 04/11/2005 01:28:02. Modified on 04/11/2005 01:28:02.
Fim do Algoritmo
Type: public ActivityFinal Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 15/06/2005 20:58:28. Modified on 05/11/2005 10:17:49. Retorna o grid com as análises ao Mapserver Guarani.
Connections
� Stateflow link from activity Retorna Dados ao Mapserver Guarani
Fim Erro
Type: public Final State Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 15/06/2005 20:23:30. Modified on 05/11/2005 10:17:49. Fim do fluxo de execução do algoritmo caso ocorra algum erro.
Connections
� Stateflow link from activity Mensagem Erro
Mapserver Guaraní
Type: public ActivityInitial Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 13/06/2005 23:24:10. Modified on 15/06/2005 21:13:46.
Connections
� Stateflow link to activity Calcula as informações para a criação do grid
Realiza Análise Kernel
Type: public Choice Status: Proposed. Version 1.0. Phase 1.0. Package: Atividades Details: Created on 04/11/2005 01:20:16. Modified on 16/11/2005 00:24:38.
Sequencia - Análise Kernel
sd Diagrama de Sequencia
loop Todas as Células
opt Tau > 0
Diagrama de
Classe::Algoritimo_Analise_Geoespacial
Diagrama de
Classe::Celula
Diagrama de
Classe::Lance
loop Lances Encontrados
opt Tau > 0
opt Tau == 0
Usuário
(from Análise GeoEspacial)
Mapserver Guarani
(from Diagrama de Classe)
grid:= Realiza_Analise_Geoespacial(pArrExtent,pDblGranularidade,pTmpTempo_Inicial,pTmpTempo_Final,pIntMetrica,pIntTau,pIntCodEspecie,pObjMapa)
Identifica_Dados_Grid()
array:= Cria_Janelas_Grid((aIntNumeroCelulaColuna*aIntNumeroCelulaColuna)-1)
boolean:= Busca_Lances_Total()
int:= Calcula_Celula_Lance(pDblX,pDblY)
array:= Retorna_Dados_Lance(numero_lance)
array:= Celulas_Inclusas_Tau(pIntIndOrig)
string:= Calcula_Celulas_Tau(pIntIndice)
Instancia_Celula(pArrExtentJanela,pArrDadosCelula)
Inicializa_Celula_Kernel()
setExtentCelula(pArrExtentCelula)
setDataInicialAnalise(pTmpDataInicial)
setDataFinalAnalise(pTmpDataFinal)
setArrayDadosCelula(pArrDadosCelula)
setCoordenadaPontoCelula(pDblPosicao_x,pDblPosicao_y,pDblPosicao_z)
setAreaCelula(pDblArea)
array:= CalculaValorMetrica(pObjCelula,pIntMetrica)
setValorMetricaCelula(pArrValorMetrica)
float:= Analise_Geoespacial_Da_Janela(pObjCelula)
array:= getCoordenadaPontoCelula()
array:= getArrDadosCelula()
float:= getDblValorMetricaPos(0)
setValorKernelCelula(pDblValor)
Cria_Celula_Correspondente_Mapserver(pObjCelula,pObjCelulaMapserver,pStrTexto)
array:= getExtentCelula()
Figura 3: Diagrama de Seqüência
Diagrama de Sequencia Messages ID Message From Object To Object Notes 1 Usuário Mapserver
Guarani
2 Realiza_Analise_Geoespac
Mapserver Guarani
Algoritimo_Analise_Geoes
ial(array, float, string, string, string, int, int, mapObj)
pacial
3 Identifica_Dados_Grid()
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
4 Cria_Janelas_Grid(int)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
5 Busca_Lances_Total()
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
6 Calcula_Celula_Lance(float, float)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
7 Retorna_Dados_Lance(int)
Algoritimo_Analise_Geoespacial
Lance
8 Celulas_Inclusas_Tau(int)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
9 Calcula_Celulas_Tau(int)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
10 Instancia_Celula(array, array)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
11 Inicializa_Celula_Kernel()
Algoritimo_Analise_Geoespacial
Celula
12 setExtentCelula(array)
Algoritimo_Analise_Geoespacial
Celula
13 setDataInicialAnalise(string)
Algoritimo_Analise_Geoespacial
Celula
14 setDataFinalAnalise(string)
Algoritimo_Analise_Geoespacial
Celula
15 setArrayDadosCelula(array)
Algoritimo_Analise_Geoespacial
Celula
16 setCoordenadaPontoCelula(float, float, float)
Algoritimo_Analise_Geoespacial
Celula
17 setAreaCelul Algoritimo_A Celula
a(float) nalise_Geoespacial
18 CalculaValorMetrica(Celula, int)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
19 setValorMetricaCelula(array)
Algoritimo_Analise_Geoespacial
Celula
20 Analise_Geoespacial_Da_Janela(Celula)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
21 getCoordenadaPontoCelula()
Algoritimo_Analise_Geoespacial
Celula
22 getArrDadosCelula()
Algoritimo_Analise_Geoespacial
Celula
23 getDblValorMetricaPos(int)
Algoritimo_Analise_Geoespacial
Celula
24 setValorKernelCelula(float)
Algoritimo_Analise_Geoespacial
Celula
25 Cria_Celula_Correspondente_Mapserver(Celula, layerObj, string)
Algoritimo_Analise_Geoespacial
Algoritimo_Analise_Geoespacial
26 getExtentCelula()
Algoritimo_Analise_Geoespacial
Celula
27 Algoritimo_Analise_Geoespacial
Mapserver Guarani
Internal Links
� Sequence diagram :: Diagrama de Sequencia Package :: Sequencia - Análise Kernel.
� Sequence diagram :: Diagrama de Sequencia Package :: Sequencia - Análise Kernel.
� Sequence diagram :: Diagrama de Sequencia Package :: Sequencia - Análise Kernel.
� Sequence diagram :: Diagrama de Sequencia Package :: Sequencia - Análise Kernel.
� Sequence diagram :: Diagrama de Sequencia Package :: Sequencia - Análise Kernel.
� Sequence diagram :: Diagrama de Sequencia
Package :: Sequencia - Análise Kernel.
Gera_Analise_Todas_Celulas
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 01/06/2005 21:53:08. Modified on 01/06/2005 22:36:18.
Lances Encontrados
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 03/11/2005 23:39:21. Modified on 04/11/2005 14:27:48.
Mais Celulas
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 31/07/2005 23:19:03. Modified on 01/08/2005 00:01:31.
Tau == 0
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 04/11/2005 00:17:07. Modified on 06/11/2005 01:47:09.
Tau == 0
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 04/11/2005 00:39:43. Modified on 04/11/2005 00:55:08.
Tau > 0
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 04/11/2005 00:15:57. Modified on 06/11/2005 01:47:09.
Tau > 0
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel Details: Created on 04/11/2005 00:21:51. Modified on 04/11/2005 14:27:48.
Todas as Células
Type: public InteractionFragment Status: Proposed. Version 1.0. Phase 1.0. Package: Sequencia - Análise Kernel
Details: Created on 04/11/2005 00:01:00. Modified on 04/11/2005 14:27:48.
Sequência - Mapserver Guarani
sd Sequência - Mapserver Guarani
Usuário
(from Análise GeoEspacial)
«script l ibrary»
Mapserver
Guarani::Tela
«script l ibrary»
Mapserver
Guarani::Selecao
Mapserver
Guarani::Mapscript
VerificaDadosKernel(pDblMinx,pDblMiny,pDblMaxx,pDblMaxy,pDblGranularidade,pIntTau,pIntMetrica,pStrDataIni,pStrDataFim)
EnviaDadosKernel(pDblMinx,pDblMiny,pDblMaxx,pDblMaxy,pDblGranularidade,pIntTau,pIntMetrica,pStrDataIni,pStrDataFim)
EnviaDados()
Figure 1 : Sequência - Mapserver Guarani
Sequência - Mapserver Guarani Messages ID Message From Object To Object Notes 1 VerificaDado
sKernel(string, string, string, string, string, string, string, string, string)
Usuário Tela
2 EnviaDadosKernel(string, string, string, string, string, string, string, string, string)
Tela Selecao
3 EnviaDados() Selecao Mapscript
Lógica
Diagrama de Classe
cd Diagrama de Classe
Classes providadas pelo sistema Pesca Tijucas
Classes a serem implementadas
Lance
- aIntCodLance: int
- aIntCodPlanilha: int
- aIntNumeroLance: int
- aTmpDataInicialLance: string
- aTmpHoraInicialLance: string
- aTmpHoraFinalLance: timestamp
- aDblLatitudeInicial: float
- aDblLongitudeInicial: float
- aDblProfundidadeInicial: float
- aDblVelocidadeInicial: float
- aDblLatitudeFinal: float
- aDblLongitudeFinal: float
- aDblProfundidadeFinal: float
- aDblVelocidadeFinal: float
- aDblQuantidadeTotal: float
- aStrT ipoLance: string
-/ aIntPagina: int
-/ aIntPaginaMax: int
-/ aStrEmbarcacao: string
-/ aStrObservador: string
-/ aIntCodRede: int
-/ aStrNumeroRede: string
-/ aDblConstanteRede: float
+ Retorna_Dados_Lance(int) : array
Dados_Controle_Lance
- aIntPagina: int
- aIntPaginaMax: int
- aStrEmbarcacao: string
- aStrObservador: string
- aStrTipoLance: string
Algoritimo_Analise_Geoespacial
+ aArrExtent: array[]
+ aStrMensagemOperacao: string
- aIntCodProduto: int
- aIntMetrica: int
- aIntNumeroCelulaLinha: int
- aIntNumeroCelulaColuna: int
- aIntNumeroClasses: int
- aIntPeriodoDias: int
- aIntTau: int
- aDblGranularidade_Grid: float
- aDblValorKernelMinimo: float
- aDblValorKernelmaximo: float
- aStrNomeCamadaGridMapserver: string
- aTmpTempo_Inicial: string
- aTmpTempo_Final: string
- aArrCelulas: Celula[]
- aArrDadosLances: array
- aArrDadosLanceCelTau: array
- aArrDadosLanceParametro: array
- aArrValoresMetrica: array
+ Realiza_Analise_Geoespacial(int, int, mapObj) : grid
- Analise_Geoespacial_Da_Janela(Celula) : float
- Busca_Lances_Total() : boolean
- Calcula_Celula_Lance(float, float) : int
- Calcula_Celulas_Tau(int) : string
- Calcula_Indice_Celula(float) : int
- CalculaValorMetrica(Celula, int) : array
- Celulas_Inclusas_Tau(int) : array
- Cria_Celula_Correspondente_Mapserver(string, layerObj, Celula) : void
- Cria_Janelas_Grid(int) : array
- Identifica_Dados_Grid() : void
- Identifica_Janelas_Grid(array) : array
- Instancia_Celula(array) : void
- Instancia_Celula(array, array)
Celula
- aIntIndiceClasse: int
- aDblArea: float
- aDblPosicao_X: float
- aDblPosicao_Y: float
- aDblPosicao_Z: float
- aDblValorKernel: float
- aTmpDataInicialAnalise: string
- aTmpDataFinalAnalise: string
- aArrExtent_Celula: array
- aArrDados_Celula: array
- aArrValorMetrica: array
+ Inicializa_Celula_Kernel() : void
+ getIndiceCelula() : int
+ getAreaCelula() : float
+ getArrDadosCelula() : array
+ getArrValorMetrica() : array
+ getCoordenadaPontoCelula() : array
+ getDataFinalAnalise() : string
+ getDataInicialAnalise() : string
+ getDblValorMetricaPos(int) : float
+ getDblValorKernel() : float
+ getExtentCelula() : array
+ setAreaCelula(float) : void
+ setArrayDadosCelula(array) : void
+ setCoordenadaPontoCelula(float, float) : void
+ setDataFinalAnalise(string) : void
+ setDataInicialAnalise(string) : void
+ setExtentCelula(array) : void
+ setIndiceCelula(int) : void
+ setValorKernelCelula(float) : void
+ setValorMetricaCelula(array) : void
Dados_Produto
- aIntProduto: int
- aDblPeso: float
- aStrNomeProduto: string
Rede_Pesca
- aIntCodRede:
- aDblConstanteRede: float
- aStrNumeroRede: string
Mapserver Guarani
+ Mapscript
+ Selecao
+ Tela
1 *
1 1..*
*
1
* 1
Figura 5: Diagrama de Classe
Internal Links � Logical diagram :: Diagrama de Classe
Package :: Diagrama de Classe.
Algoritimo_Analise_Geoespacial
Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 06/06/2005 18:08:58. Modified on 16/11/2005 00:25:32. Classe responsável por controlar a realização da análise geoespacial, controlando todas as mensagens e o fluxo de dados para a correta execução e realização da análise através do método Kernel. Prove a interface de acesso para o Mapserver Guarani realizar análises geoespaciais.
Connections
� Association link from package Mapserver Guarani � Association link to class Celula
Algoritimo_Analise_Geoespacial Attributes Attribute Type Notes aArrExtent public :
array[] Atributo responsável por armazenar em um array o extent do grid.
aStrMensagemOperacao
public : string
Atributo responsável por armazenar possíves mensagens decorrentes da execução do algoritmo.
aIntCodProduto private : int
Atributo responsável por armazenar o código da espécie de peixe que se deseja pesquisar.
aIntMetrica private : int
Atributo responsável por armazenar qual a métrica utilizada no sistema. Apresenta cinco métricas possíveis: 1 - KG/Tempo de Arrasto 2 - KG por Espécie/Por período 3 - Tempo de Arrasto/Por Período 4 - Numero de Lances/Área/Por Tempo 5 - Numero de Barcos/Área (quadrante) Todas as métricas foram identificadas pelos especialistas do GEP como cruciais na toma de decições.
aIntNumeroCelulaLinha
private : int
Atributo responsável por armazenar o número de linhas do grid para os limites pesquisados.
aIntNumeroCelulaColuna
private : int
Atributo responsável por armazenar o número de colunas do grid para os limites pesquisados.
aIntNumeroClasses private : int
Atributo responsável por armazenar o numero de classes existentes para a camada do grid no arquivo Mapfile.
aIntPeriodoDias private : int
Atributo responsável por armazenar qual o período de dias entre as datas informadas pelo usuário.
aIntTau private : Atributo responsável por armazenar o o número de células
int adjacentes que devem ser consideradas para a análise Kernel. aDblGranularidade_Grid
private : float
Atributo responsável por armazenar a granularidade a qual cada célula do grid será gerada.
aDblValorKernelMinimo
private : float
Atributo responsável por armazenar o valor mínimo de Kernel calculado para uma célula.
aDblValorKernelmaximo
private : float
Atributo responsável por armazenar o valor mínimo de Kernel calculado para uma célula.
aStrNomeCamadaGridMapserver
private : string
Atributo responsável por armazenar qual o nome da camada no arwuivo Mapfile para a arepresentação do grid.
aTmpTempo_Inicial private : string
Atributo responsável por armazenar a data inicial do pe'riodo da análise requisistada pelo usuário.
aTmpTempo_Final private : string
Atributo responsável por armazenar a data final do período da análise requisistada pelo usuário.
aArrCelulas private : Celula[]
Atributo responsável por armazenar um array de todas as células do grid.
aArrDadosLances private : array
Atributo respossável por armazenar os dados dos lances que pertencem a célula.
aArrDadosLanceCelTau
private : array
Atributo responsável por armazenar os dados de lances que pertencem a célula, bem como de suas células adjacentes.
aArrDadosLanceParametro
private : array
Atributo responsável por armazenar o array com os dados a serem passados para a célula.
aArrValoresMetrica private : array
Atributo responsável por armazenar os valores calculados de métrica para os lances encontrados. Armazena os valores calculados para a amétrica, bem como das dimensões envolvidas.
Algoritimo_Analise_Geoespacial Methods Method Type Notes Realiza_Analise_Geoespacial (array, float, string, string, string,
int, int, mapObj)
public: grid param: pArrExtent [ array - in ] param: pDblGranularidade [ float - in ] param: pTmpTempo_Inicial [ string - in ] param: pTmpTempo_Final [ string - in ] param: pIntMetrica [ string - in ] param: pIntTau [ int - in ] param: pIntCodEspecie [ int - in ] param: pObjMapa [ mapObj - in ] Funcão responsável por realizar a análise Kernel dos dados de esforco de pesca. Utiliza para a criacão do GRID os valores passados pelo usuário, este GRID será visualizado no UMN Mapserer. Action: Método provido como interface ao algoritmo, através deste
método é que as requisicões serão aceitas. Analise_Geoespacial_Da_Janela (Celula)
private: float param: pObjCelula [ Celula - in ] Método que realiza a análise espacial pelo método Kernel nos dados pesquisados. O método Kernel foi implementado seguindo as especificacão de modelo descritas no documento TCC.
Busca_Lances_Total () private: boolean
Método responsável por pesquisar no bancod de dados todos os resgistros que estão contidos dentos dos limites do GRID. Espe método executa uma pesquisa espacial através de uma funcão específica do PostGIS para localizar tais registros. A pesquisa espacial é executada somente uma vez e retorna todos os registros encontrados, sendo que a celula correspondete para acada registro será calculada.
Calcula_Celula_Lance (float, float)
private: int param: pDblX [ float - in ] param: pDblY [ float - in ] Método responsável por calcular a qual célula pertence o ponto pesquisado. Para a realização deste cálculo utiliza-se uma aritmética básica.
Calcula_Celulas_Tau (int)
private: string param: pIntIndice [ int - in ] Método responsável por retornar as células adjacentes a célula de origem que estejam dentro dos limites estipulados pelo usuário para TAU. Apresenta como retorno uma string contendo das células adjacentes.
Calcula_Indice_Celula (float)
private: int param: pDblvalor [ float - in ] Método Reponsável por calcular a que classe pertence o valore informado. Retorna o índice da classe corresponde na camada da classe que representa o GRID no Mapserver Guarani.
CalculaValorMetrica (Celula, int)
private: array param: pObjCelula [ Celula - in ] param: pIntMetrica [ int - in ] Método responsável por gerar os valores da métrica estipulada para os lances pertencentes a célula.
Celulas_Inclusas_Tau (int)
private: array param: pIntIndOrig [ int - in ] Método responsável por retornar as células adjacentes a célula de origem que estejam dentro dos limites estipulados pelo usuário para TAU. Este método não considera as os limites de células que estejam fora dos limites máximos estipulados pelo usuário. Apresenta como retorno um array contendo o índice de todas as células adjacentes, incluindo o índice da célula de origem no retorno.
Cria_Celula_Correspondente_Mapserver
private: void param: pObjCelula [ Celula - in ] param: pObjCelulaMapserver [ layerObj - in ] param: pStrTexto [ string - in ]
(Celula, layerObj, string)
Método responsável por criar a célula no objeto do mapa do Mapserver Guarani. Utiliza o como base para geracão da célula os limites da célula de pesquisa.
Cria_Janelas_Grid (int)
private: array param: pIntCodJanela [ int - in ] Método responsável por criar os limites da célula. Utiliza uma atirmética simples de deslocamento em matriz para localizr qual a linha e coluna da célula do índice correspondente. Apresneta como retorno um array com os limites da célula em questão. A célula é criada seguindo o padrão OGC para polígono (4 pontos + 1), sendo que o último ponto coincide com o inicial, criando um poligono fechado. Os limites da célula são criados seguindo do sentido horário.
Identifica_Dados_Grid ()
private: void Método reponsável por identificar o numero de linhas e colunas presentes nos limites estipulados pelo usuário, baseando-se na granularidade do GRID para a identificacao de tais valores.
Identifica_Janelas_Grid (array, float)
private: array param: extent_grid [ array - in ] param: granularidade [ float - in ] Método responsável por identificar e gerar todas as jenelas a serem criadas pelo algoritmo. Calcula as janelas através da granularidade e do extent do grid a ser gerado. Action: Método responsável por identificar e gerar todas as jenelas a serem criadas pelo algoritmo. Calcula as janelas através da granularidade e do extent do grid a ser gerado.
Instancia_Celula (array, array)
private: void param: pArrExtentJanela [ array - in ] param: pArrDadosCelula [ array - in ] Método responsável por instancia o objeto que contêm todos os objetos da classe Celula. Action: Método responsável por instancia o objeto que contêm todos os objetos da classe Celula.
Instancia_Celula (array, array)
private: param: pArrExtentJanela [ array - in ] param: pArrDadosCelula [ array - in ] Método responsável por instanciar o objeto célula correspondente aos limites informados, apresentando os dados repassados.
Celula
Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 06/06/2005 18:10:36. Modified on 16/11/2005 00:25:32.
Classe responsável por prover o objeto célula para ser utilizada pelo algoritmo para armazenar os dados da a análise geoespacial para a célula e visualização através do Mapserver.
Connections
� Association link from class Algoritimo_Analise_Geoespacial � Association link from class Lance
Celula Attributes Attribute Type Notes aIntIndiceClasse private :
int Atributo responsável por armazenar o índice da célula.
aDblArea private : float
Atributo responsável po armazenar a área da célula.
aDblPosicao_X private : float
Atributo responsável po armazenar a posição no eixo da coordenadas X do ponto da célula.
aDblPosicao_Y private : float
Atributo responsável po armazenar a posição no eixo da coordenadas Y do ponto da célula.
aDblPosicao_Z private : float
Atributo responsável po armazenar a posição no eixo da coordenadas Z do ponto da célula.
aDblValorKernel private : float
Atributo responsável po armazenar o valor da análise geoespacial por método Kernel da célula.
aTmpDataInicialAnalise
private : string
Atributo responsável por armazenar a data incial do periodo de analise requisitado pelo usuário
aTmpDataFinalAnalise private : string
Atributo responsável por armazenar a data final do periodo de analise requisitado pelo usuário
aArrExtent_Celula private : array
Atributo responsável po armazenar o extent da célula.
aArrDados_Celula private : array
Atributo responsável por armazenar os dados de lances que pertencem a célula.
aArrValorMetrica private : array
Atributo responsável por armazenar os dados da métrica, armazenando os valores para a métrica e para as dimensoes envolvidas.
Celula Methods Method Type Notes Inicializa_Celula_Kernel ()
public: void Construtor da classe Célula
getIndiceCelula () public: int Método responsável por retornar o indice da célula getAreaCelula () public: float Método responsável por retornar a área da célula getArrDadosCelula () public: array Método responsável por retornar todos os dados da célula getArrValorMetrica () public: array Metodo responsável por retornar o array com os valores
calculados da métrica para a célula getCoordenadaPontoCelula ()
public: array Método responsável por retornar o ponto central armazenado para a célula
getDataFinalAnalise () public: string Método responsável por retornar qual a data final do período
de analise para a célula getDataInicialAnalise ()
public: string Método responsável por retornar qual a data incicial do período de análise para a célula
getDblValorMetricaPos (int)
public: float param: pIntPosicao [ int - in ] Método resposnável por retornar um valor específico do array de dados da métrica para a célula
getDblValorKernel () public: float Método responsável por retornar qual o valor calculado da análise Kernel para a célula
getExtentCelula () public: array Método responsável por retornar os limites da célula setAreaCelula (float) public: void param: pDblArea [ float - in ]
Método responsável por armazenar o valor da aárea para célula
setArrayDadosCelula (array)
public: void param: pArrDadosCelula [ array - in ] Método responsável por armazenar o array com os dados para a célula
setCoordenadaPontoCelula (float, float, float)
public: void param: pDblPosicao_x [ float - in ] param: pDblPosicao_y [ float - in ] param: pDblPosicao_z [ float - in ] Método responsável por armazenar o ponto central da célula
setDataFinalAnalise (string)
public: void param: pTmpDataFinal [ string - in ] Método responsável por armazenar qual a data final do periodo de análise para a célula
setDataInicialAnalise (string)
public: void param: pTmpDataInicial [ string - in ] Método responsável por armazenar qual a data inicial do periodo de análise para a célula
setExtentCelula (array)
public: void param: pArrExtentCelula [ array - in ] Método responsável por armazenar os limites da célula
setIndiceCelula (int) public: void param: pIntIndiceCelula [ int - in ] Método responsável por armazenar o índice da classe para a céluna no Mapserver Guarani
setValorKernelCelula (float)
public: void param: pDblValor [ float - in ] Método respnsável por armazenar o valor calculado de Kernel para a célula
setValorMetricaCelula (array)
public: void param: pArrValorMetrica [ array - in ] Método responsável por armazenar o valor calculado da métrica para a célula
Dados_Controle_Lance
Type: public Class
Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 06/06/2005 17:58:38. Modified on 07/11/2005 00:16:58. Classe responsável por prover uma abstração dos dados do banco de dados referentes a embarcação e ao observador. Esta classe será provida pelo sistema Pesca Tijucas, não cabendo sua implementação ao algoritmo proposto. Compõe a fonte externa de dados ao qual a análise será realizada.
Connections
� Aggregation link from class Lance Dados_Controle_Lance Attributes Attribute Type Notes aIntPagina private :
int Atributo responsável por armazenar á página de registro no livro de lances.
aIntPaginaMax private : int
Atributo responsável por armazenar á última página de registro no livro de lances.
aStrEmbarcacao private : string
Atributo responsável por armazenar qual o nome da embarcacao que realizou os lances.
aStrObservador private : string
Atributo responsável por armazenar qual o nome do observador de bordo que realizou as anotações sobre os lances.
aStrTipoLance private : string
Atributo responsável por armazenar qual o tipo do lance realizado. No caso deste TCC será fixo: ARRASTO DE FUNDO.
Dados_Produto
Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 13/06/2005 13:14:57. Modified on 07/11/2005 00:16:58. Classe responsável por prover a abstração dos dados sobre os produtos do lance. Sendo que cada lance pode ter nenhum ou vários produtos associados a ele. Esta classe será provida pelo sistema Pesca Tijucas, não cabendo sua implementação ao algoritmo proposto. Compõe a fonte externa de dados ao qual a análise será realizada.
Connections
� Association link to class Lance Dados_Produto Attributes Attribute Type Notes aIntProduto private :
int Atributo responsável por armazenar o identificador único do registro do produto.
aDblPeso private : float
Atributo responsável po armazenar quantidade recolhida por especie em cada lance.
aStrNomeProduto private : string
Atributo responsável po armazenar o nome do produto (Espécie de Peixe) recolhido no lance.
Lance
Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 06/06/2005 17:55:12. Modified on 16/11/2005 00:25:32. Classe responsável pro prover a abstração dos lances armazenados no banco de dados. As informações referentes ao lance estão disponíveis através dos métodos desta classe, sendo que cada lance esta ligado a um objeto da classe Dados_Controle_Lance. Esta classe será provida pelo sistema Pesca Tijucas, não cabendo sua implementação ao algoritmo proposto. Compõe a fonte externa de dados ao qual a análise será realizada.
Connections
� Aggregation link to class Dados_Controle_Lance � Association link from class Rede_Pesca � Association link to class Celula � Association link from class Dados_Produto
Lance Attributes Attribute Type Notes aIntCodLance private :
int Atributo responsável por armazenar o identifiador único do lance.
aIntCodPlanilha private : int
Atributo respnsável por armazenar o código da planilha ao qual o lances está associado.
aIntNumeroLance private : int
Atributo responsável por armazenar o numero do lance.
aTmpDataInicialLance private : string
Atributo responsável por armazenar a data inicial de realização do lance.
aTmpHoraInicialLance private : string
Atributo responsável por armazenar a hora inicial de realização do lance.
aTmpHoraFinalLance private : timestamp
Atributo responsável por armazenar a hora final de realização do lance.
aDblLatitudeInicial private : float
Atributo responsável por armazenar a latitude inicial de realização do lance.
aDblLongitudeInicial private : float
Atributo responsável por armazenar a longitude inicial de realização do lance.
aDblProfundidadeInicial
private : float
Atributo responsável por armazenar a profundidade inicial de realização do lance.
aDblVelocidadeInicial private : float
Atributo responsável por armazenar a velocidade inicial de realização do lance.
aDblLatitudeFinal private : float
Atributo responsável por armazenar a latitude final de realização do lance.
aDblLongitudeFinal private : float
Atributo responsável por armazenar a longitide final de realização do lance.
aDblProfundidadeFinal
private : float
Atributo responsável por armazenar a profundidade final de realização do lance.
aDblVelocidadeFinal private : float
Atributo responsável por armazenar a velocidade final de realização do lance.
aDblQuantidadeTotal private : float
Atributo responsável por armazenar a captura totalpara o lance.
aStrTipoLance private : string
Atributo responsável por armazenar o tipo de lance.
aIntPagina private : int
Atributo responsável por armazenar a página da planilhao qual o lance está associado.
aIntPaginaMax private : int
Atributo responsável por armazenar a última página da planilha ao qual o lance está associado.
aStrEmbarcacao private : string
Atributo responsável por armazenar o nome da embarcação que realizou o lance.
aStrObservador private : string
Atributo respons;avel por armazenar o nome do observador que realizou a coleta dos dados do lance
aIntCodRede private : int
Atributo responsável por armazenar o identificador da rede utilizada no lance.
aStrNumeroRede private : string
Atributo responsável por armazenar o nome da rede utilizada.
aDblConstanteRede private : float
Atributo responsável por armazenar a constante da rede.
Lance Methods Method Type Notes Retorna_Dados_Lance (int)
public: array param: numero_lance [ int - in ] Método responsável por retornar todos os dados do lance requisitado. Apresenta como parametro os numero do lance a ser pesquisado. Action: Método responsável por retornar todos os dados do lance requisitado. Apresenta como parametro os numero do lance a ser pesquisado.
Rede_Pesca
Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Classe Details: Created on 16/06/2005 23:06:59. Modified on 07/11/2005 00:16:58. Classe responsável por prover uma abstração das informações referentes a rede de pesca utilizada em cada lance. Esta classe será provida pelo sistema Pesca Tijucas, não cabendo sua implementação ao algoritmo proposto. Compõe a fonte externa de dados ao qual a análise será realizada.
Connections
� Association link to class Lance
Rede_Pesca Attributes Attribute Type Notes aIntCodRede private :
Atributo responsável por armazenar o identificador único da rede.
aDblConstanteRede private : float
Atributo responsável por armazenar a constante da rede a ser utilizana para estimativa da boca de rede.
aStrNumeroRede private : string
Atributo responsável por armazenar qual o nome da rede utilizada pelo lance.
Mapserver Guarani
cd Mapscript Guarani
Mapserver Guarani
Tela a ser implementada
Classes a serem modificadas
Mapscript
- acao:
- camada_index:
- camada_nova:
- camadas_sel:
- camadas:
- corb_pes:
- corg_pes:
- corr_pes:
- escala_padrao:
- extent_x1_ctr:
- extent_y1_ctr:
- extent_x2_ctr:
- extent_y2_ctr:
- layer_pes:
- mapa:
- RefExtMinX:
- RefExtMinY:
- RefExtMaxX:
- RefExtMaxY:
- pesquisa_por_usuario:
- pesquisa_camada:
- pesquisa_texto:
- pesquisa_cor:
- query_pes:
-/ lObjAnaliseGrid: Algoritmo_Analise_Geoespacial
+ retorna_imagem_referencia(float, float, float, float) : void
+ calcula_extent_reais() : void
+ executa_query_selecao(string, string, string, string, string) : void
+ gera_nova_camada() : void
+ mostra_query(string, string) : void
+ mostra_query_salva(hex, hex, hex, string, string, string) : void
+ gera_base(string, string) : void
+ EnviaDados() : void
Selecao
- kernelminx: string
- kernelminy: string
- kernelmaxx: string
- kernelmaxy: string
- kernelgranularidade: string
- kernelmetrica: string
- kerneldataini: string
- kerneldatafim: string
- Selecao: string
+ capturaXY(event) : void
+ CapturaEventos() : void
+ resize() : void
+ capturaMouse(event) : void
+ iniciaSelecao(event) : void
+ movimentaMouse(event) : void
+ DesenhaSelecao() : void
+ DesenhaCoordenada() : void
+ levantaMouse(event) : void
+ finalizaSelecao() : void
+ DesenhaMapa() : void
+ EnviaDadosKernel(string, string, string, string, string, string, string, string, string) : void
+ CarregaMapa(string, string, string, string, string, string, string, string, string, string, string, string, string) : void
+ SelecaoMapa(string) : void
Tela
- minx: text
- miny: text
- maxx: text
- maxy: text
- granularidade: text
- tau: text
- metrica: select
- especie: select
- data_ini: text
- data_fim: text
+ VerificaDadosKernel(string, string, string, string, string, string, string, string, string) : void
+ EnviaDadosKernel(string, string, int, int, float, float, float, float, float) : void
Figure 6 : Mapscript Guarani
Mapscript
Type: public Class Status: Proposed. Version 1.0. Phase 1.0. Package: Mapserver Guarani Details: Created on 04/11/2005 13:13:10. Modified on 14/11/2005 00:35:42. Author: LCA
Connections
� Association link from class Selecao Mapscript Attributes Attribute Type Notes acao private :
camada_index private :
camada_nova private :
camadas_sel private :
camadas private :
corb_pes private :
corg_pes private :
corr_pes private :
escala_padrao private :
extent_x1_ctr private :
extent_y1_ctr private :
extent_x2_ctr private :
extent_y2_ctr private :
layer_pes private :
mapa private :
RefExtMinX private :
RefExtMinY private :
RefExtMaxX private :
RefExtMaxY private :
pesquisa_por_usuario private :
pesquisa_camada private :
pesquisa_texto private :
pesquisa_cor private :
query_pes private :
lObjAnaliseGrid private :
Algoritmo_Anal
ise_Geoespacia
l Mapscript Methods Method Type Notes retorna_imagem_referencia (float, float, float, float)
public: void param: refminx [ float - in ] param: refminy [ float - in ] param: refmaxx [ float - in ] param: refmaxy [ float - in ] Funcao resposavel por gerar a imagem de referencia.
calcula_extent_reais () public: void Calculo dos extents reais da imagem quando existe uma selecao que é aplicada sobre os extents ja existentes
executa_query_selecao (string, string, string, string, string)
public: void param: nm_campo_sel [ string - in ] param: nm_campo_array [ string - in ] param: nm_campo_query [ string - in ] param: regex [ string - in ] param: desc [ string - in ] Executa uma query em uma layer a partir de uma seleção retangular
gera_nova_camada () public: void Gera uma nova camada a partir de defini�es de uma camada base
mostra_query (string, string)
public: void param: nm_campo [ string - in ] Campo a ser definido como pesquisa. param: regex [ string - in ] Clausula da pesquisa Mostra uma query que não foi salva na interface.
mostra_query_salva (string, string, string, hex, hex, hex)
public: void param: nm_camada [ string - in ] Camada que pertence a query param: nm_campo [ string - in ] Campo a ser definido como pesquisa param: regex [ string - in ] Clausula da pesquisa param: red [ hex - in ] param: green [ hex - in ] param: blue [ hex - in ] Mostra uma query que foi salva na interface
gera_base (string, string)
public: void param: camada_nome [ string - in ] param: mode [ string - in ] Gera a base de visualização do mapa
EnviaDados () public: void Envio de dados através do método POST
Selecao
Type: public «script library» Class
Status: Proposed. Version 1.0. Phase 1.0. Package: Mapserver Guarani Details: Created on 04/11/2005 13:31:34. Modified on 14/11/2005 00:35:42. Author: LCA JavaScript File sresponsável por enviar as requisicoes ao Mapscript. Neste script, já disponibilizado pelo Mapserver Guarani, será adicionado o método EnviaDadosKernel para envio das variáveis ao Mapscript. Esse novo método é o mesmo que o método DesehaMapa, mas adicionado das variáveis específicas do méto kernel.
Connections
� Association link to class Mapscript � Association link from class Tela
Selecao Attributes Attribute Type Notes kernelminx private :
string Variável responsável por armazrnar o valor minino em x para o grid informado
kernelminy private : string
Variável responsável por armazrnar o valor minino em y para o grid informado
kernelmaxx private : string
Variável responsável por armazrnar o valor máximo em x para o grid informado
kernelmaxy private : string
Variável responsável por armazrnar o valor máximo em y para o grid informado
kernelgranularidade private : string
Variável responsável por armazenar a granularidade informada para o grid
kernelmetrica private : string
Variável responsável por armazenar a metrica selecionada pelo usuário informadas para o grid
kerneldataini private : string
Variável responsável por armazenar a data inicial do periodo de análise selecionado.
kerneldatafim private : string
Variável responsável por armazenar a data inicial do periodo de análise selecionado.
Selecao private : string
Identificação do objeto html
Selecao Methods Method Type Notes capturaXY (event) public: void param: e [ event - in ]
Captura as coordenadas do mouse
CapturaEventos () public: void resize () public: void capturaMouse (event) public: void param: e [ event - in ]
iniciaSelecao (event) public: void param: e [ event - in ]
Inicia o processo de Seleção e desenho do retangulo de seleção
movimentaMouse (event)
public: void param: e [ event - in ] Movimentação do Mouse Carrega as coordenadas do mouse
DesenhaSelecao () public: void Desenha o retângulo de seleção DesenhaCoordenada () public: void Desenha o retângulo de coordenada levantaMouse (event) public: void param: e [ event - in ]
Verifica o que estava em curso quando o mouse acusou levantar-se
finalizaSelecao () public: void Finaliza o arrasto executa alguma ação referente DesenhaMapa () public: void EnviaDadosKernel (string, string, string, string, string, string,
string, string, string)
public: void param: pDblMinx [ string - in ] param: pDblMiny [ string - in ] param: pDblMaxx [ string - in ] param: pDblMaxy [ string - in ] param: pDblGranularidade [ string - in ] param: pIntTau [ string - in ] param: pIntMetrica [ string - in ] param: pStrDataIni [ string - in ] param: pStrDataFim [ string - in ] Método adicionado ao código para permitir a coumunicacão entre a interface disponibilizada ao usuário para para o método Kernel e o Mapserver Guarani. Esta funcão é basedada na funcão DesenhaMapa() do Mapserver Guarani.
CarregaMapa (string, string, string, string,
string, string, string,
string, string, string,
string, string, string)
public: void param: imagem [ string - in ] param: minx [ string - in ] param: miny [ string - in ] param: maxx [ string - in ] param: maxy [ string - in ] param: escala [ string - in ] param: referencia [ string - in ] param: refminx [ string - in ] param: refminy [ string - in ] param: refmaxx [ string - in ] param: refmaxy [ string - in ] param: escalamapa [ string - in ] param: legenda [ string - in ] Fim do método para comunicacão com a interface do método Kernel
SelecaoMapa (string) public: void param: sessao [ string - in ]
Tela
Type: public «script library» Class Status: Proposed. Version 1.0. Phase 1.0. Package: Mapserver Guarani
Details: Created on 04/11/2005 14:06:46. Modified on 14/11/2005 00:35:42. Tela a ser adicionada a interface do Mapserver Guarani, irá substituir o arquivo responável pela aba de geracao de análise espacial já existente.
Connections
� Association link to class Selecao Tela Attributes Attribute Type Notes minx private :
text Input para envio do valor minimo e x
miny private : text
Input para envio do valor minimo e y
maxx private : text
Input para envio do valor máximo de x
maxy private : text
Input para envio do valor máximo de y
granularidade private : text
Input para envio do valor da granularidade
tau private : text
Input para envio do valor de celulas adjacentes
metrica private : select
Campo de selecao para escolha da métrica a ser calculada
especie private : select
Campo de selecao para escolha da espécie caso a métrica escolhida necessite da espécie.
data_ini private : text
Input para envio da data inicial do periodo de análise
data_fim private : text
Input para envio da data inicial do periodo de análise
Tela Methods Method Type Notes VerificaDadosKernel (string, string, string, string, string, string,
string, string, string)
public: void param: pDblMinx [ string - in ] param: pDblMiny [ string - in ] param: pDblMaxx [ string - in ] param: pDblMaxy [ string - in ] param: pDblGranularidade [ string - in ] param: pIntTau [ string - in ] param: pIntMetrica [ string - in ] param: pStrDataIni [ string - in ] param: pStrDataFim [ string - in ] Função para validação dos dados inseridos pelo usuário.
EnviaDadosKernel (float, float, float, float, float, int, int, string,
string)
public: void param: pDblMinx [ float - in ] param: pDblMiny [ float - in ] param: pDblMaxx [ float - in ] param: pDblMaxy [ float - in ] param: pDblGranularidade [ float - in ]
param: pIntTau [ int - in ] param: pIntMetrica [ int - in ] param: pStrDataIni [ string - in ] param: pStrDataFim [ string - in ] Envia dados para análise.
Diagrama de Componentes
cd Diagrama de Componentes
PostgreSQL
Mapserver Guarani
UMN Mapserv
Sistema Pesca
Tijucas
Algorimo
Proposto
PostGIS
Abstrai
Acessa
Acessa
Disponibiliza
Utiliza
Requisita
Figura 7: Diagrama de Componentes
Algorimo Proposto
Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Componentes Details: Created on 31/07/2005 22:52:29. Modified on 03/11/2005 20:21:04. Componente exemplificando o algoritmo proposto.
Connections
� Association link to component Mapserver Guarani � Association link from component Mapserver Guarani � Connector link to component Sistema Pesca Tijucas
Mapserver Guarani
Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Componentes Details: Created on 31/07/2005 22:50:40. Modified on 01/08/2005 00:21:49. Componente demonstrando o componente Mapserver Guarani ao qual o algoritmo será incluso. Este componente acessa o banco de dados PostgreSQL através do UMN Mapserv
Connections � Association link to component PostgreSQL � Association link from component Algorimo Proposto � Association link from component Sistema Pesca Tijucas � Association link to component Algorimo Proposto
UMN Mapserv
Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Componentes Details: Created on 31/07/2005 22:50:53. Modified on 01/08/2005 00:21:49. Componente demonstrando o aplicativo UMN Mapserv o qual é utilizado pelo Mapserver Guarani como gerador de mapas termáticos.
PostgreSQL
Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Componentes Details: Created on 31/07/2005 22:50:19. Modified on 01/08/2005 00:34:38. Componente demonstrando o componente de banco de dados. Neste TCC demonstrando o PostgreSQL.
Connections
� Association link from component Mapserver Guarani � Connector link from component Sistema Pesca Tijucas
PostGIS
Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Componentes Details: Created on 01/08/2005 00:32:02. Modified on 01/08/2005 00:34:38. Componente responável por armazenar a representação geoespacial no banco de dados PostgreSQL.
Sistema Pesca Tijucas
Type: public Component Status: Proposed. Version 1.0. Phase 1.0. Package: Diagrama de Componentes Details: Created on 31/07/2005 22:51:37. Modified on 01/08/2005 00:21:49. Componente demonstrando o sistema Pesca Tijucas o qual utiliza o Mapserver Guarani como interface web mapping
Connections
� Association link to component Mapserver Guarani � Connector link to component PostgreSQL � Connector link from component Algorimo Proposto
Protótipo
cd Protótipo
«php page»
Aba Análise Espacial
Limites do Grid
Minx Miny
Maxx Maxy
Dados do Grid
Granularidade
Celulas Adjacentes
Período de Análise
Data Inicial
Data Final
Métrica
Métrica
Espécie
Analisar
Figure 8 : Protótipo
Aba Análise Espacial
Type: public «php page» Screen Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 22:10:35. Modified on 16/11/2005 00:26:41. Author: Fernando Simon Prótipo de tela que permite ao usuário do sistema PescaTijucas analisar espacialmente dados de esforço de pesca, pelo método Kernel, utilizando o Mapserver Guarani.
Analisar
Type: public «button» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:11:24. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Celulas Adjacentes
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:03:37. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Dados do Grid
Type: public «dialog» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:00:39. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Data Final
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:07:37. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Data Inicial
Type: public «date» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:06:47. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Espécie
Type: public «dropdown» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:10:17. Modified on 03/11/2005 23:11:24. Author: Fernando Simon
Granularidade
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:01:54. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Limites do Grid
Type: public «dialog» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 22:12:48. Modified on 03/11/2005 23:12:58.
Maxx
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 22:15:43. Modified on 03/11/2005 23:05:47. Author: Fernando Simon
Maxy
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 22:16:17. Modified on 03/11/2005 23:05:47. Author: Fernando Simon
Métrica
Type: public «dialog» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:08:37. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
Métrica
Type: public «dropdown» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:09:56. Modified on 03/11/2005 23:11:24. Author: Fernando Simon
Minx
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 22:14:26. Modified on 03/11/2005 23:05:47. Author: Fernando Simon
Miny
Type: public «textbox» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 22:14:54. Modified on 03/11/2005 23:05:47. Author: Fernando Simon
Período de Análise
Type: public «dialog» GUIElement Status: Proposed. Version 1.0. Phase 1.0. Package: Protótipo Details: Created on 03/11/2005 23:05:47. Modified on 03/11/2005 23:12:58. Author: Fernando Simon
APÊNDICE B – CÓDIGO FONTE
As seções abaixo apresentam o código fonte dos arquivos criados e ou alterados para o
desenvolvimento do TCC.
Arquivo Mapfile #============================================================ # Arquivo Mapfile utilizado pelo projeto Pesca Tijucas # Arquvo Mapfile utilizado durante o TCC #============================================================ map extent -1 -1 40 40 size 350 318 units dd interlace on imagecolor 113 167 255 imagetype png shapepath "data" fontset "/webdata/httpd/mapserv/pescatijucas/fontes/fontes.txt" symbolset "symbols.sym" symbol name 'coleta' type vector filled on points 0 0 1 0 1 1 0 1 0 0 end end #============================================================ # Definicao do tipo de output da imagem do mapa #============================================================ outputformat name png driver "gd/png" mimetype "image/png" imagemode "PC256" transparent off extension "png" end #============================================================ # Definicao do objeto web #============================================================ web imagepath "/webdata/httpd/htdocs/tmp/" imageurl "/tmp/" end #============================================================ # Definicao da escala #============================================================ scalebar transparent on status off size 200 4 style 1 units kilometers color 0 0 0 outlinecolor 0 0 0 imagecolor 255 255 255 intervals 3 position lc label outlinecolor 255 255 255 color 0 0 0 size tiny
end end #============================================================ # Definicao da legenda do mapa #============================================================ legend status off keysize 20 15 transparent on outlinecolor -1 -1 -1 label type truetype font verdana size 8 antialias true #color 0 0 89 end end #============================================================ # Definicao da camada LANCES #============================================================ LAYER name "lances" sizeunits PIXELS status off type point CONNECTIONTYPE postgis units meters class name "Lances" symbol "coleta" color 255 0 0 outlinecolor 0 0 0 size 6 end END #============================================================ # Definicao da camada GRID - Escala #============================================================ LAYER name "grid" sizeunits PIXELS status off type polygon units meters class name "Sem Ocorrencia" style outlinecolor 0 0 0 size 2 end end class name "Nivel 1" style color 36 169 3 outlinecolor 0 0 0 size 2 end end class name "Nivel 2" style color 53 255 10 outlinecolor 0 0 0 size 2 end end class name "Nivel 3" style color 44 255 79 outlinecolor 0 0 0 size 2 end end class name "Nivel 4" style color 13 251 199 outlinecolor 0 0 0
size 2 end end class name "Nivel 5" style color 165 243 252 outlinecolor 0 0 0 size 2 end end class name "Nivel 6" style color 165 204 252 outlinecolor 0 0 0 size 2 end end class name "Nivel 7" style color 107 171 249 outlinecolor 0 0 0 size 2 end end class name "Nivel 8" style color 107 107 249 outlinecolor 0 0 0 size 2 end end class name "Nivel 9" style color 3 3 239 outlinecolor 0 0 0 size 2 end end class name "Nivel 10" style color 3 3 151 outlinecolor 0 0 0 size 2 end end end end
Arquivo Tree.php <?php require_once("../config.inc"); require_once("../libs/language_$idioma.inc"); ?> <html> <head> <style> a, a:link, a:visited, a:active, a:hover{ color: #000000; text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px; } </style> </head> <script language="javascript" type="text/javascript"> function VerificaDadosKernel(pDblMinx, pDblMiny, pDblMaxx, pDblMaxy, pDblGranularidade, pIntTau, pIntMetrica, pStrDataIni, pStrDataFim) { var lBolMinx = parseInt(pDblMinx.value); var lBolMiny = parseInt(pDblMiny.value); var lBolMaxx = parseInt(pDblMaxx.value); var lBolMaxy = parseInt(pDblMaxy.value); var lBolTau = parseInt(pIntTau.value);
var lBolGranularidade = parseInt(pDblGranularidade.value); if ( (lBolMinx || (lBolMinx == 0)) && (lBolMiny || (lBolMiny == 0)) && (lBolMaxx || (lBolMaxx == 0)) && (lBolMaxy || (lBolMaxy == 0)) && (lBolTau || (lBolTau == 0)) && (lBolGranularidade || (lBolGranularidade == 0)) ) { alert("Dependendo do granularidade e dos limites do grid definidos os valores para MaxX e MinY podem ser alterados pela análise"); self.parent.EnviaDadosKernel( pDblMinx.value, pDblMiny.value, pDblMaxx.value, pDblMaxy.value, pDblGranularidade.value, pIntTau.value, pIntMetrica.value, pStrDataIni.value, pStrDataFim.value ); } else { if ( isNaN(lBolMinx) || isNaN(lBolMiny) || isNaN(lBolMaxx) || isNaN(lBolMaxy) || isNaN(lBolGranularidade) ) { alert("Verifique os dados inseridos, valores inválidos"); } if (isNaN(lBolTau)) alert("O valor para TAU deve maior ou igual a zero"); } } </script> <body bottommargin="0" topmargin="0" leftmargin="0" rightmargin="0" marginheight="0" marginwidth="0" bgcolor="#ECE9D8"> <span style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;"> <center><?="Defina os valores a serem inseridos para análise <b>kernel</b>"?></center></span> <hr> <form name="kernel" method="POST" action="mapscript.mphp"> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td align="right"> <label for="minx" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;">MinX</label> <input type="text" size="4" name="minx" id="minx"/> </td> <td align="right"> <label for="minx" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;">MinY</label> <input type="text" size="4" name="miny" id="miny"/> </td> </tr> <tr> <td align="right"> <label for="maxx" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;">MaxX</label> <input type="text" size="4" name="maxx" id="maxx"/> </td> <td align="right"> <label for="maxy" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;">MaxY</label> <input type="text" size="4" name="maxy" id="maxy"/> </td> </tr> </table> <hr> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td align="right"> <label for="granularidade" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;"><?="Granularidade"?></label>
<input type="text" size="4" name="granularidade" id="granularidade" value="1"/> </td> </tr> <tr> <td align="right"> <label for="tau" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;"><?="Tau"?></label> <input type="text" size="4" name="tau" id="tau" value="1"/> </td> </tr> </table> <hr> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td align="left"> <label for="metrica" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;"><?="Métrica"?></label> <select style="width:150px" name="metrica" id="metrica"> <option value ="1"><?="KG/Tempo de Arrasto"?></option> <option value ="2"><?="KG por espécie/Período"?></option> <option value ="3"><?="Tempo de Arrasto/Período"?></option> <option value ="5"><?="Numero de lances por Area(quadrante)/Tempo de arrasto"?></option> <option value ="6"><?="Numero de barcos/Area(quadrante)"?></option> </select> </td> </tr> </table> <hr> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td align="right"> <label for="data_ini" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;"><?="Data inicial da análise"?></label> <input type="text" size="9" name="data_ini" id="data_ini"/> </td> </tr> <tr> <td align="right"> <label for="data_fim" style="text-decoration: none; font-family: Tahoma, Verdana; font-size: 12px;"><?="Data final da análise"?></label> <input type="text" size="9" name="data_fim" id="data_fim"/> </td> </tr> </table> <hr> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td align="center"> <input align="middle" type="button" name="enviar" id="enviar" value="Enviar dados" onclick="VerificaDadosKernel(minx,miny,maxx,maxy,granularidade,tau,metrica,data_ini,data_fim)"></input> </td> </tr> </table> </form> </body> </html>
Arquivo Lance.php <?php require_once( "config.inc" ); class Lance { private $aIntCodLance; private $aIntNumeroLance; private $aIntCodPlanilha; private $aTmpDataInicialLance; private $aTmpHoraInicialLance; private $aTmpHoraFinalLance;
private $aDblLatitudeInicial; private $aDblLongitudeInicial; private $aDblProndidateInicial; private $aDblVelocidadeInicial; private $aDblLatitudeFinal; private $aDblLongitudeFinal; private $aDblProfundidadeFinal; private $aDblVelocidadeFinal; private $aDblQuantidadeTotal; private $aIntPagina; private $aIntPaginaMax; private $aStrEmbarcacao; private $aStrObservador; private $aStrTipoLance; private $aIntCodRede; private $aStrNumeroRede; private $aDblConstanteRede; public function Retorna_Dados_Lance_Arrasto($pIntCodLance) { $lArrDados = array(); $lArrDadosArrasto = array(); $lArrDadosControle = array(); $lArrDadosProduto = array(); $lArrDadosRede = array(); $lArrDadosProdutoTemp = array(); $this->aStrTipoLance = "Arrasto"; $this->aIntCodLance = $pIntCodLance; $lObjDbConexao = new DB_LCA(); $lStrSql = "SELECT p.cod_planilha , p.txt_nome_embarcacao , p.txt_observador , p.int_num_pagina , p.int_num_pagina_max FROM prt_dados_planilha_tcc p , prt_dados_lance_tcc l WHERE l.cod_lance_serial = $pIntCodLance AND l.cod_planilha = p.cod_planilha"; $lObjDbConexao->Consulta( $lStrSql ); if ($lObjDbConexao->ProximoRegistro()) { list( $this->aIntCodPlanilha , $this->aStrEmbarcacao , $this->aStrObservador , $this->aIntPagina , $this->aIntPaginaMax ) = $lObjDbConexao->Tupla(); array_push($lArrDadosControle, $this->aIntCodLance); array_push($lArrDadosControle, $this->aIntCodPlanilha); array_push($lArrDadosControle, $this->aStrEmbarcacao); array_push($lArrDadosControle, $this->aStrObservador); array_push($lArrDadosControle, $this->aIntPagina); array_push($lArrDadosControle, $this->aIntPaginaMax); array_push($lArrDadosControle, $this->aStrTipoLance); } $lObjDbConexao->Libera(); $lStrSql = "SELECT cod_lance , to_char(dat_data_inicial, 'DD/MM/YYYY') AS data_inicial , to_char(dat_hora_inicial, 'HH24:MI') AS hora_inicial , flt_profundidade_inicial , flt_velocidade_inicial , to_char(dat_hora_final, 'HH24:MI') AS hora_final , flt_profundidade_final , flt_velocidade_final , flt_captura_total , X(geo_coordenada_inicial) AS x_inicial , Y(geo_coordenada_inicial) AS y_inicial , X(geo_coordenada_final) AS x_final , Y(geo_coordenada_final) AS y_final FROM prt_dados_lance_tcc WHERE cod_lance_serial = $pIntCodLance"; $lObjDbConexao->Consulta( $lStrSql ); if ($lObjDbConexao->ProximoRegistro()) {
list( $this->aIntNumeroLance , $this->aTmpDataInicialLance , $this->aTmpHoraInicialLance , $this->aDblProndidateInicial , $this->aDblVelocidadeInicial , $this->aTmpHoraFinalLance , $this->aDblProfundidadeFinal , $this->aDblVelocidadeFinal , $this->aDblQuantidadeTotal , $this->aDblLongitudeInicial , $this->aDblLatitudeInicial , $this->aDblLongitudeFinal , $this->aDblLatitudeFinal ) = $lObjDbConexao->Tupla(); array_push($lArrDadosArrasto, $this->aIntNumeroLance); array_push($lArrDadosArrasto, $this->aTmpDataInicialLance); array_push($lArrDadosArrasto, $this->aTmpHoraInicialLance); array_push($lArrDadosArrasto, $this->aDblProndidateInicial); array_push($lArrDadosArrasto, $this->aDblVelocidadeInicial); array_push($lArrDadosArrasto, $this->aTmpHoraFinalLance); array_push($lArrDadosArrasto, $this->aDblProfundidadeFinal); array_push($lArrDadosArrasto, $this->aDblVelocidadeFinal); array_push($lArrDadosArrasto, $this->aDblQuantidadeTotal); array_push($lArrDadosArrasto, $this->aDblLongitudeInicial); array_push($lArrDadosArrasto, $this->aDblLatitudeInicial); array_push($lArrDadosArrasto, $this->aDblLongitudeFinal); array_push($lArrDadosArrasto, $this->aDblLatitudeFinal); } $lObjDbConexao->Libera(); $lStrSql = "SELECT dp.txt_nome_produto , dpl.flt_quantidade , dp.cod_produto FROM prt_dados_produto_lance_tcc dpl , prt_dados_lance_tcc dl , prt_dados_produto_tcc dp WHERE dl.cod_lance_serial = $pIntCodLance AND dl.cod_lance_serial = dpl.cod_lance AND dp.cod_produto = dpl.cod_produto"; $lObjDbConexao->Consulta( $lStrSql ); while ($lObjDbConexao->ProximoRegistro()) { $lArrDadosProdutoTemp = array(); list( $lStrNomeProduto , $lDblPesoproduto , $lIntCodProduto ) = $lObjDbConexao->Tupla(); array_push($lArrDadosProdutoTemp, $lStrNomeProduto); array_push($lArrDadosProdutoTemp, $lDblPesoproduto); array_push($lArrDadosProdutoTemp, $lIntCodProduto); array_push($lArrDadosProduto, $lArrDadosProdutoTemp); } $lObjDbConexao->Libera(); $lStrSql = "SELECT dr.cod_rede , dr.txt_nome_rede , dr.txt_numero_rede , dr.flt_constante_rede FROM prt_dados_rede_tcc dr , prt_dados_lance_tcc dl WHERE dl.cod_lance_serial = $pIntCodLance AND dl.cod_rede = dr.cod_rede"; $lObjDbConexao->Consulta( $lStrSql ); if ($lObjDbConexao->ProximoRegistro()) { list( $this->aIntCodRede , $this->aStrNumeroRede , $this->aStrNumeroRede , $this->aDblConstanteRede ) = $lObjDbConexao->Tupla(); array_push($lArrDadosRede, $this->aIntCodRede); array_push($lArrDadosRede, $this->aStrNumeroRede); array_push($lArrDadosRede, $this->aStrNumeroRede); array_push($lArrDadosRede, $this->aDblConstanteRede); } $lObjDbConexao->Libera(); array_push($lArrDados, $lArrDadosControle); array_push($lArrDados, $lArrDadosArrasto);
array_push($lArrDados, $lArrDadosProduto); array_push($lArrDados, $lArrDadosRede); return $lArrDados; } } ?>
Arquivo Celula.php <?php /** * Classe responsável por armazenar os dados da célula. * */ class Celula { private $aIntIndiceClasse; private $aDblArea; private $aDblPosicao_X; private $aDblPosicao_Y; private $aDblPosicao_Z = 0; private $aDblValorKernel; private $aTmpDataInicialAnalise; private $aTmpDataFinalAnalise; private $aArrExtent_Celula; private $aArrDados_Celula; private $aArrValorMetrica; /** * Construtor da classe Célula * */ public function Inicializa_Celula_Kernel(){ } /** * Método responsável por retornar o indice da célula * * @return int */ public function getIndiceCelula() { return $this->lIntIndiceClasse; } /** * Método responsável por retornar qual o valor calculado da análise Kernel para a célula * * @return float */ public function getDblValorKernel() { return $this->aDblValorKernel; } /** * Método responsável por retornar a área da célula * * @return unknown */ public function getAreaCelula() { return $this->aDblArea; } /** * Método resposnável por retornar um valor específico do array de dados da métrica para a célula * * @param int $pIntPosicao * @return float */ public function getDblValorMetricaPos($pIntPosicao) { return $this->aArrValorMetrica[$pIntPosicao]; } /** * Método responsável por retornar qual a data incicial do período de análise para a célula * * @return string */ public function getDataInicialAnalise()
{ return $this->aTmpDataInicialAnalise; } /** * Método responsável por retornar qual a data final do período de analise para a célula * * @return string */ public function getDataFinalAnalise() { return $this->aTmpDataFinalAnalise; } /** * Método responsável por retornar os limites da célula * * @return array */ public function getExtentCelula() { return $this->aArrExtent_Celula; } /** * Método responsável por retornar todos os dados da célula * * @return array */ public function getArrDadosCelula() { return $this->aArrDados_Celula; } /** * Metodo responsável por retornar o array com os valores calculados da métrica para a célula * * @return array */ public function getArrValorMetrica() { return $this->aArrValorMetrica; } /** * Método responsável por retornar o ponto central armazenado para a célula * * @return unknown */ public function getCoordenadaPontoCelula() { return array($this->aDblPosicao_X, $this->aDblPosicao_Y, $this->aDblPosicao_Z ); } /** * Método responsável por armazenar os limites da célula * * @param array $pArrExtentCelula */ public function setExtentCelula($pArrExtentCelula) { $this->aArrExtent_Celula = $pArrExtentCelula; } /** * Método responsável por armazenar o array com os dados para a célula * * @param array $pArrDadosCelula */ public function setArrayDadosCelula($pArrDadosCelula) { $this->aArrDados_Celula = $pArrDadosCelula; } /** * Método responsável por armazenar qual a data inicial do periodo de análise para a célula * * @param string $pTmpDataInicial */ public function setDataInicialAnalise($pTmpDataInicial) { $this->aTmpDataInicialAnalise = $pTmpDataInicial;
} /** * Método responsável por armazenar qual a data final do periodo de análise para a célula * * @param string $pTmpDataFinal */ public function setDataFinalAnalise($pTmpDataFinal) { $this->aTmpDataFinalAnalise = $pTmpDataFinal; } /** * Método responsável por armazenar o índice da classe para a céluna no Mapserver Guarani * * @param string $pIntIndiceCelula */ public function setIndiceCelula($pIntIndiceCelula) { $this->aIntIndiceClasse = $pIntIndiceCelula; } /** * Método respnsável por armazenar o valor calculado de Kernel para a célula * * @param float $pDblValor */ public function setValorKernelCelula($pDblValor) { $this->aDblValorKernel = $pDblValor; } /** * Método responsável por armazenar o valor calculado da métrica para a célula * * @param float $pArrValorMetrica */ public function setValorMetricaCelula($pArrValorMetrica) { $this->aArrValorMetrica = $pArrValorMetrica; } /** * Método responsável por armazenar o valor da aárea para célula * * @param float $pDblArea */ public function setAreaCelula($pDblArea) { $this->aDblArea = $pDblArea; } /** * Método responsável por armazenar o ponto central da célula * * @param float $pDblPosicao_x * @param float $pDblPosicao_y * @param float $pDnlPosicao_z */ public function setCoordenadaPontoCelula($pDblPosicao_x, $pDblPosicao_y, $pDnlPosicao_z = 0) { $this->aDblPosicao_X = $pDblPosicao_x; $this->aDblPosicao_Y = $pDblPosicao_y; $this->aDblPosicao_Z = $pDnlPosicao_z; } } ?>
Arquivo Algoritmo_Analise_Geoespacial.php <?php /* * Carregando as bibliotecas necessárias para comunicacao com o Mapserver Guarani * bem como as outras classes utilizadas no projeto. */ require_once( "config.inc" ); require_once("/webdata/httpd/htdocs/pescatijucas/webgis/Celula.php"); require_once("/webdata/httpd/htdocs/pescatijucas/webgis/Lance.php"); class Algoritmo_Analise_Geoespacial { /*
* Variáveis publicas */ public $aArrExtent = array(); public $aStrMensagemOperacao; /* * Variáveis privadas */ /* Variáveis para valores inteiros. */ private $aIntCodProduto = null; private $aIntPeriodoDias = 10; private $aIntMetrica; private $aIntNumeroCelulaLinha = 0; private $aIntNumeroCelulaColuna = 0; private $aIntNumeroClasses = 10; private $aIntTau = 0; /* Variáveis para valores em ponto flutuante. */ private $aDblGranularidade_Grid; private $aDblTolerancia = 0.000005; private $aDblValorKernelMinimo = null; private $aDblValorKernelmaximo = null; /*Variáveis para valores textuais*/ private $aStrNomeCamadaGridMapserver = 'grid'; /*Variáveis para valores de tempo*/ private $aTmpTempo_Inicial; private $aTmpTempo_Final; /* Variáveis para valores de tipo complexos. */ private $aArrCelulas = array(); private $aArrDadosLances = array(); private $aArrDadosLanceCel = array(); private $aArrDadosLanceCelTau = array(); private $aArrExtent_Janela = array(); private $aArrLances = array(); private $aArrValoresMetrica = 0; /* Variáveis para objetos. */ private $aObjMapa; private $aObjObjetos_Celula; /** * Funcão responsável por realizar a análise Kernel dos dados de esforco de pesca. * Utiliza para a criacão do GRID os valores passados pelo usuário, este GRID será * visualizado no UMN Mapserer. * * @param array $pArrExtent * @param float $pDblGranularidade * @param string $pTmpTempo_Inicial * @param string $pTmpTempo_Final * @param int $pIntMetrica * @param int $pIntTau * @param int $pIntCodEspecie * @param object $pObjMapa * @return unknown */ public function Realiza_Analise_Geoespacial($pArrExtent, $pDblGranularidade, $pTmpTempo_Inicial, $pTmpTempo_Final, $pIntMetrica, $pIntTau, $pIntCodEspecie, $pObjMapa ) { /* Inicializando os atributos com os valores passados por parametro */ $this->aIntTau = $pIntTau; $this->aIntMetrica = $pIntMetrica; $this->aIntCodProduto = $pIntCodEspecie; $this->aDblGranularidade_Grid = $pDblGranularidade; $this->aTmpTempo_Inicial = $pTmpTempo_Inicial; $this->aTmpTempo_Final = $pTmpTempo_Final; $this->aArrValoresMetrica = array_fill(0, 3, 0); $this->aArrExtent = $pArrExtent; $this->aObjMapa = $pObjMapa; /* * Executando uma consulta no banco de dados para retorno do período de análise * Utilizando a classe de conexão provida pelo Mapserver Guarani com o banco de * dados PostGIS */
$lStrSqlSelect = "SELECT "; $lStrSqlData1 = "to_date('".$this->aTmpTempo_Final."', 'DD/MM/YYYY')"; $lStrSqlData2 = "to_date('".$this->aTmpTempo_Inicial."', 'DD/MM/YYYY')"; $lStrSql = $lStrSqlSelect.$lStrSqlData1." - ".$lStrSqlData2; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSql); if ($lObjDbConexao->ProximoRegistro()) { list($this->aIntPeriodoDias) = $lObjDbConexao->Tupla(); } $lObjDbConexao->libera(); /* Finalizando a conexão com o banco de dados.*/ /* * Executando a funcão Identifica_Dados_Grid() para inicializacão dos dados a * serem utilizados para a criacao do GRID. */ $this->Identifica_Dados_Grid(); /* * Inicializando o array quer armazenará os dados para cada célula do grid. * Cada posicao desse array armazena?a um array com os dados para cada célula */ $this->aArrDadosLanceCel = array_fill(0, ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna), array()); /* * Executando funcão para pesquisar no banco de dados todos os registros de * esforcos de pesca(lances) que estao contidos dentro dos limites definidos * pelo usuário. */ if (!$this->Busca_Lances_Total()) { $this->aStrMensagemOperacao = "Erro ao pesquisar GRID"; return null; } /* * Verificando se o usuário deseja analisar os dados pelo método Kernel ou somente * deseja realizar a plotagem dos dados. */ if ($this->aIntTau > 0) { /* * Inicializando o array quer armazenará os dados para cada célula do grid. * Onde neste array estarao todos os dados das células vizinhas que estão contidos * dentro dos limites de TAU. */ $this->aArrDadosLanceCelTau = array_fill(0, ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna), array()); for ($f = 0; $f < ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna); $f++) { /* Pesquisando as células adjacentes, baseando-se em TAU. */ $lArrCelulas = $this->Celulas_Inclusas_Tau($f); for($l = 0; $l < sizeof($lArrCelulas); $l++) { for ($i = 0; $i < sizeof($this->aArrDadosLanceCel[$lArrCelulas[$l]]); $i++) { array_push($this->aArrDadosLanceCelTau[$f], $this->aArrDadosLanceCel[$lArrCelulas[$l]][$i]); } } /* Instanciando a célula com os dados encontrados. */ $this->Instancia_Celula( $this->Cria_Janelas_Grid($f), $this->aArrDadosLanceCelTau[$f]); } } else { for ($f = 0; $f < ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna); $f++) { /* Instanciando a célula com os dados encontrados. */ $this->Instancia_Celula( $this->Cria_Janelas_Grid($f), $this->aArrDadosLanceCel[$f]); } } /* Retornando a camada para a representa?ão do GRID no objeto do Mapserver Guarani. */ $lObjCamadaGrid = $this->aObjMapa->getLayerByName($this->aStrNomeCamadaGridMapserver); for ($f = 0; $f < ($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna); $f++) {
/* Criando a célula para a visualizacão no Mapserver Guarani. */ $this->Cria_Celula_Correspondente_Mapserver($this->aArrCelulas[$f], $lObjCamadaGrid, $f); } } /** * Método repon?avel por identificar o numero de linhas e colunas presentes nos * limites estipulados pelo usuário, baseando-se na granularidade do GRID para * a identificacao de tais valores. * */ private function Identifica_Dados_Grid() { /* Inicializando as variáveis com os dados de célula e coluna do GRID. */ $this->aIntNumeroCelulaColuna = ceil(abs($this->aArrExtent[0] - $this->aArrExtent[2])/$this->aDblGranularidade_Grid); $this->aIntNumeroCelulaLinha = ceil(abs($this->aArrExtent[1] - $this->aArrExtent[3])/$this->aDblGranularidade_Grid); /* Verifiando a última célula para correcão ddo Xmax e Ymax do GRID. */ $lArrJanela = $this->Cria_Janelas_Grid(($this->aIntNumeroCelulaLinha*$this->aIntNumeroCelulaColuna)-1); if ( $lArrJanela[1][0] > $this->aArrExtent[2] ) $this->aArrExtent[2] = $lArrJanela[1][0]; if ( $lArrJanela[2][1] < $this->aArrExtent[1] ) $this->aArrExtent[1] = $lArrJanela[2][1]; } /** * Método responsável por criar os limites da célula. Utiliza uma atirmética * simples de deslocamento em matriz para localizr qual a linha e coluna da * célula do índice correspondente. * Apresneta como retorno um array com os limites da célula em questão. A célula * é criada seguindo o padrão OGC para polígono (4 pontos + 1), sendo que o último * ponto coincide com o inicial, criando um poligono fechado. * Os limites da célula são criados seguindo do sentido horário. * * @param int $pIntCodJanela * @return array */ private function Cria_Janelas_Grid($pIntCodJanela) { /* Identificando a linha e a coluna da célula. */ $lIntColuna = $pIntCodJanela%$this->aIntNumeroCelulaColuna; $lIntLinha = floor($pIntCodJanela/$this->aIntNumeroCelulaColuna); $lDblX = $this->aArrExtent[0]+(($lIntColuna*$this->aDblGranularidade_Grid)); $lDblY = $this->aArrExtent[3]-(($lIntLinha*$this->aDblGranularidade_Grid)); /* Ponto 1 - Inicial. */ $lArrPnt1 = array( $lDblX, $lDblY ); /* Ponto 2. */ $lArrPnt2 = array( ( $lDblX + $this->aDblGranularidade_Grid ), $lDblY ); /* Ponto 3. */ if ( $lDblY >= 0 ) $lArrPnt3 = array( ( $lDblX + $this->aDblGranularidade_Grid ), ( $lDblY - $this->aDblGranularidade_Grid ) ); else $lArrPnt3 = array( ( $lDblX + $this->aDblGranularidade_Grid ), ( $lDblY + $this->aDblGranularidade_Grid ) ); /* Ponto 4. */ if ( $lDblY >= 0 ) $lArrPnt4 = array( $lDblX, ( $lDblY - $this->aDblGranularidade_Grid ) ); else $lArrPnt4 = array( $lDblX, ( $lDblY + $this->aDblGranularidade_Grid ) ); $lArrJanela = array($lArrPnt1, $lArrPnt2, $lArrPnt3, $lArrPnt4, $lArrPnt1); return $lArrJanela; } /** * Método responsável por calcular a qual célula pertence o ponto pesquisado. * Para a realiza?ão deste cálculo utiliza-se uma aritmética básica. * * @param float $pDblX * @param float $pDblY * @return int
*/ private function Calcula_Celula_Lance($pDblX, $pDblY) { $lDblPosRelY = ( ($pDblY)-($this->aArrExtent[1]) )/( ($this->aArrExtent[3])-($this->aArrExtent[1]) ); $lDblPosRelY = min( floor( (1 - $lDblPosRelY)*$this->aIntNumeroCelulaLinha ), $this->aIntNumeroCelulaLinha-1 ); $lDblPosRelX = ( ($pDblX)-($this->aArrExtent[0]) )/( ($this->aArrExtent[2])-($this->aArrExtent[0]) ); $lDblPosRelX = min( floor( $lDblPosRelX*$this->aIntNumeroCelulaColuna ), $this->aIntNumeroCelulaColuna-1 ); $lDblPosRel = $lDblPosRelY * $this->aIntNumeroCelulaColuna + $lDblPosRelX; return $lDblPosRel; } /** * Método Reponsável por calcular a que classe pertence o valore informado. * Retorna o índice da classe corresponde na camada da classe que representa * o GRID no Mapserver Guarani. * * @param float $pDblvalor * @return int */ private function Calcula_Indice_Celula($pDblvalor) { if (is_null($this->aDblValorKernelmaximo)) $this->aDblValorKernelmaximo = 0; if (is_null($this->aDblValorKernelMinimo)) $this->aDblValorKernelMinimo = 0; if ($pDblvalor != 0) { if ($this->aDblValorKernelmaximo != $this->aDblValorKernelMinimo) { $lIntValor = ($pDblvalor - $this->aDblValorKernelMinimo) / ($this->aDblValorKernelmaximo - $this->aDblValorKernelMinimo) * ($this->aIntNumeroClasses - 1); $lIntValor = round($lIntValor, 0); $lIntValor += 1; } else $lIntValor = 1; } else $lIntValor = $pDblvalor; return $lIntValor; } /** * Método responsável por retornar as células adjacentes a célula de origem * que estejam dentro dos limites estipulados pelo usuário para TAU. * Apresenta como retorno uma string contendo das células adjacentes. * * @param int $pIntIndice * @return string */ private function Calcula_Celulas_Tau($pIntIndice) { $lStrCelulas = ""; for ($f = 1; $f < $this->aIntTau; $f++) { $lIntIndCelula1 = $pIntIndice - ( $f * $this->aIntNumeroCelulaColuna); $lIntIndCelula2 = $pIntIndice + ( $f * $this->aIntNumeroCelulaColuna); if ($lIntIndCelula1 >= 0 && $lIntIndCelula1 < ($this->aIntNumeroCelulaColuna*$this->aIntNumeroCelulaLinha)) $lStrCelulas .= " ".$lIntIndCelula1; if ($lIntIndCelula2 >= 0 && $lIntIndCelula2 < ($this->aIntNumeroCelulaColuna*$this->aIntNumeroCelulaLinha)) $lStrCelulas .= " ".$lIntIndCelula2; } return $lStrCelulas; } /** * Método responsável por retornar as células adjacentes a célula de origem * que estejam dentro dos limites estipulados pelo usuário para TAU. * Este método não considera as os limites de células que estejam fora dos limites
* máximos estipulados pelo usuário. * Apresenta como retorno um array contendo o índice de todas as células adjacentes, * incluindo o índice da célula de origem no retorno. * * @param int $pIntIndice * @return array */ private function Celulas_Inclusas_Tau($pIntIndOrig) { /* Encontrando qual a linha atual que está a célula de origem. */ $lIntLinhaAtual = floor($pIntIndOrig/$this->aIntNumeroCelulaColuna); $lStrCelulas = $pIntIndOrig; $lArrCelulas = array(); /* verificando as celulas adjacentes a de origem. */ $lStrCelulas .= $this->Calcula_Celulas_Tau($pIntIndOrig); for ($l = 1; $l < $this->aIntTau; $l++) { $lIntIndeColAtual = $pIntIndOrig - $l; /* Verificando se a célula se encontra fora dos limites. */ if (floor($lIntIndeColAtual/$this->aIntNumeroCelulaColuna) == $lIntLinhaAtual) { $lStrCelulas .= " ".$lIntIndeColAtual; $lStrCelulas .= $this->Calcula_Celulas_Tau($lIntIndeColAtual); } $lIntIndeColAtual = $pIntIndOrig + $l; /* Verificando se a célula se encontra fora dos limites. */ if (floor($lIntIndeColAtual/$this->aIntNumeroCelulaColuna) == $lIntLinhaAtual) { $lStrCelulas .= " ".$lIntIndeColAtual; $lStrCelulas .= $this->Calcula_Celulas_Tau($lIntIndeColAtual); } } return ( explode(" ", $lStrCelulas) ); } /** * Método respon?avel por pesquisar no bancod de dados todos os resgistros que estão contidos * dentos dos limites do GRID. Espe método executa uma pesquisa espacial através de uma funcão * específica do PostGIS para localizar tais registros. * A pesquisa espacial é executada somente uma vez e retorna todos os registros encontrados, sendo * que a celula correspondete para acada registro será calculada. * * @return boolean */ private function Busca_Lances_Total() { $lIntCod = ""; $lStrSqlPesquisaEspacial = ""; $lStrSqlSelect = "SELECT "; $lStrSqlFrom = "FROM "; $lStrSqlWhere = "WHERE "; $lStrSqlGeomExtent = "GeomFromText('POLYGON(("; $lArrLances = array(); $lArrDadosLance = array(); $lObjDbConexao = new DB_LCA(); $lObjLance = new Lance(); /* * Montando o SQL a ser utilizado para a pesquisa, o primeiro passo é retornar os códigos únicos * de todos os registros contidos dentro do GRID. */ $lStrSqlSelect = $lStrSqlSelect."pesq.cod_lance_serial, X(pesq.geo_coordenada_inicial), Y(pesq.geo_coordenada_inicial) "; $lStrSqlFrom = $lStrSqlFrom."prt_dados_lance_tcc pesq "; $lStrSqlWhere = $lStrSqlWhere."Intersects(pesq.geo_coordenada_inicial, "; /* * Montando o objeto geométrico utilizado para a pesquisa espacial, este objeto é basedo nos * limites dos GRID. */ $lStrSqlGeomExtent = $lStrSqlGeomExtent.$this->aArrExtent[0]." ".$this->aArrExtent[1]; $lStrSqlGeomExtent .= ", ".$this->aArrExtent[0]." ".$this->aArrExtent[3]; $lStrSqlGeomExtent .= ", ".$this->aArrExtent[2]." ".$this->aArrExtent[3]; $lStrSqlGeomExtent .= ", ".$this->aArrExtent[2]." ".$this->aArrExtent[1]; $lStrSqlGeomExtent .= ", ".$this->aArrExtent[0]." ".$this->aArrExtent[1];
$lStrSqlGeomExtent = $lStrSqlGeomExtent."))', -1)"; /* Integrando objeto espacial na cláusula WHERE do SQL. */ $lStrSqlWhere = $lStrSqlWhere.$lStrSqlGeomExtent.") AND dat_data_inicial >= to_date ('$this->aTmpTempo_Inicial', 'DD/MM/YYYY') AND dat_data_inicial <= to_date('$this->aTmpTempo_Final', 'DD/MM/YYYY')"; /* Finalizando e montando o SQL de pesquisa. */ $lStrSqlPesquisaEspacial = $lStrSqlSelect.$lStrSqlFrom.$lStrSqlWhere; /* Reqlizando a consulta no banco de dados. */ $lObjDbConexao->Consulta($lStrSqlPesquisaEspacial); /* Retornando os registros. */ while($lObjDbConexao->ProximoRegistro()) { list($lIntCod, $lDblXLance, $lDblYLance) = $lObjDbConexao->Tupla(); $lArrInfoTmp = array($lIntCod, $lDblXLance, $lDblYLance); array_push($lArrLances, $lArrInfoTmp); } $lObjDbConexao->libera(); /* * Para cada registro encontrado os dados completos serão retornados do banco de dados * pela classe Llance (provida pelo PescaTijucas) que á partir do identificador do Lance * retorna todos os dados deste. */ for ($l = 0; $l < sizeof($lArrLances); $l++) { /* Calculando a qual célula o registro pertence. */ $lIntPos = $this->Calcula_Celula_Lance($lArrLances[$l][1], $lArrLances[$l][2]); /* Retornando os dados completos do Lance encontrado. */ array_push( $this->aArrDadosLanceCel[$lIntPos], $lObjLance->Retorna_Dados_Lance_Arrasto($lArrLances[$l][0]) ); } return true; } /** * Método responsável por instanciar o objeto célula correspondente aos limites informados, * apresentando os dados repassados. * * @param array $pArrExtentJanela * @param array $pArrDadosCelula */ private function Instancia_Celula($pArrExtentJanela, $pArrDadosCelula) { /* Instanciando o objeto do tipo célula. */ $lObjCelula = new Celula(); /* Inicializando a célula. */ $lObjCelula->Inicializa_Celula_Kernel(); /* Setando os limites espaciais da célula. */ $lObjCelula->setExtentCelula($pArrExtentJanela); /* Setando as datas de análise. */ $lObjCelula->setDataInicialAnalise($this->aTmpTempo_Inicial); $lObjCelula->setDataFinalAnalise($this->aTmpTempo_Final); /* Setando os dados da célula. */ $lObjCelula->setArrayDadosCelula($pArrDadosCelula); /* * Executando uma pesquisa espacial no banco de dados PostGIS * para retornar o ponto dentral da célula e sua área. */ $lStrSqlSelect = "SELECT X(t.geom), Y(t.geom), t.area FROM (SELECT "; $lStrSqlCentroid = "CENTROID("; $lStrSqlArea = "AREA2D("; $lStrSqlGeomExtent = "GeomFromText('POLYGON(("; $lStrSqlGeomExtent = $lStrSqlGeomExtent.$pArrExtentJanela[0][0]." ".$pArrExtentJanela[0][1]; for ($f = 1; $f < sizeof($pArrExtentJanela); $f++) { $lStrSqlGeomExtent .= ", ".$pArrExtentJanela[$f][0]." ".$pArrExtentJanela[$f][1]; } $lStrSqlGeomExtent = $lStrSqlGeomExtent."))', -1)"; $lStrSqlCentroid .= $lStrSqlGeomExtent.") AS geom,"; $lStrSqlArea .= $lStrSqlGeomExtent.") AS area"; $lStrSqlSelect = $lStrSqlSelect.$lStrSqlCentroid.$lStrSqlArea.") t"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); if ($lObjDbConexao->ProximoRegistro()) { list($lDblX, $lDblY, $lDblArea) = $lObjDbConexao->Tupla();
} $lObjDbConexao->libera(); /* Finalizando a consulta ao banco de dados. */ /* Setando o ponto central da célula. */ $lObjCelula->setCoordenadaPontoCelula($lDblX, $lDblY, 0); /* Setando a área da célula. */ $lObjCelula->setAreaCelula($lDblArea); /* * Executando a funcão responsável por retornar o valor para os dados da célula * este valor se baseia na métrica estipulada pelo usuário. */ $this->aArrValoresMetrica = $this->CalculaValorMetrica($lObjCelula, $this->aIntMetrica); /* Setando o valor para a célula. */ $lObjCelula->setValorMetricaCelula($this->aArrValoresMetrica); /* * Executando o método que irá realizar a análise espacial pelo método Kernel * na célula pesquisada. */ $lDblValor = $this->Analise_Geoespacial_Da_Janela($lObjCelula); /* Setando o valor da análise para a célula. */ $lObjCelula->setValorKernelCelula($lDblValor); /* Armazenando as células no array de células da classe. */ array_push($this->aArrCelulas, $lObjCelula); if ($lDblValor != 0) if (is_null($this->aDblValorKernelmaximo)) $this->aDblValorKernelmaximo = $lDblValor; elseif ($lDblValor > $this->aDblValorKernelmaximo) $this->aDblValorKernelmaximo = $lDblValor; elseif (is_null($this->aDblValorKernelMinimo)) $this->aDblValorKernelMinimo = $lDblValor; elseif ($lDblValor < $this->aDblValorKernelMinimo) $this->aDblValorKernelMinimo = $lDblValor; } /** * Método responsável por criar a célula no objeto do mapa do Mapserver Guarani. * Utiliza o como base para geracão da célula os limites da célula de pesquisa. * * @param Celula $pObjCelula * @param layerObj $pObjCelulaMapserver * @param string $pStrTexto */ private function Cria_Celula_Correspondente_Mapserver(Celula $pObjCelula, $pObjCelulaMapserver, $pStrTexto) { /* Calculando o índice da célula. */ $lIntIndice = $this->Calcula_Indice_Celula($pObjCelula->getDblValorKernel()); $lArrExtentCelula = $pObjCelula->getExtentCelula(); /* Criando um polígomo fechado para a célula. */ $lObjPoligono = ms_newShapeObj(MS_SHAPE_POLYGON); $lObjLinha = ms_newLineObj(); for ($f = 0; $f < sizeof($lArrExtentCelula); $f++) { $lObjLinha->addXY($lArrExtentCelula[$f][0], $lArrExtentCelula[$f][1]); } $lObjPoligono->add($lObjLinha); /*Setando a qual classe pertence a célula. */ $lObjPoligono->set("classindex", $lIntIndice); /* Adicionando a string de rótulo para a célula. */ //$lObjPoligono->set("text", $pObjCelula->getDblValorKernel()); //$lObjPoligono->set("text", $pStrTexto); $lObjPoligono->set("text", $lIntIndice); /* Limpando objetos não mais utilizados. */ $lObjLinha->free(); /* Adicionando a célula a objeto do Mapserver guarani. */ $pObjCelulaMapserver->addFeature( $lObjPoligono ); /* Limpando objetos não mais utilizados. */ $lObjPoligono->free(); } /** * Método que realiza a análise espacial pelo método Kernel nos dados pesquisados. * O método Kernel foi implementado seguindo as especificacão de modelo descritas no
* documento TCC. * * @param Celula $pObjCelula * @return float */ private function Analise_Geoespacial_Da_Janela(Celula $pObjCelula) { /* Laco condicional para verificar se o usuário deseja analisar a célula pelo método Kernel. */ if ($this->aIntTau > 0) { $lDblKDimensao1 = 0; $lDblKDimensao2 = 0; $lDblKTotal = 0; $lDblKFinal = 0; $lDblKSoma = 0; $lArrDados = array(); /* Contante FatorU. */ $lDblFatorU = 3/pi(); /* Calculando o Tau para a célula. */ $lDblTau = sqrt( pow(($this->aDblGranularidade_Grid)/2,2) + pow(($this->aDblGranularidade_Grid)/2,2) ); $lDblTau *= $this->aIntTau; //$lDblTau = ( ($this->aDblGranularidade_Grid*$this->aIntTau)*sqrt(2) )/2; /* Retornando o ponto central da célula. */ $lArrPosicoes = $pObjCelula->getCoordenadaPontoCelula(); $lDblPosicaoX = $lArrPosicoes[0]; $lDblPosicaoY = $lArrPosicoes[1]; /* Retornando os registros para a célula. */ $lArrDados = $pObjCelula->getArrDadosCelula(); for ($f = 0; $f < sizeof($lArrDados); $f++) { if ($lArrDados[$f][1][9] != null && $lArrDados[$f][1][10] != null) { /* Calculando a posicão relativa de X em relacao a celula. */ $lDblDX = $lDblPosicaoX-$lArrDados[$f][1][9]; /* Calculando a posicão relativa de X em relacao a celula. */ $lDblDY = $lDblPosicaoY-$lArrDados[$f][1][10]; /* Calculando a lozalizacão do dado, basedado em TAU. */ $lDblSSi = sqrt( pow($lDblDX,2) + pow($lDblDY,2) )/$lDblTau; if ($lDblSSi <= 1) $lDblK = pow( 1-$lDblSSi*$lDblSSi, 2)*$lDblFatorU; else $lDblK = 0; //$lDblKSoma += $lDblK; //$lDblKDimensao1 += $lDblK*$pObjCelula->getDblValorMetricaPos(1); //$lDblKDimensao2 += $lDblK*$pObjCelula->getDblValorMetricaPos(2); //$lDblKTotal += $lDblK*$pObjCelula->getDblValorMetricaPos(0); $lDblKDimensao1 += $lDblK*$lArrDados[$f][4][1]; $lDblKDimensao2 += $lDblK*$lArrDados[$f][4][2]; $lDblKTotal += $lDblK*$lArrDados[$f][4][0]; } } if ($lDblKDimensao2 != 0) { //$lDblKFinal = $lDblKDimensao1/$lDblKDimensao2; $lDblKFinal = $lDblKTotal; $lDblLambda = $lDblKFinal; //$lDblMediaKernel = $lDblLambda/$lDblKSoma; } else { $lDblLambda = 0; } return $lDblLambda; } else { return $pObjCelula->getDblValorMetricaPos(0); }
} private function CalculaValorMetrica(Celula $pObjCelula, $pIntMetrica) { $lArrDados = array(); $lDblPeso = 0; $lDblTempoArrasto = 0; $lIntNLances = 0; $lIntNBarcos = 0; $lArrNBarcos = array(); $lArrNLances = array(); $lArrValoresMetrica = array(); $lArrValoresMetricaReg = array(); $lArrValoresMetrica = array_fill(0, 3, 0); $lDblCalculo = 0; $lArrDados = $pObjCelula->getArrDadosCelula(); for ($f = 0; $f < sizeof($lArrDados); $f++) { $lArrValoresMetricaReg = array(); switch ($pIntMetrica) { case 1: { for ($i = 0; $i < sizeof($lArrDados[$f][2]); $i++) { $lDblPeso += $lArrDados[$f][2][$i][1]; } $lStrSqlSelect = "SELECT to_timestamp('".$lArrDados[$f][1][5]."', 'HH24:MI') > to_timestamp('".$lArrDados[$f][1][2]."', 'HH24:MI')"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lStrVData) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); if ($lStrVData == 'f') { $lStrSqlSelect = "SELECT to_char(to_date('".$lArrDados[$f][1][1]."', 'DD/MM/YYYY') + 1, 'DD/MM/YYYY')"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lStrDataIni) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); } else $lStrDataIni = $lArrDados[$f][1][1]; $lStrSqlSelect = "SELECT 24*EXTRACT(DAY FROM d.DATA)+EXTRACT(HOUR FROM d.DATA)+(EXTRACT(MINUTE FROM d.DATA)/60) FROM (SELECT to_timestamp('".$lArrDados[$f][1][5]." ".$lStrDataIni."', 'HH24:MI DD/MM/YYYY') - to_timestamp('".$lArrDados[$f][1][2]." ".$lArrDados[$f][1][1]."', 'HH24:MI DD/MM/YYYY') as DATA) d"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lDblPeriodo) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); $lDblTempoArrasto += $lDblPeriodo; if ($lDblTempoArrasto != 0.0) $lDblCalculo = $lDblPeso/$lDblTempoArrasto; else $lDblCalculo = 0; $lArrValoresMetricaReg[0] = $lDblCalculo; $lArrValoresMetricaReg[1] = $lDblPeso; $lArrValoresMetricaReg[2] = $lDblTempoArrasto; array_push($lArrDados[$f], $lArrValoresMetricaReg); break; } case 2: { for ($i = 0; $i < sizeof($lArrDados[$f][2]); $i++) {
if ($lArrDados[$f][2][$i][2] == $this->aIntCodProduto) $lDblPeso += $lArrDados[$f][2][$i][1]; } $lStrSqlSelect = "SELECT EXTRACT(DAY FROM d.DATA) FROM (SELECT to_timestamp('".$this->aTmpTempo_Final."', 'DD/MM/YYYY') - to_timestamp('".$this->aTmpTempo_Inicial."', 'DD/MM/YYYY') as DATA) d"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lDblPeriodo) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); if ($lDblPeriodo != 0) $lDblCalculo = $lDblPeso/$lDblPeriodo; else $lDblCalculo = 0; $lArrValoresMetricaReg[0] = $lDblCalculo; $lArrValoresMetricaReg[1] = $lDblPeso; $lArrValoresMetricaReg[2] = $lDblPeriodo; array_push($lArrDados[$f], $lArrValoresMetricaReg); break; } case 3: { $lStrSqlSelect = "SELECT to_timestamp('".$lArrDados[$f][1][5]."', 'HH24:MI') > to_timestamp('".$lArrDados[$f][1][2]."', 'HH24:MI')"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lStrVData) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); if ($lStrVData == 'f') { $lStrSqlSelect = "SELECT to_char(to_date('".$lArrDados[$f][1][1]."', 'DD/MM/YYYY') + 1, 'DD/MM/YYYY')"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lStrDataIni) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); } else $lStrDataIni = $lArrDados[$f][1][1]; $lStrSqlSelect = "SELECT 24*EXTRACT(DAY FROM d.DATA)+EXTRACT(HOUR FROM d.DATA)+(EXTRACT(MINUTE FROM d.DATA)/60) FROM (SELECT to_timestamp('".$lArrDados[$f][1][5]." ".$lStrDataIni."', 'HH24:MI DD/MM/YYYY') - to_timestamp('".$lArrDados[$f][1][2]." ".$lArrDados[$f][1][1]."', 'HH24:MI DD/MM/YYYY') as DATA) d"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lDblPeriodo) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); $lDblTempoArrasto += $lDblPeriodo; $lStrSqlSelect = "SELECT EXTRACT(DAY FROM d.DATA) FROM (SELECT to_timestamp('".$this->aTmpTempo_Final."', 'DD/MM/YYYY') - to_timestamp('".$this->aTmpTempo_Inicial."', 'DD/MM/YYYY') as DATA) d"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lDblPeriodo) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); if ($lDblPeriodo != 0) $lDblCalculo = ($lDblTempoArrasto/24)/$lDblPeriodo; else $lDblCalculo = 0; $lArrValoresMetricaReg[0] = $lDblCalculo; $lArrValoresMetricaReg[1] = ($lDblTempoArrasto/24); $lArrValoresMetricaReg[2] = $lDblPeriodo; array_push($lArrDados[$f], $lArrValoresMetricaReg); break;
} case 4: { $lStrSqlSelect = "SELECT to_timestamp('".$lArrDados[$f][1][5]."', 'HH24:MI') > to_timestamp('".$lArrDados[$f][1][2]."', 'HH24:MI')"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lStrVData) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); if ($lStrVData == 'f') { $lStrSqlSelect = "SELECT to_char(to_date('".$lArrDados[$f][1][1]."', 'DD/MM/YYYY') + 1, 'DD/MM/YYYY')"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lStrDataIni) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); } else $lStrDataIni = $lArrDados[$f][1][1]; $lStrSqlSelect = "SELECT 24*EXTRACT(DAY FROM d.DATA)+EXTRACT(HOUR FROM d.DATA)+(EXTRACT(MINUTE FROM d.DATA)/60) FROM (SELECT to_timestamp('".$lArrDados[$f][1][5]." ".$lStrDataIni."', 'HH24:MI DD/MM/YYYY') - to_timestamp('".$lArrDados[$f][1][2]." ".$lArrDados[$f][1][1]."', 'HH24:MI DD/MM/YYYY') as DATA) d"; $lObjDbConexao = new DB_LCA(); $lObjDbConexao->Consulta($lStrSqlSelect); $lObjDbConexao->ProximoRegistro(); list($lDblPeriodo) = $lObjDbConexao->Tupla(); $lObjDbConexao->libera(); $lDblTempoArrasto += $lDblPeriodo; if (sizeof($lArrNLances) == 0) array_push($lArrNLances, $lArrDados[$f][0][2]); else if (!in_array($lArrDados[$f][0][2], $lArrNLances)) array_push($lArrNLances, $lArrDados[$f][0][2]); if ($lDblTempoArrasto != 0) $lIntNLances = sizeof($lArrNLances)/$lDblTempoArrasto; else $lIntNLances = 0; $lArrValoresMetricaReg[0] = $lIntNLances; $lArrValoresMetricaReg[1] = sizeof($lArrNLances); $lArrValoresMetricaReg[2] = $lDblTempoArrasto; array_push($lArrDados[$f], $lArrValoresMetricaReg); break; } case 5: { if (sizeof($lArrNBarcos) == 0) array_push($lArrNBarcos, $lArrDados[$f][0][2]); else if (!in_array($lArrDados[$f][0][2], $lArrNBarcos)) array_push($lArrNBarcos, $lArrDados[$f][0][2]); $lIntNBarcos = sizeof($lArrNBarcos); $lArrValoresMetricaReg[0] = $lIntNBarcos; $lArrValoresMetricaReg[1] = $lIntNBarcos; $lArrValoresMetricaReg[2] = 1; array_push($lArrDados[$f], $lArrValoresMetricaReg); break; } default: { break; } } } $pObjCelula->setArrayDadosCelula($lArrDados); } } ?>
Arquivo Mapscript.mphp /**************************************************************************************************/ /**************************************************************************************************/ /* TRECHO TCC /**************************************************************************************************/ /**************************************************************************************************/ /* Calculo de GRID /**************************************************************************************************/ /**************************************************************************************************/ if (in_array("grid", $camadas) && $kernelmaxx != "") { $lIntMetrica = $kernelmetrica; $lIntTau = $kerneltau; $lDblGranularidade = $kernelgranularidade; $lTmpDataInicial = $kerneldataini; $lTmpDataFinal = $kerneldatafim; $lArrExtent = array($kernelminx, $kernelminy, $kernelmaxx, $kernelmaxy); $lObjAnaliseGrid = new Algoritmo_Analise_Geoespacial(); $lObjAnaliseGrid->Realiza_Analise_Geoespacial($lArrExtent, $lDblGranularidade, $lTmpDataInicial, $lTmpDataFinal, $lIntMetrica, $lIntTau, $lIntCodEspecie, $mapa ); } /**************************************************************************************************/ /**************************************************************************************************/ /* TRECHO TCC /**************************************************************************************************/ /**************************************************************************************************/ /* Calculo de GRID /**************************************************************************************************/ /**************************************************************************************************/
Arquivo selecao.js /* * Variáveis do método Kernel * para permitir integracão com * outras abas do Mapserver Guarani */ var kernelminx = ""; var kernelminy = ""; var kernelmaxx = ""; var kernelmaxy = ""; var kernelgranularidade = ""; var kerneltau = ""; var kernelmetrica = ""; var kerneldataini = ""; var kerneldatafim = ""; /* * Fim da declaracão das variáveis de integracão com o método Kernel */ /* * Método adicionado ao código para permitir a coumunicacão entre a interface disponibilizada ao usuário para * para o método Kernel e o Mapserver Guarani. Esta funcão é basedada na funcão DesenhaMapa() do Mapserver Guarani. */ function EnviaDadosKernel(pDblMinx, pDblMiny, pDblMaxx, pDblMaxy, pDblGranularidade, pIntTau, pIntMetrica, pStrDataIni, pStrDataFim) { carregar(1); tmpacao = "";
var srcmapa = ArquivoScript; srcmapa += "arquivo_do_mapa=" + ArquivoMap; kernelminx = pDblMinx; kernelminy = pDblMiny; kernelmaxx = pDblMaxx; kernelmaxy = pDblMaxy; kernelgranularidade = pDblGranularidade; kerneltau = pIntTau; kernelmetrica = pIntMetrica; kerneldataini = pStrDataIni; kerneldatafim = pStrDataFim; srcmapa += "&kernelminx="+kernelminx; srcmapa += "&kernelminy="+kernelminy; srcmapa += "&kernelmaxx="+kernelmaxx; srcmapa += "&kernelmaxy="+kernelmaxy; srcmapa += "&kernelgranularidade="+kernelgranularidade; srcmapa += "&kerneltau="+kerneltau; srcmapa += "&kernelmetrica="+kernelmetrica; srcmapa += "&kerneldataini="+kerneldataini; srcmapa += "&kerneldatafim="+kerneldatafim; //variaveis para o mapa principal srcmapa += "&largura_mapa=" + ImagemLargura; srcmapa += "&altura_mapa=" + ImagemAltura; srcmapa += "&extent_x1=" + MinExtX; srcmapa += "&extent_y1=" + MinExtY; srcmapa += "&extent_x2=" + MaxExtX; srcmapa += "&extent_y2=" + MaxExtY; //variaveis para a referencia srcmapa += "&ref_largura_mapa=" + LarguraImagemRef; srcmapa += "&ref_altura_mapa=" + AlturaImagemRef; srcmapa += "&ref_extent_x1=" + RefMinExtX; srcmapa += "&ref_extent_y1=" + RefMinExtY; srcmapa += "&ref_extent_x2=" + RefMaxExtX; srcmapa += "&ref_extent_y2=" + RefMaxExtY; if(SelecaoImagem) { srcmapa += "&sel_x1=" + PSelx1; srcmapa += "&sel_y1=" + PSely1; srcmapa += "&sel_x2=" + PSelx2; srcmapa += "&sel_y2=" + PSely2; if (PesquisandoSelecao) { srcmapa += "&acao=" + "pesquisaselecao"; tmpacao = "pesquisaselecao"; } else { srcmapa += "&acao=" + "selecao"; tmpacao = "selecao"; } } else if (ZoomMais) { srcmapa += "&acao=" + "aproximacao_centralizada"; srcmapa += "&fator_de_zoom=" + "2"; tmpacao = "aproximacao"; } else if (ZoomMenos) { srcmapa += "&acao=" + "aproximacao_centralizada"; srcmapa += "&fator_de_zoom=" + "-2"; tmpacao = "aproximacao"; } else if (ZoomPadrao) { srcmapa = ArquivoScript; srcmapa += "arquivo_do_mapa=" + ArquivoMap; srcmapa += "&largura_mapa=" + ImagemLargura; srcmapa += "&altura_mapa=" + ImagemAltura; srcmapa += "&acao=" + "reset"; srcmapa += "&ref_largura_mapa=" + LarguraImagemRef; srcmapa += "&ref_altura_mapa=" + AlturaImagemRef; tmpacao = "reset";
VizinhancaPonto = ""; VizinhancaRaio = ""; PontosPesquisa = false; } else if (MoverImagem) { tmpacao = "moverimagem"; srcmapa += "&acao=" + "moverimagem"; } srcmapa += "&camadas_info="; mais = ""; for(i=0;i<CamadasDados.length;i++) { if ((CamadasDados[i][4] == -1) || (CamadasDados[i][4] == CartaSelecionada)) { if (CamadasDados[i][7] == true) { srcmapa +=mais+CamadasDados[i][1]; mais = "+"; } } } srcmapa += "&camadas_sel="; mais = ""; for(i=0;i<CamadasDados.length;i++) { if (CamadasDados[i][2]) { srcmapa +=mais+CamadasDados[i][1]; mais = "+"; } } if (embarcacoesselecionadas != '') { srcmapa += "&embarcacao="+embarcacoesselecionadas+"&dataini="+dataini+"&datafim="+datafim; }; if (PontosPesquisa == true) { srcmapa += "&pontos_pesquisa=1"; PontosPesquisa = false; } else srcmapa += "&pontos_pesquisa=0"; if (CalcularVizinhanca) // { srcmapa += "&enviar_pesquisa=1"; } else { srcmapa += "&enviar_pesquisa=0"; } if ((VizinhancaPontoX != "") && (VizinhancaRaio != "")) { srcmapa += "&vizinhanca_pontox="+VizinhancaPontoX+"&vizinhanca_pontoy="+VizinhancaPontoY+"&vizinhanca_raio="+VizinhancaRaioKM; } if (EscalaPadrao != 0) { srcmapa += "&escala_padrao="+EscalaPadrao; } if ((tmpacao == 'reset') || (tmpacao == '')) { ZeraHistorico(); } HistoricoAtual = ArrayHistorico.length; ArrayHistorico[ArrayHistorico.length] = [encodeURI(srcmapa)]; Historico(0);
MapaScript.src = encodeURI(srcmapa); } /* * Fim do método para comunicacão com a interface do método Kernel */
Anexo I – MODELAGEM MAPSERVER GUARANI
As seções abaixo apresentam a modelagem existente para o framework Mapserver Guarani.
ACESSO AO MAPFILE
Figura 1: Integração com o arquivo Mapfile.
SCRIPTS PHP
Figura 2: Scripts PHP.
SCRIPTS JAVASCRIPT
Diagrama contendo a organização dos vários scripts.
index.php
+ openwindow(String) : void
idioma.php
inicial.php
configura a variável de sessão
"sessionglobalIdioma" com o
idioma selecionado
gcjs.php
config.inc
responsável pela criação do script JS
com as variáveis configuradas na
ferramenta administrativa
responsável pela criação do script
PHP com as variáveis configuradas na
ferramenta administrativa
«framework»
Mapserver Guarani
MapScript
«.map»
mapfi le
Figura 3: Scripts JavaScript.
DIAGRAMA DE SEQÜÊNCIA
Diagrama de seuqüencia do script seleção.js.
Referência
Menus
Caixa de ferramenta
Scripts básicos
base carregar selecao
caixaferramenta abaferramenta
menu iframe cartas camadas
consulta analiseespacial calculodistancia abamenu
referencia abareferencia barrareferencia
Figura 4: Diagrama de seqüência.
DIAGRAMA DE CLASSE
Figura 5: Diagrama de classe.
.
.
ADM_SISTEMA
ID_SISTEMA
DIRETORIOPADRAO
URLPADRAO
ARQUIVOMAP
ARQUIVOSCRIPT
ARQUIVOQUERY
DIRETORIOIMAGEM
TIPOSISTEMA
MINEXTX
MINEXTY
MAXEXTX
MAXEXTY
DIRETORIOINCLUDES
DIRETORIODATA
NOMEPROJETO
<pk>
ADM_CARTAS
ID_CARTA
NOME_CARTA
<pk>
ADM_CAMPO
NOME
ID_LAYER
LABEL
TIPO
FUNCAO
<pk>
<fk>
ADM_LAYER
ID_LAYER
ID_CARTA
LABEL
NOME
DADOS
CHECKED
FIXO
SELECIONADA
ORIGEM_DATA
REFERENCIA
INFO_ATIVO
ORDEM
<pk>
<fk>
usuario
MS
Guarani::MapScript
MS Guarani - JS
Basico::selecao.js
MS Guarani - JS
Basico::analiseespacial
a chamada ao MapScript é feita pela chamada do src de um iframe oculto
DesenhaMapa()
executa
MostrarSelecaoPesquisa(sessao)
CarregaMapa()
ARTIGO CIÊNTÍFICO
