The exchange of geographical data is an important problem and of difficult treatment. The most common approach is just about the direct syntactic conversion that presents a series of problems. This work presents an analysis of the different approachs proposals for the problem of Interoperability, covering the syntactic and semantic level through the use of metadata, ontologies and languages based on the XML standard. It is also presented how the format GeoBR can promote the interoperability in semantic level.

O intercâmbio de dados espaciais é um importante desafio no uso das geotecnologias, impulsionado principalmente pelo alto custo de produção deste tipo de dados. Segundo Hartman (1998), em um ambiente de sistemas heterogêneos, a aquisição de dados representa um custo entre 60% e 80% do custo total na implantação de Sistemas de Informação Geográfica.

Para modelar objetos e fenômenos georreferenciados, cada SIG utiliza um modelo conceitual próprio. Esta diversidade faz com que organizações produtoras de informação georreferenciada sigam regras conceituais vinculadas ao sistema por elas utilizado. O resultado é um ambiente heterogêneo, onde cada organização tem sua maneira de tratar a informação espacial.

Esta falta de modelos conceituais comuns acarreta problemas na troca de dados entre organizações utilizando SIGs distintos, que incluem distorção de dados, comprometimento de qualidade da informação, perda de definições de atributos e georreferenciamento. Para que o intercâmbio de dados espaciais aconteça sem o comprometimento da informação é necessário um alto grau de interoperabilidade entre os SIGs.

Em SIGs, alcançar a interoperabilidade não é uma tarefa simples, devido a complexidade da informação geográfica envolvida, ocorrendo incompatibilidades em níveis sintático e semântico. Propostas existentes, como a conversão direta entre formatos de exportação próprios dos SIGs mais comuns no mercado DXF (Autocad), Shape (ArcView), MID/MIF (MapInfo), E00 (ArcInfo) e o uso de formatos independentes como SDTS (USGS, 1998), têm maior ênfase no aspecto sintático. A interoperabilidade plena requer não só uma equivalência sintática entre as entidades representadas pelos sistemas, mas inclui também a equivalência de conceitos e significados destas entidades. Assim surgem propostas como o uso de metadados (FGDC, 2001), modelos genéricos para dados espaciais (Bauzer Medeiros, Pires, et al., 1997, Davis, Borges et al., in press) e Ontologias (Fonseca, 2000).

Com base nesta motivação, este artigo discute novas abordagens ao problema da interoperabilidade entre sistemas heterogêneos e autônomos através do uso de linguagens baseadas no padrão XML para descrever metadados RDFSchemas (W3C, 2001) e Ontologias DAML+OIL (DARPA, 2001), e apresenta como o formato GeoBR pretende promover a interoperabilidade de dados espaciais em nível semântico através do uso de abordagens discutidas. Como complemento, é mostrado ainda a incorporação de um mecanismo para intercâmbio semântico no software "open-source" TerraTranslator (Lima, 2002).

O restante deste artigo é organizado da seguinte maneira: a seção 2 apresenta diferentes níveis de abordagem para o problema da interoperabilidade entre SIGs e algumas propostas existentes na tentativa de tratar o problema. A seção 3 descreve o uso de XML como padrão de intercâmbio e linguagens derivadas deste padrão. A seção 4 apresenta o uso de GeoBR com DAML+OIL para promover a interoperabilidade semântica. E a seção 5 apresenta o TerraTranslator como um mecanismo para manipulação semântica de dados espaciais.

A abordagem mais básica para intercâmbio de dados geográficos é a conversão sintática direta, que procura realizar a tradução dos arquivos de informação geográfica entre diferentes formatos.

Para permitir este tipo de conversão, os SIGs trabalham com duas alternativas: (a) oferecer um formato de exportação ASCII de fácil legibilidade, como DXF (Autocad), MID/MIF (MapInfo), E00 (Arc/Info) e SPR (Spring); (b) documentar as estruturas de dados internas, como no caso do SHP (ArcView). Estes formatos não garantem a transferência sem distorção de informações, pois são organizados de acordo com o sistema que os gerou, e quando importados para sistemas conceitualmente diferentes, necessitam de manipulação externa.

Existem ainda formatos independentes de sistema para intercâmbio de dados como o SDTS - Spatial Data Transfer Standard (USGS, 1998). O SDTS é projetado especificamente como um formato para transferência de dados, não para uso direto. Para isto, é especificado em partes que procuram abordar o nível conceitual, o lógico e o físico.

Apesar da decisão do Governo dos EUA em padronizar o SDTS para todos os órgãos federais americanos, este formato apresenta diversos problemas. O modelo conceitual do SDTS tem conteúdo semântico limitado, e está fortemente acoplado às definições do sistema Arc/Info-7. O padrão SDTS não contempla os conceitos de modelagem espacial orientada a objetos, não estabelece definições de metadados, não descreve formalmente relacionamentos espaciais e nem tem formas de capturar procedimentos de consulta e análise. Em resumo, o SDTS comporta-se como um formato de intercâmbio tradicional do tipo SHP ou MIF, sem grandes vantagens adicionais.

Apesar das limitações da conversão sintática, deve-se reconhecer que a grande maioria dos processos de conversão de dados opera neste nível (Hartman, 1998).

Para facilitar este processo, estão disponíveis ferramentas de conversão, tanto sob forma de programas comerciais, como o FME, ou disponíveis como open source (FreeGIS, 2001).

O consórcio OpenGIS pretende definir um modelo de dados genérico e interfaces padronizadas para acesso a bancos de dados geográficos, baseadas em diferentes tecnologias, como XML, COM, Java e SQL (OGC, 1996).

Esta abordagem segue o conceito de API (Application Programming Interface), o que fornece uma forma unificada de acesso às funcionalidades de sistemas distintos.

Apesar dos inegáveis avanços, a proposta OpenGIS tem várias limitações. Para começar, a existência de uma API resolve apenas o problema de acesso padronizado a bancos de dados espaciais e não substitui a necessidade da transferência dos dados entre sistemas.

O padrão OpenGIS inclui, até o momento, apenas operações topológicas de consulta sobre objetos simples (Egenhofer and Franzosa, 1991) sem permitir a definição de relacionamentos espaciais para definição de restrições espaciais, como proposto em Davis et al (2001). Os problemas de especialização e hierarquia entre classes de objetos também ainda não foram resolvidos.

Adicionalmente, alguns sistemas existentes têm modelos conceituais mais ricos em conteúdo que o OpenGIS, e seu mapeamento para o OpenGIS pode representar sensível perda de informação semântica (Câmara, Thomé et al., 1999).

Finalmente, o uso da linguagem SQL como base para a linguagem de consulta no caso de OpenGIS é questionável. Como mostram Egenhofer (1992) e Câmara (1995), o padrão declarativo do SQL tem diversas limitações para tratar com dados geográficos. O SQL não prevê a existência de uma linguagem de apresentação associada às consultas realizadas, e nem suporta o conceito de que o resultado de consultas retorne objetos e campos, para manipulação posterior.

Metadados descrevem o conteúdo, condição, histórico, a localização e o formato do dado. O objetivo do seu uso é ter um mecanismo para identificar qual dado existe, a sua qualidade e como acessá-lo e usá-lo. A principal proposta de padrão de metadados é do FGDC (Federal Geographic Data Committee), comitê que promove a coordenação do uso, troca e disseminação de dados espaciais nos EUA (FGDC, 2001).

O padrão FGDC estabelece um conjunto comum de definições para a documentação do dado geográfico, incluindo: identificação, qualidade do dado, organização espacial do dado, referência espacial, informação sobre entidade e atributo, distribuição e referência do metadado.

O FGDC também patrocina a criação de uma clearinghouse (National Geospatial Data Clearinghouse).

Trata-se de um site que guia usuários ao melhor dado espacial para seus projetos por meio de pesquisa a metadados disponibilizados no padrão do FGDC por órgãos produtores de dados espaciais.

Como sua ênfase é na disponibilidade da informação, o padrão FGDC não especifica a maneira pela qual a informação está organizada nem o processo de transferência. Com exceção da parte de entidades e atributos, que pode revelar parte do significado do dado, as demais partes não descrevem a semântica da informação espacial.

O grande problema da proposta do FGDC (e do uso de metadados em geral) é a excessiva ênfase em informações que descrevem o processo de produção dos dados. Com relação à sintaxe, o padrão limita-se a indicar qual o formato em que os dados estão disponíveis. No aspecto semântico, suas informações são muito limitadas, pois o FGDC não adota o "modelo padrão" de geoinformação (campos e objetos). Adicionalmente, o padrão do FGDC reflete os compromissos inevitáveis do "projeto de comitê", pois requer uma excessiva quantidade de informações (de aplicação questionável), com dezenas de formulários.

Em resumo, a substancial burocracia envolvida em adotar o padrão FGDC não se traduz em benefícios proporcionais. Estes fatos talvez expliquem porque sua adoção ainda está limitada e porque o consórcio OpenGIS propõe seu próprio formato para metadados.

O aspecto semântico diz respeito à representação conceitual da informação geográfica presente em cada sistema. Como comunidades com cultura e história diferentes que interpretam distintamente a realidade geográfica e produzem sistemas conceitualmente heterogêneos, a capacidade de transferir dados de um sistema para outro não garante que os dados têm significado para o novo usuário (Fonseca, Egenhofer et al., 2000).

Adicionalmente, os modelos adotados nos SIGs implementam diferentemente conceitos de campos e objetos. Por exemplo, comparemos os sistemas MGE/Intergraph e SPRING (Câmara, Thomé et al., 1999).

Um dado geográfico representado no sistema MGE como uma especialização do tipo básico CLASSE DE FEIÇÕES pode ser mapeado para duas classes no SPRING.

TEMATICO e OBJETOS. Esta duplicidade de mapeamento acontece porque no MGE não existe distinção para representar geo-campos contínuos e geocampos discretos. Neste caso, o termo CLASSE DE FEIÇÃO é utilizado para representar estes dois tipos de fenômenos.

Isto indica que, para que o intercâmbio aconteça, um conjunto consistente de interpretações deve estar disponível para a informação, levando a um significado comum sobre o dado trocado.

Nesta visão semântica, a realização plena da interoperabilidade depende de compartilhamento de conceitos comuns entre os membros de uma comunidade de informação. Estes conceitos incluem: (a) o modelo de dados, como no caso do modelo OMT-G (Davis, Borges et al., in press); (b) o dicionário de conceitos, indicado por uma ontologia comum (Fonseca, Egenhofer et al., 2000); (c) o dicionário de procedimentos, que contém os diferentes mecanismos de consulta, manipulação e apresentação utilizados para extrair informação dos dados compartilhados (Câmara, 2000).

O uso de Ontologias para interoperabilidade de dados geográficos ainda está nos seus primórdios, sem exemplos concretos nem padrões estabelecidos. Espera-se que, nos próximos anos, haja um substancial desenvolvimento neste campo.

O problema da interoperabilidade não é exclusividade para usuários de SIGs, mas é uma questão para todos os sistemas computacionais, impulsionado principalmente pelo avanço das redes de computadores, e o padrão XML foi projetado com o propósito de resolver este problema.

O padrão XML codifica o conteúdo de um documento, ou descreve dados, e não sua apresentação. A forma como os dados descritos serão interpretados e apresentados é função da aplicação que os usará. O uso de XML é vantajoso, pois é ideal para descrever estruturas de dados hierárquicas e complexas, características comuns em dados espaciais, o dado permanece legível, pois usa a codificação ASCII, e acessível através de programas que acessam dados no padrão, os " parsers XML" . Além destas vantagens, o uso de XML vem aumentando e este cada vez mais afirmado como padrão para armazenar e trocar dados.

Mecanismos para promover a interoperabilidade são propostos como linguagens baseadas no padrão XML, específicas para dados geográficos como GML2.1.1 (OGC, 2002) ou que procuram incluir descrição semântica nos dados, como RDFSchema (W3C, 2001) e DAML+OIL (DARPA, 2001), impulsionadas principalmente pelo projeto Semantic Web (Berners-Lee et al, 2001).

GML 2.1.1 (Geography Markup Language) foi especificada para o transporte e armazenamento de informação geográfica, incluindo propriedades espaciais e não espaciais das feições geográficas (OGC, 2002).

O objetivo é oferecer um conjunto de regras com as quais um usuário pode definir sua própria linguagem para descrever seus dados. Para tanto a GML é baseada em Esquema XML (XML Schema). O Esquema XML define os elementos (tags) usados em um documento que descreve os dados. Atualmente a linguagem está em sua versão 2.1.1 e esta inclui Esquemas que contêm os modelos mais básicos de geometria e feições (features).

Os Esquemas estão publicados nas especificações do OpenGIS (OGC, 2002) e atualmente existem três, a saber:

• Feature.xsd – define tipos e elementos concretos e abstratos de acordo com a especificação do OpenGIS.
• Geometry.xsd – define a geometria de acordo com a especificação do OpenGIS.
• Xlinks.xsd – define formas de ligação entre documentos e elementos dentro de um documento XML.

De posse destes Esquemas um usuário pode definir, seu próprio Esquema para sua aplicação. Mas há algumas exigências a seguir para obter conformidade descritas em (OGC, 2001).

A GML 2.1.1 inclui modelos básicos para feições e geometrias. Para representar outros modelos como superfícies, a GML 2.1.1 por si só, não é adequada, necessitando ser estendida com a adição de um Esquema de aplicação.

Os Esquemas da GML sozinhos não são adequados para criar uma instância de documento. Estes devem ser estendidos pela criação de Esquemas de aplicação para domínios específicos, seguindo as regras descritas na especificação, somente assim, pode-se garantir que um Esquema e seus dados serão úteis para um software baseado em GML. Isto exige um investimento na elaboração de Esquemas.

GML 2.1.1 possui pontos, linhas, polígonos e coleções geométricas (MultiPoint, MultiPolygon) definidos por coordenadas cartesianas uni, bi ou tridimensionais associados a eventuais Sistemas de Referência Espacial. Mas as localizações espaciais são definidas apenas por coordenadas cartesianas, coordenadas projetivas não estão previstas.

Ainda sobre Sistema de Referência Espacial, a seção 4.3.2 – Geometry Elements, diz que " as coordenadas de uma geometria são definidas em um Sistema de Referência Espacial (SRS), e toda geometria deve especificar este SRS. GML 2.1 não trata dos detalhes da definição de Sistemas de Referência Espacial" . O que descaracteriza GML 2.1.1 como padrão para transferência de dados espaciais, ao passo que cada usuário pode descrever da sua forma Sistemas de Referência Espacial. Já que existem várias geometrias sob um mesmo Sistema de Referência Espacial, repetir o Sistema para cada geometria é um ponto redundante. O ideal é fazer como todo SIG de mercado, e anexar o Sistema de Referência Espacial a um elemento de nível superior no caso de GML, <featureCollection>, que representa uma coleção de feições que possuem geometria e atributos não espaciais em um mesmo sistema de referência.

Uma vantagem no uso de XML é a flexibilidade oferecida para criar " tags" que expressam o significado do dado descrito, obtendo-se um documento rico semanticamente. Mas, considere a seguinte situação: Dois usuários de domínios diferentes representam uma determinada entidade, pela GML, como <rio> e <curso_de_agua>. Em uma troca de dados entre os usuários, os Esquemas também devem ser compartilhados, pois só assim uma aplicação poderá saber que <rio> ou <curso_de_agua> são da classe <_Feature> definida pelo Esquema Feature.xsd da GML, e então usá-los adequadamente. Desta forma o problema de acesso aos dados é resolvido. Mas como saber que <rio> é <curso_de_agua> e vice-versa? O aspecto semântico não é considerado de forma efetiva a promover a interoperabilidade. Para amenizar este problema, pode-se acrescentar tags que descrevem as entidades e suas relações, ou que identifiquem sinônimos. Mas dentro de um ambiente heterogêneo, o ideal seria a criação de uma forma unificada ou padronizada de realizar isto, definida também nas especificações do OGIS.

A GML, se baseia em conceitos comuns no domínio dos SIGs, como pontos, linhas e polígonos, apresentando assim, deficiencias de precisão semântica. Como exemplo, temos o caso da definição de linha fechada (LinearRing) que não exige na prática que esta seja constituída por mais de um ponto, ou o fragmento <LinearRing> <coordinates>10.0,10.0</coordinates></LinearRing> é válido.

Outra questão relevante no uso de GML é a disponibilidade de ferramentas computacionais.

A validação de dados GML pode ser feita por um " parser" XML que suporte Esquemas, e garante a validade do mesmo segundo os Esquemas GML, mas não verifica os detalhes exigidos na seção 5.2 da especificação do padrão GML. Não valida Esquemas de Aplicações de usuários.

Espera-se que estas questões sejam tratadas para a versão 3.0 que pretende incluir Superfícies (Coverages) TIN, superfícies poliédricas, curvas, Topologia, Bibliotecas de Sistemas de Coordenadas, Dados Temporais (Temporal Features), Endereços Postais e Metadados.

Semantic Web é uma extensão da Web atual na qual a informação recebe um significado bem definido possibilitando computadores e pessoas a trabalharem em cooperação (Berners-Lee et al, 2001). Neste sentido, a Semantic Web é uma visão: a idéia de ter dados na Web definidos e ligados para serem usados por máquinas não apenas para apresentação, mas para automação, integração e reuso entre aplicações. Para isto, os dados devem ser descritos de forma que a máquina entenda seu significado.

A seguir são apresentadas, linguagens baseadas no padrão XML que se enquadram como tecnologia para promover a idéia da Semantic Web.

No cenário atual, o uso de XML como padrão para intercâmbio de dados é inquestionável. Mas a simples descrição dos dados por tags XML promove a interoperabilidade semântica apenas quando houver um software pronto a entender o significado das tags e inferir relacionamentos entre entidades produzindo novas informações a partir das que recebeu. O ideal é aproveitar o poder de descrição semântica do padrão XML para estruturar os dados, explicitando relacionamentos entre entidades, de forma que novas informações possam ser inferidas a partir do próprio dado. Portanto, este trabalho propõe o uso de DAML+OIL (DARPA Agent Markup Language + Ontology Inference Layer) como forma de descrever ontologias para os dados espaciais e promover a interoperabilidade semântica.

A proposta de vários Esquemas que devem ser estendidos para Esquemas de aplicação é interessante quando se deseja flexibilidade na descrição dos dados, fácil consulta e uso dos dados entre comunidades que adotam o mesmo Esquema. Mas quando se trata de intercâmbio de dados, a criação de Esquemas de aplicação deve prever fatores que tornam este trabalho mais árduo, como estrutura lógica dos dados e tamanho dos arquivos gerados. Portanto é necessário um investimento na criação de Esquemas de aplicação. Além disso, a existência de diferentes Esquemas de aplicação, acarreta em esforço para conversão de dados. Os Esquemas a serem estendidos devem por sua vez, incluir suporte para todos os tipos de dados espaciais (campos e objetos) a fim de oferecer compatibilidade com dados existentes em outros formatos.

A proposta do GeoBR (Lima, 2002) é um Esquema único, com elementos pré-definidos, o que faz com que um arquivo GeoBR seja facilmente acessado por uma única interface de programação. E um outro arquivo descreve de forma genérica com o uso de DAML, as entidades e relacionamentos presentes no arquivo GeoBR, tornando seu conteúdo mais rico e promovendo a interoperabilidade em nível semântico.

A seguir é mostrado um exemplo de arquivo DAML definindo uma Ontologia usada em outro arquivo de acordo com o Esquema GeoBR para descrever entidades.

Uma ontologia exemplo.

Qualquer elemento presente em uma cidade.

Entidade Referente à Hidrologia </rdfs:comment>

A seguir um trecho de um arquivo no formato GeoBR usando uma entidade descrita pelo arquivo DAML mostrado anteriormente.

1. <data_model>

2. <feature type=" lote" rdfs:resource=" #Lote">

3. <attribute name=" uso" type=" string" />

4. <attribute name=" area" type=" string" /> 5. </feature>

6. <themathic name=" rio" rdfs:resource=" #Rio">

7. <label name=" perene" />

8. <label name=" temporário" />

9. </themathic>]

10. </data_model>

#Lote na linha 2 é uma referência a classe Lote definida no arquivo DAML, assim como #Rio é da classe Rio.

Para viabilizar o uso do dicionário de termos, o Software TerraTranslator (Lima, 2002) inclui um módulo de exportação onde é possível ler um arquivo DAML e escolher os nomes das entidades descritas para incluir em um arquivo GeoBR.

A construção do software está sendo feita em C++, com o uso da biblioteca de classes TerraLib (Câmara, Souza et al., 2000) e do ambiente de interface multiplataforma Qt (Troll_Tech, 2001). A Figura 1 mostra a interface do conversor.

A proposta de formato GEOBR apresenta um conjunto de inovações com relação aos formatos atualmente existentes.

Considerando a substancial complexidade do problema de interoperabilidade de dados geográficos, procuramos elaborar uma proposta que incluísse um mecanismo simples e genérico para promover a interoperabilidade semântica. Esperamos que venha a preencher a atual lacuna de propostas para intercâmbio da geoinformação no Brasil.