A solução para a dualidade de bancos de dados geográficos
Durante o processo de solução de problemas usando GIS, é necessário identificar todos os objetos do mundo real necessários para o trabalho. Em seguida, é preciso extrair um conjunto de características de cada objeto identificado, em um processo de abstração, a base da modelagem de dados. Neste processo, determinados aspectos do objeto são desprezados, e são determinadas as características essenciais para que o seu comportamento ou funcionamento sejam adequadamente incorporados ao sistema. São descritas tanto características geométricas, que nos possibilitam visualizar o objeto em tela ou no papel, quanto características descritivas, codificadas alfanumericamente, que contêm informações adicionais sobre o objeto.
A maioria dos GIS separa as características geométricas e descritivas em estruturas de dados separadas, configurando o que se denomina arquitetura dual. Existem diversas razões para essa separação, e as principais são o desempenho do GIS e o volume de armazenamento exigido. As características geométricas são, em geral, armazenadas em uma estrutura de dados proprietária, que apenas os desenvolvedores do GIS detêm informações técnicas para decifrar. Essa estrutura é definida de modo a tornar rápidas a recuperação e a exibição da informação geométrica. Por outro lado, as características descritivas já são bem administradas pelos sistemas gerenciadores de bancos de dados relacionais (SGBDR) amplamente disponíveis no mercado – e portanto o desenvolvedor do GIS tem um problema a menos com que se preocupar.
Ocorre que a arquitetura dual tem um ponto fraco, que é a dificuldade em garantir a integridade entre as partes geométrica e descritiva da representação do objeto geográfico. Na maioria dos casos, existe a possibilidade de um usuário desavisado acessar o banco de dados alfanumérico e, inadvertidamente, modificar algo sem que a estrutura de dados geométricos tenha conhecimento do fato.
Para resolver este problema, é necessário acabar com a dualidade do banco de dados geográfico. Diversos caminhos foram tentados ao longo dos anos neste sentido. Uma alternativa envolveu a criação de estruturas proprietárias tanto para a parte geométrica quanto para a parte descritiva. Essa saída não é a ideal, pois dificulta ou mesmo impede a integração dos dados geográficos ao conjunto das informações da organização – o que está completamente na contramão da história. A demanda atual é por sistemas que facilitem ao máximo a integração do conjunto de informações disponíveis, e a tecnologia GIS é sempre candidata a servir de catalisador para que essa integração aconteça. Outra alternativa para resolver a dualidade resultou em um problema semelhante. O uso de bancos de dados orientados a objetos impede a quebra da integridade, mas não resolve totalmente o problema de integração do GIS a outros sistemas de informação, que são, em sua ampla maioria, baseados em SGBDR.
Resta ainda uma alternativa, que consiste na codificação da forma geométrica dos objetos usando as tabelas típicas dos SGBDR. Como resultado, toda a codificação da geometria fica aberta e acessível, aumentando bastante a possibilidade de integração do GIS a outros sistemas. No entanto, a grande variabilidade estrutural da informação geométrica (por exemplo, dados vetoriais podem ser representados usando desde um único par de coordenadas até milhares) faz com que tais SGBDR apresentem problemas de consumo excessivo de espaço em disco e baixo desempenho.
A solução mais moderna que se apresenta utiliza um novo conceito: o de bancos de dados objeto-relacionais. Para as aplicações geográficas, a idéia é que todas as características dos objetos geográficos sejam codificadas em tabelas, como nos SGBDR. As características descritivas são codificadas usando os tipos de dados usuais, ou seja, números e cadeias de caracteres. Um dos atributos, no entanto, é de um tipo especial, de tamanho variável, capaz de registrar a descrição completa da geometria. Esse tipo de atributo, denominado SDO_GEOMETRY, é implementado no SGBD Oracle 8i através da extensão Spatial. A definição de SDO_GEOMETRY é a seguinte:
O campo SDO_GTYPE serve para especificar qual é o tipo de geometria do objeto, usando um número. Os valores válidos estão na Tabela 1. Observe que existe previsão para a representação de objetos de mais de duas dimensões, mas para as aplicações usuais de GIS 2D é suficiente. Esses tipos de geometria correspondem aos definidos pelo Consórcio OpenGIS (leia entrevista, no padrão denominado Geometry Object Model for the OGIS Simple Features for SQL, à exceção do tipo reservado para superfícies, ainda não implementado no Oracle 8i Spatial.
O campo SDO_SRID é usado para especificar o sistema de referência espacial (sistema de coordenadas) associado à geometria. Curiosamente, este valor se repete em todos os objetos de uma tabela. O valor numérico corresponde à chave de uma tabela auxiliar que acompanha o produto, onde estão registrados os parâmetros um número muito grande de projeções cartográficas e sistemas de coordenadas.
Em seguida, o campo SDO_POINT define um ponto tridimensional, cujas coordenadas X e Y são consideradas válidas para a representação do objeto se os campos seguintes estiverem vazios. Se não estiverem, esse campo é ignorado.
Os campos restantes, SDO_ELEM_INFO e SDO_ORDINATES, são formados por listas de grupos de números. No primeiro três valores são usados para definir o início de um grupo de coordenadas e sua interpretação geométrica. No segundo são armazenadas as coordenadas propriamente ditas. Com essa estrutura, existe grande flexibilidade em representar a forma geométrica, permitindo polígonos com ilhas e buracos, agrupamentos de pontos, poligonais e polígonos com segmentos em arco de círculo, retângulos, círculos, e diversas outras combinações.
Para que se possa entender melhor como funciona essa representação, a Figura 1 apresenta três objetos em um sistema simples de coordenadas, e a Tabela 2 expõe a codificação comentada.
Figura 1 – Objetos a armazenar.
Como já foi dito, essa forma de codificação da geometria foi baseada nos padrões desenvolvidos pelo Consórcio OpenGIS, e é ao mesmo tempo simples e poderosa. Observe como não está previsto qualquer suporte no banco a atributos gráficos como cor, tipo de linha e padrão de preenchimento. Isso é deixado a cargo do GIS, que é o responsável por extrair os objetos geográficos do banco de dados e apresentá-los na tela do usuário. Não é tarefa do banco de dados armazenar tais parâmetros, até mesmo porque seria difícil fazer com que outros usuários tivessem a liberdade de escolher atributos gráficos diferentes. Desta forma, fica muito bem caracterizada, no banco de dados, a separação entre representação (a codificação da geometria) e apresentação (parâmetros de visualização) da informação geográfica.
Existe suporte aos tradicionais predicados de relacionamento espacial entre objetos (tais como toca, cruza e dentro – vide InfoGEO número 12), que podem ser usados para compor comandos SQL e recuperar objetos do banco. No entanto, o banco de dados não gerencia estruturas topológicas para determinar tais relacionamentos: todo o processamento é realizado construindo dinamicamente a topologia na região geográfica da consulta. Ainda assim, o processamento é primeiro realizado de modo aproximado, usando os retângulos envolventes mínimos dos objetos, para só depois, se houver necessidade, comparar as formas geométricas completas e determinar se o relacionamento espacial existe ou não.
Esta implementação, e o amplo suporte que vem recebendo dos desenvolvedores de GIS (o Oracle 8i Spatial já pode funcionar com uma ampla variedade de softwares, incluindo as famílias ARC/INFO, ArcView, GeoMedia, MapGuide, MapInfo e MicroStation Geographics), indicam que a era da topologia explicitamente armazenada está chegando ao fim.
Clodoveu Davis é engenheiro civil, doutor em Ciência da Computação e Assessor de Desenvolvimento e Estudos da Prodabel – Empresa de Informática e Informação do Município de Belo Horizonte. Rua Alagoas, 314/1501. CEP 30130-160 – Belo Horizonte – MG . Tel.:(031)9978-1422 . Fax:(031)224-0022 . e-mail: cdavis@uol.com.br