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
681.322.0 : 528.711.7 LUCENA, I. S.
Projeto de interfaces para álgebra de mapas em cessamento no ambiente SPRING / I. S. Lucena – São José dos Campos: INPE, 1998.
126p. – (INPE-9307-TDI/820).
Aprovado pela Banca Examinadora em cumprimento a requisito exigido para a obtenção do Título de Mestre em
Computação Aplicada.
"Quem dentre vós é sábio e entendido? Mostre
pelo seu bom procedimento as suas obras em mansidão de sabedoria. Mas, se tendes
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.
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
DESIGN OF MAP ALGEBRA INTERFACE FOR GEOPROCESSING AT SPRING ENVIRONMENT
ABSTRACT
SUMÁRIO
LISTA DE FIGURAS Pág.
LISTA DE TABELAS
LISTA DE SIGLAS E ABREVIATURAS
CAPÍTULO 1 – INTRODUÇÃO 19
1.1 – Objetivos ... 20
1.2 – Organização ... 21
1.3 – Contribuições ... 22
CAPÍTULO 2 - CONCEITOS DE GEOPROCESSAMENTO 23 2.1 - Modelagem de Dados Geográficos ... 23
2.1.1 - Universo Conceitual ... 23
2.1.2 - Universo de Representação ... 25
2.2 - Estrutura de um Banco de Dados Geográficos ... 28
2.2.1 - Instanciação do modelo ... 29
2.3 - Análise Espacial ... 30
2.3.1 - Operações sobre Campos ... 30
2.3.2 - Operações sobre Objetos ... 31
2.3.3 - Operações entre Campos e Objetos ... 32
2.3.4 - Relações de Operadores ... 33
CAPÍTULO 3 - CONCEITOS DE GEOPROCESSAMENTO 35 3.1 - Classificação de LEGAL ... 35
3.2 - Características de LEGAL ... 35
3.2.1 - Classes do modelo de dados e sua representação em LEGAL ... 36
3.2.2 - Seções de um Programa em LEGAL ... 36
3.3 - Classificação de Operadores em LEGAL ... 44
3.3.1 - Operadores entre Geo-campos ... 44
3.4 - Resumo das Operações sobre Geo-campos ... 54
4.2.2 - Menus e Formulários ... 60
4.2.3 - Interfaces por Manipulação Direta ... 63
4.2.4 - Resumo ... 70
4.3 - Requisitos para o projeto de Interface para Álgebra de Mapas ... 72
4.3.1 - Requisitos Gerais ... 73
4.3.2 - Requisitos Específicos sobre Álgebra de Mapas ... 74
4.3.3 - Requisitos Específicos para o SPRING ... 75
CAPÍTULO 5 - INTERFACES AMO 77 5.1 - Descrição Geral ... 77 5.1.1 - Paradigmas Escolhidos ... 77 5.1.2 - Material e Método ... 78 5.2 - Estrutura de AMO ... 80 5.2.1 - Tela Principal ... 81 5.2.2 - Região de Seleção ... 83
5.2.3 - Região de Edição e Visualização ... 85
5.2.4 - Funções Gerais de AMO (Barra de ferramentas e menus) ... 87
5.3 - Características Visuais ... 91
5.4 - Modelo de Interação ... 92
5.4.1 - Conexão de Comandos e Variáveis ... 93
5.5 - Modelo de Objetos ... 93
5.6 - Exemplos ... 94
CAPÍTULO 6 – TUTORIAL DE AMO 97 6.1 - Definição do Problema ... 97
6.1.1 - Metodologia do ZEE ... 98
6.2 - Elaboração do Modelo de Análise no SIG ... 100
6.3 - Tutorial de AMO ... 101
LISTA DE FIGURAS
Pág.
2.1 Componentes básicos da representação vetorial: Ponto, Linha e Região ... 25
2.2 Estrutura Topológica ... 26
2.3 Exemplo de Sensoreamento Remoto ... 27
2.4 Exemplo de Mapa Temático ... 27
2.5 Exemplo de definição do Esquema Conceitual ... 29
2.6 Representação ... 30
3.1 Três seções de um programa em LEGAL ... 37
3.2 Sintaxe da declaração de Planos de Informação ... 38
3.3 Sintaxe da declaração de tabelas de transformações ... 38
3.4 Sintaxe da Instanciação de Planos de Informação ... 39
3.5 Sintaxe da instanciação de Tabelas ... 39
3.6 Sintaxe geral para Operações em LEGAL ... 41
3.7 Sintaxe de Operações sobre IMAGEM ... 41
3.8 Sintaxe de Operações sobre NUMERICO ... 42
3.9 Sintaxe para Operações sobre TEMATICO ... 42
3.10 Sintaxe de Expressões Condicional ... 43
3.11 Sintaxe de Expressões Booleana ... 44
3.12 Classes de Operadores ... 45
3.13 Operação de Fatiamento ... 46
3.14 Operação de Ponderação ... 47
3.15 Operação Matamática ... 50
4.1 Processo de desenvolvimento de Projeto de Interfaces ... 56
4.2 Exemplo de operação de análise no Arc/Info ... 58
4.3 Interface por Linha de Comandos do OSUMAP ... 59
4.4 Interface de operações aritméticas no SPRING ... 60
4.5 Formulário do operador “escalar” do IDRISIW ... 62
4.6 Formulário do MGE Intergraph ... 63
4.11 Diagrama de Fluxo do Model Maker ... 69
4.12 Operador de Buffer no VFQL ... 70
4.13 Virtual Functional Query Language ... 70
5.1 Exemplo de conexão com ODBC via Tclodbc ... 80
5.2 Estrutura hierárquica da interface de AMO ... 81
5.3 Tela Principal de AMO ... 82
5.4 Região de Seleção em AMO ... 83
5.5 Seleção de Dados em AMO ... 84
5.6 Região de Seleção de Operadores em AMO ... 85
5.7 Funções de encadeamento de conectores ... 90
5.8 Janela de Diálogo para Configuração de Variáveis ... 90
5.9 Janela de Diálogo para Configuração de Comandos ... 91
5.10 Ícone de uma Variável em AMO ... 92
5.11 Modelo de Objetos de AMO ... 94
5.12 Exemplo de procedimento em AMO ... 95
5.13 Exemplo de tabela de ponderação em AMO ... 95
6.1 Modelo para estimar a Vulnerabilidade Natural à Erosão ... 100
6.2 Seleção de Banco de Dados ... 102
6.3 Seleção de Projeto ... 102
6.4 Seleção de Dados ... 103
6.5 Instanciação de Variável ... 103
6.6 Lista de Hierárquica de Operadores ... 104
6.7 Criação de um Comando ... 105
6.8 Criação de Conexões ... 105
6.9 Fluxo de Dados ... 106
6.10 Criação de Novas Varáveis ... 106
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
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
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
• 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.
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
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).
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áficos
Um 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
! 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
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:
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.
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:
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áficos
" 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 Dado Sens. Rem. Fazendas Mapa Propriedades Mapa solos Altimetria Declividade Dados LANDSAT is-a is-a is-mapped-in is-a is-a is-a is-a is-a is-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.:
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 de Informação Represent. Geom. Matricial Vetorial é-um is-represented-by é-um Figura 2.6 - Representação 2.3 Análise Espacial
Um 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):
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
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,
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ção
Ponderaçã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ÁTICO
TEMÁTICO (regras)
Matemática NUMÉRICO NUMÉRICO (fórmula)
Vizinhança NUMÉRICO, TEMÁTICO NUMÉRICO, TEMÁTICO (função local e forma da vizinhança)
Zonais NUMÉRICO TEMÁTICO NUMÉRICO
Seleção
Espacial GEO-OBJETO(conjunto) CADASTRAL GEO-OBJETO(conjunto) (predicado espacial) Junção
Espacial GEO-OBJETO(conjuntos) CADASTRAL GEO-OBJETO eVALORES (conjunto)
(predicado espacial)
Identificação TEMÁTICO GEO-OBJETO
(conjunto) CADASTRAL Intersecção
Espacial TEMÁTICO (n) GEO-OBJETO(conjunto)
CADASTRAL Mapa
Distâncias GEO-OBJETO
CADASTRAL TEMÁTICO (predicado métrico) Reclassificação
Atributos GEO-OBJETO(conjunto) CADASTRAL TEMÁTICO (atributo)
Zonal sobre
GEO-OBJETOs TEMÁTICO,NUMÉRICO
GEO-OBJETO, CADASTRAL TEMÁTICO, NUMÉRICO Seleção espacial (restr= GEO-CAMPO) GEO-OBJETO
(conjunto) CADASTRAL,TEMÁTICO, NUMÉRICO
GEO-OBJETO
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 LEGAL
No 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 LEGAL
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
{
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, “+”, “*”, “&&”, “||” , “<”, “<=”, “!=”‘), palavras reservadas (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:
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);
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ático
limites , Caso Numérico
onde: resolução : ResX = numero, ResY = numero
escala : Escala = numero
limites : Min = numero, Max = numero
representação : Repres = Vetor Caso
Temático
Repres = 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: ,
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:
variável = expressão_real expressão_imagem expressão_tematica expressão_numérica expressão_condicional expressã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;
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
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
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 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).
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
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,
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
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
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
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:
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:
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
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-campos
A 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 m pos: Operadores Unários:
Pondere Pondere
Fatie Fatie
Reclassifique Reclassifique
Operações Booleanas sobre Geo-ca m pos Atribua
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-Computador
No 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
Projeto de Interface Modelo 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 Mapas
Nesta 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
É 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.
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 de reflorestamento
1. Criar mapa de distância (arquivo roadbuffer) a partir do 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 roadbuf Arcplot: linecolor 2 Arcplot: arcs roadline Arcplot: linecolor 5 Arcplot: arcs roadbuf
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”.
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.
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:
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
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)
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.
Engineering: gentle slope close 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 slope good view west aspect Constraints: 100m sefback <50% slope Primary maps Derived maps Interpreted maps Prescriptive maps
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.
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.
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”.
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.
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,
Figura 4.12 – Operador de Buffer atuando sobre mapa temático “Lakes” no VFQL (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).
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:
• 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 Mapas
Para 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.
