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 MÓDULO DE SISTEMA PARA
GEOCODIFICAÇÃO DE DADOS PESQUEIROS POR QUADRANTE
Área de Sistemas de Informação
por
Adalberto Cidnei de Menezes
Adriana Gomes Alves, M.Eng.
Orientadora
Paulo Ricardo Pezzuto, 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 MÓDULO DE SISTEMA PARA
GEOCODIFICAÇÃO DE DADOS PESQUEIROS POR QUADRANTE
Área de Sistemas de Informação
por
Adalberto Cidnei de Menezes
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientadora: Adriana Gomes Alves, M.Eng.
Itajaí (SC), dezembro de 2005.
“[...] um tempo em que aprendi a entender as coisas do mar, a conversar com as grandes ondas e
não descutir com o mau tempo. A transformar o medo em respeito, o respeito em confiança.
Descobri como é bom chegar quando se tem paciência. E para se chegar, aonde quer que seja,
aprendi que não é preciso dominar a força, mas a razão. É preciso, antes de mais nada, querer.”
AMYR KLINK, 1985.
iii
DEDICATÓRIA
À minha esposa e companheira,
Nilva,
Aos meus filhos,
Jéferson e Welliton
iv
HOMENAGEM
Aos ausentes, que no decorrer desse projeto partiram,
mas que com certeza estarão dando força
no lugar onde estão:
Minha vó Camila Gomes Cavalheiro,
Meu avô Ademar Cavalheiro,
Meu cunhado Valdecir Pedro de Borba,
Minha cunhada Marli Trento,
Minha nona Maria Sechi, e
Minha prima “Preta”.
v
AGRADECIMENTOS
Agradeço a:
Deus, por ter me dado a vida e as oportunidades que muitos gostariam de ter que eu tive;
Aos meus pais, Albino e Dileta, e toda a minha família que sempre acreditaram em minhas
capacidades e se orgulham de tudo que faço;
A minha esposa Nilva, por ter me suportado nos momentos difíceis e dado a força necessária para
que eu não desistisse;
Ao meu irmão José, por todo o apoio e pela compreensão;
A minha orientadora Adriana, pelos momentos de esclarecimento, pela paciência e pela força
incondicional;
Ao meu co-orientador Pezzuto, por toda a força despendida, pelo apoio, pela compreensão, pelos
“puxões de orelha”, pelas explicações....;
Aos meus amigos do Laboratório de Computação Aplicada, por todo o apoio dispensado e pela
oportunidade. Em especial ao Rafael Sperb, Carlos Bughi e Fernando Simon;
Ao pessoal do Laboratório de Geoprocessamento também pelo apoio em especial ao Rodrigo e ao
Sergey;
Por fim a todos os meu amigos que não estão citados aqui, mas que contribuíram para que essa idéia
chegasse ao final.
vi
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................x
LISTA DE FIGURAS ..............................................................................xi
LISTA DE TABELAS.............................................................................xii
RESUMO ................................................................................................xiii
ABSTRACT ...............................................................................................1
1. INTRODUÇÃO.....................................................................................1
1.1. OBJETIVOS ........................................................................................................ 4
1.1.1. Objetivo Geral ................................................................................................... 4
1.1.2. Objetivos Específicos ........................................................................................ 4
1.2. METODOLOGIA................................................................................................ 5
1.3. ESTRUTURA DO TRABALHO ....................................................................... 7
2. FUNDAMENTAÇÃO TEÓRICA .......................................................8
2.1. PESCA .................................................................................................................. 8
2.1.1. Pesca e Sustentabilidade................................................................................... 8
2.1.2. Gerenciamento da Pesca no Brasil .................................................................. 9
2.1.3. Políticas de Ordenamento Pesqueiro ............................................................ 11
2.1.4. Gerenciamento Espacial da Atividade Pesqueira........................................ 13
2.1.5. Informações de Pesca em Santa Catarina .................................................... 16
2.2. INFORMAÇÕES GEOGRÁFICAS OU GEOINFORMAÇÕES ................ 20
2.2.1. Dados Espaciais ou Geográficos .................................................................... 20
2.2.2. Geocodificação................................................................................................. 23
2.2.3. Representação Computacional de Dados Geográficos................................ 27
2.3. TECNOLOGIAS ADOTADAS PARA O PROJETO.................................... 30
2.3.1. WebMapping .................................................................................................... 30
2.3.2. Servidores de Mapas....................................................................................... 32
2.3.3. Banco de Dados Geo Espaciais ...................................................................... 37
2.3.4. Linguagem de Programação .......................................................................... 42
2.4. FERRAMENTAS SIMILARES....................................................................... 44
2.4.1. Sipesca .............................................................................................................. 44
2.4.2. Sagreh............................................................................................................... 45
2.4.3. Rastro ............................................................................................................... 45
2.4.4. Ecosgrass.......................................................................................................... 46
2.5. MÉTODO DE DIVISÃO POR QUADRANTES............................................ 46
3. PROJETO............................................................................................48
3.1. INTRODUÇÃO ................................................................................................. 48
3.2. DADOS DO SISTEMA ..................................................................................... 48
3.3. MODELAGEM DO SISTEMA........................................................................ 49
vii
3.3.1.
3.3.2.
3.3.3.
3.3.4.
3.3.5.
3.3.6.
3.3.7.
3.3.8.
3.3.9.
Ferramenta de Modelagem ............................................................................ 49
Requisitos do Sistema ..................................................................................... 50
Estudo do Modelo de Banco de dados do SIESPE....................................... 51
Diagramas de Caso de Uso ............................................................................. 53
Descrições dos Casos de Uso .......................................................................... 54
Diagrama de classes e ER............................................................................... 56
Representação da Estrutura do Sistema....................................................... 59
Definição dos Mapas ou Cartas ..................................................................... 59
Definição e aquisição dos quadrantes ........................................................... 60
4. IMPLEMENTAÇÃO..........................................................................61
4.1. CRIAÇÃO DOS QUADRANTES.................................................................... 62
4.1.1. Delimitação do Grid ........................................................................................ 62
4.1.2. Processo de Criação dos Pontos para Divisão em Quadrantes .................. 63
4.1.3. Processo de fechamento dos quadrantes e acerto da linha de costa .......... 64
4.1.4. Adequação do Banco de Dados para Armazenamento de Objetos
Espaciais ..................................................................................................................... 66
4.1.5. Importação dos Dados do Formato Shapefile para o Oracle Spatial ......... 66
4.2. INSTALAÇÃO DOS PROGRAMAS NECESSÁRIOS AO
DESENVOLVIMENTO ........................................................................................... 67
4.3. IMPLEMENTAÇÃO DO MÓDULO DE ESPACIALIZAÇÃO.................. 68
4.3.1. Seleção de Quadrantes.................................................................................... 69
4.3.2. Consultar Desembarques Não Espacializados ............................................. 75
4.3.3. Consultar desembarques espacializados....................................................... 77
4.3.4. Análise de campos descritivos e listagem de áreas diferentes .................... 79
4.3.5. Integração entre o Sistema SIESPE e o Módulo de Espacialização .......... 80
4.4. TESTES E VALIDAÇÃO................................................................................. 82
5. TRABALHOS FUTUROS .................................................................83
6. CONCLUSÕES ...................................................................................84
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................86
GLOSSÁRIO ...........................................................................................90
APÊNDICE A ..........................................................................................93
PROCESSO DE IMPORTAÇÃO DE DADOS...................................................... 93
APÊNDICE B ..........................................................................................97
INSTALAÇÃO DE PROGRAMAS ........................................................................ 97
APÊNDICE C ........................................................................................ 103
TABELAS CRIADAS PARA O MODULO ......................................................... 103
APÊNDICE C ........................................................................................ 104
DESCRIÇÃO DETALHADA DE ALGUNS PROCESSOS ............................... 104
APÊNDICE D ........................................................................................ 106
viii
ARTIGO CIENTÍFICO ......................................................................................... 106
ix
LISTA DE ABREVIATURAS
ABNT
CTTMar
DPA
FAO
GEP
GML
HTML
LCA
MNT
NASA
PHP
SEAP/PR
SGDB
SIESPE
SIG
SPRING
SQL
TCC
UNIVALI
UTM
W3C
WCS
WEB(WWW)
WFS
AJAX
Associação Brasileira de Normas Técnicas
Centro de Ciências Tecnológicas da Terra e do Mar
Departamento de Pesca e Aqüicultura
Food and Agriculture Organization of the United Nations
Grupo de Estudos Pesqueiros
Geography Markup Language
Hyper Text Markup Language
Laboratório de Computação Aplicada
Modelo Numérico do Terreno
National Aeronautics and Space Administration
Hipertext Processor
Secretaria Especial de Aqüicultura e Pesca
Siestema Gerenciador de Banco de Dados
Sistema Integrado de Estatística Pesqueira
Sistema de Informação Geográfica
Sistema de Processamento de Informações Geográficas
Structured Query Language (Linguagem de Consulta Estruturada)
Trabalho de Conclusão de Curso
Universidade do Vale do Itajaí
Universal Transverse Mercator
World Wide Web Consortium
Web Coverage Service
World Wide Web
Web Feature Service
Asynchronous JavaScript and XML
LISTA DE FIGURAS
Figura 1. Uma das telas do SIESPE para entrada de áreas ................................................................19
Figura 2. Representação mostrando as folhas projetadas no processo UTM para o Brasil ...............26
Figura 3. Um exemplo de possível arquitetura Webmapping ............................................................32
Figura 4. Tipos primitivos do Oracle Spatial ....................................................................................40
Figura 5. Relações entre os tipos de pesquisa espacial ......................................................................42
Figura 6. Representação dos Requisitos Funcionais ..........................................................................50
Figura 7. Representação dos Requisitos não funcionais ....................................................................51
Figura 8. Visão parcial do modelo de dados do SIESPE ...................................................................53
Figura 9. Visão Use Case do módulo proposto..................................................................................54
Figura 10. Modelo Conceitual mostrando a relação do Módulo proposto ao do SIESPE. ................57
Figura 11. Diagrama de Entidade Relacionamento............................................................................58
Figura 12. Estrutura do sistema proposto...........................................................................................59
Figura 13: Grid de pontos base dos quadrantes..................................................................................63
Figura 14: Representação de parte da planilha de pontos e suas representações. ..............................64
Figura 15: Representação da grade de quadrantes fechados .............................................................65
Figura 16: Representação do processo de importação dos dados para banco de dados.....................67
Figura 17: Tela principal do sistema, com detalhe para os quadrantes e a batimetria. ......................69
Figura 18: Opção de menu para seleção de quadrantes .....................................................................70
Figura 19: Espacialização com os quadrantes selecionados e a tabela de informação. .....................71
Figura 20: Mensagem indicando que o quadrante já foi selecionado ................................................72
Figura 21: Código para seleção de quadrante ....................................................................................73
Figura 22: Tela atualizada, destacando os quadrantes salvos. ...........................................................74
Figura 23: Opção de menu para procura de desembarques não espacializados.................................75
Figura 24: Representação da consulta a desembarque . .....................................................................77
Figura 25: Consulta a um de um desembarque, mostrando os quadrantes selecionados ...................79
Figura 26: Tela do SIESPE mostrando o botão de integração ...........................................................81
Figura 27: Trecho do código fonte para chamada do módulo de quadrantes. ...................................81
LISTA DE TABELAS
Tabela 1.: Caso de uso executa novo lançamento para espacializar. .................................................54
Tabela 2.: Caso de Uso consulta dados de lançamentos espacializados. ...........................................55
Tabela 3.: Caso de uso Espacializar Lançamento Existente ..............................................................55
Tabela 4.: Caso de uso monta e atualiza a tela...................................................................................56
RESUMO
MENEZES, Adalberto Cidnei de. Desenvolvimento de um Módulo de Sistema para
Geocodificação de Dados Pesqueiros por Quadrante. Itajaí, 2005. 119 f. 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.
A pesca é uma atividade extrativista e, como tal, necessita de constante monitoramento para
prevenir o esgotamento dos recursos. Estudos são realizados por diversos institutos de pesquisa para
avaliar a situação dos estoques e propor políticas de exploração e gerenciamento adequados. Para
que essas ações possam assegurar a proteção das espécies e do meio ambiente é necessário ter
conhecimento das áreas onde os recursos são pescados. Esse trabalho apresenta o desenvolvimento
de um módulo de sistema para geocodificação de dados pesqueiros por quadrante
(latitude/longitude), a ser implantado junto ao Sistema Integrado de Estatística Pesqueira Industrial
de Santa Catarina (SIESPE), o qual atualmente não permite a sistematização de informações
referentes às áreas de pesca. Esse módulo utiliza tecnologias de geoprocessamento, Sistema de
Informação Geográfica e Webmapping para permitir a inserção de dados georeferenciados através
da seleção dos objetos (quadrantes). O trabalho agrega outras funcionalidades como a utilização de
procedimentos para recuperação de informações existentes passando da forma textual para o
formato de quadrantes. O objetivo é facilitar o trabalho dos pesquisadores do Grupo de Estudos
Pesqueiros (GEP) da Universidade do Vale do Itajaí (UNIVALI), possibilitando a posterior
recuperação de dados geocodificados sobre as áreas de pesca constantes no banco de dados
(SIESPE) para futuras análises. As principais tecnologias utilizadas são o Mapserver/Mapserver
Guarani como servidor de mapas, banco de dados com extensão espacial Oracle Spatial e
linguagem de programação e integração através de PHP/Mapscript. A principal vantagem do
módulo, ora desenvolvido, foi a agilidade no processo de geocodificação, sem necessidade de
digitação. A operacionalização da ferramenta integrada ao SIESPE, preenche uma lacuna existente
no sistema e ao mesmo tempo incorpora um potencial recurso para análises sobre as pescarias, a ser
explorado pelo corpo científico.
Palavras-chave: Sistema de Informação Geográfica. Espacialização por quadrantes. Mapserver.
xiii
ABSTRACT
Development of a new module of system for geocodification of fishery data by quadrant
Fishery is an exploiting activity with needs constant monitoring to prevent the resources collapse.
Studies have been made by many research institutions to valuate the stocks situations and propose
the right exploitations politics of management. And to ashore the protection of species and the
environment, it’s necessary to have the knowlegment of the areas where the resources are caught.
This work presents the development of a new module of system for fishery data geocodification by
grid (latitude/longitude), to be introduced on the Industrial Fishery Statitics System of Santa
Catarina (SIESPE). This module uses geoprecessing technologies, geographic information systems
and webmapping to allow the insertion of georeferenced data by the selection of objects (poligons).
As well as other functionalities like utilization of recovering procedures of existing information’s
converting it from a textual format to a latitude/longitude format. The objective is to help the
researchers work of Fishery Studies Group (GEP) of Universidade do Vale do Itajaí (UNIVALI), to
making possible the recovery of geocodificated data of the fishery ground inserted in database
(SIESPE) for future analyses. The main tools used are: the Mapserver, as map server, database
with extension spatial Oracle Spatial and Mapscript PHP as programming language and
integration. The main advantage of this new module, was the agility in the geocodification process,
without necessity of typing. The operacionalization of this toll integrated to SIESPE fills a existing
gap into the system, and at some time incorporate a potential resource for fishery analysis to be
explored by scientific group.
Keywords: Geographic Information System. Spatial distribution by grid. Mapserver.
1. INTRODUÇÃO
O Brasil abriga a maior biodiversidade do planeta, mas possui um sistema insustentável de
exploração (VIANA, 2005). Um dos exemplos é a pesca marinha que tem grande importância tanto
econômica como social e cultural, a qual vem há anos se degradando devido à falta de políticas
públicas que visem a sustentabilidade. Para reverter essa situação de uso irracional dos recursos
pesqueiros, são necessários não apenas investimentos econômicos, mas também investimentos em
conhecimento e pesquisa para que possam ser tomadas as medidas de ordenamento adequadas ao
desenvolvimento sustentável (AGENDA 21, 1992).
Institutos e grupos de pesquisa do Brasil há algum tempo vêm concentrando seus estudos na
avaliação da abundância (quanto está disponível), distribuição (locais onde se encontram) e
potencial de exploração de recursos pesqueiros presentes na costa brasileira. Dentre essas
instituições destaca-se o Grupo de Estudos Pesqueiros - GEP do Centro de Ciências Tecnológicas
da Terra e do Mar (CTTMar) da Universidade do Vale do Itajaí (UNIVALI) que desde 2000
mantém convênios com o Governo Federal para operacionalização de vários projetos de pesquisa,
com destaque para a Estatística Pesqueira Industrial de Santa Catarina. O grupo é hoje responsável
por toda a coleta e processamento de informações de desembarques industriais de Santa Catarina. O
Trabalho é desenvolvido em parceria com a SEAP/PR - Secretaria Especial de Pesca e Aqüicultura
da Presidência da República, órgão do Governo Federal responsável pelas políticas de investimento
em infra-estrutura, pesquisa e outras ações de suporte a atividade pesqueira (SEAP/PR, 2004).
Para processar e armazenar as informações de desembarque de Santa Catarina, o GEP
desenvolveu a partir do ano 2000 o Sistema Integrado de Estatística Pesqueira - SIESPE. Esse
sistema foi modelado e projetado para receber, processar e armazenar dados relativos ao sistema de
pesca e desembarques industriais de Santa Catarina, tendo como fonte principal de informações os
documentos de mapa de bordo e de entrevista no cais. Hoje o SIESPE concentra informações de
desembarques dos últimos cinco anos e constitui a principal fonte de informações para vários
estudos desenvolvidos pelo GEP e por outras instituições do Brasil.
Embora o SIESPE tenha um dos bancos de dados de informações de pesca mais completo do
Brasil, o sistema não contempla consultas espaciais. Mesmo tendo em sua base de dados a descrição
das áreas onde ocorrem as capturas (áreas descritivas), a falta de coordenadas produz uma certa
limitação ao sistema. Assim, nos casos onde há a necessidade de localização mais precisa, os
pesquisadores necessitam lançar mão de vários outros recursos para transformar as descrições
textuais das áreas de pesca em áreas georreferenciadas, ou seja, precisam converter as informações
das áreas armazenadas para o formato de coordenadas antes de prosseguirem com as pesquisas.
Um dos motivos das informações do SIESPE não estarem espacializadas tem relação com os
próprios documentos que são sua fonte de informação, pois a maioria deles não tem especificada
uma localização objetiva e clara. Ou seja, na maioria das vezes, a localização é tão generalizada que
impossibilita o lançamento no sistema de forma adequada, utilizando coordenadas geográficas. A
qualidade dessas informações é influenciada principalmente pelo tipo de aparelho de pesca
utilizado. Certos aparelhos possibilitam informações quase pontuais, pois em sua operação não há
um deslocamento de área muito grande. Por outro lado, há aqueles que dificilmente ficam
estacionados em somente um local e geralmente englobam grandes áreas para completarem a
captura. Tais características fazem com que as informações de localização das operações dos
petrechos sejam diferenciadas, não havendo portanto, uma forma padronizada que possa representar
as operações de todas as frotas. Com base nisso, fica caracterizado que a melhor representação
dessa situação poderia ser em forma de faixas ou quadros, pois a utilização de pontos isolados sem
considerar uma área de vizinhança não atende as características de todos os petrechos e poderia
resultar em informações pouco acuradas.
O conhecimento das áreas de pesca sempre foi importante nos estudos realizados pelos
pesquisadores do GEP, que vêm utilizando as formas descritivas dessas áreas (não codificadas) para
executarem suas análises. No entanto, o interesse por informações detalhadas sobre capturas de
determinados recursos tem aumentado significativamente trazendo à tona a necessidade de
padronização dos dados armazenados, permitindo melhor recuperação dos mesmos. Esse interesse é
um reflexo da atual “globalização de mercado” que também afeta a maneira como os recursos são
explorados. A influência de mercados externos faz com que haja intensa atividade sobre alguns
recursos em certos locais, que podem colapsar, antes mesmo que se conheça a capacidade de
captura. Essa demanda em ter informações com rapidez esbarra em um banco de dados com mais de
31 mil registros onde as informações dos locais de captura estão armazenadas, mas não
geocodificadas. As descrições, não padronizadas, existentes necessitam ser interpretadas pelos
pesquisadores a cada novo estudo realizado. Este fato reforça a necessidade de soluções que possam
ser usadas mesmo com a atual situação dos dados armazenados e das fontes de informação para
agilizar principalmente o processo de interpretação.
2
Uma das formas para melhorar essa situação consiste em utilizar o potencial computacional,
através do uso de tecnologias, que conjugados ao sistema de banco de dados existente, possam
simplificar e automatizar o trabalho tanto de inserção como de recuperação de dados relativos às
áreas de pesca. Dentro dessa perspectiva, a utilização de uma ferramenta para geocodificação de
áreas, através de um padrão que seja compatível a todos os petrechos de pesca, propiciando a
alocação adequada dos recursos aos locais onde foram capturados tornou-se fundamental. A
intenção do módulo desenvolvido, foi acrescentar ao sistema existente (SIESPE) uma nova
funcionalidade específica para trabalhar com esses dados, referentes a localização geográfica das
operação de cada viagem dos barcos de pesca registrados, através de uma interface que facilite a
operação.
Este trabalho propôs utilizar-se das tecnologias existentes para trabalhar com dados
espaciais, como técnicas de geoprocessamento, integração de banco de dados com suporte espacial
e uso de ferramentas para visualização de mapas via web como o Mapserver, para desenvolver uma
solução que auxilie na tarefa de geocodificação dos dados de pesca. O sistema utiliza como base,
mapas digitais com as linhas batimétricas (de profundidade) e a área do oceano dividida em
quadrantes (polígonos) formando um grid. Esse grid possui resolução de meio grau (30’ x 30’)
permitindo que os usuários selecionem os quadrantes para determinar as áreas de pesca. Nessa
operação, as informações espaciais dos quadrantes selecionados para cada registro de desembarque
serão armazenadas em banco de dados com suporte espacial.
Este projeto tem importância fundamental pois buscou além de solucionar o problema de
geocodificação de dados de capturas de pesca, propor também um padrão (através do uso de
quadrantes) que possa ser usado em outras situações, com características parecidas, principalmente
onde não é possível utilizar coordenadas exatas. Seu desenvolvimento objetivou criar uma solução
que possa ser usada por qualquer área onde não é possível conseguir dados de localização exatos no
formato de latitude e longitude, mas sim aproximados em faixas ou zonas de atuação. Objetivou
também, tirar proveito de soluções de tecnologias existentes para agilizar a entrada de dados
espaciais, facilitar a crítica dos dados através de um ambiente visual, diminuindo a incidência de
erros e melhorando, assim, a confiabilidade dos dados armazenados.
3
1.1. OBJETIVOS
1.1.1.
Objetivo Geral
Desenvolver um módulo de sistema para geocodificação de dados de captura de pesca para o
SIESPE – Sistema de Estatística Pesqueira Industrial de Santa Catarina, utilizando recursos de
Webmapping.
1.1.2.
Objetivos Específicos
Este projeto tem os seguintes objetivos específicos:
•
Definir o problema foco deste trabalho em relação a pesca e à geocodificação;
•
Avaliar soluções similares a proposta;
•
Definir metodologia para geocodificação e divisão de quadrantes;
•
Aplicar ferramentas e metodologias para geocodificação baseado em ambiente SIG;
•
Determinar requisitos necessários ao sistema;
•
Realizar Análise e Projeto do módulo proposto;
•
Definir os mapas ou cartas náuticas para utilização no projeto;
•
Implementar algoritmo para georeferenciamento de dado de pesca;
•
Documentar as atividades e procedimentos realizados para o projeto.
4
1.2. METODOLOGIA
Para uma melhor execução do trabalho, o mesmo foi dividido em etapas. Embora essas
etapas não sejam baseadas em uma metodologia específica, elas seguem um modelo semelhante ao
espiral, de forma que cada fase pode ser revisada e avaliada. Com esse modelo as etapas puderam
ser refeitas quando houve necessidade. O trabalho foi dividido nas seguintes fases:
O levantamento bibliográfico foi feito através de artigos, trabalhos científicos, livros e
Internet. O objetivo foi reunir o material necessário para definir adequadamente o problema,
aumentar os conhecimentos sobre a pesca e sistemas de informações geográficos de forma a
delinear o trabalho e conseguir os conceitos necessários.
Foi necessária uma fase de seleção dos materiais considerados importantes para a elaboração
do trabalho, descartando aqueles considerados de menos importância. De posse dos materiais
considerados relevantes, iniciou-se então o processo de estudo e redação dos capítulos que fizeram
parte do documento de TCC.
Primeiramente foram estudados materiais sobre a atividade pesqueira, verificando-se a
situação atual da pesca no Brasil e fazendo um levantamento de eventuais problemas relacionados
a atividade. O objetivo foi situar o problema de espacialização no contexto geral da pesca.
Em seguida foi efetuado um estudo sobre GIS e Banco de dados espaciais com o objetivo de
reunir conceitos e técnicas necessárias para a posterior modelagem do sistema, bem como a
definição das ferramentas e tecnologias necessárias ao desenvolvimento.
Foi necessária também uma etapa de estudo (análise) do sistema SIESPE a fim de conhecer
o banco de dados e verificar os locais de possíveis associações entre o banco de dados atual e as
novas funcionalidades. Nessa etapa, também foi possível propor funcionalidades para recuperação
das descrições de áreas, existentes no SIESPE, a fim de facilitar o processo de espacialização
utilizado quadrantes.
Antes da modelagem foi realizado um estudo das principais tecnologias e ferramentas a
serem usadas nas etapas posteriores do projeto, com o objetivo de aumentar o conhecimento sobre
os métodos e funcionalidades oferecidos pelas mesmas, de modo a auxiliar no entendimento e na
definição das possíveis formas de funcionamento do sistema proposto.
5
A modelagem constituiu também uma etapa onde foi utilizada a UML para a modelagem
do módulo proposto, apresentando como resultado, os principais diagramas gerados pela ferramenta
de modelagem. Essa etapa objetivou representar da melhor forma possível o sistema proposto
facilitando a posterior implementação do mesmo.
A implementação foi a última etapa realizada, onde foram utilizados todos os documentos
gerados pelas etapas anteriores para integrar as tecnologias e dar forma ao módulo de
geocodificação. Durante essa etapa os métodos previstos na modelagem foram efetivamente
executados, testados e validados.
6
1.3. ESTRUTURA DO TRABALHO
O presente trabalho está dividido em cinco capítulos que são:
1. Introdução, composta pela descrição do problema, os objetivos, a metodologia e a
estrutura do trabalho;
2. Fundamentação teórica, composta por vários sub-capítulos sobre a situação da pesca,
Sistemas de Informações Geográficas, conceitos de cartografia e tecnologias adotadas no
projeto;
3. Projeto, composto pelas etapas de análise e requisitos e a modelagem com a
apresentação das principais funcionalidades lógicas e físicas do sistema.
4. Implementação, composto pela parte de prototipação da ferramenta, ou seja, a fase de
preparação do ambiente e geração do sistema, bem como a apresentação de telas e
resultados de testes.
5. Considerações finais ou Conclusões, composto pela descrição de possíveis falhas de
modelagem, indicação para trabalhos futuros e as principais considerações sobre todo o
processo de desenvolvimento.
7
2. FUNDAMENTAÇÃO TEÓRICA
2.1.
PESCA
2.1.1. Pesca e Sustentabilidade
A pesca é uma atividade essencialmente extrativista, isto é, se caracteriza por utilizar
recursos disponíveis na natureza, os quais também são repostos de forma natural e gradual ao longo
do tempo. O que geralmente não é considerado é que os recursos naturais são finitos e a falta de
alguns deles causa desequilíbrios a ponto de afetarem as populações que se utilizam desses
recursos, em seu desenvolvimento econômico, social e natural (PALMA, 2002).
A sustentabilidade da pesca depende de um ambiente natural com todos os seus fatores que
contribuem de maneira a manter um equilíbrio biológico. O atual modelo de desenvolvimento
pesqueiro, que se configura como ambientalmente predatório é um dos principais fatores que
interferem no equilíbrio natural dos recursos, pois as capturas geralmente não obedecem à
capacidade de recuperação dos mesmos (GAMA, 2000).
Para alcançar a sustentabilidade ou desenvolvimento em longo prazo, é necessário que a
atividade do homem sobre os pescados seja controlada e regulamentada. Essa regulação de uso
constitui em um dos grandes desafios que envolvem mais que interesses econômicos, como também
sociais, culturais e políticos. Nesta tarefa, as instituições de pesquisa, governamentais ou não, têm a
importante missão de fornecer condições para que as medidas necessárias ao gerenciamento
adequado dos recursos sejam tomadas (MONTEIRO, 2005).
Antes de controlar, é preciso ter conhecimento para edificar planos de ação global que
atribuam prioridades às necessidades das gerações atuais, sem que sejam comprometidas as
necessidades das gerações futuras. Ou seja, adotando bases de desenvolvimento sustentável, que
compatibilizam justiça social, crescimento econômico e proteção ambiental, priorizando melhorar a
situação ameaçadora em que se encontram várias espécies marinhas de grande importância para o
equilíbrio dos ecossistemas, garantindo assim, condições para a sobrevivência da atividade
pesqueira (GAMA, 2000).
Nesse contexto, para que as decisões envolvendo a atividade pesqueira sejam tomadas
corretamente, é necessário ter informações sobre a atividade de pesca, ambiente marinho e
8
principalmente sobre os recursos que o compõe. Não são simples informações, mas sim
informações que envolvam a inter-relação de: o que se pesca? Quanto se pesca? Como se pesca?
Quando se pesca? E também onde se pesca? A resposta a essas perguntas para cada espécie não é
tarefa fácil e depende de toda uma estrutura de coleta e armazenamento de informação.
2.1.2. Gerenciamento da Pesca no Brasil
No Brasil, a pesca representa uma das mais antigas atividades econômicas, que vem desde o
tempo em que constituía colônia de Portugal (FAVERET FILHO, 1997). Verificando a evolução da
atividade pesqueira no Brasil, considerando a quantidade produzida, a distribuição geográfica e o
valor da produção pesqueira, é constatado que após um grande crescimento na produção a mesma
ha anos se encontra em nível acima do máximo rendimento sustentável. De forma que é evidente a
situação de sobre-pesca de grande parte das espécies de valor comercial capturadas em nosso litoral
(ABDALLAH, 1999).
A atividade pesqueira teve um grande crescimento a partir da década de 1960, intercalando
períodos de altas e de baixas produções, os quais sempre tiveram relação a programas de incentivos
e estímulos do governo para aumentar a produção e o crescimento industrial da pesca. Esses
incentivos aumentaram o poder de captura das unidades pesqueiras e a produção se manteve à custa
da exaustão dos estoques. Há alguns anos a produção encontra-se em decréscimo, pois o nível de
pesca está acima da capacidade de recuperação natural da maioria dos recursos. Espécies de grande
importância econômica como sardinha, lagosta, pargo, camarão e mais recentemente o peixesapo, estão seriamente ameaçadas sem condições de exploração em grande escala (ABDALLAH,
1999).
Outra característica envolvendo a pesca brasileira é que as águas da costa são pobres em
nutrientes, caracterizando uma limitada potencialidade dos recursos pesqueiros. As poucas correntes
frias do Atlântico possibilitam a existência de grande variedade de espécies mas poucas com
capacidade de formar estoques passíveis de serem explorados economicamente. Mas esse ainda não
é o principal problema relacionado a pesca extrativista brasileira, pois se comparado os dados da
produção potencial sustentável com os da produção efetiva de pesca nota-se espaço para expansão
desde que gerenciado adequadamente (ABDALLAH, 1999).
9
2.1.2.1.
Operações da Pesca Industrial
As principais frotas de pesca industrial que atuam no litoral brasileiro são as de arrasto,
cerco, emalhe, espinhel, vara e isca-viva e armadilha, de forma que as operações de pesca se
concentram em sua maioria em águas rasas, próximo a costa, uma vez que a maior parcela da frota
brasileira não tem capacidade tecnológica para explorar grandes profundidades. Uma prática
adotada com a intenção de atingir águas mais profundas é o arrendamento de embarcações
estrangeiras que possuem tecnologia e capacidade para explorar áreas mais distantes da costa
(UNIVALI/CTTMar, 2003).
Embora cada frota de pesca tenha um fim mais específico no que tange a espécies alvos de
captura, o que acontece na realidade é a sobreposição de alguns petrechos de pesca em mesmas
áreas, ou então a mudança de atuação constante das frotas em busca de espécies mais disponíveis e
que tenham um maior valor comercial (PEREZ, 2001). Historicamente, não existe um controle
eficiente sobre a atuação das frotas pesqueiras, muito menos sobre as áreas onde eles atuam. Isto
implica a captura acentuada de certas espécies em pontos determinados da costa, contribuindo para
depleções localizadas e incontroláveis dos recursos (CERGOLE, 2003).
2.1.2.2.
O Desenvolvimento Pesqueiro e Problemas Gerenciais
O problema principal relacionado ao desenvolvimento pesqueiro é sem dúvida o uso
irracional dos recursos, tanto em diversificação e racionalização da atividade como em
investimentos em pesquisa, fiscalização e controle de extração. Nos últimos anos mais de 70% dos
valores captados pela atividade pesqueira foram investidos na indústria de captura e muito pouco
em pesquisa, levantamento de dados e análise espacial dos estoques (ABDALLAH, 1999).
Esse problema, aliado a outros, gera a redução dos estoques que, por sua vez, encarece as
operações de captura forçando as embarcações a atuarem em áreas cada vez maiores para conseguir
quantidades viáveis economicamente (FAVERET FILHO, 1997). A falta de um gerenciamento
espacial traz dificuldades ainda maiores como a impossibilidade de saber a localização dos estoques
passíveis de serem explorados, e também o controle da ação predadora das embarcações sobre
estoques vulneráveis e áreas que não deveriam ser exploradas (como as de proteção ambiental).
A frota pesqueira brasileira expandiu-se muito rapidamente nos últimos anos e hoje está com
um número excessivo de embarcações atuando sobre um estoque limitado de espécies. Segundo
Perez (2001), a ação desordenada das embarcações, tem relação principalmente à grande
10
diversidade das espécies e às dimensões geográficas da costa brasileira que não permitem fazer um
acompanhamento dirigido da atuação das frotas pesqueiras. Este contexto só deverá mudar com a
implantação de um novo modelo de ordenamento de pesca que está em estudo pelas entidades de
pesquisa, dentre as quais o GEP.
Outro problema reside em considerar os recursos pesqueiros como de uso comum, ou seja,
sem direitos de propriedade sobre eles. Essa condição compromete o uso eficiente dos mesmos que
são considerados de livre acesso. Cada qual captura os recursos de maneira que mais lhe convém do
ponto de vista econômico em detrimento a capacidade real sustentável. A concentração da atividade
leva a “tragédia dos comuns”, usando os recursos até o esgotamento. Nesse ponto podemos supor
que se a atividade sobre um recurso em uma determinada área pertence a alguém, é ele que terá
responsabilidade nas ações sobre esse recurso (MONTEIRO, 2005).
Um problema recente reside no fato de o Brasil ter pouca atividade no limite das 200 milhas
do mar territorial. De acordo com a Convenção das Nações Unidas sobre o Direito do Mar, que
criou a Zona Econômica Exclusiva, o país que não comprovar a sua capacidade de exploração pode
perder o direito sobre seus estoques passando os mesmos para outro que tenha condição de explorálo. Uma forma encontrada pelos órgãos de governo para suprir essa deficiência foi a adoção do
arrendamento de embarcações estrangeiras, procedimento que requer uma estrutura de controle e
gerenciamento adequados para não causar conflitos, que possam agravar ainda mais a situação atual
das pescarias (CERGOLE, 2003; FAVERET FILHO 1997). Uma das soluções adotadas é a
utilização do sistema de rastreamento via satélite como o RASTRO desenvolvido pelo LCA (LCA,
2005) em conjunto com o GEP no ano 2000 (GEP,2005).
2.1.3. Políticas de Ordenamento Pesqueiro
A falta de investimento em pesquisa, regulamentação e controle por parte dos órgãos
governamentais e do próprio setor pesqueiro constituem um dos principais entraves para o
gerenciamento adequado da atividade pesqueira que necessita urgentemente de um novo modelo de
ordenamento (PEREZ, 2001).
Para que atividade de pesca seja executada de forma responsável e sustentável são
necessárias medidas de ordenamento para estabelecer critérios e procedimentos adequados para as
operações, considerando principalmente os tipos de recursos, as frotas e áreas de atuação (PEREZ,
2001).
11
Quem estabelece os critérios e normas são os órgãos gestores, baseando-se nos estudos
realizados por pesquisadores que apontam tendências e fornecem diagnósticos da situação em que a
atividade se encontra. Sem dúvida, esses pesquisadores precisam de mecanismos que os auxiliem
nos estudos a fim de apontar recomendações que reflitam a realidade. Um desses mecanismos é o
gerenciamento espacial das capturas.
Segundo Monteiro (2005) algumas normas que podem ser adotadas pelos órgãos
governamentais na intenção de ordenar e prevenir a sobre-pesca dos recursos são:
•
limitar a pesca a determinados períodos do ano (defeso);
•
estabelecer licenças de pesca com quantidades limitadas;
•
restringir os tipos de petrechos usados na pesca do recurso;
•
impor taxas sobre as capturas;
•
estabelecer quotas individuais entre os pescadores;
•
delimitar áreas de atuação das embarcações;
•
mais recentemente a obrigação do rastreamento das operações de pesca e a utilização
de observadores de bordo nas embarcações.
Ainda segundo o autor, as normas para gestão dos recursos pesqueiros, as regulamentações e
também as penalidades impostas devem levar em consideração as localizações espaciais. Ou seja,
considerar o tamanho das áreas, o nível de atividade sobre elas e o próprio ecossistema local, pois
cada área tem uma característica diferente que deve ser considerada a fim de conciliar a atividade de
pesca com a preservação do ambiente marinho.
Atualmente, algumas das normas citadas acima são adotadas pelos órgãos governamentais
como tentativa de conter a depleção de algumas espécies como é o caso do defeso da sardinha, onde
durante o período de desova, a pesca é proibida. Mas geralmente as determinações são
descumpridas pela falta de fiscalização eficiente, punições exemplares e gerenciamento adequado,
tendo um efeito muito abaixo do esperado.
12
2.1.4. Gerenciamento Espacial da Atividade Pesqueira
Como mencionado anteriormente, a pesca marinha é considerada a maior atividade
econômica extensiva mundial e como qualquer grande atividade, tem enfrentado muitos problemas
ao longo do tempo. Esses problemas vêm se multiplicando em número e também em extensão de
forma muitas vezes incontrolável. Esses problemas estão saindo de uma esfera localizada de alguns
anos atrás atingindo a esfera global nos tempos atuais (FAO, 2005).
De acordo com FAO (2005) os maiores problemas relacionados a atividade pesqueira
mundial geralmente estão associados a: poluição do mar, degradação da zona litorânea, explotação
de recursos, conflitos pela distribuição dos recursos e destruição do habitat natural. Todos esses
problemas têm relação direta com a área geográfica onde eles acontecem, de maneira que
dependendo do local, o grau de impacto poderá ser maior ou menor. Além disso, poderá existir um
grau de precedência entre eles, onde um problema poderá levar a outros mas sempre tendo como
base a dimensão espacial onde eles acontecem.
Ainda segundo os autores, a origem e o posterior agravamento de todos os problemas
relacionados a atividade estão relacionados a falta de dimensionamento e delimitação das áreas
onde eles acontecem. A maioria dos problemas somente poderá ser equacionada quando
delimitamos uma área para então calcular os efeitos sobre ela, pois em áreas muito amplas não é
possível ter a noção adequada da extensão dos problemas a não ser que eles atinjam um nível
substancial. A sobre-pesca de um recurso, por exemplo, só poderá ser vista delimitando áreas de
estudos dirigidos a cada recurso, verificando a existência de pressões no nível de captura sobre o
mesmo.
Segundo a FAO (2005), a maior ameaça à vida marinha é a pesca comercial em grande
escala. Os equipamentos pesados de pesca, principalmente os que arrastam o fundo do mar
destroem habitats importantes ameaçando gravemente a permanência dos recursos nesses locais.
Daí vem a grande importância da consideração espacial para o gerenciamento da atividade. Devido
a esses fatores várias entidades estão se manifestando e movendo algumas ações que assegurem, ao
mesmo tempo, a exploração comercial com a preservação dos recursos. Um exemplo é o Conselho
Internacional para Conservação dos Mares que afirma que a administração espacial eficiente resolve
grande parte dos problemas relacionados ao gerenciamento das pescarias marinhas.
13
2.1.4.1.
Os Sistemas de Gerenciamento Atuais
FAO (2005) explica que os sistemas de gerenciamento existentes hoje não são totalmente
ideais, pois há um esforço muito grande de pesca exercendo muita pressão sobre os recursos
havendo um desequilíbrio entre o lucro, a produção e a capacidade real dos recursos. Isso se agrava
ainda mais pelo aumento da utilização desses recursos que, como já mencionado, são considerados
de livre acesso.
Uma prática que já vem sendo utilizada para amenizar os problemas de gerenciamento é a
divisão em áreas econômicas, onde cada país é responsável pela administração da sua área de
extração mas deve seguir normas internacionais do ponto de vista econômico. Essa prática ainda
não está resolvendo o problema por não haver um monitoramento adequado ou regras que garantam
a sustentabilidade nessas áreas. Uma solução seria envolver toda a costa marinha: os ecossistemas
juntamente com as comunidades pesqueiras que utilizam os recursos de maneira a incentivar a
produção de recursos alternativos, além de supervisionar e regulamentar as atividades locais (FAO,
2005).
Baseado nisso e levando em consideração que a maioria dos problemas relacionados a pesca
geralmente tem a ver com o espaço onde as espécies são encontradas (vivem), é evidente que a
melhoria no gerenciamento espacial pode atenuar toda essa situação. De acordo com FAO (2005), o
estudo e o mapeamento das pescarias e dos recursos através de Sistemas de Informações deveriam
ser a primeira atividade da administração pesqueira, mesmo que as informações não sejam
completas. A medida que vão chegando informações mais detalhadas, o sistema aumentará ainda
mais sua eficiência.
2.1.4.2.
Importância dos Sistemas de Informações Geográficos (SIG) no Gerenciamento de
Pesca
Segundo FAO (2005), todo e qualquer sistema de informação precisa de dados, sendo que
no caso típico da pesca, além da qualidade, é preciso ter quantidade para que se possa ter
representatividade. Além disso, os dados devem vir de um número variado de fontes para que se
possa tirar um melhor proveito dos mesmos, já que a dificuldade em ter informações completas é
grande.
Os sistemas com suporte espacial possibilitam uma visualização próxima da realidade,
fazendo com que a identificação e o tratamento dos problemas tenham mais chance de sucesso,
14
pois utilizam o potencial do ser humano de gerenciar muito mais informações interpretando
imagens. Os mapas e todo o aparato gráfico utilizado nos sistemas geralmente representam com
muita fidelidade a realidade. Existe uma máxima que diz: ”Uma imagem vale mais que mil
palavras”, e esta é uma diferença fundamental entre os sistemas atuais que utilizam SIG dos mais
antigos que não possuíam essa capacidade (FAO, 2005).
Recentemente, houve um grande desenvolvimento de soluções e sistemas de TI que
trabalham com dados geográficos. Esse desenvolvimento proporcionou o crescimento das
aplicações de SIG, fazendo com que hoje eles sejam empregados em um grande número de campos
diferentes e servindo para diversos propósitos, onde a quantidade de dados é grande e há a
necessidade de geração de informações mais acuradas envolvendo dados geográficos configurando
uma boa solução (FAO, 2005).
No entanto, até pouco tempo a utilização dos SIG para o gerenciamento de recursos
marinhos ficou muito limitada a pequenas áreas e em zonas litorâneas, onde os principais sistemas
têm o objetivo de controle de poluição, administração de cultivos de moluscos (maricultura) e
projeções da costa. FAO (2005) explica que existem algumas razões para que as aplicações de SIG
ainda não estejam sendo utilizadas na pesca, dentre as quais:
•
Dificuldades na projeção da distribuição de muitas espécies dentro de um ambiente;
•
A dinâmica de transformação e variabilidade do ambiente marinho é muito alta;
•
Alto custo na obtenção de dados;
•
Áreas espaciais que precisam ser cobertas de dimensões elevadas;
•
Falta de reconhecimento da importância espacial na administração de pesca;
•
Problemas de cooperação na aquisição de dados;
•
Dificuldades na definição de limites na distribuição dos recursos;
•
Necessidade de sistemas confiáveis e de grande capacidade de armazenamento;
•
Falta de qualidade dos dados em muitos locais;
•
Falta de integração entre as decisões dos principais responsáveis pela administração
de pesca.
15
Devido a esses fatores, a utilização efetiva dos SIG deverá acontecer em um processo
progressivo. O fundamental é ter consciência da urgência em mudar o atual sistema de
administração de pesca que se encontra em profunda crise. Para que isso aconteça é preciso usar
todas as ferramentas de informação disponíveis, sendo que, indiscutivelmente, os SIG terão papel
fundamental (FAO, 2005).
2.1.5. Informações de Pesca em Santa Catarina
A coleta, processamento e armazenamento de informações sobre a produção são atividades
de fundamental importância para a administração da atividade pesqueira (MENEZES, 2005). Em
Santa Catarina, essas atividades para a pesca industrial estão sendo realizadas pelo Grupo de
Estudos Pesqueiros – GEP do Centro de Ciências Tecnológicas da Terra e do Mar – CTTMar da
Universidade do Vale do Itajaí – UNIVALI, que desde 2000, mantém uma estrutura de pessoal e
equipamentos específicos para esse fim. Esse trabalho tem sido viabilizado por uma série de
convênios de cooperação técno-científicas celebrados anualmente entre a UNIVALI e o Ministério
da Agricultura Pecuária e Abastecimento (2000-2002) e, a Secretaria especial de Aquicultura e
Pesca da Presidência da República (2003-2005).
Com o início das atividades no ano 2000, foi estruturado um novo Sistema de Estatística
Pesqueira para o estado abrangendo a pesca industrial. O objetivo do sistema foi captar, armazenar,
processar e disseminar de forma eficiente informações de diversas fontes como: fichas de produção,
mapas de bordo, entrevistas de desembarques no cais, amostragens biológicas e informações
coletadas por observadores de bordo. Assim surgiu o SIESPE, que foi uma forma de concretizar
esses objetivos através de um sistema computacional de grande capacidade (UNIVALI/CTTMar,
2003a).
2.1.5.1.
O SIESPE
O SIESPE é o Sistema Integrado de Estatística Pesqueira de Santa Catarina que possui
capacidade de processamento e armazenamento de dados pesqueiros. Foi estruturado através do
convênio entre o GEP e o DPA/MA e atualmente é mantido pelo convênio entre o GEP e a
Secretaria Especial de Aqüicultura e Pesca da Presidência da República SEAP/PR.
O SIESPE possui uma base de dados que armazena informações de diferentes categorias de
forma integrada, como:
16
•
Fichas de Produção: São formulários preenchidos pelas empresas ou armadores
com os registros finais da captura de uma viagem de pesca coletados nas empresas
por uma equipe de campo;
•
Entrevistas no Cais: Realizadas pelo GEP desde 1995, abrange principalmente os
municípios de Itajaí, Navegantes e Porto Belo e consiste na visita da equipe de
campo aos pontos de desembarques realizando entrevistas no momento do
desembarque colhendo as mais diversas informações da viagem de pesca e as
estimativas de captura por espécie.
•
Mapas de Bordo: É um documento oficial utilizado na viagem onde são obtidas
informações que permitem realizar o acompanhamento dos padrões espaciais e
temporais das embarcações, obter dados sobre o esforço de pesca e capturas para
cada local e identificar mudanças de modalidade de pesca pelas embarcações.
•
Informações de observadores de bordo: São informações de captura e
desembarque das embarcações principalmente arrendadas, através do uso de
formulários dos observadores de bordo, que são mais detalhados que os documentos
tradicionais (UNIVALI/CTTMar, 2003a).
Toda a informação da pesca industrial coletada através dessas diferentes categorias é
analisada, verificando a confiabilidade, processada e armazenada no banco de dados do SIESPE.
Muitas vezes, mais de um tipo de documento, para um mesmo desembarque é enviado por fontes
diferentes, como por exemplo: ficha de produção, pela empresa de pesca e mapa de bordo, pelo
mestre de embarcação. Esses documentos são processados e armazenados no sistema, sendo que as
duplicidades são consideradas formas complementares de informações. Todo o processo, tanto de
coleta como de processamento, é realizado por profissionais especializados nas variadas
modalidades de pesca da região, assegurando assim, a eficiência e a segurança na interpretação e na
análise dos dados obtidos (UNIVALI/CTTMar, 2003a).
2.1.5.2.
Espacialização dos Dados no SIESPE
O SIESPE atualmente concentra informações de desembarque da frota industrial realizados
em Santa Catarina nos últimos seis anos. O sistema possui mais de 31 mil desembarques
cadastrados e constitui a principal fonte de informações para vários estudos desenvolvidos pelo
GEP e por outras instituições (inclusive através de consultas on line pela internet) (GEP, 2005).
17
Entretanto, na época da criação do sistema a principal prioridade foi estruturar a sistematização dos
dados referentes à produção desembarcada por espécie de pescado, visando atender à necessidade
primordial de publicação das estatísticas oficiais de produção do Estado. Assim, para simplificar a
entrada dos dados, as informações sobre áreas de pesca foram inseridas no sistema sem uma
padronização definida, uma vez que não foi possível desenvolver, naquele momento, um módulo
específico para realizar a espacialização dos dados de pesca. Por esse motivo, o sistema não possui
suporte a informações georreferenciadas, ou seja, as capturas armazenadas não têm uma localização
em forma de latitude e longitude. O sistema possui somente uma localização suposta e não
padronizada através da descrição das áreas de pesca por onde a embarcação atuou durante a
operação de pesca. Isto dificulta muito o trabalho de análise, pois impossibilita a localização
automática das capturas de forma a proporcionar uma crítica mais acurada relacionando os dados da
captura da viagem com as áreas onde essas capturas aconteceram.
Uma das grandes dificuldades para a codificação dos dados de captura tem a ver com a
forma com que os documentos, fontes de informações, são preenchidos. Esses documentos não
trazem um nível de detalhamento que facilitem a distribuição em áreas codificadas. Os dados das
áreas de pesca vêm discriminados através da descrição dos locais, os quais variam de acordo com o
tipo de documento e os petrechos de pesca, dificultando o lançamento. Além disso, eles necessitam
de uma crítica para definir o posicionamento geográfico corretamente antes do lançamento no
sistema. Essa característica força o usuário a consultar mapas levando em consideração critérios
como o petrecho, a profundidade e a própria descrição para definir adequadamente os locais das
capturas.
O lançamento no sistema de áreas, no “formato textual” (descritivo), sem muita
especificação também impede que sejam realizadas análises diretamente sem antes realizar uma
“geocodificação manual”. Esse trabalho precisa ser realizado toda vez que uma nova pesquisa
necessite dos dados de área de pesca. Levando em consideração a quantidade de informações
existentes, esse processo torna-se quase impraticável quando uma análise mais detalhada sobre
dados de vários anos é requerida. De outro modo, a definição de um padrão que atenda às
necessidades de todos os petrechos que possa ser usada para geocodificar tanto os novos quanto os
dados que já estão armazenados facilitaria e agilizaria todo o processo de análise de distribuição de
capturas. Na figura 1, é apresentada uma das telas utilizadas para o lançamento das áreas no
SIESPE, destacando a descrição das áreas de pesca como representação dos pontos de capturas.
18
Figura 1. Uma das telas do SIESPE para entrada de áreas
Fonte: SIESPE - Sistema Integrado de Estatística Pesqueira Industrial
19
2.2. INFORMAÇÕES GEOGRÁFICAS OU GEOINFORMAÇÕES
Informações geográficas são informações relacionadas a um conjunto de dados ou valores
que podem ser representados tanto em forma gráfica como também numérica ou alfanumérica e
possuem como característica fundamental associações ou relações de caráter espacial, ou seja, são
dados geográficos tratados, compostos pela representação de uma entidade (figura geométrica) e
seus dados.
Essas informações possuem natureza dual, ou seja, contêm dados de localização geográfica
e dados descritivos. Os dados de localização são expressos em coordenadas enquanto que os dados
descritivos são atributos que podem representar estados ou relações dos objetos. Dessa forma
podemos afirmar que as informações geográficas estão condicionadas a existência dos objetos que
possuem a sua localização espacial e também suas relações com outros objetos, como: vizinhança,
distância e direção (EPAMIG, 1998a).
De acordo com Câmara & Medeiros (2001), as informações espaciais também estão ligadas
ao conceito de espaço geográfico, o qual pode ser definido como uma coleção de localizações da
superfície da Terra onde fenômenos envolvendo os objetos acontecem. Esse espaço geográfico é um
espaço localizável definido em função das coordenadas, altitude e sua posição relativa.
As aplicações que trabalham com os dados espaciais para produzir informações geográficas
são denominadas de SIG - Sistemas de Informações Geográficas. Os SIG se diferenciam de outros
sistemas por: a) utilizar um sistema de referência e de condenadas; b) integrar dados espaciais de
diversas fontes, formatos, escalas, sistemas de projeção...) terem capacidade de integrar os dados
espaciais para desenvolver análises espaciais. (ARAÙJO et al, 2004).
2.2.1. Dados Espaciais ou Geográficos
O processamento de dados necessita que os dados do mundo real sejam mapeados e
representados de forma abstrata através de entidades ou objetos a fim de possibilitarem operações
sobre eles. Esses objetos compõem os dados espaciais ou geográficos que se distinguem uns dos
outros através do componente espacial que é capaz de associar cada entidade ou fenômeno a uma
localização georeferenciada em um determinado período de tempo (ESTRADA, 2005).
20
Com a evolução dos sistemas computacionais os dados espaciais ganharam inúmeras
maneiras de serem representados, de modo que hoje a maioria dos dados é armazenada em formato
digital, facilitando o acesso, a análise e a divulgação dos mesmos. Os dados espaciais armazenados
são divididos em vários tipos, de acordo com suas características, para melhor representá-los
computacionalmente, a saber: dados temáticos, dados cadastrais, dados de redes, dados de modelos
numéricos e dados de imagens. Essa divisão em tipos serve também para facilitar e padronizar a
utilização dos dados (SILVA, 2002).
Atualmente existe um padrão definido pelo consórcio OGC – Open Geospatial Consortium
para representação de dados espaciais chamado de padronização Information View Point. O padrão
define formas de representação e modelagem para os dados espaciais em formato digital que vão
desde definições de modelos conceituais até aos métodos utilizados para o tratamento das
informações nas aplicações. Essa padronização facilita a troca e compartilhamento dos dados, fato
cada vez mais comum entre empresas e entidades.
2.2.1.1.
Considerações Sobre a Modelagem de Dados Espaciais ou Geográficos
O processo de modelagem de dados geográficos busca traduzir ou abstrair as entidades do
mundo real para o ambiente computacional de um SIG, que pode ser representado pelo paradigma
dos quatro universos (CÂMARA et al, 2001), a saber:
•
Universo do mundo real, compreendido pelas entidades e fenômenos geográficos a
serem modelados pelo sistema;
•
Universo matemático ou conceitual, compreendido pelas definições utilizadas na
modelagem das entidades e fenômenos geográficos (classes de campos e objetos);
•
Universo de representação, compreendido pelas representações associadas às classes
formais definidas no universo conceitual (matricial e vetorial);
•
Universo de implementação, compreendido pelos procedimentos e estruturas de
dados utilizados na implementação computacional das classes definidas no universo
de representação (ex. árvore-R).
Os universos descritos buscam facilitar a definição e construção de um objeto geoespacial a
partir da descrição formal, favorecendo também a definição dos métodos responsáveis pelo
21
tratamento dos dados. De acordo com a padronização OGC, a melhor representação para as
geotecnologias envolvem principalmente feições geoespaciais e objeto geoespacial.
2.2.1.2.
Feições Geoespaciais
A feição espacial é a abstração de um fenômeno real da natureza e uma feição geoespacial
distingue-se pela sua associação a uma localização espacial no globo terrestre. Toda a representação
do mundo real através de meio digital é constituída por um conjunto de feições.
Segundo Estrada & Paiva (2005), as feições geoespaciais possuem dois níveis: features
instances e features types. Features instances são feições geoespaciais que representam um
fenômeno associado a coordenadas geoespaciais, e o agrupamento dessas feições por características
comuns é denominado de features types. Elas também podem ser locais ou globais, podendo ter um
certo conjunto de propriedades, que podem ser operações, atributos ou associações.
2.2.1.3.
Outros Conceitos Relacionados a Dados Espaciais
Alguns conceitos relativos aos dados espaciais são importantes para compreender como eles
são organizados tendo em vista a qualidade da modelagem e representação em um SIG:
•
Região Geográfica: “Define-se uma região geográfica R como uma superfície
qualquer pertencente ao espaço geográfico, que pode ser representada num plano
ou reticulado, dependente de uma projeção cartográfica” (EPAMIG, 1998a). É
através da região geográfica que localizamos as entidades.
•
Geo-campo: “Um geo-campo representa a distribuição espacial de uma variável, a
qual possui valores em todos os pontos pertencentes a uma região” (ASSAD, 1998).
Podem ser especializados em: temático (associado a um mapa), numérico (associado
a um valor), dado de sensor remoto (associado a valor de sensor) (EPAMIG, 1998a).
•
Geo-objetos: “Um geo-objeto é um elemento único que possui atributos nãoespaciais e está associado a múltiplas localizações geográficas. A localização
pretende ser exata e o objeto é distinguível de seu entorno.” (ASSAD, 1998). Os
geo-objetos podem aparecer particionados como também podem ter mais de uma
representação de escala ou representações de alterações temporais.
22
•
Mapa Cadastral: “Um mapa cadastral é um objeto complexo que agrupa geoobjetos a uma dada projeção cartográfica e região geográfica” (ASSAD, 1998). O
mapa cadastral mapeia os objetos que possuem as localizações geográficas.
•
Objeto Não-Espacial: “Um objeto não-espacial é um objeto que não possui
localizações espaciais associadas” (EPAMIG, 1998a). Representa qualquer
informação não referenciada associada ao banco de dados geo-referenciado.
•
Plano de Informação: “Um plano de informação é o suporte para a representação
geográfica de diferentes tipos de dados geográficos. Trata-se da generalização dos
conceitos de mapas de geo-objetos e de geo-campos” (EPAMIG, 1998a). Representa
uma região geográfica com seus dados (geo-campos e geo-objetos).
2.2.2. Geocodificação
A geocodificação de dados compreende a definição da posição dos elementos geográficos
referenciado a um sistema de coordenadas padrão. Esse processo transforma um endereço ou uma
descrição em coordenadas locais de forma que possam ser utilizados através do geoprocessamento
para gerarem informações espaciais. Usualmente são utilizados centróides para definir as
coordenadas referentes a uma determinada área (WEBSOLUTIONS, 2005).
Somente os dados geocodificados podem ser referenciados através do sistema
computacional, que constitui no relacionamento das suas coordenadas ao sistema de coordenadas
real.
A diferença básica entre a geocodificação e o georreferenciamento é que na primeira o
elemento torna-se localizável através da atribuição de uma posição referenciável, enquanto que na
segunda é estabelecida uma relação entre o sistema de coordenadas adotado e o sistema de
coordenadas do mundo real de forma que o elemento ou entidade geográfica possa ser localizado
dentro do sistema de coordenadas adotado. (ESTEIO, 2005)
Através da geocodificação, é possível tanto encontrar e identificar uma posição geográfica a
partir de um nome ou endereço (identificação de um objeto), como também é possível, de forma
inversa, identificar um endereço ou um nome atribuído a um objeto espacial, a partir de uma dada
posição geográfica possibilitado pela utilização de um sistema de coordenadas (SILVA, 2005).
23
2.2.2.1.
Sistema de Coordenadas
Por trás de qualquer operação envolvendo localização de pontos na superfície plana como de
um mapa podem existir várias transformações entre sistemas de localização, chamados de sistemas
de coordenadas. A finalidade é relacionar o sistema utilizado ao sistema de coordenadas geográficas
usado para localizar e determinar relações de vizinhança aos elementos na superfície terrestre
(EPAMIG, 1998c). Os sistemas de coordenadas relevantes para esse trabalho são o sistema de
coordenadas geográficas e o sistema de coordenadas planas.
2.2.2.1.1.
Sistemas de Coordenadas Geográficas
No sistema de coordenadas geográficas, cada ponto da superfície terrestre é dado pela
interseção entre duas linhas imaginárias. Essas linhas imaginárias são chamadas de meridianos, para
o sentido norte e sul e paralelos, para o sentido leste oeste (EPAMIG, 1998c).
Segundo EPAMIG (1998c), meridianos são elipses que se interceptam no seu eixo de
rotação que coincide com os pólos e possuem sua máxima separação sobre a linha do equador. O
meridiano de origem (fundamental) é o que passa pelo observatório de Greenwich, na Inglaterra,
definido como origem 0º das longitudes terrestres. Meridianos a leste de Greenwich, variam de 0º a
180º positivos enquanto que os a oeste variam de 0º a 180º negativos.
EPAMIG (1998c) define como paralelos as linhas circulares cujo plano é perpendicular ao
eixo dos pólos, o círculo central ou mais eqüidistante dos pólos é chamado de Equador e divide a
terra em dois hemisférios, sendo considerado o paralelo de origem 0º das latitudes terrestres. A
partir do equador os círculos traçados diminuem de tamanho em direção aos pólos, onde variam de
0º a 90º positivos ao norte e de 0º a 90º negativos ao sul (PAES, 1999).
O meio para determinar distâncias no sistema de coordenadas geográficas é definido como
Latitudes e Longitudes. Onde a “Longitude de um lugar qualquer da superfície terrestre é a
distância angular entre o lugar e o meridiano inicial ou de origem, contada sobre um plano
paralelo ao equador” (EPAMIG, 1998c) Já “latitide é a distância angular entre o lugar e o plano
do Equador, contada sobre o plano do meridiano que passa no lugar” (EPAMIG, 1998c).
2.2.2.1.2.
Sistemas de Coordenadas Planas
Os mapas que representam os elementos do globo em formato digital (ou não) são planos e a
superfície da Terra é irregular e curva. Como os elementos do mapa devem ser localizáveis há a
24
necessidade de utilização de um sistema que possa representar medidas da superfície da Terra na
superfície plana. Esse sistema é chamado de sistema de coordenadas plano-retangulares (EPAMIG,
1998c).
O sistema de coordenadas plano-retangulares utiliza um ponto de partida, que é a
intersecção entre duas retas perpendiculares de onde é possível projetar qualquer ponto do globo
terrestre. No sistema, as coordenadas são representadas por dois números reais, um representando a
reta horizontal (x), associado a longitude, outro representando a reta vertical (y), associado a
latitude, e se referem ao ponto onde as mesmas se cruzam. O sistema de coordenadas planas mais
utilizado é o sistema baseado na projeção UTM (Universal Transverse Mercator), também
chamado de sistema de coordenadas UTM (ROCHA, 2000; EPAMIG, 1998c).
Para o desenvolvimento da ferramenta o Sistema de Coordenadas Plano será adotado, por
ser o sistema que possibilita ser utilizado no meio digital.
2.2.2.2.
Sistemas de Projeção UTM
Os sistemas de projeção são uma forma de transferir para o papel a superfície real curva da
Terra. Muitos métodos são utilizados de forma a permitir maior fidelidade da representação. Nessa
tarefa devem ser levadas em consideração: as formas, as áreas superficiais, e a distância entre
pontos (ROCHA, 2000).
As projeções podem ser classificadas baseadas em seu modelo geométrico como cilíndrica,
azimutal e cônica, sendo que cada uma tem um padrão de distorção na forma ou na distância entre
os objetos (EPAMIG, 1998c).
A projeção UTM é uma projeção que permite representar grandes áreas do globo terrestre
com poucas deformações utilizando apenas um grupo de fórmulas para lidar com as
inconformidades (EPAMIG, 1998c)
Na projeção UTM, o meridiano central do fuso, o equador e os meridianos situados a 90º do
meridiano central são representados por retas, os outros meridianos e paralelos são curvas
complexas. Nessa projeção a Terra é dividida em 60 fusos com amplitude de 6º de longitude, onde
o fuso é representado pelo meridiano central, assim o primeiro meridiano central possui longitude
igual a 177º (variação de 174º – 180º) e o último possui longitude de 3º (variação de 0º - 6º)
25
(EPAMIG, 1998c). O ponto de ajuste entre a representação projetada no plano e a real é
possibilitada pela utilização de datuns planimetricos.
Figura 2. Representação mostrando as folhas projetadas no processo UTM para o Brasil
Fonte: Adaptado de (EPAMIG, 1998c).
2.2.2.3.
Datum planimétrico
Considerando que a superfície real de referência da Terra seja um geóide e a figura adotada
para representar distâncias e outros cálculos na cartografia um elipsóide não é possível ter uma
equivalência entre as mesmas para a representação de todo o globo terrestre. Desta forma, são
utilizados critérios para a adequação regional à superfície real, projetando em partes e conservando
o paralelismo entre o eixo de rotação das figuras (ROCHA, 2000).
Para cada país ou região são escolhidos pontos centrais para anulação do ângulo vertical
formado entre a superfície do elipsóide e a superfície real, esse ponto é chamado de datum
planimétrico. Os datums tornam possível a adequação da região a superfície geoidal, possibilitando
as medições planimétricas de forma aproximada à real para a região na qual é referência,
representada nos mapas (EPAMIG, 1998c).
2.2.2.4.
Mapas/Cartas
Segundo EPAMIG (1998c) mapas são modelos simplificados da realidade que utilizam uma
representação de entidades abstratas relacionadas com a superfície da Terra normalmente em escala,
que estão entre a realidade e a base de dados de um SIG.
26
As cartas representam aspectos naturais ou artificiais da Terra, de forma a permitir precisão
na avaliação de distâncias, direções e localizações geográficas de pontos ou áreas (PAES, 2000).
Segundo a ABNT (Associação Brasileira de Normas Técnicas) adaptado de Paes (2000), as
cartas podem ser classificadas assim:
•
Geográficas: podem ser (a) topográficas, confeccionadas mediante levantamento
topográfico regular, através da compilação de cartas geográficas existentes; (b)
planimétricas, semelhante às topográficas com apenas uma diferença, não
representam indicação de altitude;
•
Cadastrais e plantas: possuem geralmente “escala grande”, utilizadas para mostrar
limites verdadeiros e usos de propriedades;
•
Aeronáuticas: representam a superfície com sua cultura e relevo a fim de satisfazer
às necessidades da navegação aérea;
•
Náuticas: as cartas náuticas resultam dos levantamentos dos oceanos, mares, rios
lagos e canais navegáveis, trazem a representação das profundidades e são destinadas
a segurança de navegação.
•
Outras: representadas por meteorológicas, que se referem ao clima; de solo, que
classificam tipos de solos; de vegetação, que mostram as características e
distribuição da cobertura vegetal; de uso da terra, representam a distribuição
geográfica e classificação de usos da superfície; globos, que têm representação da
superfície terrestre.
Todos os mapas utilizam uma forma de relação entre as dimensões dos seus elementos e as
medidas reais sobre a superfície da Terra. Essa relação é denominada escala. está presente nos
mapas através de forma numérica ou gráfica. Um exemplo para um mapa do Estado de Santa
Catarina onde a escala numérica indica 1:500.000, isso que quer dizer que um metro representado
no mapa é equivalente a 500.000 metros na superfície real. (EPAMIG, 1998c).
2.2.3. Representação Computacional de Dados Geográficos
Segundo Câmara & Medeiros (1998), existem vários tipos de dados que podem representar
o mundo real nos Sistemas de Informações Geográficas. As principais representações
27
computacionais desses dados através de mapas podem ser: mapas temáticos, mapas cadastrais,
redes, imagens (diversas fontes) e modelos numéricos do terreno.
Os mapas temáticos são mapas que descrevem a distribuição de uma grandeza geográfica de
forma qualitativa. Através de polígonos, eles medem sobre os atributos, valores nominais (lista de
valores) e ordinais (em escala) para representar classes (EPAMIG, 1998a). Em sua grande maioria
os mapas temáticos são armazenados no formato vetorial, usando a topologia arco-nó-polígono para
formar uma região,mas pode também ser armazenado em formato matricial (PAES, 2000).
As imagens podem ser originadas de diversas fontes como: imagens de satélites, fotografias
aéreas e imagens de scanners aerotransportados. As imagens são armazenadas em formato matricial
e seu menor elemento é o píxel o qual tem a característica de cor própria. Nas imagens os objetos
geográficos estão contidos nos elementos da imagem necessitando de processos de seleção ou de
classificação para melhor interpretá-los (EPAMIG, 1998a).
2.2.3.1.
Mapeamento Temático:
O mapeamento temático consiste em criar regiões definidas por um ou mais polígonos que
representam uma categoria relativa a um determinado tema. Esse mapeamento busca capturar no
GIS a melhor representação possível a natureza dos padrões e processos do espaço. Assim, no
ambiente computacional, são utilizadas as transposições de mapas que irão representar uma
característica conhecida relacionada a uma determinada região.
A diferença entre um mapa temático e qualquer outro mapa é que ele é essencialmente
analítico e explicativo, além da localização, o mapa temático tende a demonstrar padrões de
distribuição ou ocupação do espaço.
Os mapas temáticos podem ser sobrepostos em várias camadas possibilitando a análise de
mais de uma variável diferente ao mesmo tempo. Isso constitui uma forma poderosa de utilização
dos mapas temáticos que facilitam tanto a análise como a visualização dos dados. (FARIA, 2000).
2.2.3.2.
Mapeamento por Quadrantes
O mapeamento por quadrantes ou células como é chamado, consiste na divisão de uma
região em quadrados formando um grid. Cada polígono que compõe o grid faz parte de uma
categoria e por conseqüência pertence a um tema. Esse tipo de mapeamento é utilizado
28
principalmente para realização de consultas espaciais onde cada grupo de células representa uma
particularidade sobre uma ou mais variáveis. No caso específico dessa ferramenta, o mapeamento
por quadrante terá a função visual (na interface com a divisão do oceano ) e também servirá como
mapa base para o processo de geocodificação dos dados através da utilização de sua posição no
grid.
29
2.3. TECNOLOGIAS ADOTADAS PARA O PROJETO
2.3.1. WebMapping
O principal conceito que compõe WebMapping é a capacidade de um sistema em
proporcionar ao usuário navegar através da utilização de mapas para localizar as informações na
Internet. Ou seja, o uso de servidores de mapas através da Internet para divulgação de informações
de forma dinâmica com geração de consultas espaciais (SPERB et al. 2004).
Em WebMapping, diferentemente da navegação tradicional através de links, existe o
conceito de navegação por mapas utilizando marcadores espaciais como referência. O usuário, além
de navegar pelo mapa, pode também escolher quais informações deseja consultar, gerando as mais
diversas associações entre os dados para obter o resultado visual que deseja.
Webmapping representa muito mais que a simples visualização de mapas digitalizados pela
Internet, representa um serviço que proporciona aplicação de análises espaciais para diversos casos
de estudo, utilizando mapas dinâmicos, aliados a dados armazenados sobre os mais variados temas
com a utilização da interface web. Embora até há pouco tempo o serviço se resumisse na
disponibilização de mapas simplesmente para visualização de consultas pré-determinadas, hoje as
opções são mais poderosas de forma que a implantação de Webmapping em servidores de mapas já
se tornou uma necessidade para aplicações de SIG atuais que tendem a ter aplicações web com
capacidade para recuperar, administrar, filtrar e visualizar as informações espaciais (MATA &
TORRES, 2003).
Segundo Mata & Torres (2003) em Webmapping há duas formas de apresentar informações:
através da requisição de consultas ao banco de dados e posterior geração de mapas em formato de
imagem (raster), que é mostrado incrustado através de uma página html sem a necessidade de
plugin. Como também, através da obtenção de dados em formato vetorial, através das consultas,
para posterior manipulação no cliente, neste caso seria necessário a instalação de um plugin para a
geração dos mapas no cliente.
A forma padrão utilizada para possibilitar a navegação pelo usuário é permitir a navegação
espacial através de requisições, de forma que ele pode aproximar, afastar e analisar os dados
retornados. Estas são características importantes relacionadas com WebMapping, que permitem que
mapas sejam entregues sobre demanda ao usuário. Outra característica é a visualização onde o
30
usuário pode escolher quais os elementos que deseja visualizar e quais dados devem ser expressos
no mapa. Dessa maneira o usuário pode encontrar relações que seriam difíceis de serem observadas
através de simples dados textuais (MCCURLEY, 2005).
Inúmeros sistemas servem de base para Webmapping, a maioria deles suportam várias
formas para geração de mapas e possuem muitas funcionalidades permitindo que os objetos
espaciais possam ser manipulados diretamente pelo SIG. Esses sistemas, possuem duas formas para
o acesso aos objetos espaciais, que podem ser por manipulação em tempo de execução ou através de
dados já pré-formatados. A manipulação em tempo de execução, permite que as informações sejam
realmente processadas no momento da solicitação sob os critérios do usuário. Essa característica
torna as aplicações mais dinâmicas e permite análises mais específicas sobre os objetos. É desta
forma de acesso aos dados que a maioria dos SIGs para WebMapping é desenvolvida, pois esta
viabiliza que os objetos espaciais possam ser manipulados antes que o mapa seja entregue ao
usuário. Essas formas de entrega são determinadas, além do propósito do sistema, pela arquitetura
utilizada.
2.3.1.1.
Arquitetura WebMapping
De acordo com Mata & Torres (2003) a arquitetura mais comum é composta por um
administrador de servidor de mapas, uma base de dados geográfica, um mecanismo de análises
espaciais, um módulo de funções e procedimentos, um repositório de imagens e um servidor Web.
Os elementos interagem entre si, proporcionando o fluxo de informações para a geração das telas
resultantes com os dados espaciais.
O processo mais comum é descrito da seguinte forma: um cliente Web (navegador) solicita
através de uma imagem descarregada pelo servidor Web uma consulta espacial. O servidor Web
envia a solicitação ao servidor de mapas. O servidor de mapas por sua vez, envia os parâmetros ao
mecanismo de análises espaciais que invoca um procedimento que acessa a base de dados
geográfica, recupera a informação solicitada e monta um formato de saída. O processo é
supervisionado pelo gerenciador de análise espacial para informar ao servidor de mapas possíveis
erros. Caso esteja tudo correto é solicitada a montagem da página html com a saída gráfica pelo
servidor de mapas e enviado então ao servidor Web. Nesse momento poderá ser acessado também o
repositório de imagens, tanto para armazenar como para recuperar uma imagem existente.
Finalmente as informações são mostradas no cliente Web.
31
SERVIDOR WEB
GERADOR DE
INTERFACE
MECANISMO DE ANÁLISE
ESPACIAL
SERVIDOR DE
MAPAS
BANCO DE DADOS
GEOGRÁFICOS
Figura 3. Um exemplo de possível arquitetura Webmapping
2.3.2. Servidores de Mapas
Inúmeros sistemas servem de base para WebMapping e a maioria deles suportam várias
formas para geração de mapas e possuem muitas possibilidades permitindo que os objetos espaciais
possam ser manipulados diretamente pelo SIG. Os sistemas mais avançados utilizam servidores de
mapas proprietários, os quais são considerados de alto custo, o que pode o inviabilizar o seu uso na
maioria dos projetos.
De acordo com Sperb et al. (2004), a solução para sistemas a baixo custo reside no emprego
de softwares livre ou OpenSource, de forma que existem hoje várias organizações empenhadas em
desenvolver ferramentas de qualidade com a finalidade OpenSource, um desses é o Mapserver.
2.3.2.1.
MapServer
De acordo com Cabral et al. (2002) MapServer é uma tecnologia que permite a criação de
aplicações para geração de mapas via web. O software segue a licença OSS/FS, e é construído com
base em outros pacotes freeware como Shapelib, GD, OGR, e outros.
O software foi desenvolvido inicialmente por Stephen Lime em 1994 como parte do projeto
ForNet entre a NASA e a Universidade Minessota. Hoje ele é mantido por diversas instituições
como: Universidade de Minessota, DM Solutions, CCGIS e UNIVALI. De forma que cada uma é
responsável por partes específicas do código. A parte de responsabilidade da UNIVALI é o
32
desenvolvimento do driver de comunicação com o Oracle Spatial, que é realizado através do
Laboratório de Computação Aplicada (LCA),.
Segundo MAPSERVER (2005) o MapServer 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;
•
Suportar a bancos de dados espaciais;
•
Suporte a Mapscript.
Ainda de acordo com MAPSERVER (2005), a ferramenta suporta as especificações OGC
(Open Geoespatial Consortiun), que são padrões para representação de dados espaciais, como
WMS (cliente e servidor), WFS não transacional (cliente e servidor), WCS (servidor), WMC, SLD,
e GML. O suporte a banco de dados espacial presente no MapServer possibilita o acesso a dados
armazenados em vários SGBDs, dentre eles o Oracle através do pacote Oracle Spatial. Esse acesso
aos bancos de dados pode ser de duas formas: através do suporte nativo ou através de OGR.
O suporte nativo a SGBDs apresenta a melhor performance, pois o acesso é feito
diretamente nas interfaces disponibilizadas pelo banco. Como exemplos de suportes nativos
podemos citar: Shapefile, através de arquitetura dual; MyGis, através de estratégia relacional;
PostGIS e Oracle Spatial, com estratégia orientada a objetos.
As características de suporte a vários bancos de dados fazem do MapServer um excelente
aplicativo de base para desenvolvimento de sistemas de Webmapping. Mesmo que não possa ser
considerado um aplicativo completo de SIG, o MapServer possui o suporte ao desenvolvimento de
sistemas SIG voltados a Internet possuindo uma base para fornecimento de mapas que pode ser
direcionada a vários tipos de aplicações. Assim sendo, o MapServer não disponibiliza nenhuma
ferramenta para análise espacial ou qualquer funcionalidade SIG complexa. Provê sim, a capacidade
de gerar objetos espaciais passiveis de serem utilizados no desenvolvimento dos aplicativos SIG.
33
O MapServer permite que aplicativos SIG possam manipular objetos espaciais de forma
simples, permitindo que mapas dinâmicos sejam gerados a partir da interação entre o usuário e a
aplicação. Não há restrição à utilização dos objetos espaciais, seu uso fica direcionado ao foco do
sistema desenvolvido, e ao MapServer cabe a função de suporte a estes objetos espaciais
(MAPSERVER, 2005).
Dentre as características principais destacam-se:
•
Acesso a Oracle Spatial: o MapServer pode comunicar-se diretamente com o Oracle
Spatial 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.
•
Suporte a Mapscript: Que são implementações em linguagem script (PHP, Pearl)
que acessam as funções do Mapserver possibilitando o acesso e a manipulação
objetos espaciais.
As duas características citadas, foram amplamente utilizadas no desenvolvimento do projeto,
Mapscript permitindo manipulação de objetos espaciais e Oracle Spatial para o armazenamento das
informações espaciais.
O uso do MapServer pode ser de duas formas principais: como gerador de mapas
geográficos ou como provedor de objetos espaciais (MAPSERVER, 2005). Quando utilizado como
gerador de mapas geográficos a principal funcionalidade é entregar mapas completos (mapa,
legenda, escala), a partir de requisições do usuário, entregando um mapa contendo todas as
informações selecionadas pelo usuário: camadas, símbolos e organização trabalhando em modo
CGI (Comoon Gateway Interface).
Quando o MapServer for utilizado como provedor de objetos espaciais, permite que sistemas
SIG possam utilizar seus objetos espaciais para diversas finalidades, principalmente geração de
análises espaciais. Essas análises não necessitam obrigatoriamente da geração de mapas no final do
processo e o MapServer pode então trabalhar sobre os objetos espaciais gerando como resultados,
outros tipos de saídas. Nessa forma de trabalho poderá ser usada programação Mapscript para
geração desses resultados.
34
Independente da forma de utilização, para que seja possível gerar tanto mapas quanto os
objetos espaciais, um requisito importante é necessário: a criação do Mapfile. É neste arquivo que
os parâmetros básicos serão definidos como: estilo, fontes, acesso aos dados e cores. Todos estes
parâmetros são usados para completar o objeto espacial, que é definido pelo bloco identificado por
layer no arquivo (Mapfile). O MapServer montará o objeto espacial através dos parâmetros
definidos no Mapfile através do layer (MAPSERVER, 2005).
Um detalhe importante a ser ressaltado é que as últimas versões do Mapserver, atualmente
na 4.4.6, permitem que parâmetros do Mapfile possam ser definidos dinamicamente via Mapscript,
sendo que já é possível trabalhar sem utilizar o arquivo de configuração mapfile (MAPSERVER,
2005).
O MapServer vem cada vez mais se destacando como ferramenta poderosa tanto para
sistemas SIGs voltados para Web quanto sistemas de Webmapping, os quais, permitem fácil
interação e dinamicidade trabalhando em tempo real. (MAPSERVER, 2005). Tudo isso, aliado a
facilidade de uso em conjunto com o banco de dados espacial Oracle Spatial, a facilidade de
desenvolvimento em PHP, utilizando o PHP/Mapscript e a licença de uso OpenSource/Freeware
foram fundamentais para que fosse utilizado esse projeto.
2.3.2.2.
Mapserver Guarani
Segundo o Laboratório de Computação Aplicada (LCA), o MapServer Guarani constitui-se
em um Framework para UMN MapServer que foi desenvolvido para permitir a elaboração de
sistemas voltados para WebMapping, incluindo funcionalidade de interação através de mapas e de
navegação.
De acordo com Guarani, (2005), as funcionalidades disponibilizadas são para sistemas SIG
desktop para Web, e permitem que múltiplos usuários possam compartilhar das mesmas ferramentas
a partir de um único sistema. Algumas destas funcionalidades são:
•
Conexão com banco de dados: permite a conexão com o PostgreSQL e Oracle,
também com as extensões espaciais;
•
Entrega de mapas sob demanda: permite a entrega de mapas, gerados pelo UMN
MapServer, através das requisições do usuário;
35
•
Navegação aprimorada: 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 na tela e
calcular as distâncias entre os mesmos em diversos sistemas métricos;
•
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;
•
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.
A ferramenta foi desenvolvida de forma modular e possibilita que novas funcionalidades
sejam adicionadas ou removidas do sistema sem interferir no funcionamento dos outros módulos
do aplicativo.
O MapServer Guarani é desenvolvido nas linguagens PHP e JavaScript e utiliza como
engine geradora de mapas o UMN MapServer, através de sua API PHP/Mapscript. O uso de
linguagens de conhecimento público no desenvolvimento do aplicativo, facilita a utilização,
manutenção e aprendizado da ferramenta que atualmente está em sua terceira versão.
Alguns projetos do LCA que já utilizaram o framework como interface para webmapping,
são: Pesca Tijucas, Sistema de Monitoramento de Mamíferos Marinhos (SIMMAM), BioEnsaios e
Sistema Rastreador Geográfico.
Devido ao fato de o Framework Mapserver Guarani permitir que novas funcionalidades
sejam adicionadas àquelas já existentes, o desenvolvimento de novas funções como a de
espacialização por quadrante foi incorporado facilmente a ferramenta que serviu de comunicação
entre a interface e os componentes internos do sistema.
36
2.3.3. Banco de Dados Geo Espaciais
A necessidade de armazenamento de grandes quantidades de dados fez surgir os sistemas
gerenciadores de banco de dados ou SGDB que de maneira estruturada, facilitaram o
armazenamento e utilização, tanto de dados espaciais, como também de atributos não espaciais
relacionados a geoobjetos.
De acordo com Silva (2002) o termo “banco de dados geoespaciais” é usado sempre que os
dados a serem armazenados possuem características espaciais, ou seja, possuem propriedades que
descrevem a sua localização no espaço (latitude/longitude) e a sua forma de representação.
Um banco de dados geoespacial necessita, além de controlar grandes quantidades de dados
espaciais armazenados, acessar e manipular atributos não espaciais. As mudanças necessárias para
comportar suporte espacial afetaram as lógicas de concepção dos sistemas SIG e mudaram os
conceitos de banco de dados que só foi possível após haver um entendimento dos padrões que
envolvem o tratamento de dados espaciais que diferem o banco geoespacial de banco
textual/numérico (SILVA, 2002).
De acordo com EPAMIG (1998 b) Os principais requisitos para que um banco de dados
possa trabalhar com dados espaciais são:
•
Modelagem
conceitual,
de
forma
que
os
avanços
na
modelagem
em
Geoprocessamento são necessários para permitir a utilização integrada de formas
matricial e vetorial, como também para gerar interfaces com maior conteúdo
semântico;
•
Integração Sensoriamento Remoto – Geoprocessamento, permitir integração entre
mapas temáticos, modelos de terreno e imagens de satélites necessárias para a análise
espacial;
•
Suporte adicional para área de Processamento de Imagens de Satélite, que utiliza
sensores e de técnicas de interpretação automática;
•
Representações Topológicas em Múltiplas Escalas e Projeções, assim em sistemas
que necessitam de muitas representações para um mesmo dado geográfico o sistema
deve garantir a unicidade de descrição;
37
•
Linguagens de Consulta, Manipulação e Apresentação, o banco requer linguagens de
consulta, manipulação e representação de objetos espaciais de grande poder, que
podem ser baseadas em SQL para consulta e para manipulação de dados geográficos
linguagem da álgebra de mapas;
•
Novas Técnicas de Análise Geográfica, a incorporação de técnicas de análise
geográfica como classificação contínua e modelagem ambiental, é necessária para
que os SIG sejam capazes de satisfazer de forma plena aos requisitos de análise e
modelagem de grandes bases de dados;
•
Arquiteturas para Bancos de Dados de Grande Porte, onde são necessárias mudanças
nos esquemas tradicionais de arquiteturas de sistemas de gerência de banco de dados
com avanças em novas arquitetura e métodos de indexação espacial.
Conforme Silva (2002) os bancos de dados geoespaciais devem garantir um total controle
sobre objetos espaciais, permitindo meios de manipular eficientemente esses objetos. Assim os
bancos de dados geo-espaciais possuem métodos denominados como indexação espacial onde os
mais comuns são: KD-tree, Quad-trees e R-trees.
Quanto a modelagem, os bancos de dados geoespaciais podem ser de três formas: Modelo
Relacional, Modelo Relacional Estendido e Modelo Orientado a Objetos. Dessas três formas se
destaca o Modelo Relacional Estendido que é uma mistura entre o modelo relacional e o modelo
orientado a objetos. Esse modelo contempla uma necessidade advinda do modelo relacional que é a
inclusão de tipos de dados longos de tamanho variável. Isso proporcionou o armazenamento
dinâmico de objetos complexos como os objetos espaciais em um modelo relacional (SILVA,
2002).
Quanto à arquitetura para os bancos de dados espaciais, elas podem ser: Arquitetura dual ou
arquitetura integrada. A arquitetura Integrada é a que usa o Modelo Relacional Estendido. Começou
com a utilização de campos longos e atualmente através de extensões espaciais especialmente para
trabalhar com objetos complexos como é o caso da ORACLE com a extensão SPATIAL. Esse tipo
de arquitetura não apresenta problema de integridade e o próprio SGDB provê os métodos de acesso
e controle sobre todos os dados, cabendo ao SIG somente a manipulação do geoobjeto (SILVA,
2002).
38
Devido ao SIESPE ser um sistema que usa o SGDB ORACLE foi adotado o mesmo SGDB
para este projeto. Um fator que influenciou para a escolha, é que o ORACLE possui suporte
espacial através da extensão SPATIAL. A seguir breve descrição sobre esse SGBD e sua extensão
espacial.
2.3.3.1.
Oracle/Spatial
O Oracle é um sistema gerenciador de banco de dados objeto-relacional com abordagem
aberta 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 (ORACLE, 2005).
A arquitetura do Oracle provê muitas características como: uma arquitetura cliente servidor,
segurança gerenciável, interidade de dados, portabilidade de informações, replicação, e sistemas
distribuídos (ORACLE, 2005).
O Oracle possui um conjunto de funcionalidades (funções e procedimentos) que permitem o
armazenamento, acesso, modificação e análise de dados espaciais, agregados num pacote
denominado Oracle Spatial.
Segundo Queiroz & Ferreira (2005) o Oracle Spatial é formado pelos seguintes
componentes:
•
Um modelo chamado MDSYS responsável pela forma de armazenamento, a sintaxe
e semântica de tipos geométricos suportados;
•
Sistema de indexação espacial;
•
Conjunto de operadores e funções para realizar consultas e manipulação de dados
espaciais;
•
Funções administrativas.
No Oracle Spatial, de acordo com a implementação da estratégia objeto relacional, os dados
espaciais são armazenados internamente em qualquer tabela, desde que apresente uma coluna do
tipo SDO_GEOMETRY e uma chave primária para indexação (SILVA, 2002).
39
Esta coluna é visível através das consultas relacionais, mas internamente ela faz referência a
um objeto, sendo que os dados espaciais armazenados nesta coluna estão na realidade organizados
através de atributos em um objeto espacial.
O modelo do Oracle Saptial permite que dados de diversos tipos possam ser armazenados,
inclusive a criação de novos tipos. O modelo é formado por um conjunto hierárquico de elementos,
geometrias e planos de informação. Os planos são formados por geometrias que são formadas por
elementos e esse elemento está associado a um tipo primitivo. Os tipos primitivos 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 (QUEIROZ & FERREIRA, 2005).
Figura 4. Tipos primitivos do Oracle Spatial
Fonte: Queiroz & Ferreira (2005).
O objeto espacial utilizado pelo esquema Oracle Spatial para armazenamento é organizado
hierarquicamente em elemento, geometria, e camada (layer), onde um elemento é a estrutura básica
que suporta o objeto espacial interno no banco. Este elemento pode ser de três tipos primitivos,
pontos, linhas e polígonos (SILVA, 2002)
Segundo Silva (2002) uma layer corresponde a uma tabela espacial que contém uma coluna
do tipo espacial, onde uma geometria corresponde a cada linha desta tabela, sendo que uma camada
é um conjunto de geometrias que apresentam os mesmos atributos.
40
No modelo do Oracle Spatial, todo o objeto espacial está associado a um sistema de
coordenadas, mesmo que a mesma seja definida como NULL. Esta informação é necessária para
que o banco de dados possa relacionar a localização espacial com os dados informados, assim,
dependendo do tipo de coordenada alguns cálculos especiais devem ser realizados sobre os dados,
como os cálculos de projeção. O sistema de coordenadas pode ser do tipo georreferenciada ou não
(QUEIROZ & FERREIRA, 2005).
É a partir da correta definição do tipo de sistema de coordenada 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 os sistema de coordenadas utilizadas, sem que este trabalho seja implementado
pelo usuário (QUEIROZ & FERREIRA, 2005)
O Oracle Spatial utiliza duas etapas internas na realização de suas consultas espaciais. De
acordo com Queiroz & Ferreira (2005) existem duas formas distintas de operações que são
executadas no momento de uma pesquisa. Essas formas são:
•
Filtro primário: funciona por aproximação da geometria envolvente a fim de reduzir
a complexidade computacional permitindo realizar pesquisas rápidas sobre os dados
armazenados no banco através de comparações ente a geometria da pesquisa e as
geometrias armazenadas.
•
Filtro secundário: trabalha com as geometrias exatas, realiza comparações entre as
relações dos dados espaciais retornados pelo filtro primário com os dados existentes
na consultas.
A pesquisa espacial realizada pode ser definida pelo usuário por meio de funções do banco
utilizadas nas consultas. Os tipos de relações utilizadas no filtro secundário também podem ser
definidos pelo usuário.
41
Figura 5. Relações entre os tipos de pesquisa espacial
Fonte: Queiroz & Ferreira (2005)
O Oracle Spatial possui muitas outras funcionalidades como indexação espacial para
trabalhar com geo-objetos de alta performance, como o R-tree e o Quad-tree. Também possui
operadores e funções que podem ser usados de forma conjugada para um melhor resultado no
trabalho com geo-objetos ou separadamente, dependendo da necessidade. Essas funções não serão
abordadas nesse trabalho por não serem objetivo do mesmo, mas torna-se importante salientar a
compatibilidade entre o Oracle Spatial e o Mapserver o que também se traduz em uma vantagem
para o desenvolvimento.
2.3.4. Linguagem de Programação
2.3.4.1.
Mapscript
Segundo MAPSERVER (2005), Mapscript é uma interface disponibilizada pelo MapServer
que permite a criação de scripts em diversas linguagens. Essa interface, disponibilizando ao
desenvolvedor uma 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.
De acordo com MAPSERVER (2005), MapScript não é uma linguagem como JavaScript ou
Postscript, é sim um módulo (extensão) que possibilita desenvolver sistemas com extensão espacial
utilizando o MapServer, através das linguagens suportadas.
42
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
adicionada ao suporte à manipulação de objetos espaciais. 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 a pesquisa aos atributos não espaciais dos objetos;
•
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 (MAPSERVER, 20005).
Um detalhe a ser destacado é que o objeto espacial do MapScript, contendo todos os seus
parâmetros, está 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 (MAPSERVER, 20005).
São inúmeras as funções do tipo layerobj, podendo-se destacar como principais as funções
de pesquisa a atributos e de retorno de dados do objeto, sendo que o acesso aos atributos que
compõem 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
Sistemas de Informação Geográfica podem ser desenvolvidos através do Mapserver, pois é este que
disponibiliza o objeto espacial já devidamente formatado, facilitando assim a sua utilização pelo
SIG.
43
O PHP foi a principal linguagem utilizada no desenvolvimento do projeto através das
facilidades de integração fornecidas pelo Mapscript com as funcionalidades do MapServer, como
também a interface com o banco de dados.
2.4. FERRAMENTAS SIMILARES
Nas pesquisas realizadas, não foram encontradas ferramentas que fossem totalmente
similares a proposta. Existem varias ferramentas com propósitos diferentes que utilizam o conceito
WebMapping, muitas delas desenvolvidas pelo próprio LCA. Abaixo segue descrição resumida de
algumas ferramentas estudadas:
2.4.1. Sipesca
Um projeto semelhante na área de pesca é o SIPESCA desenvolvido pelo Laboratório de
Computação Aplicada do CTTMar/UNIVALI (ALVES et al. 2002). Este sistema é um modelo de
informações para a gestão de recursos pesqueiros. O mesmo é disponibilizado na web e apresenta
informações geocodificadas, permitindo a consulta a mapas da região da Baia de Guanabara no Rio
de Janeiro.
O sistema é construído dentro do conceito WebMapping e usa ferramentas OpenSource com
uma arquitetura baseada na plataforma operacional GNU/Linux e o sistema de gerenciamento de
banco de dados Oracle
Para interação com o usuário o sistema utiliza requisições web que disparam através dos
níveis de aplicação Apache, OpenSSL e PHP programas que interagem com a plataforma
operacional e implementam a funcionalidade do sistema, gerando conteúdo em formato
HTML/JavaScript.
A capacidade SIG do sistema se da através dá tecnologia MapServer, juntamente com a
linguagem PHP, permitindo a geração automática de mapas para a Web. A pesquisa em conteúdo
espacial é implementada via extensão Spatial da Oracle.
44
2.4.2. Sagreh
O Sagreh é outro projeto desenvolvido pelo Laboratório de Computação Aplicada do
CTTMar/UNIVALI com suporte espacial, baseado em tecnologias Opensource para web, usado no
apoio ao planejamento e à gestão dos recursos hídricos da bacia do Itajaí (SPERB et al. 2004).
O sistema permite a identificação de informações detalhadas para todo tipo de usuário de
água, e através da parametrização das finalidades de utilização, seus tipos de uso e produtos
associados. As atividades associadas aos usuários estão normatizadas pelo Cadastro Nacional de
Atividades Econômicas (CNAE), fator que facilita a organização e pesquisa de informações
(SPERB et al. 2004).
Algo de interessante nesse sistema é a sua interface web avançada e intuitiva e que permite
localizar objetos no mapa associados a usuários ou rios, os quais são destacados para visualização.
2.4.3. Rastro
O Rastro é um sistema para rastreamento online de embarcações via satélite. Se constitui em
um sistema construído com tecnologias freeware como: OSS/FS, GNU/Linux, Apache, OpenSSL,
PHP e MapScript, interligadas através de scripts e pequenos programas que dão forma à aplicação
de rastreamento (CABRAL et al. 2002).
Na aplicação, os usuários, de qualquer ponto na Internet, podem acessar a informação de
rastreamento de embarcações organizada na forma de mapas (imagens) e texto (histórico de
posições). A navegação no mapa e o acesso ao histórico de posições são implementados através de
páginas web que facilitam a descoberta da posição da embarcação monitorada, bem como a
inspeção do deslocamento. Para isso a aplicação recebe como entrada dados provindos do serviço
de rastreamento via satélites que é tratado em um servidor antes e após liberado para consultas
(CABRAL et al. 2002).
O sistema de rastreamento online de veículos monitorados via satélite está sendo utilizado
pelo projeto de rastreamento em conjunto com o Grupo de Estudos Pesqueiros (GEP) do Centro de
Tecnologias da Terra e do Mar (CTTMar) da Universidade do Vale do Itajaí (UNIVALI), onde a
aplicação é utilizada no rastreamento das embarcações arrendadas (CABRAL et al. 2002).
45
2.4.4. Ecosgrass
Ecosgrass um sistema integrado com funcionalidades para o gerenciamento de informações
de objetos espaciais discretos, integrado pelo SIG EcosGRASS, o banco de dados espacial
PostgreSQL/PostGIS e o servidor web de mapas Ecos Mapserver (DUPRÉ et al. 2004).
O GRASS foi originalmente desenvolvido pelo Laboratório de Pesquisa em Engenharia da
Construção do Corpo de Engenheiros do Exército Americano (U.S. Army Construction Engineering
Research Laboratories - USACERL) como ferramenta de planejamento e gestão do terreno com
fins militares. O projeto foi abandonado após ter atingido o objetivo de desenvolver a base
conceitual a ser utilizada pelos fornecedores de SIG americanos, visando atender as necessidades do
setor militar. Desde 1999, uma versão derivada do projeto original é mantida e distribuída como
Software Livre (licença GPL) pela Comunidade GRASS. O projeto é denominado EcosGRASS e
tem como as principais características: a) Gerenciamento de feições vetoriais discretas com
estrutura topológica; b)armazenamento simultâneo e em tempo real das entidades espaciais; c)
Álgebra de mapas; d) Análise Grid; e) Geração de cenários 3D (DUPRÉ et al. 2004).
O aplicativo está sendo usado pela prefeitura de Rio do Sul como sistema de gestão espacial
Urbana.
2.5. Método de Divisão por quadrantes
A principal inspiração para dar início a esse trabalho veio da observação do método de
trabalho dos pesquisadores, especificamente sobre um projeto de pesquisa sobre atuns, o qual utiliza
a divisão em quadrantes para fins de análise. A diferença é que no trabalho de pesquisa o
procedimento é todo “manual”, enquanto que na ferramenta proposta será automatizado.
Trata-se de uma metodologia que utiliza a técnica de divisão em quadrantes para
espacializar dados de capturas para o projeto de Avaliação da Pescaria de Tunídeos
(UNIVALI/CTTMar, 2003 b). Este projeto é executado por pesquisadores do próprio CTTMar e
utiliza o método de espacialização por quadrantes para mostrar a dinâmica da pescaria dos atuns
(albacoras, bonitos, agulhões...) no sudeste e sul do Brasil, onde os dados de captura são
apresentados em unidades de esforço por unidades de área. Para chegar a um relatório mais
eficiente, é realizado um mapeamento utilizando a divisão da área do oceano em quadrantes
formando uma grade, de forma que os dados pontuais (com latitude e longitude) são agrupados e
somados dentro de cada unidade da grade a que pertencem. Para gerar gráficos trimestrais e anuais
46
a captura por unidade de esforço é obtida calculando uma média ponderada dos quadrantes
envolvidos. Os mapas são plotados com uma resolução de 1º latitude por 1º longitude, que é o
refinamento recomendado pela ICCAT (International Commission for the Conservation of Atlantic
Tunas) órgão que regulamenta a pesca de atuns no Oceano Atlântico (UNIVALI/CTTMar. 2003 b).
47
3. PROJETO
3.1. INTRODUÇÃO
De acordo com a literatura estudada, não foi encontrado nenhum trabalho com
características muito semelhantes ao aqui proposto, embora a idéia venha de uma necessidade real
existente na maioria dos sistemas que lidam com dados pesqueiros. Principalmente, porque o
trabalho vem adicionar funcionalidades a um sistema existente, o SIESPE, modelado e já populado
mas com a deficiência de não espacializar os dados das pescarias.
Este trabalho se propõe a facilitar a entrada de novos dados de localização e recuperar dados
já cadastrados que não possuem uma forma de localização adequada, facilitando a passagem dos
mesmos para o formato de quadrantes. Essas funcionalidades irão facilitar as consultas requeridas
para estudos desenvolvidos pelos pesquisadores do GEP.
Neste capítulo serão apresentadas as etapas de desenvolvimento do trabalho, juntamente
com a modelagem, onde serão mostradas as principais funcionalidades de acordo com os objetivos
propostos utilizando tanto tecnologia de sistemas de informações geográficas como de
WebMapping.
Este projeto foi viabilizado com o apoio do Grupo de Estudos Pesqueiros-GEP do
CTTMar/UNIVALI e também do Laboratório de Computação Aplicada – LCA, que possui toda a
estrutura necessária para o desenvolvimento de projetos na área de SIG voltados para Web. Na
etapa final do trabalho, o LCA forneceu, além do apoio técnico, um espaço físico para que a
ferramenta fosse desenvolvida dentro do laboratório, facilitando todo processo. Além desse trabalho
de conclusão, existe outro trabalho que também está sendo desenvolvido no LCA que utiliza a
técnica de quadrantes para realizar análise espacial sobre dados de pesca. Na medida do possível,
houve cooperação entre os projetos no sentido de contribuir para o sucesso dos mesmos.
3.2. DADOS DO SISTEMA
Conforme descrito no capítulo 2, o módulo proposto atuará sobre os dados do sistema
existente SIESPE e adicionará as funcionalidades de entrada e de armazenamento de dados de
localização das capturas pesqueiras na forma de quadrantes (polígonos).
48
Os dados novos terão sua entrada através de sistema gráfico por meio de seleção das áreas
correspondentes e o sistema armazenará os identificadores relativos aos quadrantes em tabelas no
banco de dados relacionadas a cada desembarque. Já os dados que já estão no SIESPE serão
importados para o novo formato.
3.3. MODELAGEM DO SISTEMA
A modelagem do sistema mostra os aspectos lógicos e relacionais fazendo uma transcrição
das informações reais para modelos lógicos de solução. O objetivo é mostrar em uma representação
conceitual as classes básicas, as associações e funções que farão com que o módulo proposto seja
implementado.
Foi utilizada a modelagem orientada a objetos em UML (Unified Model Language), onde
foram usados os diagramas considerados importantes no processo de desenvolvimento do projeto de
software.
Segundo Stefanes (1999), UML é uma notação para modelagem de sistemas, que usa
conceitos orientados a objetos. Ela usa princípios, padrões e formulas para chegar a soluções dos
problemas em todo o processo de desenvolvimento, motivo pelo qual foi escolhido este tipo de
modelagem para o projeto.
3.3.1. Ferramenta de Modelagem
A ferramenta utilizada para modelagem do sistema é a EA Enterprise Architect produzida
pela empresa australiana SPARK SYSTEM. A ferramenta trabalha dentro dos padrões UML
cobrindo todos os diagramas previstos. Além disso, a ferramenta é de fácil utilização possuindo
uma interface amigável e padronizada.
Algumas das facilidades providas pela ferramenta EA Enterprise Architect são: modelagem
no padrão UML 2.0, possibilidade de trabalhar com engenharia reversa, possui facilidade para
geração de código, possibilita a exportação dos modelos completos em vários formatos ou a geração
de relatório em XML entre outras. O site da ferramenta é http://www.sparxsystems.com.au/ .
49
3.3.2. Requisitos do Sistema
As figuras abaixo apresentam os requisitos principais do módulo de espacialização, a figura
6 mostra os requisitos funcionais para o sistema e a figura 7 mostra os requisitos não funcionais.
cd Funcionais
RF1:O sistema deve permitir a entrada de dados de
RF8: O sistema deve consultar banco de dados (SIESPE) e
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
localização de capturas por quadrantes (latitude x longitude).
listar os desembarques que não estão espacializados
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
RF2: O sistema deve apresentar mapa da costa marítima
brasileira, com batimetria e dividido em quadrantes
RF9: O sistema deve analisar o campo descritivo de área de
pesca existente no banco SIESPE e sugerir áreas
correspondentes
RF3: O sistema deve criar um objeto para cada quadrante
RF10: O sistema deve permitir associar o desembarque a
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
representado no mapaTrial
que possa
receber informações
uma
ou mais
áreas propostas
ou a5.0
entrada
de áreas novas
EA 5.0 Unregistered
Version
EA 5.0 Unregistered
Trial
Version
EA
Unregistered
Trial Version
espaciais
EA 5.0 Unregistered
Triala entrada
Version
EA
Trial
Version
EAde5.0
Unregistered Trial Version
RF4:O sistema deve permitir
de dados
para5.0
cada Unregistered
RF11:
O sistema
deve ter áreas
correspondências
objeto através da seleção dos mesmos
diferentes para petrechos e documentos diferentes
(mapas/entrevistas)
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
RF5: O sistema deve permitir selecionar mais de um objeto
de cada vez para um mesmo desembarque
RF12:O sistema deve armazenar as informações referentes a
EA 5.0 Unregistered Trial Version EA 5.0 Unregisteredquadrantes
Trial Version
EA
5.0emUnregistered
Trial Version
e as alterações do
registro
banco de dados
RF6: O Sistema deve armazenar
as informações
espaciais
EA 5.0 Unregistered
Trial Version
EA
5.0 UnregisteredR13:Trial
Version
EA de5.0
Unregistered
Trial Version
O sistema
deve dar opções
consulta
a registros
referentes aos quadrante selecionado em banco de dados
com suporte espacial
espacializados
RF7: O sistema deve relacionar as informações dos
R16: O sistema deve apresentar no mapa os dados relativos
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
opção de consulta
quadrantes às informações do banco de dados relacional
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistereda uma
Trial
Version EA 5.0 Unregistered Trial Version
existente do Siespe
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Figura 6. Representação dos Requisitos Funcionais
50
Figura 7. Representação dos Requisitos não funcionais
3.3.3. Estudo do Modelo de Banco de dados do SIESPE
O SIESPE utiliza o ORACLE® como Sistema Gerenciador de Banco de Dados. Baseado
nisso é que o sistema de quadrantes também usará esse mesmo banco de dados para
armazenamento.
Antes de qualquer tarefa de modelagem foi necessário um estudo no modelo de banco de
dados do SIESPE a fim de encontrar possíveis pontos de associação e locais considerados
estratégicos onde não demandaria grandes alterações no modelo atual para inclusão da nova
funcionalidade.
51
O estudo se deu a partir das entidades, levando em consideração também seus atributos,
associações e dependências. Os diagramas apontaram a existência de três fluxos possíveis para
armazenamento de dados relativos ao desembarques a partir de criação do mesmo na entidade
desembarque. Os fluxos são complementares o que implica que para cada desembarque deverá
existir uma associação com um ou ambos os fluxos. A explicação para a existência de fluxos
diferentes é a existência de três documentos fontes que podem vir de formas distintas através de: a)
mapa de bordo; b) Entrevista no cais; e c) Fichas de produção. Assim o banco foi modelado para
refletir essas três maneiras diferentes para registro de desembarques.
Foi verificado também que, dos três fluxos, somente dois possuem capacidade de
armazenamento de dados relativos a localização, que são mapa de bordo e entrevista no cais,
descartando então o fluxo fichas de produção que não possui essa capacidade.
Outra particularidade verificada na modelagem do SIESPE é a existência de uma entidade
para cada tipo de desembarque levando em consideração o petrecho e o documento de origem.
Dessa forma, o fluxo de entrevista é dividido em seis novos fluxos de acordo com os petrechos
cobertos por ela. Assim como também o fluxo mapa é dividido para refletir os petrechos.
De acordo com o modelo do SIESPE são nas entidades relacionadas aos petrechos que se
encontram os principais atributos e associações que dão unicidade a cada desembarque. Uma dessas
associações se dá com as entidades de área de pesca que também são diferentes para cada petrecho
em cada documento.
As entidades referentes a área de pesca possuem atributos principalmente relativos a
profundidade, tempo de permanência e descrição das área de pesca, podendo ter ainda outros
atributos dependendo do petrecho. Como é nesse ponto do modelo que existe referência às
localizações então também é nesse ponto que melhor se adequou a característica de
geoespacialização por quadrante.
O diagrama a seguir reflete o estudo do modelo de SIESPE, mostrando as entidades estudas
e suas associações:
52
cd Logical Model
SIESPE
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
«objeto»
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
Desembarque
Desembar
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA
5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version
«objeto»
Mapa_Entrevista
«objeto»
Mapa de bordo
Entrev ista no cais
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version«objeto»
EA 5.0 Unregistered«objeto»
Trial Version EA 5.0
Unregistered Trial Version
«objeto»
«objeto»
Mapa_arrasto
Area_mapa_arrasto
Area_entrev ista_arrasto
Entrev ista_arrasto
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version«objeto»
EA 5.0 Unregistered«objeto»
Trial Version EA 5.0
Unregistered Trial Version
«objeto»
«objeto»
Mapa_cerco
Area_mapa_cerco
Area_entrev ista_cerco
Entrev ista_cerco
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
«objeto»
Mapa_emalhe
«objeto»
Area_mapa_emalhe
«objeto»
Area_entrev ista_emalhe
«objeto»
Estrev ista_emalhe
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
«objeto»
Mapa_espinhel
«objeto»
Area_mapa_espinhel
«objeto»
Area_entrev ista_Vara_iv
«objeto»
Entrev ista_Vara_isca_v iv a
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
«objeto»
Mapa_armadilha
«objeto»
Area_mapa_armadilha
«objeto»
Area_entrev ista_esp_fundo
«objeto»
Esntrev ista_espinhe_fundo
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
«objeto»
«objeto»
«objeto»
«objeto»
Mapa_v ara_isca_v iv a
Area_mapa_v ara_isca_v iv a
Area_entrev ista_esp_superf
Entrev ista_Espinhel_superficie
EA 5.0 Unregistered
Trial Version
EA 5.0 Unregistered
Trial Version EA
5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Figura 8. Visão parcial do modelo de dados do SIESPE
3.3.4. Diagramas de Caso de Uso
De acordo com (STEFANES, 2002) os diagramas de casos de uso são uma forma para
descrever uma visão externa do sistema apresentando através de descrições narrativas as interações
do sistema com o mundo exterior. Os diagramas representam uma visão macro do sistema
mostrando a relação do mesmo com as ações do usuário.
No sistema de quadrantes, os diagramas de caso de uso representam ações que o usuário
poderá efetuar no sistema, de forma que o usuário terá a capacidade de executar o lançamento da
53
espacialização de um novo desembarque, requisitar um desembarque antigo para espacializá-lo e
consultar dados de espacialização dos desembarques. Em todos os casos o sistema verifica os
parâmetros e monta ou atualiza a tela. A figura 9 apresenta o diagrama use case que mostra as ações
do usuário sobre o sistema que executa procedimentos e retorna os resultados para a tela do usuário:
ud Modelo Use Case
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Sistema de Quadrantes
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
UC2: Executa nov o
lançamento paraTrial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
espacializar
«extend»
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
UC2: Consulta dasdos de
lançamento espacializados
«extend»
UC4: Monta e atualiza a
tela
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Usuário
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version
«extend»
UC3: Altera lançamento
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
antigo espacializado
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Figura 9. Visão Use Case do módulo proposto.
3.3.5. Descrições dos Casos de Uso
As tabelas abaixo trazem as principais descrições dos casos de uso para o sistema:
Tabela 1.: Caso de uso executa novo lançamento para espacializar.
Nome do caso de uso: UC1: Executa seleção para novo lançamento e espacializa
Quem dispara: Usuário
Curso Básico: Após criar um novo desembarque no SIESPE, o usuário aciona o módulo de
lançamento de espacialização. Nesse momento o sistema monta a tela com o mapa base e
os quadrantes e fica esperando a seleção dos quadrantes pelo usuário (clique) para cada área
onde ocorreu pescaria. O usuário pode ajustar o zoom da tela, selecionar os quadrantes
equivalentes a área de pesca e salvar no sistema. O sistema salva as informações dos
quadrantes em banco de dados e retorna nova tela atualizada mostrando os quadrantes
selecionados para o desembarque salvo. O modulo de seleção também pode ser acio nado
pelos módulos procura não espacializados e pelo localiza espacializados.
Curso alternativo: Os quadrantes selecionados podem ser excluídos na forma de um por
vez ou todos.
Pré-condições: Para executar o lançamento o desembarque já deve estar criado de acordo
com o tipo de documento (Mapa de bordo e Entrevista), e petrecho do mesmo. Não é
possível espacializar sem essas informações, pois as áreas são especializadas de acordo
com os dados específicos para cada tipo de desembarque. Esse modo funciona para novos
desembarques ou para desembarques selecionados no módulo de consulta..
54
Tabela 2.: Caso de Uso consulta dados de lançamentos espacializados.
Nome do caso de uso: UC2: Consulta dados de lançamentos espacializados para exclusão
ou alteração
Quem dispara: Usuário
Curso Básico: O usuário aciona o modulo de quadrantes. O sistema monta a tela com o
mapa base, os quadrantes e também uma tela de opções onde o usuário escolhe o modo de
consulta e especifica opções da consulta com parâmetros como tipo de documento,
petrecho e data; ou então digita um desembarque. O sistema atualiza a tela de acordo com
os parâmetros criando uma lista dos desembarques espacializados. Ao selecionar um
desembarque da lista o sistema mostra os quadrantes que estão espacializados para o
mesmo. O usuário poderá ajustar o zoom para visualizar melhor os resultados.
Curso alternativo: O registro pode ser excluído ou alterado através da seleção e
confirmação.
Pré-condições: Para que a consulta aconteça, os desembarques devem estar espacializados
e os parâmetros de consulta selecionados.
Pós-condições: Não possui
Tabela 3.: Caso de uso Espacializar Lançamento Existente
Nome do caso de uso: UC3: Espacializar Lançamento Existente não Espacializado
Quem dispara: Usuário
Curso Básico: O usuário aciona o módulo. O sistema monta a tela com o mapa base e os
quadrantes. O usuário indica que irá consultar desembarques não espacializados. O sistema
mostra opções onde o usuário pode digitar um desembarque específico ou requisitar para o
sistema mostrar uma lista de desembarques ainda não espacializados para um tipo de
documento fonte (entrevista ou mapa), petrecho e período. O sistema então atualiza a tela
de acordo com a opção escolhida. Ao selecionar um desembarque da lista o sistema verifica
se há alguma descrição de área na tabela de área correspondente ao desembarque. Se
houver verifica na tabela de áreas similares se há áreas cadastradas com descrição parecida.
Se houver, traz uma lista de opções com sugestões de quadrantes os quais o usuário poderá
aceitar ou inserir novos. Para iniciar a espacialização o usuário deve selecionar o
desembarque e logo após uma das áreas listadas para o mesmo, o sistema então muda para
o modo de espacialização onde o usuário poderá escolher os quadrantes para o
desembarque selecionado.
Curso alternativo: Ao entrar o usuário pode optar entre alterar um desembarque não
espacializado ou consultar um desembarque espacializado.
Pré-condições: Para que seja gerada a lista de correspondência, o campo descritivo área
deverá estar preenchido na tabela de área correspondente ao documento. A tabela de
correspondência também deverá estar atualizada.
Pós-condições: Marcar desembarque como espacializado na tabela de desembarques
55
Tabela 4.: Caso de uso monta e atualiza a tela
Nome do caso de uso: UC4: Monta e atualiza a tela
Quem dispara: UC1/UC2/UC3
Curso Básico: Em qualquer dos casos, primeiro o sistema monta a tela com o mapa e com
os quadrantes, a linha de costa e as linhas batimétricas. da costa definidos em banco de
dados. Também monta as opções por onde o usuário pode determinar o que deseja fazer. A
partir dos parâmetros passados por qualquer caso de uso o sistema atualiza novamente a
tela e espera por uma ação do usuário através do caso de uso.
Curso alternativo:
Pré-condições: Para a montagem da tela com os quadrantes é necessário que os mesmos
estejam definidos em banco de dados.
Pós-condições:
3.3.6. Diagrama de classes e ER
Conforme STEFANES (2002), os diagramas de classes são a essência da UML, são eles que
definem a estrutura lógica e estática do sistema. Nesse modelo são representadas as classes,
juntamente com os tipos de conteúdos, métodos e relações. Os diagramas de classe têm grande
importância no sistema, devido à enorme quantidade de elementos que podem ser visualizados para
o entendimento do sistema.
A figura 10 apresenta o modelo de classes conceitual, o qual demonstra os relacionamentos
conceituais entre as classes do SIESPE e as novas classes propostas para o módulo de
geocodificação por quadrantes. È possível observar duas classes principais: Mapa de Bordo e
Entrevista que possuem derivações para cada petrecho. Em cada petrecho há uma associação com
uma classe área, onde houve a ligação do módulo de geocidificação. Este diagrama foi elaborado
para uma melhor compreensão do SIESPE, através de um processo de engenharia reversa, que
possibilitou realizar as alterações/ inclusões de classes necessárias ao módulo proposto.
Depois de realizada esta análise, elaborou-se o novo diagrama ER para o SIESPE, ou parte
do mesmo, acrescentando as tabelas necessárias para realizar-se o georeferenciamento dos
desembarques do Sistema SIESPE. As classes representadas foram as que tiveram alterações para a
inclusão da nova funcionalidade. Classes associativa entre essas classes e a classe quadrante irão
permitir maior flexibilidade no sistema. Para a classe quadrante, é possível observar o atributo
geométrico, o qual será responsável pela utilização das funcionalidades do Oracle Spatial.
56
cd Modelo lógico
Ent_arrasto
Ent_area_arr
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Ent_cerco
Ent_area_cer
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Entrev ista
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
Ent_emalhe
Ent_area_ema
Módulo Quadrante
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Ent_v ara_isca_v iv a
Ent_area_v iv
Quadrante
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
-
Cd_quadrante: var
Nm_quadrante: var
Gm_quadrante: Sdo.geometry
+
Encontrar_quadrante() : void
«object
system»
EA
5.0
Unregistered Trial Version EA 5.0 Unregistered Trial Version EA+5.0
Unregistered Trial Version
Atribuir_valores() : void
SIESPE
Ent_area_ef
Ent_esp_fun
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Ent_area_es
Ent_esp_sup
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
Map_arrasto
map_area_arr
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Map_cerco
Map_area_cer
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Map_area_ema
Map_emalhe
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Área similar
Mapa de Bordo
- Cd_area_sililar
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
Map_area_esp
Map_espinhel
- Cd_petrecho_indust
- DS_area_similar
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Map_area_arm
Map_armadilha
EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Map_area_v iv
Map_v ara_isca_v iv a
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Figura 10. Modelo Conceitual mostrando a relação do Módulo proposto ao do SIESPE.
57
Figura 11. Diagrama de Entidade Relacionamento.
58
3.3.7. Representação da Estrutura do Sistema
Na figura 12 pode ser visualizado o esquema da estrutura do módulo proposto, visualizando
as tecnologias que serão utilizadas como: Sistema operacional Linux, banco e dados Oracle com
extenção espacial Spatial, servidor de mapas Mapserver, Linguagem de programação para
integração PHP, servidor de páginas web Apache e suporte a conexão segura OpenSSL. Também
pode ser vista a relação com o ambiente web.
Figura 12. Estrutura do sistema proposto
Fonte: ALVES et al. (2002)
3.3.8. Definição dos Mapas ou Cartas
Os mapas ou cartas usadas no projeto são disponibilizados pela Agência Nacional de
Petróleo – ANP. A carta principal representa as linhas batimétricas e da linha da costa com a
identificação dos principais locais de referência ao longo da mesma. O sistema de projeção utilizado
na produção dessas cartas é a UTM e o sistema de coordenados é o WGS – 64.
Essas cartas, segundo os pesquisadores do GEP, são muito completas e precisas e também
oferecem muitas opções com relação às linhas de batimetria e escala. Por essa razão e também por
ser disponibilizada gratuitamente ela foi a escolhida para o projeto. As cartas da ANP estão
disponíveis na Internet através do endereço: http://www.bdep.gov.br/webmaps_download.html.
59
3.3.9. Definição e aquisição dos quadrantes
Para o sistema, os quadrantes são pequenos objetos geométricos armazenados em banco de
dados. Toda vez que é solicitada a montagem da tela para lançamento esses objetos são
posicionados de acordo com as informações de geometria armazenada. Assim, cada quadrante
ocupará uma posição no grid sem se sobrepor.
Os quadrantes serão armazenados em banco devido à necessidade de os mesmos serem
objetos clicáveis, assim uma etapa importante da modelagem é justamente a definição desses
quadrantes.
Como previsto nos requisitos do sistema, os quadrantes terão uma resolução de 30’(trinta
minutos), ou seja, cada quadrícula representará 30’ de latitude por 30’ de longitude. A aquisição das
geometrias dos quadrantes foi realizada com o auxílio da ferramenta ArcMap® através de uma base
digital da ANP. Todo o processo de aquisição, bem como os outros processos necessários ao
funcionamento do módulo serão descritos mais adiante.
60
4. IMPLEMENTAÇÃO
A etapa de implementação permite dar vida a todo o processo que começou com a revisão
bibliográfica, passou pelas definições de requisitos e pela modelagem. Nesta etapa, além de colocar
em prática o que já está definido na modelagem, foi possível verificar possíveis equívocos ou falhas
que puderam ou não ser corrigidos, dependendo da gravidade ou da importância que recairá sobre o
funcionamento do sistema como um todo.
Para esse projeto, a implementação passou por algumas fases importantes para que os
objetivos fossem cumpridos em sua totalidade. Muitas atividades que não estavam inteiramente
previstas tiveram que ser efetuadas, pois a construção da ferramenta necessitou de uma estrutura
previamente montada e configurada.
A primeira fase foi determinada pela definição e criação dos quadrantes, ou seja, instituir a
estrutura com os objetos geométricos de acordo com os limites propostos que servem de base para
absorver as informações geocodificadas. Ao final dessa fase, arquivos contendo toda a malha de
objetos foram gerados.
Após a fase de criação, foi necessária a fase de adequação do banco de dados e importação
das estruturas criadas para o banco de dados, de forma a permitir o armazenamento de informações
espaciais. Essa fase envolveu a criação das tabelas e a importação dos dados dos arquivos para o
banco de dados.
Antes de começar a implementação das funcionalidades, propriamente ditas foi necessário
uma fase de instalação e configuração das ferramentas necessárias pela interação e geração de
resultados, dentre elas se destaca o MapServer Guarani responsável pela geração da interface da
ferramenta.
Somente após a definição dos quadrantes, adequação do banco de dados e à configuração de
todas as ferramentas envolvidas, deu-se início à implementação das rotinas necessárias para a
espacialização propriamente ditas. As rotinas implementadas se dividiram basicamente na seleção e
salvamento dos quadrantes, na interação com o usuário com geração de resultados na interface, na
procura de desembarques e sua posterior espacialização e na localização, exclusão e alteração de
desembarques espacializados.
4.1. Criação dos Quadrantes
4.1.1. Delimitação do Grid
O primeiro processo necessário na implementação foi a criação dos quadrantes. Inicialmente
estava prevista a utilização da ferramenta Spring® para a criação da estrutura, como constava na
primeira versão da modelagem proposta. Nesse particular, houve uma mudança adotando a
ferramenta ArcMap® do pacote de ferramentas ArcGis®. Essa mudança ocorreu basicamente pelo
pouco conhecimento na ferramenta Spring® o que resultou em tentativas frustradas de
implementações. Com a ferramenta ArcMap®, os resultados apareceram de forma mais rápida,
graças ao apoio técnico de pessoal capacitado do Laboratório de Geoprocessamento da UNIVALI.
Tanto os limites, como a resolução da malha de quadrantes, foram definidos através de
reuniões com o responsável pelo projeto de Estatística Pesqueira. Após alguma discussão sobre as
necessidades e as possibilidades para o momento ficou definido que a malha de quadrantes deveria
envolver, além de toda a costa brasileira, também a costa sul da América do Sul e a porção extremo
norte do Brasil, chegando até as Guianas. Quanto a extensão mar adentro, ficou definido que
deveria garantir atingir grandes profundidades. Dessa forma, ficaram definidos os limites de 6º
Norte a -55º Sul, no sentido das latitudes, e da linha de costa continental da América do Sul
extrapolando o limite de 10º Leste, no sentido das longitudes, conforme figura 13. Quanto à
resolução do grid, foi cogitado a hipótese de que os quadrantes tivessem o tamanho de 15’,
entretanto após a verificação de que isso acarretaria em uma estrutura quatro vezes maior e devido
também às dificuldades iniciais para a geração dessa estrutura, ficou definida a resolução de 30’.
Com essa resolução, houve grande diminuição no número de estruturas sem comprometer a
qualidade dos dados ora espacializados. A figura 13 mostra o grid de pontos até os limites
especificados e a linha de costa da América do Sul.
62
Figura 13: Grid de pontos base dos quadrantes
4.1.2. Processo de Criação dos Pontos para Divisão em Quadrantes
Após a definição dos limites, foi necessário um estudo para encontrar a melhor forma de
geração dos objetos que iriam compor a grade. Esses objetos deveriam ser gerados de acordo com
as necessidades para armazenamento em banco de dados, ou seja, como o banco de dados a ser
usado foi o Oracle®, esses objetos deveriam ser criados obedecendo a seqüência de pontos que
representam os seus vértices aceitos pelo banco.
Os pontos que mais tarde deram origem aos objetos, foram gerados inicialmente através de
rotinas na linguagem PHP observando os limites impostos tanto para latitudes como para as
longitudes gravando um arquivo com os valores do vértice mínimo e máximo para cada quadrante.
Isso porque, inicialmente, imaginava-se que os objetos poderiam ser criados somente a partir de
63
dois pontos. Mais tarde, verificou-se que dois pontos não eram suficientes e que deveriam ser
gerados no mínimo quatro pontos e um identificador para possibilitar o fechamento dos objetos e a
posterior extração dos pontos excedentes pela ferramenta ArcMap®. Desse modo, a rotina inicial
necessitou de ajustes para gerar quatro vértices e mais um identificador para cada grupo de vértices.
Essa implementação não foi feita na linguagem PHP, em vez disso, foi utilizado o software Excel®
para ajustar o arquivo que já existia. Essa ferramenta foi utilizada devido a facilidade de ajuste
através de fórmulas simples, a rapidez para alterações e correções e a gravação de arquivo no
formato adequado para posterior utilização no processo de fechamento dos objetos. A figura 14
mostra a tabela com os pontos de cada objeto e ao lado a representação de alguns quadrantes
originados a partir dessa seqüência, situados no Hemisfério Norte.
Long
Lat
-10
-9,5
-9,5
-10
-10,5
-10
-10
-10,5
-11
-10,5
-10,5
-11
-11,5
-11
-11
-11,5
Obj
5
5
5,5
5,5
5
5
5,5
5,5
5
5
5,5
5,5
5
5
5,5
5,5
1
1
1
1
2
2
2
2
3
3
3
3
4
4
4
4
Obj 4
-11,5 / 5,5
-11,5 / 5
Obj 3
Obj 2
-11 / 5,5
-10,5 / 5,5
-11 / 5
-10,5 / 5
Obj 1
-10 / 5,5
-9,5 / 5,5
-9 / 5,5
-10 / 5
-9,5 / 5
Quadrantes
Figura 14: Representação de parte da planilha de pontos e suas representações.
4.1.3. Processo de fechamento dos quadrantes e acerto da linha de costa
O processo de criação dos quadrantes como objetos referenciados, bem como o de extração
dos excedentes, que estavam além da linha de costa da América do Sul, se deu com a utilização do
software ArcMap®. Essa ferramenta faz parte de uma suite de programas para trabalhar com
sistemas de informações geográficas chamado ArcGis®, desenvolvido pela ESRI®. Esse processo
contou com o apoio do Laboratório de Geoprocessamento da UNIVALI, o qual possui pessoas
habilitadas para utilização das ferramentas de geoprocessamento.
O arquivo com a grade de pontos com informações de quatro vértices para cada objeto,
agrupados por um identificador foi importado para o ArcMap®, onde procedeu-se a espacialização
utilizando o sistema de coordenadas WGS 64, mais utilizado para esse tipo de dado. A
espacialização compreendeu em georeferenciar os pontos de acordo com o sistema de coordenadas.
64
O passo seguinte foi utilizar os identificadores dos pontos para agrupar os mesmos, de forma
que identificadores iguais originaram um polígono. Cada polígono foi fechado individualmente,
assim, o arquivo de pontos deu origem a uma grade de polígonos retangulares e espacializados.
Para a extração dos quadrantes desnecessários, foi utilizado um mapa da América Latina
disponibilizado pelo GEBCO - General Bathymetric Chart of the Oceans, o qual estava no mesmo
sistema de coordenadas. O mapa e os quadrantes foram sobrepostos, de forma que todos os
quadrantes que continham intersecção com o mapa foram excluídos (no caso de intersecção total),
ou foram modificados no (caso de intersecção parcial).
Nesse processo houve transformações dos polígonos em pontos, no momento da extração, e
logo após transformados em polígonos novamente pela necessidade de os mesmos serem objetos
fechados para colocação no banco de dados. O resultado do processo foi um conjunto de arquivos
no formato Shapfile identificados com o nome quadrantes. Foram esses arquivos que mais tarde
foram utilizados para importação dos objetos para banco de dados. A figura abaixo representa a
grade de quadrantes após o fechamento e a retirada dos quadrantes desnecessários.
Figura 15: Representação da grade de quadrantes fechados
65
4.1.4. Adequação do Banco de Dados para Armazenamento de Objetos
Espaciais
Para armazenamento de dados espaciais diretamente, o banco de dados Oracle necessita da
habilitação de um pacote de funcionalidades apropriado para trabalhar com objetos espaciais, o
Oracle Spatial. O SIESPE está atualmente rodando em Oracle 8i, o qual provê um conjunto
mínimo de funcionalidades, não suportando totalmente o gerenciamento de objetos espaciais. Para
que fosse possível a espacialização através de polígonos (quadrantes), houve a necessidade da
criação de uma cópia do banco de dados do SIESPE, que foi exportado para a versão 9i, que é uma
versão que suporta totalmente a utilização de objetos espaciais.
Após a atualização do banco, foi criada a tabela chamada quadrante onde as informações
sobre os objetos pudessem ser armazenadas. Essa tabela foi composta inicialmente pelos campos
cd_quadrante, gm_quadrante e obj. O campo cd_quadrante é um seqüencial em formato numérico
que identifica o quadrante armazenado, o campo gm_quadrante é o campo geométrico, responsável
por armazenar as informações relativas aos objetos geográficos e o campo obj também é um
identificador de nome do objeto criado na geração do gride.
4.1.5. Importação dos Dados do Formato Shapefile para o Oracle Spatial
A tarefa de transformação dos dados no formato de arquivo (Shapefile) para a tabela em
banco de dados constituiu em algumas novas etapas e necessitou do auxílio de ferramentas
especializadas para esse tipo de processo como: SHP2SDO, SQLPLUS e SQLLDR.
Todas as ferramentas são fornecidas pela ORACLE e servem para ler o arquivo Shapefile,
gerar arquivos intermediários, preparar o banco para receber os dados daquele arquivo específico e
popular a tabela com os registros oriundos das informações formatadas a partir do arquivo de dados
do Shapefile.
Na figura 16 estão demonstradas as etapas do processo, bem como os resultados gerados por
cada ferramenta em cada etapa. Essa demonstração simplificada poderá ser vista com mais detalhes
no Apêndice A, onde está descrito o processo completo de importação dos dados para banco de
dados.
66
SqlPlus.EXE
Sh2Sdo.EXE
1
SqlLdr.EXE
2
3
Arquivos Shapefile
Quadrante.sql
Quadrante.ctl
Banco de
DadosEspacial
Configurações
Tabela
Quadrante
Objetos
ESpaciais
Figura 16: Representação do processo de importação dos dados para banco de dados
4.2. Instalação dos Programas Necessários ao Desenvolvimento
Para que fosse possível iniciar os procedimentos de implementação do trabalho, foi
necessária uma etapa de instalação e configuração dos programas, os quais deram base à aplicação.
Devido ao propósito desse tipo de aplicação que necessita de funcionalidades de vários aplicativos,
essa tarefa mereceu atenção especial, bem como uma seqüência lógica nos procedimentos de
instalação e configuração.
Os softwares necessários para o perfeito funcionamento da aplicação instalados e
configurados nesse processo foram:
•
Servidor de páginas Web (Web Server) Apache;
•
Servidor interpretador de scripts PHP;
•
Servidor de mapas para Web UMN Mapserver;
•
Biblioteca de conversão de projeções e sistemas de coordenadas Proj 4;
•
Biblioteca de funções PHP/Mapscript;
•
Biblioteca do cliente do Banco de Dados Oracle®;
•
Banco de Dados PostgreSql;
•
Módulo responsável pela interface, Framework Mapserver Guarani.
67
Grande parte dos softwares listados possui licença Open Source e foram adquiridos em suas
distribuições pela Internet. O processo e a seqüência de instalação seguiu publicação do sítio de
Internet Webmapit (Webmapit, 2005), que é voltado a tecnologias de WebMapping. Maiores
detalhes consulte o Apêndice B.
4.3. Implementação do Módulo de Espacialização
O sistema foi gerado utilizando o Framework Mapserver Guarani (Guarani, 2005) para o
qual foi necessário um período de estudos e adequação para entender o funcionamento da
ferramenta, visto que as novas funcionalidades deveriam ser incorporadas à estrutura existente. A
linguagem de programação predominante no Guarani é o JavaScript, o que fez com que a maioria
dos procedimentos para o módulo de espacialização por quadrante também fossem desenvolvidos
nessa linguagem. A seguir serão apresentadas algumas funcionalidades que caracterizam a
ferramenta.
Uma das funcionalidades previstas na modelagem de fundamental importância para o
sucesso da ferramenta foi a montagem de tela. Nessa operação, o sistema prepara a estrutura para a
coleta de informações e aciona os componentes de interação com o usuário.
Com a utilização do Mapserver Guarani o processo de montagem de tela, bem como, a
interface do sistema ficou padronizada e simplificada. Através dessa ferramenta, houve a
possibilidade de perfeita configuração dos temas mais importantes para aplicação, compostos
principalmente pela layer quadrantes e a layer batimetria. São essas duas layer que tornam possível
a identificação aproximada dos locais no momento da determinação dos quadrantes para
espacialização. As configurações para montagem da tela ficam armazenadas no banco de dados do
Mapserver Guarani e durante a inicialização ou a qualquer momento que for necessário atualização,
essas configurações são carregadas pelo procedimento de montagem da tela.
Na montagem da tela da ferramenta são carregados tanto dados do banco Oracle Spatial®,
como também dados de arquivos Shapefile®. Os dados do banco são os objetos que formam o grid
da layer quadrantes. Os dados de arquivos Shapefile são os elementos gráficos que compõem as
outras layers, como o Mapa-Mundi, o Mapa do Brasil e a Carta com as batimetrias. Além das layers
que compõem a área do mapa, durante a montagem da tela, são montados os menus de interação
com o usuário. Os menus da ferramenta são retráteis, ou seja, só aparecem quando solicitados,
possibilitando um melhor aproveitamento útil para a área dos mapas. Os componentes de interação
68
são compostos pela barra de menu, o menu de ferramentas, o menu de trabalho e o menu de
referência. O resultado da montagem de tela, ou tela inicial da ferramenta pode ser observado na
figura abaixo.
Figura 17: Tela principal do sistema, com detalhe para os quadrantes e a batimetria.
4.3.1. Seleção de Quadrantes
O processo de seleção de quadrantes implementado na ferramenta permite que sejam
selecionados os quadrantes desejados coletando as informações na estação cliente para posterior
envio ao servidor, onde os dados são processados. Esse processo envolve uma série de
procedimentos e funções desenvolvidos na linguagem javaScript, usada em todo o processo de
seleção devido à facilidade em trabalhar no lado do cliente sem sobrecarregar o servidor tornando o
processo mais rápido.
A funcionalidade foi incorporada ao sistema na forma de uma opção de menu na interface
do Mapserver Guarani sendo acionada através da seleção no menu ou automaticamente através do
69
menu de procura. A interface do menu possui três campos de informações: desembarque, petrecho e
documento; e as opções através de botões, para inicializar uma espacialização, apagar o último
quadrante selecionado ou todos os quadrantes, e a opção de envio das informações para salvamento.
Figura 18: Opção de menu para seleção de quadrantes
4.3.1.1.
Opção Iniciar
A opção iniciar é a responsável pelo início de uma nova espacialização. Ao selecionar esta
opção na interface, são disparadas funções que preparam o ambiente para receber as informações
considerando o desembarque indicado. O sistema fica capturando os eventos do dispositivo
apontador(mouse), esperando pelo clique em algum local do mapa. A seleção dos quadrantes
acontece a cada clique, para isso a localização em píxel da tela é transformado em coordenadas X e
Y, que é comparada com as dos limites dos quadrantes. Através dessa comparação é possível saber
a qual quadrante pertence o clique. A utilização do clique para a seleção do quadrante torna esse
sistema diferente dos outros existentes, sem a necessidade de digitação das coordenadas.
O sistema possibilita a computação de somente um clique por quadrante, para isso mantém
estruturas de controle, desconsiderando as seleções repetidas (Figura 20). Essa verificação é
realizada considerando os limites do quadrante descobertos para cada clique levando em
consideração a posição da coordenada clicada. Isso é executado no lado cliente através de rotinas
em javaScript para melhorar a performance do sistema.
70
Uma preocupação com o processo de seleção foi o de mostrar ao usuário os locais onde
aconteceram os eventos. Nesse sentido, foram desenvolvidas duas formas de visualização: através
de um elemento indicador na área do mapa e através de uma tabela na aba do menu de trabalho. O
objeto indicador é uma figura com um número seqüencial, inserida dinamicamente a cada clique
válido. A tabela da aba do menu de trabalho possibilita uma entrada a cada clique válido mostrando
o identificador, as coordenadas e os limites do quadrante a que ele pertence. Na figura 19, está
representado a tela do sistema durante um processo de seleção, com a tabela de dados, os
indicadores de seleção dos quadrantes e a mensagem informando os limites do quadrante no
momento da seleção. Na figura 20, é representado um processo de seleção, quando um mesmo
quadrante é selecionado mais de uma vez com a mensagem.
Figura 19: Espacialização com os quadrantes selecionados e a tabela de informação.
71
Figura 20: Mensagem indicando que o quadrante já foi selecionado
4.3.1.2.
Opção Salvar
A opção salvar da ferramenta tem dois propósitos, finalizar o procedimento de seleção de
quadrante voltando o status da ferramenta para normal, e iniciar o processo de salvamento dos
quadrantes selecionados. Esse processo acontece parte no lado cliente, mas a maior parte no lado
servidor.
No lado cliente acontece a atualização das estruturas e preparação dos dados a serem
enviados ao servidor. Havendo quadrantes selecionados, uma tabela para salvamento é escolhida
baseada nas informações de tipo de documento e petrecho. O procedimento de escolha de tabela foi
necessário, devido a existência de um tabela associativa para cada tipo de documento e petrecho
diferente. Após todas as verificações no lado do cliente o processamento passa ao servidor levando
72
o nome da tabela, o array de pontos selecionados, informações do desembarque e a indicação de
salvamento.
No lado do servidor todas as funções foram desenvolvidas em PHP motivado pela facilidade
de trabalho e eficiência para o objetivo do trabalho. Os procedimentos desenvolvidos possuem as
seguintes finalidades: a) receber as variáveis e os pontos convertidos em coordenadas; b) encontrar
o quadrante para cada par de coordenadas; c) inserir os quadrantes encontrados na tabela
determinada; d) atualizar informação de espacialização; e) gerar uma layer dinâmica com as
informações dos quadrantes; e f) retornar a layer para a interface cliente.
Receber as variáveis consiste em tornar possível a utilização das mesmas em todos os
procedimentos da ferramenta, como, por exemplo, a conversão de arrays. Como no lado cliente é
somente feita uma verificação baseada nos limites dos clique, a efetiva descoberta dos
identificadores únicos dos quadrantes é realizada no servidor. Para encontrar os quadrantes que têm
relação a cada par de coordenada, um objeto ponto é criado dinamicamente para ser utilizado em
uma rotina de verificação. Essa rotina consulta o banco de dados verificando a relação do objeto
ponto com os objetos da tabela quadrante, retornando seus identificadores. Na figura 21 está um
trecho de código utilizado para encontrar essa relação.
select
from
where
q.cd_quadrante
quadrante q
SDO_RELATE(q.gm_quadrante,MDSYS.SDO_GEOMETRY(
2001,
8307,
MDSYS.SDO_POINT_TYPE($pontoX,$pontoY,NULL),
NULL,
NULL), 'mask=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE';
Figura 21: Código para seleção de quadrante
Para salvar o quadrante é necessário ter o nome da tabela associativa correspondente,
informações do desembarque e o identificador do quadrante encontrado na tabela de geometrias. A
rotina é repetida até que todos os quadrantes da lista (array) sejam salvos.
A indicação de que o desembarque selecionado foi espacializado é feita na tabela de
desembarque, que é a tabela onde estão registrados todos os desembarques, isso facilita as consultas
a desembarques ainda não espacializados.
Uma nova layer é gerada pelo Mapserver a cada salvamento de um grupo de quadrantes,
plotando os quadrantes que foram salvos no sistema. Essa layer é utilizada no processo de
atualização de tela retornando ao usuário os quadrantes salvos em cor diferente dos demais do grid.
73
Na figura 22, esse procedimento é ilustrado mostrado a layer gerada com os quadrantes que foram
salvos no processo de espacialização em cores diferentes.
Figura 22: Tela atualizada, destacando os quadrantes salvos.
4.3.1.3.
Opção Apagar
A opção apagar foi desenvolvida na ferramenta para possibilitar correções antes do envio
dos quadrantes para salvamento. Esta opção permite alterar uma seleção ainda no lado cliente e
consiste basicamente na deleção dos objetos indicadores da tela, na atualização da tabela de
quadrantes e na atualização das estruturas internas de controle. Essa opção permite apagar o último
quadrante selecionado, podendo ser invocada sequencialmente até apagar todos os quadrantes da
seleção. Outra forma que pode ser utilizada é indicando a intenção de apagar todos, de forma que ao
74
solicitar a remoção, todos os quadrantes selecionados são deletados. Após a deleção é possível a
continuação da seleção dos quadrantes para o desembarque ativo.
4.3.2. Consultar Desembarques Não Espacializados
Durante a fase de implementação foi verificada a necessidade de implementação de formas
de consulta para efetuar a espacialização dos desembarques pretéritos. Esse módulo de consulta
permite listar todos os desembarques de um determinado ano, possibilitando a escolha do
desembarque, através da seleção e mostrando os dados para facilitar a espacialização.
O processo de consulta implementado na ferramenta é dinâmico, isto é, as opções vão sendo
montadas a partir de uma determinada seleção. Isso torna esta funcionalidade eficiente sem, no
entanto ocupar grandes espaços na interface. A técnica utilizada para a atualização dos dados
dinamicamente é denominada AJAX - Asynchronous JavaScript and XML (AJAX, 2005), que
mistura métodos JavaScript com requisições XML. Essa técnica permite que somente as áreas
desejadas da tela sejam atualizadas, sem a atualização de toda a página.
.
Figura 23: Opção de menu para procura de desembarques não espacializados
4.3.2.1.
Processo para consulta
Para o sistema conseguir mostrar os desembarques esperados de acordo com a data, tipo de
documento e petrecho, foi necessário adicionar várias opções selecionáveis á interface. Podem ser
75
consultados dados para um desembarque específico utilizando a opção de digitação ou para um
grupo de desembarques, utilizando as opções de seleção de ano, tipo de documento e petrecho. A
partir, dessas seleções na estação cliente, o sistema automaticamente passa o processamento para o
servidor utilizando requisições através do método AJAX (AJAX, 2005). No servidor são executadas
as seguintes tarefas: a) se não especificado, descobrir tipo de documento e petrecho para o
desembarque enviado; b) tratar as variáveis enviadas, ou descobertas, criando nome da tabela a ser
consultada e os respectivos campos; c) realizar uma consulta parametrizada ao banco de dados; e d)
retornar o resultado da consulta para o ano, tipo de documento e petrecho requisitado, em forma de
lista para a estação cliente. Esse processo é utilizado tanto para a geração das listas de
desembarques como também para a geração das áreas relativas ao mesmo, que acontece a cada
clique em um determinado desembarque da lista no menu de consulta. Para cada área retornada
poderão haver ou não áreas similares.
Através do menu de consulta também é possível inicializar uma espacialização, com a
escolha de um desembarque e da área descritiva do mesmo. Isso é possibilitado porque o sistema
atualiza as variáveis a cada seleção de área descritiva, acionando o menu de espacialização por
quadrante. Dessa forma poderão ser selecionados os quadrantes relativos a área descrita para o
desembarque ativo automaticamente. Após o salvamento da espacialização, é mostrada a nova layer
com o resultado e alternado para o menu de consulta novamente, onde outro desembarque da lista
poderá ser selecionado. A tela de retorno de um desembarque espacializado, bem como, a lista de
desembarques, são mostrados na figura 24.
76
Figura 24: Representação da consulta a desembarque .
4.3.3. Consultar desembarques espacializados
Outra funcionalidade do sistema é a possibilidade de consultar desembarques que já foi
espacializados, mostrando os quadrantes selecionados na espacialização. Isso facilita a conferência
e proporciona a escolha de novos quadrantes em caso de erros.
Com esse módulo de consulta é possível mostrar uma lista de desembarques espacializados
baseando-se em critérios selecionáveis. Os critérios disponíveis desenvolvidos na ferramenta são a
77
digitação do desembarque; a digitação de um intervalo de datas; ou a seleção de um ano, tipo de
documento e petrecho. Para qualquer uma das opções o sistema passa o processamento para o
servidor que realizará uma consulta na tabela quadrante e na tabela desembarque, verificando a
existência de desembarques espacializados. Todos os desembarques encontrados, para os
parâmetros passados,são listados através do método AJAX (AJAX, 2005), na tela do cliente.
Através da seleção de um desembarque na lista, o sistema procede a criação de um layer
plotando os quadrantes relacionados ao mesmo. Essa layer é utilizada no processo de atualização de
tela retornando ao usuário os quadrantes relativos ao desembarque em cor diferente dos demais do
grid. O sistema também fica preparado para uma ação de exclusão ou alteração.
A opção de exclusão e de alteração também são exibidas no módulo de consulta, e
possibilitam excluir totalmente os quadrantes para o desembarque selecionado, através de uma
chamada ao servidor, ou então a alteração alternando para o menu de seleção de quadrantes para
que novos quadrantes sejam selecionados para o desembarque ativo. A figura 25 ilustra esse
processo, onde é mostrado em cor diferente os quadrantes relativos ao desembarque grifado.
78
Figura 25: Consulta a um de um desembarque, mostrando os quadrantes selecionados
4.3.4. Análise de campos descritivos e listagem de áreas diferentes
A funcionalidade de análise de campos descritivos foi implementada em conjunto com a
funcionalidade de consulta a desembarques não espacializados, (localização). Essa funcionalidade
se mostrou desnecessária ou pouco relevante, pelo menos para essa fase do projeto (conforme
considerações), dessa forma foi implementado somente a análise mais básica utilizando a diretiva
do Oracle LIKE nas consultas a áreas similares. A conseqüência disso, é que poucos resultados são
retornados na interface sem muita influência para o processo de espacialização.
A rotina para listagem das “áreas textuais”, ou seja, das áreas descritivas armazenadas para
análise e definição de padrões de procura, foi implementada, mas não houve tempo hábil necessário
79
para que pudesse ser utilizada com segurança em forma de importação automática para os
desembarques.
4.3.5. Integração entre o Sistema SIESPE e o Módulo de Espacialização
Além das formas de procura desenvolvidos para a ferramenta de espacialização, as quais
possibilitam a localização dos desembarques que ainda não foram espacializados, também foi
implementada uma forma de integração entre o Sistema SIESPE e a ferramenta de espacialização.
Essa funcionalidade foi implementada dentro dos módulos do sistema, na linguagem de
programação Java, que é a linguagem utilizada no desenvolvimento do SIESPE. Em cada módulo
de lançamento de área (que é diferente para cada petrecho e tipo de documento) foi incluído um
botão que dispara um procedimento de chamada de Sistema Operacional (no Windows) responsável
pela ativação do módulo. Esse procedimento também seta as variáveis correntes e enviado-as via url
na abertura do módulo de espacialização. Toda vez que o módulo de espacialização é iniciado, é
feita uma verificação para descobrir se a chamada foi feita através do SIESPE. Se positivo, as
variáveis são carregadas e uma seleção de quadrantes pode ser inicializada para o desembarque
enviado. O procedimento ocorre da mesma forma como acontece na seção seleção de quadrantes.
Na figura 26 está representado uma das telas do sistema SIESPE com o botão responsável pelo
envio das informações ao módulo de espacialização. Na figura 27 está o código implementado para
que fosse possível essa integração.
80
Figura 26: Tela do SIESPE mostrando o botão de integração
/* CGAI$PERFORM_ACTION */
/* Performs Action Item Action */
/* Chama o browser padrão com o sistema de quadrantes*/
DECLARE
desemb
petr
doc
atrac
area
VARCHAR2(20);
VARCHAR2(20);
VARCHAR2(20);
VARCHAR2(20);
VARCHAR2(20);
BEGIN
desemb := :dese_cd_dese;
atrac := :atra_cd_atra;
area := :CD_AREA_PESC_ENAR;
doc := 'EN';
petr := 'AS';
IF :TI_PETR_ARRA
petr :=
END IF;
IF :TI_PETR_ARRA
petr :=
END IF;
= 'T' THEN
'AD';
= 'P' THEN
'AP';
host('cmd /c start iexplore.exe http://localhost/quadrante?desemb='||desemb||'atrac='||atrac||'-area='||area||'-doc='||doc||'-petr='||petr||'');
END;
Figura 27: Trecho do código fonte para chamada do módulo de quadrantes.
81
4.4.
Testes e Validação
A etapa de testes e validação teve como objetivo a análise do comportamento dos
procedimentos implementados, colocando a ferramenta a prova. Para essa etapa, um protótipo
completo da ferramenta foi utilizado, verificando durante o processamento o conteúdo das variáveis
e comparando com as ações que a ferramenta deveria executar.
O comportamento da ferramenta foi bom, dentro do esperado. Claro que muitos
procedimentos ainda não estavam completamente funcionais e não puderam ser avaliados em sua
totalidade. Nos testes, ficou evidente que quanto menos atualizações de tela forem necessárias,
melhor o desempenho da ferramenta, por isso a importância de haver muitos procedimentos na
estação cliente.
Outra característica observada foi a funcionalidade das chamadas com a utilização AJAX, as
quais são muito rápidas e possibilitaram um melhor funcionamento da ferramenta nos acessos a
banco de dados para atualização de opções. O uso do AJAX também permitiu que a maioria do
processamento ficasse no lado cliente, ficando para o servidor apenas o essencial para a geração das
listas.
Também foi testada a integração entre o sistema SIESPE e a ferramenta de espacialização.
Nesse ponto, a ferramenta apresentou vários problemas de incompatibilidades, principalmente com
a utilização do Windows XP. Um dos principais problemas foi a incapacidade de envio de variáveis
através da chamada do sistema operacional. Outro problema foi que para cada sistema operacional,
novos módulos de chamada deveriam ser criados, pois as chamadas ao sistema são diferentes. Os
problemas foram sanados e a ferramenta conseguiu apresentar uma perfeita integração utilizando,
no caso dos testes, o Windows XP, que é o sistema mais usado pelos usuários.
Embora a ferramenta não esteja completamente validada, a impressão causada para os
usuários especializados que usaram a ferramenta foi muito boa, superando as expectativas de
facilitar e agilizar o processo de espacialização. Nesse quesito, Muitos detalhes ainda estão sendo
discutidos para que a ferramenta seja realmente funcional e facilite ainda mais as operações de
espacialização. Para completar a validação mais processos de testes serão realizados em conjunto
com os usuários do sistema.
82
5. TRABALHOS FUTUROS
O módulo de geocodificação foi o start inicial para uma série de outras implementações que
poderão ser feitas a partir das tecnologias e dos métodos utilizados neste projeto. Desta forma ficam
algumas recomendações que com certeza melhorarão ainda mais a ferramenta e todo o processo de
geocodificação de dados.
Uma primeira recomendação para trabalhos futuros é a utilização de grid variável e
dinâmico. Isso possibilitaria a escolha de resolução de acordo com o petrecho utilizado e também de
acordo com a precisão dos dados pretendidos no processo de espacialização. Isso acarretaria em
uma montagem estrutural de banco de dados que possibilitasse essas funcionalidades.
Outra recomendação é com respeito à segurança, onde um modulo de segurança poderia ser
implementado nas futuras versões do módulo.
Para melhorar a usabilidade do sistema o mesmo poderia ser convertido para a linguagem
Java, que funciona com as últimas versões do MapServer, e que é a mesma utilizada pelo sistema
SIESPE. Desta forma seriam sanados os problemas de saída do sistema no momento da
espacialização de um novo desembarque.
Uma recomendação importante seria a utilização de técnicas de Inteligência artificial e com
algoritmo genético para a recuperação automatizada das áreas textuais existentes no SIESPE
encontrando automaticamente os quadrantes que mais se encaixam para a área descrita.
De qualquer forma, esse projeto trará muitas outras idéias que poderão se beneficiar do que
já foi desenvolvido, para desenvolver outras importantes funcionalidades.
83
6. CONCLUSÕES
Grande parte da motivação do desenvolvimento deste trabalho foi devido a uma necessidade
existente para a espacialização de dados, especialmente quando não há a possibilidade da digitação
das coordenadas exatas devido a imprecisão de dados. Outra motivação foi o desafio de conseguir
essa espacialização através de uma ferramenta que usa basicamente as funcionalidades Web de um
navegador para possibilitar a espacialização sem a necessidade de digitação das coordenadas.
A primeira dificuldade encontrada foi na determinação e geração dos pontos que deram
origem aos polígonos. Essa dificuldade acarretou na mudança de ferramenta, utilizando a
ferramenta ARcMap® no lugar do Spring que estava previsto. Para geração dos pontos foi de
fundamental importância a ajuda dispensada tanto pelo laboratório de Geoprocessamento quanto
pelo LCA da UNIVALI, assim como do apoio oferecido pelo GEP.
Durante a definição da extensão do grid, não se tinha certeza da definição dos limites “mar
adentro”, por isso o avanço demasiado em relação aos quadrantes em alto mar. As dimensões
adotadas foram definidas através de reuniões com os responsáveis pela estatística pesqueira. Essas
reuniões serviram também para definir a resolução do grid que ao final ficou estabelecido em 30’ x
30’, considerada adequada para os objetivos do módulo de espacialização.
Um problema encontrado foi a necessidade de troca de versão do banco de dados ORACLE
da versão 8i para a versão 9i, pois a 8il não suporta totalmente a utilização de objetos espaciais. A
solução adotada foi a geração de uma réplica do banco de dados para a versão 9i, a qual suporta
totalmente a utilização de objetos espaciais. Como conseqüência dessa mudança, será necessária a
conversão do Siespe para a versão 9i, ou versão 10g, mais atual. A conversão do SIESPE se dará
em etapa futura, visando a implementação definitiva do módulo de geoespacialização.
Quanto a geração de áreas similares para a espacialização automática dos dados pretéritos,
foram impressos alguns relatórios de área, como estava previsto, mas não houve a criação de
critérios devido ás muitas particularidades na digitação das áreas textuais. O processo de montagem
de critérios e implementação de rotina para a decisão sobre as áreas acarretaria em um período
maior de tempo que o previsto. Além disso, teria que ser usado alguma técnica de IA, que não
estava prevista, para executar a mineração e geração dessas áreas. Em conversa com o responsável
pelo sistema de estatística e de acordo com a orientação, esse processo ficou em segundo plano,
84
sendo que poderá ser realizado posteriormente como trabalho futuro, pois a prioridade é a
ferramenta de espacialização.
Durante a implementação verificou-se estar construindo uma ferramenta que agiliza
significativamente o processo de geocodificação de dados. Além disso, a utilização do conceito
Web com uma interface gráfica, limpa e objetiva que possuindo grande potencial para utilização a
distância também vem de encontro a tendência de desenvolvimento atual.
Acredita-se que a ferramenta desenvolvida irá garantir um grande benefício tanto para quem
necessita de uma ferramenta versátil com grandes possibilidades de uso, como também para o
amadurecimento na utilização de meios computacionais para resolução de problemas, com soluções
muitas vezes baratas e de bons resultados.
85
REFERÊNCIAS BIBLIOGRÁFICAS
ABDALLAH, P.R.; BACHA, C. J. C. Evolução da Atividade Pesqueira no Brasil:1960 – 1994.
Passo Fundo-RS: Teor. Evid. Econ. p 9-24. v. 7 .n 13. nov 1999. Disponível em
<http://www.upf.br/cepeac/download/artigo01_13.pdf>. Acessado em: 20 mar. 2005, 13:00:00.
AGENDA 21. Conferência das Nações Unidas para o Meio Ambiente e o Desenvolvimento. Rio
de Janeiro,1992. Protection of the quality and supply of freshwater resources: Application of
Integrated Approaches to the Development, Managment and Use of Water Resources. Cap 18.
Disponível em < http://www.agenda21.org.br>. Acesso em: 15 abr. 2005, 20:30:30.
AJAX - Web mais interactiva. 2005. Disponível em <
http://www.gildot.org/articles/05/10/27/1949215.shtml>
ALVES, A. G. et al. Sistemas de Informação em Gestão Ambiental - Um Caso Aplicado à
Gestão de Recursos Pesqueiros. 2002 In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO,
2002, Itajaí. Congresso Brasileiro de Computação. 2002.
ANP. Agência Nacional do Petróleo. Disponível em
<http://www.bdep.gov.br/webmaps_download.html>
ARAÚJO, L. A. et al. A Importância da Espacialização de Dados para a Atenção Básica em
Saúde Pública. 2004 In:CONGRESSO BRASILEIRO DE CADASTRO TÉCNICO
MULTIFINALITÁRIO, 2004, Florianópolis. UFSC – Universidade Federal de santa Catarina.
Florianópolis. Out-2002.
ArcMap ® – ESRI ® ArcMap 8.4 - ArcGIS Desktop Tolls – Disponível em CD.
CABRAL, R. B.; SPERB, R.M.; TRIPODI, R. Z. Tecnologia Opensource para Rastreamento de
Veículos Monitorados via Satélite. 2002. In: CONGRESSO BRASILEIRO DE
COMPUTAÇÃO,2002, Itajaí. Congresso Brasileiro de Computação. 2002.
CÂMARA, G.; MEDEIROS, J.S. Princípios Básicos em Geoprocessamento. In: ASSAD, E.
D.;SANO E.E.Sistemas de Informações Geográficas: Aplicações na Agricultura. Brasilia:EmbrapaSPI/Embrapa-CPAC, 2001.
CASTAGNETTO, et al. Professional PHP Programando. Ed. Makron Books, São Paulo, 2001.
CERGOLE, M.C; WONGTSCHOWSKI, C. L. DEL B. R (Org) Análise das Principais Pescarias
Comerciais do Sudste-Sul do Brasil. Dinâmica das Frotas Pesqueiras.São Paulo:Evoluir, 2003
Disponível em:<www.cic.ipn.mx/editorial/researchcomp/contenido/vol3/indice.html > . Acessado
em 20 mai 2005.
DUPRÉ, D et al; 2004. Utilização de Software Livre para a Implementação de um Sistema de
Gestão Espacial Visando o Gerenciamento de Informações Corporativas em um Banco de
Dados Espaciais. GISBrasil 2004 in: GISBrasil, 2004.
EPAMIG, Empresa de Pesquisas Agropecuárias de minas Gerais, Introdução a SIG e Modelagem
de Dados, Belo Horizonte – MG. Disponível em <
86
http://www.epamig.br/geosolos/Apostila_PDF/Geo_cap1.pdf>. Acesso em: 15 abr. 2005, 20:30:30
(a)
EPAMIG, Empresa de Pesquisas Agropecuárias de minas Gerais, Introdução a SIG e Modelagem
de Dados, Belo Horizonte – MG. Disponível em <
http://www.epamig.br/geosolos/Apostila_PDF/Geo_cap2.pdf>. Acesso em: 15 abr. 2005, 20:30:30
(b)
EPAMIG, Empresa de Pesquisas Agropecuárias de minas Gerais, Introdução a SIG e Modelagem
de Dados, Belo Horizonte – MG. Disponível em <
http://www.epamig.br/geosolos/Apostila_PDF/Geo_cap3.pdf>. Acesso em: 15 abr. 2005, 20:30:30
(c)
ESTRADA, R. P. D & PAIVA, J. A. C. Integração Semântica e de Dados entre Sistemas de
Informações Geográficas Heterogêneos, Instituto Nacional de Pesquisas Espaciais. Disponível em
< http://www.cartografia.org.br/xxi_cbc/262-SG55.pdf >. Acessado em: 22 jul. 2005.
FAO FISHERIES TECHNICAL PAPER 356. Geographical Information Systems – Applications to
Marine Fisseries. Roma:Fao Fiat Panis, - versão atualizada em 2005.
FARIA, C. M. 2000. Aplicando Técnicas de Geoprocessamento no Estude de Sistema de Produção:
O milho em Minas Gerais. Disponível
em:<http://www.csr.ufmg.br/geoprocessamento/centrorecursos/3cursopub/moreirafaria2000.pdf > .
Acessado em: 25 jul 2005
FAVERET FILHO, P; SIQUEIRA, S.G. Panorama da Pesca Marítima no Mundo e no Brasil.
Brasília-DF. 1997. Ministério do Desenvolvimento, Indústria e Comércio Exterior. Banco Nacional
de Desenvolvimento Econômico e Social – BNDES. Disponível em
<http://www.bndes.gov.br/conhecimento/bnset/rspesca.pdf>. Acessado em: 20 mar. 2005, 11:00:00.
FERREIRA, K.R et al. Arquitetura e Linguagens. Disponível em:
<http://www.dpi.inpe.br/livros/bdados/capitulos.html>. Acesso em: 25 maio 2005
GUARANI. 2005. II Encontro Nacional de Usuários MapServer. Minicuso de Framework
Mapserver Guarani. UNIVALI. 11/2005.
GAMA, A. M. de F. Coord. Agenda 21: Plano de Desenvolvimento Sustentável da Bacia do Rio
Pirapama. Recife-PE:Rio - CPRH/DFID. 2000. 92 p. 2ª ed. ISBN: 85-86592-06-4
GEBCO - General Bathymetric Chart of the Oceans. 1998. Disponível em CD Rom.
GEP. Grupo de Estudos Pesqueiros. Disponível em < http://www.cttmar.univali.br>. Aacessado em
30 mar 2005, 08:00:00
LCA – Laboratório de Computação Aplicada – Contribuição em 25 out. 2005.
MAPSERVER. Página do Mapserver no Brasil. Disponível em:
<http://mapserver.cttmar.univali.br>, acessada em 10 abr 2005.
MATA, F; TORRES, M. Servidor De Mapas con Web-Mapping Orientado a Componentes.
87
MCCURLEY, K.S. Geospatial Mapping and Navigation of the Web. Disponivel em: <
http://www10.org/cdrom/papers/278/> . Acessado em 25 abr 2005.
MENEZES, A. C.; VALE, W. G.; PEZZUTO, P. R. A Utilização da Internet como Meio de
Divulgação da Estatística Pesqueira Industrial de Santa Catarina. In: CBO – Congresso
Brasileir de Oceanografia, 67. , 2004, Itajaí-SC. Anais... Itajaí, 2004. p.212
México, D.F. 2003. Centro de Investigación en Computación – IPN, Instituto Politécnico Nacional
MONTEIRO, S. M. M; CALDASSO, L. P. A Regulação Da Pesca Artesanal No Município Do
Rio Grande/RS. Rio Grande_RS:CEEMA/DCEAC/FURG. Centro de Estudos em Economia e
Meio Ambiente. Projeto de Iniciação Científica.. Disponível em
<http://www2.furg.br/depto/dceac/ceema/liandraartunicamp.pdf>. Acessado em: 10 mar. 2005,
12:00:00.
MOURA, A. C. M. M. Geoprocessamento na Gestão e Planejamento Urbano, Belo Horizonte MG: Ed. da autora, 2003. 294 p. ISBN 85-903669-1-X.
ORACLE, CORPARATION ® - Página Oficial.. Disponível em:<http://www.oracle.com>.
Acessado em: 15 mai 2005.
PAES, J. V. Sistema de Informação Geográfica Aplicado a Maricultura. Trabalho de Conclusão
de Curso. Curso Ciência da Computação. Universidade do Vale do Itajaí-UNIVALI. Nov 1999.
PALMA, L. T. Patrimônio natural e arqueológico em parques: preservação e contribuições
para o desenvolvimento local. Campo Grande-MS:UCDB, 2002. Disponível na Internet em
http://www.ucdb.br/coloquio/arquivos/leonardo.pdf. Acesso em: 15 mar. 2005, 20:10.
PEREZ, et al. Relatório da Reunião Técnica de Ordenamento da Pesca de Arrasto nas Regiões
Sudeste e Sul do Brasil. Pezzuto et al (Org). Notas Técnicas Facimar, Itajaí-SC, v. 5, ed. Especial,
2001.
QUEIROZ, G.R; FERREIRA, K.R. SGBD com extensões espaciais. Disponível em:
<http://www.dpi.inpe.br/livros/bdados/capitulos.html>. Acesso em: 25 maio 2005
REFERENCIAIS CURRICULARES NACIONAIS DA EDUCAÇÃO – ÁREA: Recursos
Pesqueiros. Brasília-DF. 2000. Disponível em <
http://portal.mec.gov.br/setec/arquivos/pdf/recpesqu.pdf>. Acessado em 02 abr 2005, 19:00:00
ROCHA, C. H. B. Geoprocessamento: Tecnologia Transdisciplinar, Juiz de Fora - MG: Ed. Do
Autor, 2000, 220 p.
ROSE, Adriana. Uma avaliação comparativa de alguns sistemas de informação geográfica
aplicado aos transportes. Dissertação de Mestrado. Escola de Engenharia de São Carlos.
Universidade de São Paulo. 2001.
SEAP/PR 2004. Secretaria Especial de Aqüicultura e Pesca da Presidência da República PROJETO POLÍTICO-ESTRUTURAL. Julho de 2004. Brasília/DF. Disponível na Internet em
(http://www.presidencia.gov.br/seap/).
88
SILVA G. K. C, et al. Disponibilização De Serviços Baseados Em Localização Via Web
Services - CPqD—Centro de Pesquisa e Desenvolvimento em Telecomunicações. Disponível em:
<http://www.geoinfo.info/geoinfo2004/papers/6392.pdf >,. Acessado em: 25 jul 2005
SILVA, R. Banco de Dados Geográficos: Uma Análise das Arquiteturas Dual (Sprng) e Integrada
(Oracle Spatial). 2002. Dissertação de Mestrado. Escola Politécnica da Universidade de São Paulo.
SPERB R.M. et al. SAGREH: um sistema de apoio à gestão de recursos hídricos com suporte
espacialbaseado em tecnologias opensource e internet. 2004 In: Gis Brasil 2004 – 10º Show
Internacional de Geotecnologias. São Paulo – sp – 17 a 20 de agosto de 2004. Disponívl em <
http://www.gisbrasil.com.br>.
STEFANES, R. S. Desenvolvimento de Uma Ferramenta de Simulação Discreta com Ênfase na
Smulação de Redes Locais. Trabalho de Conclusão de Curso. Curso Ciência da Computação.
Universidade do Vale do Itajaí-UNIVALI. Nov 2002.
UNIVALI/CTTMar 2003a. Estatística pesqueira industrial de Santa Catarina – Ano 2002.
2003. Meta 1, Relatório Final Ações Prioritárias ao Desenvolvimento da Pesca e Aqüicultura no Sul
do Brasil. Convênio Ministério da Agricultura, Pecuária e Abastecimento (MAPA) / Universidade
do Vale do Itajaí, MA/SARC/003/2000, MAPA/SARC/003/2001,
MAPA/SARC/DENACOOP/176/2002. Pezzuto, P. R (Coord).
UNIVALI/CTTMar. 2003b. Relatório anual da pesca brasileira do bonito listrado Katswonus
pelamis – Ano 2002. Meta 2, Relatório Final Ações Prioritárias ao Desenvolvimento da Pesca e
Aqüicultura no Sul do Brasil, Convênio Ministério da Agricultura, Pecuária e Abastecimento
(MAPA), Universidade do Vale do Itajaí, MA/SARC/003/2000, MAPA/SARC/003/2001,
MAPA/SARC/DENACOOP/176/2002. Pezzuto, P. R (Coordenador).
VIANA, V. M. et al. Utilização Sustentável de Componentes da Diversidade Biológica e
Incentivos-versão final. Grupo de Trabalho Temático em Utilização Sustentável de Componentes
da Diversidade. São Paulo: USP. Disponível na Internet em
http://www.mma.gov.br/port/sbf/chm/doc/gtt4.pdf. Acesso em: 17 mar 2005, 20:00.
Web Mapit, 2005. Web Mapit - Setting up a MapServer development environment in a Windows
box Disponível em: <
http://www.webmapit.com.br/index.php?option=com_content&task=view&id=69&Itemid=65&lan
g=en>. Acessado em: 2005
WebSolutions - Glossário de Termos de Geoprocessamento. Disponível em: <
http://www.websolbi.com.br/empresas/mi/produtos/glossarioOneBodyPage.htm >. Acessado em:
22 jul 2005
89
GLOSSÁRIO
Abundância
Em pesca, o número relativo de indivíduos de cada espécie
de peixe.
Consulta Espacial
Consulta a banco de dados com suporte a objetos espaciais
que utiliza como parâmetros dados relativos a localização do
objeto.
Depleção
Relativo a exaustão ou baixa significativa de determinado
recurso natural (espécie pesqueira).
Defeso
É uma medida de proteção, que proíbe a pesca durante o
período de desova, para evitar que as fêmeas sejam
capturadas durante a desova.
Espacialização
Tornar os dados localizáveis em formato latitude e
longitude.
Explotação
Termo utilizado para as atividades relativas a exploração dos
recursos pesqueiros
Freeware
Software gratuito sem custos de licença.
Linhas Batimétricas
Linhas que representam a medição da profundidade
oceânica.
Máximo Rendimento Sustentável
Termo que também é conhecido como Máxima Captura
Sustentável ou Captura Máxima Sustentável (Maximum
Sustainable Yield – MSY). Refere-se ao limite máximo de
captura de um determinado recurso pesqueiro, de forma a
não comprometer o estoque existente nem o recrutamento de
indivíduos jovens ao estoque adulto. Trata-se de um valor
determinado com base nos melhores dados existentes,
considerando aspectos científicos, biológicos e econômicos
da atividade pesqueira.
(http://www.mma.gov.br/port/sqa/projeto/revizee/glossari.html)
Ordenamento
Estudo profundo e detalhado da atividade pesqueira para
conhecer todas as suas características e que constituirá a
base para a elaboração de um plano cuja finalidade é a
utilização racional dos recursos aproveitando suas
potencialidades com a maximização da produção,
promovendo a proteção do ambiente, visando o
desenvolvimento socioeconômico.
Petrecho
Tipo de Equipamento e técnica utilizada para a pesca,
também chamado de “arte de pesca”.
Plotar
Localizar a posição de um objeto em uma carta ou mapa.
90
Plugin
Bibliotecas básicas de um software instaladas para que a
visualização dos arquivos baseados no mesmo seja provida
dentro do navegador web.
Recurso Pesqueiro
Bens existentes em estado natural que podem ser explorados
de formas diversas, como peixes e animais marinhos.
Sobre-pesca
A atividade de pesca excedeu a capacidade de recuperação
do recurso pesqueiro.
Open Source
Software livre de código aberto.
Tragédia dos comuns
cenário proposto por Garrett Hardin em 1968 – que
descreve que o uso não planejado dos recursos
compartilhados acaba impondo uma lógica destrutiva de
consumo que, inevitavelmente, leva ao esgotamento
completo. Está relacionado ao comportamento egoísta dos
indivíduos que, com a pretensão de maximizar o lucro
individual, geram danos irreparáveis à coletividade.
91
APÊNDICES
APÊNDICE A
PROCESSO DE IMPORTAÇÃO DE DADOS
Após a adequação do banco de dados e a instalação das ferramentas necessárias, procedeu-se a
importação dos dados propriamente dita, que consistiu no seguinte:
O primeiro programa utilizado foi o SHP2SDO, que teve a função de ler arquivos em
formato shapefile e gerar arquivos intermediários para serem utilizados no processo de importação.
O programa foi executado no mesmo diretório onde estavam os shapefiles através do comando a
seguir:
shp2sdo.exe -o quadrante quadrante -g gm_quadrante –i cd_quadrante -d -x (-180,180) -y (-90,90) -s
8307 -t 0.000005 -v
As opções usadas foram:
•
-o
•
quadrante se refere ao nome do shapefile e também da tabela no banco;
•
-g
se refere ao campo com informações geométricas (gm_quadrante);
•
-i
se refere a um campo de indentificador único para a coluna de geometrias
-para converter para o formato objeto relacional;
(cd_quadrante);
•
-d
•
-x e –y
põe os dados em um arquivo de controle gerado pela ferramenta;
identifica os limites para as dimensões X (de -180 a 180º) e Y (de -90 a
90º);
•
-s
refere-se ao SRID, ou seja, sistema de coordenadas utilizado, no caso o
número 8307, refere-se ao “Longitude / Latitude (WGS 84)”, que é largamente
usado, mas poderia ser null.
•
-t
refere-se a tolerância, no caso o 0.0000005 é uma tolerância baixa usada nas
funções de recuperação dos objetos;
•
-v
mostra as mensagens durante o processo.
Dois arquivos foram gerados pelo programa, identificados como quadrante.sql e
quadrante.ctl. O primeiro é um script SQL usado pelo SQL PLUS que tem a finalidade de criar a
tabela para o armazenamento dos dados provenientes do shapefile e instituir uma entrada na tabela
de USER_SDO_GEOM_METADATA, identificando a tabela criada e a coluna de tipo geométrico.
Essa tabela possui informações de metadados de todas as tabelas que o usuário possui. Logo abaixo
é mostrado a parte funcional do script mencionado, onde foi recriado a tabela quadrante com os
campos CD_QUADRANTE, OBJ, e GM_QUADRANTE, sendo o último responsável pelo
armazenamento
da
geometria
dos
objetos.
Logo
após
foi
inserida
na
tabela
USER_SDO_GEOM_METADATA uma entrada com o nome da tabela (quadrante), o nome da
coluna geométrica (gm_quadrante), informações sobre dimensões (Diminfo) e o identificador do
sistema de coordenada associado a geometria (SRID).
???
DROP TABLE QUADRANTE;
CREATE TABLE QUADRANTE (
CD_QUADRANTE
NUMBER(38)
PRIMARY KEY,
OBJ NUMBER,
GM_QUADRANTE
MDSYS.SDO_GEOMETRY);
DELETE FROM USER_SDO_GEOM_METADATA
WHERE TABLE_NAME = 'QUADRANTE' AND COLUMN_NAME = 'GM_QUADRANTE' ;
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('QUADRANTE', 'GM_QUADRANTE',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', -180.000000000, 180.000000000, 0.000000500),
MDSYS.SDO_DIM_ELEMENT('Y', -90.000000000, 90.000000000, 0.000000500)
),
8307);
COMMIT;
O segundo arquivo é um arquivo para ser utilizado com o aplicativo SQLLOADER da
oracle. Esse arquivo possui uma rotina para inserção dos dados diretamente na tabela do banco de
dados, bem como também contém todos os dados formatados utilizando delimitadores para que seja
possível a importação. Abaixo é mostrado o script que foi gerado, onde pode-se observar a
referência a tabela quadrante, os campos da tabela (cd_quadrante,obj e gm_quadrante), de forma
que o campo geometria possui as atribuições de objeto. Também é possível verificar os
delimitadores dos campos e o indicador de próximo registro. Abaixo do cabeçalho estão as
informações a serem importadas com os valores dos campos separados por “|” os arrays de valores
inicializados por “#” e finalizados por “|/”. Como o arquivo é muito extenso está representado os
primeiros três registros e parte do último registro.
LOAD DATA
INFILE *
TRUNCATE
94
CONTINUEIF NEXT(1:1) = '#'
INTO TABLE QUADRANTE
FIELDS TERMINATED BY '|'
TRAILING NULLCOLS (
CD_QUADRANTE INTEGER EXTERNAL,
OBJ,
GM_QUADRANTE COLUMN OBJECT
(
SDO_GTYPE
INTEGER EXTERNAL,
SDO_SRID
INTEGER EXTERNAL,
SDO_ELEM_INFO
VARRAY TERMINATED BY '|/'
(X
FLOAT EXTERNAL),
SDO_ORDINATES
VARRAY TERMINATED BY '|/'
(X
FLOAT EXTERNAL)
)
)
BEGINDATA
1|1|
#3|8307|
#1|3|1|/
#-9,500000|5,000000|-10,000000|5,000000|-10,000000|5,500000|-9,500000|5,500000|
#-9,500000|5,000000|/
2|2|
#3|8307|
#1|3|1|/
#-10,000000|5,000000|-10,500000|5,000000|-10,500000|5,500000|
#-10,000000|5,500000|-10,000000|5,000000|/
3|3|
#3|8307|
#1|3|1|/
#-10,500000|5,000000|-11,000000|5,000000|-11,000000|5,500000|
#-10,500000|5,500000|-10,500000|5,000000|/
.
.
.
10196|14761|
#7|8307|
#1|3|1|9|3|1|95|3|1|113|3|1|3651|3|1|3669|3|1|3683|3|1|3701|3|1|3737|3|1|
#3751|3|1|3767|3|1|3783|3|1|3797|3|1|3819|3|1|3873|3|1|3891|3|1|3911|3|1|
#3931|3|1|3949|3|1|3967|3|1|3989|3|1|4007|3|1|4031|3|1|4047|3|1|4075|3|1|
#4109|3|1|4529|3|1|4543|3|1|/
#-69,500000|-54,998816|-69,500000|-54,999600|-69,500800|-54,999200|
#-69,500000|-54,998816|-69,500000|-54,945400|-69,501700|-54,946300|
#-69,508300|-54,946200|-69,510800|-54,947500|-69,510800|-54,948300|
#-69,510000|-54,948700|-69,508300|-54,948700|-69,507600|-54,949200|
#-69,510100|-54,950400|-69,511600|-54,950400|-69,513300|-54,951200|
#-69,516700|-54,951200|-69,517500|-54,950900|-69,517600|-54,950000|
#-69,518400|-54,949600|-69,520100|-54,950400|-69,521700|-54,950400|
#-69,525000|-54,952100|-69,526600|-54,951200|-69,530000|-54,951200|
#-69,531700|-54,950400|-69,536700|-54,950400|-69,537500|-54,950000|
#-69,537600|-54,946700|-69,536700|-54,946200|-69,521700|-54,946200|
#-69,520000|-54,945400|-69,518300|-54,946200|-69,516700|-54,946300|
#-69,511600|-54,943700|-69,510100|-54,943700|-69,508400|-54,942900|
#-69,506700|-54,942900|-69,505900|-54,942500|-69,505900|-54,941700|
#-69,505000|-54,941200|-69,503300|-54,941200|-69,502500|-54,940800|
#-69,502600|-54,940000|-69,500900|-54,939100|-69,500900|-54,936700|
#-69,500000|-54,936224|-69,500000|-54,945400|-69,505100|-54,901200|
#-69,503400|-54,902100|-69,500000|-54,902100|-69,500000|-54,907050|
#-69,503300|-54,905400|-69,505000|-54,905400|-69,505800|-54,905000|
#-69,505900|-54,901700|-69,505100|-54,901200|-69,975900|-54,705800|
#-69,975900|-54,710800|-69,972700|-54,712500|-69,972600|-54,715800|
#-69,971000|-54,716600|-69,970900|-54,721700|-69,972600|-54,722500|
#-69,972600|-54,728300|-69,970900|-54,729100|-69,970900|-54,732500|
#-69,969300|-54,733300|-69,969300|-54,735800|-69,967600|-54,736600|
#-69,967600|-54,738400|-69,965900|-54,739200|-69,965900|-54,743300|
.
.
.
/
Na seqüência, foi utilizado o programa SQLPLUS para executar o script quadrante.sql,
utilizando o comando: @<path>quadrante.sql. O resultado dessa execução foi a criação da tabela
quadrantes, assim como o registro da coluna geométrica.
Para finalizar o processo de importação foi utilizado o programa SQLLDR. Com os arquivos
no mesmo diretório foi executado o comando: sqlldr <usuário>@<senha>/<banco> quadrante.ctl.
95
Esse programa conecta com o banco de dados e de maneira sincronizada lê as linhas do arquivo
inserindo as mesmas como registros na tabela especificada. O resultado da execução é o enchimento
da tabela quadrante com os dados do arquivo.
Após o processo de importação foi necessária a execução de um comando no aplicativo
SQLPLUS informando a tabela e o campo geométrico. O comando serve para ajustar os objetos
criados ao esquema da versão do banco corrigindo possíveis erros de importação. A rotina é a
seguinte: EXECUTE SDO_MIGRATE.TO_CURRENT('QUADRANTE','GM_QUADRANTE').
Antes da utilização dos dados foi necessário a criação do índice espacial
para que a coluna espacial da tabela quadrantes pudesse ser utilizada nas
consultas.A rotina de criação do índice foi como segue:
CREATE INDEX quadrante_idx ON quadrante(gm_quadrante)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
96
APÊNDICE B
INSTALAÇÃO DE PROGRAMAS
A maior parte desses softwares possuem licença Open Source, podem ser adquiridos
facilmente pela rede mundial de computadores nos sítios oficiais de cada produtora. Dessa forma o
processo de aquisição tanto do software como também da documentação e recomendações é muito
simplificado.
O processo de instalação das ferramentas seguiu as recomendações e a seqüência publicadas
em artigo na página de Internet WEBMAPIT intitulado Preparando um Ambiente de
desenvolvimento Mapserver em uma estação Windows. De acordo com esse artigo a seqüência de
programas a serem instalados inicia pelo Apache, após o PHP, Proj4, Mapserver e PHP/Mapscript.
O servidor web Apache foi baixado do sítio oficial da Apache Software Foundation através
do link http://www.apache.org/dist/httpd/binaries/win32/apache_1.3.33-win32-x86-no_src.exe. A
versão instalada para esse trabalho foi a 1.3.33. O processo de instalação foi relativamente simples,
já que o instalador é um único arquivo executável. Após a instalação houve a necessidade de
algumas configurações que basicamente foram mudanças de diretórios de trabalho, acionamento de
alguns flegs de segurança e inclusão de nome de arquivos que poderão ser interpretados pelo
servidor.
A linguagem de Scripts PHP foi baixada do sítio oficial The PHP Group no link
http://www.php.net/get/php-4.3.11-Win32.zip/from/a/mirror. O pacote de instalação em formato zip
utilizado nesse trabalho foi a versão 4.3.11. Para a instalação, foi utilizado o processo manual que
consistiu primeiro na criação dos diretórios para abrigar os arquivos e na descompactação dos
mesmos como determinados no manual. O passo seguinte foi fazer com que o Windows
reconhecesse o arquivo do PHP php4ts.dll, adicionando o caminho do arquivo á variável de
ambiente %PATH%. Após esses procedimentos foi efetuada a configuração, primeiro copiando o
arquivo php.ini, que contém toda a configuração do PHP, para o diretório onde foi instalado o
Apache. Alguns parâmetros de configuração foram alterados como tempo de execução de scripts,
diretivas de registro, diretório de extensões, acionamento de extensões necessárias como a
biblioteca gráfica GD (php_gd2.dll), biblioteca para clientes http (php_curl.dll), biblioteca de
funções de banco de dados Oracle versão 8i ou superior (php_oci8.dll) e biblioteca de funções de
banco de dados PostGres(php_pgsql.dll). Uma configuração importante após a instalação do PHP
foi a configuração para o mesmo ser executado como “Dynamic Shared Object dentro do Apache,
assim foi preciso adicionar ao arquivo http.conf do apache as seguintes linhas:
LoadModule php4_module "C:/Arquivos de Programas/php4/php4apache.dll" # define o módulo e diretório
AddModule mod_php4.c
AddType application/x-httpd-php .php .phtml .php3
AddType application/x-httpd-php-source .phps
As linhas acima indicam ao apache que o módulo PHP deve ser executado e indica o nome e
caminho necessário, além de mostrar os tipos de arquivos a serem executados.
A Proj4 é uma biblioteca de funções requerida pelo Mapserver. Essa biblioteca permite ao
Mapserver trabalhar com vários tipos de projeções e diferentes sistemas de coordenadas provendo
as conversões necessárias. Para a instalação a biblioteca na versão 4.4.6 foi baixada no formato
pré-compilada do sitio da Open Source Software Remote sensig, através do link
ftp://ftp.remotesensing.org/proj/proj446_win32_bin.zip. O arquivo foi descompactado no diretório
Proj, como especificado no manual. Para a configuração foi necessário a criação de uma entrada na
variável de ambiente %PATH% indicando o caminho dos binários (Proj/bin), assim como a criação
de uma variável de ambiente chamada %PROJ_LIB% contendo o caminho para o diretório
Proj/nad.
O passo seguinte foi a instalação do Mapserver que na realidade é um conjunto de
ferramentas e recursos para a criação de aplicações geográficas em ambiente web. Os arquivos para
a instalação na versão 4.6.0, foram baixados do sítio DM Solutions Group no link
http://www.maptools.org/dl/mapserver-4.6.0-win32-php4.3.11.zip. O pacote de instalação em
formato zip foi extraído no diretório de programas do Windows como especificado no manual.
Logo após foi necessário a descompactação dos arquivos .zip que acompanham a instalação do
Mapserver. Esses arquivos possuem dlls necessárias ao funcionamento adequado do programa
adicionando funcionalidades ao mesmo. Os arquivos foram ECW3.1_DLL.zip - suporte ECW,
gdal-1.2.6.zip - suporte GDAL/OGR, libcurl-7.10.7_dll.zip - necessária para suporte cliente a
WMS/WFS, libpq.zip - suporte PostGIS, pdfdll.zip - suporte a saídas em PDF, xerces_dll.zip processador XML necessário para operações OGC. Para utilizar o Mapserver como CGI foi
necessário copiar o executável mapserv.exe para a pasta CGI-BIN/ do Apache, no meu caso
utilizado mais para teste. Para configuração foi necessário adicionar o caminho da instalação do
mapserver a variável de ambiente do Windows %PATH% e testado o seu funcionamento.
Após a instalação do Mapserver foi providenciada a instalação do PHP/Mapscript, o qual
permite o uso das funcionalidades do Mapserver dentro de scripts do PHP, possibilitando o aumento
98
de potencialidade das ferramentas. A instalação foi muito simples e se resumiu em mover o arquivo
php_mapscript_46.dll do diretório de instalação do Mapserver para o diretório de extensões criado
na instalação do PHP. Feito isso foi necessário a inclusão de uma diretiva no arquivo de
configuração do PHP php.ini, onde na seção extenssões foi adicionada a linha: extension =
php_mapscript_46.dll. Para conferir a instalação foi executado a função de teste do php phpinfo() e
verificado a inclusão dessa biblioteca.
O cliente de Banco de dados ORACLE foi necessário para possibilitar a utilização do
ORACLE SPATIAL com o Mapserver e foi baixado da página de Oracle Technology Network no
link
http://www.oracle.com/technology/software/products/database/oracle10g/index.html.
A
instalação consistiu na descompactação das dlls em um diretório e a criação de uma entrada na
variável %PATH% identificando esse diretório.
Para que fosse possível a utilização do Mapserver Guarani, foi necessário a instalação do
banco de dados PostGreSQL, pois o mesmo necessita do banco para armazenar as suas
configurações. O arquivo de instalação foi baixado da PostgreSQL Global Development Group sob
o link http://www.postgresql.org/ftp/binary/v8.1.0/win32/. A versão utilizada foi a 8.1 e o processo
de instalação foi relativamente simples. Antes da execução da instalação foi necessária a definição
de um usuário do Windows como dono do banco e a definição dos diretórios de instalação. A
instalação em si se resumiu na execução do binário, e na criação de usuário de banco.
O Framework Mapserver Guarani, apesar de ser a última ferramenta a ser instalada, é a
ferramenta que permitiu que as funcionalidades de todas as outras ferramentas fossem usadas. O
Mapserver Guarani que é desenvolvido pelo Laboratório de Computação Aplicada – LCA, da
Universidade do Vale do Itajaí – UNIVALI. Foi disponibilizado diretamente pelos responsáveis
pelo laboratório. O pacote de instalação se resume em três pastas com finalidades distintas, webgis,
configurewebgis e manual. A instalação se resume na transferência dessas três pastas para o
diretório publico de Internet do Apache. Entretanto a configuração do Mapserver Guarani
necessitou de alguns cuidados. Primeiro deve se ter previamente definido os diretórios da aplicação
e principalmente as outras ferramentas, especialmente o banco de dados PostGreSQL deve estar
funcionando corretamente. A pasta webgis é a pasta onde estão todos os arquivos necessários a
aplicação, a pasta configurewebgis é onde estão os arquivos de configuração da aplicação e a pasta
manual é onde há um guia de configuração da ferramenta. Depois de consultado o manual
procedeu-se a configuração da aplicação. A primeira providência foi definir no arquivo de
99
configuração o usuário, senha e banco onde as informações seriam acessadas/gravadas. Logo após
seguiu-se a configuração de acordo com o módulo existente para isso, conectado no banco de
dados. As telas abaixo mostram a tela do programa de configuração com as configurações adotadas
para na aplicação. Na primeira tela (figura 13), foi configuradas as variáveis como nome do projeto,
url padrão, diretórios de includes e shapes, nome e local do mapfile, arquivo mapscript, arquivo de
query, diretório de imagens, tipo de sistema de Georreferenciamento e os extends mínimos e
máximos para a dimensão X e Y.
Na segunda tela foi especificado quais as cartas ou layers que fazem parte da aplicação. As
layers definidas nesta tela se relacionam diretamente com o arquivo mapfile da aplicação, por isso,
os dados têm que estar coerentes. No caso do sistema de quadrantes foram especificadas as layers
mundo, Brasil, municípios, quadrantes e batimetria.
100
Na terceira tela foram definidas as camadas que estão vinculadas aos layers que no caso do
sistema de quadrantes foram uma para cada layer criada. Para cada camada são definidas também
algumas configurações como exemplificado na quarta tela.
101
Outro programa que também foi instalado para desenvolvimento foi o Editplus. Esse
programa é produzido pela ES Computing e foi utilizado em caráter de teste.
102
APÊNDICE C
TABELAS CRIADAS PARA O MODULO
Antes da geração das rotinas do sistema foi necessário também uma etapa de criação das
tabelas necessárias para a espacialização por quadrantes que além da própria tabela quadrante
envolve uma tabela associativa para cada petrecho de cada tipo de documento além das tabelas para
armazenamento de áreas similares.
As tabelas criadas de acordo com o que estava previsto na modelagem estão descritas
na tabela abaixo:
Tabela
Descrição
QUADRANTE
Armazena os quadrantes
QUAD_AREA_PES_ENT_ARR
Associativa entre a tabela quadrante e quad_area_pes_ent_arr
QUAD_AREA_PES_ENT_CER
Associativa entre a tabela quadrante e quad_area_pes_ent_cer
QUAD_AREA_PES_ENT_EF
Associativa entre a tabela quadrante e quad_area_pes_ent_ef
QUAD_AREA_PES_ENT_EMA
Associativa entre a tabela quadrante e quad_area_pes_ent_ema
QUAD_AREA_PES_ENT_ES
Associativa entre a tabela quadrante e quad_area_pesca_ent_es
QUAD_AREA_PES_ENT_VI
Associativa entre a tabela quadrante e quad_area_pesca_ent_vi
QUAD_AREA_PES_MAB_ARM Associativa entre a tabela quadrante e
quad_area_pesca_mab_arm
QUAD_AREA_PES_MAB_ARR Associativa entre a tabela quadrante e
quad_area_pesca_mab_arr
QUAD_AREA_PES_MAB_CER Associativa entre a tabela quadrante e
quad_area_pesca_mab_cer
QUAD_AREA_PES_MAB_EMA Associativa entre a tabela quadrante e
quad_area_pesca_mab_ema
QUAD_AREA_PES_MAB_ESP Associativa entre a tabela quadrante e
quad_area_pesca_mab_esp
QUAD_AREA_PES_MAB_VIV Associativa entre a tabela quadrante e
quad_area_pesca_mab_viv
AREA_SIMILAR
Tabela para armazenamento das áreas similares
QUAD_AREA_SIMILAR
Associativa entre a tabela quadrante e a tabela area_similar
103
APÊNDICE C
DESCRIÇÃO DETALHADA DE ALGUNS PROCESSOS
Iniciar espacialização
Ao selecionar a opção de iniciar uma espacialização na interface são disparadas funções a fim de
preparar o ambiente para receber as infomações, sendo considerado o desembarque ativo. A partir
desse momento o sistema fica capturando os eventos do dispositivo apontador esperando pelo
clique em algum local do mapa. A cada clique efetuado são capturadas as informações de
localização do dispositivo apontador em píxel. Essas informações são convertidas para valores em
coordenadas através de um cálculo que usa a largura e altura da imagem em relação aos valores de
X e Y máximos e mínimos de mapa, chegando ao valor aproximado em coordenada. Posteriormente
é verificado se o a coordenada corresponde a algum quadrante já selecionado. Se pertencer, então o
clique é desconsiderado e uma mensagem é emitida, enquanto o sistema fica aguardando por um
novo clique. Se o valor da coordenada não pertence a nenhum quadrante selecionado anteriormente,
então é disparado um procedimento para descobrir a qual quadrante pertence o clique. O quadrante
é descoberto delimitando limites mínimos e máximos possíveis de se encaixar ao clique, então esses
limites são guardados para futura verificação. O próximo passo é mostrar ao usuário o local onde
aconteceu o evento clique, para isso foi desenvolvido um procedimento que adiciona um elemento
demarcador à interface com o número do clique, facilitando o acompanhamento do processo. Outra
característica desenvolvida, foi a criação de uma tabela visível na aba de menu e a cada novo clique
válido é adicionada entrada nessa tabela mostrando o identificador, as coordenadas e os limites do
quadrante a que ele pertence. Finalizando o evento clique os valores reais da coordenada clicada
também são guardados para uso posterior. Esse processo se repete até que seja solicitado o
salvamento, quando as informações são enviadas ao servidor e a interface atualizada.
Finalizar espacialização e salvar
Outra opção do menu espacializar é a de salvar espacialização. No momento que essa opção
é escolhida, encerra-se a captura dos quadrantes, sendo invocado o procedimento de gravação dos
quadrantes selecionados pelo usuário. Essa funcionalidade poderá ser invocada a qualquer instante
dede que haja quadrantes selecionados. Algumas considerações são necessárias para essa
funcionalidade, pois como já mencionado, existe uma tabela associativa diferente para cada
petrecho de cada tipo de documento, dessa forma, antes de enviar a seqüência de pontos
104
selecionados, foi necessária a implementação de uma rotina que descubrisse qual tabela salvar. Essa
rotina é camada toda vez que houver pontos selecionados e leva em consideração informações
passadas ou coletadas de tipo de documento e petrecho para gerar o nome da tabela que será
enviado ao servidor. Devido a diferença entre as estruturas de arrays da linguagem javascript e da
linguagem PHP, o array contendo os pontos selecionados é passa por uma conversão antes de ser
enviado de forma que o PHP consiga interpretar. Após todas as verificaões no lado do cliente o
processamento passa o servidor levando o nome da tabela, o array de pontos selecionados e a
indicação de salvamento.
No lado do servidor todas as funções foram desenvolvidas em PHP motivado pela facilidade
de trabalho, mais que qualquer outra coisa. A seqüência para o salvamento dos quadrantes
selecionados é a seguinte: uma função recebe o array de quadrantes converte novamente de forma
que possa ser utilizado. Logo após esse array é percorrido e para cada coordenada X e Y contidas
no array, um procedimento para encontrar o quadrante correspondente em banco de dados é
invocado. O quadrante é descoberto através de uma consulta na tabela quadrante invocando o oracle
spatial através da montagem de um objeto do tipo ponto com as coordenadas X e Y e verificando o
relacionamento desse objeto com os objetos contidos na coluna geométrica (gm_quadrante) da
tabela.
$sql= "select
from
where
q.cd_quadrante
quadrante q
SDO_RELATE(q.gm_quadrante,MDSYS.SDO_GEOMETRY(
2001,
8307,
MDSYS.SDO_POINT_TYPE($pontoX,$pontoY,NULL),
NULL,
NULL), 'mask=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE'";
Assim que o quadrante é encontrado o procedimento de salvamento é invocado levando em
consideração o identificador do quadrante e o nome da tabela e os outros campos chaves. A rotina
de salvamento insere na tabela requerida um registro com o código do desembarque, código da área
código do atracadouro e a identificação do quadrante selecionado. Essa rotina se repete até que
todos os quadrantes do array sejam salvos. Após a execução desse procedimento é salvo uma
indicação de que o desembarque já foi espacializado na tabela de desembarques, isso facilita futuras
consultas já que essa é a única tabela que concentra todos os desembarques sem considerar os
petrechos. Após o salvamento das informações foi necessário implementar um retorno das
informações para o cliente, é nesse momento que as funcionalidades do mapserver são invocadas
para gerar uma nova camada contendo os quadrantes que foram salvos.
105
APÊNDICE D
ARTIGO CIENTÍFICO
106