Um Ambiente de Geração de Programas de Análise Espacial

Ivan Lucena 1
Gilberto Câmara 2
Mário A. Nascimento 1

1- Embrapa Informática Agropecuária - Caixa Postal 6041 - CEP 13.083-970
Campinas, SP, Brasil
ivan@cnptia.embrapa.br
mario@cnptia.embrapa.br

2 - Instituto Nacional de Pesquisas Espaciais - Av. dos Astronautas, 1758 - CEP 12227-001
São José dos Campos SP, Brasil
gilberto@dpi.inpe.br

Resumo

Sistemas de informação geográfica oferecem operações de análise espacial, que permitem gerar novos mapas a partir de mapas existentes, e que, na maior parte dos casos, são descritas em linguagens de comandos. Apesar do poder expressivo de algumas dessas linguagens, seu uso requer noções de fundamentos de programação dificultando o aprendizado para usuário iniciantes. Este fato tem motivado o desenvolvimento de melhores interfaces para manipulação de álgebra de mapas. Neste sentido, este trabalho apresentar uma interface amigável para álgebra de mapas no ambiente SPRING (INPE, 1999), denominada A.M.O. (Álgebra de Mapas por Objetos), que gera programas na linguagem LEGAL (nativa do SPRING) a partir de diagramas de fluxo.

Abstract

Geographic information systems offer operations of space analysis, that allow to generate new maps from existing maps, and that, in the biggest part of the cases, they are described in languages of commands. Despite the expressive power of some of these languages, its use requires slight knowledge of programming making it difficult the learning for user beginning. This fact has motivated the development of better interfaces for manipulation of algebra of maps. In this direction, this work to present a friendly interface for algebra of maps in environment SPRING (INPE, 1999), called A.M.O. (Algebra of Maps for Objects), that it generates programs in the LEGAL language (native of the SPRING) from data flow diagrams.

Introdução

Temos assistido uma grande difusão do uso de tecnologia de Geoprocessamento. 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, verificou-se uma mudança no perfil do uso de sistemas informatizados de Geoprocessamento. Os sistemas, que antes estavam baseados em computadores de grande e médio 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 temos o sistema SPRING (Sistema de Processamento de Informações Georeferenciadas), 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(Câmara et al., 1996).

Uma das principais características de um sistema de informação geográfica (SIG) é a capacidade de modelar fenômenos da realidade geográfica através de mecanismos de análise espacial, que permitem gerar novos mapas a partir de mapas existentes. Os sistemas oferecem funcionalidade para que o usuário desenvolva modelos de análise espacial, através do ordenamento de seqüências de expressões (com operandos e operadores específicos de análise espacial). O que é chamado de informalmente de álgebra de mapas. Na maior parte dos SIG este processo de interação entre o usuário e o sistema se dá através de linguagens de programação, com as seguintes alternativas:

Apesar do grande poder expressivo de linguagens, seu uso requer noções de fundamentos de programação, competência nem sempre disponível entre os especialistas em Geoprocessamento. Este fato tem motivado o desenvolvimento de interfaces amigáveis para a geração de programas de álgebra de mapas, como MapModeler (ERDAS, 1993), GrassLand (Global, 1999) e PCI Modeler (PCI, 1999). Neste trabalho apresentamos uma interface amigável para álgebra de mapas no ambiente SPRING, denominada A.M.O. (Álgebra de Mapas por Objetos), que permite a geração de programas na linguagem LEGAL a partir de diagramas de fluxo de dados desenvolvidos pelo usuário.

Domínio do problema

A grande maioria do SIG oferecem operações de álgebra de mapas através de linguagens de comandos. O importante é que quando o usuário desenvolve um modelo de análise sua seqüência de operações sejam corretamente armazenadas para posterior execução, p. ex. um programa escrito em LEGAL (Figura-1).

Figura 1 - Programa escrito em LEGAL

Os problemas com as linguagens de programação para álgebra de mapas são:

Modelo de Interfaces Usuário-Computador

Em Lucena et al. (1997) analisamos as alternativas de interface gráfica para álgebra de mapas, linguagem de comandos e linguagem de programação; menus e formulários; interfaces por manipulação direta baseadas em pilhas e diagramas de fluxo. Optamos pelo desenvolvimento de uma interface baseada na manipulação em diagramas de fluxo de dados. "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). 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. Portanto, a metáfora de uma interface baseada em fluxograma 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 Fonte Berry (1991) A figura 2 ilustra um exemplo de problema de análise espacial expresso a partir de diagramas de fluxo:

Figura 2 – Diagrama de Fluxo em Análise Espacial. Fonte Berry (1991)

Requisitos para o projeto de Interface para Álgebra de Mapas

Em Lucena et al. (1998) apresentamos a proposta para o desenvolvimento de uma interface usuário-computador baseada na edição de diagramas de fluxo para a posterior geração automática de programas em linguagem de álgebra de mapas; Analisamos as implementações existentes tais como MapModeler (ERDAS, 1993), VFQL (Standing, 1995), Geographer Desktop (Egenhofer, 1993), GrassLand (Global, 1999), PCI Modeler (PCI, 1999); e propomos um projeto de interface que utiliza a orientação por objetos para enriquecer semanticamente o diagrama de fluxo, facilitando ao usuário, por exemplo, identificar do operador certo para o tipo de mapa escolhido. Para o efetivo desenvolvimento da interface proposta estabelecemos uma lista de requisitos baseada numa revisão bibliográfica sobre o tema interfaces usuário-computador, GIS, interfaces para GIS e a na documentação do SPRING:

1. Utilizar metáforas adequadas com o domínio da aplicação. A escolha de metáforas certa agiliza o processo mental do usuário de relacionar o símbolo com o seu conteúdo semântico. 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 possa responder imediatamente aos atos do usuário.

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áficas. Oferecer uma interação com os elementos da interface com regras simples e intuitivas e dar suporte a administração de diagramas muito extensos.

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. 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 seu GIS

11. Extensiblidade. O sistema de interface deve ser extensível. Conforme novos operadores são desenvolvidos é 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.

12. Gera programas. O sistema deve ser capaz de gerar código em LEGAL livre de erros.

13. Representar o modelo conceitual do SIG. 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. Armazenar o modelos no banco de dados do SIG. O sistema deverá salvar os modelos de análise na mesma estrutura de armazenamento do banco de dados do SPRING.

Porque Á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-se 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. 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, atender ao requisito nº3, "facilitar a construção de comandos corretos".

Desenho da Interface A.M.O.

A interface de A.M.O. 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.

Em A.M.O. 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. 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 A.M.O. deverá oferecer recursos específicos para a manutenção de diagramas extensos e complexos, atendendo ao requisito nº7, "reduzir complexidades".

A interface A.M.O. 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, "arrastando-o" ao editor de diagramas.

Tendo em vista o proposto pelo requisito nº6 "Evitar a sobreposição de janelas", optou-se uma única janela para a interface de A.M.O.. A janela principal de A.M.O. (Figura-3) é composta por uma barra de menus, uma barra de ferramentas (conjunto de ícones) e um painel que pode ser ajustado deslocando-o horizontalmente, para 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. Este desenho de interface tem por objetivo oferecer ao mesmo tempo uma boa visualização do esquema do banco de dados, do conjunto de operadores e do diagrama do modelo de análise em desenvolvimento.

Figura 3 - Tela Principal de A.M.O.

Ícones de A.M.O.

A.M.O. apresenta um reduzido conjunto de ícones para representar os operandos e operadores da álgebra de mapas disponíveis no SPRING. Do lado esquerdo da Figura 4 temos um ícones de um plano de informação e a direita temos o ícone do operador de ponderação:

Os ícones que representam os planos de informação identificam o tipo de mapas que representam através da cor da sua borda e o desenho no interior do ícone. Os planos de informação temáticos são representados pela cor vermelha, os numéricos por verde e as imagens por azul (Figura 5). Acima da desenho está o nome deste plano de informação no banco de dados e abaixo o nome da variável no programa LEGAL a ser gerado.

Figura 5 - Ícones de A.M.O.

Os ícones de operadores (Figura 4) possuem a borda compatível com o tipo de dado que geram, ou seja, operadores que geram planos de informação numéricos são verdes, os que geram mapas temáticos são vermelhos. A desenho no seu interior representa uma operação de sobreposição e cruzamento de planos de informação. Acima do desenho temos o nome do operador e abaixo o nome do comando a ser gerado em LEGAL.

Uso efetivo de A.M.O.

Para exercitar os conceitos abordados por A.M.O. 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 A.M.O. 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).

Definição do Problema

O 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. Serão utilizados como fontes primárias de dados: imagens de satélite e mapas temáticos pedológicos, geológicos, geomorfológicos 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.

Metodologia do ZEE

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 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. Para os quatro temas restantes repete-se o processo a seguir: 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, atribui-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 entre as notas individuais de cada tema para cada unidade ambiental, como é ilustrado na A Figura 6.

Figura 6 - Modelo para estimar a Vulnerabilidade Natural à Erosão de uma Unidade Territorial Básica. Fonte: Barbosa (1998)

Elaboração do Modelo de Análise no SIG

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

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.

Tutorial de A.M.O.

Entendido o problema e o modelo de análise é possível então iniciar a construção do diagrama solução em A.M.O.. 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 é 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 A.M.O., pode-se navegar pelo sistema de arquivo, a fim de selecionar o banco de dados desejado. (Figura 5).

Figura 7 – Seleção de Banco de Dados

Todos os diretórios contendo bancos de dados do SPRING são identificados por um ícone específico. Um clique duplo sobre o nome do diretório ZEE, faz A.M.O. conectar-se a este banco, e apresenta ao usuário a lista de seus projetos, para o usuário possa selecionar o projeto desejado (também através de um clique-duplo) (Figura 8). Neste banco de dados, o ZEE, só há um projeto de nome "224".

Figura 8 – Seleção de Projeto

2º Passo: Selecionar os Dados

Após a escolha do projeto, A.M.O. apresenta a hierarquia do modelo conceitual do banco de dados geográfico, conforme foi definida pelo usuário que o construiu (lado direito da Figura 9). Os tipos de dados são representados por ícones que os distinguem, semelhante a Figura 5 mas em escala menor. Um clique sobre os sinais "+" faz com que A.M.O. apresente a lista de planos de informações. A seleção do dado se pelo arrastar do ícone da para a região de edição de diagrama (Figura 9):

Figura 9 – Seleção de Dados

A qualquer momento, o usuário pode verificar o código gerado por A.M.O. Para isto, basta clicar sobre o nome da pasta "Code" na Região de Edição. (Figura 10).

Figura 10 – Código gerado em LEGAL

Seguindo os procedimentos proposto pela metodologia, selecionamos os planos de informação: go_atualizado, gm_atualizado, solo_atualizado, veget_atualizado e utbas. 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 A.M.O. apresente todos os operadores de análise geográfica disponíveis no SPRING (Figura 11). Navegando-se por esta hierarquia é possível identificar quais os operadores que irão compor as expressões desejadas, 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. O procedimento de seleção e idêntico a seleção de planos de informação, basta arrasta-los para a região de edição.

Figura 11 - Lista de Hierárquica de Operadores

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 colocar quatro comandos de ponderação no diagrama (Figura 12)

4º Passo: Conectar Elementos

Para estabelecer uma conexão entre os planos de informação e os operadores: clicar o botão de conexão que está a direita da região de edição, clicar sobre ícone do plano e depois sobre o ícone do operador. Isto fará com que se estabeleça um fluxo entre os dois ícones partindo do primeiro para o segundo conforme a ordem que foram selecionados (Figura 12).

Figura 12 – Fluxo de Dados

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 nova quando ainda não existe seu Plano de Informações, basta selecionar a pasta onde ela será incluída arrastando-a para o diagrama. Selecione a pasta "Data" na Região de Seleção e de um arraste o pasta "Numérico" desta forma, A.M.O. irá criar uma nova variável. 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 13).

Figura 13 – Criação de Novas Varáveis

6º Passo: Configurar Variáveis

No nome "*NOVO*" indica ele ainda não foi dado um nome para o plano de informação da nova variável. Para fazer isto basta apontar o cursor para os ícones e dar um clique-duplo. Irá aparecer uma janela com um formulário para a configuração desta variável logo abaixo da região de seleção. O Usuário deve preencher os dados conforme as característica que se deseja para o novo plano de nformação. No caso desta aplicação os dados são os seguinte (Figura 14):

Figura 14 – Configurando um novo plano de informação

Repetir o mesmo processo para os outros três resultados intermediários dos demais comandos de ponderação, dando-lhes o nome de geologia_ponderada, geomorfologia_ponderada e vegetacao_ponderada respectivamente.

7º Passo: Configurar Comandos

Para configurar os comandos do diagrama o procedimento é o mesmo, porém é necessário observar que cada comando tem parâmetros diferentes a serem preenchidos. 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 A.M.O. irá incluir nesta janela os campos necessário a inclusão dos elementos da nova tabela (Figura 15). Para selecionar uma classe clique no ícone representado por um triângulo e selecione um dos nomes que aparecem na lista.

Figura 15 - Configuração de Tabelas

Deve-se repetir o mesmo procedimento para as todas as tabelas de ponderação com os dados sugeridos Barbosa et al. (1998).

8º Passo: Adicionar Operação de Média Zonal

Seguindo o proposto na seção 6.2, item 2, o próximo passo é incluir as operações de "Média Zonal" tendo como referência as UTBs. Para isto, deve-se repetir o mesmo procedimento do Passo nº 3 para instanciar comandos para incluir comandos com o operador "Média Zonal". Repetir os Passos nº 5, 6 e 7, ou seja, Criar novas variáveis, configurar variáveis, fazer as conexões e configurar os comandos. A operação de Média Zonal não necessita de nenhum parâmetro adicional (Figura 16). Repetir o mesmo procedimento para os quatro planos de informação.

Figura 16 – 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 com o parâmetro (variable9 + variable10 + variable11 + variable12) / 4.

10º Passo: Criar Mapa de Vulnerabilidade

O resultado da expressão numérica anterior é um mapa de vulnerabilidade numérico, e para a gerar o resultado final é necessário executar uma operação de "Fatiamento" transformando as faixas de valores em classes de Vulnerabilidade a erosão. É necessário construir um tabela de fatiamento, informando as faixas de valores e as respectivas classes conforme Barbosa et al. (1998).

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.

Resultados

O diagrama da solução desenvolvida em A.M.O. 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:

Figura 6.17 - Motodologia ZEE desenvolvido em A.M.O.

Análise dos Resultados e Conclusões

O Programa gerado pelo A.M.O. é 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 A.M.O. é atingir ao público 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 A.M.O., 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 A.M.O. é 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 A.M.O. apresenta um resumo da parte operacional do procedimento, permitindo ao usuário uma apreensão cognitiva imediata da metodologia adotada. Consideramos assim que o A.M.O., uma vez tornado operacional, provavelmente será mais utilizado que a programação direta em LEGAL.

Referências bibliográficas

Barbosa, C. C., Álgebra de Mapas e suas aplicações em Sensoriamento Remoto e Geoprocessamento . (Tese de Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, São José dos Campos, 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.

Baylor, GRASS GIS HomePage, < http://www.baylor.edu/~grass/ >, Mar, 1999

Berry, J. K. in Maguire,D.; Goodchild, M.; Rhind, D. (eds.) Geographical Information Systems: 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.

CLARK, Idrisi Project Home Page, < http://www.clarklabs.org/ >, Mar, 1999

Coad, P. e Yourdon E., Projeto Baseado em Objetos, Editora Campus, 1991.

Egenhofer, M. and Richards, J.. "The Geographer’s Desktop: A Direct-Manipulation User Interface for Map Overlay." In Auto-Carto 11, McMaster, R. and Armstrong, M., eds. Minneapolis, MN. 63-71. 1993.

ERDAS, Model Maker Tour Guide. Atlanta, GA, ERDAS, Inc. 1993.

ESRI. ESRI - The GIS Software Leader, Because Geography Matters, < http://www.esri.com >, Mar 1999.

Global, Geomatics, Grassland Home Page, < http://www.globalgeo.com/grassland/grassland.html >, Mar, 1999.

INPE. Sistema de Processamento de Informacões Georeferenciadas, < http://www.inpe.br/spring >, Mar 1999.

Lucena, I., Câmara., G., Nascimento, M., A.M.O. – Algebra de Mapas Orientada por Objetos, IV Congresso e Feira para Usuários de Geoprocessamento da Amárica Latina, , GIS Brasil 98, Sagres, Curitiba, 1998.

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, GIS Brasil 97, Sagres, Curitiba, 1997.

Maguire, D.; Goodchild, M.; Rhind, D. (eds.) Geographical Information Systems: Principles and Applications. New York, John Wiley and Sons, 1991.

MapInfo, MapInfo Data Visualization Maps, Spatial Analysis and Geocoding Intranet and Extranet Solutions, http://www.mapinfo.com, Mar, 1999

PCI, PCI - Products - Visual Modeller's Page, < http://www.pci.on.ca/vm/>, Mar, 1999.

Standing, C., Roy, G. G., Functional visual programming interface to geographical information systems, Interacting with Computers, vol 7, n. 3, 1995.