GEOBR: INTERCÂMBIO SINTÁTICO E SEMÂNTICO DE DADOS ESPACIAIS

Transcrição

1 INPE TDI/948 GEOBR: INTERCÂMBIO SINTÁTICO E SEMÂNTICO DE DADOS ESPACIAIS Paulo de Oliveira Lima Júnior Dissertação de Mestrado do Curso de Pós-Graduação em Computação Aplicada, orientada pelo Dr. Gilberto Câmara, aprovada em 24 de julho de INPE São José dos Campos 2004

2 LIMA JR, P. O. GEOBR: intercâmbio sintático e semântico de dados espaciais / P. O. Lima Júnior. São José dos Campos: INPE, p. (INPE TDI/948). 1.Sistemas de Informação Geográfica (SIG). 2.Interoperabilidade. 3.Ontologias. 4. Intercâmbio de dados. 5.Informação geográfica. I.Título.

3

4

5 Dedico às pessoas que foram exemplos importantes de honestidade, trabalho, humildade e amizade em minha vida: Minha Mãe, Meu Pai e Tio Edson. Aos que primeiro incentivaram, Arquiteto e primo Valério Tadeu de Assis e prof. José Maria Ribeiro Neves. À Renata e meu filho Pedro grande inspiração.

6

7 AGRADECIMENTOS Agradeço a minha esposa Renata, pelo apoio, incentivo, compreensão e companheirismo em momentos difíceis durante este trabalho. Agradeço a minha Mãe pelo incentivo e apoio durante o trabalho. Agradeço ao Gilberto Câmara pela oportunidade, confiança, apoio e exemplo. João Argemiro Paiva e Antônio Miguel Vieira Monteiro pelo apoio técnico e psicológico. Ricardo Cartaxo pelo apoio técnico, boa vontade, colaboração e códigos. Agradeço a Lúbia Vinhas e Equipe de desenvolvimento da TerraLib. Agradeço aos amigos Capitão Roberto Penido Duque Estrada, Raúl Patrício, pelo companheirismo em trabalhos e conversas produtivas, Gilberto Ribeiro de Queiroz e Karine Reis também companheiros de sala. Douglas, Felipe e Beto, pela boa convivência em São José dos Campos. Amigos da Serigy que me incentivaram. Aos amigos da Computação Aplicada (CAP) Ao Instituto Nacional de Pesquisas Espaciais (INPE) apoio. À Fundação de Ciência, Aplicações e Tecnologia Espaciais (FUNCATE) pelo À Divisão de Processamento de Imagens (DPI), pelo apoio, estrutura para a realização do trabalho e exemplo de profissionalismo.

8

9 RESUMO O intercâmbio de dados espaciais é uma questão importante no uso das geotecnologias, impulsionada principalmente pelo alto custo de produção deste tipo de dado e sua necessidade para produção de informações geográficas. É também um desafio, pois ressalta o problema da interoperabilidade entre os sistemas concebidos para armazenar, visualizar e manipular dados espaciais, denominados Sistemas de Informação Geográfica. Cada Sistema de Informação Geográfica (SIG) é desenvolvido independentemente e utiliza um modelo conceitual próprio sem a preocupação em seguir um modelo ou terminologia comum. O resultado é um ambiente heterogêneo onde cada organização tem sua maneira de tratar a informação espacial, vinculada ao SIG por elas adotado. Distorção de dados e perda de informação, são problemas que freqüentemente aparecem em uma troca de dados entre organizações que usam SIGs distintos. Este cenário é propício ao desenvolvimento de modelos e formatos de dados que são capazes de representar diferentes tipos de informação geográfica e promover a interoperabilidade entre SIGs distintos. Este trabalho descreve o desenvolvimento de um formato para intercâmbio sintático e semântico de dados espaciais, entre diferentes SIGs, e um software de código aberto para visualização e conversão de arquivos em formatos de diferentes SIGs do mercado e o formato proposto.

10

11 GEOBR: SINTACTIC AND SEMANTIC SPATIAL DATA INTERCHANGE ABSTRACT The exchange of spatial data is an important issue in the use of the geotecnologias, impelled mainly by the high cost of production of this dice type and its need for production of geographical information. It is also a challenge, because it stands out the problem of interoperability among the systems conceived to store, visualize and manipulate spatial data, denominated Geographic Information Systems (GIS). Each GIS software is developed independently and it uses an own conceptual model without the concern in following a common model or common terminology. The result is a heterogeneous environment where each organization has its way to treat the spatial information, linked to the GIS by them adopted. Data distortion and loss of information are problems that frequently appear in a change of data among organizations that use different GIS. This scenery is favorable to the development of models and formats of data that are capable to represent different types of geographical information and to promote the interoperability among different GIS softwares. This work describes the development of a format for syntactic and semantic exchange of spatial data, and an open source software for visualization and conversion of files in formats of different GIS softwares of the market and the proposed format.

12

13 SUMÁRIO Pág. CAPÍTULO 1: INTRODUÇÃO Objetivo Motivação Metodologia Contribuição Estrutura da dissertação...21 CAPÍTULO 2: O PROBLEMA DA INTEROPERABILIDADE EM GEOPROCESSAMENTO Dimensões do Problema da Interoperabilidade Nível Sintático Nível Semântico...26 CAPÍTULO 3: PROPOSTAS PARA INTEROPERABILIDADE Conversão Sintática Formatos de Exportação MIF (MapInfo Interchange File) ASCII SPRING E00 Arc/Info Export Format DXF AutoCad Shape files (.SHP) Avaliação SDTS OpenGIS Modelo Abstrato GML Avaliação OpenGIS / GML Uso de Metadados FGDC Ontologias Ferramentas...48 CAPÍTULO 4 : GEOBR - DESCRIÇÃO GERAL Uso de XML como padrão de transferência Porque XML? Estrutura Validação Dicionário de Ontologias Semantic Web...56

14 RDF (Resource Description Framework) DAML (DARPA Agent Markup Language) Conteúdo de um arquivo GeoBR Metadados Modelo Genérico para Dados Geográficos Projeções Descrição dos dados Geometria Atributos e Classes Procedimentos de Análise GeoBR x GML: uma comparação...70 CAPÍTULO 5: CONVERSOR TERRATRANSLATOR Descrição Geral Implementação do tradutor Projeto da Interface Menu Principal Barra de Ferramentas...83 CAPÍTULO 6: CONCLUSÃO E PERSPECTIVAS...85 REFERÊNCIAS BIBLIOGRÁFICAS...89 APÊNDICE A: GEOBR SCHEMA...95

15 LISTA DE FIGURAS Pág. 2.1: Geometria : Arquivos diferentes - E00 x MIF : Subtipos de feature : Relação entre Feature e Coverage : Subtipos de Coverage : Trecho de um Esquema de aplicação : Criação de uma tag : Exemplo de namespace : Fragmento de um arquivo de dados em XML : Esquema de SIG baseado em ontologias, (Fonseca et al., 2000) : Exemplo de dados em XML : Descrição de dados em XML : Polígonos representando a mesma entidade : Tela Principal : Menu Principal e suas opções : Dado proveniente de um arquivo do tipo Shape File Geometria e Tabela de Atributos...77

16 5.4: Dados provenientes de arquivos do tipo Shape Files (shp) e MapInfo Interchange Files (mif) : Conteúdo do arquivo GeoBr a ser importado : Camadas de informação contidas no arquivo GeoBR a ser importado : Criação de Metadados : Projeções : Manipulação de Atributos : Dicionário de Termos : Modelo de Dados : Árvore de Diretórios : Barra de Ferramentas...83

17 LISTA DE TABELAS Pág. 1.1: Formatos Comuns no mercado... 30

18

19 CAPÍTULO 1 INTRODUÇÃO Um dos desafios mais importantes no uso das geotecnologias é o intercâmbio de dados espaciais, impulsionado principalmente pelo alto custo de produção deste tipo de dado. A falta de modelos conceituais comuns acarreta problemas na troca de dados entre organizações utilizando Sistemas de Informação Geográfica (SIGs) distintos, que incluem distorção de dados, comprometimento de qualidade da informação, perda de definições de atributos e georreferenciamento. 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 SIGs. Atualmente, 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. No caso brasileiro, o problema do intercâmbio de dados espaciais é agravado pela falta de padrões nacionalmente estabelecidos para intercâmbio de dados geográficos e pela não disponibilidade de ferramentas de baixo custo e fácil utilização para conversão de dados. Em função das deficiências nacionais neste campo, os produtores de dados (públicos e privados) vêm adotando soluções ad-hoc para o intercâmbio de dados, muitas vezes sem a devida análise crítica da experiência internacional nesta área. Assim, o intercâmbio de dados espaciais ressalta o problema da interoperabilidade entre os SIGs, sendo esta uma área de pesquisa que cresce a cada dia. Diante deste cenário, pretendemos com esta dissertação de mestrado, contribuir para a área de interoperabilidade entre SIGs. Para a elaboração do trabalho contamos com a experiência do INPE no ensino, uso e desenvolvimento de ferramentas para Geoprocessamento. 17

20 1.1. Objetivo O presente trabalho tem como objetivo propor um modelo genérico para dados geográficos e um formato brasileiro de intercâmbio de dados geográficos baseados neste modelo, denominado GeoBR, e como complemento, sob a forma de código aberto ( open-source ), uma ferramenta para visualização e conversão entre formatos de dados geográficos comuns no mercado e o formato proposto. Para tanto, o trabalho aborda o problema da interoperabilidade entre SIGs em seus múltiplos aspectos. São apresentadas soluções existentes na comunidade para promover a interoperabilidade entre SIGs, que incluem desde formatos e padrões de intercâmbio até o desenvolvimento de SIGs baseados em Ontologias (Fonseca et al., 2000), formando um conjunto de conceitos teóricos para cumprir o propósito do trabalho e formular um produto de qualidade Motivação A motivação básica para este trabalho é a falta de formatos e padrões nacionalmente estabelecidos para intercâmbio de dados geográficos no Brasil. Câmara et al.(2000a) considera que este é um dos fatores que reconhecidamente impede uma maior difusão de tecnologia de Geoprocessamento. Outro aspecto negativo é a não disponibilidade de ferramentas, de baixo custo e fácil utilização, para conversão de dados espaciais Metodologia Uma abordagem prática ao problema da interoperabilidade em SIGs é o uso de formatos de intercâmbio para dados espaciais. Os SIGs oferecem formatos de exportação próprios e um processo de conversão tem seus prós e contras, principalmente em um ambiente com uma variedade de sistemas diferentes. Qual o formato adotar? O formato adotado captura o significado da informação bem como as relações entre as entidades descritas? Estas questões são importantes em se tratando do uso de formatos para intercâmbio de dados espaciais. 18

21 Do ponto de vista conceitual, uma das melhores alternativas para enfrentar o problema da interoperabilidade é dispor de modelos de dados espaciais de aplicabilidade geral (Bauzer Medeiros et al., 1997) (Davis et al., 2001). Estes modelos permitem traduzir os dados produzidos por um SIG específico para uma visão genérica da geoinformação e assim formam a base para a proposição de um formato geral para intercâmbio de dados espaciais. Câmara et al. (1996) comenta que em geral, padrões facilitam o compartilhamento, a integração e a transferência de dados, sendo padrões para linguagens de especificação, transferência de dados, geocodificação ou documentação de formatos. Padrões para SIG vêm sendo definidos em nível internacional, nacional, federal ou industrial, alguns legalmente estabelecidos outros aceitos por consenso por uma considerável parcela da comunidade. Fonseca et al. (2000) ressalta que problemas semânticos irão persistir e impedir a interoperabilidade e que seria interessante conviver com estas diferentes formas de conhecimento sobre a realidade e tentar criar mecanismos para implementar e combinar diferentes visões, ou seja, representar o conhecimento geográfico no computador buscando interoperabilidade pela equivalência semântica dos conceitos entre sistemas distintos. Neste sentido, são propostos trabalhos relacionados a Ontologias e seu uso para interoperabilidade e concepção de SIGs baseados em Ontologias. Diante do quadro exposto, a abordagem deste trabalho para o problema da interoperabilidade é a criação de um formato de intercâmbio de dados espaciais independente de sistema, baseado em um modelo genérico para dados espaciais, que possa preservar a qualidade da informação geográfica (topologia e atributos). Criação de um Dicionário de Ontologias como mecanismo para correspondência de termos no processo de transferência. O presente trabalho inclui também a criação de ferramentas computacionais de fácil utilização para suportar a conversão entre o formato proposto e alguns formatos existentes. Desta forma pretende-se promover a interoperabilidade nos níveis sintático e semântico. 19

22 Para cumprir o objetivo, o trabalho é dividido em três partes, a saber: Proposta de um formato de intercâmbio de dados espaciais - GeoBR: componentes e sintaxe; Proposta de um Dicionário de Termos; Desenvolvimento de um software tradutor de dados. Thomé (1998), ressalta que mecanismos de transferência de dados entre formatos distintos esbarram nas regras conceituais que devem ser obedecidas para a absorção destes dados geográficos pelos SIGs. Entretanto uma ferramenta para conversão, gratuita e de fácil utilização que suporte diferentes formatos, é relevante em um cenário onde temos alternativas com alto custo ou opções de conversão entre formatos isolados MIF (MapInfo, 2001) para SHP (ESRI, 1998), SHP para DXF (AutoDesk, 2002), sem interface gráfica e com poucos recursos para manipulação dos dados. Do ponto de vista prático, adotou-se a tecnologia XML extensible Markup Language (Bray et. al, 2000), como sintaxe para descrever os dados espaciais no formato proposto, tornando-os mais acessíveis e semanticamente ricos, fazendo com que o seu significado seja facilmente compartilhado no processo de transferência Contribuição O trabalho contribui, de forma teórica e prática, para uma parcela de usuários de SIGs que desejam integrar dados de diferentes fontes em seus sistemas, fornecendo: Um formato de intercâmbio de dados legível que permite fácil acesso a seu conteúdo e edição externa. Elaborado a partir de conceitos teóricos em interoperabilidade, e atual tecnologia para descrição e intercâmbio de dados; Uma ferramenta gratuita, alternativa ao que existe no mercado, para lidar com a conversão entre os formatos suportados e possibilidade de extensão com a inclusão de novos formatos no futuro. 20

23 1.5. Estrutura da dissertação Esta dissertação divide-se em 6 capítulos, sendo o primeiro uma introdução, que traz uma breve apresentação do problema, o objetivo do trabalho, a motivação, a metodologia usada para alcançar o objetivo e a contribuição do trabalho. No segundo capítulo é apresentado o problema da interoperabilidade em SIGs, e no terceiro, propostas existentes na comunidade para tratar o problema. Estes capítulos fornecem uma base teórica para elaboração e desenvolvimento prático da proposta do trabalho. O quarto capítulo apresenta a proposta do trabalho para abordar o problema da interoperabilidade em SIGs, a descrição e justificativa do formato GeoBR e do dicionário de ontologia. O quinto capítulo descreve a implementação de uma ferramenta para converter arquivos de dados espaciais comuns no mercado e o formato proposto. A conclusão é o assunto do sexto capítulo que também apresenta perspectivas de evolução do trabalho. 21

24 22

25 CAPÍTULO 2 O PROBLEMA DA INTEROPERABILIDADE EM GEOPROCESSAMENTO Neste documento, entendemos por interoperabilidade a capacidade de compartilhar e trocar informações e processos entre ambientes computacionais heterogêneos, autônomos e distribuídos (Yuan, 1998). Examinaremos o caso de Sistemas de Informação Geográfica (SIG), projetados para armazenamento e análise de objetos e fenômenos georreferenciados (Goodchild, 2001) Para representar estes objetos e fenômenos, os SIGs possuem estruturas próprias criadas para diferentes tipos de dados geográficos. As diferentes formas de representar a realidade geográfica, contribuem para uma diversidade de modelos conceituais 1 dos SIGs disponíveis no mercado. Esta diversidade faz com que muitas 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 organizar a informação espacial. A expansão da rede mundial de computadores e a crescente popularização de SIGs em novos domínios de aplicações, propiciam um ambiente para realização de intercâmbio de informação espacial, impulsionado principalmente pelo custo de produzir o dado independentemente. Entretanto, a falta de modelos conceituais comuns acarreta problemas na troca de dados entre organizações utilizando SIGs distintos. Estes problemas incluem distorção de dados, perdas de qualidade da informação e de definições de atributos e informação sobre georreferenciamento. A tarefa de compartilhamento de dados geográficos deve envolver processos para garantir que a informação não seja perdida ou corrompida na transferência. Dada a variedade de usuários e diversidade do uso do dado espacial e sistemas de computação, é conveniente dispor de um formato de intercâmbio comum como uma forma de compartilhar dados entre diferentes sistemas de computação. 23

26 2.1 Dimensões do Problema da Interoperabilidade Em SIGs, alcançar a interoperabilidade não é uma tarefa simples, devido a complexidade da informação geográfica envolvida, ocorrendo incompatibilidades em vários níveis. Esta missão é um processo em desenvolvimento na comunidade, onde cada vez mais, trabalhos relacionados à interoperabilidade são abordados, buscando soluções desde padrões para intercâmbio de dados (OGC, 2002), (USGS, 1998) até o desenvolvimento de SIGs baseados em Ontologias (Fonseca et al., 2000). Por estes diferentes trabalhos, pode ser visto que o problema da interoperabilidade vem sendo abordado em diferentes níveis, como a conversão entre formatos de dados próprios de cada SIG (ESRI, 1998), (INPE, 2000), (MapInfo, 2001), a conversão entre semânticas de bancos de dados distintos (Thomé, 1998) e o desenvolvimento ou uso de modelos gerais de dados geográficos (Bauzer Medeiros et al., 1997), (Câmara et al., 2000a), (Davis et al., 2001) propostos por diferentes organizações. No que segue, consideramos a interoperabilidade em dois níveis: sintático e semântico. E apresentamos iniciativas já realizadas ou em desenvolvimento para alcançar a interoperabilidade entre SIGs nestes níveis, bem como uma análise crítica de cada uma. Teremos assim uma base teórica, fundamentada na experiência internacional, na qual é elaborado o produto desta dissertação Nível Sintático O armazenamento dos dados geográficos em um SIG é organizado em estruturas próprias que descrevem características dos dados, por exemplo, coordenadas dos pontos que formam um polígono representando geometricamente uma dada entidade geográfica. As entidades geográficas possuem uma representação geométrica ou geometria e atributos associados. A geometria é baseada nas primitivas: ponto, linha, polígonos, polígonos com 1 Segundo Thomé (1998) entende-se por modelos conceituais a semântica do funcionamento de cada SIG, e a maneira como os dados devem estar organizados. 24

27 buracos e ilha (Burrough, 1998) que podem ser derivadas para formar estruturas mais complexas. A Figura 2.1 mostra primitivas e formas de algumas possíveis entidades. FIGURA 2.1 Geometria. Normalmente a organização dos dados nos SIGs é distribuída em camadas ( layers ou planos de informação ) (ESRI, 2001a), (ESRI, 2001b), (INPE, 2001), (MapInfo, 2002), onde cada camada contém uma variável geográfica distinta, por exemplo uma imagem de satélite de uma região, os municípios desta região, a sua geomorfologia, ou hidrologia. Cada camada é representada internamente em estruturas lógicas próprias de cada SIG e em arquivos distintos de acordo com o formato próprio do sistema utilizado. Este esquema de codificação e arquivos ou o formato de exportação possui uma sintaxe própria de cada sistema para descrever as entidades (geometria e atributos), ou seja, a forma de escrever o dado. Consideramos este esquema próprio de cada sistema para armazenar e documentar seus dados, o nível sintático. Tradicionalmente, muito do trabalho realizado em intercâmbio de dados geográficos trata de transformações estruturais (Gardels, 1996). A abordagem mais básica é a conversão sintática direta de formatos, que procura realizar a interpretação e tradução dos arquivos de informação geográfica em diferentes formatos, permitindo que um sistema compreenda os dados provenientes de outros sistemas. Isto é eficiente desde que o desenvolvedor da conversão tenha conhecimento dos formatos envolvidos para não comprometer a qualidade dos dados no processo de conversão. Cada sistema tem sua própria definição e nomenclatura para as diferentes formas de geometria. A Figura 2.2 mostra dois trechos de arquivos em diferentes formatos de exportação. O lado direito é um fragmento de um arquivo com extensão.e00 (Morissette, 2001) proveniente do software Arc/Info (ESRI, 2001b) o da esquerda é um fragmento de um arquivo de extensão.mif (MapInfo, 2001) 25

28 proveniente do software MapInfo (MapInfo, 2002). Ambos descrevem uma mesma entidade (mesma geometria, mesmas coordenadas) mas com uma sintaxe própria. FIGURA Arquivos diferentes - E00 x MIF. Entendendo a estrutura específica de um formato, é possível escrever um código que trata as características de cada sistema envolvido, viabilizando a conversão ou importação direta, atingindo desta forma um grau de interoperabilidade no nível sintático Nível Semântico O nível semântico diz respeito à representação conceitual da informação geográfica presente em cada sistema, ou o significado do dado geográfico para um dado sistema. Barreiras semânticas aparecem em 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) A literatura sobre SIG usualmente considera duas classes de modelos de informação geográfica: campos e objetos (Couclelis, 1992), representando respectivamente uma distribuição contínua de um fenômeno sobre o espaço geográfico e uma superfície ocupada 26

29 por entidades discretas e identificáveis com representação geométrica e atributos descritivos. Os modelos adotados nos SIGs implementam diferentemente estes conceitos. Por exemplo, uma informação, representada no sistema MGE (Intergraph, 2001b) por uma classe denominada CLASSE DE FEIÇÕES, pode ser mapeada para duas classes: TEMATICO e OBJETOS no SPRING. Esta duplicidade de mapeamento acontece porque no MGE não existe distinção para representar fenômenos geográficos distribuídos espacialmente, e fenômenos geográficos discretos. Neste caso, a classe: CLASSE DE FEIÇÃO é utilizada para representar estes dois tipos de fenômenos (Thomé, 1998). Outra questão relevante neste nível é o significado que as entidades modeladas podem ter para diferentes usuários. O que remete a um problema com a nomenclatura utilizada por diferentes domínios de usuários. Entidades iguais podem ser denominadas por nomes diferentes ao passo que um mesmo nome pode ser utilizado para descrever entidades distintas, em domínios diferentes. A realização plena da interoperabilidade requer o compartilhamento de significado. Assim, quando o dado for aceito pelo novo sistema, o usuário deve compreender seu significado. 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. Câmara et al. (1999) diz que interoperabilidade em SIG requer um nível de modelagem semântica para explicar a correspondência dos conceitos entre diferentes sistemas. Ferramentas vêm sendo produzidas, como GeoTMS (Thomé, 1998) e FME (Safe, 2002) para apoiar a modelagem de projetos subsidiando a conversão conceitual entre sistemas diferentes. Pesquisas relacionadas ao uso de Ontologias (Fonseca et al., 2000) surgem no sentido de promover a interoperabilidade entre SIGs também neste nível. 27

30 28

31 CAPÍTULO 3 PROPOSTAS PARA INTEROPERABILIDADE A questão da interoperabilidade entre SIGs vem sendo tratada pela comunidade de geoprocessamento por iniciativas que buscam soluções nos diferentes níveis: sintático e semântico. Alguns dos trabalhos mais relevantes são comentados a seguir, como o padrão americano para transferência de dados SDTS (Spatial Data Transfer Standard) (USGS, 1998), o consórcio OpenGIS (OGC, 1996) e padrões de metadados como proposto pelo FGDC (Federal Geographic Data Committee) (FGDC, 2001). Estas propostas constituem um conjunto de conceitos que servem de base para formular um produto de melhor qualidade, cumprindo o propósito desta dissertação. No Brasil, devemos citar esforços para compartilhamento de dados por propostas de organizações como (BCDAM, 2001), (CPRM, 2001), e (GeoMinas, 2001), que disponibiliza na Internet dados georreferenciados sobre Minas Gerais Conversão Sintática Formatos de Exportação 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. Formato, neste caso, é a estrutura lógica usada para armazenar dados de um SIG em arquivos. Para permitir este tipo de conversão, os SIGs trabalham com duas alternativas: Oferecer um formato de exportação ASCII de fácil legibilidade, como o DXF (AutoDesk, 2002) do software Autocad (AutoDesk, 2000), MID/MIF (MapInfo, 2001) do software MapInfo (MapInfo, 2002), E00 (Morissette, 2001) do software ArcInfo (ESRI, 2001b) e SPR (INPE, 2000) do software SPRING (INPE, 2001); Documentar as estruturas de dados internas, como no caso do formato Shapefile SHP (ESRI, 1998) usado pelo software ArcView 8.x (ESRI, 2001). 29

32 Os formatos de intercâmbio podem ser formatos documentados nos quais um determinado sistema organiza seus dados (formato de exportação), facilitando a leitura por outro sistema e possibilitando uma conversão sintática. Ou podem ser independentes de sistema, criados com a finalidade de ser usado apenas para transferência. O processo de transferência de dados geográficos envolve duas fases. A fase de exportação que consiste em selecionar uma camada do SIG e converte-lo para um formato de transferência e na fase de importação, converter os dados e inseri-los no sistema de destino. Caso o sistema de destino tenha suporte para o formato recebido, uma conversão não é necessária, pois ocorre a importação direta. Existem vários formatos de codificação da informação geográfica, criados por distintos desenvolvedores de SIGs. Exemplos: TABELA Formatos comuns no mercado. Sistema Formato de exportação Formato interno Arc/Info E00 Não documentado Arc/View SHP O mesmo AutoCad DXF DWG Map/Info MIF Não documentado Spring SPR/ASCII Não documentado Nem sempre o formato de exportação coincide com o formato interno que por sua vez nem sempre está documentado. Em alguns sistemas, o formato de exportação está descrito por um arquivo ASCII representando um dado geográfico, contendo as informações necessárias para sua decodificação. Os formatos incluem informações geográficas: posição e formas das entidades, informações sobre atributos: dados não espaciais e em alguns casos informações de apresentação. Geralmente, um arquivo descreve a geometria (pontos, linhas e áreas) das entidades 30

33 geográficas e outro descreve seus atributos. Cada sistema possui uma definição para a geometria das entidades representadas. Podemos dividir os formatos em dois tipos: vetoriais e matriciais (raster). A seguir, apresentaremos as características de formatos vetoriais de exportação de alguns sistemas mais comuns no mercado, destacando os aspectos relevantes como representação topológica (polígonos fechados ou arco-nó-polígono), tratamento de dados 3D e toponímia MIF/MID (MapInfo Interchange File) O software MapInfo (MapInfo, 2002) utiliza um formato para intercâmbio de dados denominado MapInfo Interchange File MIF (MapInfo, 2001). Consiste de dois arquivos: um para dados gráficos, pois armazena a geometria (coordenadas) e parâmetros de apresentação como cor e estilo de linhas, e outro para dados tabulares. O arquivo com os dados gráficos tem a extensão.mif e o de dados tabulares tem a extensão.mid. Além de representar as primitivas básicas de geometria (ponto, linha e polígono), o formato inclui seções que descrevem elipses e retângulos. Entidades representadas por um ou mais polígonos são denominadas regiões, representadas no arquivo de exportação pelo elemento REGION seguido de informações sobre o número de polígonos da região, as respectivas coordenadas x e y e estilo para apresentação. Não há informação explícita sobre hierarquia de polígonos para o caso de polígonos aninhados ou com buracos. O formato não inclui formas de descrever dados em 3D (coordenadas x, y e z). A questão da toponímia é descrita pelo elemento TEXT, que descreve o texto sua posição (x,y) e estilo como fonte, tamanho e cor ASCII SPRING O software SPRING (INPE, 2001) oferece um formato de exportação baseado em arquivos ASCII (INPE, 2000). Cada arquivo armazena um tipo de entidade. As informações são guardadas de forma seqüencial e palavras chaves identificam diversos tipos de dados e componentes do formato. O formato inclui além de pontos, linhas e polígonos, suporte para dados em 3D, ou amostras 3D (SAMPLES), como isolinhas (LINE3D) e pontos cotados (POINT3D). 31

34 E00 Arc/Info Export Format Outro formato de exportação baseado em arquivos ASCII é o E00, criado pelo software Arc/Info (ESRI, 2001b). Para a descrição dos dados espaciais, este formato possui as primitivas básicas de arco, nó e polígono e descreve explicitamente a topologia, incluindo informações como polígono à direita e a esquerda de um determinado arco. Também fornece uma seção para toponímia DXF AutoCad O formato DXF (AutoDesk, 2002) é o formato de exportação usado pelo software AutoCad (AutoDesk, 2000). Este se destaca no mercado como uma ferramenta CAD (Computer Aided Design). O DXF é codificado em ASCII e descreve as camadas de informação editadas no AutoCad como arquivos de desenho. O AutoCad é tradicionalmente uma ferramenta de desenho, assim inclui vários tipos de geometria, toponímia e dados 3D. O software é uma ferramenta difundida no mercado e a maioria dos SIGs possui suporte para importar diretamente o formato DXF. Os formatos descritos até aqui são arquivos ASCII, o que facilita a escrita de algoritmos para ler e escrever estes formatos Shape files (.SHP) Outro formato comum para dados espaciais é o Shapefile, utilizado pelos produtos ESRI ( como o ArcView (ESRI, 2001b). Os dados são organizados em arquivos binários com extensão.shp com a geometria, arquivos com extensão.shx com índices e extensão.dbf com atributos. Programas podem ser criados para ler ou escrever arquivos.shp (shapefile) usando sua especificação técnica, (ESRI, 1998) e bibliotecas como a Shapelib, que fornece suporte para lidar com arquivos no formato em nível de programação. O formato inclui ponto, linha e polígono e tipos para o caso de entidades representadas por mais de um polígono ou polígonos com vários anéis. Não inclui topologia. 32

35 3.1.6 Avaliação Dois sistemas merecem menção especial, o ambiente MicroStation (Bentley, 2002), utilizado pelos produtos MGE (Intergraph, 2001b) e MicroStation Geographics - Bentley, um sistema CAD, que utiliza um arquivo de desenho (DGN), que não contém explicitamente a topologia e os atributos dos dados. O produto GeoMedia (Intergraph, 2001a), não possui formatos documentados de exportação ou importação, mas é capaz de ler/escrever dados em formatos SHP, E00, DXF e MIF. Estes formatos intermediários 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, como é o caso das traduções usando-se o formato DXF (Fonseca et al., 1999). Existem formatos alternativos, independentes de sistema, que procuram evitar a perda de informação, como o SDTS (Spatial Data Transfer Standard), descrito a seguir SDTS O SDTS (Spatial Data Transfer Standard) (USGS, 2001) é um padrão de formato para dados de SIG, e tem como propósito, promover e facilitar a transferência de dados espaciais entre sistemas computacionais distintos, preservando o significado da informação e minimizando a necessidade de informação externa para transferência. É um formato de transferência, não um formato de processamento, ele não substitui qualquer formato interno de qualquer SIG. Ele especifica construtores de troca, formatos de endereçamento, estrutura e conteúdo para dados georreferenciados vetoriais e matriciais. O SDTS foi aprovado em 1992 como Padrão Federal de Processamento de Informação (FIPS - Federal Information Processing Standard), programa federal de padronização do uso de computação, administrado pelo Instituto Nacional de Padrões e Tecnologia (NIST - National Institute of Standards and Technology), a versão atual foi adotada pelo Instituto Nacional Americano de Padrões (ANSI - American National Standards Institute). O padrão está descrito em três partes, a Parte 1 apresenta especificações lógicas requeridas para transferência de dados espaciais e possui três componentes principais: um modelo 33

36 conceitual de dados espaciais que descreve entidades do mundo real (cidades, fazendas e seus atributos), objetos espaciais (pontos, linhas, polígonos) e o relacionamento entre eles, a descrição de componentes para qualidade de dados e a descrição de construtores lógicos para formatos de transferência. A parte 2 contém uma espécie de glossário de termos com a definição de entidades, atributos, sinônimos e outros. A Parte 3 especifica como implementar a Parte 1 usando o padrão ISO/ANSI 8211 de troca de dados. Para a conversão entre sistemas de dados espaciais específicos e o SDTS, uma visão da informação espacial é traduzida nos conceitos e termos da Parte 2 e então representada como objetos espaciais, segundo definido na Parte 1. Os objetos espaciais, juntamente com atributos e metadados, são transferidos usando estruturas lógicas definidas também na Parte 1. Estas estruturas são fisicamente formatadas em arquivos, segundo especificado na Parte 3. Maiores informações são encontradas em ( onde encontra-se gratuitamente uma biblioteca de classes (SDTS++), escrita em C++, para manipular dados no formato, e softwares para visualização e conversão. 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 OpenGIS Esta abordagem segue o conceito de API (Application Programming Interface), um conjunto de funções usadas para comunicar com uma determinada aplicação, o que dá aos desenvolvedores, uma forma unificada de acessar as funcionalidades de sistemas distintos. O uso de API para obter interoperabilidade em SIGs inclui a definição de um modelo de 34

37 dados genérico, e de uma interface padronizada de acesso a bancos de dados geográficos. Organizações que desenvolvem seus SIGs segundo um protocolo de acesso à informação espacial, podem ter acesso a dados geográficos independente do formato de armazenamento, com base em mecanismos de consulta previamente estabelecidos. O Consórcio OpenGIS é uma organização entre instituições envolvidas com SIGs com a missão de distribuir, abertamente, especificações de interface espacial para uso global (OGC, 1996), e 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). Para realizar seus propósitos, um Comitê Técnico, organizado em linhas de tarefas, produz e revisa as especificações (OGC 1996), procurando abordar interfaces que serão úteis em todos os domínios de aplicação, tornando os sistemas de geoprocessamento abertos. Como descrito por Câmara et al. (1996), o projeto considera todos os dados, processos e servidores como objetos, baseados em uma tecnologia de objetos distribuídos que tratam da interoperabilidade, comunicação e gerência de objetos e serviços distribuídos. Também se baseia em serviços a serem implementados fornecendo ligações entre o modelo de objetos e formatos de dados privados, definindo uma interface padrão para cada elemento do modelo (dados, funções e processos). Aplicações em conformidade com o OGIS podem usar dados de diversos sistemas de armazenamento com diferentes formatos, através de gerenciamento de acesso. A intenção é encorajar os desenvolvedores de software e integradores a aderirem a estes padrões e assim criar, através do tempo, ferramentas, bancos de dados e sistemas de comunicação que maximizem a utilidade de sistemas e recursos e usufruam os avanços tecnológicos (Fonseca et al., 1999). No entanto, a questão do mapeamento de sistemas existentes para o padrão OpenGIS em alguns casos, leva a um desentendimento envolvendo uma série de ajustes semânticos. Câmara et al.(1999), apresenta uma análise do modelo conceitual de três SIGs ( Intergraph 35

38 MGE, ESRI - Arc/Info e INPE - SPRING ) e descreve o mapeamento destes para o padrão OpenGIS. As principais conclusões são: Alguns sistemas têm modelos semânticos mais ricos em conteúdo que o OpenGIS, (como a definição de objeto no MGE e a definição de campo no SPRING), e seu mapeamento para o OpenGIS pode representar sensível perda de informação semântica (Câmara, Thomé et al., 1999). O uso da terminologia adotada pelos principais fabricantes de SIG do mercado, em vez de simplificar processo de migração, pode ser uma fonte de desentendimento, por exemplo, o mapeamento de COVERAGES no Arc/Info para FEATURE WITH GEOMETRY no OpenGIS. Assim, em algumas circunstâncias, onde a migração automática para o OpenGIS não é recomendada, é necessário um nível de modelagem semântica antes que o mapeamento aconteça (Câmara et al., 1999) Modelo Abstrato O modelo conceitual do OpenGIS é baseado em uma classe abstrata denominada feature, Figura 3.1. Uma feature é considerada pelo OpenGIS uma abstração de um fenômeno do mundo real; é uma feição geográfica se é associada com uma localidade relativa à Terra. FIGURA Subtipos de feature. FONTE: Adaptada de OGC (1996). 36

39 A classe abstrata FEATURE tem duas especializações FEATURE WITH GEOMETRY (que almeja capturar o conceito de geo-objetos) e COVERAGES (que pretende capturar o conceito de geo-campos), Figura 3.2. FIGURA Relação entre Feature e Coverage. FONTE: Adaptada de OGC (1996). O padrão OpenGIS relaciona diretamente cada tipo de coverage com uma geometria particular, como mostra a Figura 3.3, num relacionamento de especialização. Isto faz com que o conteúdo semântico de uma coverage (os tipos de dados geográficos representados) sejam confundidos com seu conteúdo sintático (a estrutura de dados utilizada). Esta relação é incoerente com a definição proposta pelo padrão OpenGIS para coverages, que fala em função, domínio e intervalo. FIGURA Subtipos de Coverage. FONTE: Adaptada de OGC (1996). 37

40 Deste modo, o modelo conceitual do OpenGIS não captura a noção que um mesmo geocampo pode ser representado simultaneamente nos formatos vetorial e matricial GML Seguindo a tendência do uso de padrões para intercâmbio de dados, o OpenGIS usa o padrão XML (extensible Markup Language) para definir uma forma de codificar dados geográficos. Para isso especificou a linguagem GML (Geography Markup Language) (OGC, 2002). GML (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) (Fallside, 2001). O Esquema XML define os elementos (tags) usados em um documento que descreve os dados. Atualmente a linguagem está em sua versão 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. Segundo (OGC, 2002) são elas: 38

41 Um Esquema de aplicação de usuário deve seguir as regras de desenvolvimento de Esquemas definidas na especificação da GML (OGC, 2002); Uma delas é que desenvolvedores de Esquemas de aplicação devem assegurar que seus tipos são subtipos dos correspondentes tipos da GML: gml:abstractfeaturetype ou gml:abstractfeaturecollectiontype para feições e gml:abstractgeometrytype ou gml:geometrycollectiontype para a geometria. Um Esquema de aplicação não pode mudar o nome, definição ou tipo de dado dos elementos obrigatórios da GML; Definições de tipos abstratos podem ser livremente estendidas ou restritas; O Esquema de aplicação deve estar disponível a qualquer um que receba o dado estruturado por aquele Esquema; Os Esquemas relevantes devem especificar um namespace que não deve ser Desta forma um desenvolvedor de Esquemas pode criar seus próprios tipos e tags e uma aplicação GML poderá fazer uso dos dados. Por exemplo, consideramos dois arquivos, um para o Esquema (exemplo.xsd) e outro com os dados (exemplo.xml): FIGURA Trecho de um Esquema de aplicação. A Figura 3.4 é um fragmento do arquivo exemplo.xsd (Esquema de aplicação), mostrando a criação de um tipo, no caso hidrografia. Seguindo as regras, a linha 3 faz com que 39

42 hidrografia seja subtipo de gml:abstractfeaturetype. Este tipo pode ser usado na criação de uma tag, por exemplo: FIGURA Criação de uma tag. O fragmento mostrado na Figura 3.5 é parte do mesmo Esquema e define a criação de uma tag <rio> do tipo hidrografia que pode ser usada para descrever um determinado rio no arquivo exemplo.xml. Também é definido que o elemento tem o atributo substitutiongroup igual a gml:_feature, o que garante a uma aplicação a leitura dos dados. O ex em ex:hidrografia indica que o nome hidrografia é do domínio ex, declarado no início do arquivo: FIGURA Exemplo de namespace. No início do arquivo foi definido o namespace ex, como mostra a linha 4 do exemplo mostrado na Figura 3.6. Um fragmento do arquivo contendo os dados é ilustrado pela Figura 3.7: 40

43 FIGURA Fragmento de um arquivo de dados em XML. As tags <gml:description> (linha 2) e <gml:name> (linha 3) da Figura 3.7, não foram criadas no Esquema de aplicação, mas sim herdadas do tipo AbstractFeatureType, já que hidrografia é deste tipo e <rio> foi definido como hidrografia. Para a transferência de dados é necessária a transferência do arquivo com o Esquema também, só assim uma aplicação que procura por <_Feature> poderá saber que <rio> é <_Feature> Avaliação OpenGIS / GML Apesar dos inegáveis avanços, a proposta OpenGIS tem outras 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 e 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. 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. 41

44 A GML inclui modelos básicos para feições e geometrias. Para representar outros modelos como superfícies, a GML 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 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 Sistemas de Referência Espacial a seção Geometry Elements da especificação (OGC, 2002) diz que as coordenadas para uma geometria são definidas em algum Sistema de Referência Espacial (SRS) e toda geometria deve especificar este SRS. GML não trata dos detalhes da definição de SRS, assim fica a cargo do usuário criar sua própria forma de tratar o SRS, descaracterizando GML como padrão para intercâmbio. O Esquema GML GeometrySchema.xsd, permite que toda geometria tenha seu SRS associado, o que torna o dado redundante quando representa-se um conjunto de entidades em um mesmo SRS. Se a associação fosse permitida só a elementos de níveis superiores, como coleções de feições (<featurecollections>) esta redundância seria evitada. 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 42

45 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, deficiências 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. Atualmente, uma API em Java para acesso a dados em GML (GML4J) está sendo desenvolvida de forma aberta pela Internet (SourceForge, 2001). A sua versão atual é capaz de ler dados e Esquemas GML, desde que estes obedeçam às regras especificadas na seção 5 da especificação do padrão GML, mas não permite escrever. O software FME, suporta a leitura e escrita de dados GML mas não inclui a manipulação de Esquemas de Aplicação. 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. Assim, consideramos que os avanços no OpenGIS merecem revisão nas questões levantadas. Parte destas revisões, como os uso de ontologias para interoperabilidade semântica, uso de um modelo genérico para dados espaciais e definição semântica das geometrias, foram incorporadas à proposta GeoBR. 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 43