Apresentações são dispensáveis quando se fala das vantagens e horizontes promissores da imersão do GIS na internet, o GISWeb, SIGWeb ou um dos diversos outros termos análogos. Um ótimo exemplo são os sistemas Google Maps e Google Earth, que popularizaram o uso de informações geográficas de forma inédita. Diversas outras soluções para implementação de GISWeb, proprietárias e livres, também já estão à disposição de empresas de qualquer porte, universidades ou usuários mais vorazes.
Todavia, como grande parte das áreas tecnológicas, o GISWeb tem desafios a ultrapassar. A computação em nuvem, por exemplo, é um novo paradigma neste ambiente, porém ainda é difícil realizar um sistema de informação geográfica na web próximo ao que se tem hoje instalado nos computadores, ou seja, um SIG Desktop. Os motivos para isso são diversos, sendo um processo de maturação tecnológica e dos recursos disponíveis.
O problema do cliente limitado
Entre os fatores que limitam os sistemas GISWeb atuais, um dos mais discutidos tem sido a limitação do navegador de internet (browser), deixando quase todo o processamento a cargo dos sistemas servidores, que vamos chamar aqui apenas de servidor. Na grande parte dos GISWeb atuais, o cliente (navegador ou browser) apenas provê a interface ao usuário e exibe imagens processadas, que ilustram os dados geográficos. Em outras palavras, o cliente não trabalha com os dados em si, mas com “fotos” deles, chamadas de snapshots, que são providas e geradas pelo servidor.
Para citar um exemplo, suponha uma imagem retratando a América do Sul. O usuário então realiza uma operação de zoom na área da Bolívia. O cliente faz a solicitação ao servidor, que por sua vez acessa seu banco de dados e transmite a nova imagem ao cliente. A figura a seguir ilustra um exemplo, onde os servidores do Google Maps estão provendo a nova imagem em blocos separados, chamados titles. Na figura, apenas alguns blocos já foram recebidos pelo navegador após a operação de zoom, enquanto os outros estão com uma resolução insatisfatória à nova escala de visualização.
Nesse tipo de sistema, que é o mais utilizado hoje, cada operação de navegação, consulta aos dados ou outra que altere a visualização gráfica ao usuário gera a necessidade de uma nova imagem, que é processada e enviada pelo servidor. Neste cenário, não é difícil prever que o processamento no servidor e o tráfego de rede são muito demandados, o que compromete o desempenho geral e limita as ferramentas viáveis à utilização.
A evolução desses sistemas já permitiu o advento de recursos mitigadores aos problemas mencionados. Dentre esses recursos, podemos citar o tráfego de rede, a compactação de imagem e a divisão da mesma em blocos – o title mencionado anteriormente, junto à figura. Para o processamento do servidor, podemos citar o recurso de cache, onde é armazenado um conjunto de imagens de resposta ao cliente, não as gerando dinamicamente no servidor. O cache troca certo volume de processamento por outro volume de armazenamento.
Mesmo com esses recursos, a limitação ainda é significativa. O principal problema se dá no uso das imagens como elemento de visualização dos dados geográficos junto ao cliente. Como dito anteriormente, o cliente não detém o dado, mas apenas uma figura representativa. Desta maneira, qualquer operação que necessite do dado tem que ser repassada ao servidor.
A alternativa
Como o problema descrito aqui se concentra na imagem, podemos buscar alternativas nas próprias formas de representação da informação geográfica no SIG: a representação matricial e a vetorial.
A representação matricial subdivide a superfície em células ou pixels de tamanho regular, gerando uma matriz, ou seja, a imagem é uma representação matricial. As bandas de satélite são um bom exemplo de dado nesta representação, onde um formato de arquivo, comumente aplicado no SIG, é o Tagged Image File Format (tiff).
A representação vetorial é essencialmente composta por coordenadas que constituem pontos, linhas ou polígonos no espaço. Um formato de arquivo muito utilizado em SIG para esta representação é o formato Esri shapefile (shp).
A escolha entre as representações se dá principalmente por dois fatores: a natureza da informação que se quer representar e o tipo de processamento que se deseja realizar com a informação. Por exemplo, não é pertinente representar uma banda de satélite na forma vetorial, devido à alta variação da radiação eletromagnética no espaço. Por sua vez, não é recomendado realizar cálculos de rotas sobre um sistema viário na representação matricial, pois a mesma não estrutura bem a topologia dos arruamentos.
Em linhas gerais, o SIG trabalha com boa parte das informações na representação vetorial, cabendo à matricial os dados de sensoriamento remoto, geofísicos e superfícies interpoladas de relevo, chuvas, temperatura e afins.
No que tange o GISWeb, a representação vetorial apresenta as seguintes vantagens: é mais compacta, em geral, do que a representação matricial, diminuindo o tráfego de rede; e permite maior autonomia ao cliente para processar os dados. Ou seja, ataca dois problemas apontados anteriormente no uso de imagens.
Então por que não se usa representação vetorial? A resposta é simples: falta de suporte e padronização, ao menos até há pouco tempo. Em contrapartida, imagens são suportadas na web desde seu início. Segundo autores da área, a proposta inicial da internet era “trabalhar com documentos contendo texto e eventualmente imagens” que, por sinal, a definição é bem despretensiosa em relação aos padrões atuais.
As iniciativas em prol dos dados vetoriais na web são recentes, onde pode-se destacar: padronização pelo World Wide Web Consortium (W3C) do formato de arquivo Scalable Vectorial Graphics (SVG) e do elemento Canvas, que permite o desenho de vetores; e a interface para serviços Web Feature Service (WFS) criada pelo Open Geospatial Consortium (OGC), para comunicação de dados vetoriais entre cliente e servidor.
Neste cenário, é comum o uso de plug-ins, que são programas que rodam dentro do navegador e não estão limitados aos recursos do padrão na web. Pode-se citar, como exemplo, o Flash Player e plug-in para Java. A desvantagem deste recurso é a necessidade de download e instalação do plug-in, compatibilidade com os principais navegadores, controle de atualização, entre outros.
Mesmo tendo o recurso de comunicação e exibição, os dados vetoriais requerem uma série de técnicas para serem bem aportados num GISWeb, provendo sistemas inteligentes. Como trabalhar com os dados vetoriais no cliente? Como diminuir a redundância de envio de dados, fazendo uma comunicação otimizada? Como aumentar a interatividade do usuário? Estas perguntas estão sendo exploradas pela academia e algumas empresas já desprendem esforços neste sentido.
Um exemplo de GISWeb com abordagem vetorial
Para citar um exemplo de sistema que explora algumas facetas do cenário abordado, vejamos o Progressive Vector Map Browser (PVMB), criado num trabalho acadêmico do Instituto de Computação da UFF e do Instituto Alberto Luiz Coimbra de Pós-graduação e Pesquisa de Engenharia (Coppe) da UFRJ. Ele trabalha com dados vetoriais, os transmite de forma progressiva (em blocos) e minimiza o tráfego de dados redundantes. Todos os recursos utilizados no cliente e no servidor são softwares livres e, principalmente, seguem a última especificação HTML 5 da W3C, ou seja, sem o uso de plug-ins ou recursos não padronizados.
No PVMB, os vetores são exibidos num nível de detalhe mínimo necessário para visualização corrente do cliente. Se o usuário, por exemplo, realizar uma operação de Zoom, são enviados apenas os níveis de detalhes adicionais necessários, aproveitando a informação já contida no cliente.
No fluxo de dados entre o servidor e cliente, o PMVB envia as informações em blocos. A cada bloco de dados recebido, o mesmo é exibido, dando o efeito de atualização progressiva dos níveis de detalhe. Veja a figura abaixo, na qual foi realizada uma aproximação no Estado do Rio de Janeiro. Em (b) se tem o display logo após o Zoom, em (c) e (d) se tem a atualização progressiva dos níveis de detalhe.
Por último, o cliente contém um cache de tamanho limitado, no qual armazena os vetores recebidos pelo servidor. Se o usuário, por exemplo, realizar uma operação de navegação, apenas os dados que não constam neste cache serão enviados. Quando o cache fica cheio, o cliente elimina os dados com menor probabilidade de reuso, segundo uma heurística.
Com os vetores armazenados no desktop, se optarmos por alterar a cor dos mesmos, o servidor não será demandado, isto é, ficará apenas a cargo do cliente.
Tendências futuras?
O uso de dados vetoriais no GISWeb, para constituir sistemas mais inteligentes, está dando passos significativos. O problema no uso de imagens já está bem identificado, cabe agora a academia e empresas explorarem uma melhor solução, tendo em vista que muitas técnicas precisam ser elaboradas ou aprimoradas.
Todavia, a tendência mais provável é que os sistemas GISWeb trabalhem com representações vetoriais e matriciais concomitantemente, como ocorre nos sistemas desktop. Como dito anteriormente, cada representação é mais propícia a determinados casos. Quando se imerge o GIS na web, há inúmeras questões a serem abordadas, muitas ainda a explorar.
José Augusto Sapienza Ramos
Bacharel em ciência da computação pela Universidade Federal Fluminense (UFF), professor de cursos de extensão em geotecnologias na Universidade do Estado do Rio de Janeiro (Uerj) e analista GIS pela empresa Gisplan
ja_sapienza@yahoo.com.br
