PROJETO DE INTERFACES PARA ÁLGEBRA DE MAPAS EM...
121
MINISTÉRIO DA CIÊNCIA E TECNOLOGIA INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS INPE-9307-TDI/820 PROJETO DE INTERFACES PARA ÁLGEBRA DE MAPAS EM GEOPROCESSAMENTO NO AMBIENTE SPRING Ivan Soares de Lucena Dissertação de Mestrado em Sensoriamento Remoto, orientada pelo Dr. Gilberto Câmara, aprovada em 14 de setembro de 1998. INPE São José dos Campos 2002
Transcript of PROJETO DE INTERFACES PARA ÁLGEBRA DE MAPAS EM...
MINISTÉRIO DA CIÊNCIA E TECNOLOGIAINSTITUTO NACIONAL DE PESQUISAS ESPACIAIS
INPE-9307-TDI/820
PROJETO DE INTERFACES PARA ÁLGEBRA DE MAPAS EMGEOPROCESSAMENTO NO AMBIENTE SPRING
Ivan Soares de Lucena
Dissertação de Mestrado em Sensoriamento Remoto, orientada pelo Dr. GilbertoCâmara, aprovada em 14 de setembro de 1998.
INPESão José dos Campos
2002
681.322.0 : 528.711.7
LUCENA, I. S. Projeto de interfaces para álgebra de mapas em geopro- cessamento no ambiente SPRING / I. S. Lucena – São José dos Campos: INPE, 1998. 126p. – (INPE-9307-TDI/820).
1.Álgebra. 2.Mapa. 3.Interface usuário/computador. 4.Geoprocessamento. 5.Sistemas de Informação Geográfica. I.Título.
Aprovado pela Banca Examinadora em
cumprimento a requisito exigido para a
obtenção do Título de Mestre em
Computação Aplicada.
Candidato: Ivan Soares de Lucena
São José dos Campos, 14 de setembro de 1998.
"Quem dentre vós é sábio e entendido? Mostrepelo seu bom procedimento as suas obras emmansidão de sabedoria. Mas, se tendesamargo ciúme e sentimento faccioso em vossocoração, não vos glorieis, nem mintais contraa verdade. Essa não é a sabedoria que vem doalto, mas é terrena, animal e diabólica.Porque onde há ciúme e sentimento faccioso,aí há confusão e toda obra má. Mas asabedoria que vem do alto é, primeiramente,pura, depois pacífica, moderada, tratável,cheia de misericórdia e de bons frutos, semparcialidade, e sem hipocrisia."
da Epístola de São Tiago
À minha esposa Dilma e aos nossosfilhos Alexandre e João Victor
AGRADECIMENTOS
Primeiramente agradeço a Deus, orientador de minha vida, que me faz vencer
os desafios. Que a Sua referência seja sempre presente eu meu coração.
Ao professor, orientador e amigo Dr. Gilberto Câmara pela orientação neste
trabalho e pelo compartilhar da sua experiência em Geoprocessamento e desenvolvimento
de tecnologia.
Agradeço à toda a chefia do Centro Nacional de Pesquisa Tecnológica em
Informática para Agricultura, CNPTIA, pelo apoio no desenvolvimento deste trabalho.
Aos colegas do CNPTIA e do Divisão de Processamento de Imagens do
INPE pela troca de informações técnicas valiosas, pelo companheirismo, incentivo e
solidariedade.
A compreensão da família, minha esposa e meus dois filhos, que puderam
entender os momentos de ausência, ou mesmo quando presente, diante da fria máquina do
computador, não pude dar-lhes muita atenção.
RESUMO
Os Sistemas de Informação Geográfica (SIG) oferecem procedimentos de
manipulação de mapas para que o usuário possa expressar modelos de análise espacial.
Estes procedimentos, denominados Álgebra de Mapas, usualmente são expressos em
linguagens, que permitem ordenar seqüências de transformações do dados geográficos para
gerar novos mapas a partir dos mapas existentes. O Sistema de Processamento de
Informações Georeferenciadas (SPRING), desenvolvido pelo Instituto Nacional de
Pesquisas Espaciais (INPE), possui uma linguagem para Álgebra de Mapas denominada:
Linguagem Espacial para Geoprocessamento Algébrico (LEGAL). Apesar do grande poder
expressivo de uma linguagens como LEGAL, seu uso requer noções de fundamentos de
programação, competência nem sempre disponível entre os especialistas em
Geoprocessamento. Como alternativa ao uso de LEGAL, este trabalho desenvolve uma
interface amigável para Álgebra de Mapas no ambiente SPRING, denominada Álgebra de
Mapas por Objetos (AMO), que permite a geração de programas em LEGAL através de
diagramas de fluxo. O processo de definição dos requisitos para o desenvolvimento de
AMO inclui uma revisão dos conceitos de Geoprocessamento, modelagem de dados
geográficos, análise espacial, álgebra de mapas em LEGAL e a revisão de interfaces para
álgebra de mapas existentes no mercado ou propostas na literatura. A interface AMO
representa uma contribuição para o uso da tecnologia SPRING em projetos ambientais e
de agropecuária, por fornecer a uma vasta gama de usuários uma ferramenta de fácil
utilização para expressar problemas complexos de análise espacial. Adicionalmente, o
projeto da interface AMO foi concebido com base em noções gerais de
Geoprocessamento, podendo deste modo ser estendido para outros SIG.
DESIGN OF MAP ALGEBRA INTERFACE FORGEOPROCESSING AT SPRING ENVIRONMENT
ABSTRACT
Most implementations of Geographical Information Systems (GIS) include
procedures, which allow the user to express complex spatial analysis models. These
procedures are refereed to as Map Algebra, and are usually expressed by a language, which
provides operations that generate new maps from an existing ones. The GIS system
developed by National Institute of Space Research (INPE), includes the a spatial algebra
language, whose use requires notions of programming languages. Such knowledge is not
always available in the GIS user community. As an alternative to direct programming using
this programming language, we have developed a friendly user interface for expressing Map
Algebra programs, called (AMO) that means Map Algebra with Objects. AMO uses the
flow diagram paradigm, which is a natural way of expressing spatial analysis problems, and
enables the automatic generation of Map Algebra programs. In order to develop AMO, we
have analyzed different alternatives for Map Algebra interfaces, including programming
languages, forms and flow diagrams. AMO is an improvement of INPE´s GIS technology,
as it allows non-expert users a straightforward way of expressing complex spatial analysis
problem. Finally, the AMO design has been based on general principles of GIS, and the
interface can be extended for use with other systems.
SUMÁRIO
LISTA DE FIGURAS Pág.LISTA DE TABELASLISTA DE SIGLAS E ABREVIATURAS
CAPÍTULO 1 – INTRODUÇÃO 191.1 – Objetivos ......................................................................................................................... 201.2 – Organização .................................................................................................................... 211.3 – Contribuições ................................................................................................................. 22
CAPÍTULO 2 - CONCEITOS DE GEOPROCESSAMENTO 232.1 - Modelagem de Dados Geográficos .............................................................................. 232.1.1 - Universo Conceitual .................................................................................................... 232.1.2 - Universo de Representação ........................................................................................ 252.2 - Estrutura de um Banco de Dados Geográficos ......................................................... 282.2.1 - Instanciação do modelo ............................................................................................. 292.3 - Análise Espacial .............................................................................................................. 302.3.1 - Operações sobre Campos .......................................................................................... 302.3.2 - Operações sobre Objetos ........................................................................................... 312.3.3 - Operações entre Campos e Objetos ......................................................................... 322.3.4 - Relações de Operadores ............................................................................................. 33
CAPÍTULO 3 - CONCEITOS DE GEOPROCESSAMENTO 353.1 - Classificação de LEGAL ............................................................................................... 353.2 - Características de LEGAL ............................................................................................ 353.2.1 - Classes do modelo de dados e sua representação em LEGAL ............................ 363.2.2 - Seções de um Programa em LEGAL ....................................................................... 363.3 - Classificação de Operadores em LEGAL ................................................................... 443.3.1 - Operadores entre Geo-campos ................................................................................. 443.4 - Resumo das Operações sobre Geo-campos ............................................................... 54
CAPÍTULO 4 - INTERFACES PARA ÁLGEBRA DE MAPAS 554.1 - Projeto de Interfaces Usuário-Computador ............................................................... 554.2 - Paradigmas de Interfaces para Álgebra de Mapas .................................................... 564.2.1 - Linhas de Comandos e Linguagens de Programação ............................................ 56
4.2.2 - Menus e Formulários .................................................................................................. 604.2.3 - Interfaces por Manipulação Direta ........................................................................... 634.2.4 - Resumo ......................................................................................................................... 704.3 - Requisitos para o projeto de Interface para Álgebra de Mapas .............................. 724.3.1 - Requisitos Gerais ......................................................................................................... 734.3.2 - Requisitos Específicos sobre Álgebra de Mapas .................................................... 744.3.3 - Requisitos Específicos para o SPRING .................................................................. 75
CAPÍTULO 5 - INTERFACES AMO 775.1 - Descrição Geral .............................................................................................................. 775.1.1 - Paradigmas Escolhidos ............................................................................................... 775.1.2 - Material e Método ....................................................................................................... 785.2 - Estrutura de AMO ......................................................................................................... 805.2.1 - Tela Principal ............................................................................................................... 815.2.2 - Região de Seleção ........................................................................................................ 835.2.3 - Região de Edição e Visualização ............................................................................... 855.2.4 - Funções Gerais de AMO (Barra de ferramentas e menus) ................................... 875.3 - Características Visuais .................................................................................................... 915.4 - Modelo de Interação ...................................................................................................... 925.4.1 - Conexão de Comandos e Variáveis .......................................................................... 935.5 - Modelo de Objetos ......................................................................................................... 935.6 - Exemplos ......................................................................................................................... 94
CAPÍTULO 6 – TUTORIAL DE AMO 976.1 - Definição do Problema .................................................................................................. 976.1.1 - Metodologia do ZEE .................................................................................................. 986.2 - Elaboração do Modelo de Análise no SIG ................................................................. 1006.3 - Tutorial de AMO ............................................................................................................ 1016.4 - Resultados ........................................................................................................................ 1136.5 - Análise dos Resultados .................................................................................................. 113
CAPÍTULO - CONCLUSÕES 1157.1 - Melhorias Propostas e Direções Futuras .................................................................... 1157.2 – Contribuições ................................................................................................................. 116
REFERÊCIAS BIBLIOGRÁFICAS 117
APÊNDICE 121
LISTA DE FIGURAS
Pág.2.1 Componentes básicos da representação vetorial: Ponto, Linha e Região ........ 252.2 Estrutura Topológica ............................................................................................... 262.3 Exemplo de Sensoreamento Remoto .................................................................... 272.4 Exemplo de Mapa Temático ................................................................................... 272.5 Exemplo de definição do Esquema Conceitual ................................................... 292.6 Representação ............................................................................................................ 303.1 Três seções de um programa em LEGAL ............................................................ 373.2 Sintaxe da declaração de Planos de Informação .................................................. 383.3 Sintaxe da declaração de tabelas de transformações ............................................ 383.4 Sintaxe da Instanciação de Planos de Informação ............................................... 393.5 Sintaxe da instanciação de Tabelas ......................................................................... 393.6 Sintaxe geral para Operações em LEGAL .............................................................. 413.7 Sintaxe de Operações sobre IMAGEM ................................................................... 413.8 Sintaxe de Operações sobre NUMERICO .............................................................. 423.9 Sintaxe para Operações sobre TEMATICO ............................................................ 423.10 Sintaxe de Expressões Condicional ....................................................................... 433.11 Sintaxe de Expressões Booleana ............................................................................ 443.12 Classes de Operadores ............................................................................................. 453.13 Operação de Fatiamento ......................................................................................... 463.14 Operação de Ponderação ........................................................................................ 473.15 Operação Matamática .............................................................................................. 504.1 Processo de desenvolvimento de Projeto de Interfaces ..................................... 564.2 Exemplo de operação de análise no Arc/Info ..................................................... 584.3 Interface por Linha de Comandos do OSUMAP ................................................ 594.4 Interface de operações aritméticas no SPRING .................................................. 604.5 Formulário do operador “escalar” do IDRISIW ................................................. 624.6 Formulário do MGE Intergraph ............................................................................ 634.7 Avaliação de Interfaces por Manipulação Direta ................................................. 644.8 Diagrama de Fluxo em Análise Espacial ............................................................... 654.9 Interface Baseada em Pilhas .................................................................................... 674.10 Ambiente de Análise Espacial do Grassland ........................................................ 68
4.11 Diagrama de Fluxo do Model Maker .................................................................... 694.12 Operador de Buffer no VFQL ............................................................................... 704.13 Virtual Functional Query Language ...................................................................... 705.1 Exemplo de conexão com ODBC via Tclodbc ................................................... 805.2 Estrutura hierárquica da interface de AMO ......................................................... 815.3 Tela Principal de AMO ............................................................................................ 825.4 Região de Seleção em AMO .................................................................................... 835.5 Seleção de Dados em AMO .................................................................................... 845.6 Região de Seleção de Operadores em AMO ........................................................ 855.7 Funções de encadeamento de conectores ............................................................. 905.8 Janela de Diálogo para Configuração de Variáveis .............................................. 905.9 Janela de Diálogo para Configuração de Comandos ........................................... 915.10 Ícone de uma Variável em AMO ........................................................................... 925.11 Modelo de Objetos de AMO ................................................................................. 945.12 Exemplo de procedimento em AMO .................................................................... 955.13 Exemplo de tabela de ponderação em AMO ....................................................... 956.1 Modelo para estimar a Vulnerabilidade Natural à Erosão ................................. 1006.2 Seleção de Banco de Dados .................................................................................... 1026.3 Seleção de Projeto .................................................................................................... 1026.4 Seleção de Dados ...................................................................................................... 1036.5 Instanciação de Variável .......................................................................................... 1036.6 Lista de Hierárquica de Operadores ...................................................................... 1046.7 Criação de um Comando ......................................................................................... 1056.8 Criação de Conexões ................................................................................................ 1056.9 Fluxo de Dados ......................................................................................................... 1066.10 Criação de Novas Varáveis ...................................................................................... 1066.11 Formulário de Configuração de Variáveis ............................................................ 1076.12 Dados do Novo Plano de Informação .................................................................. 1076.13 Janela de Configuração de Comandos ................................................................... 1086.14 Configuração de Tabelas .......................................................................................... 1086.15 Inclusão da Média Zonal ......................................................................................... 1116.16 Configuração de Expressão Matemática ............................................................... 1116.17 Motodologia ZEE desenvolvido em AMO .......................................................... 113
LISTA DE TABELAS
Pág. 2.1 Operações sobre Campos e Objetos ..................................................................... 33 3.1 Exemplo: “Regras para Aptidão Agrícola” ........................................................... 49 3.2 Relação de Operadores sobre Geo-campos ......................................................... 54 3.2 Resumo de Operadores de álgebra de Mapas ...................................................... 66 6.1 Fatores que influenciam na erosão ........................................................................ 99 6.2 Tabela de Ponderação para Solos .......................................................................... 109 6.3 Tabela de Ponderação para Geologia ................................................................... 109 6.4 Tabela de Ponderação para Vegetação ................................................................. 109 6.5 Tabela de Ponderação para Geomorfologia ........................................................ 110 6.6 Tabela de Fatiamento de Vulnerabilidade ............................................................ 112
LISTA DE SIGLAS E ABREVIATURAS
SIG - Sistema de Informação geográfica
LEGAL - Linguagem Espaço Geográfica baseada em Álgebra
SPRING - Sistema de Processamento de Informações Georeferenciadas
AMO - Ambiente de Álgebra de Mapas Orientada por Objetos
IUC - Interface Usuário Computador
SQL - Structured Query Language
ODBC - Open Data Base Connection
GUI - Graphical User Interface (Interface Gráfica com o Usuário)
ZEE - Zoneamento Ecológico Econômico
19
CAPÍTULO 1
INTRODUÇÃO
A partir do início da década de 90, ocorreu uma grande difusão do Geoprocessamento.
Antes confinada a laboratórios com altos custos de instalação e manutenção, e
necessitando de pessoal altamente especializado e treinado no uso de suas ferramentas, esta
tecnologia hoje está ao alcance de qualquer usuário de computador e vem sendo utilizada
nos mais variados tipos de aplicações.
Na medida em que equipamentos de baixo custo se tornaram suficientemente capazes para
processar e armazenar, com rapidez e eficiência, grandes volumes de dados na forma de
mapas, imagens e bancos de dados censitários, verifica-se uma mudança no perfil do uso de
sistemas informatizados de Geoprocessamento. Ao longo do final da década de 80 e início
da década de 90 estes sistemas, que antes estavam baseados em computadores de grande e
médio porte, e que só podiam ser adquiridos por instituições e empresas com grande
disponibilidade de recursos, foram sendo substituídos por versões para computador
pessoal.
Os custos com mão-de-obra para operação dos sistemas anteriores eram altos, não
somente devido à complexidade dos problemas envolvidos em análise geográfica, mas
também pela dificuldade de interação entre o usuário e o sistema. Este fator influencia
significativamente a exigência de treinamento e especialização, não somente na tecnologia
de Geoprocessamento, mas principalmente na habilitação para operar sistemas específicos.
No contexto do desenvolvimento tecnológico de Geoprocessamento no Brasil, este
trabalho está diretamente ligado ao sistema Sistema de Processamento de Informações
Georeferenciadas (SPRING) (Câmara et al., 1996), um software para Geoprocessamento
que oferece um conjunto integrado de ferramentas para processamento de informações
geográficas, com modelagem digital de terreno, análise espacial e tratamento de imagens de
satélite. Os objetivos do sistema SPRING são (Câmara et al., 1993):
20
• Integrar as tecnologias de Sensoriamento Remoto e Sistemas de Informação
Geográfica.
• Utilizar modelo de dados orientado-por-objetos, que melhor reflete a metodologia de
trabalho de estudos ambientais e cadastrais.
• Fornecer ao usuário um ambiente interativo para visualizar, manipular e editar
imagens e dados geográficos.
O processo de disseminação do SPRING vem se acelerando muito a partir do lançamento
de sua versão para Microsoft Windows e pelo livre acesso através da Internet. Desta forma,
novos usuários, de perfis diversos, passaram a utilizar o sistema para os mais variados fins.
Isto tem exigido que sua interface seja o mais amigável possível, até mesmo nos
procedimentos mais complexos, tais como a manipulação de dados geográficos (álgebra de
mapas) envolvidos em análise espacial.
Neste contexto se insere o presente trabalho, ao auxiliar na disseminação da tecnologia de
Geoprocessamento no ambiente do SPRING, oferecendo uma ferramenta interativa e
amigável para o estabelecimento de metodologias de análise espacial.
1.1 Objetivos
O objetivo deste trabalho é desenvolver um sistema baseado em interface de manipulação
direta, que permita ao usuário do SPRING a fácil expressão de seu conhecimento em
metodologias de análise espacial. Este sistema irá traduzir esta metodologia, ou
conhecimento, para programas na linguagem Linguagem Espaço Geográfica baseada em
Álgebra (LEGAL), utilizada pelo sistema SPRING.
LEGAL é a linguagem proposta por Câmara (1995) com o objetivo de prover um ambiente
geral para análise geográfica, incluindo operações de manipulação, consulta espacial e
apresentação. Para isto vem sendo desenvolvido um interpretador de LEGAL
adicionalmente ao produto SPRING o que já tem mostrado resultados bastante favoráveis
(Barbosa, 1998).
A linguagem de programação é um dos possíveis modos de interação entre o usuário e o
sistema. Utilizando um editor de texto, o usuário escreve os programas seguindo a
21
gramática da linguagem, descrevendo todos os procedimentos para execução de sua
metodologia de análise e, em seguida, este programa é submetido ao interpretador da
linguagem no SIG o qual ira checar a validade das expressões e executar o procedimento.
Como muitos problemas em análise espacial podem ser expressos através de uma
metodologia de trabalho que define procedimentos sucessivos de transformação dos dados,
é natural expressar esta metodologia através de diagramas de fluxos (Maguire e Goodchild,
1991). Deste modo, o desenvolvimento de uma interface gráfica baseada em diagrama de
fluxo, será útil tanto para usuários iniciantes quanto para ilustrar graficamente
procedimentos complexos.
Para atender esta demanda por uma interface amigável para álgebra de mapas no ambiente
SPRING, projetamos e desenvolvemos um sistema denominamos Álgebra de Mapas por
Objetos (AMO). Utilizamos a abordagem orientada por objetos como forma de enriquecer
semanticamente os elementos de um diagramas de fluxo, para melhorar a interação do
usuário experiente com o sistema, aumentar sua produtividade e oferecer recursos de
documentação de seus modelos, bem como aumentar a velocidade de aprendizado de
usuários novatos.
O processo de definição dos requisitos para o desenvolvimento de AMO inclui uma
revisão dos conceitos de Geoprocessamento, modelagem de dados geográficos, análise
espacial, álgebra de mapas em LEGAL e a revisão de interfaces para álgebra de mapas
existentes no mercado ou proposta na literatura, como será apresentado neste trabalho.
1.2 Organização
O trabalho está organizado como segue: O Capítulo 2 apresenta conceitos gerais de
Geoprocessamento, o Capítulo 3 apresenta álgebra de mapas no contexto do software
SPRING na linguagem LEGAL. O Capítulo 4 discute interfaces usuário-computador para
álgebra de mapas, revisa trabalhos existentes e estabelece um conjunto de requisitos para o
desenvolvimento do projeto de interface. O Capítulo 5 apresenta o AMO. O Capítulo 6
apresenta os resultados atingidos com AMO. O Capítulo 7 apresenta as conclusões deste
trabalho.
22
1.3 Contribuições
Este trabalho traz como contribuição um novo sistema (AMO) que gera programas em
LEGAL, baseado no paradigma de interfaces por diagrama de fluxo de dados, com o
objetivo de apoiar a difusão da tecnologia de Geoprocessamento ao atender aos critérios de
qualidade de software: “usabilidade” e “facilidade de aprendizado” (I.S.O., 1991).
Este sistema representa um avanço significativo para o uso da tecnologia SPRING em
projetos ambientais e de agropecuária, por fornecer a uma vasta gama de usuários uma
ferramenta de fácil utilização para expressar problemas complexos de análise espacial.
Adicionalmente, o projeto da interface AMO foi concebido com base em noções gerais de
Geoprocessamento, podendo deste modo ser estendido para outros SIGs.
23
CAPÍTULO 2
CONCEITOS DE GEOPROCESSAMENTO
Para iniciar um projeto de interface é necessário conhecer bem o domínio de sua aplicação.
Neste sentido, este Capítulo revisa alguns conceitos importante de Geoprocessamento no
ambiente do SPRING tais como a modelagem de dados geográficos, estrutura do banco de
dados geográficos e noções de análise espacial em SIG.
2.1 Modelagem de Dados GeográficosUm modelo é uma construção artificial na qual partes de um domínio (domínio origem)
são representadas em outro domínio (domínio destino) (Worboys, 1995). O propósito da
modelagem é simplificar e abstrair o entendimento do domínio, ou universo, de origem e
representá-lo sob a forma de expressão do domínio, ou universo, de destino. No processo
de modelagem de dados geográficos, relacionaremos estes dois universos:
• Universo Conceitual, que contém uma definição matemática formal das entidades do
mundo real, consideradas relevantes para o estudo;
• Universo de Representação, onde as diversas entidades formais são mapeadas para
representações geométricas.
2.1.1 Universo Conceitual
“O dado geográfico pode ser estudado segundo duas visões complementares: o modelo de
campos e o modelo de objetos” Câmara et al. (1996). O modelo de campos enxerga o
mundo como um superfície contínua, sobre a qual os fenômeno geográfico variam
segundo diferentes distribuição. O modelo de objetos representa o mundo como uma
superfície ocupada por objetos identificáveis, com geometria e características próprias.
Compartilhando da mesma visão, Goodchild (1992) cita: “da análise do universo do mundo
real pode-se constatar que as aplicações de Geoprocessamento lidam com dois grandes
tipos de dados:
24
! Campo geográfico (Geo-campos): correspondem a grandezas distribuídas
espacialmente, como tipo de solo, topografia e teor de minerais.
! Objetos geográficos (ou Geo-objetos): individualizáveis e tem identificação com
elementos do mundo real, como lotes num cadastro urbano e postes numa rede
elétrica.”
A identificação de Geo-campos se distingue em muito da identificação de Geo-objetos: p. ex.,
um solo arenoso é um valor para um Geo-campo que pode estar espalhado em manchas
desconexas em mapa de classificação de solo; já a rodovia D. Pedro I é um Geo-objeto único.
No entanto, Geo-objetos podem estar associados a mais de uma representação geométrica, ou
seja, a rodovia D. Pedro I pode ter um mesmo identificador no banco de dados e mais de
uma representação em mapas diferentes em escala e nível de detalhes.
Classes de Dados em SIG:
No modelo de dados do SPRING (Câmara, 1995) o universo conceitual toma como base
as classes Geo-campos e Geo-objetos e as especializam em tipos de dados que suportam os
dados geográficos em conformidade com suas características, as quais seriam:
Temático: É um Geo-campo que caracteriza um mapa temático, onde cada posição
do campo possui uma identificação do tema a que pertence, um
exemplo seria um mapa de vegetação que é caracterizado pelo conjunto
de temas (p. ex.: floresta densa, floresta aberta e cerrado);
Numérico: É um Geo-campo que caracteriza um modelo numérico de terreno, onde
cada posição do campo possui um valor real que descreve a ocorrência
de um fenômeno, p. ex.: mapa de campo magnético ou mapa de
altimetria;
Imagem: É uma especialização da classe Numérico onde os atributos são inteiros
naturais (Ν) que caracteriza um valor de intensidade e cor para dados
de sensoreamento remoto, p. ex.: imagens de satélite, imagens de radar,
fotografia aérea, etc.;
25
Cadastral: É um conjunto de representações de Geo-objetos para uma mesma área
geográfica, projeção cartográfica e escala, p. ex.: Mapa de Lotes de uma
cidade.
Redes: É uma especialização da classe Cadastral que armazena estruturas e
localidades linearmente, p. ex.: rede elétrica.
2.1.2 Universo de Representação
No universo de representação, definimos as representações geométricas que estão
associadas às classes do universo conceitual; Primeiramente, devemos considerar as duas
grandes classes, ou estrutura de dados, para representações geométricas: Representação
Vetorial e Representação Matricial:
A Representação Vetorial:
“Todo fenômeno geográfico em princípio pode ser representado por um ponto, uma linha
ou uma região com um rótulo identificando-o” (Burrough, 1986). A representação vetorial
podem ser resumida neste três conceitos (ponto, linha e região) vide Figura 2.1. Desta
forma, uma antena emissora de TV, p. ex., pode ser representada por um ponto, através do
par de coordenadas XY e seu rótulo “Antena X”. Analogamente o mesmo se dá com
estradas, oleodutos e limites políticos quando representados por linhas. Já uma região é um
conjunto de polígonos identificados por um mesmo rótulo , podendo ser composto por
várias ocorrências discretas (vários polígonos que identificam o mesmo fenômeno) e
podendo conter regiões de rótulo diferente dentro destes polígonos (polígonos com furos).
Figura 2.1 - Componentes básicos de Vetorial: Ponto, Linha e Região
26
Apesar de nossos olhos poderem facilmente distinguir em um mapa os relacionamentos
topológicos, para sua representação computacional é necessário explicitá-los em cada
componente do mapa (ponto, linha e região) em uma estrutura de dados conhecida como
Estrutura arco-nó-polígono (Worboys, 1995), vide Figura 2.2. Esta estrutura de dados visa
manter consistente os relacionamentos topológicos entre todos os elementos do mapa, o
que irá possibilitar a aplicação de operadores de análise e consultas que requerem topologia.
Figura 2.2 - Estrutura Topológica
27
A Representação Matricial:
A mais simples das estruturas de dados matriciais consiste de uma grade de células. Cada
célula é referenciadas pela linha e coluna que a contém e um número que representa o tipo
ou valor de seu atributo, ex. Figura 2.3 e Figura 2.4:
Figura 2.3 – Exemplo de Sensoreamento Remoto (imagem LandSat de Poçosde Caldas-MG)
Figura 2.4 – Exemplo de Mapa Temático (geologia de Poços de Caldas)
28
Classes de Dados e sua Representação:
Neste ponto é necessário estabelecer o relacionamento entre o Universo Conceitual e o
Universo de Representação, ou seja, entre as classes de dados e sua representação:
Temático: A princípio é capturado pelo SIG como dado Vetorial, mas para fins de
cruzamento de informações, em procedimentos de análise, pode
possuir uma representação Matricial produzida através de conversão
Vetorial-Matricial.
Numérico: Pode ser capturado pelo SIG como dado Vetorial, p. ex. curvas de nível,
valores para pontos de amostras regulares ou irregulares, mas para fins
de operações de análise deve possuir uma representação Matricial
produzida através de procedimentos de interpolação dos valores
amostrados.
Imagem: É tipicamente um dado Matricial, .
Cadastral: É representado por uma estrutura topológica arco-nó-poligno, podendo
suportar pontos, linhas e regiões.
Rede: É representado por uma estrutura topológica de arco-nó, podendo
suportar pontos e linhas.
2.2 Estrutura de um Banco de Dados GeográficosAtravés do processo de definir o esquema conceitual de um banco de dados geográficos no
SPRING o usuário estrutura o banco de dados de sua(s) aplicações. Este processo consiste
em definir Categorias, as Categorias estendem as classes de dados do SPRING, criando classes
derivadas de Geo-objeto, Cadastral, Rede, Não-Espacial, Temático, Numérico e Imagem. Os nomes
das Categorias que são fornecidos pelo próprio usuário. O exemplo a seguir define o
esquema conceitual para um banco de dados geográficos para cadastro rural. Na Figura 2.5
é apresentado o modelo de classes deste banco de dados, as setas identificas como “is-a”
indicam especializações.
29
" uma Categoria “Fazendas”, especialização de Geo-objeto
" uma Categoria “Mapa de Propriedades”, especialização de Cadastral, que define um
mapeamento para os objetos da classe fazendas e suas especializações.
" uma Categoria “Mapa de Solos”, especialização de Temático, cujas instâncias
armazenam o tipo de solos para as áreas de estudo;
" as Categoria “Altimetria” e “Declividade”, especializações de Numérico, cujas
instâncias guardam (respectivamente) a topografia e a declividade da área de estudo;
" uma Categoria “Dados LandSat”, especialização de Imagem, cujas instâncias contêm
as imagens do satélite LandSat sobre a região de estudo.
GeoCampo Cadastral
is-a
GeoObjeto
Temático MNT
DadoSens. Rem.
FazendasMapaPropriedades
Mapasolos
Altimetria DeclividadeDados
LANDSAT
is-a
is-a
is-mapped-in
is-a
is-a
is-ais-a
is-ais-a
Figura 2.5 – Exemplo de definição do Esquema Conceitual.Adaptado de Câmara (1995)
2.2.1 Instanciação do modelo
A população do banco de dados geográfico, no exemplo específico do SPRING (Câmara
1995), se dá pela inclusão no sistema de Planos de Informação. Em última análise um Planos de
Informação é um mapa (isto é verdade para as Categorias Imagem, Numérico, Cadastral. Temático e
Redes). Cada Plano de Informação é uma instância direta da Categoria a que pertence, p. ex.:
“MapaBasico” da Categoria “Mapa solos”.
30
Multi-representação e a Instanciação:
No modelo de dados do SPRING, um Plano de Informação pode ter mais de uma
representação. Por exemplo, uma Plano de Informação de um Categoria do tipo Temático pode
ter uma representação Vetorial e outra Matricial (Figura 2.6).
Plano deInformação
Represent.Geom.
Matricial Vetorial
é-um
is-represented-by
é-um
Figura 2.6 - Representação
2.3 Análise EspacialUm sistema de informações geográficas não é apenas um repositório de dados geográficos
que possibilita procedimentos de automatização de desenho. A característica fundamental
de um SIG é sua capacidade de gerar novas informações a partir dos dados disponíveis em
seu repositório. Este processo é denotado por termo “análise espacial” e envolve um
conjunto de operadores sobre campos e objetos geográficos.
Esta seção faz uma apresentação sucinta da hierarquização destes operadores. Sua
utilização prática é discutida no próximo Capítulo.
2.3.1 Operações sobre Campos
Descrevemos nesta seção as operações sobre Geo-campos e suas especializações Temático,
Numérico e Imagem, que podem ser classificados como (Tomlin, 1990):
1) Pontuais: a saída da operação é um Geo-campo cujos valores são função apenas dos
valores dos Geo-campos de entrada em cada localização correspondente. Podem
operar apenas sobre um campo (p. ex. fatiar um modelo numérico de terreno,
classificar uma imagem) ou realizar intercessões entre conjuntos espaciais (p. ex.
operações booleanas entre mapas temáticos).
31
2) Vizinhança: o resultado é um Geo-campo cujos valores dependem da vizinhança da
localização considerada. (p. ex. filtragem espacial de uma imagem, cálculo de
declividade de um Numérico)
3) Zonais: caso especial de (2), estas operações são definidas sobre regiões específicas
de um Geo-campo de entrada, onde as restrições são fornecidas por outro Geo-campo
temático. (p. ex. “dado um mapa de solos e um mapa de declividade da mesma
região, obtenha a declividade média para cada tipo de solo”).
4) Propriedades: operações que devolvem valores (escalares ou vetores) de um Geo-campo
ou um conjunto de Geo-campos. (p. ex. “calcule a altitude média do terreno” e
“obtenha o histograma de uma imagem”).
2.3.2 Operações sobre Objetos
As operações sobre Geo-objetos incluem:
• Restrições sobre atributos: computados em função dos atributos de entidades
espaciais (p. ex. “selecione todas as cidades de Alagoas com mortalidade infantil
maior que 10% ?”).
• Restrições espaciais: derivados a partir dos relacionamentos topológicos das entidades
geográficas (p. ex. “dê-me todos as escolas municipais do bairro Jardim Satélite”),
de direção (“ao norte de”, “acima de”) ou métricos (e.g. “dê-me todas as escolas a
menos de 500 m da Via Dutra”).
• Propriedades de Geo-objetos: os resultados correspondem a predicados de um Geo-objeto
ou de um conjunto de Geo-objetos (p. ex. “calcule a média do valor venal das casas
do bairro Jardim Esplanada” ou “indique o caminho ótimo para o ônibus que vai
do Centro ao Jardim Planalto”).
32
2.3.3 Operações entre Campos e Objetos
As operações que combinam campos e objetos incluem:
• Atualização de atributos de objetos, a partir de Geo-campos: Exemplo: “Dados a altimetria e
o mapa de municípios do Vale do Paraíba, crie um novo mapa aonde cada município
terá o atributo “altitude média” atualizado a partir dos dados numéricos.
• Atualização de atributos de objetos, a partir de restrições booleanas aplicadas a um conjunto de Geo-
campos. Exemplo: “Atualize o mapa de municípios da Amazônia, indicando a área de
cada município onde ocorreu desmatamento em 1996”.
• Geração de objetos e um mapa cadastral associado, a partir de Geo-campos: Exemplo:
“Identifique as áreas homogêneas de uma região a partir da interseção dos mapas de
vegetação, solos e geologia.” ( operação de identificação).
• Operações que geram Geo-campos a partir de atributos de objetos. Exemplo: “Gere um mapa
temático da distribuição de renda no Brasil, a partir do mapa de municípios do IBGE”.
(operação de Reclassificação por Atributos). Pode haver a necessidade de se recalcular
a topologia do mapa resultante pois as regiões serão combinadas.
• Operações que geram Geo-campos a partir de propriedades de objetos: Exemplo: “Determine a
região que dista 50m da rodovia para que não haja queima de cana”. (Mapa de distâncias,
Buffer): gera um Geo-campo contendo as distâncias de cada ponto do mapa a um Geo-
objeto de referência (representado por um ponto, linha ou região).
33
2.3.4 Relações de Operadores
Em Câmara (1995) encontramos a seguinte relação de operadores (Tabela 2.1) indicando,
para cada operação: a classe dos objetos de entrada e de saída, e dos objetos modificadores
(quando cabível) e as restrições de cada operação:
Tabela 2.1 - Operações sobre Campos e Objetos. Fonte: Câmara (1995).
Operação Objeto Entrada Objeto Modificador Objeto Saída RestriçãoPonderação TEMÁTICO NUMÉRICO (função unária)Fatiamento NUMÉRICO TEMÁTICO (função unária)Reclassificação TEMÁTICO TEMÁTICO (função unária)Booleana NUMÉRICO,
TEMÁTICOTEMÁTICO (regras)
Matemática NUMÉRICO NUMÉRICO (fórmula)Vizinhança NUMÉRICO,
TEMÁTICONUMÉRICO,TEMÁTICO
(função local eforma davizinhança)
Zonais NUMÉRICO TEMÁTICO NUMÉRICOSeleçãoEspacial
GEO-OBJETO(conjunto)
CADASTRAL GEO-OBJETO(conjunto)
(predicado espacial)
JunçãoEspacial
GEO-OBJETO(conjuntos)
CADASTRAL GEO-OBJETO eVALORES(conjunto)
(predicado espacial)
Identificação TEMÁTICO GEO-OBJETO(conjunto)CADASTRAL
IntersecçãoEspacial
TEMÁTICO (n) GEO-OBJETO(conjunto)CADASTRAL
MapaDistâncias
GEO-OBJETO CADASTRAL TEMÁTICO (predicado métrico)
ReclassificaçãoAtributos
GEO-OBJETO(conjunto)
CADASTRAL TEMÁTICO (atributo)
Zonal sobreGEO-OBJETOs
TEMÁTICO,NUMÉRICO
GEO-OBJETO,CADASTRAL
TEMÁTICO,NUMÉRICO
Seleçãoespacial (restr=GEO-CAMPO)
GEO-OBJETO(conjunto)
CADASTRAL,TEMÁTICO,NUMÉRICO
GEO-OBJETO(conjunto)
(predicado espacial)
34
35
CAPÍTULO 3
ÁLGEBRA DE MAPAS EM LEGAL
Neste Capítulo é apresentada uma visão geral de LEGAL, seus objetivos e características.
O enfoque principal será sobre os operadores de álgebra de mapas, restrito a operadores
sobre Geo-campos. Outros operadores, exemplos, extensões e aplicações de LEGAL podem
ser vistos em Barbosa (1998), mecanismos de consulta e recuperação estão descritos em
Câmara (1995). Para facilitar a leitura dos exemplos a seguir, diferenciando os comentários
das palavras reservadas da linguagem, estas últimas aparecem no texto em fonte COURIER
e sem acentuação.
3.1 Classificação de LEGALNo contexto de interfaces usuário-computador, LEGAL é classificada como “interface por
linguagem de programação”, possuindo as características, vantagens e desvantagens inerentes a
este tipo de interface, o que será discutido no próximo capítulo. Para executar um
procedimento de análise espacial em LEGAL, o usuário utiliza um editor de texto para
escrever programas, seguindo a gramática desta linguagem, e submete-os ao interpretador
da linguagem do SIG. No caso de LEGAL o interpretador vem sendo desenvolvido como
um módulo adicional ao SPRING.
3.2 Características de LEGALLEGAL foi proposta por Câmara (1995) com o objetivo de prover um ambiente geral para
análise geográfica, incluindo operações de manipulação, operações de consulta espacial e
operações de apresentação. Enquanto outros sistemas tratam estas classes de operações de
forma separada, obrigando o usuário a mudar de ambiente muitas vezes durante uma seção
de trabalho, em LEGAL o usuário tem todas estas funcionalidades numa mesma
linguagem, podem-se expressar um procedimento completo através de um programa em
LEGAL.
36
3.2.1 Classes do modelo de dados e sua representação em LEGAL.
Como visto no Capítulo anterior o processo de modelagem resulta em classes de dados de
uso específicos para cada finalidade. Na prática estas classes são nomes reservados da
linguagem que permitem ao usuário organizar os dados da sua aplicação. Em LEGAL,
como na maioria das linguagens de programação, os dados são representados por variáveis
e é necessário que a classe da variável seja compatível com a classe de dados que ela
representa. Em LEGAL uma variável representa um dado pertencente ao banco de dados
no ambiente do SPRING, e portanto as tipos de variáveis disponíveis tem relação direta
com o modelo de dados geográfico do SPRING:
! Cadastral para instâncias de cadastral;
! Tematico para instâncias de Temático;
! Imagem para instâncias de Imagem;
! Digital para instâncias de Numérico.
! Objetos para instâncias de Geo-objeto;
! Nao-espacial para instâncias de dado Não-espacial;
! Rede para instâncias de Rede;
3.2.2 Seções de um Programa em LEGAL
O formato geral de um programa escrito em LEGAL deve compreender as seções de
declaração, instanciação e de operações de transformação (Figura 3.1). Cada uma com o
respectivo objetivo:
37
{
declarações ;
instanciações ;
operações ;}
Figura 3.1 - Três seções de um programa em LEGAL. Fonte: (INPE, 1998).
Declaração: nesta seção definem-se variáveis de trabalho. Cada variável deve ser
declarada explicitamente, isto é, deve fornecer um nome e associá-la
a uma categoria no esquema conceitual.
Instanciação: nesta seção recuperam-se os dados já existentes do banco de dados
ou cria-se um novo Plano de Informação. Este novo Plano de Informação
poderá então ser associado ao resultado de operações em Legal.
Operação: nesta seção, realizam-se as operações da álgebra de mapas.
Cada sentença em LEGAL pode envolver símbolos (por exemplo, “{“, “(“, “;”, “,”),
operadores (por exemplo, “+”, “*”, “&&”, “||” , “<”, “<=”, “!=”‘), palavrasreservadas (por exemplo, Novo, Tematico, Nome, ResX), nomes de variáveis e
nomes de dados (Planos de Informações). Os nomes dos Planos de Informações,
categoria e classes temáticas devem ser escritos entre aspas (“”). As palavras reservadas
iniciam com maiúscula e não utilizam acentos (por exemplo, Tematico).
Declaração:
Na seção de declaração define-se o nome de uma ou mais variáveis que poderão ser
utilizadas no decorrer do programa. Toda variável deve ser declarada antes de ser usada por
algum comando da linguagem. É através destes nomes de variáveis que o programa acessa
os dados geográficos disponíveis no sistema. Além de definir o nome de uma variável, a
ação de declaração também determina que categoria de dados geográficos presentes no
banco poderão posteriormente ser associados a este nome (Figuras 3.2, 3.3).
38
Sintaxe:
Imagem , Numerico , Tematico nome_variável ( “nome_categoria”) ; Objetos Cadastral
Figura 3.2 - Sintaxe da declaração de Planos de Informação. Fonte: INPE (1998).
Exemplos de declaração de Planos de Informações:
Imagem banda3, banda4, ivdn ("LANDSAT"); Tematico solo("Tipo_Solo"), geo("geologia"); Digital alti1 ("ALTIMERIA"); Tematico solos("pedologia"); Digital solonumerico("ponderacoes"); Imagem TM5("ancoras");
, ,
Tabela nome_variável ( Reclassificacao ) ; ( Fatiamento ) ( Ponderacao )
Figura 3.3 - Sintaxe da declaração de tabelas de transformações. Fonte: INPE (1998).
Exemplos de declaração de Tabelas:
Tabela pesos(Ponderacao); Tabela faixas(Fatiamento); Tabela classes(Reclassificacao);
Instanciação:
A instanciação é caracterizada pelos comandos Recupere e Novo. O comando
Recupere associa o nome de uma variável a um Plano de Informação existente no banco de
dados geográfico corrente; já o comando Novo cria um novo Plano de Informação (vide
Figuras 3.4 e 3.5)
39
Sintaxe:
variável = Novo ( Nome = “nome_pi”, parâmetros ) ; Recupere ( Nome = “nome_pi” )
onde, parâmetros: resolução , Caso Imagem
escala , representação Caso Temáticolimites , Caso Numérico
onde: resolução : ResX = numero, ResY = numeroescala : Escala = numerolimites : Min = numero, Max = numerorepresentação : Repres = Vetor Caso
TemáticoRepres = Raster Caso Temático
Figura 3.4 - Sintaxe da Instanciação de Planos de Informação. Fonte: INPE (1998).
Exemplos de recuperação de Planos de Informações:
tema = Recupere (Nome = "baciashidrograficas"); alti = Recupere (Nome = "CotasAltimetricas"); ima = Recupere (Nome = "TM4");
variável = Novo ( categorias , entradas );
onde, categorias: CategoriaIni = “categoria”,
CategoriaFim = “categoria” ,
e entradas : lista_de_ponderação lista_de_fatiamento lista_de_reclassificação
,onde, lista_de_ponderação: ,
“classe” : numero ,
lista_de_fatiamento: , [numero, numero] : “classe”
, lista_de_reclassificação: ,
“classe” : “classe”
Figura 3.5 - Sintaxe da instanciação de Tabelas. Fonte: INPE (1998).
40
Exemplos de criação de Planos de Informações:
solo = Novo (Nome = "Solos_A", ResX=50, ResY=50,
Escala=100000, Repres = Vetor);
alti = Novo (Nome = "Altimetria", ResX=50, ResY=50,
Escala=1000, Min=0, Max=100);
Ima = Novo (Nome = "ImagemTM_Res", ResX=30, ResY=30);
Exemplo de tabela de reclassificação: Grupo = Novo(CategoriaIni="Vegeta",
CategoriaFim="Vegeta","Db", "Ds1", "Ds2", "Ds4", "Dm" :"Florestabrofila","Pfm", "Pa", "Pah" : "FmPioneiras", "Ap" :"Floresfila");
Exemplo de tabela de fatiamento:
grupo = Novo(CategoriaFim = "Vegetacao",[0.0, 0.2]: "Floresta",[0.2, 0.45], [0.8, 1.0]: "Mata_galeria",[0.45, 0.8]: "Cerrado");
Exemplo de tabela de ponderação:
ponde1 = Novo(CategoriaIni = "Vegetacao","Floresta": 0.2,"Mata_galeria", "Mata": 0.43"Cerrado"): 0.456);
Operação:
Após a declaração e instanciação de variáveis segue-se a definição das ações, através da
construção de expressões, que em LEGAL são representados por operações. Numa
operação uma variável recebe o resultado do processamento de expressões envolvendo
operadores da linguagem que atuam sobre as variáveis declaradas e instanciadas
previamente no programa. O diagrama abaixo (Figura 3.6) mostra os possíveis
relacionamentos em operações:
41
variável = expressão_realexpressão_imagemexpressão_tematicaexpressão_numéricaexpressão_condicionalexpressão_booleana
Figura 3.6 - Sintaxe geral para Operações em LEGAL. Fonte: INPE (1998).
Os operadores aritméticos “+”, “−”, “*”’, “/”e “^”, assim como funções matemáticas
(seno, tangente, etc.), são entendidos como pontuais ou locais, isto é, atuam sobre cada
elemento de representações matriciais de imagens ou grades numéricas, ou sobre elementos
vizinhos que são localizados relativamente a um elemento de referência.
Expressão Imagem
Expressões Imagem compõem o conjunto das operações possíveis sobre a classe Imagem
(Figura 3.7):
Expressão Imagem op
variável = variável_imagem Imagem ( expressão_real ) Imagem ( expressão_numérica ) - expressão_imagem expressão_real op expressão_imagem expressão_imagem op expressão_real ( expressão_imagem ) expressão_imagem [expressão_real , expressão_real] função_matematica ( expressão_imagem )
Onde: op são operadores como: + - * / ^
Figura 3.7 - Sintaxe de Operações sobre Imagem. Fonte: INPE (1998).
Exemplos de expressões imagem:
ima1 = Imagem(grade1); ima3 = ima2 + 20; res_ima1 = abs(sen(ima1)- 255);
42
Expressão Numérica
Expressões Numéricas compõem o conjunto das operações possíveis sobre a classe
Numérico (Figura 3.8):
Expressão Numérica op
variável = variável_numérica Numerico-’(’-expressão_imagem-) Numerico-’(’-expressão_real ) Pondere-’(’-expressão_tematica , variável_tabela- ) - expressão_numérica expressão_real op expressão_numérica expressão_numérica op expressão_real ( expressão_numérica ) expressão_numérica-[expressão_real , expressão_real] expressão_condicional_numérica função_matematica ( expressão_numérica )
Onde: op são operadores como: + - * / ^
Figura 3.8 - Sintaxe de Operações sobre NUMERICO. Fonte: INPE (1998).
Exemplos de expressões numéricas:
ph_fe1 = Numerico(banda_spot2); soma_grade = (grade_solo + grade_decl)/2; grade_seno = sen(grade1);
Expressão Temática
Expressões Temáticas compõem o conjunto das operações possíveis sobre a classe Temática(Figura 3.9).
Expressão Temática variável = variável_temática ;
variável_temática . Classe Classe (”geoclasse”) Fatie ( expressão_numérica , variável_tabela ) Reclassifique ( expressão_tematica , variavel_tabela ) Atribua ( CategoriaFim = “categoria" ) {lista_de_casos} expressão_numérica-[expressão_real , expressão_real]
, Onde : lista_de_casos : ”geoclasse” : (expressão_booleana)
Figura 3.9 - Sintaxe para Operações sobre Tematico. Fonte: INPE (1998).
43
Exemplos de expressões temáticas:
cl_decliv = Fatie (decliv,tab_decliv);
desmat = Reclassifique (cobertura, tab_recl);
aptidao = Atribua (CategoriaFim = "Aptidao")
{"Boa" : (solo.Classe == "LatosoloRoxo" &&
decliv.Classe == "O-3"),"Inapto" :
(solo.Classe == "AreiaQuat" && decliv.Classe
== ">8") };
Expressão Condicional
Expressões Condicionais atuam sobre classes de dados indistintamente compondo as
expressões já mencionadas (Figura 3.10).
Expressão Condicional : variável = expressão_condicional_imagem
expressão_condicional_digital expressão_condicional_temática
Onde:expressão_condicional_temática:(expressão_booleana) ? expressão_temática : expressão_temática
expressão_condicional_imagem:(expressão_booleana) ? expressão_imagem : expressão_imagem
expressão_condicional_digital:(expressão_booleana) ? expressão_numérica : expressão_numérica
Figura 3.10 - Sintaxe de Expressão Condicional.Fonte: INPE (1998).
Exemplo de expressão condicional:
Imag_out = (ta.Class == "mata") ? Imagem (TM5): 0;
Expressão Booleana
As expressões booleanas envolvem todos os tipos de expressões (Figura 3.11). O valor
resultante de uma tal expressão deve ser verdadeiro (TRUE) ou falso (FALSE), podendo
ser feito da comparação entre pixels de imagens ou valores de grade através dos operadores
“<”, “>”, “<=”, “>=”, “==” e “!=”‘; ou da comparação entre classes de Planos de
Informações temáticos através dos operadores “==” e “!=”. Podendo envolver até 40
Planos de Informações simultaneamente. Expressões booleanas podem ainda ser
44
combinadas a partir dos operadores “&&” (e lógico, intercessão), “||” (ou lógico, união) e
“!” ou “~” (negação, complemento).
|| && ! = = != < > <= >=
expressão_numérica expressão_imagem
expressão_tematica ! expressão_booleana
(expressão_booleana)
Figura 3.11 - Sintaxe de Expressões Booleana.Fonte: INPE (1998).
3.3 Classificação de Operadores em LEGAL
A linguagem LEGAL dispõe de um certo número de operadores sobre Geo-campos, a fim de
desenvolver os modelos de análise geográfica, porém, esta linguagem está em constante
evolução e novos operadores vão sendo acrescentados a cada nova versão. Isto implica no
requisito de extensibilidade para a interface usuário-computador como será visto no
próximo capítulo.
3.3.1 Operadores entre GEO-campos
As operadores entre Geo-campos disponíveis na versão hora em desenvolvimento da
Linguagem LEGAL são melhor apresentadas segundo a seguinte classificação: Operadores
Pontuais e os Operadores Locais e Zonais, a saber:
• Operadores Pontuais : As operações pontuais se distinguem por atuarem em cada
ponto do mapa baseado somente em seu valor não levando em consideração os valores
dos pontos vizinhos.(Figura 3.12a).
• Operadores Pontuais Unários: Os operadores Pontuais Unários requerem que o
usuário defina um tabela de mapeamento entre os Geo-campos de entrada e de saída. O
usuário cria uma instancia da classe Tabela do tipo: Tabela_de_fatiamento,
Tabela_de_ponderacao, Tabela_de_reclassificacao, conforme o
respectivo operador, Fatie, Pondere e Reclassifique.
45
• Operadores Locais: São operações de vizinhança, que levam em consideração os
valores dos pontos próximos na mesma região do Geo-campo de entrada, para
determinarem o valor para a mesma posição do Geo-campo de saída. Em operadores
Locais a região de Vizinhança é definida por uma máscara regular (Figura 3.12b).
• Operadores Zonais Operações zonais são um subconjunto de operações de vizinhança
onde a máscara são substituídas por classes de um Geo-campo temático (figura 3.12c).
Figura 3.12 - Classes de Operadores. Adaptado de Barbosa (1998).
Operador : FATIE (PONTUAL UNÁRIO)
46
O operador Fatie transforma um Numérico ou uma Imagem em um Temático. Sua tabela de
mapeamento estabelece as faixas de valores do Geo-campo que irão compor as Geo-classes do
plano de informação Temático a ser gerado.
Exemplo:
A Figura 3-13 abaixo mostra um exemplo de uma operação de
fatiamento onde um mapa de declividade em graus é convertido para um
mapa de classes de declividade a partir da transformação: {(0-5%)-
"baixa"; (5-15%)-"média"; (acima de 15%)-"alta"}.
Figura 3.13 - Operação de Fatiamento. Fonte: INPE (1998).
Código em LEGAL:
{
// Declaração de Variáveis
Tematico classes_decl ("Declividade");
Numerico decliv_num ("Declividade_Numerica");
Tabela tab_fatia (Fatiamento);
// Definicao da tabela de fatiamento
tab_fatia = Novo ( CategoriaFim = "Declividade",
[0.0, 5.0] : "Baixa",
[5.0, 15.0]: "Media",
[15.0, 45.0]: "Alta");
// Recuperação do PI de Declividade Numérica
decliv_num = Recupere (Nome = "Declive_SJC");
// Geracao do PI de saida
classes_decl = Novo (Nome = "Classes_Decl",
ResX = 50, ResY = 50,
Escala = 100000);
// Operação de Fatiamento
classes_decl = Fatie (decliv_num, tab_fatia);
}
47
Operador : PONDERE (PONTUAL UNÁRIO)
O operador Pondere transforma um Temático em um Numérico através da uma tabela de
ponderação. Sua tabela de mapeamento estabelece valores para o Geo-campo de saída
conforme as Geo-classes de entrada.
Exemplo:
A Figura 3.14 mostra um exemplo do operador de ponderação (conversão de
um mapa de solos em um mapa de solos ponderado). Neste caso, o Plano de
Informação de entrada é Temático, um mapa de solos com as classes { Le, Li, Ls,
Aq } e o Plano de Informação de saída é Numérico cujos valores estão entre 0.0 e 1.0
e a operação de ponderação consiste na associação {(Le-0.60), (Li-0.20), (Ls-
0.35), (Aq-0.10)}.
Figura 3.14 - Operação de Ponderação. Fonte: INPE (1998).
Código em LEGAL:
{
// Parte 1- Declaracao
Tematico SOLOS ("Solos");
Tabela ponderaSOLO (Ponderacao);
Numerico SOLOpond ("SoloPonderado");
// Definicao da Tabela de Pesos
ponderaSOLO = Novo (CategoriaIni = "Solos",
Le : 0.60,
Li : 0.2,
Ls : 0.35,
Aq : 0.1);
// Parte 2 – Instanciacao do mapa de solos
SOLOS = Recupere (Nome = "SoloCE");
// Criacao do novo mapa de solos ponderado
SOLOpond = Novo (Nome = "solop",
ResX = 30, ResY = 30,
Escala = 100000, Min = 0, Max = 1);
// Parte 3 – Operacao de Ponderacao
SOLOpond = Pondera (SOLOS, ponderaSOLO);}
48
Operador : RECLASSIFIQUE (PONTUAL UNÁRIO)
O operador RECLASSIQUE transforma um mapa Temático em outro Temático de classe
distinta. Sua tabela de mapeamento estabelece quais as Geo-classes do Temático de entrada
que irão compor as Geo-classes do Temático de saída.
Exemplo:
Como exemplo, temos um mapa de cobertura do solo na Amazônia com
diferentes classes {"Floresta Densa", "Floresta Várzea", "Rebrota", "Área
Desmatada", "Cerrado"}. Este mapa Temático será reclassificado para um novo
mapa apenas com as classes {"Floresta", "Desmatamento", "Cerrado"}.
Código em LEGAL:
{
// Parte 1 – Declaração
Tematico cobertura ("Floresta");
Tematico desmat ("Desmatamento");
Tabela tab_recl (Reclassificacao);
tab_recl= Novo(CategoriaIni = "Floresta",
CategoriaFim = "Desmatamento",
"FlorestaDensa" : "Floresta",
"FlorestaVarzea" : "Floresta",
"Rebrota" : "Desmatamento",
"AreaDesmatada" : "Desmatamento",
"Cerrado" : "Cerrado");
// Parte 2 – Instanciação- Recuperação da variável
cobertura = Recupere (Nome = "Uso_JiParana");
// Criação do novo PI
desmat = Novo (Nome = "Desmat_JiParana", ResX= 30,
ResY = 30, Escala = 100000);
// Parte 3 – Operação Reclassificação
desmat= Reclassifique (cobertura, tab_recl);
}
49
Operador : ATRIBUA (Operações Booleanas entre GEO-CAMPOS)
Trata-se de uma operação pontual unária que realiza transformações baseado no valor de
cada posição de mais de um Geo-campos de entrada através de álgebra booleana.
Este tipo de operação recebe como entrada um Imagem, Numérico ou Temático e retorna um
dado Temático. É necessário informar um conjunto de regras booleanas para determinar
quais condições dos dados de entrada irão satisfazer às classes dos dados de saída.
Exemplo:
A Tabela 3.1 a seguir exemplifica o uso de operação booleana aplicado a
classificação de aptidão agrícola:
Tabela 3.1 - Exemplo: “Regras para Aptidão Agrícola” Fonte: INPE (1998)
Aptidão Solos Declividade
Boa Latossolo Roxo 0-3%
Média Latossolo Vermelho-Amarelo 3-8%
Inapto Areia Quartzosa >8%
Código em LEGAL:
{
// Parte 1 – Declaração
Tematico solos ("Solos"), aptidao ("Aptidao"),
decliv ("Declividade");
// Parte 2 – Instanciação
decliv = Recupere(Nome = "Decliv94");
solos = Recupere (Nome = "Solos94");
aptidao = Novo (Nome = "apt94", ResX=50, ResY=50,
Escala = 50000);
// Parte 3 – Operacao
aptidao= Atribua (CategoriaFim = "Aptidao")
{ "Boa" : (solo.Classe == "LatosoloRoxo" &&
decliv.Classe == "O-3"),
"Media" : (solo.Classe == "LatosolVeAm" &&
decliv.Classe == "3-8"),
"Inapto" : (solo.Classe == "AreiaQuat" &&
decliv.Classe == ">8")};
}
50
Operações Matemáticas (Pontuais)
São operações matemáticas pontuais as expressões matemáticas que atuam sobre Planos de
Informação da Categoria Numérico e Imagem onde as expressões válidas são:
operações aritméticas: soma (+), subtração (-), multiplicação (*) e divisão (/);
funções matemáticas: seno (sin), cosseno (cos), tangente (tan), arcoseno (asin), arco-
cosseno (acos), arco-tangente (atan), logaritmo (log),
logaritimo base 10 (log10), exponencial (exp), raiz quadrada
(sqrt), inteiro (int), valor absoluto (abs);
relações: menor que (<), maior que (>), menor ou igual (<=), maior ou
igual (>=), igual (==), diferente (!=).
Exemplo:
Como exemplo de operação matemática, tome-se a figura a seguir, onde o Plano de
Informação da esquerda é um mapa de solos ponderado e Plano de Informação da direita
é um mapa de declividade. Consideremos que desejamos computar um indicador de
adequação de solos como a soma do valor atribuído ao solo com o inverso da
declividade. A operação a seguir poderia ser utilizada como passo intermediário ao
calcular um mapa de adequação de solos (quanto maior o valor, mais adequado),
veja Figura 3.15.
Figura 3.15 - Operação Matemática. Fonte: INPE (1998).
51
Código em LEGAL:
{
// Parte 1 - Declaração
Numerico solo_pond ("Solo_ponderado"),
Decliv ("Declividade"),
aptidao ("AdequacaoNumerico");
// Parte 2 - Instanciação
decliv = Recupere (Nome = "Decliv94");
solo_pond = Recupere (Nome = "Solos94");
aptidao = Novo (Nome = "adequcao94",
ResX=50, ResY=50,
Min=0, Max=2, Escala = 50000);
// Parte 3 - Operacao
aptidao = solo_pond + 1/decliv;}
Operador: RECLATRIB (Reclassificação por Atributos).
São operações pontuais que reclassificam, reagrupam, classes baseadas em seus valores, ou
operações que nos permitem gerar Geo-campos a partir de Geo-objetos.
Sintaxe:
<Geo-campo> = Reclatrib (<Cadastral>, <Atributo>) ON
MAP <Cadastral>;
Exemplo:
Para ilustrar estas operações, consideremos o caso onde um mapa de distribuição
da pobreza do Brasil será obtido a partir dos dados do IBGE, agregados por estado.
Suporemos que um dos atributos é a renda per capita. Para isto é necessário uma
composição de operações: primeiramente é gerado um modelo de terreno com a
distribuição da váriavel renda per capita, que será em seguida fatiado.
52
Código em LEGAL:
{
Colecao estados Estado_Brasil;Tematico mapa_estados Mapa_IBGE;
Tematico campo_renda Campo_Renda;Tematico tab_fatia Slice_Table;
Atributo renda_per_capita FLOAT;Mapa_renda = Novo (nome = "Mapa Riqueza Brasil")
(RES_X = 1000m, RES_Y = 1000m);tab_fatia = Novo ( CLASS_OUT = RENDA,
([0-500] : "Miseravel",
(500-1000] : "Pobre",(1000-2000] : "Remediado",
>2000 : "Rico"));
mapa_renda = Fatie(Reclatrib(estados,renda_per_capita)
ON MAP mapa_estados), tab_fatia);}
Vizinhança:
As operações de vizinhança levam em consideração os valores dos pontos próximos na
mesma região do Geo-campo de entrada para determinarem o valor para uma posição do
Geo-campo de saída.
O processamento de um operador de vizinhança se dá pela definição de uma máscara que
se desloca a sobre o Geo-campo de origem e a cada passo deste deslocamento aplica uma
operação que se baseia nos valores das posições compreendidas pela máscara.
Operadores locais:
SomaL Calcula a soma local dos pontos do Geo-campo para uma vizinhança;
MédiaL Calcula a média local dos pontos para uma vizinhança especificada;
MaxL Determina o máximo local dos pontos do Geo-campo, dada uma
vizinhança;
MinL Determina o mínimo local dos pontos do Geo-campo, dada uma
vizinhança;
53
StdevL Calcula o desvio padrão dos pontos do Geo-campo, dada uma
vizinhança;
VarL Determina o número de valores distintos do Geo-campo, para uma
vizinhança em torno de cada ponto.
Sintaxe:
A sintaxe geral dos operadores locais é
<Geo-campo> = <operador_local> (<Geo-campo>,
<Local_region>);
onde a definição LOCALREGION pode ser implementada como um retângulo ou
um círculo. No primeiro caso, teremos:
<Geo-campo> = <operador_local> (<Geo-campo>,
<Retangulo>, <dim_h>,<dim_v>);
e no segundo:
<Geo-campo> = <operador_local> (<Geo-campo>,
<Circulo>, <raio>);
Parâmetros e Opções:
dim_h e dim_v - Dimensão da máscara vertical em número de células
raio - Dimensão do raio em número de células
Operadores zonais entre GEO-campos
Operações zonais são um subconjunto de operações de vizinhança onde a máscara são
substituídas por classes de um Geo-campo temático. O valor de cada posição do Geo-campo
gerado por uma operação depende do valor do atributo em todas as posições geográficas
que compõem a região no Geo-campo de origem.
54
Operadores Zonais:
MaxZ Determina o máximo zonal dos pontos do Geo-campo.
MinZ Determina o mínimo zonal dos pontos do Geo-campo.
MedZ Determina o médio zonal dos pontos do Geo-campo.
MaiZ Determina o maioria zonal dos pontos do Geo-campo.
MinoZ Determina o minoria zonal dos pontos do Geo-campo.
SomZ Determina o soma zonal dos pontos do Geo-campo.
VarZ (ou variabilidade), Determina a diversidade zonal dos pontos do Geo-
campo.
Sintaxe:
<campo> = <operador_zonal> (<Numerico>,
<Tematico>."Classe *");
3.4 Resumo das Operações sobre Geo-camposA Tabela 3.2 apresenta o resumo e a hierarquia das operações sobre Geo-campos
disponíveis em LEGAL:
Tabela 3.2 - Relação de Operadores sobre Geo-campos
CLASSIFICAÇÃO OPERADOR
Operadores Pontuais sobre Geo-ca mpos:
Operadores Unários:
Pondere Pondere
Fatie Fatie
Reclassifique Reclassifique
Operações Booleanas sobre Geo-ca mpos Atribua
Operações Matemáticas sobre Geo-c a mpos = <expressões matemáticas>
Operações Fuzzy sobre Geo-campo s Fuzzy, FuzzyR, FuzzyL
Operações de Vizinhança sobre Ge o -campos MaxZ, MinZ, MedZ, StdevL, SomZ, VarZ
Operações Zonais sobre Geo-camp o s MaxZ, MinZ, MedZ, MaiZ, MinoZ, SomZ, VarZ
55
CAPÍTULO 4
INTERFACES PARA ÁLGEBRA DE MAPAS
Segundo Oliveira (1996), "em Sistemas de Informações Geográficas (SIG), o modelo
conceitual não pode ser usado como modelo de representação para a interface (como
ocorre, por exemplo, com interfaces de bancos de dados relacionais). A modelagem de
dados em um SIG envolve conceitos espaciais usualmente expressos em estruturas de
baixo nível, que não são adequadas para a cognição espacial humana”. Mesmo assim, os
SIGs devem oferecer ao usuário as funcionalidades necessárias para que este possa
expressar seus modelos, fórmulas e procedimentos da maneira mais próxima possível da
sua percepção dos fenômenos espaciais.
O objetivo deste Capítulo é estabelecer os requisitos para o projeto de interface para
Álgebra de Mapas para o SPRING, serão revisados alguns conceitos de projetos de interface
usuário-computador, serão apresentados os paradigmas de interface e sua aplicação em álgebra
de mapas e serão revisadas algumas interfaces para álgebra de mapas existentes no mercado
ou propostas na literatura.
4.1 Projeto de Interfaces Usuário-ComputadorNo entender de Eberts(1994), “o projetista de interface deve conhecer a atividade cognitiva
do usuário a fim de projetar interfaces efetivas e fáceis de usar” Aspectos psicológicos da
teoria de cognição humana devem ser aplicados em Interfaces Usuário Computador (IUC)
para fazer com que o processamento das informações por parte do usuário seja rápido e
eficiente, reduzindo dúvidas e ambigüidades. O Projeto de Interface deve se basear no
Modelo Conceitual do sistema, concebido em uma fase anterior no processo de engenharia do
software, e no Modelo Mental do usuário, que é a forma como o usuário irá conceber o
funcionamento do sistema, como é ilustrado na Figura 4.1:
56
Projeto de InterfaceModelo Metal
Modelo Conceitual
Figura 4.1 - Processo de desenvolvimento de Projeto de Interfaces. Fonte: Adaptado de Eberts (1994).
O modelo conceitual deve estar o mais próximo possível do modelo mental, cabe ao projeto de
interface ajudar o usuário a formar um modelo mental conciso e coerente com o sistema. Uma
forma de fazer com que o modelo mental do usuário seja conciso é utilizando-se de
analogias e metáforas. O uso eficiente deste recurso visa minimizar o processo de
familiarização com o sistema. Para isto são escolhidos comandos, figuras e relacionamentos
semelhantes a situações rotineiras da atividade do usuário, para representar dados,
operadores, opções e relacionamentos no sistema informatizado.
4.2 Paradigmas de Interfaces para Álgebra de MapasNesta seção analisaremos paradigmas de interfaces aplicáveis a álgebra de mapas, os quais
são: interfaces por linha de comando ou linguagem de programação; interface por menus e formulários
e interfaces de manipulação direta. Foge ao escopo deste trabalho interfaces por linguagem
natural e comandos de voz e demais inovações que envolvem outra linha de pesquisa que
não a de interface gráficas com o usuário, ou Graphical User Interface (GUI).
4.2.1 Linhas de Comandos e Linguagens de Programação
Visão Geral
Neste categoria de interface, os sistemas oferecem uma ou mais linhas em branco onde o
usuário pode digitar uma expressão (no caso de linguagens de programação) ou comando
(no caso de interfaces por linha de comandos), informando ao sistema aquilo que pretende
que se faça. Para preencher estas linhas em branco, o usuário deve conhecer a sintaxe dos
comandos e expressões da linguagem.
Neste paradigma de interface, seu projetista tenta estabelecer metáforas através do uso de
expressões do jargão do usuário, com a finalidade de aproximar-se da sua linguagem
natural. "Na prática de SIGs este processo é prejudicado, muitas vezes, porque a estrutura
de dados acaba por influenciar na definição da linguagem, tornando necessário o uso de
termos como vector ou grid" (Lucena et al., 1997).
57
É necessário também que esta linguagem seja abrangente o suficiente para oferecer ao
usuário a facilidade de expressão de conceitos complexos na construção de modelos
espaciais com todos os operadores, parâmetros e tipos de dados necessários. Por este
motivo, a álgebra de mapas de Tomlin (1990) tem servido de referência para os projetistas
de SIG, no desenvolvimento de várias implementações.
Apesar da grande maioria do SIGs de mercado possuir interfaces gráficas baseadas em
ícones, menus e botões, o uso de linguagens de comando e linguagens de programação
continua sendo necessário para a realização de projetos complexos, que envolvem
procedimentos de modelagem. Entre as abordagens possíveis, podemos citar:
• Macro-comandos interpretados que operam através de através de
procedimentos atômicos (como o AML do ARC/INFO e os arquivos
“batch” do IDRISI e do GRASS). Cada comando tem de ser auto-contido
e fornecer todos os parâmetros necessários para sua operação.
• Linguagens de programação de propósito geral, às quais são acrescentados
operadores específicos de análise espacial e tipos de dados gráficos e
tabulares básicos (como o AVENUE do Arc/View ou o MapBasic do
Map/Info). Cabe ao usuário a responsabilidade de definir a semântica das
operações de análise espacial a partir dos tipos de dados básicos.
• Linguagens de programação específicas para geoprocessamento, com tipos
de dados de alto conteúdo semântico, como LEGAL, MAP e GRID. Os
programas são menores e mais legíveis, mas o usuário tem de seguir uma
seqüência estabelecida de organização de programa (como foi mostrado no
Capítulo 3), incluindo necessidades típicas de programação, tais como
declaração e instanciação.
O formalismo inerente às linguagens de programação, aliado à expressividade da linguagem
são pontos fortes para a defesa deste tipo de interação. Programadores de computador
trabalham a décadas e com sucesso documentando e desenvolvendo procedimentos
complexos desta maneira. Adicionalmente, uma vez desenvolvido e testado um modelo de
análise, na forma de um programa, o procedimento fica estabelecido, podendo ser
analisado, disseminado e reaproveitado.
58
As dificuldades do usuário com interface baseadas em linha de comandos e linguagem de
programação são (Bruns e Egenhofer 1997) :
! Memorizar um número grande de nomes de operadores;
! Escrever a sintaxe dos comando corretamente;
! Selecionar o operador apropriado para cada tarefa.
A prática mostra que aprender uma linguagem de comandos ou linguagem de programação
demanda uma certa quantidade de tempo, que irá depender de quão complexo são os
comandos e que experiência o usuário tem na aplicação em outras linguagens de
programação. Adicionalmente, um programa que descreva um modelo de análise só é
compreendido por pessoas que conhecem a mesma linguagem, limitando assim, sua
capacidade de disseminar de informações.
Exemplo - Arc/ Info:
O sistema Arc/Info (ESRI, 1992) possui vários modos de operação, como será vistos nos
exemplos. Na sua forma básica a interação se baseia em chamada de programas e passagem
de parâmetros, onde os dados são arquivos de entrada e saída para os comandos,
caracterizado portanto como Interface por Linguagem de Comandos (Figura 4.2).
Objetivo: determinar as regiões que distam 5 km das estradas em uma área dereflorestamento
1. Criar mapa de distância (arquivo roadbuffer) a partirdo mapa de estradas (arquivo roadlines), utilizar o módulo “arc”:Arc: buffer roadline roadbuf # # 5000 # line
2. Visualizar o resultado utilizar o módulo “arcplot”e informar os parâmetros:Arcplot: mapex roadbufArcplot: linecolor 2Arcplot: arcs roadlineArcplot: linecolor 5Arcplot: arcs roadbuf
Figura 4.2 - Exemplo de operação de análise no Arc/Info. Fonte: Tutorial do Arc/Info (Murmion, 1997)
Alguns módulos podem ser acrescentados ao mesmo sistemas conferindo-lhe outras
formas de interação. O módulo GRID (ESRI, 1992), por exemplo, adiciona ao sistema
uma linguagem de programação para álgebra de mapas, baseada nos trabalho de Tomlin
(1990).
OUTGRID = INGRID1 + INGRID2
59
OUTGRID = INGRID1 XOR 5
OUTGRID = SIN(INGRID1)*4/LOG(INGRID2)
Exemplo - OSUMAP:
O sistema OSUMAP (OSU, 1997) baseado na linguagem MAP (Tomlin, 1990)é um
exemplo clássico de interface por linha de comando em álgebra de mapas. Toda interação
se dá pela digitação de comandos no sinal de prontidão do sistemas: “>”, o que pode ser
observado na linha de baixo da tela do computador representada pela Figura 4-3. O usuário
pode solicitar ajuda ao sistema (comando “help”) e obter uma lista dos comandos
disponíveis (Figura 4.3), pode ainda solicitar a instruções sobre cada comando, p. ex.: o
comando “help expose” trás a sintaxe completa do comando “expose”.
Figura 4.3 – Interface por Linha de Comandos do OSUMAP.
60
4.2.2 Menus e Formulários
Visão Geral
O princípio básico deste paradigma é a existência de um questionário eletrônico, baseado
em campos texto, listas de opções, botões de múltipla escolha e outros recursos de
interface gráfica (GUI), onde o sistema pode auxiliar o usuário no preenchimento correto
dos campos, ex.: Figura 4.4.
Figura 4.4 – Interface de operações aritméticas no SPRING.
Em interface por menus existe um conjunto hierarquizado de opções para facilitar ao usuário a
busca por um operador apropriado. Se o sistema puder determinar qual o tipo de resultado
que o usuário pretende obter então ele desabilitar ou deixa de apresentar as opções
inconsistentes, o que facilitaria a construção de comandos corretos. Este procedimento é
chamado “seleção baseada em contexto” onde o contexto pode ser determinado, p. ex.,
pelo último dado selecionado.
Menus e formulários é o paradigma de interface utilizado nos SIG atuais para a maioria das
tarefas. Como as operações de álgebra de mapas requerem um conjunto amplo de
61
informações, alguns sistemas utilizam janelas de diálogo baseadas em formulário para que o
usuário estabeleça os parâmetros para a execução da operação.
Interfaces por formulários auxiliam o usuário na construção de comandos corretos. Uma vez
que todas as opções são apresentadas sob a forma de listas e botões de escolha, o comando
construído através de formulários fica livre de erros de sintaxe.
Os principais inconvenientes do uso de menus e formulários para operações de Álgebra de
Mapas são:
• Menus e janelas de diálogo com formulários costumam apresentar
sobreposições inconvenientes, escondendo partes da janela que deveriam
estar expostas no momento da definição dos parâmetros.
• Este paradigma não permite uma visão global da seqüência dos comandos
e do modelo de Análise Espacial.
• Normalmente, os formulários são preenchidos, executados e desaparecem
da tela, nem sempre sendo armazenados nem organizados como
procedimentos para ser reutilizados, e não ficam documentados como em
uma linguagem de programação. A menos que o sistema mantenha um
registro do que esta sendo executado não é possível recuperar a história
dos comandos e opções executados, para recuperar o modelo de análise
desenvolvido.
Em resumo, o uso de menus e formulários para álgebra de mapas só pode ser
recomendado para operações atômicas, que tenham grande significado independente e não
necessitem fazer parte de um procedimento mais elaborado. Os exemplos seriam
operações de declividade e fatiamento em modelos numéricos de terreno, mapas de
distância, geração de legendas.
Exemplo - IDRISI Windows:
O sistemas IDRISI Windows 1.0 (IDRISI, 1996), Figura 4-5, faz uso de janelas de diálogos
do MS_Windows com formulários para que o usuário especifique operações de análise
espacial. O usuário escolhe o operador adequado a sua tarefa em um sistema hierárquico de
62
menus, onde as opções estão agrupadas em subníveis, por tipo do operador, o que facilita
a localização do operador desejado.
Em alguns SIGs, cada operador de análise espacial tem um formulário próprio que solicita
ao usuários o preenchimentos dos campos referentes aos parâmetros que são necessário
para a sua execução.
Figura 4.5 - Formulário do operador “escalar” do IDRISIW.
Exemplo - MGE Intergraph
No sistema MGE Intergraph existe um único formulário para geração de comandos para
vários operadores. O usuários selecionar os operadores, operandos e opções através de
listas de opções. Conforme isto é feito o sistema responde ao usuário apresentando na
linha inferior do formulário o texto completo do comando, dá como está sendo
“montado”, o que pode ser observado na parte inferior da Figura 4.6:
63
Figura 4.6 - Formulário do MGE Intergraph.
Nota-se que neste tipo de interface o contexto é definido pelos valores preenchidos pelo
usuário, de forma que os campos que ainda não foram preenchidos listam somente opções
compatíveis com o contexto.
4.2.3 Interfaces por Manipulação Direta
Visão Geral
Interface gráfica baseadas em manipulação direta permitem a interação do usuário com o
sistema mediante o ato de apontar, mover ou conectar representações de objetos do
sistema na tela do computador. “A idéia central está em visualizar e identificar rapidamente
os objetos e operadores de interesse, substituindo os comandos de sintaxe complexas pela
manipulação direta de seus ícones.” (Adaptado de Shineidermann, 1992)
Alguns ensaios tem analisado a eficiência e a deficiência de interfaces por manipulação
direta. O trabalho de Eberts (1994) mostrou que, tomando-se uma interface baseada em
comandos e uma interface baseada em manipulação direta, o desempenho dos usuários
experientes tende a diminuir quando estes migram de sistemas baseados em comandos para
sistemas baseados em manipulação direta; usuários novatos tendem a apresentar melhor
desempenho se iniciam sua atividades em sistemas baseados em manipulação direta do que
em sistemas baseados em comandos, como indicado na Figura 4.7.
64
Figura 4.7 - Avaliação de Interfaces por Manipulação Direta. Fonte: Eberts (1994).
Interface Baseada em Diagrama de Fluxo
Diagramas são bastante empregados em ambientes CASE (Computer Aided Software
Engineering) e sistemas industriais. Neste tipo de interface, ícones são dispostos sobre a
tela de forma que o usuário possa fazer conexões entre eles estabelecendo uma seqüência,
da mesma forma como faria se estive simplesmente editando um diagrama estático.
Este paradigma oferece uma visão global e gráfica do procedimento em desenvolvimento.
A linguagem metafórica se restringe ao ícones e suas conexões e não à manipulação
propriamente dita (como no ato de arrastar um arquivo para a lixeira). Mas, na vida real, o
usuário não arrasta um mapa para sua prancheta de desenho, a fim de construir um
diagrama de fluxo com este mapa.
A metáfora principal não tem relação com a tarefa física desenvolvida pelo usuário, mas
sim com a forma de expressão de um problema através do encadeamento de tarefas em um
diagrama, técnica que é largamente utilizada em várias áreas do conhecimento e utilizada
em muitas publicações sobre aplicações de análise espacial (MacGuire e GodChild, 1992)
(Figura 4.8).
65
Engineering:gentle slopeclose to roads
Elevation
Roads
Slope
Coast
Slope
Coast
Elevation
Elevation
Coast
Slope
Elevation
Prox-R
Prox-C
Views
Aspect
Constraints
S-Pref
R-Pref
C-Pref
V-Pref
A-Pref
Development
Aesthetics:gentle slopegood viewwest aspect
Constraints:100m sefback<50% slope
Primarymaps
Derivedmaps
Interpretedmaps
Prescriptivemaps
Figura 4.8 – Diagrama de Fluxo em Análise Espacial. Fonte Berry (1991).
Interfaces de Manipulação Direta em Álgebra de Mapas
No caso de SIG, as interfaces de manipulação direta estão, na maior parte dos casos, ligadas
às interfaces por linguagens de programação, pois geram programas que podem ser
posteriormente executados.
As interfaces de manipulação direta dão uma visão global e gráfica do procedimento em
desenvolvimento, os modelos de análise ficam documentados de forma gráfica e bastante
expressiva. Ao contrário de programas em linguagem de programação não é necessário ser
especialista no software para se ter um entendimento mínimo do que faz o modelo.
No entanto, administrar diagramas muito complexos pode se tornar uma atividade extra
para usuário e tomar mais tempo do que o necessário. Em alguns casos o sistema precisará
de janelas de diálogo com alguns formulários para que o usuário informe parâmetros de
operadores ou expressões complexas que não podem ser expressas graficamente de forma
simples, tais como expressões matemáticas.
A aplicabilidade deste paradigma de interface, manipulação direta, para Geoprocessamento é
funcionar como suporte ao desenvolvimento de modelos de análise espacial de forma mais
cognitiva do que na própria linguagem de manipulação do SIG. Sua principal vantagem é
66
dar ao usuários uma visão global do procedimento de análise. Entre os principais exemplos
de interfaces de manipulação direta para álgebra de mapas, podemos citar:
• Geographer’s DeskTop ( citado por Bruns e Egenhofer, 1996);
• Grassland (LAS, 1997);
• Model Maker (ERDAS, 1993);
• VFQL (Standing, 1995).
Exemplo – Geographer´s Desktop
No Geographer’s Desktop (citado por Bruns e Egenhofer, 1996) como pode ser observado
na Figura 4.9, os objetos são apresentados em projeção perspectiva, um armário de mapas e
uma mesa de luz. As gavetas são abertas através de um “clique” do “mouse”, quanto então
os mapas aparecem flutuando sob o armário, também em projeção perspectiva, com seus
nomes ao lado. O usuário pode arrasta os mapas para mesa de luz na ordem que lhe
convier e estabelecer operações na pilha de mapas que se forma sobre a mesa de luz. Os
operadores apresentam uma outra metáfora, a de operações matemáticas sobre colunas de
valores.
A expressividade desta interface é grande. É praticamente um ambiente virtual onde os
mapas podem ser arrastados e sobrepostos. No entando, devemos observar que, sendo
agora um tecnologia mais acessível, os sistemas informatizados para Geoprocessamento
acabaram por abolir o uso de mesas de luz e sistemas manuais, o que prejudica esta
metáfora como forma de aproximação à rotina do atual usuário de SIG.
67
Figura 4.9 - Interface Baseada em Pilhas. Fonte: Bruns (1996) .
Este paradigma de interface baseada em Manipulação Direta resgata a metáfora da
manipulação, ou seja, o ato de arrastar e dispor dos ícones semelhantemente ao que é feito
na prática. Tal qual a operação em um ambiente “DeskTop” os ícones dos documentos são
arrastados e empilhados sobre os operadores que irão processá-los.
Exemplo - Grassland
Desenvolvido a partir do GRASS, o Grassland 1.1 (LAS, 1997) implementa sua interface
para análise geográfica baseada em fluxograma como pode ser visto na Figura 4.10. Os
dados e operadores são selecionados em janelas auxiliares e arrastados para a janela do
“Procedure Workbench”.
No “Procedure Workbench” o usuário pode fazer conexão entre dados e operadores para a
montagar diagramas de fluxo de dados. Tanto os dados quanto os operadores tem
terminais para as conexão, como “plugs” de tomadas. O formato e a cor do “plug”
identificam o tipo do dado, se é vetorial ou matricial, por exemplo. Isto para impedir que as
conexões sejam feita erroneamente. Selecionando-se o ícone do operador, uma janela com
formulário pede os parâmetros necessários. Estabelecida uma conexão de entra ou saída de
dado, automaticamente o campo apropriado do formulário, “mapa de entrada” ou “mapa
de saída”, é preenchido.
68
Figura 4.10 - Ambiente de Análise Espacial do Grassland. Fonte: Bruns e Egenhofer (1996).
Exemplo - Model Maker
Baseado na “Spatial Modeler Language” (SML) e fazendo parte do conjunto de módulos
do sistema IMAGINE (ERDAS, 1993), o Model Maker é um editor de diagramas de fluxo
aplicado a álgebra de mapas. Seu desenho é bastante simples é limpo, facilitando a leitura
do modelo. Existem ícones para cada tipo de dado, um único ícone para operador
(representado por um círculo) e as setas indicam a direção do fluxo de dados.
No procedimento de criação de um modelo o usuário seleciona em uma janela a parte, qual
o tipo de ícone ele deseja incluir no diagrama: grade, imagem, mapa temático ou um
operador. Neste ponto as conexões já podem ser feitas, mesmo sem terem sido definidos
que mapas e que operadores são aqueles representados pelos ícones. Portanto, o diagrama
é montado sem que o usuário tenha a certeza da disponibilidade do dado ou se o operador
é adequado para processá-lo, já que o sistema só pode checar a consistência das conexões
após obter do usuário estas informações.
69
Figura 4.11 – Diagrama de Fluxo do Model Maker. Fonte: Bruns e Egenhofer (1996).
Exemplo – VFQL
Visual Funcition Query Language (Standing, 1995) é uma ferramenta de interface por
manipulação direta que permiti a construção de operações de consulta e análise espacial,
através da geração de macros em linguagem AML (Arc/Info). A metáfora deste modelo de
interface se restringe aos ícones dos dados que representam mapas em papel semi
desenrolados (somente a parte escura da Figura 4.12). A indicação de que tipo de dado é
representado pelo ícone se dá pelo desenho este que contém, como por exemplo o
polígono (vide Figura 4-12) indica um dado temático. Cada um deste ícones escuros, na
forma de mapas semi desenrolados, aparecem desordenadamente em uma janela onde o
usuário pode arrastá-los para um outra região da interface onde serão conectados dados e
operadores.
70
Figura 4.12 – Operador de Buffer atuando sobre mapa temático “Lakes” noVFQL (Standing, 1995).
Um exemplo completo usando o VFQL (Figura 4.13) apresenta a sobreposição de
comandos, onde resultados intermediário são dados de entrada para o comando seguinte
construindo a expressão apresentada logo abaixo da figura:
Showattribs(Vegsite(Identify(Erase(Buffer(Roads,300),Buffer(Lakes,20)),Vegcn),VEGCN-ID=14 and INSIDE=1 and AREA=>2000))
Figura 4.13 – Virtual Functional Query Language.Fonte Standing (1995).
A proposta de VFQL se baseia em programação funcional, ou seja, seu objetivo é que o
usuário construa expressões de manipulação espacial, semelhante ao exemplo da Figura
4.13, e armazene-as no sistema como uma função. Então, cada função pode ser executada
independente de uma seqüência de operações. Isto difere de diagrama de fluxo de dados,
que se baseiam em programação procedural, caracterizada por registrar e seguir uma
seqüência ordenada de procedimentos.
4.2.4 Resumo
A revisão dos paradigmas de interface e sua implementação, feita na seção anterior, indica
que para álgebra de mapas em Geoprocessamento é interessante que o usuário possua, ao
mesmo tempo, uma linguagem de programação de grande poder expressivo, um sistema de
menus e formulários para executar operações atômicas e uma interface de manipulação direta
71
para expressar graficamente seqüência de procedimentos baseados em metodologias de
análise espacial. Neste sentido, o paradigma de diagrama de fluxos seria empregado com o
objetivo de auxiliar o usuário a compor seus modelo diretamente em um diagrama de fluxo
e gerar programas executáveis no SIG.
Um fator que determina de forma bastante decisiva o projeto de interface é o modelo de
dados do SIG sobre o qual a interface é desenvolvida. Se o modelo de dados é capaz de
representar a informação geográfica em níveis de abstração de mais alto nível, da mesma
forma a linguagem de programação e a interface de manipulação direta poderão representar
melhor o conhecimento do usuário em um nível mais elevado, ao construir o modelo de
análise espacial.
Por exemplo: na Figura 4.9, no Geographer’s Desktop, o operador "add" atua sobre o dado
solos (soil) e vegetação (veg), somando indistintamente os valores encontrados nos dois
mapas e criando como resultado o mapa "solos+vegetação" (veg+soil). Este comando não
explicita quais as classes de solos e vegetação serão combinadas no mapa resultante como
ocorre em uma expressão em LEGAL (vide Capítulo 3).
Outro problema nas interfaces analisadas: no Model Maker, baseado no sistema ERDAS,
os dados são armazenados diretamente pelo sistema de arquivo, não existe um modelo
conceitual que organize um banco de dados geográficos como no SPRING (vide Capítulo
2), já no Grassland, o modelo conceitual se restringe a separar os mapas de acordo com
suas estruturas de armazenamento de baixo nível, tais como raster, vector, line, point e
region. Além de impactar na qualidade da representação do conhecimento, a conseqüência
prática é que o usuário certamente terá dificuldade em encontrar o dado caso ele se
encontre em uma estrutura desordenada de arquivos e diretórios.
A partir da análise aqui apresentada, podemos concluir que:
• Dada a complexidade das aplicações de Geoprocessamento e a diversidade
de capacitação dos usuários, um SIG de propósito geral não pode estar
limitado a um único paradigma de interface, devendo idealmente combinar
as três alternativas: linguagens de comando ou linguagens programação; menus e
formulários; e interfaces de manipulação direta.
72
• Para usuários experiente, a metáfora de diagrama de fluxo traz a vantagem de
apresentar e documentar bem o modelo da análise espacial.
• Considerando o problema de aprendizado, diagramas de fluxo se baseiam em
programação procedural o que corresponde ao apelo mais didático,
expressivo e intuitivos deste paradigma.
Neste contexto, optou-se por desenvolver uma interface de Álgebra de Mapas baseada no
paradigma de diagramas de fluxo, que tenha como saída um programa na linguagem LEGAL.
Deste modo, pode-se estabelecer uma combinação ótima para satisfazer tanto usuários
experientes (que preferem a expressão direta do programa em linguagem) como iniciantes
(que terão uma ferramenta de fácil compreensão).
4.3 Requisitos para o projeto de Interface para Álgebra de MapasPara o desenvolvimento de um projeto de interface para álgebra de mapas, é necessário em
primeiro lugar o conhecimento do domínio do problema análise espacial e
geoprocessamento, como visto no Capítulo 2, e o conhecimento de uma descrição formal
para operações sobre dados espaciais tal qual o apresentado pela linguagem LEGAL
(Capítulo 3). Feita estas duas revisão é importante também analisar as alternativas existentes
no mercado e na literatura verificando as soluções adotadas e suas justificativas. Como
resultado deste processo de analise é possível então, elaborar uma lista com os requisitos
para a interface a ser proposta.
A lista de requisitos a seguir está dividida em: requisitos gerais de interface por
manipulação direta, requisitos específicos para álgebra de mapas e requisitos específicos
para o SPRING. As fontes bibliográficas das quais foram extraídos os requisitos são:
" dos critérios utilizados no trabalho de Bruns e Egenhofer (1996), que analisa
interfaces para álgebra de mapas em vários sistemas SIG comerciais: requisitos
1, 3, 4, 7, 8, 9;
" discussões sobre a tendência das interfaces (Halfhill, 1997): requisito 6;
" observações sobre personalização de interface para SIG, em Câmara e
Medeiros (1996) e Worboys (1996): requisitos 10 e 11;
73
" tópicos de projetos de interfaces em Sheniderrman (1993) e Eberts (1994):
requisitos 2 e 5;
" dos Capítulos 2 e 3 deste trabalho: requisitos 12 e 13.
4.3.1 Requisitos Gerais
1. Utilizar metáforas adequadas com o domínio da aplicação;
A escolha de metáforas irá agilizar o processo mental do usuário de
relacionar o símbolo com o seu conteúdo semântico. Interfaces baseadas
em comandos costumam adotar como comandos termos do jargão do
usuário o que é preferível a se adorar termos computacionais ou
matemáticos. Semelhantemente, interfaces baseadas em manipulação direta
necessitam relacionar seus ícones e a maneira de trata-los dentro de um
ambiente gráfico, com os elementos do cotidiano das tarefas executadas
pelo usuário.
2. Não trazer uma metáfora estranha ao domínio da aplicação;
Evitar apresentar uma outra metáfora que não seja aquela relacionada
diretamente com o contexto da aplicação pois pode causar ambigüidade.
3. Facilitar a construção de comandos corretos;
Apresentar formas assistidas de edição dos comandos e impedir que se
estabeleçam conexões incorretas.
4. Auxiliar na escolha do operador certo para a tarefa;
O sistema deve basear-se no contexto para listar e sugerir operadores
apropriados, oferecendo recursos de busca e seleção tanto de dados como
de operadores;
5. Ambiente dinâmico e interativo;
Oferecer ao usuário a sensação de controle sobre os elementos do sistema
através de um ambiente de trabalho dinâmico e interativo, onde o sistema
poça responder imediatamente aos atos do usuário.
74
6. Evitar a sobreposição de janelas;
O excesso de janelas se sobrepondo dificultam o diálogo entre o usuário e o
sistema, escondendo parte da informação justamente no momento de tomar
a decisão sobre a ação a ser executada.
7. Reduzir complexidades
Reduzir complexidades, sejam elas sintáticas ou gráficais. Oferecer uma
interação com os elementos da interface com regras simples e intuitivas e
dar suporte a administração de diagramas muito extensos.
4.3.2 Requisitos Específicos sobre Álgebra de Mapas
8. Expressar bem o modelo de análise espacial;
Facilitar a compreensão da lógica do modelo independentemente dos
rudimentos da linguagem e do sistema utilizado;
9. Documentar o modelo de análise;
Para seu uso posterior, difusão ou publicação dos resultados e da
metodologia.
10. Permitir a personalização de aplicações de SIG;
Segundo Câmara et. al. (1996), Sistemas de Informação Geográfica, de uma
maneira geral, têm aplicações tão diversificadas que seria necessário a
construção de uma interface para cada aplicação, e por este motivo é
importante que os SIGs permitam que o usuário configure e personalize a
interface da sua aplicação. Este não é um requisito específico de álgebra de
mapas mas de todo o conjunto de funcionalidade que o SIG pode oferecer
e que portanto influencia nas operações de álgebra de mapas. No entanto na
medida em que o usuário possa incluir seus modelos de análise no banco de
dados e possa reutiliza-lo, pode-se considerar que ele esteja personalizando
ama aplicação.
11. Extensiblidade
75
O sistema de interface deve ser extensível. Conforme os novos operadores
de são desenvolvidos, no decorrer da evolução do software, é necessário
incluí-los na interface, através de recursos que não impliquem em
reprogramar seu código mas sim reconfigurar o software, informando as
características de cada novo operador.
4.3.3 Requisitos Específicos para o SPRING
12. Gera programas em LEGAL
O sistema deve ser capaz de gerar código em LEGAL livre de erros.
13. Representar o modelo conceitual do SPRING
O sistema deverá se basear no modelo de dados do SPRING tanto no
acesso ao dados quanto na construção de expressões de análise.
14. Salvar e recuperar modelos no banco de dados do SPRING
O sistema deverá salvar os modelos de análise na mesma estrutura de
armazenamento do banco de dados do SPRING.
76
77
CAPÍTULO 5
INTERFACE AMO
Baseado na análise dos problemas envolvidos em interface para álgebra de mapas
apresentada no Capítulo anterior, neste Capítulo propomos uma interface que objetiva
atender aos requisitos levantados. A esta interface demos o nome de AMO, que significa:
Ambiente de Álgebra de Mapas Orientado por Objetos, ou simplesmente Álgebra de
Mapas por Objetos. Sua contribuição é utilizar a abordagem orientada por objetos como
forma de enriquecer semanticamente os elementos de um diagramas de fluxo a fim de
melhorar a interação do usuário experiente com o sistema, aumentar sua produtividade e
oferecer recursos de documentação de sues modelos, bem como aumentar a velocidade de
aprendizado de usuários novatos e facilitando a disseminação da tecnologia de
Geoprocessamento.
Este Capítulo apresenta e descreve AMO, justifica a escolha dos paradigmas de interface
utilizados em seu projeto, relacionando-os com os requisitos levantados no Capítulo
anterior. Apresenta também seu modelo de objetos e exemplos de sua utilização.
5.1 Descrição GeralPorque Álgebra de Mapas por Objetos? Os operadores de Álgebra de Mapas atuam sobre
os tipos de dados de maneira distinta, isto é, nem todos operadores são válidos para todos
tipos de dados; Em uma interface baseada em manipulação direta é importante que os mapas
expressem quais são os operadores válidos para seu tipo de dado como forma de reduzir o
esforço do usuário em selecionar operadores. Os conceitos básicos de orientação por
objetos, classe, métodos e instâncias, (Coad 1991) são empregados aqui de forma a suportar o
relacionamento dos dados como os operadores. Mapas são instâncias das classes a que
pertencem, p. ex.: Numérico, Temático, etc. Operadores podem ser entendidos como métodos
destas classes. Desta forma, selecionado um mapa de uma determinado classe, só são
apresentados os operadores válidos para esta classe, facilitando assim a escolha do
operador certo para a tarefa.
78
AMO apresenta um editor de diagramas de fluxo no qual o usuário pode desenvolver,
graficamente, algoritmos de Álgebra de Mapas. Estes algoritmos podem ser executados no
SIG, impressos como documentação de seus procedimentos e reaproveitados no
desenvolvimento de novos algoritmos.
5.1.1 Paradigmas Escolhidos
Em AMO adotamos o paradigma de manipulação direta baseado em diagrama de fluxos para
representar o encadeamento de procedimentos necessário à realização de um modelo de
análise espacial. “O diagrama de fluxo é uma forma eficiente de apresentar um modelo de
análise mostrando os dados envolvidos e a seqüência de transformação para atingir um
objetivo” (Lucena et al. 1998). Esta opção está fortemente relacionada com os requisitos
nº8 e nº9, “expressar bem o modelo de análise espacial” e “documentar o modelo de
análise”, da lista de requisitos do Capítulo anterior. Adicionalmente, o ambiente AMO irá
oferecer recursos específicos para a manutenção de diagramas extensos e complexos,
atendendo ao requisito nº7, “reduzir complexidades”.
AMO baseia-se também em outros aspectos do paradigma de manipulação direta como
arrastar-e-soltar (do termo em inglês: “drag-and-drop”), apresentando um “ambiente”
virtual onde o usuário navega (do termo em inglês: “browse”) em seus bancos de dados e
seleciona o mapa que será inserido no diagrama de análise, levando-o ao editor de
diagramas.
Outro paradigma implicitamente já mencionado é o de Interface Orientada por Objetos
onde “Para cada objeto, pode ser mostrado um menu de possíveis ações” (LabIUtil, 1998).
Mais especificamente: quando o usuário houver selecionado um dado na interface somente
as operações válidas para este tipo de dado estarão disponíveis. Por exemplo, o método
Fatie é um método válido para um plano de informação da categoria numérico, portanto
ele é apresentado como disponível e pode ser conectado com o ícone do dado e assim
encadear um procedimento. O objetivo é garantir a consistência semântica e simplificar a
construção do modelo de análise; reduzindo o risco de erros do usuário no momento da
escolha dos operadores e da montagem do procedimento de análise e assim atender ao
requisito nº3, “facilitar a construção de comandos corretos”.
79
Tendo em vista o proposto pelo requisito nº6 “Evitar a sobreposição de janelas”, optou-se
por um único documento e uma única janela para a interface de AMO. Além de evitar
sobreposições é uma tendência em sistemas de GUI em ambientes distribuídos ou NUI
(Network User Interface – Interface para usuários de rede). Para isto foram empregados os
objetos de interface gráficas notebook e pages, conforme será apresentado
posteriormente.
5.1.2 Material e Método
Como sistemas de suporte ao desenvolvimento de interface gráficas, AMO utiliza o Tcl/Tk
(tool command language e Toolkit de interface gráfica) (Ousterhout, 1994) originário da
universidade de Berkley (E.U.A.). Este ambiente de desenvolvimento de softwares bem
com suas extensões, foi escolhido devido a:
1. Portabilidade (funciona em ambiente Windows, UNIX e Macintosh);
2. Permite alta produtividade no desenvolvimento de interfaces gráficas interativas;
3. Oferece facilidade na integração de software;
4. Disponível gratuitamente na internet, tanto o Tcl/Tk quanto a maioria de suas
extensões.
5. Conta com o suporte de um grande número de usuários no mundo todo que
trocam informação constantemente através de lista de discussão na Internet.
Para suprir um deficiente da linguagem Tcl no manuseio de estruturas de dados complexas
e para dar suporte a programação orientada-a-objetos (POO), AMO utiliza a extensão [Incr
Tcl] (MacLennan, 1996). Que além de suportar POO ainda oferece um conjunto de
Widgets (Objetos de Interface Gráfica) em extensão aos do TK.
Para o acesso ao sistema de gerenciamento de dados do SPRING, AMO utiliza a extensão
TclOdbc, que adciona à linguagem Tcl, comandos de manipulação de bancos de dados em
Open Data Base Connection (ODBC), tais como linguagem SQL.
80
Como exemplo, na Figura 5-1 são apresentados os procedimentos para conexão com
ODBC; exemplo de consulta em SQL para acessar a lista de categorias do banco de dados
de nome ZEE; e a apresentação do resultado da consulta em um objeto de interface do
[incr Tcl], o scrolledlistbox.
Figura 5-1 – Exemplo de conexão com ODBC via Tclodbc.
A versão do SPRING utilizada é a disponível na internet em
www.inpe.br/spring. O banco de dados nos quais os testes foram desenvolvidos é o
Zoneamento Econômico Ecológico (ZEE), disponível também no mesmo endereço.
81
5.2 Estrutura de AMOA seguir descreveremos AMO através da sua estrutura de componentes e funções (vide
Figura 5.2):
S. Operadores S. Dados
Região de Seleção
E. Diagrama V . Código
Região de Edição
Tela Principal
Componentes Funções
AMO
Figura 5.2 – Estrutura hierárquica da interface de AMO.
Cada um dos componentes desta hierarquia será descrito de acordo com os itens abaixo:
! Componentes – Os objetos de interface gráficas (Widgets) que o compõe;
! Funções – Qual sua funcionalidade na interface de AMO;
! Justificativas – Qual sua relação com o requisitos de interface para Álgebra de
Mapas.
5.2.1 Tela Principal
Componentes:
A janela principal de AMO (vide Figura 5.3) é composta por uma barra de
menus, uma barra de ferramentas (conjunto de ícones) e um painel, construído
com o widget paned, que pode ser ajustado deslocando-o horizontalmente a
fim de conferir maior ou menos espaço para as duas regiões principais da
interface, a região de seleção” e a região de edição e visualização.
82
Figura 5.3 - Tela Principal de AMO.
Na parte inferior da tela encontra-se a barra de “status” que dá ao usuário
informações adicionais sobre o funcionamento do sistema, como por exemplo
qual o dado ou operador correntemente selecionado.
Função:
As funções disponíveis nos menus também são acessíveis através dos ícones na
barra de ferramentas, de maneira que o usuário tenha a opção de não ser
prejudicado pela sobreposição do menu. Ao posicionar o cursor sobre este
ícones, mesmo sem acioná-los o programa apresenta um texto que descreve
brevemente a função relacionada com o ícone, este recurso é conhecido com
balloon, em uma analogia a diálogos de histórias em quadrinho.
Justificativa:
Este desenho de interface tem por objetivo oferecer boa visualização tanto do
esquema do banco de dados quanto do diagrama do modelo de análise. Os
requisitos diretamente atendidos são “evitar a sobreposição de janelas”
(requisito nº6) e “auxiliar na escolha do operador certo para a tarefa” (requisito
nº 4).
83
5.2.2 Região de Seleção
Componentes:
O componente principal da região de seleção é o widget notebook que permite
compartilhar uma mesma região da janela com várias páginas de informação de
conteúdo distinto. A seleção entre as páginas se dá clicando os rótulos “Data”
e “Operator” na parte superior do objeto, conforme indicado na Figura 5.4:
Figura 5.4 - Região de Seleção em AMO.
Função:
A finalidade da região de seleção é permitir ao usuário consultar o sistema SIG,
seu esquema de banco de dados, suas instância de dados e os operadores.
Justificativa:
Atende ao requisito requisito nº6, “Evitar a sobreposição de janelas”.
5.2.2.1 Seleção de Dados
Componentes:
Dentro das páginas do notebook existe um widget do tipo hierarchy
que permite a criação de uma lista hierarquicamente organizada. N a região de
seleção de dados este widget é utilizado para mostrar o esquema conceitual do
banco de dados e sua instâncias (Figura 5.5).
Função:
84
A finalidade da região de seleção de dados é permitir ao usuário a consulta
hierárquica do seu dados no banco de dados do SPRING e a fazer a seleção
deste dados que comporão seu modelo de análise espacial.
Figura 5.5 - Seleção de Dados em AMO.
Justificativa:
Atende ao requisito: “ambiente dinâmico e interativo” (requisito nº5), devido a
possibilidade de navegar no modelo conceitual do banco de dados e por
permitir a manipulação direta dos planos de informação, arrastando-os para o
diagrama. Atende também ao requisito: “representar o modelo conceitual do
SPRING” (requisito nº13).
5.2.2.2 Seleção de Operadores
Componentes:
De forma semelhante a região de seleção de dados, a região de seleção de operadores os
operadores ficam dispostos em uma hierarquia que pode ser explorada
abrindo-se os itens nó da árvore nas caixas assinaladas com “+” e “−” (Figura
5.6).
Função:
Quando é selecionado um plano de informações de uma determinada categoria
somente os operadores que se relacionam com esta categoria ficam expostos na
85
hierarquia. Neste ponto, selecionando-se um operador o sistema instancia um
comando no diagrama com o referido operador.
Figura 5.6 - Região de Seleção de Operadores em AMO.
Justificativa:
Atende ao requisito (requisito nº4): “auxilia na escolha do operador certo para
a tarefa”. Seguindo a os conceitos de orientação por objeto já mencionados.
5.2.3 Região de Edição e Visualização
Componentes:
A finalidade região de edição e visualização é gerencia a construção de modelo de
análise. Sua descrição física se assemelha ao da região de seleção, ou seja, também
é composta por um notebook sendo que seus rótulos são: “Diagrama” e
“Code” indicando a edição de diagramas e a visualização do Código em
LEGAL respectivamente.
Função:
A finalidade é permitir ao usuário construir seu modelo de análise espacial.
Justificativa:
Atende ao requisito (requisito nº6) “evitar a sobreposição de janelas”.
86
5.2.3.1 Edição de Diagrama
Componentes:
É composta pelo widget scrolledcanvas, que implementa um região de
janela para manipulação gráfica, com controle de eventos de mouse e
apresentação de primitivas de interação gráficas. Este objeto de interface tem a
capacidade de se auto-ajustar em tamanho a medida que o diagrama cresce em
complexidade e espaço ocupado. Para isto o usuário pode utilizar as barras de
rolagem vertical e horizontal, encontradas à direita e a baixo respectivamente.
Função:
A finalidade da região de edição de diagramas é apresentar o diagrama de Álgebra
de Mapas e permitir sua edição.
Justificativa:
O requisitos atendido é (requisito nº1): “utilizar metáfora adequada como o
domínio da aplicação”, ou seja, AMO se baseia no tarefa do usuário em
elaborar modelos de análise espacial em diagrama de fluxo;
Atende ao requisito nº2, “não trazer metáfora estranha ao domínio da
aplicação”, como no caso de mesa de luz que já é uma tecnologia ultrapassada;
Atende ao requisito nº3, “ambiente dinâmico e interativo”, o usuário tem total
liberdade de fazer o desenho de seu diagrama;
Atende ao requisito nº7, “reduz complexidades”, é muito mais fácil de
aprender do que linguagens de programação;
Atende ao requisito nº8, “expressar bem o modelo de análise” porque permite
a fácil interpretação do procedimento e;
Requisito nº9: “documentar o modelo de análise” que é uma característica
própria de um diagrama.
87
5.2.3.2 Visualização de Código
Componentes:
O objeto de interface utilizado aqui é o scrolledtext que permite a
visualização e edição de textos com várias linhas.
Função:
Visualizar o código gerado em legal.
Justificativa:
Atende ao requisito “gera programas em LEGAL” (resuisito nº12). Outro
requisitos atendido é “evitar a sobreposição de janelas” (requisito nº6), já que
não é necessário que o usuário utilize um outro editor de texto apenas para ler
o programa gerado em LEGAL.
5.2.4 Funções Gerais de AMO (Barra de ferramentas e menus)
Componentes:
As funções de AMO tanto podem ser acessadas através do sistema de menus
como através dos ícones na barra de ferramenta (Figura 5.3).
Função:
Estas opções do menu e ícones da barra de ferramenta ativam as funções que
serão apresentadas nos itens a seguir, com as respectivas justificativas.
Justificativa:
A vantagem da barra de ferramentas é oferecer um acesso imediato, sem
percorrer a hierarquia do menu, e diminuir a sobreposição de janelas (resquisito
nº6).
5.2.4.1 Manutenção de modelos
Função:
88
Permitir gerenciar os arquivos que descrevem os modelos, podendo “salvar”
modelo, “abrir” modelo e criar um novo modelo, gravando-os no sistema de
arquivos com extensões “.amo” na estrutura de diretórios do banco de dados
do SPRING, atendendo ao requisito: “salvar e recuperar modelos no banco de
dados do SPRING” (requisito nº14).
Justificativa:
Documentar o modelo de análise. Atende parcialmente ao requisito nº10,
“permitir a personalização de aplicações de SIG”. Na verdade a interface do
SPRING não será personalizada por AMO mas o usuário poderá guardar seu
modelo no banco de dados do SPRING, com um procedimento de análise
criado por ele mesmo e disponível para quem desenvolver outros projetos no
mesmo banco, p. ex.: banco de dados: RIMA, projeto: “bacia do rio Madeira”,
modelo de análise: “metodologia de avaliação de impacto ambiental”.
5.2.4.2 Geração de Código em LEGAL
Função:
Gerar um arquivo com o programa fonte em LEGAL (requisito nº12) com
extensão “.alg”. Este arquivo poderá então ser submetido ao SPRING para
que sejam executados os procedimentos tal qual foram descrito pelo diagrama
do modelo.
Justificativa:
Esta é a função básica de AMO gerar código em LEGAL evitando a
complexidade de se escrever código em linguagem de programação, Requisito
nº 7).
5.2.4.3 Impressão de Modelos e Código em LEGAL
Função:
A função de impressão de modelo em AMO gera arquivos em “Postscript”,
um formato reconhecido e suportado por um bom número de dispositivos de
89
impressão tais como impressoras e plotadoras, e conta também com uma
janela de “preview” onde o usuário pode observar como será a disposição do
diagrama na folha antes que seja impressa.
Justificativa:
Atende ao requisito nº9, “documentar o modelo de análise”, além da impressão
propriamente dita, arquivo em “Postscript” pode ser anexado a trabalhos
técnico-científicos em editores de texto.
5.2.4.4 Configuração de Operadores
Função:
Para que AMO possa ser atualizado com novos operadores de LEGAL, é
necessário informar ao sistemas através de arquivos de configuração, sem que
seja necessário modificar seu código fonte a cada evolução de LEGAL.
Através dos comandos disponíveis no arquivo de configuração o usuário
projetista de LEGAL inclui novos operadores, identifica seu ícone, sua categoria
de saída e entrada, sejam elas mapas, tabelas, parâmetros, campos numéricos.
O projetista informa também a máscara da linha de comando a ser gerada em
LEGAL. Vide apêndice I.
Justificativa:
Isto confere a característica “Extensibilidade” observada no requisito nº11. O
projetista pode inclusive escolher um novo ícone para cada operador do
sistema.
5.2.4.5 Encadeamento
Função:
Esta função, ativada pelos ícones da Figura 5.7, permitem ao usuário definir os
encadeamento de dados e comandos:
90
Figura 5.7 - Funções de encadeamento de conectores.
Justificativa:
Atende ao requisito nº3, “facilitar a construção de comandos corretos”,
conforme já foi apresentado neste Capítulo. Atende também ao requisito nº4,
“Auxiliar na escolha do operador certo para a tarefa”, pois o usuário poderá, p.
ex., saber que o dado selecionado pode sofrer “ponderação” mas não
“fatiamento”. O ícone escolhido para identificar o operador poderá informa ao
usuário, qual o efeito da operação.
5.2.4.6 Configuração de dados e comandos:
Função:
A função de configuração faz com que AMO apresente uma janelas de diálogo
(Figura 5.8) de configuração, para dados e para operadores.
Figura 5.7 - Janela de Diálogo para Configuração de Variáveis.
Na configuração de variáveis o usuário deve modificar o nome de variável e
definir parâmetros para criação de novos planos de informações, tais como
resolução X, resolução Y, escala e valores mínimos e valores máximos. O
leiaute ira depender do tipo de dado selecionado, omitindo os parâmetros que
não pertencem ao contexto.
91
O mesmo procedimento se aplica a janela de configuração de comandos,
conforme a contexto a interface apresenta somente os campos que são
necessários (ex.: Figura 5.9):
Figura 5.9 - Janela de Diálogo para Configuração de Comandos.
Na configuração de comandos AMO oferece uma interface dinâmica, com
leiaute variável, dependendo da configuração do operador associado ao
comando, podendo configurar o comando de acordo os parâmetros
necessários.
Justificativa:
Atende ao requisito º3, “facilitar a construção de comandos corretos”, através
do uso de interface baseada em formulários.
5.3 Características VisuaisAs variáveis são representadas por uma cor associada a sua classe, as variáveis temáticas são
vermelhas, as variáveis numéricas são verdes e as variáveis imagem são azuis (Figura 5.10).
Esta cor aparece no contorno interno do ícone de variável e nos ícones de operadores.
Sendo que em se tratando de comandos está cor representa o tipo de dado que o operador
retorna.
92
Figura 5.10 - Ícone de uma Variável em AMO.
5.4 Modelo de InteraçãoAo iniciar o programa, o usuário procurar seu bancos de dados no sistema de arquivo de
seu computador ou na sua rede local; Abre o banco de dados e selecionar um projeto. A
partir deste ponto, a árvore de hierarquia passa a apresentar os níveis de abstração do
banco de dados segundo o esquema definido pelo próprio usuário no SPRING, como na
Figura 5.5. No primeiro nível está o nome do banco de dados como raiz de uma árvore
vista de cabeça para baixo; em seguida está o nome do projeto; o próximo nível são as
Categorias, identificadas pelo ícone das classes básicas que elas representam (imagem,
numérico, temático, cadastral e redes). As folhas desta árvore são os planos de informação. Os
símbolos “+” e “−” permitem “abrir” e “fechar” o nível hierárquico, escondendo ou não
seus níveis inferiores.
A seleção dos dados se dá por apontar o cursor sobre o ícone do dado e clicar o botão da
esquerda do mouse. Mantendo este botão pressionado e arrastando o cursos, o nome do
Plano de Informação acompanha o curso dando a impressão de estar-se arrastado do
banco de dados para a Região de Edição de Diagrama. Na Região de Edição de Diagrama
este dado passa se chamar variável é recebe um nome seqüêncial “variable0”, “variable1”, o
usuário de trocar este nome na função de configuração de elementos do diagrama (será
apresentada a seguir).
Quando um plano de informações é arrastado para esta região, ele passa a ter um ícone
próprio, composto do nome do plano de Informações, o ícone correspondente, e o nome
da variável no programa LEGAL a ser gerado. Em uma segunda página da Região de Edição
93
pode ser visto o código gerado em linguagem LEGAL. Quando um ícone de uma Categoria
é arrastado da Região de Edição de Diagrama, significa que será instanciado um novo Plano de
Informações daquela Categoria. O ícone que o irá representar tenho o nome de “*NOVO*” até
que o usuário o reconfigure.
Inicialmente a Região de Seleção de Operadores apresenta toda a lista hierárquica
conforme a classificação definida em arquivo de configuração de operadores, mas
selecionando-se um dado no diagrama faz com que a Região de Seleção de Operadores
apresente somente os operadores cuja conexão com este dado seja possível. Seleciona-se
um operador simplesmente clicando-se sobre seu nome da lista de operadores ou sobre o
seu ícone no diagrama, caso ele já esteva presente no modelo, como no caso de operadores
que tem mais de uma entrada.
5.4.1 Conexão de Comandos e Variáveis
A conexão se estabelece quando o usuário seleciona dois elementos do diagrama. Ao
apontar sobre o primeiro elemento e fazer um clique-duplo a borda externa do ícone deste
elemento, variável ou comando, fica amarela indicando que ele está selecionado. Após
selecionar o próximo elemento o programa pergunta ao usuário se ele deseja fazer uma
conexão entre os dois elementos selecionados, sendo que o sentido do fluxo de dado é
sempre do primeiro elemento selecionado para o segundo elemento selecionado.
5.5 Modelo de ObjetosNa figura Figura 5.11 temos o modelo de objetos que compõem o software AMO, tal qual
foi implementado em [incr Tcl] (MacLennan, 1996).
94
Figura 5.11 - Modelo de Objetos de AMO.
Observações: os objetos da classe Operator são instanciados quando o sistema lê o arquivo
de configuração. Os objetos da classe Infolayer e Category são carregados lendo-se o banco
de dados do SPRING. A cada operação seleção de dado e operador o sistema instancia um
“variavel” ou “commando” respectivamente.
5.6 ExemplosO procedimento a seguir é a ponderação de um mapa temático de vegetação, segundo um
tabela de ponderação. O algoritmo em AMO é representado pelo diagrama (Figura 5.12),
onde o plano de informação temático de nome “atualizado” é entrada para o operador
Pondere e cria um novo plano de informação do tipo Numérico.
95
Figura 5.12 - Exemplo de procedimento em AMO.
Para compor uma expressão completa de ponderação é necessário informar uma tabela de
ponderação. O que é feito apontando-se o operador e dando um clique-duplo sobre ele.
Isto faz com que apareça a janela de configuração de comandos, onde a tabela de
ponderação é informa conforme a Figura 5.13:
Figura 5.13 – Exemplo de tabela de ponderação em AMO.
96
O código gerado por AMO será processado pelo SPRING:
// Seção de Declaração
Tematico variavel0 ("vegetacao");
Digital variavel1 ("Numerico");
Tabela TbNotasVegetacao (Ponderacao);
// Seção de Instanciação
variavel0 = Recupere (Nome= "atualizado");
variavel1 = Novo (Nome="veget_ponderado", ResX=60, ResY=60 Escala=100000, Min=0,Max=3);
TbNotasVegetacao = Novo ( CategoriaIni="vegetacao",
"Fdt" : 1.0,
"arFdt" : 3.0,
"Fam" : 1.3,
"Fal" : 1.2,
"Sc" : 1.7,
"Scmd" : 1.8,
"Srmd" : 2.2,
"Sr" : 2.0 );
// Seção de Operação
variavel1 = Pondere (variavel0, TbNotasVegetacao);
Maiores detalhes e conclusões sobre a aplicação efetiva de AMO em Álgebra de Mapas será
apresentado no Capítulo seguinte.
97
CAPÍTULO 6
TUTORIAL DE AMO
Para exercitar os conceitos abordados por AMO e provar sua utilidade é necessário
apresenta-lo em aplicação completa e efetiva de álgebra de mapas no ambiente do
SPRING. Para isto, foi escolhida a metodologia do “Zoneamento Ecológico Econômico”
(Barbosa, 1998) por representar um conjunto de problemas comuns em análise espacial, em
aplicações ambientais, e por oferecer a complexidade necessária para comprovar as
vantagens de se utilizar AMO como gerador de programa em LEGAL. Os dados do
problema foram adquiridos através da página do SPRING na Internet (INPE, 1998), a
descrição do problema provem dos trabalhos de Barbosa (1998) e Barbosa et al. (1998).
O objetivo deste Capítulo é apresentar esta aplicação na foram de um tutorial,
apresentando passo a passo como ela foi desenvolvida em AMO.
6.1 Definição do ProblemaO objetivo desta aplicação é fazer um mapeamento do grau de resistência ao processo
natural de erosão de uma determinada região geográfica, estabelecendo os níveis de
vulnerabilidade conforme a metodologia que será apresentada.
Como a maioria das aplicações ambientais de Geoprocessamento, nesta aplicação são
utilizadas técnicas de integração de dados básicos de várias fontes. Segundo o
procedimentos metodológicos propostos pelo INPE e LAGET/UFRJ para ZEE
(Zoneamento Ecológico-Econômico) (Crepani et al., 1996) serão utilizados como fontes
primárias de dados: imagens de satélite e mapas temáticos pedológicos, geológicos, de
geomorfologia e de vegetação. O produto final é o mapa temático de vulnerabilidade à
erosão integrando dados do meio físico-biótico e dados sócio-econômicos.
Na metodologia para Zoneamento Ecológico-Econômico o uso de imagens de satélite
serve como base para definição de unidades de paisagem (chamadas unidades territoriais
básicas). Uma unidade territorial básica (UTB) exprime o conceito geográfico de zonalidade
98
através de atributos ambientais que permitem diferenciá-la de outras unidades vizinhas, ao
mesmo tempo em que possui vínculos dinâmicos que a articulam a uma complexa rede
integrada por outras unidades territoriais. Estas UTBs são definidas por foto-interpretação,
num processo manual de observação e identificação de regiões em imagens de satélite.
6.1.1 Metodologia do ZEE
A descrição sucinta desta metodologia adaptada de Barbosa et al. (1998) apresenta o
seguinte roteiro:
1. Levantamento e aquisição de material cartográfico e de imagens de satélite
! Adquirir imagens do sensor Thematic Mapper (TM) do satélite LANDSAT, bandas
3,4,5;
! Levantar dados bibliográficos da região;
! Adquirir mapas temáticos do RADAMBRASIL ( geológico, geomorfológico, solos,
fitoecológico) na escala 1:1.000.000;
! Adquirir carta topográfica da área de estudo na escala 1:250.000.
2. Preparação de “overlay” de interpretação
! Compilação cartográfica de pontos de referência, tais como drenagem, estradas,
cidades, etc., obtidos diretamente sobre a carta topográfica do IBGE, na escala
1:250.000.
3. Elaboração de mapa preliminar de Unidades Homogêneas
! Consiste na elaboração de um mapa preliminar de unidades homogêneas de
paisagem obtidas a partir da análise e interpretação das imagens do sensor
Thematic Mapper (TM) do satélite LANDSAT. Estas unidades homogêneas são
classificadas como unidades territoriais básicas (utbs).
4. Associação de mapa Unidades Homogêneas com dados auxiliares
! Consiste na associação de dados auxiliares temáticos preexistentes tais como,
mapas geológicos, geomorfológicos, mapas de solos e de cobertura vegetal, com o
99
mapa preliminar de unidades homogêneas obtido na etapa “C”. Esta associação
permite caracterizar tematicamente cada unidade homogênea.
5. Avaliação da vulnerabilidade de Unidades Homogêneas
! Estabelecer a vulnerabilidade natural de cada unidade homogênea considerando
a integrada da rocha, do solo, do relevo e da vegetação. Informações
complementares dos efeitos do clima e de uso da terra são também considerados.
! A estabilidade ou vulnerabilidade, resistência ao processo natural à erosão, são
utilizados para caracterizar uma unidade homogênea conforme os seguintes
aspectos de influência:
Tabela 6.1 - Fatores que influenciam na erosão. Adaptado de Barbosa (1998)
Geologia O grau coesão das rochas determinado pelaintensidade da ligação entre os minerais ou partículasque as constituem
Pedologia Atributos do solo: textura, estrutura, porosidade,permeabilidade, profundidade, e pedregosidade.
Geomorfologia Descrição do relevo: altitude, amplitude altimétrica,declividade e intensidade de dissecação peladrenagem.
Vegetação A vegetação evita o impacto direto contra o terrenodas gotas de chuva que promovem a desagregaçãodas partículas; impede a compactação do solo quediminui a capacidade de absorção de água; aumentaa capacidade de infiltração do solo pela difusão dofluxo de água.
! Para cada tema, repete-se o mesmo processo: para geologia, se o tipo de rocha
presente na unidade apresenta alto grau de coesão, atribui-se à unidade nota
próxima à estabilidade (1,0); se o tipo de rocha presente na unidade apresenta
valores intermediários no seu grau de coesão, atribui-se nota ao redor de 2,0 à
unidade; se o tipo de rocha presente na unidade apresenta baixa resistência à
erosão, pequeno grau de coesão, atribue-se nota próximo à vulnerabilidade
(3,0). Para determinação a classe de vulnerabilidade resultante de uma unidade
territorial básica é considerando simultaneamente a contribuição de todos os
temas, ou seja, a nota final de cada unidade pode ser obtida por uma média
100
entre as notas individuais de cada tema para cada unidade ambiental, como é
ilustrado na A Figura 6.1.
Figura 6.1 - Modelo para estimar a Vulnerabilidade Natural à Erosão de umaUnidade Territorial Básica.Fonte: Barbosa (1998).
6. Elaboração de carta de vulnerabilidade
! Gerar o mapa temático de vulnerabilidade a partir dos resultados numéricos
alcançados até então.
6.2 Elaboração do Modelo de Análise no SIGDe posse do mapa preliminar de unidades homogêneas de paisagem obtida a partir da
análise e interpretação visual de LANDSAT/TM e dos mapas temáticos de Geologia,
Geomorfologia, Pedologia e Cobertura Vegetal inseridos no banco de dados do SPRING
executar as seguintes operações de transformações nos dados (Barbosa, 1998):
1. Associar a cada um dos mapas base de Geologia, Geomorfologia, Pedologia e
Cobertura Vegetal os pesos que indicam a contribuição relativa de cada tema. A partir
de cada mapa temático, serão gerados modelos numéricos de terreno nos quais os
valores estarão entre o mínimo de 1 (estabilidade) e 3 (instabilidade).
101
2. Gerar os mapas derivados, através de uma operação zonal entre o mapa de unidades
territoriais básicas (UTB), obtido na etapa (1) com o modelo numérico de terreno
resultante da ponderação de cada mapa temático, obtido na etapa (2). Esta etapa deverá
produzir novos modelos numéricos, com a distribuição das contribuições da cada
componente do meio físico esteja homogeneizada pela zonalidade das UTBs.
3. Realizar uma operação de média ponderada entre os mapas gerados na etapa (3), o que
permitirá integrar a contribuição de cada componente do meio físico para as diferentes
UTBs. O dado resultante será um único modelo numérico, com valores entre 1 e 3.
4. Por fim, o proceder o fatiamento do modelo resultante, gerando assim uma carta
temática de vulnerabilidade natural a erosão.
6.3 Tutorial de AMOEntendido o problema e o modelo de análise é possível então iniciar a construção do
diagrama solução em AMO. As palavras que fazem parte da interface são apresentadas em
fonte ARIAL, para facilitar a indetificação. O primeiro passo se refere ao conexão aos banco
de dados no SPRING:
1º. Passo: Selecionar Banco de Dados e Projeto
Para iniciar um diagrama novo, após acionar o programa AMO, é necessário selecionar o
banco de dados e o projeto onde estão os dados da aplicação ZEE, no SPRING. Na região
de seleção, da janela principal de AMO, pode-se navegar pelo sistema de arquivo, a fim de
procurar o banco de dados desejado. (Figura 6.2).
102
Figura 6.2 – Seleção de Banco de Dados.
Um clique duplo sobre o nome do diretório, que neste tutorial é o ZEE, faz com que
AMO verifique se o mesmo é ou não um banco de dados do SPRING. No caso afirmativo,
AMO automaticamente conecta-se a este banco, e apresenta ao usuário a lista de seus
projetos, para o usuário seleciono o projeto desejado (também através de um clique-duplo
sobre o projeto desejado) (Figura 6.3). Neste tutorial o projeto escolhido é o “224”.
Figura 6.3 – Seleção de Projeto.
2º. Passo: Selecionar os Dados
Após a escolha do projeto, AMO apresenta a hierarquia do modelo conceitual do banco de
dados geográfico, conforme foi definida pelo usuário (Figura 6.4). Cada Categoria é
identificada por um ícone, tal qual um pasta, com um desenho que a destingue de acordo
com o modelo de dados que pertence (Temático, Numérico, Imagem, Rede, Cadastral, Não-
espacial, Objeto) e seu nome à direita. Um clique sobre os sinais “+” faz com que AMO
apresente a lista de Planos de Informações desta Categoria.
103
Figura 6.4 – Seleção de Dados.
Os Planos de Informação são identificados por um ícone, tal qual uma folha de papel, com o
mesmo desenho da sua Categoria e seu nome à direita. Um clique-duplo sobre o Plano de
Informação faz com que AMO instancie uma variável deste dado, criando um ícone na Região
de Edição de Diagramas. (Figura 6.5):
Figura 6.5 – Instanciação de Variável.
A qualquer momento, o usuário pode verificar o código gerado por AMO. Neste ponto é
possível verifiar a declação e instanção desta variável. Para isto, basta clicar sobre o nome
da pasta “Code” na Região de Edição. Neste exemplo, o código gerado até o momento é:
{//// Declaracao das Variaveis//Tematico variable0 ("pedologia");
//// Instanciacao das Variaveis//variable0 = Recupere (Nome="solo_atualizado");
//// Fim//}
Repete-se o mesmo procedimento para todos os dados de entrado do problema, ou seja, os
Planos de Informação: go_atualizado, gm_atualizado, solo_atualizado, veget_atualizado e utbas.
104
Para melhor posicionar os elementos no diagrama, basta apontar o cursor sobre eles,
pressionar e manter pressionado o botão esquerdo do mouse, enquanto se desloca a figura.
Quando a figura estiver no local desejado solta-se o botão do mouse.
3º. Passo: Seleção de Operadores
Seleciona-se a pastar “Operator” na Região de Seleção, o que faz com que AMO apresente
todos os operadores de análise geográfica do sistema (Figura 6.6). Navegando-se por esta
hierarquia é possível identificar quais os operadores que irão compor as expressões
desejadas (conforme apresentado no Capítulo 3), ou seja, para compor uma expressão que
resulte em um dado do tipo Númérico procura-se o operador apropriado na pasta
identificada por Numérico:
Figura 6.6 - Lista de Hierárquica de Operadores.
Um clique-duplo sobre o nome do operador faz com que AMO instancie um comando
com este operador no diagrama em edição (Figura 6.7).
105
Figura 6.7 - Criação de um Comando.
No caso do problema apresentado serão necessário quatro operações de ponderação, uma
para cada um dos temas, geologia, geomorfologia, pedologia e vegetação. Portanto, é
necessário instanciar mais três comandos de ponderação.
4º. Passo: Conectar Elementos
Para estabelecer uma conexão entre os dados e operadores basta selecionar o ícone destes
dois elementos, na ordem em que se deseja que o fluxo de dados ocorra. Por exemplo, para
conectar o dado “solo_atualizado” identificado pela variavel0 e o comando de ponderação,
é necessário dar um clique-duplo sobre a variavel0, o que faz com que a sua moldura fique
amarela, e em seguida dar um clique-duplo sobre o comando Ponderação. Aparece um
menu onde o usuário deve confirmar ou cancelar esta conexão.
Figura 6.8 – Criação de Conexões.
Confirmando a conexão é estabelecido um fluxo de dado entre os dois elementos do
diagrama conforme pode ser observado na Figura 6.9:
106
Figura 6.9 – Fluxo de Dados.
Para se cancelar um fluxo incorreto basta dar um clique-duplo sobre o linha do fluxo de
dados e escolher a opção “Remove” no menu que aparecerá em seguida.
5º. Passo: Criar Variáveis Novas
Os quatro comandos de ponderação que foram instanciados no diagrama irão produzir
resultados do tipo Numérico como saída, portanto é necessário criar variáveis novas do tipo
Numérico para serem conectas na saída, no lado direito, dos comandos. Para criar uma
variável quando ainda não existe seu Plano de Informações, basta selecionar a sua Categoria com
um clique-duplo. Selecione a pasta “Data” na Região de Seleção e de um clique duplo sobre a
Categoria identificada como: Numérico. desta forma, AMO irá criar uma nova variável da
mesma Categoria. Repetir o processo para cada um dos quatro comandos de ponderação e
estabelecer as conexões entre o comando e a nova variável (Figura 6.10).
Figura 6.10 – Criação de Novas Varáveis.
107
6º. Passo: Configurar Variáveis
No nome “*NOVO*” indica para o usuário que ele ainda não forneceu os dados para a
configuração de uma nova variável. Para fazer isto basta apontar o cursor para os ícones e
dar um clique-simples com o botão esquerdo do mouse. Aparecerá um menu com as
opções “Config”,“Remove” e “Cancel”, selecionando-se a primeira opção AMO irá
apresentar uma janela com um formulário para a configuração desta variável (Figura 6.11).
Observe que estas informações serão utilizadas para a criação de um novo Plano de
Informação, como poderá ser observado clicando-se sobre a pasta “Code” na Região de Edição.
Figura 6.11 – Formulário de Configuração de Variáveis.
O Usuário deve preencher os dados conforme as característica que se deseja para o novo
Plano de Informação. No caso desta aplicação os dados são os seguinte (Figura 6.12):
Figura 6.12 – Dados do Novo Plano de Informação.
Repetir o mesmo processo para os outros três resultados intermediários dos demais
comandos de ponderação.
7º. Passo: Configurar Comandos
108
Para configurar os comandos do diagrama, procede-se da mesma forma como foi feito para
ativada a janela de configuração de variáveis: Clicar com o botão da direita e escolher
“Config” (Figura 6.13):
Figura 6.13 – Janela de Configuração de Comandos.
O preenchimento do campo “comment” não é obrigatório mas é útil para documentar o
procedimento. Este comentário fará parte do código a ser gerado em LEGAL. Para
configurar o comando de ponderação é necessário criar um tabela de ponderação,
atribuindo valores numéricos às classes do tema do dado de entrada. É necessário dar um
nome a esta tabela, no campo “Table Name” e em seguida clicar no botão “Edit Table”.
Neste ponto AMO irá incluir nesta janela os campos necessário a inclusão dos elementos
da nova tabela (Figura 6.14). Para selecionar uma classe clique no ícone representado por
um triângulo e selecione um dos nomes que aparecem na lista.
Figura 6.14 - Configuração de Tabelas.
Deve-se repetir o mesmo procedimento para as todas as tabelas de ponderação com os
seguintes dados (Tabelas 6.2, 6.3, 6.4 e 6.5):
109
Tabela 6.2 – Tabela de Ponderação para Solos. Adaptado de Barbosa et al. (1998)
Classe ValorPB1 2.0PB5 2.0HG 3.0R1 3.0TR 2.0R2 3.0LV7 1.0LV8 1.0ar 3.0A 3.0
Tabela 6.3 – Tabela de Ponderação para Geologia. Adaptado de Barbosa et al.(1998)
Classe ValorpEx_c_xingu 1.5pEgp_g_grao_para 1.4pErn_f_rio_fresco 2.7pEac_gran_s_carajas 1.3pEse_f_sobrei 1.9pEia_form_Iriri 1.0pEav_gran_v_guilher 1.2pEgo_f_gorotire 2.6Qa_Qc_aluviao 3.0
Tabela 6.4 – Tabela de ponderação de Vegetação. Adaptado de Barbosa et al.(1998)
Classe ValorFdt 1.0ArFdt 3.0Fam 1.3Fal 1.2Sc 1.7Scmd 1.8Srmd 2.2Sr 2.0
110
Tabela 6.5 – Tabela de Ponderação de Geomorfologia. Adaptado de Barbosaet al. (1998)
Classe ValorSept 1.2Estb 1.3Espp 1.1Ei 1.9Egi 2.2dr 2.3drv 2.7dk 2.4dkr 2.6dke 2.5drt 2.1dkit 2.0dm 1.2dmit 1.4dcta 1.6dci 2.0atf 1.0apf 3.0dit 1.4dc 1.6
8º. Passo: Adicionar Operação de Média Zonal
Seguindo o proposto na seção 6.2, item 2, o próximo passo é executar operações de Média
Zonal tendo como referencia as UTBs. Para isto, deve-se repetir o mesmo procedimento
do Passo nº 3 para instanciar comandos, mas desta o operador será Média Zonal. Repetir
os Passos nº 5, 6 e 7, ou seja, Criar novas variáveis, configurar variáveis e configurar
comandos. Os parâmetros de configuração de variáveis sãos os mesmo Figura 6.12 (exceto
o nome do campo “infolayer name” que é único para cada Plano de Informação). A operação
de Média Zonal não necessita de nenhum parâmetro mas é possível inserir comentários.
111
Figura 6.15 – Inclusão da Média Zonal.
9º. Passo: Calcular Média
O próximo passo é fazer o cálculo da média dos valores resultantes das médias zonal de
cada tema; Instanciar um comando a partir de “Expressão Numérica” na hierarquia de
operadores; conectar as variáveis que contém os valores resultantes de Média Zonal e
Configurar o a expressão numérica (Figura 6.16):
Figura 6.16 - Configuração de Expressão Matemática.
10º. Passo: Criar Mapa de Vulnerabilidade
O resultado da expressão numérica anterior é um mapa de vulnerabilidade numérico, para a
gerar o resultado final é necessário fazer um fatiamento transformando as faixas de valores
112
em classes da Categoria Vulnerabilidade. É necessário construir um tabela de fatiamento,
informando as faixas de valores e as respectivas classes (Tebela 6.6):
Tabela 6.6 – Tabela de Fatiamento de Vulnerabilidade. Adaptado de Barbosa etal. (1998)
Faixas Classes
[1.0,1.0999] estavel
[1.0999,1.1999] estavel1
[1.1999,1.2999] estavel2
[1.2999,1.3999] estavel3
[1.3999,1.4999] moderadamente_estavel
[1.4999,1.5999] moderadamente_estavel1
[1.5999,1.6999] moderadamente_estavel2
[1.6999,1.7999] moderadamente_estavel3
[1.7999,1.8999] medianamente_estavel
[1.8999,1.9999] medianamente_est_vul
[1.9999,2.0999] medianamente_est_e_ou_vul
[2.0999,2.1999] Medianamente_vul_est
[2.1999,2.2999] Medianamente_vulneravel
[2.2999,2.3999] Moderadamente_vul1
[2.3999,2.4999] Moderadamente_vul2
[2.4999,2.5999] Moderadamente_vul3
[2.5999,2.6999] Moderadamente_vul
[2.6999,2.7999] Vulneravel1
[2.7999,2.8999] Vulneravel2
[2.8999,2.9999] Vulneravel3
[2.9999,3.0] Vulneravel
Para informa esta tabela o procedimento é o mesmo da edição de tabelas da Figura 6.14, ou
seja, configurar o comando Fatiamento, dar um nome para a tabela e editar as valores
mínimo e máximo da faixa e as classes correspondentes.
113
6.4 ResultadosO diagrama da solução desenvolvida em AMO pode ser observado na Figura 6.8.
Tomando-o como um programa, é possível observar perfeitamente as entradas de dados e
as transformações ocorridas ao longo de todo o procedimento:
Figure 6.17 - Motodologia ZEE desenvolvido em AMO.
6.5 Análise dos ResultadosO Programa gerado pelo AMO é funcionalmente idêntico ao código fonte digitado
diretamente em LEGAL e apresentado no trabalho de Barbosa et al. (1998). Portanto, não
cabe analisar os resultados dos mapas gerados.
Como citou Eberts (1994), os usuários “experts” tendem a preferir linguagens de
comandos e linguagens de programação, enquanto que interfaces por manipulação direta
são melhores aceitas por usuário novatos. Um dos objetivo de AMO é atingir ao público
114
iniciante em Geoprocessamento facilitando sua iniciação no uso de procedimentos
complexos de álgebra de mapas sem, ao mesmo tempo sobrecarrega-lo com o aprendizado
de linguagem de programação. Programando em AMO, o usuário fica desobrigado de lidar
com conceitos de programação tais como variáveis, declaração e instanciação de variáveis,
chamada de funções e formato de parâmetros.
A programação de álgebra de mapas em AMO é feita de forma linear. Os procedimentos
são estabelecidos e detalhados em uma única seqüência e o usuário faz todas as conexões
para depois preencher as janelas de configuração. Ao escrever código em LEGAL, o
usuário trabalha de forma não linear, p. ex.: define as tabelas antes de definir o operador.
Neste sentido, uma interface AMO apresenta um resumo da parte operacional do
procedimento, permitindo ao usuário uma apreensão cognitiva imediata da metodologia
adotada. Consideramos assim que o AMO, uma vez tornado operacional, provavelmente
será mais utilizado que a programação direta em LEGAL.
115
CAPÍTULO 7
CONCLUSÕES
Este trabalho apresenta um protótipo de interface para Álgebra de Mapas que gera código
de programas em linguagem LEGAL. Com base na revisões das interfaces para Álgebra de
Mapas da literatura, no modelo de dados geográficos do SPRING e na definição da
linguagem LEGAL, propomos e implementamos uma interface para Álgebra de Mapas,
baseada em conceitos de orientação-por-objetos.
As principais vantagens do programa AMO são:
• Permitir a expressão, sob forma de diagrama de procedimento, de uma metodologia
complexa para Análise Espacial;
• Representar de forma cognitiva o modelo de análise espacial utilizado pelo usuário;
• Realizar a tradução automática dos diagramas para a linguagem LEGAL.
• Compõe um ambiente de rápido desenvolvimento de programas de Álgebra de
Mapas.
7.1 Melhorias Propostas e Direções FuturasPodemos apontar algumas melhorias e direções futuras para este trabalho:
• O uso de AMO como executor de programas em LEGAL e não simplesmente um
gerador de código. Para isto seria necessário uma integração mais forte com o
SPRING.
• A extensão do AMO para ler programas escritos em LEGAL, permitindo
apresentar graficamente o modelo de aplicação utilizado. Um programa escrito em
LEGAL tem todos os atributos necessários à criação de um diagrama a não ser a
posição de seus elementos. Para tanto é necessário dotar AMO de um interpretador
de LEGAL e um algoritmo de construção de diagramas.
116
• A extensão de AMO para gerar programas de Álgebra de Mapas em diferentes
sistemas (como ARC/INFO, IDRISI e GRASS), tornando-se uma poderosa
ferramenta de interoperabilidade, permitindo a rápida expressão de um mesmo
modelo em ambientes distintos;
• A realização de ensaios de usabilidade (LabIUtil, 1998) com usuários experientes em
análise geográfica e com novatos, pedindo que reportem a experiência a fim de
validarmos a interface e recolher-mos críticas e sugestões de melhoria;
• Dotar AMO da funcionalidade de visualização dos dados geográficos e tabelas do
sistema para facilitar o processo de análise do usuário.
7.2 ContribuiçõesTrata-se de um trabalho de pesquisa tecnológica, que apresenta como resultado principal a
interface AMO para desenvolvimento de programas em LEGAL. As contribuições que
este trabalhos oferece são:
• O AMO, como gerador de código em LEGAL poderá vir a se tornar um produto
de distribuição através da Internet, da mesma forma que o SPRING.
• O produto desenvolvido é uma ferramenta bastante útil na disseminação de
tecnologia de Geoprocessamento.
• A lista de requisitos, e toda a análise desenvolvida neste trabalho tem aplicação em
outros trabalhos relacionados com o tema.
117
REFERÊNCIAS BIBLIOGRÁFICAS
Barbosa, C. C., Álgebra de Mapas e suas aplicações em Sensoriamento Remoto eGeoprocessamento. São José dos Campos, Dissertação (Mestrado em Computação
Aplicada) - Instituto Nacional de Pesquisas Espaciais, 1998.
Barbosa, C. C.,Câmara, G.,Medeiros J. S., Crepani,E., Novo, E., Cordeiro, J. P. C.,
Operadores Zonais em Álgebra de Mapas e Sua Aplicação a Zoneamento Ecológico-
Econômico, Simpósio Brasileiro de Sensoriamento Remoto, Santos, 1998. Anais.
Berry, J. K. in: Maguire,D., Goodchild, M., Rhind, D. ed. Geographical InformationSystems: Principles and Applications. New York: John Wiley and Sons, 1991.
Bruns, T. e Egenhofer, M., Web-Top Interfaces for GIS Map Algebra. [online].
<http://www.cs.umd.edu/projects/hcil/People/tbruns/gisjournal/webalgebra.html>.
Fev. 1997.
Burrough, P. A., Principles of Geographical Information Systems for Land ResourcesAssesment, Oxford Science Publications, 1986.
Câmara, G. e Medeiros S., Geoprocessamento para Projetos Ambientais, VIII Simpósio
Brasileiro de Sensoriamento Remoto, Salvador-BA, 1996. Anais.
Câmara, G., Casanova, M., Hemerly, A.., Magalhães, G., Medeiros C. Anatomia deSistemas de Informação Geográficas, Campinas: UNICAMP, 1996. (Série X-Escola
Brasileira da Computação)
Câmara, G., Modelos, Linguagens e Arquiteturas para Bancos de Dados Geográficos.
São José dos Campos, Dissertação (Doutorado em Computação Aplicada) - Instituto
Nacional de Pesquisas Espaciais, 1995.
Câmara, G.; Souza, R. C. M.; Freitas, U. M. Paiva, J. A. C. SPRING: Concepção, Evolução,
Perspectivas. In: VII Simpósio Brasileiro de Sensoriamento Remoto, Curitiba-PA, 1993.
Anais, São José dos Campos: INPE, 1993.
Coad, P. e Yourdon E., Projeto Baseado em Objetos, Editora Campus, 1991.
118
Crepani. E., Medeiros, J. S., Azevedo, L. G.; Hernandez, P.; Florenzano, T. G., Duarte, V.
Curso de Sensoriamento Remoto Aplicado ao Zoneamento Ecológico-Econômico. São José dos Campos: INPE. 1996.
Eberts, Ray E., User Interface Design, Prentice Hall, 1994.
Egenhofer, M. and Richards, J. in McMaster, R. and Armstrong, M., ed. The Geographer’sDesktop: A Direct-Manipulation User Interface for Map Overlay. Minneapolis:
Auto-Carto 11, 1993. p. 63-71.
ERDAS, Model Maker Tour Guide, Atlanta: ERDAS Inc. 1993.
ESRI, GRID User's Guide. Redlands: Environmental Systems Research Institute, Inc.
1992.
Goodchild, M., Haining, R.P., Wise, S. Integrating GIS and spatial data analysis: problems
and possibilities. International Journal of Geographical Information Systems, 1992.
p. 407-423
Halfhil, Good By GUI, Hello NUI, Byte Magazine, p. 32-33 Set. 1997
I.S.O. International organization for Standardization / International Electrotechanical
Commission. Information Technology - Software Product evaluation - Qualitycharacteristics and guidelines for use. - ISO/IEC 9126, Genève: ISO, 1991.
IDRISI, IDRISI Project at Clark University, [online]. <http://www.idrisi.clarku.edu>.
Mar, 1996
INPE, Home Page do SPRING , [online]. <http://www.dpi.inpe.br/spring>. Mar. 1998.
LabIUtil, Ergonomia de Interfaces Homem-Computador, [online]. <ftp://ftp.ctai.rct-
sc.br/pub/labutil/apost4-2.zip>. Mar 1998.
LAS, Grassland, The land of Geographic Resources Analysis Support System, [online].
<http://www.las.com/grassland>. Mar. 1997.
Lucena, I., Câmara., G., Nascimento, M., AMO – Algebra de Mapas Orientada por Objetos,
IV Congresso e Feira para Usuários de Geoprocessamento da Amárica Latina [CD-
ROM]. In: GIS Brasil 98, Curitiba, 1998. Anais., Curitiba: Sagres, 1998. Seção de
Comunicação Técnico-Científica.
119
Lucena, I., Câmara., G., Nascimento, M., Interfaces para Algebra de Mapas, III Congresso e
Feira para Usuários de Geoprocessamento da Amárica Latina [CD-ROM]. In: GIS Brasil
98, Curitiba, 1997. Anais., Curitiba: Sagres, 1997. Seção de Comunicação Técnico-
Científica.
MacLennan, M. Object-Oriented Programing with [incr Tcl], Bell Labs Innovations for
Lucent Techologies, 1994.
Maguire,D.; Goodchild, M.; Rhind, D. Geographical Information Systems: Principlesand Applications. New York: John Wiley and Sons, 1991.
Murnion, S., ARC/INFO tutorial Home Page [online]. < http://boris.qub.ac.uk/shane/
arc/ARChome.html >. Fev. 1997.
Oliveira J. L. e Medeiros, C. B., Tutorial: User Interface Architecture, Languages, and Models
in Geographic DataBases, XI - Simpósio Brasileiro de Banco de Dados, São Carlos:
1996.
OSU, OSUMAP, Ohio State University Map Analysis Package for the PC, [online].
<http://thoth.sbs.ohio-state.edu>. Mar 1997.
Ousterhout, J. k., Tcl and the Tk Toolkit, Adison Wesley, 1994. (professional Computing
Series)
Shineiderman, B. Designing the User Interface, Stratgies for Effecitive Human-Computer Interaction. Addison Wesley. 1992.
Standing, C., Roy, G. G., Functional visual programming interface to geographical
information systems, Interacting with Computers, v. 7, n. 3, p. 82, Jan 1995.
Tomlin, D. Geographic information systems and Cartographic Modeling. New York:
Prentice Hall, 1990.
Worboys, M., GIS - A Computing Perspective, United Kingdown: Taylor & Francis, 1995.
121
APENDICE A
CONFIGURAÇÃO DE OPERADORES DE ÁLGEBRA DE MAPAS
Arquivo D:/amo/class/Operator.tcl
## [incr TCL] Class Operator of AMO#
class Operator {
inherit Tree
public variable Model ""public variable Label ""public variable Name ""public variable Icon ""public variable LIcon ""public variable Color "Gray3"public variable Inputs ""public variable Table falsepublic variable TabLabels ""public variable Mask ""public variable Token ""public variable Expression falsepublic variable Description "Descricao nao
fornecida"
constructor {name label model} {global icon;
set Name $nameset Label $labelswitch [string tolower $model] {
root {set Model 0}imagem {set Model 1}numerico {set Model 2}tematico {set Model 4}redes {set Model 8}nespacial {set Model 16}cadastral {set Model 64}objeto {set Model 128}
}if {$Model != 0} {
if {$Name == "group"} {set LIcon $icon(cat,$Model)
} else {set LIcon $icon(pi,$Model)
}
122
}}public method set_table {true_or_false} {set Table[string tolower $true_or_false]}public method set_expression {true_or_false} \
{set Expression [string tolower $true_or_false]}public method set_description {text}{set Description$text}
public method set_icon {file} {set icon $file}public method add_tablabel {label} {lappend TabLabels
$label}public method set_mask {args}public method add_input {indice times name type}
}
body Operator::add_input {indice times name type} {lappend temp $indicelappend temp $timeslappend temp $nameset type [string tolower $type]if {$name == "infolayer"} {
switch $type {imagem {set aux 1}numerico {set aux 2}tematico {set aux 4}redes {set aux 8}nespacial {set aux 16}cadastral {set aux 64}objeto {set aux 128}
}lappend temp $aux
} else {lappend temp $type
}lappend Imputs $temp
}
body Operator::set_mask {mask token} {set Mask $maskset Token $token
}
## ###################################################################
123
Arquivo D:/amo/etc/operators.cfg
## This file configure the Map Algebra Operators#
## Group and Operators:#
#Class Id {Name,form,group) LabelModel(output)#-------.----------.-----------------.---------------------.---------.Operator root group "Operadores" rootOperator img group "Imagem" imagemOperator num group "Numéricos" numericoOperator tem group "Temáticos" tematicoOperator red group "Redes" redesOperator cad group "Cadastrais" cadastral
Operator temclas Class "Classe" numericoOperator temfatie Fatie "Fatiamento" numericoOperator temrecla Reclassifique "Reclassificação" numericoOperator tematrib Atribua "Expressão Booleana" numericoOperator temexpr "= expr num" "Expressão Numérica" numerico
Operator imgexpr "= expr img" "Expressão Imagem" imagemOperator imgmat "= expr mat" "Função Matemática" imagemOperator imgreal "= real" "Real" imagemOperator imgbool "= expr bool" "Booleanos" imagem
Operator numexpr "= expr num" "Expressão Numérica" numericoOperator nummat "= mat func" "Função Matemática" numericoOperator numpond Pondere "Ponderação" numericoOperator numzons group "Zonais" numericoOperator numbool "= expr bool" "Booleanos" numerico
Operator nz_min MinimoZonal "Mínimo zonal" numericoOperator nz_max MaximoZonal "Máximo zonal" numericoOperator nz_med MediaZonal "Média zonal" numericoOperator nz_mai MairiaZonal "Maioria" numericoOperator nz_mino MinoriaZonal "Minoria" numericoOperator nz_sun SomaZonal "Soma" numericoOperator nz_over Overlay "Overlay" numericoOperator nz_buf Bufffer "Buffer" numerico
Operator numlocs group "locais" numerico
Operator nl_min MinimoLocal "Mínimo local" numericoOperator nl_max MaximoLocal "Máximo local" numericoOperator nl_med MediaLocal "Média local" numericoOperator nl_sun SomaLoca "Soma local" numericoOperator nl_dvp DesvPadrao "Desvio Padrão" numerico
124
Operator nl_vari Variedade "Variedade" numerico
125
## Hierarqy of Operators:##parent-ID add child-ID#----------.---.------------.root add imgroot add numroot add temroot add redroot add cad
img add imgexprimg add imgmatimg add imgrealimg add imgbool
num add numexprnum add nummatnum add numpondnum add numlocsnum add numzonsnum add numbool
numlocs add nl_minnumlocs add nl_maxnumlocs add nl_mednumlocs add nl_sunnumlocs add nl_dvpnumlocs add nl_vari
numzons add nz_minnumzons add nz_maxnumzons add nz_mednumzons add nz_mainumzons add nz_minonumzons add nz_sunnumzons add nz_overnumzons add nz_buf
tem add temclastem add temfatietem add temreclatem add tematribtem add temexpr
## Configure Operators here:##
#ID instruction values#----------.---------------.-----------------------------------------.numpond set_table truenumpond add_tablabel "classe"numpond add_tablabel "valor"numpond add_input A: 1 infolayer tematico
126
numpond set_mask "%s = Pondere(%s,%s);" "output,A,table"
nz_med add_input A: 1 infolayer numericonz_med add_input B: 1 infolayer tematiconz_med set_mask "%s = MediaZonal(%s.Class *);""output,A,B"
temfatie set_table truetemfatie add_tablabel "mínimo"temfatie add_tablabel "máximo"temfatie add_tablabel "classe"temfatie add_input A: 1 infolayer numericotemfatie set_mask "%s = Fatie(%s,%s);" "output,A,table"
numexpr set_expression truenumexpr add_input A: N infolayer numericonumexpr set_mask "%s = %s" "output,expression"
## Return de zero level of Operators hierarqy## It most be the last line code:
return root
