Divisão de Observação da Terra e Geoinformática

Foram levantados alguns requisitos para o TerraView pela equipe que trabalha com modelagem:

1. Legenda: agrupamento de atributos (vetoriais) ou valores (raster) categóricos (e.g., 10 classes de solo agrupadas em três).

2. Exportar e importar layer de células (para troca de dados entre bancos terralib).

3. Geração de dados temáticos (vetoriais) e raster a partir de determinados atributos das células.

Não vejo grandes dificuldades em atender a esses requisitos, ainda que não tenha feito uma avaliação mais precisa. Existe uma versão 3.2.0, prevista para o final de abril, vou tentar encaixar essas demandas nessa versão. Assim que forem sendo feitas, disponibilizo versões para vocês testarem.

dando retorno ao que foi solicitado e que pode ser providenciado imediatamente:

1. em www.dpi.inpe.br/tmp/Lubia encontra-se um zip com o código mais recente do que a Priscila conseguiu fazer com a interface de preenchimento das células. Está junto o form da interface e o projeto.

2. quanto as modificações de arquitetura para as funções de preenchimento feitas pelo Pedro, elas ainda não foram aprovadas pela Ana Paula, pois houve perda de algumas funcionalidades. O código hoje na versão atual da TerraLib é o original da Ana. Ela e Pedro ainda estão trabalhando para convergir para o código mais eficiente, porém sem perder funcionalidade. A pessoa que pode avaliar isso é só a Ana Paula.

1. A equipe do TerraView/TerraLib é hoje bem limitada. Meu time tem 2 pessoas trabalhando no TerraView, eu, Karine e Gribeiro na TerraLib, e Emiliano na PDI. Este time é pequeno para tantas expectativas que todos temos sobre TV/TL.

2. Estamos tentando fazer um planejamento direito esse ano, mas estou começando a ficar desconfortável com toda essa expectativa e cobrança de funcionalidades.

3. Plugins até bem pouco tempo eram *experimentais. *O Emiliano a cada dia acho um novo erro e aperfeiçoa mais o sistema. Pra quem pensa que é simples não é… no Linux é mais fácil, no Windows dá pau pra caramba.

1. Atualmente, estou lecionando a disciplina “Técnicas de Programação II” para 36 alunos do Curso de Bacharelado em Ciência da Computação da UFOP. Nessa disciplina ensino C++, padrões de projeto de software, APIs para desenvolvimento de GUI, BD, Threads e Soquetes TCP/IP. Os alunos precisam para concluir o curso, desenvolver uma sistema que utilize estas APIs, mas encontram dificuldades em propor uma àrea aplicação. Então, estou colocando esta mão-de-obra ociosa a dispor da equipe de modelagem para o desenvolvimento de GUIs para integração TerraME/TerraLib.

1. A função CellularSpace:load poderia ter como parâmetros o tempo dos atributos, para carregar automaticamente os atributos dinâmicos em cada passo temporal do modelo.

2. A função CellularSpace:save poderia salvar os dados numa tabela temporal, para facilitar o controle de visualização. Isto seria acoplado com melhorias no TerraView para visualizar seqüências temporais.

1. Idealizei a função “load()” e “save()” para que carregassem e gravassem dados de acordo com o relógio de simulação, desta maneira o parâmetro “tempo” poderia ser dispensado. Entretanto, uma versão onde o tempo é passado como parâmetro é desejável. Especialmente quando se deseja carregar ou gravar espaços celulares de instantes passados ou futuros.

1. As API para manipulação de dados espaço-temporais existem mas não foram exercitadas. Estamos redefinindo isso, com a ajuda do Casanova. Esta é uma das prioridades para a TLib 4.0. Na reunião de 2 de março de planejamento TLib teremos uma idéia de datas de versões. Podemos utilizar a versão existente na TLib 3.1.3 e que deve permanecer a mesma ( ou com leves modificações) na TLib 3.2, planejada para Abril.

1. Permitir a visualização de uma tabela temporal com um barra de tempo para permitir animação (automática e manual).

1. Um cuidado especial deve ser tomando para a implementação desta funcionalidade: as legendas! Os limites máximos e mínimos de um determinado atributo da tabela dinâmica são diferentes para diferentes instantes do tempo. Portanto, da maneira que o TerraView calcula as legendas, estas teriam limites diferentes para cada instante de tempo, cores diferentes seriam associados a um mesmo valor, ou a mesma cor seria associada a valores distintos. Tal fato dificultaria sobremaneira a comparação visual de mapas de diferentes instantes de tempo.

2. Por exemplo, no modelo hidrologico de “Cabeça de Boi”, no primeiro instante a célula que acumulou a maior quantidade de água, possui o valor “2” em seu atributo “qteAgua”. A cor “azul escuro” é associada ao valor “2”. Entretanto, no instante “36” o maior acúmulo de água supera algumas dezenas, então a cor “azul escuro” é associado ao valor máximo do atributo “qtdeAgua” e ao valor “2” é associado a cor “azul claro” (clarissimo). Assim, como poderiamos comparar estes dois mapas visualmente?

3. Sugestão: O modelador tem codições de após análise do comportamento do modelo e da análise de sensibiliade do modelo a seus parâmetros, diagnosticar seu ponto de equilibrio, e determinar quais são os valores ideiais para os limites inferior e superior da legenda. Portanto, a interface TerraView deveria permitir que o seu usuário definisse estes valores, e os mesmos deveriam ser utilizados para todos os tempos.

1. Questões relativas a apresentação de dados temporais em TView precisam ser vistas com mais cuidado. Nao existe somente o dado celular em TLib e, portanto, o TView, que é o visualizador básico para um BD TLib, trata este conjunto de tipos. Assim, uma solução que envolva o “query” e a apresentação de dados espaço-temporais, armazenados em um BDTLib, através do seu visualizador TView precisa observar mais requisitos que apenas àqueles que as necessidades de visualizaçao para as “saídas” do TerraME necessitam.

2. É bom pensar mais um pouco antes de sair oferecendo soluções em TView que acabam atendendo bem a um “tipo” de dado geográfico, mas complicam para o universo de usos de um software com a natureza do TView. Estamos estudando isso, e o importante agora é determinar os requisitos de apresentação e visualização para os “Mundos Celulares” que devem entrar, com os outros requisitos derivados de dados e aplicações de outra natureza, no projeto da apresentação de dados espaço-temporais em TView.

1. Talvez o problema que mais restrinja o uso de TerraME é a ausência de uma interface gráfica com o usuário (Graphical User Interface - GUI) por meio da qual os usuários do TerraView possam preencher os atributos das células a partir de dados geográficos armazenado em bancos TerraLib. O desenvolvimento dessa GUI deve ser vista como PRIORIDADE no desenvolvimento de funcionalidades para acoplamento TerraME/TerraView.

1. A estratégia até o momento pensada para a questão relativa ao “preenchimento de BD Celular” é a construção de um Plug-in TerraView. Este trabalho foi iniciado, existe código pronto e precisa ser retomado e finalizado, o que deve acontecer este semestre. E está na agenda da reunião de planejamento de TLib, dia 2 de março.

1. Contem comigo para ajudar no desenvolvimento da interface para preenchimento das células. Mesmo antes da decisão sobre como encaminhar a questão nessa reunião do início de março, vou adiantar dois aspectos: a) Fechar com o Pedro algumas pendências relativas à reengenharia das funções e operadores em Terralib, para incorporar a nova versão na biblioteca. b) Pedir para a Priscila o projeto e código de interface que ela começou a implementar ano passado (e também recuperar os meus projetos preliminares).

1. Conversei hoje com a Lúbia sobre a interface de preenchimento de células do TerraView. Peço que a Lúbia e a Ana Paula analisem a proposta de Álgebra de Mapas feita pelo Danilo e Sérgio para saber se pode ser aplicada à interface de geração de espaços celulares. Vejam o paperem anexo. O Danilo já fez uma interface simplificada para esta Álgebra de Mapas. Para saber mais, conversem com o Sérgio e também convido para a defesa da dissertação do Danilo no dia 27/03.