CAPÍTULO 6
CONCLUSÕES E TRABALHOS FUTUROS
Este trabalho apresenta uma proposta de arquitetura para disseminação de dados
geográficos do tipo Cliente-Servidor de Dados Geográficos, utilizando a tecnologia JAVA
(Applet/Servlet) para sua implementação. Inicialmente, discutimos no Capítulo 2 as
principais características das arquiteturas disponíveis e constatamos que um dos grandes
desafios, para disseminar dados geográficos pela Internet, é a necessidade de transferência
de grandes arquivos de imagem, ou vetores, que são utilizados para representação gráfica
desses dados. Mesmo utilizando técnicas de compactação ou organização dos dados, como
(Evans,1996) e (Ferreira,1998), os usuários de aplicações de dados geográficos para
Internet sofrem com o tempo de espera dos arquivos para visualização. Em alguns casos
uma escolha infeliz nas opções de visualização pode ocasionar uma demora indesejada, o
que torna a interação com o aplicativo improdutiva.
Nas medidas de tempo efetuadas podemos constatar que o fato do cliente acessar o servidor
através de uma rede local, ou através da Internet, não tem muita influência sobre os
processamentos efetuados integralmente no servidor. Um fator mais representativo é a
concorrência de outros programas pelos recursos do servidor. Como exemplo, se um cliente
solicita a transferência de um conjunto de geometrias no instante em que o servidor está
ocupado executando outra tarefa, seu pedido levará mais tempo para ser atendido do que
em situações onde o servidor está desocupado.
Nas situações onde há acessos simultâneos e os pedidos chegam quase ao mesmo tempo ao
servidor é estabelecido um atendimento por filas, ou seja, o primeiro a chegar será o
74
primeiro a ser atendido. Isto pode ocasionar longos períodos de espera para se executar uma
consulta simples quando as consultas que estiverem na sua frente na fila forem demoradas.
De maneira geral, as atividades de transferência de dados entre cliente e servidor são as
mais demoradas. Os tempos para acessos via Internet são bem maiores que os medidos para
os acessos via redes locais. No protótipo desenvolvido, o cliente fica com seu aplicativo
inoperante enquanto o servidor não responde às suas consultas. Para acessos via Internet,
esta situação pode levar o usuário a desistir de esperar quando a resposta estiver demorando
muito e abandonar o aplicativo. Além das técnicas de compactação já citadas, é necessário
desenvolver outras técnicas para tornar a interação com o usuário mais eficiente quando há
necessidade de transferência de dados entre o servidor e o cliente.
As interações do usuário com os dados, depois de já terem sido integralmente transferidos
ao cliente, não apresentou problemas e podemos considerar sua performance aceitável para
as atividades de seleção e apresentação dos dados geográficos.
O protótipo mostrou ser viável a utilização da tecnologia JAVA para disseminação de
dados geográficos, no entanto, é necessário aprimorar sua implementação para tornar o
processo mais interativo para o usuário buscando formas de minimizar o tempo de espera
pelo resultado de suas consultas.
Como discutido nos capítulos anteriores, existe uma variedade de SIGs e cada um deles
utiliza um modelo conceitual diferente. A utilização de um modelo conceitual para a
arquitetura proposta permite a organização e apresentação dos dados de forma hierárquica.
O esquema do banco de dados geográfico converte-se numa forma natural de apresentar
metadados para o usuário. Desta forma conhecendo o modelo conceitual e o esquema do
75
banco de dados geográfico o usuário tem mais facilidades para selecionar os dados de seu
interesse. A comunicação entre o cliente e o servidor fica simplificada pela utilização de
um modelo conceitual para manipulação dos dados por ambos os lados. Neste caso, tanto o
cliente como o servidor tem conhecimento sobre todas as entidades que podem ser
manipuladas pelo sistema. Como ainda não existe um modelo de consenso, neste trabalho
foi utilizado um modelo conceitual que utiliza a representação dos dados geográficos na
forma especificada pelo OpenGis® que pode vir a se tornar padrão de facto.
6.1 TRABALHOS FUTUROS
Neste trabalho a única iniciativa em direção a interoperabilidade foi a utilização de
representação dos dados geográficos na forma de WKG definidas pelo OpenGis®. Em
trabalhos futuros o problema da interoperabilidade pode ser abordado de maneira mais
abrangente apresentando alternativas para integração de dados geográficos provenientes de
bases de dados heterogêneas.
Devido a falta de consenso no padrão OpenGis® para a forma de representação de campos
este tipo de dado não foi implementado no sistema desenvolvido para testar a arquitetura.
Outra limitação é a ênfase nos aspectos descritivos dos dados para sua seleção antes que o
usuário tenha uma interface para navegação e interação. A forma com que são tratados os
metadados no sistema podem ser ampliadas fornecendo mecanismos mais eficientes para
que o usuário explore de forma mais eficiente o conteúdo do banco de dados geográfico.
76
As estruturas utilizadas para organização das representações dos dados geográficos (listas)
são simples e ineficientes para buscas com restrições espaciais. A implementação de
estruturas hierárquicas de busca, tal como RTREE (Guttman,1984), traria grande aumento
de eficiência para busca e apresentação dos dados geográficos.
O armazenamento de representações de dados geográficos em campos binários longos de
SGBDR ainda necessita de algumas medidas comparativas de performance com relação aos
sistemas de arquivos convencionais. Uma análise mais detalhada neste sentido traria
informações úteis sobre alguns tipos de limitação que esta arquitetura possa apresentar.
A forma de consulta deve ser expandida para permitir além de buscas pelas descrições
consultas espaciais, utilizando uma linguagem de consultas espaciais tais como LEGAL
(Câmara,1995) e Spatial SQL (Egenhover,1994).
A utilização de tecnologia de objetos distribuídos DCOM, CORBA, RMI pode ser avaliada
como alternativa para implementação no lugar da
tecnologia “applet-servlet”. Estas
tecnologias podem facilitar a integração do sistema com outros sistemas e bibliotecas de
programas existentes.
A implementação do protótipo não possibilita que o usuário possa continuar trabalhando
enquanto os dados estão sendo transferidos entre o cliente e o servidor e vice-versa. Seria
mais conveniente que este processo de transferência fosse transparente para o usuário e
assim que novos dados fossem chegando eles já ficassem disponíveis para utilização.
77