FuturoGEO

Em 1994, publiquei o artigo "Anatomia de Sistemas de Informação Geográfica", que apresentava os diferentes componentes da tecnologia de Geoprocessamento, e analisava o que ofereciam alguns dos sistemas disponíveis no mercado. Neste artigo, pretendo atualizar esta visão geral, e explicar o que mudou desde então. Também espero preparar o leitor para o debate "O Futuro do GIS", que será realizado como parte do GeoBrasil 2.000, em junho na cidade de São Paulo, em que esperamos a presença de representantes da ORACLE, Intergraph e SmallWorld, além deste colunista.

Há cinco anos, a quase totalidade dos sistemas poderia ser enquadrada como um ambiente mono-usuário, no qual as diferentes funções (entrada, consulta, análise, visualização) são acessadas a partir de uma única interface. Atualmente, há uma grande diversificação de oferta, com pelo menos quatro grandes tecnologias complementares, analisadas a seguir:

 Os "GIS desktop", com interfaces amigáveis e crescente funcionalidade.

 Os "Gerenciadores de Dados Geográficos", que armazenam os dados espaciais em ambiente multi-usuário.

 Os "Componentes GIS", ambientes de programação que fornecem insumos para que o usuário crie seu próprio aplicativo geográfico.

 As "Soluções Web para Dados Geográficos", utilizadas para publicação e acesso a dados geográficos via Internet.

O Poder Crescente do "Desktop"
Num "GIS desktop", os dados geográficos são armazenados de forma separada, com os atributos descritivos guardados em tabelas (usualmente no padrão xBase) e as geometrias em formatos proprietários (como os "shapefiles" do ARC/VIEW). Nos sistemas derivados de CAD, como o MICROSTATION GEOGRAPHICS, há ainda uma separação entre as representações do desenho e da topografia.

Originalmente sistemas simples de consulta e apresentação de dados, os "GIS desktop" têm evoluído para oferecer uma crescente gama de funcionalidades, incluindo:

 A combinação de tratamento de dados vetoriais e matriciais ("raster") no mesmo ambiente, com uma integração maior entre Processamento de Imagens e GIS, a exemplo do IDRISI.

 Linguagens de programação de "scripts", em que as variáveis refletem os tipos de dados geográficos suportados pelo sistema (e.g., AVENUE do ARC/VIEW e MAPBASIC do MAPINFO), e que permitem ampliar a funcionalidade disponível.

 Ferramentas sofisticadas de Análise Espacial, como os módulos de Geoestatística disponíveis nas novas versões do IDRISI, ARC/INFO E SPRING e funções de Álgebra de Mapas como as disponíveis no módulo SPATIAL ANALYST do ARC/VIEW.

 Uma integração do "desktop" com os gerenciadores de dados geográficos, como no caso da ligação entre GEOMEDIA com ORACLE SPATIAL e AUTOCADMAP com VISION*.

 O aumento do potencial de interoperabilidade e da conversão automática de formatos de dados geográficos, como suportado pelo GEOMEDIA.

 O uso de conceitos de orientação-a-objetos, que permitem uma aproximação melhor entre os problemas do mundo real e sua representação computacional, como no ARC/INFO-8 e no SPRING.

Gerenciadores de Dados Geográficos
Nos anos recentes, o interesse pelo uso de GIS no ambiente corporativo levou ao aparecimento de gerenciadores de dados geográficos, que armazenam tanto a geometria como os atributos dos objetos dentro de um sistema gerenciador de bancos de dados (SGBD). As principais vantagens desta estratégia são: (a) evitar os problemas de controle de integridade típicos do ambiente "desktop", permitindo o acesso concorrente aos dados; (b) facilitar a integração com as bases corporativas já existentes, como sistemas legados, que já utilizam SGBDs relacionais.

Estes gerenciadores possuem dois componentes, usualmente de distintos fabricantes: um SGBD com suporte a dados geográficos e uma "camada de acesso", que fornece um ambiente de armazenamento e recuperação, visível externamente ou integrado a um "GIS desktop".

Por enquanto, os SGBD geográficos armazenam apenas representações vetoriais (pontos, redes e polígonos), com três classes principais de tecnologias:

 SGBD relacional no qual as representações de dados geográficos são armazenadas como atributos numéricos em tabelas. Cada ponto é representado por um par de coordenadas x-y (cada um numa coluna separada) e cada arco é guardado como referência a dois pontos (o inicial e o final). Reconstruir a geometria de um polígono complexo requer a junção de dados de múltiplas tabelas, o que pode limitar o desempenho do sistema para grandes massas de dados. Esta é a estratégia adotada no ORACLE SPATIAL.

 SGBD relacional com suporte para campos longos (um campo longo é uma cadeia binária onde se pode armazenar informação gráfica, numérica ou pictórica). O acesso ao conteúdo dos campos longos é deixado a cargo de uma interface de aplicação. Este é o caso do CA*INGRES.

 SGBD extensível (tipicamente relacional com suporte a orientação-a-objetos), que permite a definição de novos tipos de dados (como linhas e polígonos). A idéia neste caso é que os dados espaciais são simplesmente um tipo de dado adicional em um SGBD relacional-objeto. Este é o caso do INFORMIX DATABLADE e do IBM DB2 SPATIAL EXTENDER.

As "camadas de acesso" interagem com estes servidores para fornecer um ambiente de armazenamento e recuperação através de uma interface de programação (API). Estes produtos podem ser divididos em duas grandes classes:

 Ambientes de programação genéricos que fornecem funções de acesso aos bancos de dados geográficos. Como exemplo temos SDE/ESRI e MAPINFO/SPATIALWARE.

 Sistemas de Gerência de Dados, especialmente para aplicações de redes ("AM/FM"), que oferecem, além do acesso aos dados, mecanismos sofisticados de controle de transações (como "check-in"/"check-out" ou gerência de versões). Como exemplo temos VISION* e SMALLWORLD GIS .

O uso de componentes permite uma flexibilidade maior de personalização da interface e da funcionalidade. No entanto, o que os fabricantes estão oferecendo são objetos simples (tipicamente abstrações de tabelas, mapas vetoriais e imagens bitmap), com funções de consulta e apresentação, o que limita o escopo do uso dessa tecnologia. A alternativa é utilizar uma biblioteca de rotinas, num ambiente de programação em linguagens como C ou C++. Podemos citar a biblioteca SPRINGLib, usada no desenvolvimento do SPRING e produtos derivados. Neste caso, toda a funcionalidade do sistema está disponível, mas precisa ser remontada pelo programador.

A Internet é baseada no conceito de ambiente cliente/servidor. O cliente faz um pedido de serviço, e o servidor processa-o e retorna a informação ao cliente. Este processamento é afetado por fatores como velocidade da conexão, capacidade de resposta do servidor e confiabilidade das diferentes componentes da rede.

As arquiteturas para difusão de Geoinformação na Web podem ser divididas em duas grandes classes: baseadas em clientes ("client-side") e baseadas em servidores ("server side").

Em aplicações "server-side", o usuário solicita dados através de um navegador, e estes pedidos são tratados remotamente, por uma combinação de um servidor Web padrão (HTTP) e um servidor específico para dados geográficos. Ao receber um pedido remoto, o servidor Web repassa-o para o servidor GIS que processa o pedido e envia como retorno um dado nos formatos aceito no padrão HTML, geralmente uma imagem nos formato GIF ou JPEG.

As vantagens deste tipo de arquitetura são uma maior simplicidade de montagem e manutenção do servidor WebGIS e uma acessibilidade imediata do cliente, sem necessidade de qualquer adaptação. Entretanto, esta solução tem usualmente um tempo de acesso lento, pois qualquer novo pedido é enviado de volta para o servidor, resultando em mais uma transferência pela Internet. Adicionalmente, é dificil simular, através das interfaces padrão HTML, operações de consulta típicas de GIS como seleção e apontamento de feições.
As arquiteturas "client-side" adotam como solução o uso de programas adicionais ("plug-ins") acoplados a "browsers" como o Netscape ou o Explorer ou de "applets" Java, instalados no ambiente do usuário. Estes produtos adicionais comunicam-se diretamente com bancos de dados remotos, transmitindo dados no formato vetorial.

Qual o futuro do GIS? Pelas tendências apresentadas neste artigo, a tecnologia está amadurecendo, para que o usuário possa construir a solução do tamanho de sua necessidade. Em compensação, a diversidade obriga a uma escolha muito mais cuidadosa. Se, em 1994, escolhíamos o sistema a ser utilizado, hoje precisamos primeiro determinar a arquitetura que melhor nos convém, sabendo que precisaremos de equipes competentes para combinar as diferentes soluções. Assim, antes de escolher sua solução de Geoinformação, faça um desenho detalhado de suas necessidades, agora e no futuro. Procure identificar quais os componentes necessários, e planeje uma incorporação tecnológica gradual, na qual sua empresa vai construindo o ambiente desejado, passo-a-passo. Lembre-se da receita de todos os projetos de êxito aqui e no Exterior: invista muito na formação de pessoal. Equipes capacitadas são a melhor resposta para o desafio de bem usar as tecnologias.

O autor agradece a Clodoveu Davis (PRODABEL) e Flávio Yuaça (Comdata), pelas importantes contribuições para este artigo e também a Antônio Miguel Monteiro, João Paiva e Ricardo Cartaxo (INPE), Ubirajara Freitas (FUNCATE), Marcelo Gattass e Marco Casanova (PUC/RJ), pelas muitas discussões sobre o tema,nos últimos anos.