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

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

É 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

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.

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

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

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:

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.

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.

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.

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.

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

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,

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.

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).

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

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

• 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).