MANUAL DO USUÁRIO

Versão Beta 0.09Pontifícia Universidade Católica (PUC-Rio)

Departamento de Engenharia Elétrica (DEE)

Laboratório de Visão Computacional (LVC)

Instituto Nacional de Pesquisas Espaciais (INPE)

Divisão de Processamento de Imagens (DPI)

Divisão de Sensoriamento Remoto (DSR)

Tradução para o português:

Hermann J. H. Kux

INPE - DSR

Sumário

1. Introdução...................................................................................... 32. Componentes do processo de interpretação................................. 3

2.1. Redes semânticas................................................................ 42.2. Operadores Top-Down......................................................... 52.3. Operadores Bottom-Up......................................................... 62.4. Controle da interpretação..................................................... 7

3. Janela principal do InterImage....................................................... 94. Preparando um projeto de interpretação........................................11

4.1. Criando ou editando um projeto ...........................................124.2. Criando uma rede semântica................................................134.3. Preparando regras de decisão............................................. 174.3.1. Elementos da árvore de decisão.......................................... 18 4.4. Usando conjuntos fuzzy........................................................ 23

5. Executando um projeto de interpretação........................................24 6. Visualizando os resultados............................................................ 25 7. Incluindo novos operadores...................................................... 28 7.1. Operadores Top-Down..................................................... 28 7.1.1. Arquivo de descrição da região............................. 30 7.1.2. Imagem rótulo da região........................................ 32 7.2 Operadores bottom-up..................................................... 32 7.2.1. Lista de nós............................................................ 34 8. Implementação e instalação........................................................35 9. Agradecimentos........................................................................ .36 Referencias bibliográficas................................................................... 36

1. Introdução

1

InterIMAGE é uma iniciativa de desenvolvimento de software open source que constitui parte de um projeto de cooperação internacional liderada pelo Laboratório de Visão Computacional do Departamento de Engenharia Elétrica da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) e pelo Instituto Nacional de Pesquisas Espaciais (INPE).InterIMAGE é uma rede multi-plataforma, escrita em C++, contando atualmente com implementações para sistemas operacionais para LINUX e Windows. Conforme será esclarecido nas próximas seções, InterIMAGE fornece o suporte para a integração de operadores de processamento de imagens no processo de interpretação, e assim sendo tais operadores são tratados como programas externos pelo seu mecanismo de controle, podendo ser codificados por qualquer linguagem computacional e podem mesmo ser programas proprietários. A rede InterIMAGE oferece, não obstante, um repositório de operadores (http://ww.dpi.inpe.br/terraaida), montados com as classes de software e funções fornecidos pela biblioteca TerraLib (Câmara et al., 2000).

InterIMAGE baseia-se no aplicativo GeoAIDA (Bückner et al.,2001), desenvolvido pelo TNT Institut (Institut für Informationsverarbeitung) na Universidade Leibniz, em Hannover, Alemanha, e herdou deste sistema o seu design funcional básico, estruturas de conhecimento e mecanismos de controle. Sendo um trabalho em desenvolvimento, uma nova interface de usuário gráfica bem como operadores de funcionalidade de processamento de conhecimento e de processamento de imagem serão brevemente incluídos no InterIMAGE.

Este Manual do Usuário InterIMAGE refere-se a versão Beta do sistema (Versão 0.09), que será atualizado sempre que uma nova versão for lançada. Relatórios sobre problemas, pedidos de informações adicionais e sugestões sobre novas funcionalidades devem ser enviadas para lvc_inter@ele.puc-rio.br.

2. Componentes do processo de interpretação

A Figura 1 apresenta as componentes do processo de interpretação no InterIMAGE. O sistema implementa uma estratégia de controle de interpretação específica, direcionada por um modelo de conhecimento estruturado dentro de uma rede semântica. O controle da interpretação é executado pelo núcleo do sistema, que usa como entrada, um conjunto de dados de imagem, camadas de SIG, dados de elevação digital, ou outros tipos de dados geo-registrados.Através da interpretação da cena, os dados de entrada são processados com ajuda de programas externos, denominados de operadores top-down e bottom-up. Os operadores Top-down são responsáveis pela partição da cena em sub-regiões, consideradas como hipóteses de objetos. Os operadores bottom-up avaliam as hipóteses, descartando ou validando-as e resolvendo eventuais conflitos espaciais existentes entre elas. No final do processo de interpretação as hipóteses validadas tornam-se instâncias de objetos.

A saída do processo de interpretação é uma descrição simbólica da cena, consistindo de uma rede de instâncias e das imagens rótulo (label images) que correspondem às regiões associadas às instâncias de objetos. A partir das

2

imagens rótulo o sistema está em condições de criar diferentes mapas temáticos representando os diferentes níveis de conceitos na rede semântica.

Figura 1 – Componentes do processo de análise, adaptados de Pahl (2003)

2.1 Redes semânticas

Um odelo de conhecimento no InterIMAGE contém informação específica do problema usados pelo processo de controle, para a interpretação de uma cena. É representado através de uma rede semântica (Figura 2), onde a organização dos nós é hierárquica, sendo que cada nó pode ser associado somente a um nó superior (pai) e a um ou mais nós subordinados (filhos).

Cada nó na rede semântica corresponde a uma classe de objetos que se espera encontrar na cena. Os nós possuem atributos, tais como os operadores top-down e bottom-up associados, bem como parâmetros genéricos e espeficicos e específicos do operador.

3

Figura 2 – Atributos de um nó da rede semântica no InterIMAGE

Os links da rede não tem nenhum significado semântico explícito, representando tanto relações is-a (é um) ou part-of (parte de), dependendo das operações executadas pelo operador bottom-up ligado ao nó de nível mais elevado, conectado ao link.

Os objetos encontrados na cena pelos operadores top-down são inicialmente considerados como hipóteses de objetos. A tarefa do operador bottom-up para avaliar as hipóteses associadas aos filhos do nó ao qual está atachado, criando instâncias de objetos das hipóteses validadas pelo operador.

Como não possuem filhos, não faz sentido prender operadores bottom-up aos nós-folha da rede semântica. Por outro lado, como será esclarecido na próxima seção, precisa haver um operador holístico top-down preso a cada nó folha.

2.2 Operadores Top-Down

A tarefa básica do operador Top-Down é gerar hipóteses de objetos para a cena que está sendo analisada. Como tais hipóteses são definidas sobre regiões geográficas, este objetivo refere-se a determinação de regiões na cena, onde objetos de uma certa classe possam ocorrer.

Top-down são programas executáveis, chamados pelo núcleo do sistema durante o processo de interpretação. Eles podem, em princípio processar não somente imagens, mas também qualquer tipo de informação geo-registrada, incluindo dados vetoriais de uma base de dados SIG, modelos digitais de elevação ou outros tipos de dados raster.

Quando o núcleo chama o operador top-down, ele repassa para o operador informações sobre os limites da região geográfica a ser processada. Observe que esta região de interesse (ROI) é definida por um outro operador top-down preso a um nó ancestral. Informação sobre o ROI consiste na sua caixa envoltória e de uma máscara raster binária, identificando precisamente os limites da região. Além disso, o núcleo passará para o operador como um sub-conjunto (cobrindo somente as caixas envoltórias do ROI) dos dados de imagem na base de dados especificada para ser processada.

Um operador holístico top down implementa um método especializado para a detecção de uma classe particular de objetos, através de dados de entrada com características específicas. Operadores holísticos contém conhecimento implícito sobre um conceito particular (classe de objeto) representados por um nó da rede semântica. A saída de tais operadores consiste de uma lista de regiões e de uma correspondente imagem rótulo, na qual é definida a extensão exata das regiões. Lembre-se que tais regiões são consideradas como hipóteses de objetos no processo de interpretação. Adicionalmente tais operadores podem associar valores de confiança às regiões e confirmar aqueles valores na lista da região de saída. Tais valores de confiança poderão mais tarde serem usados para a avaliação das hipóteses correspondentes (através de operador bottom-up).

4

Certos nós da rede semântica podem ser associados a classes de objetos que somente poderão ser detectados através de suas componentes estruturais, ou seja, objetos daquelas classes somente poderão ser definidos através dos seus objetos componentes. Um operador top-down dummy deve ser preso a tais nós. O operador dummy terá como saída uma simples região, que é igual ao ROI definido em seu nó-pai.

Conforme mencionado na seção anterior, operadores top-down holísticos precisam ser presos aos nós folha da rede semântica, visto que tais nós correspondem a classes de objetos primitivos.

Um tipo especial de operador top-down é um operador multi-classes. São operadores holísticos capazes de detectar objetos de diferentes classes. Um operador top-down multi-classes deve ser preso a nós no mesmo nível hierárquico para ser preciso: devem ser presos a dois ou mais nós filhos do mesmo nó pai.

No nó-raiz de uma rede semântica no InterIMAGE – o mais elevado nó da rede – não há necessidade de se definir nenhum operador top-down. De fato, o sistema simplesmente irá ignorar os operadores eventualmente presos a tais nós.

2.3 Operadores Bottom-up

A avaliação de hipóteses de objeto é a tarefa de operadores bottom-up. Operadores bottom-up também são programas executáveis, chamados pelo núcleo durante o processo de interpretação. A entrada de tais operadores é uma lista de regiões, sendo que cada região está associada a uma hipótese de objeto.

Um operador bottom-up avalia hipóteses associadas ao nó-filho do nó da rede semântica ao qual o operador está preso. Antes da execução do operador, o núcleo do sistema cria uma lista contendo as descrições de todas as hipóteses de objeto associadas aos nós-filho. Quando o operador for chamado, esta lista é passada adiante como um parâmetro de entrada ao respectivo programa executável. Quando da execução, o operador bottom-up julga as hipóteses de entrada, descartando ou validando-as. Este julgamento pode ser por regras embutidas no código dentro do operador ou explicitamente definidas como atributos do nó da rede semântica.

Propriedades das hipóteses de objeto, tais como os valores de confiança ou valores das características, podem ser usados no processo de julgamento. As hipóteses validadas a partir de então serão consideradas como instâncias de objetos.

É importante notar que as instancias de objetos geradas pelo operador podem, num momento posterior no processo de interpretação, serem descartadas. Isto acontecerá se uma hipótese de objeto de nível mais elevado, à qual as instâncias estão relacionadas, for rejeitada por um outro operador bottom-up.

5

As instâncias de objeto geradas pelo operador bottom-up precisam estar espacialmente desconectadas, de modo que também seja uma tarefa de tais operadores resolver eventuais conflitos espaciais entre as suas regiões originais, dando-lhes novo formato, para remover sobreposições de regiões.

O operador também deve agrupar as instâncias de objetos, associando a cada grupo uma região equivalente à união das componentes de regiões. Os grupos originarão novas hipóteses de objetos para o nó de rede semântica ao qual o operador foi chamado, substituindo a hipótese original, conforme será esclarecido na próxima seção.A saída de um operador bottom-up consiste de uma descrição das novas hipóteses de objeto e de instâncias de objeto em adição a duas imagens rotuladas que descrevem a extensão espacial das regiões que correspondem respectivamente às novas hipóteses (associadas ao nó no qual o operador foi chamado) e às instâncias (associadas aos nós filhos).

O operador genérico bottom-up é um operador fornecido junto com o pacote InterIMAGE. Fornece uma interface gráfica, através da qual o usuário pode compor regras de decisão complexas (vide seção 4.3).

Visto que os nós de folhas de uma rede semântica não possuem filhos, não há hipóteses a serem avaliadas em tais nós, e nenhum operador bottom-up precisa ser acoplado a estes nós. O sistema ignorará os operadores presos nestes nós.

2.4. Controle da interpretação

A principal tarefa do núcleo do sistema é o controle do processo de interpretação que consiste de dois passos complementares, a saber: top-down e bottom-up.l No passo top-down o processo de controle atravessa os nós da rede semântica, da raiz até os nós folha, chamando os operadores top-down presos a cada nó. O processamento top-down ocorrerá em paralelo com relação aos galhos da rede semântica. Hipóteses de objeto associadas aos nós da rede são criados durante este processo e organizados numa rede de hipóteses. Quando o processamento alcança os nós da folha, começa o passo bottom-up. O processo de controle inicia, visitando nós na direção oposta, chamando-se os respectivos operadores bottom-up recursivamente até que o nó raiz foi alcançado e que uma rede de instancias tenha sido criada. Neste processo as hipóteses de objeto são descartadas ou mudadas para instancias de objetos.

Uma descrição mais formal do processo de interpretação, derivada de Pahl, 2003, 2008) é apresentada abaixo.

6

Figura 3 – Fluxograma do processo de interpretação. Adaptado de Pahl (2003)

Se N estiver no modo genérico, N’ é um nó subordinado (filho) com relação a N, N’’ é um filho de N’ e assim por diante. TN denota uma rede estruturada hierarquicamente, ou seja uma árvore, e N’m e N’n designam diferentes nós num mesmo nível hierárquico de TN.

Seja S um nó da rede semântica TS e sejam H e I os nós das redes TH e TI , criados pelo processo de interpretação. H representa o nó associado a uma hipótese de objeto e I representa um nó associado a uma instância de objeto.

Seja R a representação de uma região na cena à qual os nós H ou I estão associados. R’ portanto está associado seja a H’ ou I’. Considerando a rede de hipóteses TH , todos os R’ associados aos nós H’ são sub-conjuntos de R; considerando a rede de instâncias TI , todos os pares R’m e R’n associados aos nós I’m e I’n estão desconectados.

O objetivo do processo de interpretação é criar uma rede de instâncias TI e uma correspondente rede de regiões TR , aplicando o conhecimento representado através da rede semântica TS na interpretação da região R. Inicialmente é criada a rede TH de hipóteses e gradualmente os nós de hipóteses H são substituídos por nós de instância I , de modo que no final do processo, a rede TI esteja completa.

O processamento Top-down é apresentado no topo da Figura 3. Ele começa no ponto onde o nó da hipótese H, associado à região R e ao nó da rede

7

semântica S já foi criado. A partir deste ponto, o controle passa recursivamente aos nós S’.

Nós de hipótese H’mi são gerados através da execução de um operador top-down holístico preso ao nó semântico S’m sobre a região R. Os nós H’mi estão associados às regiões parciais R’mi. Se não houver um operador holístico preso ao S’m , um simples nó de hipótese, H’ml , será associado a toda a região definida pelo seu nó superior (pai) H.R’ml e neste caso será igual a R. Se S’m é um nó de folha (ou seja não possui nós filhos), um operador holístico top-down precisa ser preso ao mesmo.

Se S’m possuir nós subordinados (filhos), o procedimento que consta no parágrafo anterior será repetido para cada H’mi até que os nós folha da rede semântica sejam alcançados. Neste ponto começa o processamento bottom-up (parte inferior da Figura 3), iniciando com os pais dos nós folha. O operador bottom-up preso ao S’m será executado para H’m assim que todos os nós de hipóteses folha H”ni tenham sido criados – o índice n identifica os descendentes diretos de H’m . O operador então avaliará os nós de hipóteses H”ni e decidirá se eles serão transformados em nós de instância I”n ou deletados da rede. Adicionalmente o operador bottom-up tornará as regiões R”ni associadas aos nós I”ni desconectados.

O operador bottom-up por sua vez agrupará os nós I”n e gerará novos nós de hipóteses H’g aos quais os nós de instancia estarão conectados. O H’g então será colocado na rede de hipóteses e associado ao nó H, sendo o nó original H’m deletado. O controle então é passado para o nó H, para a avaliação e agrupamento dos nós H’. O processamento bottom-up continua até que o nó raiz da rede de hipóteses é processado. Neste ponto a rede de instâncias TI foi completada.

3. Janela Principal do InterIMAGE

Uma vez que o sistema foi instalado, o usuário deve executar o arquivo interimage. A janela principal do InterIMAGE será mostrada (Figura 4).

Os elementos da Janela Principal são: 1. Barra do menu: o arquivo opções do menu permite ao usuário gerenciar

os projetos e redes semânticas do InterIMAGE bem como para carregar e salvar os resultados de um projeto de interpretação; o menu View dá opções ao usuário para usar e visualizar os resultados de um projeto de interpretação; o menu Actions contém os comandos para iniciar o processo de interpretação e para controlar passo a passo a interpretação; o menu Help permite ao usuário acessar o Manual do Usuário (este documento) e a tela About.

2. Barra de ferramentas: os botões da barra de ferramentas permitem ao usuário (da esquerda para a direita) a rodar um projeto de interpretação; deletar arquivos temporários criados pelo sistema durante a execução de um projeto de interpretação ; definir a estratégia de execução (síncrona, assíncrona, passo a passo); controlar a execução durante o

8

andamento de uma interpretação (Step, Continue, Stop); chamar diálogos de regras de decisão: para os operadores bottom-up (flecha descendente) e top-down (flecha ascendente).

3. Painel de rede semântica: esta área permite a visualização e edição das propriedades dos nós selecionados da rede semântica.

Figura 4 – Janela Principal

A funcionalidade das opções de menu, dos botões da barra de ferramentas e dos painéis da rede semântica (Semantic Net) e das propriedades dos nós (Node properties) serão descritos mais detalhadamente nas seções subseqüentes.

4. Preparando um projeto de interpretação

O arquivo menu (Figura 5) da Barra do Menu permite ao usuário gerenciar (criar, salvar e editar) um projeto de interpretação; carregar e salvar uma rede semântica, e para carregar e salvar os resultados de um projeto de interpretação.Segue a funcionalidade das opções do menu File:

1. New Project: abre a janela do Project Editor (seção 4.1 deste documento), permitindo ao usuário criar um projeto InterIMAGE.2. Load Project: carrega um arquivo de projeto de interpretação salvo

9

anteriormente (com extensão gap).3. Edit Project: abre a janela Project Editor, permitindo ao usuário editar o projeto atualmente carregado.

4. Load Net: carrega a rede semântica salva previamente num arquivo (com extensão .net).5. Save Net: salva a rede semântica corrente num arquivo (com

extensão .net).6. Load Result: carrega os resultados de um projeto de interpretação

salvo, num arquivo de rede de instâncias (com extensão .imap).7. Save Result: salva os resultados do atual projeto de interpretação

num arquivo de rede de instâncias (com extensão .imap).8. Quit: para o InterIMAGE.9. Recently Used Projects: mostra atalhos dos projetos mais

recentemente usados.

Figura 5 – Opções do menu de arquivos

As sub-seções subseqüentes estão organizadas de modo semelhante aos passos que o usuário deverá seguir para criar e gerenciar um projeto de interpretação de imagens no InterIMAGE.

4.1. Criando ou editando um projeto

Quando o usuário escolhe as opções New Project ou Edit Project do menu de arquivos, o sistema abre a janela Project Editor (Figura 6).Os elementos da janela Project Editor são:

1. Project File Panel: neste painel o usuário deve definir o nome e o caminho completo para o arquivo do projeto de interpretação, que basicamente contém toda a informação definida na janela Project Editor (o arquivo será salvo com a extensão gap).

2. Related Files Panel: contém os nomes dos arquivos/folders usados pelo sistema para armazenar a informação de entrada para o processo de interpretação (Semantic Net; Fuzzy Sets; Decision Tree) ou para arquivar os resultados de tal processo (Instance Net ou

10

Image Map). O sistema proporá os nomes de tais itens e recomendamos que você use os nomes propostos.

3. Add GeoImage Panel: o usuário deve adicionar as imagens a serem usadas no projeto, preenchendo todos os campos neste painel.

Após entrar com a informação de uma imagem (Key, File, Type e bordas geográficas (1) ), o usuário deverá pressionar o botão Add GeoImage (botão identificado pelo sinal de +), e a imagem, identificada pelo seu Key, será adicionada ao painel GeoImage List. Há um botão denominado Load From geoTIFF que permite ao usuário carregar os limites geográficos automaticamente a partir de um arquivo geoTIFF.

O usuário pode ver a informação sobre qualquer imagem selecionada no painel Add GeoImage se ele clicar no botão Edit. Então o usuário pode re-editar a informação, caso necessário clicando no botão Save. Para remover do projeto de uma imagem previamente adicionada, a sua chave deverá ser selecionada no painel GeoImage List, e o usuário deverá clicar no botão Remove GeoImage (identificado por um sinal de -).

As geo-imagens adicionadas através deste painel serão disponibilizadas, identificadas por sua chave (Key) para os operadores top-down (seção 2.2), ou seja o usuário pode definir mais tarde qual daquelas imagens será usada pelos diferentes operadores, presa aos nós da rede semântica. A atual versão do InterIMAGE aceita somente geo-imagens no formato PPM (portable pixel map). Não obstante, visto que os operadores top-down e bottom-up são programas externos, podem ser desenvolvidos por terceiros; operadores particulares podem processar geo-imagens de diferentes formatos, como p.ex. TIFF.

----------------------------------------------------------------------------------------------------------(1) As coordenadas geográficas da imagem devem ser descritas na projeção UTM.

11

Figura 6 – Janela de um editor de projeto

4.2 Criando uma rede semântica Após criar um projeto de interpretação, o usuário deve projetar a rede semântica que representa o modelo de conhecimento para uma aplicação particular. Isto pode ser feito criando a rede a partir do esboço, ou reusando uma rede semântica preparada anteriormente. Se for o último caso, a rede existente deve ser copiada para o nome e localização do arquivo definido no Related Files Panel (Painel de arquivos relacionado) do Project Editor (Seção 4.1). O usuário poderá criar, copiar ou deletar nós da rede semântica, editando nós no painel Semantic Net da janela principal.

Para criar um novo nó, o usuário deverá clicar à direita de um modo existente e selecionar a opção New Mode, tal como mostrado na Figura 7.

12

Figura 7 – Incluindo um Novo Modo na rede semântica

O próximo passo é introduzir as propriedades do nó no painel Node Properties. Existem propriedades de nós genéricos (que são iguais para todos os nós) e propriedades específicas bottom-up e top-down, que variam para diferentes operadores.

As propriedades genéricas são:

● BottomUpOperator: define o operador bottom-up do nó. Precisa ser preenchido com o nome do operador correspondente. Nos nós de folha esta propriedade não precisa ser colocada (vide seção 2.3).

● Class: define o nome da classe dos nós de instância associados ao conceito. É usado para o agrupamento de regiões e para operações executadas no passo de interpretação bottom-up.

● Color: define a cor que representará a região dos nós na imagem rotulada como R:G:B:. Exemplo: color= “255:255::0”.

● Debug: define o tipo de informação para eliminar falhas (bugs) produzidas pelo sistema. O seu valor precisa ser um dos seguintes: DebugInfo, NoDebugInfo, TopDown, BottomUp.

● Max: define o número máximo de hipóteses permitidas para o conceito (gerado no passo top-down). Se mais do que max hipóteses forem encontradas pelo operador, elas serão todas ignoradas – como se o operador não gerasse hipóteses.

● Min: define o número mínimo de hipóteses permitidas. Se menos do que min hipóteses forem encontradas pelo operador, elas serão todas ignoradas – como se o operador não gerasse hipóteses.

● Name: nome do nó (conceito) como será mostrado na rede semântica. Para evitar confusões, recomenda-se que o nome e as propriedades de classe tenham os mesmos valores.

13

● Order: define a ordem de execução do operador top-down, com relação aos nós no mesmo nível (siblings) da rede semântica.

● ResultNode: se esta propriedade é colocada, o nó será tratado como um nó de folha e eventuais nós descendentes serão ignorados.

● Temporal Node: se esta propriedade for colocada, o nó será tratado como nó temporal (2).

● TopDownMultiClass: um atributo booleano, o qual define que o mesmo operador top-down associado ao nó gerará hipóteses em mais de um nó/classe, no mesmo nível hierárquico (vide seções 2.2 e 7.1.1).

● TopDownOperator: define o operador do nó top-down. No nó raiz esta propriedade não precisa ser colocada (vide seção 2.2).

A seguir o usuário deve prender os operadores top-down e bottom-up ao nó. Para entrar com o operador bottom-up, o usuário deverá clicar no botão BottomUpOperator e selecionar um dos operadores disponíveis (Figura 8).

Figura 8 – Ajustando o operador Bottom-UP

(2) Apesar de já estar incluído nesta versão do sistema, o processamento temporal não será descrito neste documento. Tal descrição será feita em versões futuras deste Manual.

Uma operação similar deverá ser executada para ajustar o operador top-down para o nó (Figura 9).

14

Figura 9 – Ajustando o operador Top-Down

Geralmente os operadores possuem algumas propriedades cujos valores devem ser ajustados pelo usuário. Eles variam dependendo do operador selecionado. A Figura 10 mostra os dados de entrada do operador Top-Down TerraAIDA_Shapefile_Import . A descrição das propriedades dos operadores disponíveis encontra-se num folder denominado Help, dentro do home folder do InterIMAGE.

Figura 10 – Propriedades do operador TerraAIDA_Shapefile_Import top-down

15

Assim que a rede semântica foi criada, o usuário deve escolher a opção Save Net do sub-menu File. É importante salvar a rede semântica com exatamente o

mesmo nome esperado no arquivo do projeto definido previamente.

4.3. Preparando regras de decisão

InterIMAGE dispõe de uma forma para manipular ou avaliar hipóteses de objeto através das assim chamadas Decision Rules (regras de decisão).

Quando as regras de decisão são definidas para o operador Generic Bottom-Up (disponibilizado nesta versão do sistema), a sua tarefa é avaliar as hipóteses geradas por operadores top-down, seja descartando-as, seja tornando-os instâncias de objeto (vide seção 2.3). Regras definidas em operadores top-down também podem ser usadas para avaliar hipóteses, mas o seu resultado também são hipóteses de objetos que serão mais tarde sujeitas a avaliação durante o passo de processamento bottom-up (vide seção 2.4). Qualquer operador cujo nome contenha a palavra Generic possui uma regra de decisão como propriedade.

O Decision Rule Editor (Figura 11) é chamado quando o usuário clica nos botões da regra de decisão no Tool bar (barra de ferramentas) ou sobre a propriedade da regra de decisão no painel de propriedades do nó (Node Properties Panel) da janela principal (Main Window) no capítulo 3.

Os elementos do Decision Rule Editor (Editor de regras de decisão) são:

1. Decision Tree / Source Code Panel (Árvore de decisão / Painel do código fonte): esta área permite ao usuário elaborar uma regra de decisão. Pode ser feito pela adição de elementos de linguagem gráfica (árvore de decisão) ou escrevendo diretamente a regra na linguagem polonesa de notação reversa proprietária do sistema (código fonte). Para informações sobre a linguagem polonesa de notação reversa vide Pahl (2003 e 2008). 2. Elements: (Elementos) estes botões correspondem aos elementos

constituintes básicos de uma regra de decisão. Cada elemento possui um significado e uma funcionalidade diferentes, conforme será descrito nas próximas seções. Um clique à esquerda nos botões de

elementos gera um novo nó de regra no painel da árvore de decisão (vide seção 4.3.1).

3. General Toolbar: (Barra de ferramentas geral) Os botões da barra de ferramentas geral habilitam o usuário (da esquerda para a direita) a: apagar a árvore de decisão e iniciar uma nova; abrir um diálogo onde o usuário pode selecionar imagens que serão usadas na regra de decisão; capacitar o Expert Mode (modo especialista) que somente o Source Code (Código fonte) pode editar (no modo normal somente a árvore de decisão pode ser editada e o código fonte é habilitado somente para a leitura).

16

4. Elements Toolbar: estes botões permitem o usuário a interagir com os elementos. Os botões à esquerda e à direita movem o elemento selecionado através dos níveis da árvore. Os botões indicados para cima e para baixo movem o elemento selecionado através dos seus irmãos. Há também ações padrão na tela (cut, copy,paste e delete) (cortar, copiar, colar e apagar) e o último botão edita as propriedades do item.

Figura 11 – Editor da regra de decisão

4.3.1 Elementos da árvore de decisão Enquanto se constrói uma árvore de decisão é essencial saber o significado dos seus elementos constituintes. Uma explicação básica destes elementos é dada abaixo.

Join Element: (Elemento de junção): ajunta ou concatena a lista de hipóteses de diferentes classes numa simples lista de nós.

17

Figura 12 – Exemplos de junção

Class Element: (Elemento de classe) seleciona as hipóteses de uma classe específica. Clicando nele, aparecerá o insert class dialog (inserir o diálogo de classe) (Figura 13) e o usuário pode escolher uma das classes associadas aos nós da rede semântica, ou todos eles de uma vez.

Figura 13 – Inserir o diálogo da classe

Figura 14 – Exemplo de classe

Logic Element: (Elemento lógico) seleciona as hipóteses que satisfazem um determinado critério. Ao clicar no botão, aparece o insert logic dialog (inserir o diálogo lógico) (Figura 15) e o usuário pode escolher um atributo e especificar os critérios. Também entende expressões matemáticas.

18

Figura 15 – Inserção de um diálogo lógico

Figura 16 – Exemplo lógico

And/Or Elements: (Elementos e/ou) são usados para construir estruturas lógicas complexas quando associadas com um elemento lógico. (Figura 17).

Figura 17 – Exemplo e/ou

Expression elements: (Elementos de expressão) são usados para colocar um atributo. Clicando nele aparece o expression logic dialog (diálogo de expressão lógica) (Figura 18) e o usuário pode escolher ou definir um atributo para colocar um valor. Também entende expressões matemáticas.

Figura 18 – Diálogo de expressão lógica

Figura 19 – Diálogo de expressão lógica

19

Membership elements: (Elementos de pertinência) usam a lógica fuzzy (nebulosa) para calcular e agregar valores de pertinência. Clicando nele aparece o membership logic dialog (diálogo lógico de pertinência) (Figura 20) e o usuário pode escolher entre usar um conjunto fuzzy, um valor de operação ou de pertinência. Se o conjunto fuzzy é selecionado, o diálogo permite ao usuário criar, editar ou apagar um conjunto fuzzy. Quando o usuário optar por criar ou editar um conjunto fuzzy, o Fuzzy Set Interface (Interface de conjuntos fuzzy) é ativado (vide seção 4.4).

Figura 20 – Diálogo de expressão lógica

Figura 21 – Exemplo de expressão

Aggregate Elements: (Elementos agregados) Agrega valores de hipóteses selecionadas. Clicando neles o aggregate logic dialog (Diálogo lógico agregado) (Figura 22) aparece e o usuário pode selecionar um atributo e uma função com o argumento adequado. É possível passar estes valores agregados ao nó-pai, na hierarquia da rede semântica escolhendo a opção for parent (para pai).

20

Figura 22 – Expressão do diálogo lógico

Figura 23 – Exemplo de agregação

Classify Elements: (Classificar elementos) resolve conflitos espaciais e classifica as hipóteses selecionadas de acordo com os seus valores de pertinência. Somente é autorizado para operadores bottom-up.

Quando clicar nele, o classify logic dialog (classificar diálogo lógico) (Figura 24) abre e o usuário pode escolher a partir de uma fusão global ou fusão de vizinhos. No primeiro caso, a hipótese original, associada a nó ao qual o operador bottom-up está preso, é substituído por uma hipótese simples, cuja região geográfica correspondente é a união de todas as regiões associadas às hipóteses de nós filhos. No caso de uma fusão de vizinhos, a hipótese original será substituída por tantas hipóteses quantas forem as regiões contíguas formadas pelo agrupamento das hipóteses-filhos.

Figura 24 – Dialogo lógico de classificação

Figura 25 – Exemplo de classificação

4.4. Usando conjuntos fuzzy

21

Ao adicionar um Membership Element (Elemento de pertinência) numa regra de decisão, o usuário pode especificar as características do conjunto fuzzy (nebuloso) através da Fuzzy Set Interface (Figura 26) (Interface de conjunto fuzzy).

Os elementos de um conjunto fuzzy são:1. Attribute: (Atributo) define o atributo a ser usado no conjunto fuzzy.2. Fuzzy set: (Conjunto fuzzy) determina o nome do conjunto fuzzy.3. Function type: (Tipo de função) escolhe o tipo de função a ser

usada no conjunto fuzzy.4. Membership function: (Função de pertinência) especifica as características da função do conjunto fuzzy. Os deslocamentos X e Y e o valor de função máximo e mínimo também podem ser ajustados. Dependendo da função escolhida, alguns parâmetros podem estar disponíveis. Cada um do número de pontos definido pode ser editado na caixa de funções, clicando nela. O usuário pode arrastar e soltar o ponto ou definir as suas coordenadas na caixa de coordenadas X e Y.

Figura 26 – Interface de conjunto fuzzy

5. Executando um projeto de interpretação

22

Para executar um projeto de interpretação o usuário deverá clicar no botão mais à esquerda do Main Window’s Toolbar (Barra de ferramentas da janela principal) (vide capítulo 3), ou selecionar a opção Start (Partida) do menu Actions (Ações) (Figura 27).

Figura 27 – Opções do menu Actions

Antes de começar o processo de interpretação, o usuário deverá escolher uma das estratégias de execução na Main Window’s Toolbar (Figura 28), a partir das seguintes opções:

1. Asynchronous: (Assíncrono) o modo padrão. O processo de interpretação roda de modo assíncrono, isto é, os operadores top- down e bottom-up são chamados numa forma assíncrona, respeitando somente os passos lógicos definidos pela rede semântica. Assim, por exemplo, quando há mais de um nó num certo nível da rede semântica, e a interpretação está no passo top-down, todos os operadores top-down presos aos nós naquele nível serão chamados simultaneamente. Uma vez que o processamento de um operador tenha sido concluído, o sistema chama os operadores presos aos seus nós filhos, e assim por diante. A sincronização no entanto ocorre no passo de processamento bottom-up, já que o sistema espera por todos os processos bottom-up dos descendentes de um nó para terminar, antes de ativar o seu operador bottom-up (vide seção 2.4).

2. Asynchronous Stepwise: (Passo a passo assíncrono) um modo passo a passo que pode ser usado para eliminar os “bugs” (defeitos) do projeto de interpretação. O sistema inicia os operadores numa forma assíncrona, tal como na opção acima, mas como qualquer processo termina, o usuário precisa comandar o sistema para continuar a selecionar a opção Next Step do menu Actions. Se o usuário seleciona a opção Continue, a interpretação reinicia até que o processo termine, ou até que o usuário selecione a opção Stop do menu Actions.

3. Synchronous: (Síncrono) o processo de interpretação corre sincronicamente até o fim. A diferença com relação ao modo assíncrono é que o sistema ativará um operador de cada vez e

23

esperar até que o processamento do operador termine antes de executar um outro operador.

4. Synchronous Stepvise: (Síncrono passo a passo) é um modo passo a passo. Trata-se da versão síncrona do modo Asynchronous Stepwise.

Figura 28 – Modos de execução

6. Visualizando os resultados

Para visualizar os resultados do processo de interpretação, InterIMAGE oferece funcionalidades através do sub-menu View, conforme mostrado na Figura 29.

Figura 29 – Menu de visualização

1. Scene Viewer: (Visualização da cena) mostra a rede de instâncias com as regiões selecionadas, conforme mostrado na Figura 30.

2. Trash Viewer: (Visualização do descarte) mostra os atributos das regiões rejeitadas, relacionadas às hipóteses que foram descartadas durante o processo de interpretação (Figura 31).

3. Map Viewer: (Visualização do mapa) mostra a imagem rotulada resultante, com as regiões classificadas.

24

4. Debug Image Viewer: (Visualização da imagem descartada) mostra a imagem rotulada com as regiões descartadas (as mesmas regiões identificadas no Trash Viewer).

4. Task Viewer: (Visualização de tarefas) mostra/esconde o painel Task/Viewer que apresenta os processos iniciados pelo sistema (relacionados à execução dos operadores top-down e bottom-up).

Figura 30 – Visualização da cena

25

Figura 31 – Visualização do descarte

O Map Viewer (Visualização do mapa) mostra a imagem rotulada com as regiões classificadas. Está conectada à Scene Viewer (Visualização da cena), o que significa que, quando o usuário clica numa região no arquivo do mapa, a região é automaticamente selecionada no Scene Viewer, mostrando todos os seus atributos. É possível fazer ampliação (zoom in) ou redução (zoom out), esmaecer a imagem rótulo, combinando com a imagem de entrada, conforme apresentado na Figura 32.

Figura 32 – Visualização do mapa

O Map Viewer possui um controle deslizante, uma caixa de combinação e 5 botões. Com a caixa de combinação o usuário pode selecionar uma das

26

imagens do projeto pela sua chave e com o deslizador ele pode determinar o grau de combinação entre a imagem e a imagem rótulo que representa o resultado da classificação. Se o deslizador for posicionado completamente à direita, o Map Viewer mostrará somente a imagem rótulo, se o deslizador estiver completamente à esquerda, somente a imagem selecionada será mostrada. Em qualquer posição entre os dois extremos, Map Viewer mostrará a combinação da imagem selecionada e os resultados da classificação. Após o usuário ajustar a posição do deslizador ele/ela precisa pressionar o botão Generate map (Gerar mapa) para que a combinação seja executada.

A imagem rótulo gerada como saída da classificação mostra as regiões preenchidas com a mesma cor definida para os nós da rede semântica. Se no entanto o usuário clica no botão Random Colors (cores randômicas), Map Viewer mostrará as regiões com cores randômicas. Para voltar às cores originais (da rede semântica) o usuário deve clicar em Generate map (Gerar mapa).

Com os botões “+” e “-“ o usuário poderá comandar as operações de ampliação (zoom in) e redução (zoom out) respectivamente.

Finalmente com o botão Save map (Salvar o mapa) o usuário pode salvar o mapa temático sendo visualizado no Map Viewer (conforme mostrado na tela) a uma imagem do tipo PPP (portable pixel map) (mapa de pixel portátil).

7. Incluindo novos operadores

Conforme foi dito anteriormente (capítulo 2), os operadores usados pelo sistema são programas externos. Esta seção fornece a referencia básica para incluir novos operadores no InterIMAGE.

Tanto nos passos de processamento top-down como bottom-up, o processo de controle do InterIMAGE visita todos os nós da rede semântica, executando os operadores associados a cada nó. Os operadores são programas externos stand-alone que geram como saída uma lista de regiões e uma imagem-rótulo contendo as regiões.

7.1. Operadores Top-Down

Qualquer operador precisa conter a descrição que determina como InterIMAGE deve manuseá-lo. Esta descrição precisa ser codificada em arquivos XML com extensão op, e colocada na pasta ./share/data/operators/ , dentro do diretório raiz do InterIMAGE. Basicamente a descrição XML do operador diz ao sistema sobre como construir a linha de comando para executar o programa executável associado. O texto abaixo é um exemplo da descrição do operador:

<operator type=topdown class=gis name="TerraAIDA_ShapeFile_Import"cmd="ta_shp_import \"@geoWest@\" \"@geoNorth@\" \"@geoEast@\"

27

\"@geoSouth@\" \"@output@\" \"@class@\" \"@tmpdir@\"\"@mask_file@\" \"@shp_file_name@\" \"@shp_attributes_str@\"\"@label_img_res_str@\" \"@node_weight@\" "runglobal=false tip="Import shape files regions into the analysisprocess" ><attribute name=shp_file_name type=string label="Shape file name"><attribute name=shp_attributes_str type=string label="Shape fileattributes" ><attribute name=label_img_res_str type=double label="Label imageresolution" value=0.5 ><attribute name=node_weight label="Node weight" type=doublevalue=1.0></operator>

A descrição do operador define um grupo de argumentos que precisam ser ajustados de alguma forma. Alguns desses argumentos são automaticamente ajustados pelo sistema e são acessíveis somente pela inclusão de seu nome na propriedade cmd do operador. Outros precisam estar presentes no campo cmd e possuir um attribute tag (etiqueta de atributo) que definirá as suas propriedades:

Os argumentos (automaticamente configurados pelo sistema) são:

● geoWest, geoNorth, geoEast, geoSouth: limites geográficos dos dados de imagem.

● minRes, maxRes: resolução mínima e máxima dos dados da imagem.

● output: nome do arquivo de saída (no formato PPM3) indicando os dados da imagem de entrada que o operador deve processar.

● input_file: nome do arquivo de imagem de entrada (no formato PPM (3) indicando os dados da imagem de entrada que o operador deve processar.

● mask_file: nome do arquivo máscara, um mapa binário (no formato PBM (3) indicando a área nos dados da imagem de entrada que o operador deve processar.

● mask_x,mask_y: coordenadas do pixel de origem (canto superior esquerdo) dos dados da imagem de entrada a serem processados pelo operador.

● mask_size_x, mask_size_y: tamanho do arquivo máscara, em pixels.

(3) A descrição do formato pode ser encontrada em http://netpbm.sourceforge.net/doc/.● tmpdir: caminho do diretório temporário, usado pelo InterIMAGE para arquivar resultados intermediários do processo de análise.

28

● class: classe do nó conceito da rede semântica para a qual o operador foi definido como o operador top-down.

● fuzzysets: caminho do arquivo dos conjuntos fuzzy, usados por operadores genéricos (vide seção 4.3).

Os seguintes atributos são definidos para cada imagem fornecida ao operador. As seguintes linhas contém somente os sufixos dos nomes de atributos; numa definição de operadores atuais devem ser prefixados pelo nome da imagem (nome do atributo do parâmetro correspondente do tipo IMAGE na descrição do arquivo do operador).

Atributos dependentes da imagem:

● _key

● _type

● _file

● _res_x,_res_y

● _size_x,_size_y

Além dos argumentos automaticamente definidos pelo sistema, o usuário pode definir atributos específicos do operador, que serão considerados como parâmetros que podem ser definidos no Node Properties Panel (Painel das propriedades do nó) do Main Window (Janela principal) do InterIMAGE (vide capítulo 3). Tais atributos precisam ser definidos através de uma etiqueta de atributos, tal como no exemplo acima.

7.1.1. Arquivo de descrição da região

InterIMAGE espera como a saída de um operador top-down, umaq descrição da hipótese da região encontrada pelo operador, e uma imagem rotulada com a representação espacial da hipótese de região.

O nome e o caminho do arquivo da região de saída é dado pelo atributo output (saída), passado para o operador como um argumento de linha de comando.

Os conteúdos do arquivo devem ser uma lista de regiões, descritas individualmente como nós da região XML. Os nós precisam estar delimitados por etiquetas <region> e devem ter os seguintes atributos:

● class: indica a classe da região. Somente regiões que correspondam à classe do nó de chamada são transferidos à rede de instancias (instance net).

● id: um id numérico (integral) da região na imagem rótulo. O id é único

29

no arquivo (imagem rótulo). Cada pixel pertencente à região possui o valor id.

● file: o nome do arquivo da imagem rótulo onde a região é representada. Várias regiões podem usar a mesma imagem-rótulo enquanto não houver sobreposição espacial e os seus valores de id forem diferentes.

● file_geoSouth, file_geoWest, file_geoNorth, file_geoEast: descrevem a caixa envoltória da imagem rótulo em geo-coordenadas (projeção UTM). Se a imagem rótulo cobrir a mesma área geográfica que os dados de imagem repassadas pelo núcleo ao chamar o operador, estes valores devem ser exatamente os mesmos daqueles em argumentos da linha de comando file_geoSouth, file_geoWest, file_geoNorth, file_geoEast (vide seção anterior).

● name: o nome da região. Serve somente para finalidades de visualização. Se nenhum nome for indicado, o nome é indicado automaticamente do nome da classe e de um número seqüencial.

● Ilx,IIy, urx, ury: descreve a caixa envoltória da região dentro da Imagem rótulo(4) . As coordenadas do pixel expressas por estes valores são relativas à imagem-rótulo, ou seja a origem do sistema de coordenadas é o canto inferior direito da imagem rótulo. Se x e y definem uma coordenada de pixel dentro da região, então llx<=x<=urx e ury <=y<=lly.

● geoNorth, geoSouth, geoWest, geoEast: descrevem a caixa envolvente da região em geo-coordenadas (4). Como esta caixa envolvente está exatamente no limite da região, em vista disso ela é maior em meio pixel em cada direção do que a caixa em pixels.

● p: um valor de confiança para a hipótese de região. O operador pode definir um valor de confiança arbitrário, de 0 a 1, para as regiões encontradas. Este valor poderá adicionalmente ser usado no passo de processamento bottom-up para a decisão sobre hipóteses espacialmente concorrentes. Não é um atributo mandatório e pode ser definido no processamento bottom-up, mas é importante informar que na ausência de um valor de p ou se o valor é o mesmo para hipóteses espacialmente concorrentes, o sistema decidirá sobre as regiões numa forma randômica.

(4) Somente um dos grupos de atributos “llx, lly, urx, ury” ou “geoNorth, geoSouth, geoWest, geoEast” precisa estar presente nas descrições dos nós.

As descrições da região também podem conter quaisquer outros atributos definidos e calculados pelo operador top-down. Estes atributos podem ser

30

usados no processo bottom-up, para a decisão sobre hipóteses de regiões que se sobrepõem.

No exemplo abaixo a saída de um operador top-down é apresentada. São definidas quatro regiões. Os atributos area, perim, large, small, s_index e assim foram calculados pelo operador.

<region id=1 class=Region llx=10 lly=59 urx=29 ury=18file=region.plm p=0.1 area=779 perim=120 large=41 small=19s_index=0.075 assim=1.158 /><region id=2 class= Region llx=38 lly=59 urx=57 ury=18 file=region.plm p=0.1 area=779 perim=120 large=41 small=19s_index=0.075 assim=1.158 /><region id=3 class= Region llx=66 lly=59 urx=85 ury=18 file=region.plm p=0.1 area=779 perim=120 large=41 small=19s_index=0.075 assim=1.158 /><region id=4 class= Region llx=10 lly=88 urx=29 ury=79 file=region.plm p=0.1 area=171 perim=56 large=19 small=9 s_index=0.071assim=1.111 />

7.1.2. Imagem rótulo da região

Os nós no arquivo de descrição da região gerados pelo operador top-down referenciam uma imagem-rótulo (através de um atributo de arquivo), onde as respectivas regiões são representadas.

Mesmo que cada região num arquivo de descrição da região podem ser representados numa imagem rótulo diferente, geralmente todas as regiões são representadas no mesmo arquivo de imagem (imagem rótulo).

O arquivo de imagem deve estar nos formatos PGM ou PFM. (5) Em cada arquivo, cada pixel pertencente a uma região precisa ter o mesmo valor do id daquela região. Todos os outros pixels na imagem devem ter o valor de 0 (zero).

7.2. Operadores bottom-up

A tarefa de um operador bottom-up é agrupar a lista de nós que recebe como entrada, resolvendo concomitantemente conflitos espaciais entre hipóteses de conceitos sobrepostos. Cada grupo contém uma quantidade de instâncias particularmente agrupadas em conjunto por um motivo específico.

(5) A descrição do formato pode ser encontrada em http://netpbm.sourceforge.net/doc/

Para cada grupo, o operador bottom-up precisa gerar uma imagem rótulo (mapa de instância) no qual cada nó (instância) que pertença a este grupo precisa ser retratado e identificado por um único rótulo.

31

O operador também precisa produzir uma imagem rótulo (mapa do grupo) onde todos os grupos gerados precisam ser retratados e identificados por seu id único.

As regiões relacionadas aos nós (instâncias) validadas pelo operador precisam estar espacialmente disjuntos (valendo para todos os nós em todos os grupos).

Um operador bottom-up precisa ter um arquivo descritivo (op) similar a aqueles dos operadores top-down (vide seção 7.1). Nas linhas a seguir apresentamos um exemplo de um arquivo de descrição de operador para um operador bottom-up.

<operator type=bottomup class=bu name="Generic BottomUp"tip="Select regions using a UPN command"cmd="ga_bu_generic \"@input@\" \"@output@\" \"@cmd@\"\"@fuzzysets@\" "><attribute name=cmd label="Decision Rule" type=formula></operator>

Os atributos globais que são aqueles automaticamente definidos pelo sistema e que podem ser usados como argumentos pelo binário do operador, são somente dois:● input: (entrada) nome da lista dos nós de entrada (um arquivo com a descrição da hipótese da região a ser julgada pelo operador).

● output: (saída) nome da lista dos nós de saída (um arquivo com a descrição dos nós da rede de instâncias ou de quaisquer grupos de nós eventualmente criados). Este atributo é também o prefixo das imagens, imagens rótulo, onde os nós e grupos estão representados. Os nós da rede de instâncias precisam ser representados num arquivo denominado [output].bu.node.plm e os grupos num arquivo com o nome [output].bu.plm (os arquivos de imagem podem estar nos formatos PGM ou PFM (6). No InterIMAGE a extensão PLM pode referir-se a um arquivo de imagem PPM ou PGM. Pode referir-se também a um formato PAM específico, designado para aceitar informação com ranges dinâmicos maiores.As linhas abaixo são um exemplo de descrições de nós de entrada, num arquivo de entrada hipotético, para um operador bottom-up.(6) No InterIMAGE a extensão PLM pode se referir a um arquivo de imagem PPM ou PGM. Também pode se referir a um formato PAM específico, designado para aceitar informações com um range dinâmico maior. <node id="1" class="Region" name="Region_002_001" addr="0x831a560"status="CI" llx="0" lly="99" urx="99" ury="0" size="9998"geoSouth="1100.00" geoNorth="1200.00" geoEast="1100.00"geoWest="1000.00" file_geoNorth="1200.00" file_geoSouth="1100.00"file_geoEast="1100.00" file_geoWest="1000.00"file="/tmp/4312/Scene/Region_002/0082-output.bu.plm" /><node id="1" class="Region" name="Region_005_001" addr="0x82e6638"status="CI" llx="0" lly="99" urx="99" ury="0" size="9998"geoSouth="1000.00" geoNorth="1100.00" geoEast="1200.00"

32

geoWest="1100.00" file_geoNorth="1100.00" file_geoSouth="1000.00"file_geoEast="1200.00" file_geoWest="1100.00"file="/project/interimage/tmp/4312/Scene/Region_005/0090-output.bu.plm" />

E as linhas abaixo são um exemplo de uma lista de nós de saída, um resultado do processamento do operador bottom-up.

<group id="1" file="/tmp/4312/Scene/0098-output.bu.plm"file_geoSouth="1000" file_geoNorth="1200" file_geoWest="1000"file_geoEast="1200"><node id="2" addr="0x831a560" llx="0" lly="99" class="Region"urx="99" ury="0" file_geoNorth="1200.00" file_geoSouth="1000.00"file_geoWest="1000.00" file_geoEast="1200.00" p="1.00"file="/tmp/4312/Scene/0098-output.bu.node.plm"name="Region_002_001"/><node id="3" addr="0x82e6638" llx="100" lly="199" class="Region"urx="199" ury="100" file_geoNorth="1200.00"file_geoSouth="1000.00" file_geoWest="1000.00"file_geoEast="1200.00" p="1.00"file="/project/interimage/tmp/4312/Scene/0098-output.bu.node.plm" name="Region_005_001"/></group>

7.2.1. Lista de nós

Os operadores bottom-up recebem como entrada uma lista de nós. Um operador bottom-up processará a lista de nós para:

a) instanciar os nós; validar ou negar a hipótese do nó de entrada e resolver conflitos espaciais que se sobrepõem;

b) gerar um mapa (imagem rótulo) dos nós;c) juntar os nós em grupos.

A estrutura da descrição do nó é a mesma para a lista dos nós de entrada e para os nós de saída. Descrições de nós de instância simples são fechadas numa etiqueta <nó>, e grupos de nós numa etiqueta <grupo>.

Os nós podem ter atributos arbitrários, porém os seguintes atributos são obrigatórios (7) :

(7) Somente um dos grupos de atributos “llx, lly, urx, ury” ou “geoNorth, geoSouth, geoWest, geoEast” precisam estar presentes nas descrições dos nós.

● class: determina a classe (conceito) da região associada ao nó.● id: o id do nó. Os pixels na imagem rótulo pertencentes à região associada ao nó precisam ter um valor igual ao id.● file: é o nome do arquivo da imagem-rótulo onde as regiões de nós estão representadas. Visto que diversas regiões podem ser representadas na

33

mesma imagem-rótulo, a distinção entre estas regiões é feita pela id da região.● llx, lly, urx, ury: a caixa envoltória da região em pixels dentro de um arquivo de imagem-rótulo. Se x e y definem uma coordenada de pixel dentro da região, então llx <= x <= urx e ury <= y <= lly.

● geoNorth, geoSouth, geoWest, geoEast: define a caixa envoltória da região em geo-coordenadas. Visto que esta caixa envoltória geográfica está exatamente na borda da região, por isso ela é meio pixel maior em cada direção do que a caixa envoltória em pixels.

● file_geoNorth, file_geoSouth, file_geoWest, file_geoEast: define a caixa envoltória geográfica de todo o arquivo de imagem-rótulo.

● name: é o nome da região. Serve somente para finalidades de visualização. Se nenhum nome for indicado, um nome é gerado automaticamente a partir do nome da classe e de um número seqüencial.

● addr: o endereço de memória (apontador) deste nó. Este atributo não deve ser atualizado já que representa a área de memória onde os nós atribuem valores que será alocada/lida por InterIMAGE, os seus valores deverão tão- somente copiados da lista de nós de entrada.

Um operador bottom-up processará a lista dos nós de entrada para gerar a lista dos nós de saída e os grupos de nós. Verifica-se, a partir dos arquivos de descrição de nós de entrada e saída, conforme visto na seção anterior, qual atributo addr não muda. InterIMAGE estabeleceu os endereços de nós antes de escrever o arquivo da lista de nós de entrada. Através deste endereço, o operador bottom-up pode obter as informações necessárias sobre os nós, para a decisão de instanciação/falsificação. O processamento bottom-up também pode mudar a forma das regiões do nó, e representar esta mudança nas imagens rótulo de saída.Se um nó contido no nó de entrada não estiver presente nos arquivos de saída (descrição do nó e imagens rótulo), o sistema as considerará como uma hipótese descartada.

8. Implementação e instalação

O sistema e o seu código-fonte podem ser abaixados do site do Projeto InterIMAGE: http://www.lvc.ele.puc-rio.br/projects/interimage/, ou do repositório SourceForge: http://sourceforge.net/projects/interimage/.

Assim que o usuário baixou e desempacotou todos os arquivos do InterIMAGE, um arquivo executável denominado de interimage estará disponível no InterIMAGE diretório raiz (que pode ser livremente definido pelo usuário).

Alguns operadores básicos (top-down e bottom-up estão incluídos no pacote do sistema. Outros operadores (fonte e executáveis) podem ser encontrados em http://www.dpi.inpe.br/terraaida.

34

O usuário também pode abaixar alguns exemplos do portal para começar com o InterIMAGE. Podem ser encontrados na seção de Documentação do site.

Agradecimentos

O desenvolvimento do aplicativo InterIMAGE foi parcialmente financiado pelas seguintes instituições:

● Financiadora de Estudos e Projetos (FINEP) do Ministério da Ciência e Tecnologia (MCT).● Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE).● Fundação de Amparo à Pesquisa do Estado do Rio de Janeiro (FAPERJ).

A equipe de desenvolvimento do InterIMAGE também agradece pelo excelente trabalho realizado pelo Institut für Informationsverarbeitung (TNT) da Universidade Leibniz, em Hannover (Alemanha) pelo desenvolvimento do aplicativo GeoAIDA.

Referencias bibliográficas

Bückner, J., Pahl, M., Stahlhut, O., Liedtke, C.-E., 2001. GEOAIDA - A knowledge-based automatic image data analyzer for remote sensing data. In: ICSC Congress on Computational Intelligence Methods and Applications 2001 - CIMA 2001, Bangor, Wales, UK. Proceedings of the Congress on Computational Intelligence Methods and Applications 2001 - CIMA 2001 (CD-ROM).

Câmara, G., Souza, R.C.M., Pedrosa, B.M., Vinhas, L., Monteiro, A.M.V., Paiva, J.A., Carvalho, M.T., Gatass, M., 2000. TerraLib: Technology in Support of GIS Innovation. In: II Brazilian Symposium on GeoInformatics, GEOINFO 2000. São Paulo, Brazil. Proceedings of GEOINFO 2000 (CD- ROM).

Pahl, M., 2003. Architektur eines wissensbasierten Systems zur Interpretation multisensorieller Fernerkundungsdaten. PhD Thesis. Institut für Theoretische Nachrichtentechnik und Informationsverarbeitung, University of Hannover, Hannover, Germany.

Pahl, M., 2008. Arquitetura de um sistema baseado em conhecimento para a interpretação de dados de sensoriamento remoto de múltiplos sensores. PhD Thesis, University of Hannover, (Tradução da dissertação acima citada), INPE, São José dos Campos (INPE-15211-TAE/71) URL: <http://urlib.net/sid.inpe.br/mtc-m17@80/2008/03.07.18.31> (26.09.2008).

35