Banco de Dados Geograficos

______________________________________
Bancos de Dados Geogrficos

______________________________________
Editores
Marco Casanova (PUC-Rio), Gilberto Cmara (INPE), Clodoveu Davis (PUC Minas), Lbia Vinhas (INPE), Gilberto Ribeiro de Queiroz (INPE). Edio em papel: MundoGEO, Curitiba, 2005, disponvel na Livraria Virtual da MundoGEO Objetivo do Livro O livro Bancos de Dados Geogrficos uma obra de referncia que descreve o uso de tecnologias de informao para armazenar, processar, distribuir e compartilhar dados espaotemporais. O pblico-alvo so profissionais envolvidos em gerenciamento, modelagem e programao de aplicativos geogrficos. Os temas discutidos incluem: (a) representao computacional de objetos geogrficos; (b) modelos espao-temporais e modelagem de bancos de dados geogrficos; (c) arquiteturas e linguagens de consulta para bancos de dados geogrficos; (d) mtodos de acesso e processamento de consultas em bancos de dados geogrficos; (e) exemplos de sistemas: Oracle Spatial, PostgreSQL, TerraLib; (f) intercmbio de dados, integrao e interoperabilidade, e disseminao na Internet de dados geogrficos; (g) descrio da TerraLib, incluindo tratamento de dados matriciais e desenvolvimento de aplicativos. O livro usado como texto bsico no curso "Bancos de Dados Geogrficos", dos programas de ps-graduao em Computao Aplicada e Sensoriamento Remoto do INPE Ateno: A verso online do livro de distribuio gratuita. Os autores no autorizam a venda de nenhuma reproduo total ou parcial desse material.
Prefcio H quase duas dcadas, bancos de dados tornaram-se o componente central de sistemas de informao, tanto do ponto de vista de projeto, quanto do ponto de vista de operao. Esta evoluo foi possvel graas a uma slida tecnologia desenvolvida para armazenamento e manipulao de dados convencionais, notadamente os chamados sistemas de gerncia de bancos de dados objeto-relacionais (SGBD-OR). O projeto e operao de sistemas de informao geogrfica vem seguindo o mesmo rumo, adotando bancos de dados geogrficos (BDGs) como ponto central da arquitetura. A relativa demora na adoo de BDGs explica-se pela complexidade de representao e manipulao de dados geogrficos. Tal complexidade exigiu desenvolvimentos adicionais da tecnologia dos SGBD-OR at que o nvel de funcionalidade e o desempenho fossem satisfatrios para a plena adoo de BDGs. Mais recentemente, o foco do desenvolvimento de sistemas de informao caminhou na direo de federaes de sistemas fracamente acoplados. Os sistemas de informao geogrfica acompanharam de perto esta evoluo, oferecendo uma gama variada de servios de intercmbio e disseminao de dados geogrficos, novamente fruto da maturao de novas tecnologias. Este livro aborda bancos de dados geogrficos dentro desta ampla perspectiva, cobrindo desde aspectos de representao dos dados geogrficos at a sua disseminao na Internet. O livro est dividido em quatro partes, para facilitar a leitura. A Parte I - Fundamentos examina os problemas bsicos de representao computacional de dados geogrficos, resume os principais algoritmos geomtricos e representaes topolgicas e trata da modelagem de dados espao-temporais em geral. A Parte II - Persistncia e Acesso apresenta uma viso geral das principais tecnologias especificamente desenvolvidas para sistemas de gerncia de banco de dados geogrficos. Inclui ainda exemplos de sistemas existentes que oferecem extenses espaciais. A Parte III - Interoperabilidade cobre tecnologias relacionadas a integrao e interoperabilidade, e inclui o tema de disseminao de dados geogrficos na Internet. Apresenta tambm as propostas do Open Geospatial Consortium para interoperabilidade. Por fim, a Parte IV - TerraLib descreve os aspectos mais relevantes da biblioteca TerraLib, incluindo o tratamento de dados matriciais. Apresenta ainda o TerraLib Development Kit - Tdk, cujo objetivo principal facilitar o desenvolvimento de aplicativos geogrficos que utilizem a TerraLib. O contedo do livro foi balanceado para atender a diferentes comunidades: Gerentes de tecnologia de informao interessados em implantar bancos de dados geogrficos em suas instituies podem se beneficiar da leitura dos Captulos 1, 3, 5, 8, 10 e 11. Desenvolvedores de sistemas de informao geogrfica tm acesso a material sobre o funcionamento interno dos bancos de dados geogrficos (Captulos 2, 6 e 7) e tambm uma descrio da TerraLib (Captulos 12, 13 e 14). Alunos de ps-graduao podem encontrar uma introduo a temas no estado-da-arte nos Captulos 4, 9 e 10.
Este livro resultante da cooperao entre as equipes baseadas nos estados de So Paulo (INPE), Rio de Janeiro (PUCRio) e Minas Gerais (UFMG e PUC Minas). Uma parte substancial dos resultados aqui apresentados resultou de projetos de pesquisa e desenvolvimento, teses e dissertaes nessas instituies. Este livro serve como texto bsico do curso de ps-graduao em Bancos de Dados Geogrficos ministrado no INPE e nas disciplinas da Ps-Graduao em Informtica da PUC Minas. Este livro tambm se encontra on-line, com material adicional, no stio de livros do INPE. Agradecemos ao CNPq pelo apoio ao projeto TerraLib e o apoio parcial as pesquisas de Gilberto Cmara e Clodoveu Davis Jr; ao INPE pelo apoio na editorao deste livro; ao Dr. Antnio Miguel Vieira Monteiro, chefe da Diviso de Processamento de Imagens; ao TecGraf e seu coordenador Prof.Marcelo Gattass; PRODABEL e PUC Minas; e, finalmente, Terezinha Gomes dos Santos pelo apoio logstico. Esperamos que a comunidade de geoinformao brasileira possa beneficiar-se de nossa experincia, que tentamos
transmitir neste livro. So Jos dos Campos, Rio de Janeiro, Belo Horizonte, maio de 2005. Autores Alberto H. F. Laender doutor em Cincia da Computao pela University of East Anglia (UK) e professor titular da UFMG. Clodoveu Davis Jr. doutor em Cincia da Computao pela UFMG e professor da PUC Minas. Daniela Francisco Brauner doutoranda em Informtica na PUC-Rio. Gilberto Cmara doutor em Computao Aplicada pelo INPE e pesquisador da Diviso de Processamento de Imagens do INPE. Gilberto Ribeiro de Queiroz mestre em Computao Aplicada pelo INPE e engenheiro da Diviso de Processamento de Imagens do INPE. Karine Reis Ferreira mestre em Computao Aplicada pelo INPE e engenheira da Diviso de Processamento de Imagens do INPE. Karla A. V. Borges doutoranda em Cincia da Computao na UFMG e analista da PRODABEL. Ligiane Alves de Souza mestrando em Cincia da Computao na UFMG. Lbia Vinhas doutoranda em Computao Aplicada no INPE e engenheira da Diviso de Processamento de Imagens do INPE. Marcelo Tlio Monteiro de Carvalho pesquisador do Grupo de Tecnologia em Computao Grfica (TecGraf) da PUCRio. Marco Antonio Casanova doutor em Applied Mathematics pela Harvard University (EUA) e professor da PUC-Rio. Mrio de S Vera pesquisador do Grupo de Tecnologia em Computao Grfica (TecGraf) da PUC-Rio Olga Fradico de Oliveira doutoranda em Computao Aplicada no INPE. Paulo de Oliveira Lima Junior mestre em Computao Aplicada pelo INPE, professor e coordenador do curso de Bacharelado em Sistemas de Informao da UNIPAC (Conselheiro Lafaiete, MG) Ricardo Cartaxo Modesto de Souza engenheiro snior da Diviso de Processamento de Imagens do INPE. Taciana de Lemos Dias doutoranda em Computao Aplicada no INPE, professora da PUC Minas e analista da PRODABEL.
Parte I - Fundamentos
1. Representaes computacionais do espao geogrfico Este captulo examina os problemas bsicos de representao computacional de dados geogrficos, e esclarece questes da seguinte natureza: Como representar os dados geogrficos no computador? Como as estruturas de dados geomtricas e alfanumricas se relacionam com os dados do mundo real? Que alternativas de representao computacional existem para dados geogrficos? Autor: Gilberto Cmara. 2. Algoritmos geomtricos e representaes topolgicas Este captulo apresenta uma introduo s principais tcnicas e algoritmos utilizados na implementao das diversas funes de um sistema de gerncia de bancos de dados espaciais, em especial as operaes sobre pontos, linhas e polgonos. Autores: Clodoveu A. Davis Jr. e Gilberto Ribeiro de Queiroz. 3. Modelagem de dados geogrficos Este captulo apresenta recursos para a modelagem de dados geogrficos, apoiados principalmente no modelo OMT-G, incluindo uma descrio de classes de restries de integridade espaciais, e um algoritmo de mapeamento de esquemas OMT-G para esquemas fsicos, considerando o padro OpenGIS para representao de objetos. Inclui ainda um exemplo de modelagem. Autores: Karla A.V. Borges, Clodoveu A. Davis Jr. e Alberto H.F. Laender. 4. Modelos espao-temporais Este captulo apresenta diversos modelos espao-temporais, correspondentes a diversas iniciativas de modelar o comportamento de objetos em sua trajetria espao-temporal, visando sua representao em um sistema de informao. Autores: Taciana de Lemos Dias, Gilberto Cmara e Clodoveu A. Davis Jr.
Parte II Persistncia e Acesso

5. Arquiteturas e linguagens Este captulo inicialmente apresenta uma viso geral de sistemas de gerncia de banco de dados (SGBDs) e resume os principais conceitos da linguagem SQL. Em seguida, aborda a evoluo das arquiteturas de SIG. Por fim, apresenta os principais operadores espaciais e discute a definio de linguagens de consulta espacial. Autores: Karine Reis Ferreira, Marco Antonio Casanova, Gilberto Ribeiro de Queiroz e Olga Fradico de Oliveira. 6. Mtodos de acesso espacial Este captulo aborda alguns dos mtodos de acesso espacial mais tradicionais, denominados k-d trees, grid files, quad-trees e R-trees. Autores: Clodoveu A. Davis Jr. e Gilberto Ribeiro de Queiroz. 7. Processamento de consultas e gerncia de transaes Este captulo aborda dois aspectos da implementao de um sistema de gerncia de bancos de dados geogrficos: processamento de consultas espaciais e gerncia de transaes. O texto enfatiza as questes que necessitam solues distintas daquelas empregadas em sistemas convencionais.
Autor: Marco Antonio Casanova. 8. SGBD com extenses espaciais Este captulo apresenta duas extenses espaciais, o PostGIS, mantido pela comunidade de software aberto, e o Oracle Spatial, distribudo comercialmente. Autores: Gilberto Ribeiro de Queiroz e Karine Reis Ferreira.
PARTE III - Interoperabilidade
9. Integrao e interoperabilidade entre fontes de dados geogrficos Este captulo apresenta um breve resumo da arquitetura e das tecnologias relacionadas a integrao e interoperabilidade no contexto de dados geogrficos, seguido de exemplos de projetos que possuem integrao ou interoperabilidade como seu fator motivador. Por fim, o captulo trata da construo de mediadores capazes de distribuir consultas entre diversas fontes e combinar os resultados devolvidos em uma nica resposta para o usurio. Autores: Marco Antonio Casanova, Daniela Francisco Brauner, Gilberto Cmara e Paulo Oliveira Lima Jr. 10. Disseminao de dados geogrficos na Internet Este captulo explora diversas possibilidades de disseminao de dados geogrficos atravs da Internet: a disseminao direta, usando caractersticas grficas tpicas dos browsers; as bibliotecas digitais de informaes geogrficas; e infra-estruturas de dados espaciais. Autores: Clodoveu A. Davis Jr., Ligiane Alves de Souza e Karla A.V. Borges. 11. O Open Geospatial Consortium Este captulo descreve os diferentes aspectos da proposta de interoperabilidade do OGC, incluindo: modelo de dados, intercmbio e servios Web. Autores: Clodoveu A. Davis Jr., Karla A.V. Borges, Ligiane Alves de Souza, Marco Antonio Casanova e Paulo Oliveira Lima Jr.
PARTE IV TerraLib: uma biblioteca para aplicativos geogrficos

12. Descrio da TerraLib Este captulo descreve a biblioteca TerraLib em seus aspectos mais relevantes em termos de bancos de dados geogrficos, incluindo o modelo conceitual do banco de dados, o modelo de armazenamento de geometrias e dados descritivos, e os mecanismos de manipulao do banco em diferentes nveis de abstrao. Autoras: Lbia Vinhas e Karine Reis Ferreira. 13.Tratamento de dados matriciais na TerraLib Este captulo descreve a soluo adotada na biblioteca TerraLib para o tratamento de dados matriciais, incluindo a decodificao de diferentes formatos e o seu armazenamento e recuperao em bancos de dados objeto-relacionais. Autores: Lbia Vinhas e Ricardo Cartaxo Modesto de Souza.
14. Desenvolvimento de Aplicativos com a TerraLib Este captulo descreve o TerraLib Development Kit - Tdk, cujo objetivo principal facilitar o desenvolvimento de aplicativos geogrficos que utilizem a TerraLib, e apresenta alguns exemplos ilustrando o uso dos elementos de arquitetura Tdk na confeco de diferentes aplicativos. Autores: Marcelo Tlio Monteiro de Carvalho e Mrio de S Vera.
1 Representao computacional de dados geogrficos

Gilberto Cmara
1.1 Introduo Este captulo examina os problemas bsicos de representao computacional de dados geogrficos, e esclarece questes da seguinte natureza: Como representar os dados geogrficos no computador? Como as estruturas de dados geomtricas e alfanumricas se relacionam com os dados do mundo real? Que alternativas de representao computacional existem para dados geogrficos? Em seu livro Olhos de Madeira, Carlo Ginzburg nos traz um fascinante ensaio sobre a origem da palavra representao. A origem do termo remonta ao sculo XIII, chamando-se reprsentation aos manequins de cera exibidos junto ao cadver dos reis franceses e ingleses durante as cerimnias funerrias (Ginzburg, 2001). Enquanto o soberano era velado, a presena do manequim era um testemunho transcendncia do rei e a sua presena futura no mundo dos mortos. O manequim tinha a funo de lembrar aos presentes que o rei havia assumido uma outra forma e que uma nova vida se iniciava para o morto. Nesta nova forma, apesar de morto o rei continuaria presente para seus sditos (re + prsentation). Assim, desde a sua origem a palavra representao est associada a uma forma abstrata de descrio do mundo. O uso do manequim como representao do soberano morto apenas um exemplo do problema mais geral da construo de abstraes que descrevem o mundo. Para explicar como funcionam os bancos de dados geogrficos, este captulo descreve o processo de transformar aos conceitos abstratos de espao
geogrfico no referindo ao espao computacionalmente representado. Para exemplificar, consideremos alguns problemas: Uma cientista social deseja entender e quantificar o fenmeno da excluso social numa grande cidade brasileira, atravs de mapas de excluso/incluso social, gerados a partir de dados censitrios (Sposati, 1996). Uma ecloga pretende estudar os remanescentes florestais da Mata Atlntica, atravs de estudos de fragmentao obtidos a partir de interpretao de imagens de satlite (Pardini et al., 2005). Uma pedloga pretende determinar a distribuio de propriedades do solo numa rea de estudo, a partir de um conjunto de amostras de campo (Bnisch et al., 2004). O que h de comum nesses casos? A especialista lida com conceitos de sua disciplina (excluso social, fragmentos, distribuio de propriedades do solo) e precisa de representaes que traduzam estes conceitos para o computador. Aps esta traduo, ela poder compartilhar os dados de seu estudo, inclusive com pesquisadores de outras disciplinas. 1.2 Descrio geral de sistemas de informao geogrfica O termo sistemas de informao geogrfica (SIG) aplicado para sistemas que realizam o tratamento computacional de dados geogrficos. A principal diferena de um SIG para um sistema de informao convencional sua capacidade de armazenar tanto os atributos descritivos como as geometrias dos diferentes tipos de dados geogrficos. Assim, para cada lote num cadastro urbano, um SIG guarda, alm de informao descritiva como proprietrio e valor do IPTU, a informao geomtrica com as coordenadas dos limites do lote. A partir destes conceitos, possvel indicar as principais caractersticas de SIGs: Inserir e integrar, numa nica base de dados, informaes espaciais provenientes de meio fsico-bitico, de dados censitrios, de cadastros urbano e rural, e outras fontes de dados como imagens de satlite, e GPS.
Descrio geral de sistemas de informao geogrfica
Oferecer mecanismos para combinar as vrias informaes, atravs de algoritmos de manipulao e anlise, bem como para consultar, recuperar e visualizar o contedo da base de dados geogrficos. Os componentes de um SIG esto mostrados na Figura 1.1. No nvel mais prximo ao usurio, a interface homem-mquina define como o sistema operado e controlado. Esta interface pode ser tanto baseada na metfora da mesa de trabalho (Kuhn e Frank, 1991) (Richards e Egenhofer, 1995) (Cmara, 1999), como adaptada ao ambiente de navegao da Internet (Kraak e Brown, 2001), quanto baseada em linguagens de comando como Spatial SQL (Egenhofer, 1994) e LEGAL (Cmara, 1995). No nvel intermedirio, um SIG deve ter mecanismos de processamento de dados espaciais. A entrada de dados inclui os mecanismos de converso de dados (Hohl, 1998). Os algoritmos de consulta e anlise espacial incluem as operaes topolgicas (Egenhofer e Franzosa, 1991), lgebra de mapas (Tomlin, 1990), estatstica espacial (Druck et al., 2004), modelagem numrica de terreno (Li et al., 2004) e processamento de imagens (Mather, 2004). Os mecanismos de visualizao e plotagem devem oferecer suporte adequado para a apreenso cognitiva dos aspectos relevantes dos dados pesquisado (MacEachren, 2004) (Tufte, 1983) (Monmonier, 1993). No nvel mais interno do sistema, um sistema de gerncia de bancos de dados geogrficos oferece armazenamento e recuperao dos dados espaciais e seus atributos. Cada sistema, em funo de seus objetivos e necessidades, implementa estes componentes de forma distinta, mas todos os subsistemas citados devem estar presentes num SIG.
Interface
Entrada e Integr. Dados
Consulta e Anlise Espacial
Visualizao Plotagem
Gerncia Dados Espaciais
Banco de Dados Geogrfico
Figura 1.1 Arquitetura de sistemas de informao geogrfica.
Do ponto de vista da aplicao, o uso de sistemas de informao geogrfica (SIG) implica em escolher as representaes computacionais mais adequadas para capturar a semntica de seu domnio de aplicao. Do ponto de vista da tecnologia, desenvolver um SIG significa oferecer o conjunto mais amplo possvel de estruturas de dados e algoritmos capazes de representar a grande diversidade de concepes do espao. Como o presente livro est focado nos diferentes aspectos relacionados com a tecnologia de bancos de dados geogrficos, discutiremos em maior detalhe a questo de gerncia de dados espaciais. Leitores interessados nos demais aspectos de um SIG podero consultar as referncias acima. 1.3 Traduzindo a informao geogrfica para o computador Para abordar o problema fundamental da Geoinformao, que a produo de representaes computacionais do espao geogrfico, usamos o paradigma dos quatro universos, proposto inicialmente por Gomes e Velho (1995) e adaptado para a geoinformao por Cmara (1995). Este paradigma distingue quatro passos entre o mundo real e sua realizao computacional (ver Figura 1.2).
Traduzindo a informao geogrfica para o computador
Figura 1.2 Paradigma dos quatro universos.
No primeiro passo, nossas percepes do mundo real so materializadas em conceitos que descrevem a realidade e respondem a questes como: Que classes de entidades so necessrias para descrever o problema que estamos estudando? (Smith, 2003). Criamos assim o universo ontolgico, onde inclumos os conceitos da realidade a serem representados no computador, como os tipos de solo, elementos de cadastro urbano, e caracterizao das formas do terreno. O segundo universo (o universo formal) inclui modelos lgicos ou construes matemticas que generalizam os conceitos do universo ontolgico e do resposta pergunta: Quais so as abstraes formais necessrias para representar os conceitos de nosso universo ontolgico? Estas abstraes incluem modelos de dados e lgebras computacionais. Exemplos: o modelo entidade-relacionamento (Chen, 1976) e o modelo OMT (Rumbaugh et al., 1991). O caso especfico de modelos dados geogrficos tratado em maior detalhe nos captulos 3 e 4 deste livro e inclui o modelo OMT-G (Davis et al., 2002). A questo de linguagens tratada no Captulo 5. O terceiro universo o universo estrutural, onde as diversas entidades dos modelos formais so mapeadas para estruturas de dados geomtricas e alfanumricas, e algoritmos que realizam operaes. Neste universo, respondemos a questes como: Quais so os tipos de dados e algoritmos necessrios para representar os modelos e as lgebras do universo formal? As estruturas de dados so os elementos bsicos de construo dos sistemas computacionais, e sero discutidas em maior detalhe neste captulo. Aspectos do universo estrutural descritos no livro incluem arquiteturas de SGBD (Captulo 8), converso de dados (Captulo 9), interoperabilidade (Captulo 10) e disseminao de dados na Internet (Captulo 11).
O universo de implementao completa o processo de representao computacional. Neste universo, realizamos a implementao dos sistemas, fazendo escolhas como arquiteturas, linguagens e paradigmas de programao. Neste livro, as questes de implementao discutidas incluem geometria computacional (Captulo 2), mtodos de acesso (Captulo 6), processamento de consultas (Captulo 7), alm da descrio detalhada da biblioteca TerraLib (Captulos 12 a 14). O paradigma dos quatro universos uma forma de compreendermos que a transposio da realidade para o computador requer uma srie complexa de mediaes. Primeiro, precisamos dar nomes s entidades da realidade. Depois, geramos modelos formais que as descrevem de forma precisa. A seguir, escolhemos as estruturas de dados e algoritmos que melhor se adaptam a estes modelos formais. Finalmente, fazemos a implementao num suporte computacional apropriado. Nas prximas sees, examinaremos em detalhe cada um destes universos. 1.4 O universo ontolgico Ontologia o campo da filosofia cujo objetivo descrever os tipos e estruturas de entidades, eventos, processos e relaes que existem no mundo real (Smith, 2003). Sua gnese remonta a Aristteles, mas o interesse recente por ontologias em sistemas de informao decorre principalmente da necessidade de compartilhar informao de forma eficiente para um pblico cada vez mais interdisciplinar. Um sistema de informao pode ser concebido como um mecanismo de comunicao entre duas partes: o produtor e o usurio. Para que funcione, necessrio que haja uma concordncia entre os conceitos das partes. Numa perspectiva mais geral, seu sucesso depende da existncia de uma comunidade que compartilhe as definies utilizadas para constru-lo. Por exemplo, considere o caso de um estudo sobre segregao em reas urbanas. Existem diferentes conceitos de segregao na literatura sociolgica (Caldeira, 2000) (Massey e Denton, 1993) (Torres, 2004) (White, 1983). Para construir um sistema de informao que permita o estudo da segregao urbana, preciso que o produtor de informao defina qual dos diferentes conceitos estar sendo
O universo ontolgico
representado, como esta representao ser construda, e como o usurio pode compreender as caractersticas e limitaes desta representao. Deste modo, o problema fundamental de um sistema de informao definir o conjunto de conceitos a ser representado. Se quisermos que estes conceitos sejam compartilhados por uma comunidade interdisciplinar, fundamental que os conceitos utilizados sejam devidamente explicitados. Assim, surge a pergunta: Qual o papel dos conceitos na representao do mundo? A melhor forma de responder baseando-se na perspectiva realista (Searle, 1998): 1. A realidade existe independentemente das representaes humanas. 2. Ns temos acesso ao mundo atravs de nossos sentidos e de nossos instrumentos de medida. 3. As palavras em nossa linguagem podem ser usadas para referir-se a objetos do mundo real. 4. Nossas afirmaes so verdadeiras ou falsas dependendo de sua correspondncia aos fatos do mundo. 5. Algumas afirmaes em nossa linguagem dizem respeito a uma realidade externa e independente (h neve no topo do Monte Evereste). Outras afirmaes dizem respeito a convenes socialmente construdas (este papel uma certido de nascimento). Como nos ensina Searle (1993), esta perspectiva tem conseqncias importantes sobre nossa concepo do mundo: Apesar de termos representaes mentais e lingsticas do mundo sob a forma de crenas, experincias, afirmaes, teorias, etc., h um mundo, l fora, totalmente independente destas representaes. A rbita elptica dos planetas relativamente ao Sol e a estrutura do tomo de hidrognio so inteiramente independentes das representaes que os seres humanos tm de tais fenmenos. J coisas como o dinheiro, a propriedade, o casamento e os governos so criados e sustentados pelo comportamento cooperativo humano. Na sua maior parte, o mundo existe independentemente da linguagem (princpio 1) e uma das funes da linguagem representar como so as coisas no mundo (princpio 3). Um aspecto crucial no qual a realidade e a linguagem entram em contato marcado pela noo de verdade. Em
geral, as afirmaes so verdadeiras na medida em que representam com preciso uma caracterstica da realidade que existe independentemente da afirmao (princpio 4).. O projeto de um sistema de informao requer, como passo inicial, a escolha das entidades a ser representados e, se possvel, a descrio organizada destas entidades por meio de conceitos. Esta descrio forma uma ontologia de aplicao, definida como um conjunto de conceitos compartilhados por uma comunidade (Gruber, 1995). Para os dados geogrficos, uma geo-ontologia tem dois tipos bsicos de conceitos: (a) conceitos que correspondem a fenmenos fsicos do mundo real; (b) conceitos que criamos para representar entidades sociais e institucionais (Smith e Mark, 1998) (Fonseca et al., 2003). Chamamos o primeiro tipo de conceitos fsicos e o segundo de conceitos sociais (Tabela 1.1). Embora todos os conceitos resultem do uso compartilhado da linguagem, h uma diferena entre conceitos que se referem ao mundo fsico (A Amaznia possui uma floresta tropical) e aqueles que resultam de convenes humanas (Esta uma reserva indgena). Nossa geo-ontologia diferencia entre conceitos associados a entidades que pode ser individualizadas e identificadas nominalmente (caso de lagos e lotes) e aquelas que variam de forma contnua no espao (caso de poluio).
Tabela 1.1 Tipos de conceitos associados a entidades geogrficas Realidade fsica Entidades individualizveis Entidades com variao contnua indivduos bona fide (e.g., montanha) topografias fsicas (e.g., poluio) Realidade social indivduos fiat (e.g., lote) topografias sociais (e.g., segregao)
Os conceitos fsicos podem ser subdivididos em: Conceitos associados a entidades individualizveis, que possuem uma fronteira bem definida a partir de diferenciaes qualitativas ou descontinuidades na natureza. Designados como indivduos bona fide
O universo ontolgico
(do latim boa f), sua existncia decorre de nossa necessidade de dar nomes aos elementos do mundo natural. Por exemplo, embora a a superfcie da Terra apresente uma variao contnua no espao, nossa percepo do espao depende da associao de nomes especiais a variaes bem definidas no terreno. Da nascem conceitos como montanha, vale e desfiladeiro. Conceitos associados a entidades que tem variao contnua no espao, associadas aos fenmenos do mundo natural, no estando a princpio limitadas por fronteiras. Chamamos estes conceitos de topografias fsicas, onde o termo topografia est associado a qualquer grandeza que varia continuamente. Exemplos incluem temperatura, altimetria, declividade e poluio. Os conceitos sociais podem ser subdivididos em: Conceitos que descrevem entidades individuais criadas por leis e por aes humanas. Estas entidades possuem uma fronteira que as distingue do seu entorno e tem uma identidade nica. Sua existncia depende usualmente de um registro legal. Designadas como indivduos fiat (do latim fazer), incluem conceitos como lotes, municpios e pases. Conceitos descrevendo entidades que tm variao contnua no espao, associadas a convenes sociais. Tome-se o caso de pobreza, conceito socialmente definido que ocorre no espao de forma ininterrupta (em cada lugar h algum tipo diferente de pobreza). Chamamos estes conceitos de topografias sociais. Exemplos incluem: excluso social, segregao urbana, desenvolvimento humano. Uma geo-ontologia um conjunto de conceitos e um conjunto de relaes semnticas e espaciais entre estes termos. Cada conceito tem um nome, uma definio e um conjunto de atributos. O conjunto das relaes semnticas inclui as relaes de sinonmia, similaridade, e hiponmia (tambm dito especializao: hospital um tipo de prdio). Por exemplo: rio: Curso de gua natural, de extenso mais ou menos considervel, que se desloca de um nvel mais elevado para outro mais baixo,
10
aumentando progressivamente seu volume at desaguar no mar, num lago, ou noutro rio. riacho: rio pequeno, mais volumoso que o regato e menos que a ribeira relao semntica: um riacho um rio. (hiponmia). O conjunto de relaes espaciais inclui as relaes topolgicas como pertinncia e adjacncia, relaes direcionais como ao norte de, e relaes informais como no corao de ou perto de. Por exemplo: afluente: curso de gua que desgua em outro curso de gua, considerado principal. relao espacial: um afluente est conectado a um rio. Na maior parte dos sistemas de informao atuais, as ontologias de aplicao no esto explicitadas, o que reduz o potencial de compartilhamento da informao. Com o advento da Internet, que permite a disseminao de dados forma ampla e para um pblico heterogneo, a necessidade de explicitar as ontologias utilizadas tornouse ainda mais premente. A explicitao das ontologias de aplicao est na base das propostas recentes da Web Semntica (Berners-Lee et al., 2001) e de propostas de padres como OWL. Como resultado de pesquisas recentes, j temos vrios sistemas disponveis na Internet para criao e gesto de ontologias, como o Proteg (Noy et al., 2001). Para dados geogrficos, o consrcio OGC (Open Geospatial Consortium) props o formato GML como mecanismo de descrio de ontologias geogrficas. Fazemos uma descrio mais detalhada do tema nos Captulos 9 e 10 deste livro. 1.5 O universo formal O universo formal representa um componente intermedirio entre os conceitos do universo ontolgico e as estruturas de dados e algoritmos computacionais. Como os computadores trabalham com estruturas matemticas, a passagem direta de conceitos informais da ontologia de aplicao para estruturas de dados poderia gerar decises inconsistentes. No universo formal, buscamos estabelecer um conjunto de entidades lgicas que agrupem os diferentes conceitos da ontologia de aplicao da
O universo formal
11
forma mais abrangente possvel. Adicionalmente, neste universo definimos ainda como sero associados valores aos diferentes conceitos; ou seja, como podemos medir o mundo real. Deste modo, o universo formal tem duas partes: (a) como medir o mundo real (teoria da medida); (b) como generalizar os conceitos da ontologia em entidades formais abrangentes. Estas duas partes sero discutidas a seguir. 1.5.1 Atributos de dados geogrficos: teoria da medida Para representar dados geogrficos no computador, temos de descrever sua variao no espao e no tempo. Em outras palavras, precisamos poder a perguntas como: qual o valor deste dado aqui e agora?. Isto requer uma compreenso dos processos de mensurao da realidade, de forma consistente com os dois primeiros princpios de Searle (1998): a realidade existe independentemente das representaes humanas e ns temos acesso ao mundo atravs de nossos sentidos e de nossos instrumentos de medida. O processo de medida consiste em associar nmeros ou smbolos a diferentes ocorrncias de um mesmo atributo, para que a relao dos nmeros ou smbolos reflita as relaes entre as ocorrncias mensuradas. Por exemplo, podemos medir a poluio numa cidade atravs de sensores localizados em diferentes locais. Cada um destes sensores nos dar uma medida diferente. Esta atribuio denominada escala de medida. A referncia geral mais importante sobre escalas de medidas o trabalho de Stevens (1946), que prope quatro escalas de mensurao: nominal, ordinal, intervalo e razo. Os nveis nominal e ordinal so temticos, pois a cada medida atribudo um nmero ou nome associando a observao a um tema ou classe. A escala nominal classifica objetos em classes distintas sem ordem inerente, como rtulos que podem ser quaisquer smbolos. As possveis relaes entre os valores so identidade (a = b) e dessemelhana (a b). Um exemplo a cobertura do solo, com rtulos como floresta, rea urbana e rea agrcola.
12
Figura 1.3 Exemplos de medida nominal (mapa geolgico) e medida ordinal (mapa de classes de declividade) .
A escala ordinal introduz a idia de ordenao, caracterizando os objetos em classes distintas que possuem uma ordem natural (por exemplo 1 ruim, 2 bom, 3 timo ou 0-10%, 11-20%, mais que 20%). A distncia definida entre os elementos no significativa. Nesta escala so evidenciadas as relaes < ou >, isto implica que para todo a e b, as relaes a < b, a > b ou a = b so possveis. Um exemplo a aptido agrcola de solos, com rtulos como muito apto, apto, pouco apto, e inapto (ver Figura 1.3). As medidas temticas no esto associadas magnitude do fenmeno. Quando o estudo necessita de uma descrio mais detalhada, que permita comparar intervalo e ordem de grandeza entre eventos, recorrese aos nveis de medidas denominados de numricos, onde as regras de atribuio de valores baseiam-se em uma escala de nmeros reais. Existem dois nveis de medidas baseados em escalas de nmeros reais: escala por intervalo e o escala por razo. A escala por intervalo possui um ponto zero arbitrrio, uma distncia proporcional entre os intervalos e uma faixa de medidas entre [-,]. A temperatura em graus Celsius exemplo de medida por intervalo, onde o ponto zero corresponde a uma
O universo formal
13
conveno (a fuso do gelo em gua). Por ter uma referncia zero arbitrria, valores medidos no nvel por intervalo no podem ser usados para estimar propores. Operaes aritmticas elementares (adio e subtrao) so vlidas, porm multiplicao e diviso no so apropriadas. Por exemplo, dados a e b, pode-se ter a = b + c, onde c a diferena entre a e b em alguma unidade padro. Assim, a temperatura em So Paulo pode ser c graus mais baixa do que a temperatura em Campos de Jordo. A escala de razo permite um tratamento mais analtico da informao, pois nela o ponto de referncia zero no arbitrrio, mas determinado por alguma condio natural. Sua faixa de valores limitada entre [0,]. Nesta escala existe um ponto zero absoluto que no pode ser alterado e um intervalo arbitrrio com distncias proporcionais entre os intervalos. Nmeros negativos no so permitidos, pois o nmero zero representa ausncia total daquilo que est sendo medido. Por exemplo, na descrio de atributos como peso e volume de objetos no h valores negativos. No caso de temperatura em graus Kelvin, a condio natural o ponto de repouso dos tomos da matria, a partir do qual no se consegue temperaturas menores. Este ponto o zero absoluto para temperatura, zero graus Kelvin. O fato de ponto de referncia zero ser absoluto permite afirmaes tais como a duas vezes mais pesado que b. Desta forma, dado a e b pode-se ter a = c x b, onde c indica o nmero de vezes que b vai at a, a relao de a para b. Operaes matemticas de adio, subtrao, multiplicao e diviso so suportadas nesta escala. A Tabela 1.2 apresenta um resumo das escalas de medidas, destaca a caracterstica principal, apresenta algumas operaes admitidas e exemplos para cada uma delas.
Tabela 1.2 Tipos de medidas de dados geogrficos Escala Nominal Caractersticas Descrio Exemplos Operaes possveis
Tipo de solo, vegetao, Seleo, uso do solo Comparao
14
Ordinal
Ordem
Classes de declividade, aptido de uso Altimetria Renda, populao, taxa de natalidade
Mediana, Mximo, Mnimo Diferena, Soma Operaes aritmticas
Intervalo Distncia Razo Valores absolutos
1.5.2 Espao absoluto e espao relativo Antes de considerar os diferentes modelos formais para dados geogrficos, necessrio analisarmos brevemente os conceitos de espao absoluto e espao relativo. Esta distino decorre da possibilidade de representarmos no computador a localizao dos objetos no espao ou apenas o posicionamento relativo entre eles, como ilustrado na Figura 1.4. Nesta figura, mostramos esquerda os distritos da cidade de So Paulo, identificados por suas fronteiras. Neste caso, trata-se de uma representao no espao absoluto, na qual as coordenadas das fronteiras devem corresponder s estabelecidas na legislao. Do lado direito, mostramos um grafo com as conexes dos distritos, que formam uma rede (repetimos a imagem dos distritos por razes de melhor legibilidade da figura). No modelo de redes, a localizao exata de cada distrito no armazenada, pois a rede s captura as relaes de adjacncia. Dizemos ento que a rede de conexes dos distritos um modelo de espao relativo.
O universo formal
15
Figura 1.4 Dualidade entre espao absoluto e espao relativo. esquerda, distritos de So Paulo com suas fronteiras. direita, grafo mostrando a rede de conectividade entre os distritos (espao relativo). O mapa da esquerda foi repetido por razes de melhor legibilidade.
A distino entre espao absoluto e espao relativo de grande importncia para a Geografia. Milton Santos (Santos, 1985) refere-se ao espao dos fixos e ao espao dos fluxos. Castells (1999) fala em espao de lugares e espaos de fluxos. Vejam o que Helen Couclelis comenta a respeito do tema: Espao absoluto, tambm chamado cartesiano, um container de coisas e eventos, uma estrutura para localizar pontos, trajetrias e objetos. Espao relativo, ou leibnitziano, o espao constitudo pelas relaes espaciais entre coisas (Couclelis, 1997). Uma das escolhas bsicas que fazemos na modelagem dos fenmenos geogrficos definir se utilizaremos representaes no espao absoluto ou no espao relativo. Esta escolha depende primordialmente do tipo de anlise que queremos realizar. Usualmente, consultas espaciais que envolvem dois tipos de entidades (quais os rios que cruzam esta estao ecolgica?) requerem a representao no espao absoluto. O mesmo vale para questes de lgebra de mapas (reas inaptas tem declividade maior que 15% ou solos arenosos). Quando os procedimentos de anlise
16
envolvem apenas as relaes de conectividade (como chegar na estao de metr Clnicas, partindo da estao Liberdade? ou qual a mdia da mortalidade infantil de meus vizinhos?) podemos utilizar representaes no espao relativo. Quando falamos em entidades como estradas, linhas de transmisso, conexes de gua e esgoto, cadeias de mercado e linhas de comunicao, o espao relativo na maioria das vezes plenamente adequado. 1.5.3 Modelos no espao absoluto: geo-campos e geo-objetos Existem dois modelos formais para entidades geogrficos no espao absoluto: geo-campos e geo-objetos. O modelo de geo-campos enxerga o espao geogrfico como uma superfcie contnua, sobre a qual variam os fenmenos a serem observados. Por exemplo, um mapa de vegetao associa a cada ponto do mapa um tipo especfico de cobertura vegetal, enquanto um mapa geoqumico associa o teor de um mineral a cada ponto. O modelo de geo-objetos representa o espao geogrfico como uma coleo de entidades distintas e identificveis, onde cada entidade definida por uma fronteira fechada. Por exemplo, um cadastro urbano identifica cada lote como um dado individual, com atributos que o distinguem dos demais. Definio 1.1. Geo-Campo. Um geo-campo representa um atributo que possui valores em todos os pontos pertencentes a uma regio geogrfica. Um geo-campo gc uma relao gc = [R, A, f], onde R 2 uma partio conexa do espao, A um atributo cujo domnio D(A), e a funo de atributo f: R A tal que, dado p R, f(p) = a, onde a D(A). A noo de geo-campo decorre da definio fsica associada (segundo o Aurlio, campo um conjunto de valores de uma grandeza fsica que, numa regio do espao, dependem s das coordenadas dos pontos pertencentes a essa regio). Em outras palavras, para cada ponto do espao, um campo ter um valor diferente. Definio 1.2 Geo-Objeto. Um geo-objeto uma entidade geogrfica singular e indivisvel, caracterizada por sua identidade, suas fronteiras, e seus atributos. Um geo-objeto uma relao go = [id, a1,...an, G], onde id um identificador nico, G um conjunto de parties 2D conexas e
O universo formal
17
distintas {R1,...,Rn} do espao 2, e ai so os valores dos atributos A1,..., An. Note-se que um geo-objeto pode ser composto por diferentes geometrias, onde cada geometria tem uma fronteira fechada (e.g., o Japo com suas diferentes ilhas). Um exemplo de geo-campo (uma imagem IKONOS da cidade do Rio de Janeiro) e de um conjunto de geo-objetos (os distritos dessa cidade) apresentado na Figura 1.5. A varivel associada imagem a reflectncia do solo, medida pelo sensor ptico do satlite. Os geo-objetos associados aos distritos de So Paulo so mostrados numa gradao de tons de cinza, cuja intensidade proporcional ao ndice de excluso social (Sposati, 1996); quanto mais escuro, mais o distrito possui moradores em situao de excluso social. Os dados na Figura 1.3 acima (geologia e declividade) tambm so exemplos de geo-campos. A Figura 1.5 tambm ilustra uma questo importante: existem diferenas fundamentais entre geo-campos e geo-objetos? Ou seriam apenas duas maneiras de ver o mesmo tipo de dado? Considere os retngulos desenhados no interior das duas representaes mostradas. Na figura esquerda, o interior do retngulo tem as mesmas propriedades do geocampo que o contm. Para cada ponto interior ao retngulo, podemos recuperar o valor do atributo (neste caso, a reflectncia da imagem). Verificamos que uma partio espacial genrica de um geo-campo compe outro geo-campo com as mesmas propriedades.
18
Figura 1.5 Exemplo de geo-campo (imagem IKONOS do Rio de Janeiro) e de conjunto de geo-objetos (distritos da cidade de So Paulo).
Considere agora a figura da direita (distritos de So Paulo). O interior do retngulo mostrado no define mais um conjunto de geo-objetos com as mesmas propriedades do conjunto completo. O retngulo intercepta parcialmente alguns objetos. Como cada objeto nico e no pode ser dividido sem perder suas caractersticas originais, verificamos que uma partio espacial genrica de um conjunto de geo-objetos no compe outro conjunto de geo-objetos com as mesmas propriedades. A diferena essencial entre um geo-campo e um geo-objeto o papel da fronteira. A fronteira de um geo-campo uma diviso arbitrria relacionada apenas com nossa capacidade de medida. Na Figura 1.5, os limites da imagem correspondem apenas a eventuais limitaes do instrumento sensor e no do fenmeno medido. Assim, o geo-campo pode ser divido em partes e ainda assim manter sua propriedade essencial (que sua funo de atributo). Por contraste, um geo-objeto essencialmente definido por sua fronteira, que o separa do mundo exterior; ele no pode ser dividido e manter suas propriedades essenciais. Dentro da fronteira, todas as propriedades do objeto so constantes. Tomemos um distrito de So Paulo, como a S, que tem um cdigo nico de identificao no censo do
O universo formal
19
IBGE. Se dividirmos a S em duas partes, precisamos de dois novos cdigos de identificao para caracterizar os dois novos distritos. O exame da Figura 1.5 ilustra outra propriedade dos geo-objetos. bastante comum lidarmos com um conjunto de geo-objetos que representam uma partio consistente do espao; isto , os recobrimentos espaciais destes objetos no se interceptam e eles possuem o mesmo conjunto de atributos. Estas caractersticas fazem com que possamos agrupar estes objetos numa coleo. Definio 1.3 Coleo de geo-objetos. Uma coleo de geo-objetos relao cgo = [id, o1,...on, A1,..., An], onde id um identificador nico, e o1,...on so geo-objetos que possuem os atributos A1,..., An. Usualmente, se Ri for a regio geogrfica associada a oi, temos Ri Rj = , i j. Deste modo, uma coleo rene geo-objetos cujas fronteiras no se interceptam, e tm o mesmo conjunto de atributos. O uso de colees de geo-objetos bastante freqente em bancos de dados geogrficos, pois muito conveniente tratar geo-objetos similares de forma consistente. Por exemplo, falamos dos distritos da cidade de So Paulo, dos municpios do estado do Cear, e das reservas indgenas da Amaznia. A idia de colees de geo-objetos ainda til para propormos um modelo orientado-a-objetos para dados geogrficos, discutido a seguir. 1.5.4 Modelos no espao relativo: redes O modelo de redes concebe o espao geogrfico como um conjunto de pontos no espao (chamados de ns), conectados por linhas (chamados arcos), onde tanto os ns quanto os arcos possuem atributos. Os fenmenos modelados por redes incluem fluxo de pessoas ou materiais, conexes de influncia, linhas de comunicao e acessibilidade. Um dos atrativos do modelo de redes que o suporte matemtico para este modelo (a teoria de grafos) uma rea de pesquisa consolidada (Bondy e Murty, 1976) (Gross e Yelen, 1998). O problema que deu incio teoria dos grafos foi uma questo espacial. Em 1736, o matemtico Leonard Euler vivia na cidade de Knigsberg (na poca parte da Prssia; hoje chamada Kaliningrad e pertencente Rssia) onde haviam duas ilhas prximas no meio da
20
cidade, cruzadas por sete pontes (ver Figura 1.6 esquerda). Euler se perguntou se havia uma maneira de fazer um circuito fechado (sair e voltar para um mesmo lugar), cruzando cada uma das pontes apenas uma vez. Ele construiu um grafo equivalente (ver Figura 1.6 direita) e demonstrou que o problema era insolvel.
Figura 1.6 As sete pontes de Knigsberg e o grafo equivalente. Definio 1.4 Redes. Uma rede uma estrutura geogrfica que tem como suporte um grafo G = [N, A, ], onde N um conjunto de ns, A um conjunto de arcos (arestas), e (a)=(u,v) uma funo de incidncia que associa cada arco a A a um par de ns (u, v) N. No caso geogrfico, os ns podem estar associados a uma localizao (x,y) do espao para fins de referncia. Como os ns de uma rede so abstraes de entidades existentes no espao, eles podem estar associados aos seus atributos descritivos. Por exemplo, na rede mostrada na Figura 1.4, cada n est associado a um distrito de So Paulo, e poderia ter diferentes atributos que descrevem este distrito. Tambm os arcos de uma rede podem ter propriedades, como o custo de percorrimento de um n a outro. As propriedades mensurveis das redes incluem operaes diretas computveis sobre a topologia do grafo, como qual o caminho timo entre dois ns. Tambm podemos computar operaes matemticas que envolvem apenas as relaes de conectividade, como os indicadores locais de autocorrelao espacial (veja-se a respeito, Druck et al., 2004).
O universo formal
21
A definio de redes pode ser estendida para considerar o caso de conexes bidirecionais, como no caso de redes de transporte, onde as relaes entre os ns no so simtricas, pois os fluxos em sentidos opostos podem ser diferentes. A Figura 1.7 ilustra uma rede simples e uma rede com conexes bidirecionais.
Figura 1.7 Exemplos de redes simples e de redes com conexes bidirecionais.
Os modelos de rede tm grande utilidade em problemas de geoinformao, incluindo assuntos como gerenciamento de servios como gua, esgoto, eletricidade e telefonia. Para maiores referncias, deve-se consultar Birkin et al (1996) e Godin (2001). 1.5.5 Um modelo orientado-a-objetos para dados geogrficos As sees anteriores nos permitem apresentar um modelo orientado-aobjetos que apresenta uma verso unificada dos dados geogrficos, com base nos conceitos bsicos de geo-campo, coleo de geo-objetos e rede. Para fins de organizao lgica, o modelo considera a existncia de uma classe genrica, chamada de plano de informao (ou layer), que uma generalizao destes dois conceitos. O conceito de plano de informao captura uma caracterstica comum essencial dos trs conceitos bsicos: cada instncia deles referente a uma localizao no espao e tem um identificador nico. Assim, o uso do conceito de plano de informao permite organizar o banco de dados geogrfico e responder a perguntas como: Quais so os dados presentes no banco, qual o modelo associado a cada um e qual a regio geogrfica associada? Adicionalmente, como cada
22
geo-campo est associado a uma nica funo de atributo, ele pode ser especializado em geo-campo temtico (associado a medidas nominais ou ordinais) e geo-campo numrico (associados a medidas por intervalo ou por razo). Com estes seis conceitos, construmos um modelo formal bsico para dados geogrficos, mostrado na Figura 1.8.
Figura 1.8 Modelo OO bsico para dados geogrficos.
O modelo mostrado na Figura 1.8 serve de base para a maioria dos modelos de dados orientados-a-objetos adotados atualmente em geoinformao: O software SPRING (Cmara et al., 1996) inclui os conceitos de rede, geo-campo numrico e geo-campo temtico, coleo de geo-objetos (chamada de mapa cadastral). Os geo-campos numricos admitem as imagens como caso particular. No ArcGIS (ESRI, 2000), a coleo de geo-objetos chamada de features (feies). Os geo-campos numricos so chamados de surfaces (superfcies), e as imagens tambm so modeladas como caso particular de geo-campos numricos. As redes (networks) tambm so includas. No modelo OpenGIS (OGC, 1998), os geo-campos so chamados de coverage, e a coleo de objetos chamada de feature collection. O modelo OpenGIS no tem o conceito explcito de layer, mas
Do universo ontolgico ao universo formal
23
considera que as vises de feature collection e coverage so complementares. Na TerraLib (vide Captulo 12 deste livro), o conceito de plano de informao (layer) um conceito usado para organizar a informao no banco de dados. Os conceitos de geo-campos e de colees de geoobjetos so implcitos. Como se trata de uma biblioteca, os designers da TerraLib quiseram permitir diferentes alternativas de projeto de sistema. 1.6 Do universo ontolgico ao universo formal Para passar do universo ontolgico para o universo formal, precisamos responder pergunta: como os conceitos da ontologia de aplicao so formalizados? Colocando o problema de forma mais geral: Que critrios deve satisfazer um conceito para que seja utilizvel em estudos quantitativos associados geoinformao? Tais critrios so: O conceito deve ser passvel de ser associado a propriedades mensurveis. Estas propriedades devem ser medidas no territrio e devem permitir diferenciar as diferentes localizaes. Os resultados quantitativos e os modelos matemticos utilizados devem ser validados em estudos de campo, que devem incluir dimenses objetivas e subjetivas do fenmeno em questo. Para representar um conceito genrico como excluso social, precisamos definir precisamente quais atributos caracterizam a excluso social e como podemos medi-los no territrio. Esta caracterizao realiza a passagem do universo ontolgico para o universo formal. Com base em conceitos bem estabelecidos e associados a medidas quantitativas no espao, podemos construir territrios digitais. O processo pode ser resumido na Figura 1.9.
24
Domnios do Conhecimento Modelos Inferenciais Hipteses Testveis
Teorias
Conceitos Qualitativos
Territrios Digitais
Figura 1.9 Relao entre a construo dos territrios digitais e as teorias disciplinares (cortesia de Silvana Amaral Kampel).
Os especialistas desenvolvem teorias gerais sobre os fenmenos, que incluem o estabelecimento de conceitos organizadores de sua pesquisa (como excluso ou vulnerabilidade). Para passar destas teorias para a construo computacional, necessrio que o especialista formule modelos inferenciais quantitativos. Estes modelos devem ser submetidos a testes de validao e de corroborao, atravs dos procedimentos de anlise quantitativa. Os resultados numricos podem ento dar suporte ou ajudar a rejeitar conceitos qualitativos. Aps definir como que atributos mensurveis sero associados ao conceito, o projetista do sistema de informao dever decidir se este conceito ser modelado no espao absoluto ou no espao relativo. A deciso deve-se dar essencialmente em funo das propriedades que queremos medir. Se a localizao exata fundamental, ou se precisamos saber o valor do fenmeno em todos os pontos da regio de estudo, ento necessrio usar os modelos de espao absoluto. Se o fluxo e as conexes so essenciais, ento podemos usar o modelo de rede. Se precisamos dos dados expressos no espao absoluto, ento devemos escolher ainda qual o modelo apropriado (geo-campo ou geo-objeto). Para isto, a deciso depende essencialmente do papel da fronteira. Se as fronteiras so parte essencial das entidades modeladas, estamos tratando com indivduos e no com topografias (vide Tabela 1.1) e o modelo de
Universo estrutural
25
geo-objetos o mais adequado. Seno, usaremos os modelos de geocampos. 1.7 Universo estrutural As estruturas de dados utilizadas em bancos de dados geogrficos podem ser divididas em duas grandes classes: estruturas vetoriais e estruturas matriciais. 1.7.1 Estruturas de dados vetoriais As estruturas vetoriais so utilizadas para representar as coordenadas das fronteiras de cada entidade geogrfica, atravs de trs formas bsicas: pontos, linhas, e reas (ou polgonos), definidas por suas coordenadas cartesianas, como mostrado na Figura 1.10.
Figura 1.10 Representaes vetoriais em duas dimenses.
Um ponto um par ordenado (x, y) de coordenadas espaciais. O ponto pode ser utilizado para identificar localizaes ou ocorrncias no espao. So exemplos: localizao de crimes, ocorrncias de doenas, e localizao de espcies vegetais. Uma linha um conjunto de pontos conectados. A linha utilizada para guardar feies unidimensionais. De uma forma geral, as linhas esto associadas a uma topologia arco-n, descrita a seguir. Uma rea (ou polgono) a regio do plano limitada por uma ou mais linhas poligonais conectadas de tal forma que o ltimo ponto de uma linha seja idntico ao primeiro da prxima. Observe-se tambm que a fronteira do polgono divide o plano em duas regies: o interior e o exterior. Os polgonos so usados para representar unidades
26
espaciais individuais (setores censitrios, distritos, zonas de endereamento postal, municpios). Para cada unidade, so associados dados oriundos de levantamentos como censos e estatsticas de sade. 1.7.2 Vetores e topologia: o caso dos geo-objetos A topologia a parte da matemtica na qual se investigam as propriedades das configuraes que permanecem invariantes nas transformaes de rotao, translao e escala. No caso de dados geogrficos, til ser capaz de determinar relaes como adjacncia (vizinho de), pertinncia (vizinho de), interseco, e cruzamento. Objetos de rea podem ter duas formas diferentes de utilizao: como objetos isolados ou objetos adjacentes. O caso de objetos isolados bastante comum em SIG urbanos, e ocorre no caso em que os objetos da mesma classe em geral no se tocam. Por exemplo, edificaes, piscinas, e mesmo as quadras das aplicaes cadastrais ocorrem isoladamente, no existindo segmentos poligonais compartilhados entre os objetos. Finalmente, temos objetos adjacentes, e os exemplos tpicos so todas as modalidades de diviso territorial: bairros, setores censitrios, municpios e outros. Neste caso, pode-se ter o compartilhamento de fronteiras entre objetos adjacentes, gerando a necessidade por estruturas topolgicas. Estes tambm so os casos em que recursos de representao de buracos e ilhas so mais necessrios. Quando queremos armazenar as estruturas de dados do tipo polgono no caso de objetos adjacentes, temos uma deciso bsica a tomar: guardamos as coordenadas de cada objeto isoladamente, e assim duplicamos as fronteiras em comum com outros objetos, ou armazenamos cada fronteira comum uma nica vez, indicando a que objetos elas esto associadas? No primeiro caso chamado de polgonos sem topologia e o segundo, de topologia arco-n-polgono, comparados na Figura 1.11.
Universo estrutural
27
Figura 1.11 Polgonos sem topologia ( esquerda) e topologia arco-npolgono ( direita). (Fonte: Ravada, 2003).
Figura 1.12 Topologia arco-n-polgono. A topologia arco-n-polgono, como mostrado na Figura 1.12, requer trs listas separadas. Os pontos inicial e final de cada linha so chamados de ns. Para cada n, armazenamos as linhas nele incidentes. Para cada linha, armazenamos os ns inicial e final, permitindo assim que a linha esteja associada a um sentido de percorrimento; guardamos ainda os dois polgonos separados por cada linha ( esquerda e direita, considerando o sentido de percorrimento). Para cada polgono, guardamos as linhas que definem sua fronteira.
28
1.7.3 Vetores e topologia: o caso das redes Objetos de linha podem ter variadas formas de utilizao. Analogamente aos objetos de rea, podemos ter objetos de linha isolados, em rvore e em rede. Objetos de linha isolados ocorrem, por exemplo, na representao de muros e cercas em mapas urbanos. Objetos de linha organizados em uma rvore podem ser encontrados nas representaes de rios e seus afluentes, e tambm em redes de esgotos e drenagem pluvial. E podem ser organizados em rede, nos casos de redes eltricas, telefnicas, de gua ou mesmo na malha viria urbana e nas malhas rodoviria e ferroviria. No caso das redes, fundamental armazenar explicitamente as relaes de adjacncia, utilizamos a topologia arco-n. Um n pode ser definido como o ponto de interseco entre duas ou mais linhas, correspondente ao ponto inicial ou final de cada linha. Nenhuma linha poder estar desconectada das demais para que a topologia da rede possa ficar totalmente definida. Para exemplificar, considere-se a Figura 1.13, que mostra um exemplo de como a topologia arco-n pode ser armazenada.
Figura 1.13 Estrutura de dados para topologia arco-n no Oracle Spatial SGBD (Fonte: Ravada, 2003).
Universo estrutural
29
1.7.4 Vetores e topologia: o caso dos dados 2,5 D Uma das possibilidades associadas a dados vetoriais a associao de valores que denotem a variao espacial de uma grandeza numrica. No caso mais simples, associamos a cada localizao no espao um valor numrico de atributo. Neste caso, como os valores de localizao esto no plano e o valor adicional descreve uma superfcie sobre este plano. Os dados resultantes so chamados de dimenso dois e meio, pois no se tratam estritamente de dados tridimensionais, pois o suporte espacial ainda so localizaes 2D. A Figura 1.14 ilustra exemplo de dados de dimenso 2,5.
Figura 1.14 Exemplo de dado com dimenso 2,5 (cortesia de Renato Assuno).
A maneira mais comum de armazenar estes dados atravs de estruturas matriciais (vide prxima seo). Temos trs alternativas que usam estruturas vetoriais: Conjunto de amostras esparsas 2,5D, constitudo de pares ordenados (x,y,z), onde (x,y) uma localizao no plano e z um valor numrico de atributo. Conjunto de isolinhas (curvas de nvel), que so linhas s quais esto associados valores numricos. As isolinhas no se cruzam, e so entendidas como estando empilhadas umas sobre as outras. A malha triangular ou TIN (do ingls triangular irregular network) uma estrutura do tipo vetorial com topologia do tipo n-arco e
30
representa uma superfcie atravs de um conjunto de faces triangulares interligadas. A malha triangular a estrutura vetorial mais utilizada para armazenar dados 2,5D. Cada um dos trs vrtices da face do tringulo armazenados as coordenadas de localizao (x, y) e o atributo z, com o valor de elevao ou altitude. Em geral, nos SIGs que possuem pacotes para MNT, os algoritmos para gerao da malha triangular baseiam-se na triangulao de Delaunay com restrio de regio. Quanto mais equilteras forem as faces triangulares, maior a exatido com que se descreve a superfcie. O valor de elevao em qualquer ponto dentro da superfcie pode ser estimado a partir das faces triangulares, utilizando-se interpoladores. A Figura 1.15 mostra uma superfcie tridimensional e a grade triangular correspondente.
Figura 1.15 Superfcie e malha triangular correspondente. (cortesia de Larcio Namikawa ).
1.7.5 Hierarquia de representaes vetoriais Para um entendimento mais detalhado das representaes vetoriais em GIS, deve-se inicialmente precisar o que se entende por primitivas geomtricas: coordenadas 2D, coordenadas 2,5D, n 2D, n 2,5D, n de rede, arcos, arcos orientados, isolinhas e polgonos. Dada uma regio R 2, pode-se definir:
Universo estrutural
31
Uma coordenada 2D um objeto composto por uma localizao singular (xi, yj) R; COORDENADA_2,5D Uma coordenada 2,5D um objeto composto por uma localizao singular (xi, yj, z), onde (xi, yj) R; PONTO2D Um ponto 2D um objeto que possui atributos descritivos e uma coordenada 2D; LINHA2D Uma linha 2D possui atributos e inclui um conjunto de coordenadas 2D;
ISOLINHA uma
COORDENADA_2D
isolinha contm uma linha 2D associada a um valor
real (cota); um arco orientado contm uma linha 2D associada a uma orientao de percorrimento; N2D um n 2D inclui uma coordenada2D (xi, yi) R e uma lista L de linhas 2D (trata-se da conexo entre duas ou mais linhas, utilizada para manter a topologia da estrutura); N REDE um n de rede contm um n 2D e uma lista de arcos orientados; N 2,5D um n 2,5D instncia desta classe contm uma coordenada 2,5D (xi, yi, zi) e um lista L de linhas 2D (trata-se da conexo entre trs ou mais linhas de uma grade triangular); POLGONO um polgono pode ser armazenado como uma lista de coordenadas 2D (caso dos geo-objetos sem topologia) ou por uma uma lista de linhas 2D e uma lista de ns 2D (caso de topologia arcon-polgono). Uma vez definidas as primitivas geomtricas vetoriais, pode ser estabelecida a hierarquia de representaes geomtricas vetoriais, como mostrado na Figura 1.16, onde distinguem-se os relacionamentos de especializao -um (is-a), incluso de uma instncia parte-de (partof), incluso de um conjunto de instncias conjunto-de (set-of) e incluso de uma lista de identificadores de instncias lista-de (list-of).
ARCO ORIENTADO
32
Figura 1.16 Hierarquia de classes para estruturas vetoriais.
Distinguimos os seguintes tipos de estruturas de dados vetoriais: 2D uma instncia desta classe um conjunto de pontos 2D utilizados para guardar localizaes isoladas no espao (p.ex. no caso de poos de petrleo); CONJUNTO DE ISOLINHAS uma instncia desta classe um conjunto de linhas, onde cada linha possui uma cota e as linhas no se interceptam; SUBDIVISO PLANAR para uma regio geogrfica R qualquer, uma subdiviso planar contm um conjunto Pg de polgonos que no se sobrepem; GRAFO ORIENTADO uma instncia desta classe uma representao composta de um conjunto de n de rede e de um conjunto de arco orientado 2D;
CONJUNTO DE PONTOS
Universo estrutural
33
uma instncia desta classe contm um conjunto de ns 2,5D e um conjunto L de linhas 2D tal que todas as linhas se interseptam, mas apenas em seus pontos iniciais e finais; MAPA PONTOS 2,5D uma instncia desta classe um conjunto de coordenadas 2,5D. Trata-se de um conjunto de amostras 2,5D.
MALHA TRIANGULAR
1.7.6 Representao matricial As estruturas matriciais usam uma grade regular sobre a qual se representa, clula a clula, o elemento que est sendo representado. A cada clula, atribui-se um cdigo referente ao atributo estudado, de tal forma que o computador saiba a que elemento ou objeto pertence determinada clula. Nesta representao, o espao representado como uma matriz P(m, n) composto de m colunas e n linhas, onde cada clula possui um nmero de linha, um nmero de coluna e um valor correspondente ao atributo estudado e cada clula individualmente acessada pelas suas coordenadas. A representao matricial supe que o espao pode ser tratado como uma superfcie plana, onde cada clula est associada a uma poro do terreno. A resoluo do sistema dada pela relao entre o tamanho da clula no mapa ou documento e a rea por ela coberta no terreno, como mostrado na Figura 1.17.
Figura 1.17 Estrutura matricial.
A estrutura matricial pode ser utilizada para representar diferentes tipos de dados:
34
Grade regular: representao matricial de dimenso dois e meio na qual cada elemento da matriz est associado a um valor numrico, como mostra a Figura 1.18 esquerda. Matriz temtica: representao matricial 2D na qual cada valor da matriz um cdigo correspondente uma classe do fenmeno estudado, como mostra a Figura 1.18 direita.
Figura 1.18 esquerda, grade regular com valores de temperatura em graus Celsius e, direita, matriz temtica com dados classificados (1 = 15-20 graus, 2 = 20-25 graus, 3 = 25-35 graus).
1.7.7 Espaos celulares: generalizao de estruturas matriciais Um espao celular uma estrutura matricial generalizada onde cada clula est associada a vrios tipos de atributos. Os espaos celulares tm vrias vantagens sobre estruturas matriciais simples. Usando matrizes com um nico atributo (como o caso dos dados mostrados na Figura 1.18), um fenmeno espao-temporal complexo precisa de vrias matrizes separadas para ser representado, o que resulta em maior dificuldade de gerncia e de interface. Num espao celular, a mesma clula est associada a diferentes informaes, com ganhos significativos de manuseio dos dados. Os espaos celulares so muito convenientes para armazenamento em bancos de dados objeto-relacionais. Toda a estrutura de um espao
Universo estrutural
35
celular pode ser armazenada numa nica tabela, o que faz o manuseio dos dados ser bem mais simples que os dados vetoriais ou mesmo que os dados matriciais indexados. Aplicaes como lgebra de mapas e modelagem dinmica ficam mais simples de implementar e operar. Um exemplo de espao celular mostrado na Figura 1.19, onde mostramos uma parte de um banco de dados onde h um espao celular onde a Amaznia foi dividida em clulas de 25 x 25 km2; cada uma delas est associada a diferentes atributos socioeconmicos e ambientais (na Figura 1.19, o atributo visualizado umidade mdia nos trs meses mais secos do ano). Os espaos celulares ainda no so estruturas de dados comuns nos bancos de dados geogrficos, e atualmente apenas a TerraLib tem suporte para este tipo de estrutura (vide Captulo 12). Com a nfase crescente dos SIG em modelos dinmicos, podemos prever que esta estrutura ser futuramente amplamente disponvel nas diferentes implementaes de bancos de dados geogrficos.
Figura 1.19 Espao celular com a Amaznia dividida em clulas de 25 x 25 km2; o atributo visualizado umidade mdia nos trs meses mais secos do ano (cortesia: Ana Paula Dutra de Aguiar).
36
1.8 Do universo formal para o universo estrutural A passagem do universo formal (geo-campos, geo-objetos e redes) para o universo estrutural no unvoca. Para cada tipo de entidade do modelo formal, h diferentes possibilidades de uso de estruturas de dados, a saber: Geo-objetos: como as fronteiras so elementos essenciais, so usualmente armazenados em estruturas poligonais, com as opes polgonos sem topologia ou topologia arco-n-polgono. Redes: como a topologia parte essencial, as redes devem ser armazenadas como um grafo orientado. Geo-campos numricos: podem ser armazenados como amostras 2,5D, malhas triangulares ou grades regulares. Geo-campos temticos: admitem o armazenamento como estruturas vetoriais (polgonos) ou matriciais (matrizes temticas). Os diferentes compromissos de armazenamento para as entidades do modelo formal so discutidos a seguir. Note-se que um espao celular (discutido na Seo 1.7.7) pode guardar uma combinao arbitrria de geo-campos numricos e temticos. 1.8.1 Estruturas de dados para geo-objetos A escolha entre estruturas topolgicas ou no-topolgicas para geoobjetos em bancos de dados geogrficos depende tambm do suporte oferecido pelo SGBD. Nos SIG cujas estruturas de dados geomtricas so manuseadas fora do SGBD (como o SPRING e o Arc/Info), comum a escolha da topologia arco-n-polgono. No caso dos bancos de dados geogrficos, a maneira mais simples de armazenar geo-objetos guardando cada um deles separadamente, o que implica em estruturas no-topolgicas. Esta forma de trabalho foi sancionada pelo consrcio Open GIS e suportada pelos diferentes SGBDs (Oracle, PostgreSQL, mySQL). No entanto, vrias aplicaes requerem o uso da topologia arco-n-polgono, e alguns SGBDs com suporte espacial j esto incluindo esta opo, com o Oracle Spatial (Ravada, 2003).
Do universo formal para o universo estrutural
37
1.8.2 Estruturas de dados para geo-campos temticos Geo-campos temticos admitem tanto a representao matricial quanto a vetorial. Para a produo de cartas e em operaes onde se requer maior preciso, a representao vetorial mais adequada. As operaes de lgebra de mapas so mais facilmente realizadas no formato matricial. No entanto, para um mesmo grau de preciso, o espao de armazenamento requerido por uma representao matricial substancialmente maior. Isto ilustrado na Figura 1.20.
Figura 1.20 Geo-campo temtico em estruturas vetorial e matricial.
A Tabela 1.3 apresenta uma comparao entre as vantagens e desvantagens de armazenamento matricial e vetorial para geo-campos temticos. Esta comparao leva em conta os vrios aspectos: relacionamentos espaciais, anlise, armazenamento. Nesta tabela, o formato mais vantajoso para cada caso apresentado em destaque. O armazenamento de geo-campos temticos em estruturas vetoriais uma herana da cartografia, onde limites entre classes temticas eram desenhados com preciso em mapas. No entanto, sabemos que estes limites so imprecisos, na grande maioria dos casos. Assim, como nos ensina Peter Burrough, as estruturas matriciais so mais adequadas: Os limites desenhados em mapas temticos (como solo, vegetao, ou geologia) raramente so precisos e desenha-los como linhas finas muitas vezes no representa adequadamente seu carter. Assim, talvez
38
no nos devamos preocupar tanto com localizaes exatas e representaes grficas elegantes. Se pudermos aceitar que limites precisos entre padres de vegetao e solo raramente ocorrem, ns estaramos livres dos problemas de erros topolgicos associados como superposio e interseo de mapas(Burrough, 1986).
Tabela 1.3 Comparao entre estruturas vetoriais e matriciais para mapas temticos Aspecto Armazenamento Algoritmos Escalas de trabalho Vetorial Por coordenadas (mais eficiente) Problemas com erros geomtricos Adequado tanto a grandes quanto a pequenas escalas Representao indireta de fenmenos contnuos lgebra de mapas limitada Matricial Requer mais espao de armazenamento Processsamento mais rpido e eficiente. Mais adequado para pequenas escalas (1:25.000 e menores) Representa melhor fenmenos com variao contnua no espao Simulao e modelagem mais fceis
Anlise, Simulao e Modelagem
1.8.3 Estruturas de dados para geo-campos numricos Para geo-campos numricos, a escolha bsica se d entre malhas triangulares e grades regulares. As demais estruturas de dados (amostras 2,5D e isolinhas) so formatos intermedirios, utilizados para entrada ou sada de dados, mas no adequadas para anlise. As malhas triangulares so normalmente melhores para representar a variao do terreno, pois capturam a complexidade do relevo sem a necessidade de grande quantidade de dados redundantes. As grades regulares tm grande redundncia em terrenos uniformes e dificuldade de adaptao a relevos de natureza distinta no mesmo mapa, por causa da grade de amostragem fixa.
Universo de implementao
39
Para o caso de variveis geofsicas e para operaes como visualizao 3D, as grades regulares so preferveis, principalmente pela maior facilidade de manuseio computacional. A Tabela 1.4 resume as principais vantagens e desvantagens de grades regulares e malhas triangulares.
Tabela 1.4 Estruturas para geo-campos numricos Malha triangular Vantagens Melhor representao de relevo complexo Incorporao de restries como linhas de crista Complexidade de manuseio Grade regular Facilita manuseio e converso Adequada para dados noaltimtricos Representao relevo complexo Clculo de declividade
Problemas
1.8.4 Representaes computacionais de atributos de objetos Entende-se por atributo qualquer informao descritiva (nomes, nmeros, tabelas e textos) relacionada com um nico objeto, elemento, entidade grfica ou um conjunto deles, que caracteriza um dado fenmeno geogrfico. Nos bancos de dados geogrficos, os atributos de objetos geogrficos so armazenados em relaes convencionais. As representaes geomtricas destes objetos podem ser armazenadas na mesma tabela que os atributos ou em tabelas separadas, mas ligadas por identificadores nicos. Estes aspectos so discutidos em maior detalhe nos captulos 3, 5, e 8 deste livro. 1.9 Universo de implementao No universo de implementao, so tomadas as decises concretas de programao e que podem admitir nmero muito grande de variaes. Estas decises podem levar em conta as aplicaes s quais o sistema voltado, a disponibilidade de algoritmos para tratamento de dados geogrficos e o desempenho do hardware. Neste livro, aspectos do universo de implementao so tratados em diferentes captulos:
40
Os algoritmos de geometria computacional para problemas como ponto-em-polgono, simplificao de linhas e interseco de linhas e polgonos so tratados no Captulo 2. Os problemas de indexao espacial, que representam um componente determinante no desempenho total do sistema, so abordados no Captulo 6. As questes de processamento e otimizao de consultas espaciais so discutidas no Captulo 7. Uma discusso detalhada dos SGBDs com suporte espacial apresentada no Captulo 8. Os Captulo 12 a 14 apresentam a biblioteca TerraLib, um ambiente para construo de aplicativos geogrficos. 1.10 Leituras suplementares Este Captulo apresentou uma viso geral dos diferentes aspectos envolvidos com a representao computacional dos dados geogrficos, que o grande objetivo dos bancos de dados geogrficos. Para uma viso geral de geoinformao sob o ponto de vista da Cincia da Computao, a referncia mais atualizada Worboys e Duckham (2004). O livro de Druck et al (2004) apresenta uma discusso sobre as questes de anlise espacial de dados geogrficos. Sobre o tema de bancos de dados geogrficos, os livros de Rigaux et al (2002) e Shekar e Chawla (2002) so leituras complementares a este livro. A coletnea editada por Sellis et al (2003) apresenta um conjunto de artigos excelentes sobre os problemas emergentes de bancos de dados espao-temporais.
Referncias
41
Referncias
BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The Semantic Web. Scientific American, v. May, 2001. BIRKIN, M.; CLARKE, G.; CLARKE, M. P.; WILSON, A. Intelligent GIS : Location Decisions and Strategic Planning. New York: John Wiley, 1996. BONDY, J. A.; MURTY, U. S. R. Graph Theory with Applications. London: The Macmillan Press LTD, 1977. BNISCH, S.; ASSAD, M. L.; CMARA, G.; MONTEIRO, A. M. Representao e Propagao de Incertezas em Dados de Solos: I - Atributos Numricos. Revista Brasileira de Cincia do Solo, v. 28, n.1, p. 33-47, 2004. BURROUGH, P. Principles of Geographical Information Systems for Land Resources Assessment. Oxford, England, Oxford University Press, 1986. CALDEIRA, T. Cidade de Muros: Crime, Segregao e Cidadania em So Paulo (City of Walls: Crime, Segregation and Citizenship in Sao Paulo). So Paulo: Edusp, 2000. CMARA, G. Modelos, Linguagens e Arquiteturas para Bancos de Dados Geogrficos.So Jos dos Campos, SP: Instituto Nacional de Pesquisas Espaciais (INPE), 1995.Ph.D., 1995. CMARA, G.; SOUZA, R.; FREITAS, U.; GARRIDO, J. SPRING: Integrating Remote Sensing and GIS with Object-Oriented Data Modelling. Computers and Graphics, v. 15, n.6, p. 13-22, 1996. CMARA, G. S., R.C.M.; MONTEIRO, A.M.V.; PAIVA, J.A.C; GARRIDO, J. Handling Complexity in GIS Interface Design. In: I Brazilian Workshop on Geoinformatics. SBC, Campinas, SP, 1999. CASTELLS, M. A Sociedade em Rede. So Paulo: Paz e Terra, 1999. CHEN, P. S. S. The Entity-Relationship Model: Towards a Unified View of Data. ACM Transactions on Database Systems, v. 1, n.1, p. 9-36, 1976. COUCLELIS, H. From Cellular Automata to Urban Models: New Principles for Model Development and Implementation. Environment and Planning B: Planning and Design, v. 24, p. 165-174, 1997. DAVIS, C.; BORGES, K.; LAENDER, A. OMT-G: An Object-Oriented Data Model for Geographic Applications. GeoInformatica, v. 3, n.1, 2002.
42
DRUCK, S.; CARVALHO, M. S.; CMARA, G.; MONTEIRO, A. M. V. Anlise Espacial de Dados Geogrficos. Braslia: EMBRAPA (ISBN 857383-260-6), 2004. EGENHOFER, M. Spatial SQL: A Query and Presentation Language. IEEE Transactions on Knowledge and Data Engineering, v. 6, n.1, p. 86-95, 1994. EGENHOFER, M.; FRANZOSA, R. Point-Set Topological Spatial Relations. International Journal of Geographical Information Systems, v. 5, n.2, p. 161-174, 1991. ESRI, 2000, Modelling Our World : The ESRI Guide to Geodatabase Design, Redlands, CA. FONSECA, F.; DAVIS, C.; CAMARA, G. Bridging Ontologies and Conceptual Schemas in Geographic Applications Development. Geoinformatica, v. 7, n.4, p. 355-378, 2003. GODIN, L. GIS in Telecommunications. Redlands, CA: ESRI Press, 2001. GINZBURG, C. Olhos de Madeira: Nove Reflexes sobre a Distncia. So Paulo: Companhia das Letras, 2001. GOMES, J.; VELHO, L. Abstraction Paradigms for Computer Graphics. The Visual Computer, v. 11, n.5, p. 227-239, 1995. GROSS, J.; YELLEN, J. Graph Theory and Its Applications. Boca Raton, FL: CRC Press, 1998. GRUBER, T. R. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. Int. Journal of Human-Computer Studies, v. 43, p. 907-928, 1995. HOHL, P. GIS Data Conversion: Strategies, Techniques, and Management. Clifton Park, NY: OnWorld Press, 1998. KRAAK, M.-J.; BROWN, A., eds., 2001, Web Cartography. London, Taylor and Francis. KUHN, W.; FRANK, A., 1991. A Formalization of Metaphors and ImageSchemas in User Interfaces. In: MARK, D.; FRANK, A., eds., Cognitive and Linguistic Aspects of Geographic Space: Dordrecht, Kluwer Academic Publishers, p. 419-434. LI, Z.; ZHU, Q.; GOLD, C. Digital Terrain Modeling: Principles and Methodology. London: Taylor and Francis, 2004. MACEACHREN, A. M. How Maps Work : Representation, Visualization, and Design. New York: Guilford Press, 2004.
Referncias
43
MASSEY, D. S.; DENTON, N. A. American Apartheid: Segregation and the Making of the Underclass. Cambridge: Harvard University Press, 1993. MATHER, P. M. Computer Processing of Remotely-Sensed Images : An Introduction (3rd ed). New York: John Wiley, 2004. MONMONIER, M. Mapping It Out: Expository Cartography for the Humanities and Social Sciences. Chicago: University of Chicago Press, 1993. NOY, N. F.; SINTEK, M.; DECKER, S.; CRUBEZY, M.; FERGERSON, R. W.; MUSEN, M. A. Creating Semantic Web Contents with Protege-2000. IEEE Intelligent Systems, v. 16, n.2, p. 60-71, 2001. OGC, 1998, The OpenGIS Specification Model: The Coverage Type and Its Subtypes, Wayland, MA, Open Geospatial Consortium. PARDINI, R.; SOUZA, S.; BRAGANETO, R.; METZGER, J.-P. The role of forest structure, fragment size and corridors in maintaining small mammal abundance and diversity in an Atlantic forest landscape. Biological Conservation, v. 124, p. 253-266, 2005. RAVADA, S. Topology Management in Oracle Spatial 10g. Dagstuhl Seminar on Computational Cartography and Spatial Modelling, 2003. http://www.dagstuhl.de/03401/Materials/. RICHARDS, J.; EGENHOFER, M. A Comparison of Two DirectManipulation GIS User Interfaces for Map Overlay. Geographical Systems, v. 2, n.4, p. 267-290, 1995. RIGAUX, P.; SCHOLL, M.; VOISARD, A. Spatial Databases with Application to GIS. San Francisco: Morgan Kaufman, 2002. RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W. Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall, 1991. SANTOS, M. Espao e Mtodo. So Paulo: Nobel, 1985. SEARLE, J. R. Rationality and Realism, What is at Stake? Ddalus, v. 122, n.4, 1993. SEARLE, J. R. Mind, Language and Society. New York: Basic Books, 1998. SELLIS, T.; FRANK, A. U.; GRUMBACH, S.; GUTING, R. H.; KOUBARAKIS, M., eds., 2003, Spatio-Temporal Databases: The Chorochronos Approach: Berlin, Springer. SHEKHAR, S.; CHAWLA, S. Spatial Databases: A Tour. New York: Prentice-Hall, 2002.
44
SMITH, B., 2003. Ontology and Information Systems. In: ZALTA, E. N., ed., The Stanford Encyclopedia of Philosophy. The Metaphysics Research Lab, Center for the Study of Language and Information.: Stanford, Stanford University. SMITH, B.; MARK, D. Ontology and Geographic Kinds. In: International Symposium on Spatial Data Handling. Vancouver, Canada, 1998. p. 308320. SPOSATI, A. Mapa de Excluso/Incluso Social de So Paulo. So Paulo: EDUC, 1996. STEVENS, S. S. On the theory of scales of measurement. Science, v. 103, n.2684, p. 677-680, 1946. TOMLIN, C. D. Geographic Information Systems and Cartographic Modeling. Englewood Cliffs, NJ: Prentice-Hall, 1990. TORRES, H. Segregao residencial e polticas pblicas: So Paulo na dcada de 1990 (Spatial segregation and public policies: So Paulo in the 1990s). Revista Brasileira de Cincias Sociais (Brazilian Social Sciences Journal), v. 54, p. 41-56, 2004. TUFTE, E. The Visual Display of Quantitative Information. Chesire, CT: Graphics Press, 1983. WHITE, M. J. The measurement of spatial segregation. American Journal of Sociology, v. 88, p. 1008-1018, 1983. WORBOYS, M. F.; DUCKHAM, M. GIS - A Computing Perspective (2nd edition). Boca Raton: CRC Press, 2004.
2 Algoritmos geomtricos e relacionamentos topolgicos

Clodoveu A. Davis Jr. Gilberto Ribeiro de Queiroz
2.1 Introduo Este captulo apresenta uma introduo s principais tcnicas e algoritmos utilizados na implementao das diversas funes de um sistema de gerncia de bancos de dados espaciais (SGDBE), em especial as operaes sobre representaes vetoriais (pontos, linhas e polgonos), que esto subjacentes a situaes tpicas, tais como: Seleo por apontamento, em que um usurio seleciona um determinado objeto atravs da interface grfica; Determinao do relacionamento espacial entre dois objetos, tanto para consultas quanto para o estabelecimento de restries de integridade espaciais no banco de dados; Criao de mapas de distncia (buffer zones) e soluo de problemas de proximidade; Sobreposio e aritmtica de polgonos para operaes de anlise espacial. Essas operaes so alvo de estudo de uma rea da Cincia da Computao conhecida como Geometria Computacional (Preparata e Shamos, 1985), que procura desenvolver e analisar algoritmos e estruturas de dados para resolver problemas geomtricos diversos. Neste particular, tem um ponto importante de contato com a rea de projeto e anlise de algoritmos, uma vez que tambm procura caracterizar a dificuldade de problemas especficos, determinando a eficincia computacional dos algoritmos e usando tcnicas de anlise de complexidade assinttica (Knuth, 1973). Existe tambm uma
44
preocupao em desenvolver solues para problemas clssicos de geometria, construindo estruturas mais apropriadas para a representao geomtrica robusta no ambiente computacional, que tem limitaes conhecidas quanto preciso numrica e a capacidade de armazenamento de dados (Schneider, 1997). 2.2 Definies Em um SGBDE, cada objeto vetorial codificado usando um ou mais pares de coordenadas, o que permite determinar sua localizao. Para entender melhor a maneira como os SGBDE tratam a informao vetorial, so relacionadas a seguir algumas definies fundamentais (Davis Jr., 1997). Como na maioria dos SGBDE, as definies consideram apenas duas dimenses. Ponto: um ponto um par ordenado (x, y) de coordenadas espaciais. Reta e segmento de reta: Sejam p1 e p2 dois pontos distintos no plano. A combinao linear . p1 + ( 1 ) p2 , onde qualquer nmero real, uma reta no plano. Quando 0 1 , se tem um segmento de reta no plano, que tem p1 e p2 como pontos extremos. A definio de reta e segmento estritamente geomtrica, e nos interessa uma definio mais aplicada. Assim, partimos para o conceito de linha poligonal, que composta por uma seqncia de segmentos de reta. O mais comum, no entanto, definir a linha poligonal atravs da seqncia dos pontos extremos de seus segmentos, ou seja, seus vrtices. Linha poligonal: Sejam v 0 , v1 ,K , v n 1 n pontos no plano. Sejam
s0 = v 0 v1 , s1 = v1v 2 ,K , sn 2 = v n 2 v n 1 uma seqncia de n - 1 segmentos, conectando estes pontos. Estes segmentos formam uma poligonal L se, e somente se, (1) a interseo de segmentos consecutivos apenas o ponto extremo compartilhado por eles (i.e., si si +1 = vi +1 ), (2) segmentos no consecutivos no se interceptam (i.e., si s j = para todo i, j tais que j i + 1 ), e (3) v 0 v n 1 , ou
seja, a poligonal no fechada. Observe, na definio da linha poligonal, a excluso da possibilidade de auto-interseo. Os segmentos que compem a poligonal s se tocam
Definies
45
nos vrtices. Formalmente, poligonais que no obedecem a este critrio so chamadas poligonais complexas. Estas poligonais podem criar dificuldades na definio da topologia e em operaes como a criao de buffers (vide Seo 0). Polgono: Um polgono a regio do plano limitada por uma linha poligonal fechada. A definio acima implica que, apenas invertendo a condio (3) da definio de linha poligonal, temos um polgono. Assim, tambm aqui no permitida a interseo de segmentos fora dos vrtices, e os polgonos onde isto ocorre so denominados polgonos complexos. Os mesmos comentrios que foram feitos para poligonais valem para os polgonos. Observe-se tambm que o polgono divide o plano em duas regies: o interior, que convencionalmente inclui a fronteira (a poligonal fechada) e o exterior. Estas trs entidades geomtricas bsicas podem ser definidas em uma linguagem de programao usando tipos abstratos de dados. Essa definio inclui tipos abstratos para retngulos e para segmentos, que so bastante teis nos testes preliminares de alguns algoritmos geomtricos. No foi definido um tipo abstrato especfico para polgonos, uma vez que correspondem a poligonais em que o primeiro e o ltimo vrtices coincidem. Para as poligonais, foi includa no tipo uma varivel 1 Retngulo, para armazenar os limites do objeto segundo cada eixo .
estrutura Ponto incio inteiro x; inteiro y; fim; estrutura Segmento incio Ponto p1; Ponto p2;
Este retngulo usualmente denominado retngulo envolvente mnimo (REM), e o menor retngulo com lados paralelos aos eixos que contm o objeto em questo.
46
fim;
estrutura Retngulo incio inteiro x1; inteiro y1; inteiro x2; inteiro y2; fim; estrutura Poligonal incio inteiro numPontos; Retngulo retnguloEnvolventeMnimo; Ponto[] vertice; fim;
Programa 2.1 Tipos abstratos de dados para Ponto, Retngulo e Poligonal.
2.3 Algoritmos bsicos Diversos problemas de geometria computacional utilizam resultados bsicos de problemas mais simples em sua soluo. Alguns destes resultados bsicos vm da anlise geomtrica do mais simples dos polgonos, e o nico que sempre plano: o tringulo. 2.3.1 rea de um tringulo A determinao da rea de um tringulo uma das operaes mais bsicas empregadas por outros algoritmos. Ela calculada como a metade da rea de um paralelogramo (Figura 2.1) (Figueiredo e Carvalho, 1991). O produto vetorial dos vetores A e B determina a rea (S) do paralelogramo com os lados A e B e, portanto, a rea do tringulo ABC (que corresponde metade do paralelogramo) pode ser computada a partir da seguinte equao:
xa 1 S = xb 2 xc
ya 1 1 yb 1 = ( xa yb ya xb + ya xc xa yc + xb yc yb xc ) 2 yc 1
(2.1)
Algoritmos bsicos
47
Figura 2.1 rea do tringulo abc.
A Equao 2.1 fornece outra informao muito til para os algoritmos de geometria computacional: a orientao dos trs pontos que formam o tringulo. Caso a rea seja negativa, os pontos a, b e c encontram-se no sentido horrio; se positiva, os pontos encontram-se no sentido antihorrio; e se for zero, indica que os trs pontos so colineares (esto alinhados). 2.3.2 Coordenadas baricntricas Para determinar se um determinado ponto pertence ou no a um tringulo, utiliza-se um mtodo baseado em coordenadas baricntricas (Figueiredo e Carvalho, 1991). De acordo com esse mtodo, cada ponto p do plano pode ser escrito na forma p = 1 p1 + 2 p2 + 3 p3 , onde 1, 2 e 3 so nmeros reais e 1 + 2 + 3 = 1 . Os coeficientes 1, 2 e 3 so denominados coordenadas baricntricas de p em relao a p1, p2 e p3. Os valores de 1, 2 e 3 podem ser obtidos usando a regra de Cramer, e expressos em termos de reas de tringulos cujos vrtices so p, p1, p2 e p3. Temos, portanto: S ( pp2 p3 ) S ( p1 pp3 ) S ( p1 p2 p) , 2 = e 3 = 1 = S ( p1 p2 p3 ) S ( p1 p2 p3 ) S ( p1 p2 p3 ) A anlise do sinal das coordenadas baricntricas indica a regio do plano em que se encontra p, em relao ao tringulo p1p2p3 (Figura 2.2). Observe-se que, para isso, as reas devem ser orientadas, ou seja, com sinal.
48
1>0 2<0 3<0
= 3 0
1>0 2<0 3>0
p1
1=0
1>0 2>0 3<0 1>0 2>0 3>0
p3
2 =0
1<0 2<0 3>0
p2
1<0 2>0 3<0
1<0 2>0 3>0
Figura 2.2 Sinais das coordenadas baricntricas.
2.3.3 Interseo de retngulos Diversos algoritmos de geometria computacional se beneficiam de estratgias de implementao que procuram evitar, tanto quanto possvel, o uso de procedimentos computacionalmente caros. Assim, os problemas so geralmente resolvidos em duas etapas: uma em que a representao geomtrica dos objetos envolvidos simplificada, e outra, executada apenas se necessrio, em que a representao completa empregada. O uso do retngulo envolvente mnimo (REM) uma dessas estratgias. O REM o menor retngulo com lados paralelos aos eixos coordenados que contm a geometria do objeto. Por exemplo, antes de executar o algoritmo de determinao da interseo entre dois polgonos, comparamos seus REM diretamente. Caso os REM tenham alguma interseo, possvel que os polgonos se interceptem, e portanto o algoritmo completo precisa ser executado (Figura 2.3a); caso contrrio, certo que no existe interseo entre os objetos, e portanto a soluo o conjunto vazio (Figura 2.3b).
Algoritmos bsicos
49
Figura 2.3 (a) Interseo dos REMs
(b) REMs disjuntos.
O programa 2.2 ilustra este teste.

funo interseoRetngulos(Ponto A, Ponto B, Ponto C, Ponto D): booleano incio Ponto P, Ponto Q, Ponto P1, Ponto Q1; P.x = min(A.x, B.x); P.y = min(A.y, B.y); Q.x = max(A.x, B.x); Q.y = max(A.y, B.y); P1.x = min(C.x, D.x); P1.y = min(C.y, D.y); Q1.x = max(C.x, D.x); Q1.y = max(C.y, D.y); retorne ((Q.x >= P1.x) e (Q1.x >= P.x) e (Q.y >= P1.y) e (Q1.y >= P.y)); fim.
Programa 2.2 Interseo de retngulos envolventes mnimos.
2.3.4 Interseo de dois segmentos de reta Dados dois segmentos a e b, formados pelos pontos p1p2 e p3p4 (Figura 2.4), respectivamente, deseja-se verificar se eles se interceptam. A soluo consiste em testar se os pontos p1 e p2 esto de lados opostos do segmento formado por p3p4 e tambm se p3 e p4 esto de lados opostos do segmento formado por p1p2. Este problema se conecta com o problema da rea de
50
tringulo, pois, determinar se p3 est do lado oposto de p4 em relao ao segmento p1p2, consiste em avaliar o sinal da rea dos tringulos formados por p1p2p3 e p1p2p4. Se os sinais forem contrrios, significa que os pontos esto de lados opostos. Se o mesmo for verdadeiro para os tringulos p3p4p1 e p3p4p2, ento, com certeza podemos afirmar que as retas que passam pelos segmentos se interceptam em algum ponto, embora no se possa afirmar ainda que os segmentos tm interseo.
Figura 2.4 Segmentos que se interceptam.
Em Saalfeld (1987) discutida uma forma de determinar o ponto de interseo entre dois segmentos baseada na representao paramtrica dos segmentos2. Dados dois segmentos formados pelos pontos p1p2 e p3p4, respectivamente, e com p1 = (x1, y1), p2 = (x2, y2), p3 = (x3, y3) e p4 = (x4, y4), o ponto de interseo entre eles dado por: p1 + u ( p 2 p1 ) = p3 + v( p 4 p3 ) (2.2) Esta igualdade d origem a um sistema com duas equaes e duas incgnitas (u e v):
xint er sec ao = x1 + u( x2 x1 ) ou xint er sec ao = x3 + v( x4 x 3 ) yint er sec ao = y1 + u( y2 y1 ) ou yint er sec ao = y3 + v( y4 y3 )

Desenvolvendo o sistema temos:
(2.3)
A equao paramtrica para um segmento de coordenadas p1 e p2 dada por: p = p1 + u( p2 p1 ) , onde se 0 < u < 1 define um ponto localizado entre p1 e p2.
Algoritmos bsicos
51
u=
( x 4 x3 )( y1 y 3 ) ( y 4 y 3 )( x1 x3 ) ( y 4 y 3 )( x 2 x1 ) ( x 4 x3 )( y 2 y1 ) ( x x1 )( y1 y 3 ) ( y 2 y1 )( x1 x3 ) v= 2 ( y 4 y 3 )( x 2 x1 ) ( x 4 x3 )( y 2 y1 )
(2.4) (2.5)
Calculados os parmetros u e v, podemos determinar o ponto de interseo: xint er sec ao = x1 + u ( x 2 x1 ) ou xint er sec ao = x3 + v( x 4 x3 ) (2.6) yint er sec ao = y1 + u ( y 2 y1 ) ou y int er sec ao = y 3 + v( y 4 y 3 ) As expresses de u e v, respectivamente 2.4 e 2.5, possuem interpretaes importantes. Os denominadores so os mesmos, e, portanto, numa implementao computacional eles devero ser calculados uma nica vez. Se o denominador for zero, as duas linhas so paralelas. Se alm do denominador os numeradores de ambos os parmetros tambm forem zero, ento as duas linhas so coincidentes. Na verdade, as equaes paramtricas aplicam-se a linhas e, portanto, s haver interseo entre os dois segmentos em um ponto localizado sobre ambos, o que significa valores de u e v ambos no intervalo [0,1].
2.3.5 rea de polgonos A rea de um polgono pode ser calculada em tempo linear com relao ao nmero de vrtices, usando um somatrio simples, baseado na soma de reas de tringulos formados entre cada par de vrtices consecutivos e a origem do sistema de coordenadas (O'Rourke, 1998):
1 i = n1 A( P) = ( xi + xi +1 ) ( yi +1 yi ) 2 i =0
(2.7)
Observe que na expresso acima (Equao 2.7), quando se tem i = n - 1, necessrio ter xn = x0 e yn = y0. Como no caso dos tringulos, o sinal da rea obtida de acordo com esta frmula indica a orientao dos vrtices do polgono. Caso o resultado seja positivo, os vrtices esto ordenados no sentido anti-horrio, e caso seja negativo os vrtices encontram-se no sentido horrio.
52
2.3.6 Centride de um polgono O centro de gravidade ou centro de massa, mais conhecido como centride de um polgono pode ser obtido a partir da sua diviso em tringulos, calculando em seguida a mdia ponderada dos centros de gravidade dos tringulos usando suas reas como peso. O centro de gravidade de cada tringulo simplesmente a mdia das coordenadas de seus vrtices, ou seja, para um tringulo ABC: x + x B + xC y + yB + yC xG = A e yG = A 3 3
Embora este processo seja relativamente simples, pressupe-se a implementao de um algoritmo de triangulao de polgonos. Os centrides dos tringulos so combinados usando um processo de mdia ponderada pela rea. Assim, o centride de um polgono formado por dois tringulos T1 e T2, cujos centrides so, respectivamente, (xG1, yG1) e (xG2, yG2) o ponto (xG, yG), onde x S(T ) + xG 2 S(T2 ) y S(T ) + yG 2 S(T2 ) xG = G1 1 yG = G1 1 S(T1 ) + S(T2 ) S(T1 ) + S(T2 ) e o centride do polgono pode ser determinado de maneira incremental, adicionando um tringulo e seu centride por vez e calculando as coordenadas do centride do conjunto. No entanto, existe uma soluo mais simples e independente da triangulao, e que leva em conta tringulos com reas positivas e negativas, como no clculo da rea do polgono. O mesmo processo de mdia ponderada pela rea pode ser usado, considerando todos os tringulos formados entre um ponto fixo, por exemplo (0, 0), e cada par de vrtices sucessivos, (vi, vi+1). Assim, temos que:
Algoritmos bsicos
53
A( P) =
1 n1 ( xi yi +1 yi xi+1 ) 2 i =0
( x
xC =
i =0
n1
i +1
+ xi ) ( xi yi +1 yi xi +1 ) 3 A( P)
(2.8)
( y
yC =
i =0
n1
i +1
+ yi ) ( xi yi +1 yi xi +1 ) 3 A( P)
O resultado pode ser facilmente implementado em um algoritmo com complexidade O(n), que naturalmente pode fornecer ao mesmo tempo a rea do polgono. Mas apesar da simplicidade do processo, no existe garantia de que o centride ser um ponto pertencente ao polgono. Caso seja necessrio encontrar um ponto interno a um polgono simples dado, pode-se utilizar o seguinte processo, que busca precisamente identificar rapidamente uma diagonal do polgono (O'Rourke, 1998): identificar um vrtice convexo vi (por exemplo, o vrtice inferior mais direita) para cada outro vrtice vj do polgono verificar: se vj estiver dentro do tringulo vi-1vivi+1, ento calcular a distncia vivj armazenar vj em q se esta distncia for um novo mnimo ao final do processo, se algum ponto interior a vi-1vivi+1 for encontrado, ento o ponto mdio do segmento qvi interior ao polgono; seno, ento o ponto mdio do segmento vi-1vi+1 (ou mesmo o centride do tringulo vi-1vivi+1) interior ao polgono. Outras definies de centride consideram que o mesmo se situa aproximadamente no centro do polgono (Laurini e Thompson, 1992). O centride pode ser determinado por diversos processos, como o centro do retngulo envolvente mnimo, o centro de um crculo inscrito ou circunscrito ao polgono. Uma forma freqentemente usada para determinar um centride consiste em simplesmente obter a mdia das coordenadas x e y dos vrtices (Figura 2.5).
54
G M
Figura 2.5 Centrides calculados pela mdia (M) e como centro de gravidade (G).
2.4
Ponto em polgono
Uma das operaes mais comuns em um SIG determinar se um ponto est no interior de um polgono. Um dos algoritmos mais populares para soluo deste problema o teste do nmero de cruzamentos entre os segmentos que formam a fronteira do polgono e uma semi-reta (chamada de raio), que parte do ponto testado em qualquer direo (Haines, 1994) (Taylor, 1994). Se o nmero de cruzamentos for par, o ponto encontra-se fora do polgono; se for mpar, encontra-se dentro. A Figura 2.6 ilustra a idia desse teste. Conforme pode ser observado, o raio que parte do ponto Q, que est dentro do polgono, cruza os segmentos da fronteira um nmero mpar de vezes (3 vezes).
Figura 2.6 Ponto em polgono.
Ponto em polgono
55
Apesar da aparente simplicidade desse algoritmo, a sua implementao deve considerar alguns casos particulares (casos degenerados), como: a semi-reta passa por uma aresta do polgono (Figura 2.7a); a semi-reta passa por um vrtice do polgono (Figura 2.7b); o ponto Q est sobre a fronteira do polgono (Figura 2.7c); o ponto Q coincide com um vrtice do polgono (Figura 2.7d).
P
Q
(a)
(b)
(c)
(d)
Figura 2.7 Ponto em polgono: casos degenerados.
Para estes casos, a soluo est em adotar um critrio para a contagem de intersees de modo que: se a reta passa por um vrtice, a interseo deve ser considerada apenas se for o vrtice com maior ordenada do segmento, e ignorada caso contrrio; se a reta passa por um segmento do contorno do polgono, nenhuma interseo deve ser considerada; se o ponto Q pertence a um segmento do contorno (exceto pontos extremos), considerar como uma interseo.
56
O caso em que Q coincide com um vrtice pode ser tratado pelo primeiro critrio. O terceiro critrio faz com que todos os pontos da fronteira sejam considerados como pertencentes ao polgono. Esse algoritmo possui complexidade linear em relao ao nmero de vrtices do polgono. Para uma anlise mais aprofundada do problema, o leitor convidado a ler os trabalhos de Huang e Shih (1997) e Haines (1994).
2.5 Simplificao de poligonais Muitas entidades do mundo real podem ser modeladas como linhas ou, mais genericamente, poligonais3. Essas entidades so freqentes em bases de dados geogrficas, onde correspondem tipicamente a cerca de 80% do volume de dados vetoriais (McMaster e Shea, 1992). Por isso, o problema de simplificao de linhas particularmente importante, sendo estudado intensivamente desde os anos 60, quando ocorreram as primeiras experincias com o uso de instrumentos de transcrio de mapas para o computador, como a mesa digitalizadora. No processo de digitalizao de linhas, freqentemente so introduzidos vrtices em excesso, vrtices que, se descartados, no provocariam uma alterao visual perceptvel na poligonal. Assim, um primeiro objetivo para algoritmos de simplificao de linhas limpar (significativamente, o verbo utilizado em ingls weed, capinar) a poligonal de pontos claramente desnecessrios, do ponto de vista de sua visualizao (Weibel, 1995), mantendo a qualidade de sua aparncia grfica (Peucker, 1975) (Beard, 1991). Outro objetivo o de gerar uma nova verso da linha, mais adequada para a representao do mesmo fenmeno geogrfico em outra escala, menor que a original. Neste caso, est sendo obtida uma generalizao da linha (McMaster, 1992). Em uma extenso deste enfoque, existe o interesse em organizar os vrtices da poligonal de tal forma que seja possvel produzir, dinamicamente, verses generalizadas adequadas para uma escala definida no momento da visualizao (van Oosterom, 1993)
3
Deste ponto em diante, ser utilizado o termo poligonal, em lugar de simplesmente linha, para evitar confuso com a definio geomtrica da linha reta (infinita).
Simplificao de poligonais
57
(van Oosterom e Schenkelaars, 1995), conseguindo portanto gerar mltiplas representaes geomtricas para o mesmo fenmeno sem introduzir dados redundantes. No entanto, a utilizao de mtodos e algoritmos desenvolvidos originalmente apenas pensando na reduo do nmero de vrtices da linha podem no ser adequados para alcanar o objetivo de generalizao (Laurini e Thompson, 1992), em geral por no conseguirem uma boa representao geomtrica4, e portanto devem ser analisados cuidadosamente quanto a este aspecto. Assim, o problema de simplificao de linhas consiste em obter uma representao mais grosseira (formada por menos vrtices, e portanto mais compacta) de uma poligonal a partir de uma representao mais refinada, atendendo a alguma restrio de aproximao entre as duas representaes. Essa restrio pode ser definida de vrias maneiras (Li e Openshaw, 1992), mas em geral alguma medida da proximidade geomtrica entre as poligonais, tais como o mximo deslocamento perpendicular permitido (Figura 2.8a) ou o mnimo deslocamento angular permitido (Figura 2.8b). Na Figura 2.8a, o vrtice 2 ser mantido, uma vez que a distncia entre ele e a reta que passa pelos vrtices 1 e 3 superior permitida. Na Figura 2.8b, o vrtice 3 ser $ menor que o mnimo tolervel. eliminado, uma vez que o ngulo 324 Uma alternativa mais rara a rea entre as poligonais (Figura 2.8c), onde se estabelece um limite para ao deslocamento de rea.
3 2 2 3 4
4 distncia mxima 1 1 ngulo mnimo
(a)
3 2 4
(b)
deslocamento de rea mximo 1
(c)
Figura 2.8 Medidas de proximidade para simplificao de linhas.

4
Para auxiliar na manuteno do aspecto natural da poligonal, existem enfoques que integram algoritmos de simplificao com algoritmos de suavizao.
58
Dentre todas as medidas possveis, a mais utilizada a distncia perpendicular. O conceito de banda de tolerncia, apoiado no clculo de distncias perpendiculares, utilizado em grande parte dos algoritmos de simplificao que sero apresentados a seguir. Um problema eventualmente abordado na literatura a escolha do parmetro de tolerncia (), e sua correlao com a escala da representao simplificada. Um critrio interessante para a determinao da tolerncia o que usa o tamanho do menor objeto visvel em uma determinada escala (Li e Openshaw, 1992). Este tamanho pode ser dado em termos de uma distncia medida no espao de coordenadas do mapa plotado, ou seja, em milmetros do papel, independente da escala utilizada. Assim, definida uma correspondncia linear entre a escala e a tolerncia adotada. Grande parte dos algoritmos de simplificao de poligonais necessita realizar de maneira eficiente clculos de distncia entre um ponto dado e uma reta definida por outros dois pontos. A maneira mais interessante de calcular essa distncia utilizar o produto vetorial, conforme apresentado na Seo 2.3.1, para determinar a rea S do tringulo formado por um ponto A e uma reta definida por outros dois (B e C), de acordo com a equao 2.1. Assim, a distncia do ponto A reta definida pelos pontos B e C pode ser calculada como:
d=
| S| dist ( B, C )
onde dist(B, C) a distncia euclidiana entre os pontos B e C. Embora existam muitos algoritmos de simplificao de linhas, envolvendo variados critrios de aproximao e estratgias de processamento, um deles se destaca pela ampla aceitao. Foi proposto em 1973 por Douglas e Peucker (1973), e reconhecidamente o melhor em termos de preservao das caractersticas da poligonal original (Marino, 1979) (McMaster, 1987).
Procedimento Douglas-Peucker(linha, numvert, tol) Procedimento DP(a, f, tol) incio se ((f - a) == 1) ento retorne; maxd = 0;
maxp = 0; para i = a+1 at f-1 faa incio d = distncia(linha[i], linha[a], linha[f]); se d > maxd ento incio maxd = d; maxp = i; fim se; fim para; se maxd > tol ento incio vrtice maxp selecionado; DP(a, maxp, tol); DP(maxp, f, tol); fim seno retorne; fim; incio vrtice 1 selecionado; vrtice numvert selecionado; DP(1, numvert, tol); fim.
59
Programa 2.3 Algoritmo Douglas-Peucker.
O algoritmo recursivo, e a cada passo processa o intervalo de pontos contido entre um vrtice inicial (chamado de ncora) e um vrtice final (denominado flutuante). estabelecido um corredor de largura igual ao dobro da tolerncia, formando duas faixas paralelas ao segmento entre o ncora e o flutuante (Figura 2.9b), como no algoritmo de Lang. A seguir, so calculadas as distncias de todos os pontos intermedirios ao segmento bsico, ou seja, contidos entre o ncora e o flutuante. Caso nenhuma das distncias calculadas ultrapasse a tolerncia, ou seja, nenhum vrtice fica fora do corredor, ento todos os vrtices intermedirios so descartados. Caso alguma distncia seja maior que a tolerncia, o vrtice mais distante preservado, e o algoritmo reiniciado em duas partes: entre o ncora e o vrtice mais distante (novo flutuante), e entre o vrtice mais distante (novo ncora) e o flutuante. De acordo com este processo, os pontos tidos como crticos para a geometria da linha, a cada passo, so mantidos, enquanto os demais so descartados.
60
15 14

15
16
13
17
12 18
11 3 4 2 9 1 5 6 7 8 10 20 22 23 24 25 21
19 29
29
28
1
27 26
tolerncia
(a)
(b)
Figura 2.9 Linha original, 29 vrtices (a) e Douglas-Peucker, primeiro passo: seleo do vrtice 15 (b).
Para a anlise deste algoritmo e dos prximos ser utilizada a poligonal da Figura 2.9a, com 29 vrtices. As figuras seguintes ilustram melhor o comportamento do algoritmo Douglas-Peucker. Inicialmente, so calculadas as distncias dos vrtices 2 a 28 at a reta definida pelos vrtices 1 e 29. O vrtice mais distante nesta primeira iterao o 15, a uma distncia muito superior tolerncia (Figura 2.9b). Assim, o vrtice 15 selecionado e o procedimento chamado recursivamente duas vezes, entre os vrtices 1 e 15 e entre os vrtices 15 e 29. Continuando pela primeira chamada, o vrtice mais distante da reta entre 1 e 15 o 9, tambm a uma distncia superior tolerncia, e portanto selecionado (Figura 2.10a). Duas novas chamadas recursivas so feitas, e agora esto empilhados os intervalos 1-9, 9-15 e 15-29. No intervalo 1-9, temos tambm que preservar o vrtice 3, e portanto ficamos na pilha com os intervalos 1-3, 3-9, 9-15 e 15-29 (Figura 2.10b). Analisando agora o intervalo 1-3, verificamos que o vrtice 2 pode ser dispensado (Figura 2.11a). Ao final, so preservados os vrtices 1, 3, 4, 6, 9, 15, 16, 17, 22, 24, 27 e 29, ou seja, 41% do nmero original de vrtices (Figura 2.11b).
15
15
61
29
29
9 1
1
tolerncia
tolerncia
(a)
(b)
Figura 2.10 Douglas-Peucker, segundo passo: seleo do vrtice 9 (a) e Douglas-Peucker, terceiro passo: seleo do vrtice 3 (b).
15
15
16
17
3 2 29
3 4
29
9 1
22
6
tolerncia
tolerncia
24
(a)
(b)
Figura 2.11 Douglas-Peucker, passo 4: eliminao do vrtice 2 (a) e DouglasPeucker, final (b).
O resultado deste algoritmo aclamado pela literatura como sendo o que mais respeita as caractersticas (ou, como no ttulo do artigo de Douglas e Peucker, a caricatura) da linha cartogrfica (Marino, 1979). Assim, este algoritmo veio a ser a escolha dos desenvolvedores de software comercial na implementao de funes de simplificao de linhas para processamento ps-digitalizao (Li e Openshaw, 1992), ou seja, para limpeza de vrtices desnecessrios. O uso do algoritmo
62
Douglas-Peucker em generalizao, no entanto, comprometido pelo seu comportamento em situaes de generalizao mais radical, ou seja, com tolerncias maiores. Conforme a situao, o algoritmo pode ser levado a escolher vrtices que terminam por deixar a linha com uma aparncia pouco natural, com tendncia a apresentar picos (como no exemplo da Figura 2.11, entre os vrtices 17, 24 e 29), com ngulos agudos e mudanas bruscas de direo.
15
17
29
9 1
24
tolerncia
Figura 2.12 Douglas-Peucker, simplificao radical.
Se a mesma linha da Figura 2.9a for processada novamente com uma tolerncia, por exemplo, quatro vezes maior que a apresentada, seriam preservados apenas os vrtices 1, 9, 15, 17, 24 e 29, todos pertencentes soluo anterior (Figura 2.12). Portanto, o algoritmo de Douglas-Peucker hierrquico, pois os pontos so sempre selecionados na mesma ordem, e a tolerncia serve para determinar at que ponto o processamento deve ser realizado. Se a tolerncia for igual a zero, todos os vrtices sero eventualmente selecionados. O armazenamento das subdivises nos permite representar
63
a hierarquia dos vrtices em uma rvore binria (van Oosterom, 1993). Em cada n desta rvore representado um vrtice selecionado, e armazenado o valor da distncia calculado por ocasio da seleo, que corresponde ao valor maxd do algoritmo (Programa 2.3). Tendo sido estabelecido um valor de tolerncia, basta caminhar na rvore em preordem para determinar quais vrtices sero selecionados. Quando um n interno contiver um valor de distncia inferior tolerncia, o vrtice correspondente e todos os descendentes podero ser eliminados, no sendo necessrio continuar com o caminhamento. Observe-se, no entanto, que a rvore binria pode ser bastante desbalanceada, e dificilmente ser completa, o que vir a dificultar o seu armazenamento no banco de dados.
15
2.632
9
1.614
24
2.705
3
0.750
11
0.213
17
1.094
27
0.514
2
0.177
6
0.894
10
0.070
13
0.267
16
0.354
22
0.256
25
0.247
28
0.078
4
0.371
8
0.224
12
0.224
14
0.100
18
0.238
23
0.108
26
0.054
5
0.250
7
0.094
19
0.062
21
0.044
20
0.028
Figura 2.13 rvore binria formada a partir do exemplo da Figura 2.9 a.
64
2.6 Interseo de conjuntos de segmentos O problema de se determinar os pontos de interseo entre um conjunto de segmentos um dos mais importantes no caso de um SIG que trabalha com representao vetorial. Isso porque operaes como unio, interseo, diferena e as operaes que avaliam o relacionamento topolgico necessitam determinar esses pontos como uma das primeiras etapas de seus processamentos, sendo esta a de maior consumo de processamento. No que segue, so apresentados algoritmos para resoluo deste problema. 2.6.1 Plane sweep Shamos e Hoey (1976) apresentam um dos primeiros trabalhos discutindo o problema de interseo entre objetos com base na anlise de complexidade. Eles fornecem um algoritmo para um problema similar que determinar se, em um conjunto de n segmentos, h pelo menos um par que se intercepte. A idia para soluo desse problema vem da anlise de intervalos em uma dimenso. Considere-se que, em vez de n segmentos, tenha-se n intervalos entre nmeros reais, do tipo [xL, xR], onde x L x R . Uma soluo exaustiva seria analisar todos os n2 pares de intervalos existentes, comparando-os sempre dois a dois, e interrompendo o processamento assim que a primeira interseo fosse detectada. No entanto, uma maneira mais eficiente de resolver o problema construir uma lista ordenada dos valores extremos dos intervalos, tomando o cuidado de identific-los como sendo L ou R, de acordo com sua situao no intervalo. Assim, no haver interseo alguma entre os intervalos se e somente se a lista ordenada contiver uma seqncia alternada de Ls e Rs: L R L R ... L R L R. Em qualquer outra situao, pode-se afirmar que existe superposio entre algum par de intervalos. Esta soluo tem complexidade computacional da ordem de O(n log n), uma vez que dominada pela ordenao dos valores extremos.
Interseo de conjuntos de segmentos
65
(a)
(b)
Figura 2.14 Verificao de interseo em intervalos na reta.
Em duas dimenses, o problema torna-se um pouco mais complicado, j que no existe maneira de produzir uma ordenao adequada para segmentos no plano. A tcnica empregada clssica na geometria computacional, e denominada de varredura do plano (plane sweep). Esta tcnica faz uso de duas estruturas de dados bsicas, uma para registrar a situao da linha de varredura (sweep line status), e a outra que registra eventos ocorridos durante a varredura (event-point schedule). A idia consiste em deslocar uma reta vertical pelo conjunto de segmentos, buscando identificar inverses na ordem em que esta reta encontra dois segmentos quaisquer. Para implementar esta idia, necessrio definir uma nova relao de comparao, da seguinte forma: considere-se dois segmentos s1 e s2 no plano, sendo que s1 no intercepta s2. Diz-se que s1 comparvel a s2 se, para alguma abscissa x, existe uma linha vertical que intercepta tanto s1 quanto s2. Assim, diz-se que s1 est acima de s2 em x se, naquela abscissa, a interseo da reta com s1 est acima da interseo da reta com s2. Esta relao denotada como s1 >x s2. Na Figura 2.15, temos as seguintes relaes: s3 >v s2; s4 >v s3; s4 >v s2; s4 >w s2; s4 >w s3; s2 >w s3.
66
s4
s2
Figura 2.15 Relao de ordenao entre segmentos.
Com esta relao construda uma ordenao total dos segmentos, que muda medida em que a linha deslocada da esquerda para a direita. Nesse processo de varredura do plano, trs coisas podem ocorrer: o ponto extremo esquerda de um segmento encontrado; o segmento , portanto, inserido na ordenao; o ponto extremo direita de um segmento encontrado; o segmento , portanto, retirado da ordenao; um ponto de interseo entre dois segmentos s1 e s2 foi encontrado; portanto, s1 e s2 trocam de posio na ordenao. Observe-se que, para que s1 e s2 possam trocar de posio, necessrio que exista algum x para o qual s1 e s2 so consecutivos na ordenao. O algoritmo usa este fato, testando apenas elementos consecutivos, medida em que novos eventos vo sendo detectados conforme descrito acima. Portanto, necessrio operar duas estruturas de dados no processo. A primeira (sweep line status) a responsvel por manter a ordenao das intersees dos segmentos com a linha de varredura, e usualmente implementada como um dicionrio ou como uma rvore red-black (Cormen et al., 1990). As operaes que o sweep line status deve suportar so insero (insere, complexidade O(log n)), excluso (exclui, tambm O(log n)), e duas funes para determinar qual segmento est imediatamente acima e imediatamente abaixo de um segmento dado na
Interseo de conjuntos de segmentos
67
ordenao (acima e abaixo, O(1)). A segunda estrutura de dados (eventpoint schedule) responsvel por manter a seqncia das abscissas que sero analisadas pela linha de varredura, e implementada como uma fila de prioridades. Deve suportar as clssicas operaes de incluso (insere), retirada do elemento de mais alta prioridade (min) e uma funo que testa a presena de um determinado elemento na estrutura (membro), todas com complexidade O(log n). Inicialmente, as abscissas dos pontos extremos dos segmentos so ordenadas e inseridas no event-point schedule. Em seguida, as abscissas so retiradas a partir da menor, e so realizadas as seguintes operaes: Se a abscissa corresponder a um ponto extremo esquerda de algum segmento, inserir o segmento no sweep line status. Verificar se existem intersees entre este segmento e os segmentos que esto imediatamente acima e abaixo dele na linha de varredura. Caso exista interseo, a abscissa do ponto de interseo deve ser calculada e inserida no event-point schedule, caso j no pertena a ele. Se for um ponto extremo direita, excluir o segmento do sweep line status. Verificar se existem intersees entre os segmentos que esto imediatamente acima e abaixo dele na linha de varredura. Caso exista interseo (que estar necessariamente direita do ponto extremo), a abscissa do ponto de interseo deve ser calculada e inserida no eventpoint schedule, caso j no pertena a ele. Se for um ponto de interseo entre dois segmentos, trocar a posio destes segmentos no sweep line status. Informar a existncia de um ponto de interseo e suas coordenadas. O algoritmo possui complexidade sub-tima, O( n log n + k log n ), onde k o nmero de intersees. Um dos motivos para que ele no atinja o limite inferior de n log n + k que os pontos de interseo so reportados na ordem x, que a ordem na qual eles so inseridos na fila de eventos. A complexidade desse algoritmo depende no s do nmero de segmentos de entrada, mas tambm do nmero de intersees reportadas. Esse algoritmo pertence a uma classe conhecida como algoritmos sensveis sada, sendo apresentado originalmente por Bentley e Ottmann (1979).
68
2.6.2 Algoritmos de interseo por partio do espao Andrews et al. (1994) e Andrews e Snoeyink (1995) apresentam uma comparao entre mtodos advindos da Geometria Computacional, e mtodos desenvolvidos pela comunidade SIG (mtodos pragmticos) para resolver esse problema. Os algoritmos testados por eles foram agrupados em duas categorias: algoritmos por partio espacial e algoritmos por ordenao espacial. Nos algoritmos da primeira classe, o espao subdivido em regies, e os segmentos so atribudos s regies interceptadas por cada um deles. As intersees so computadas entre os segmentos de cada regio, normalmente empregando um algoritmo de fora bruta. A idia a aplicao de heursticas que realizem filtros, diminuindo o nmero de segmentos a serem testados. Os algoritmos agrupados na segunda classe so os baseados em estratgias de Geometria Computacional, onde a preocupao com o desenvolvimento de algoritmos onde a anlise de complexidade de pior caso possua uma boa complexidade. O algoritmo do plane sweep pode ser classificado nesta categoria. Os testes realizados no trabalho deles mostram que embora os algoritmos da primeira classe no garantam uma eficincia no pior caso como os da Geometria Computacional, eles acabam tirando proveito da caracterstica dos dados de um SIG: segmentos curtos, espaados, com poucas intersees por segmento e uniformemente distribudos no plano. Dessa forma, eles acabam sendo mais eficientes (velozes) do que os da segunda classe. Outro trabalho que realiza testes semelhantes apresentado por Pullar (1990), onde mostrado que uma tcnica baseada no Fixed Grid, tambm pertencente categoria dos algoritmos por partio, bastante competitiva em relao aos algoritmos baseados no plane sweep, apesar da complexidade de pior caso ser bem maior, O(n2). Nos trabalhos de Akman et al. (1989), Franklin et al. (1988) e Franklin et al. (1989) apresentado um algoritmo baseado no fixed grid. Dados dois conjuntos de segmentos, um vermelho e outro azul, os segmentos da primeira linha so cobertos por uma grade retangular fixa (fixed grid). Cada segmento vermelho associado s clulas da grade por
Unio, interseo e diferena de polgonos
69
onde ele passa. Os pontos de interseo so determinados procurando para cada segmento azul a lista de clulas por onde ele passa e ento utilizando um algoritmo de fora bruta esses pontos so determinados. Um dos pontos chaves desse algoritmo a determinao da resoluo da grade. Ela pode ser determinada a partir da mdia do comprimento dos segmentos. Franklin et al. (1988) mostram que utilizando-se de parmetros estatsticos, como a mdia do comprimento dos segmentos, a grade se adapta bem aos dados de entrada.
2.7 Unio, interseo e diferena de polgonos Operaes sobre polgonos so de fundamental importncia em SIG. Atravs da deteco e processamento da unio, interseo e diferena de polgonos, diversos tipos de operaes, conhecidas como em conjunto como polygon overlay, so viabilizadas. So operaes fundamentais para anlise espacial, usadas em situaes em que necessrio combinar ou comparar dados colocados em camadas distintas. Por exemplo, considerese uma consulta como identificar fazendas em que mais de 30% da rea de latossolo roxo. Para executar esta anlise, necessrio combinar uma camada de objetos poligonais (os limites de propriedades rurais) com outra (o mapa de tipos de solo), para obter uma nova camada, de cujo contedo podem ser selecionados diretamente os objetos que atendem ao critrio de anlise colocado. Algumas vezes, o polygon overlay definido como uma operao topolgica, ou seja, que executada sobre dados organizados em uma estrutura de dados topolgica. As funes de processamento de polgonos que sero descritas a seguir so utilizadas em sistemas no topolgicos, ou em situaes em que o processamento feito de maneira isolada, como na criao e uso de buffers (vide Seo 0). Para realizar operaes sobre polgonos, interessante aplicar um passo preliminar de deteco rpida da possibilidade interseo entre os polgonos. Assim, se no for possvel que dois polgonos P e Q tenham interseo, ento podemos concluir diretamente que P Q = { P, Q} , P Q = , P Q = P e Q P = Q . Uma maneira simples de testar se dois polgonos tm ou no interseo usar inicialmente o teste de interseo dos retngulos envolventes mnimos (Seo 0).
70
No caso geral, operaes de unio, interseo ou diferena entre dois polgonos simples podem gerar diversos polgonos como resultado. Mais ainda, os polgonos resultantes podero conter buracos. A Figura 2.16 contm exemplos de produo de mltiplos polgonos e de polgonos com buracos em operaes de interseo, unio e diferena.
Figura 2.16 Operaes sobre polgonos produzindo buracos e mltiplos polgonos.
Apresentaremos aqui um mtodo proposto por Margalit e Knott (1989). Esse algoritmo sensvel orientao dos polgonos, e exige que os vrtices de ilhas sejam codificados em um sentido (por exemplo, antihorrio) e os vrtices de buracos sejam dispostos no sentido inverso (horrio). Isto coincide com a conveno usada para calcular a rea de polgonos, conforme apresentado na Seo 2.3.5.
Tabela 2.1 Orientao dos polgonos de acordo com a operao Polgonos Operaes
P Q
P Q
PQ
Q P
Unio, interseo e diferena de polgonos
71
ilha ilha buraco buraco
ilha buraco ilha buraco
manter inverter inverter manter
manter inverter inverter manter
inverter manter manter inverter
inverter manter manter inverter
1.
2.
3.
4.
O algoritmo tem seis passos, que sero descritos a seguir. Normalizar a orientao dos polgonos de entrada P e Q, e inverter a orientao de Q dependendo do tipo de operao e da natureza (ilha ou buraco) dos dois polgonos de entrada, de acordo com a Tabela 2.1. Classificar os vrtices, verificando se cada um est dentro, fora ou na fronteira do outro polgono, usando o teste de ponto em polgono (Seo 2.4). Inserir os vrtices assim classificados em duas listas circulares, PL e QL, onde aparecero em seqncia, de modo a definir as arestas por adjacncia. Encontrar as intersees entre arestas dos dois polgonos, usando o teste de interseo de n segmentos (Seo 0). Inserir os pontos de interseo na posio apropriada em PL e QL, classificando-os como na fronteira. A partir deste ponto, teremos um conjunto de fragmentos de arestas em lugar das arestas originais. necessrio cuidar do caso especial de interseo ao longo de uma aresta comum, ou parte dela. Neste caso, ambos os pontos extremos da aresta devem ser classificados como na fronteira e inseridos nas listas. Classificar os fragmentos de arestas (definidos pelos pares de vrtices) formados em PL e QL com relao ao outro polgono, entre interior, exterior ou na fronteira. No necessrio realizar novamente o teste de ponto em polgono. Uma aresta pode ser considerada interior ao outro polgono caso pelo menos um de seus vrtices esteja classificado como dentro. Da mesma forma, uma aresta pode ser classificada como exterior ao outro polgono caso pelo menos um de seus vrtices esteja classificado como fora. Se ambos os vrtices estiverem classificados como na fronteira, ento necessrio verificar a situao de um ponto interno ao segmento (por exemplo, seu ponto mdio). Se este ponto
72
estiver fora do outro polgono, ento a aresta classificada como exterior. Se o ponto estiver dentro do outro polgono, ento a aresta classificada como interior. Se o ponto estiver na fronteira, a aresta classificada como fronteira. Arestas na fronteira constituem um caso degenerado, que requer tratamento especial. Se existe um fragmento de aresta na fronteira de P, ento necessariamente existe tambm um na fronteira de Q. Estes fragmentos podem estar orientados na mesma direo ou em direes opostas. A implementao pode decidir o que fazer nestes casos, ou seja, se intersees com dimenso de segmento ou de ponto sero ou no retornadas. Se as intersees como segmento forem retornadas, sero formadas por um ciclo de duas arestas sobrepostas, cada uma em uma direo. Interseo em um ponto ser retornada como um ciclo de duas arestas, cada uma em uma direo, ligando dois vrtices sobrepostos. Desta forma preserva-se a topologia do resultado (sempre cadeia fechada de segmentos), mas em SIG mais interessante detectar estes casos e retornar objetos da dimenso adequada (no caso, ponto)5. 5. Selecionar e organizar as arestas para formar os polgonos de resultado. Este processo de seleo baseado na combinao das duas listas em uma, denominada RL, usando apenas as arestas que interessam para a operao, conforme definido na Tabela 2.2. 6. Construir os polgonos de resultado, selecionando uma aresta e, com base em seu ponto final, procurar em RL sua continuao, at fechar o polgono. Repetir o processo, eliminando de RL a cada passo as arestas utilizadas, at que RL fique vazia. Os polgonos resultantes mantero a orientao adotada para ilhas e buracos.
Para uma anlise mais completa, inclusive com as combinaes de hipteses nos casos de ilhas e buracos, vide (Margalit e Knott, 1989).
Mapas de distncia (buffer zones)
73
Tabela 2.2 Tipos de arestas para seleo de acordo com o tipo de operao e os tipos de polgonos de entrada
Polgonos Operaes
P Q
P
ilha ilha buraco buraco
P Q
Q P exterior interior exterior interior Q exterior exterior interior interior P
PQ
Q interior interior exterior exterior P
Q P
Q exterior exterior interior interior
Q
buraco buraco ilha buraco
P interior exterior interior exterior
interior interior exterior exterior
exterior interior exterior interior
interior exterior interior exterior
2.8 Mapas de distncia (buffer zones) Outra operao importante para um SIG a construo de mapas de distncia ou buffer zones, que so reas construdas ao redor de objetos mantendo uma certa distncia. A Figura 2.17 ilustra a idia dessas operaes para pontos, linhas e polgonos respectivamente.
(a)
(b)
Figura 2.17 Buffers elementares ao redor de ponto (a) e segmento (b).
A determinao do buffer ao redor de um ponto feita de forma direta, como uma circunferncia de raio d (Figura 2.17a). O buffer ao redor de uma linha formada pela unio de buffers elementares (Figura 2.17b) definidos para cada segmento da linha. Esses buffers elementares so formados a partir de semicircunferncias traadas nas extremidades dos segmentos (uma em cada extremidade). Utilizando o algoritmo de
74
unio (Seo 2.7) podemos combinar esses buffers at formar o resultado final da linha (Figura 2.18a). O buffer de polgonos (Figura 2.18b) semelhante ao de linha, com a diferena de que possvel gerar buffers negativos (voltados para o interior do polgono).
Figura 2.18 Buffer ao redor de linha (a) e polgono (b).
2.9 Relacionamentos topolgicos A grande importncia da caracterizao dos relacionamentos topolgicos entre estruturas vetoriais poder atribuir um contexto semntico aos algoritmos geomtricos. Para especifica-los, inicialmente definiremos as geometrias vetoriais como elementos do 2, considerado como espao topolgico. Assim, um ponto simplesmente um elemento de 2. Uma linha L um conjunto de pontos conectados. Uma ilha ou linha circular uma linha em que o ponto inicial igual ao ponto final. A fronteira de L, denotada por L, o conjunto dos pontos inicial e final, caso L no seja uma ilha, ou o conjunto vazio, em caso contrrio. O interior de L, denotado por L, composto pelos demais pontos. Uma regio A um conjunto de pontos com um interior conectado, denotado por A, uma fronteira conectada, denotada por A, e um nico exterior conectado, denotado por A-. Assim, as regies consideradas no tm buracos. Os relacionamentos topolgicos podem ser definidos com base em um modelo, chamado matriz de 4-intersees (ver a Figura 2.19), que considera oito relaes topolgicas binrias, representando a interseo
Relacionamentos topolgicos
75
entre a fronteira e o interior de duas geometrias (Egenhofer e Franzosa, 1995). Para definir relacionamentos topolgicos entre geometrias com estruturas mais complexas, como regies com ilhas e separaes, necessrio estender a matriz de 4-Intersees para tambm considerar o exterior de uma geometria (Egenhofer e Herring, 1991). O novo modelo, chamado de matriz de 9-Intersees (ver Figura 2.20), considera ento o resultado da interseo entre as fronteiras, interiores e exteriores de duas geometrias. Maiores detalhes sobre relaes topolgicas entre regies com ilhas podem ser encontrado em (Egenhofer et al., 1994).
A B B B A A
B B B
B B B
B B B
A A meet A B
A A contains B A B B A A inside
A A Covers B A B B A A Covered By
disjoint ABB B B A A equal
B B A A overlap
Figura 2.19 Matriz de 4-Intersees para relaes entre duas regies. Fonte: (Egenhofer et al., 1994).
76
B B BA A A- disjoint ABB B B A A A- equal B-
B B BA A A- meet A B A A A- B B B
B B BA A A- contains B A
B B BA A A- covers B A
overlap
B B BA A A- inside
B B B A A A- covered by
Figura 2.20 Matriz de 9-Intersees para relaes entre duas regies. Fonte: (Egenhofer e Herring, 1991).
Nos modelos citados acima, os resultados das interseces so avaliados considerando os valores vazio ou no-vazio. H vrias situaes em que necessrio considerar as dimenses das intersees no vazias. Por exemplo, certo estado X s considera um outro estado Y como vizinho se eles tm pelo menos uma aresta em comum. Neste caso, para encontrar os vizinhos do estado X, no basta saber quais estados tocam ou so adjacentes a ele, mas sim se o resultado da interseo entre eles uma aresta. Para acomodar estas situaes, novos modelos foram definidos, levando em considerao as dimenses dos resultados das intersees no vazias, como o modelo para relaes topolgicas binrias detalhadas (Egenhofer, 1993), baseado na matriz de 4-intersees, e a matriz de 9Intersees estendida dimensionalmente (DE-9IM), baseada na matriz de 9-intersees (Paiva, 1998). Clementini et al. (1993) estenderam a abordagem da matriz de 4intersees de forma a incluir a informao da dimenso da interseo. No espao bidimensional, a dimenso da interseo pode ser vazia, um ponto, uma linha ou uma regio. Este modelo contempla assim um conjunto de 52 relacionamentos topolgicos, o que no conveniente do ponto de vista do usurio. Para equacionar este problema, os
Relacionamentos topolgicos
77
relacionamentos topolgicos foram agrupados em cinco mais gerais touch, in, cross, overlap, disjoint que so sobrecarregados, ou seja, que podem ser usados indistintamente para ponto, linha e regio. Estes relacionamentos so definidos da seguinte forma: touch: aplica-se a pares de geometrias dos tipos regio/regio, linha/linha, linha/regio, ponto/regio e ponto/linha:
o o 1 , touch, 2 (1 2 =0 /) o o 0 2 0 ((1 2 / ) (1 / ) (1 2 0 / ))
in:
aplica-se a pares de geometrias com qualquer combinao de tipos:

o o o 1 , in, 2 (1 2 0 / ) (1 / ) (1 /) 2 =0 2 =0
cross:
aplica-se a pares de geometrias dos tipos linha/linha e linha/regio. No caso de linha/regio, temos:
L, cross, R ( Lo R o 0 / ) ( Lo R 0 /)
No caso de linha/linha, temos:

o L1 , cross , L2 dim( L1 Lo 2) = 0
overlap: aplica-se a pares de geometrias dos tipos regio/regio e linha/linha. No caso de regio/regio, temos:
A1 , overlap, A2 ( A1o A2o 0 / ) ( A1o A2 0 /)
( A1 A2o 0 /)
No caso de linha/linha, temos:
o o L1 , overlap, L2 (dim( L1 Lo /) 2 ) = 1) ( L1 L2 0
( L1 Lo /) 2 0
disjoint: aplica-se a pares de geometrias com qualquer combinao de tipos:

o o o 1 , disjoint, 2 (1 2 =0 =0 / ) (1 2 /) o (1 2 = 0 / ) (1 2 = 0 /)
78
2.10 Determinao do relacionamento topolgico Nesta seo apresentaremos um algoritmo simples para a determinao dos relacionamentos topolgicos entre dois polgonos (A e B), segundo a matriz de 9-Intersees (descrita na seo anterior). Ele utiliza uma combinao dos algoritmos geomtricos apresentados anteriormente para determinar as intersees entre interior, fronteira e exterior dos dois polgonos. O algoritmo possui seis etapas, que esto descritas a seguir e so ilustradas na Figura 2.21. 1. Avaliar o relacionamento entre os REM dos polgonos A e B. Nessa avaliao podemos empregar as estratgias apresentadas por Clementini et al. (1994) que consiste basicamente no estabelecimento de um mapeamento entre os relacionamentos topolgicos dos REMs e das geometrias exatas. No caso, por exemplo, de dois polgonos A e B que estejam sendo testados para ver se A contm B, podemos rapidamente descartar essa possibilidade caso o REM de A no contenha o REM de B. Caso contrrio vamos prxima etapa; 2. Determinar os pontos de interseo entre os dois polgonos. Isso pode ser feito utilizando algum dos algoritmos apresentados na Seo 0. Esta etapa nos informa se h ou no interseo entre as fronteiras dos objetos. 3. Se no houve interseo na etapa anterior (etapa 2), ento devemos testar qualquer ponto do polgono A, num teste de ponto em polgono (Seo 2.4), com o polgono B, para determinar a localizao de A em relao a B. Este teste precisa ser feito tambm com um ponto de B em relao a A: a. Se o ponto do polgono A estiver dentro de B ento A encontra-se dentro de B (relacionamento inside). b. Caso contrrio, se o ponto de B estiver dentro de A ento A contm B (relacionamento contains). c. Caso contrrio, os polgonos so disjuntos (relacionamento disjoint). 4. Se houve interseo na etapa 2, devemos realizar a fragmentao da fronteira de A, em relao aos pontos de interseo.
Determinao do relacionamento topolgico
79
5. Depois, verificamos a localizao de cada um dos fragmentos em relao ao polgono B. Podemos utilizar o teste de ponto em polgono, tomando um ponto do fragmento que no esteja na extremidade. 6. Com base na localizao dos fragmentos, as intersees entre fronteiras, interiores e exteriores podem ser inferidas: a. Se houve fragmentos dentro e fora do polgono B ento os dois polgonos se sobrepe (relacionamento overlaps); b. Se houve fragmentos somente dentro e na fronteira do polgono B, ento o polgono A coberto pelo polgono B (covered by). c. Se houve fragmentos somente fora e na fronteira do polgono B, temos que decidir se os polgonos se tocam ou se A cobre B. Isso pode ser feito fragmentando a fronteira do polgono B, como na etapa 4 e testando a localizao dos fragmentos de B em relao a A (etapa 5). Se houver fragmentos dentro de A, ento A cobre B (relacionamento covers) seno A toca B (relacionamento touches). d. Se todos os fragmentos encontram-se na fronteira de B, ento os polgonos so iguais (relacionamento equals).
80
Figura 2.21 Determinao do relacionamento topolgico.
Referncias
81
Referncias
AKMAN, V.; FRANKLIN, W. R.; KANKANHALLI, M.; NARAYANASWAMI, C. Geometric computing and uniform grid technique. Computer-Aided Design, v. 21, n. 7, p. 410-420, set. 1989. ANDREWS, D. S.; SNOEYINK, J. Geometry in GIS is not combinatorial: segment intersection for polygon overlay. In: Annual Symposium on Computational Geometry, 11., 1995, Vancouver. Proceedings. Canada: British Columbia, 1995, p. 424-425. ANDREWS, D. S.; SNOEYINK, J.; BORITZ, J. CHAN, T.; DENHAM, G.; HARRISON, J.; ZHU, C. Further comparison of algorithms for geometric intersection problems. In: International Symposium on Spatial Data Handling, 6., 1994, Edinburgh. Proceedings. Edinburgh: Taylor and Francis, 1994, p. 709-724. BEARD, K.; Theory of the cartographic line revisited: implications for automated generalization. In: Cartographica. 1991. v. 28, cap. 4, p. 32-58. BENTLEY, J. L.; OTTMANN, T. A. Algorithms for reporting and counting geometric intersections. IEEE Transactions on Computers, v. C-28, n. 9, p. 643-647, set. 1979. CLEMENTINI, E.; DI FELICE, P.; VAN OOSTEROM, P., 1993. A Small Set of Formal Topological Relationships Suitable for End-User Interaction. In: ABEL, D.; OOI, B. C., eds., SSD '93: Lecture Notes in Computer Science, v. 692: New York, NY, Springer-Verlag, p. 277-295. CLEMENTINI, E.; SHARMA, J.; EGENHOFER, M. Modelling topological spatial relations: strategies for query processing. Computers & Graphics, v. 18, n. 6, p. 815-822, 1994. CORMEN, T. H.; LEISERSON, C. E.; RIVEST, R. L. Introduction to algorithms. E.U.A.: McGraw-Hill, 1990. DAVIS Jr., C.; Uso de vetores em GIS. Fator GIS, v. 21, n. 4, p. 22-23, 1997. DOUGLAS, D. H.; PEUCKER, T. K. Algorithms for the reduction of the number of points required to represent a line or its caricature. The Canadian Cartographer, v. 10, n. 2, p. 112-122, 1973. EGENHOFER, M. A Model for Detailed Binary Topological Relationships. Geomatica, v. 47, p. 261-273, 1993.
82
EGENHOFER, M.; P. DI FELICE; CLEMENTINI, E. Topological Relations between Regions with Holes. International Journal of Geographical Information Systems, v. 8, n.2, p. 129-144, 1994. EGENHOFER, M.; FRANZOSA, R. On the Equivalence of Topological Relations. International Journal of Geographical Information Systems, v. 9, n.2, p. 133-152, 1995. EGENHOFER, M.; HERRING, J. Categorizing Binary Topological Relationships Between Regions, Lines, and Points in Geographic Databases. Orono, ME: Department of Surveying Engineering, University of Maine, 1991. FIGUEIREDO, L. H.; CARVALHO, P. C. P. Introduo geometria computacional. Rio de Janeiro: IMPA, 1991. FRANKLIN, W. R.; CHANDRASEKHAR, N.; Kankanhalli, M.; Seshan, M.; Akman, V. Efficiency of uniform grids for intersection detection on serial and parallel machines. In: Computer Graphics International, maio, 1988, Geneva, Switzerland. Proceedings. Berlin Heidelberg: Springer-Verlag, 1988, p. 51-62. FRANKLIN, W. R.; CHANDRASEKHAR, N.; KANKANHALLI, M.; SUN, D.; ZHOU, M.; WU, P. YF Uniform grids: a technique for intersection detection on serial and parallel machines. In: Auto Carto 9, Baltimore, Mariland. Proceedings. Baltimore, Maryland: American Congress on Surveying and Mapping, 1989, p. 100-109. HAINES, E. Point in polygon strategies. In: HECKBERT, P. S. (Org.). Graphics gems IV. Boston, E.U.A.: Academic Press, 1994. p. 24-46. HUANG, C.; SHIH, T. On the complexity of point-in-polygon algorithms. Computers & Geosciences. v. 23, n. 1, p. 109-118, 1997. KNUTH, D. E. The art of computer programming, vol. 1: fundamental algorithms. Boston, Massachusetts: Addison-Wesley, 1973. LAURINI, R.; THOMPSON, D. Fundamentals of spatial information systems. : Academic Press, 1992. LI, Z.; OPENSHAW, S. Algorithms for automated line generalization based on a natural principle of objective generalization. International Journal of Geographic Information Systems, v. 6, n. 5, p. 373-389, 1992. MARGALIT, A.; KNOTT, G. D. An algorithm for computing the union, intersection or difference of two polygons. Computers & Graphics, v. 13, n. 2, p. 167-183, 1989.
Referncias
83
MARINO, J. S.; Identification of characteristic points along naturally occurring lines: an empirical study. The Canadian Cartographer, v. 16, n. , p. 70-80, 1979. MCMASTER, R. B.; SHEA, K. S. Generalization in digital cartography. Association of American Geographers, 1992. O'ROURKE, J.. Computacional geometry in C. Cambridge: Cambridge University Press, 1998. PAIVA, J. A. C. Topological Equivalence and Similarity in MultiRepresentation Geographic Database. University of Maine,1998. PEUCKER, T. K.; A theory of the cartographic line. In: International yearbook of cartography. 1975. cap. 16, p. 134-143. PREPARATA , F. P.; SHAMOS , M. I. Computational geometry an introduction. New York: Springer-Verlag, 1985. PULLAR, D. Comparative study of algorithms for reporting geometrical intersections. In: International Symposium on Spatial Data Handling, 4., 1990, Zurich. Proceedings Edinburgh: Taylor and Francis, 1990, p. 66-76. SAALFELD, A. It doesn't make me nearly as CROSS - some advantages of the point-vector representation of line segments in automated cartography. International Journal of Geographical Information Systems, v. 1, n. 4, p. 379-386, 1987. SCHNEIDER, M. Spatial data types for database systems. Berlin Hidelberg: Springer-Verlag, 1997. SHAMOS, M. I.; HOEY, D. Geometric intersection problems. In: Annual IEEE Symposium on Foundations of Computer Science, 17., oct. 1976, Houston, Texas. Proceedings. New York: IEEE, 1976, p. 208-215. TAYLOR, G. E.; Point in Polygon Test. Survey Review, v. 32, n. 254, p. 479484, 1994. VAN OOSTEROM, P.; Reactive data structures for geographic information systems. : Oxford University Press, 1993. VAN OOSTEROM, P.; SCHENKELAARS, V. The development of an interactive multi-scale GIS. International Journal of Geographical Information Systems, v. 9, n. 5, p. 489-507, 1995. WEIBEL, R.; Map generalization in the context of digital systems. Cartography and Geographic Information Systems, v. 22, n. 4, p. 3-10, 1995.
3 Modelagem conceitual de dados geogrficos

Karla A. V. Borges Clodoveu A. Davis Jr. Alberto H. F. Laender
3.1 Introduo Este captulo apresenta recursos para a modelagem de dados geogrficos, apoiados principalmente no modelo OMT-G. Inicialmente, resume um pouco do histrico dos modelos de dados geogrficos e discute os nveis de abstrao usuais para aplicaes geogrficas. Em seguida, descreve o modelo OMT-G, apresenta classes de restries de integridade espaciais, e introduz um algoritmo de mapeamento de esquemas OMT-G para esquemas fsicos, considerando o padro OpenGIS para representao de objetos. Por fim, apresenta um exemplo de modelagem e tece algumas consideraes finais. Um modelo de dados um conjunto de conceitos que podem ser usados para descrever a estrutura e as operaes em um banco de dados (Elmasri e Navathe, 2004). O modelo busca sistematizar o entendimento que desenvolvido a respeito de objetos e fenmenos que sero representados em um sistema informatizado. Os objetos e fenmenos reais, no entanto, so complexos demais para permitir uma representao completa, considerando os recursos disposio dos sistemas gerenciadores de bancos de dados (SGBD) atuais. Desta forma, necessrio construir uma abstrao dos objetos e fenmenos do mundo real, de modo a obter uma forma de representao conveniente, embora simplificada, que seja adequada s finalidades das aplicaes do banco de dados. A abstrao de conceitos e entidades existentes no mundo real uma parte importante da criao de sistemas de informao. O sucesso de
84
qualquer implementao em computador de um sistema de informao dependente da qualidade da transposio de entidades do mundo real e suas interaes para um banco de dados informatizado. A abstrao funciona como uma ferramenta que nos ajuda a compreender o sistema, dividindo-o em componentes separados. Cada um desses componentes pode ser visualizado em diferentes nveis de complexidade e detalhe, de acordo com a necessidade de compreenso e representao das diversas entidades de interesse do sistema de informao e suas interaes. Os primeiros modelos de dados para as aplicaes geogrficas eram voltados para as estruturas internas dos SIG. O usurio era forado a adequar os fenmenos espaciais s estruturas disponveis no SIG a ser utilizado. Conseqentemente, o processo de modelagem no oferecia mecanismos para a representao da realidade de forma mais prxima ao modelo mental do usurio. Ficava evidente que a modelagem de aplicaes geogrficas necessitava de modelos mais adequados, capazes de capturar a semntica dos dados geogrficos, oferecendo mecanismos de abstrao mais elevados e independncia de implementao. Apesar de toda a expressividade oferecida pelas tcnicas tradicionais de modelagem, dificuldades surgem devido ao fato de que os dados geogrficos possuem aspectos peculiares, particularmente com respeito codificao da localizao espacial e do tempo de observao, bem como em relao ao registro de fatores externos, como sua preciso de obteno. A modelagem do mundo real uma atividade complexa porque envolve a discretizao do espao como parte do processo de abstrao, visando obter representaes adequadas aos fenmenos geogrficos. Os fatores envolvidos nesse processo de discretizao do espao so inmeros. Entre eles citamos: Transcrio da informao geogrfica em unidades lgicas de dados Para Frank e Goodchild (1990), o esquema de uma aplicao geogrfica uma representao limitada da realidade, tendo em vista a natureza finita e discreta da representao nos computadores. Por maior que seja o nvel de abstrao utilizado, a realidade modelada atravs de conceitos geomtricos (Frank, 1992) e, para que esses conceitos sejam implementados em computadores, eles precisam ser formalizados, sendo necessrio um maior nmero de conceitos
Introduo
85
abstratos para descrever os dados, e um maior nmero de operaes apropriadas, que podem ser definidas de modo independente da implementao (Mark e Frank, 1990). Forma como as pessoas percebem o espao O aspecto cognitivo na percepo espacial um dos aspectos que faz com que a modelagem de dados geogrficos seja diferente da modelagem tradicional. Dependendo do observador, de sua experincia e de sua necessidade especfica, uma mesma entidade geogrfica pode ser percebida de diversas formas. Uma escola, por exemplo, poder ser representada usando um ponto (posicionado de forma aproximada), como uma rea (do terreno que ocupa), ou como um conjunto de edificaes, dependendo do observador e do que ele pretende obter com essa representao. A escala de representao exige que a mesma entidade geogrfica possa ser representada por diferentes formas geomtricas, com detalhamento varivel. O uso de mltiplas representaes para a mesma entidade pode ocorrer simultaneamente, usando-se vrias formas geomtricas para uma mesma entidade geogrfica, ou poder ser exclusiva, fazendo com que uma representao seja vlida para visualizao em determinadas circunstncias, como, por exemplo, uma determinada faixa de escalas.
Natureza diversificada dos dados geogrficos Alm de geometria, localizao no espao, informaes associadas e caractersticas temporais, os dados geogrficos ainda podem prover de origens distintas. Dados ambientais, por exemplo, so derivados de dados como topografia, clima e tempo, propriedades do solo, propriedades geolgicas, cobertura da terra, uso da terra, e hidrografia. Alguns desses fenmenos, como elevao e propriedades do solo, variam continuamente sobre o espao (viso de campos). Outros, como montanhas e bacias hidrogrficas, podem ser individualizados (viso de objetos). Alguns podem estar em ambas as categorias, dependendo do nvel de detalhe considerado. Existncia de relaes espaciais (topolgicas, mtricas, de ordem e fuzzy) Essas relaes so abstraes que nos ajudam a compreender como no mundo real os objetos se relacionam uns com os outros (Mark e Frank, 1990).
86
3.2 Modelos de dados geogrficos Modelos de dados semnticos e orientados a objetos, tais como ER (Chen, 1976), OMT (Rumbaugh et al., 1991), IFO (Abiteboul e Hull, 1987), UML (Rational Software Corporation, 1997) e outros, tm sido largamente utilizados para a modelagem de aplicaes geogrficas. Apesar da grande expressividade desses modelos, eles apresentam limitaes para a adequada modelagem de aplicaes geogrficas, j que no possuem primitivas apropriadas para a representao de dados espaciais. Modelos de dados para aplicaes geogrficas tm necessidades adicionais, tanto com relao abstrao de conceitos e entidades, quanto ao tipo de entidades representveis e seu inter-relacionamento. Diversas propostas existem atualmente, principalmente focalizadas em estender os modelos criados para aplicaes convencionais, como GeoOOA (Ksters et al., 1997), MODUL-R (Bdard et al., 1996), GMOD (Oliveira et al., 1997), IFO para aplicaes geogrficas (Worboys et al., 1990), GISER (Shekhar et al., 1997), OMT-G (Borges et al., 2001), GeoFrame (Lisboa Filho, 1997), MADS (Parent et al., 1999). Todos esses modelos procuram refletir melhor as necessidades de aplicaes geogrficas. A escolha de um deles pode ser feita observando as necessidades de modelagem quanto abstrao de conceitos geogrficos, ao atendimento de requisitos usuais para modelos de dados (como clareza e facilidade de uso) (Borges et al., 2001), e possibilidade de mapeamento dos esquemas produzidos para a implementao em SGBD espaciais, o que inclui a necessria identificao de restries de integridade espaciais (Borges et al., 2002) (Davis Jr. et al., 2005). 3.3 Nveis de abstrao de dados geogrficos Modelos de dados so classificados de acordo com o nvel de abstrao empregado. Para aplicaes geogrficas, so considerados quatro nveis distintos de abstrao: Nvel do mundo real Contm os fenmenos geogrficos reais a representar, como rios, ruas e cobertura vegetal.
Nveis de abstrao de dados geogrficos
87
Nvel de representao conceitual Oferece um conjunto de conceitos formais com os quais as entidades geogrficas podem ser modeladas da forma como so percebidas pelo usurio, em um alto nvel de abstrao. Neste nvel so definidas as classes bsicas, contnuas ou discretas, que sero criadas no banco de dados. Essas classes esto associadas a classes de representao espacial, que variam de acordo com o grau de percepo que o usurio tem sobre o assunto. Essa preocupao no aparece com freqncia nas metodologias tradicionais de modelagem de dados, uma vez que as aplicaes convencionais raramente precisam lidar com aspectos relativos representao espacial (nica ou mltipla) de objetos. Nvel de apresentao Oferece ferramentas com as quais se pode especificar os diferentes aspectos visuais que as entidades geogrficas tm de assumir ao longo de seu uso em aplicaes. Nvel de implementao define padres, formas de armazenamento e estruturas de dados para implementar cada tipo de representao, os relacionamentos entre elas e as necessrias funes e mtodos. O modelo OMT-G, descrito a seguir, atua nos nveis de representao conceitual e apresentao. No nvel de implementao, situam-se as linguagens de definio de dados associadas a SGBD espaciais. Apresentaremos mais adiante um algoritmo de mapeamento entre esquemas OMT-G e estruturas fsicas, definidas pelo padro OpenGIS, conforme implementadas no SGBD Oracle Spatial.
Nvel do mundo real
Nvel de representao
Nvel de apresentao
Nvel de implementao
Figura 3.1 Nveis de abstrao de aplicaes geogrficas. Fonte: adaptado de (Borges et al., 2001).
88
3.4
Modelo de dados OMT-G
3.4.1 Viso geral do modelo O modelo OMT-G parte das primitivas definidas para o diagrama de classes da Unified Modeling Language (UML) (Rational Software Corporation, 1997), introduzindo primitivas geogrficas com o objetivo de aumentar a capacidade de representao semntica daquele modelo e, portanto reduzindo a distncia entre o modelo mental do espao a ser modelado e o modelo de representao usual. Portanto, o modelo OMTG prov primitivas para modelar a geometria e a topologia dos dados geogrficos, oferecendo suporte a estruturas topolgicas todo-parte, estruturas de rede, mltiplas representaes de objetos e relacionamentos espaciais. Alm disso, o modelo permite a especificao de atributos alfanumricos e mtodos associados para cada classe. Os principais pontos do modelo so sua expressividade grfica e sua capacidade de codificao, uma vez que anotaes textuais so substitudas pelo desenho de relacionamentos explcitos, que denotam a dinmica da interao entre os diversos objetos espaciais e no espaciais. O modelo OMT-G baseado em trs conceitos principais: classes, relacionamentos e restries de integridade espaciais. Classes e relacionamentos definem as primitivas bsicas usadas para criar esquemas estticos de aplicao. OMT-G prope o uso de trs diferentes diagramas no processo de desenvolvimento de uma aplicao geogrfica. O primeiro e mais usual o diagrama de classes, no qual todas as classes so especificadas junto com suas representaes e relacionamentos. A partir do diagrama de classes possvel derivar um conjunto de restries de integridade espaciais, que deve ser observado na implementao. Quando o diagrama de classes especifica mltiplas representaes ou a derivao de uma classe a partir de outra, necessrio desenvolver um diagrama de transformao. Nele todo o processo de transformao pode ser especificado, permitindo a identificao dos mtodos necessrios para a implementao. Finalmente, para especificar as alternativas de visualizao que cada representao pode assumir, necessrio
89
desenvolver um diagrama de apresentao. As primitivas para cada um desses diagramas so detalhadas nas prximas sees. A identificao de restries de integridade espacial uma atividade importante no projeto de uma aplicao, e consiste na identificao de condies que precisam ser garantidas para que o banco de dados esteja sempre ntegro. Os principais tipos de restries de integridade, que ocorrem freqentemente na modelagem de banco de dados convencionais, so restries de domnio, de chave, de integridade referencial e de integridade semntica (Elmasri e Navathe, 2004). Cockcroft (1997) estende essa classificao com o objetivo de abranger as peculiaridades dos dados espaciais, incluindo restries topolgicas, semnticas e definidas pelo usurio. Restries de integridade topolgicas consideram as propriedades geomtricas e as relaes espaciais dos objetos. Existem vrios estudos tericos dos princpios que formalmente definem os relacionamentos espaciais (Egenhofer e Franzosa, 1991). Esses princpios podem ser aplicados entre entidades para prover a base do controle de integridade. As restries de integridade semnticas dizem respeito ao significado implcito s feies geogrficas; um exemplo desta restrio uma regra que impede que edifcios sejam interceptados por trechos de logradouro. As restries de integridade definidas pelo usurio permitem manter a consistncia do banco de dados atuando como regras de negcio. Um exemplo do uso desta restrio na localizao de postos de gasolina, os quais, por razo legal, precisam estar a pelo menos 200 metros de distncia de qualquer escola. Restries definidas pelo usurio podem ser armazenadas e garantidas por um repositrio ativo. As primitivas dos diagramas de classe, transformao e apresentao so apresentadas a seguir. 3.4.2 Diagrama de classes No OMT-G o diagrama de classes usado para descrever a estrutura e o contedo de um banco de dados geogrfico. Ele contem elementos especficos da estrutura de um banco de dados, em especial classes de objetos e seus relacionamentos. O diagrama de classes contem apenas regras e descries que definem conceitualmente como os dados sero estruturados, incluindo a informao do tipo de representao que ser
90
adotada para cada classe. Por esta razo, o diagrama de classe o produto fundamental do nvel de representao conceitual (Figura 3.1). A seguir esto descritas as primitivas do modelo OMT-G que so usadas para criar o diagrama de classes para as aplicaes geogrficas. Classes As classes definidas pelo modelo OMT-G representam os trs grandes grupos de dados (contnuos, discretos e no-espaciais) que podem ser encontrados nas aplicaes geogrficas, proporcionando assim, uma viso integrada do espao modelado. Suas classes podem ser georreferenciadas ou convencionais. A distino entre classes convencionais e georreferenciadas permite que aplicaes diferentes compartilhem dados no espaciais, desta forma facilitando o desenvolvimento de aplicaes integradas e a reutilizao de dados. A classe georreferenciada descreve um conjunto de objetos que possuem representao espacial e esto associados a regies da superfcie da terra (Cmara, 1995), representando a viso de campos e de objetos. A classe Convencional descreve um conjunto de objetos com propriedades, comportamento, relacionamentos, e semntica semelhantes, e que possuem alguma relao com os objetos espaciais, mas que no possuem propriedades geomtricas. As classes georreferenciadas so especializadas em classes do tipo geocampo e geo-objeto. Classes geo-campo representam objetos e fenmenos distribudos continuamente no espao, correspondendo a variveis como tipo de solo, relevo e geologia (Cmara, 1995). Classes geo-objeto representam objetos geogrficos particulares, individualizveis, associados a elementos do mundo real, como edifcios, rios e rvores. As classes covencionais so simbolizadas exatamente como na UML. As classes georreferenciadas so simbolizadas no modelo OMT-G de forma semelhante (Figura 3.2a), incluindo no canto superior esquerdo um retngulo que usado para indicar a forma geomtrica da representao. Em ambos os casos, smbolos simplificados podem ser usados. Os objetos podem ou no ter atributos no espaciais associados, listados na seo central da representao completa. Mtodos ou operaes so especificados na seo inferior do retngulo.
91
O modelo OMT-G apresenta um conjunto fixo de alternativas de representao geomtrica, usando uma simbologia que distingue geoobjetos e geo-campos (Figura 3.3 e Figura 3.4).
Nome da classe Atributos Operaes Nome da classe
Classe georreferenciada
Nome da classe
Classe convencional
Atributos Operaes
Nome da classe
(a) representao completa
(b) representao simplificada
Figura 3.2 Notao grfica para as classes do modelo OMT-G.
O modelo OMT-G define cinco classes descendentes de geo-campo: isolinhas, subdiviso planar, tesselao, amostragem e malha triangular (triangulated irregular network, TIN) (Figura 3.3), e duas classes descendentes de geo-objeto: geo-objeto com geometria e geo-objeto com geometria e topologia (Figura 3.4).
Rede triangular irregular Temperatura Isolinhas Curvas de nvel Tesselao Imagem LANDSAT Atributos Grficos Atributos Amostras Pontos cotados Atributos Grficos Atributos
Subdiviso planar Pedologia
Figura 3.3 Geo-campos.
A classe geo-objeto com geometria representa objetos que possuem apenas propriedades geomtricas, e especializada em classes: Ponto, Linha e Polgono. Como exemplo citamos, respectivamente, rvore, meiofio e edificao (Figura 3.4). A classe geo-objeto com geometria e topologia representa objetos que possuem, alm das propriedades
92
geomtricas, propriedades de conectividade topolgica, sendo especificamente voltadas para a representao de estruturas em rede, tais como sistemas de abastecimento de gua ou fornecimento de energia eltrica. Essas propriedades esto presentes em classes descendentes que representam ns e arcos, da forma usualmente adotada na teoria dos grafos. Os arcos podem ser unidirecionais, como em redes de esgoto, ou bidirecionais, como em redes de telecomunicaes. Assim, as especializaes previstas so denominadas n de rede, arco unidirecional e arco bidirecional. Os segmentos orientados traduzem o sentido do fluxo da rede, se unidirecional ou bidirecional, dando mais semntica representao. O foco do modelo OMT-G com respeito a redes no est concentrado na implementao do relacionamento entre seus elementos, mas sim na semntica da conexo entre elementos de rede, que um fator relevante para o estabelecimento de regras que garantam a integridade do banco de dados. Nas aplicaes de rede os relacionamentos do tipo conectividade e adjacncia so fundamentais. Alguns SIG oferecem suporte ao armazenamento desses tipos de relacionamentos.
Geo-objetos com geometria
Ponto rvore Linha Meio-fio Polgono Edificao
Geo-objetos com geometria e topologia

Linha unidirecional Trecho de esgoto Linha bidirecional Tubulao de gua N de rede Cruzamento
Figura 3.4 Geo-objetos.
93
Relacionamentos Um problema existente na maioria dos modelos de dados o fato deles ignorarem a possibilidade de modelagem dos relacionamentos entre fenmenos do mundo real (Oliveira et al., 1997). Considerando a importncia das relaes espaciais e no espaciais na compreenso do espao modelado, o modelo OMT-G representa trs tipos de relacionamentos entre suas classes: associaes simples, relacionamentos topolgicos em rede e relacionamentos espaciais. A discriminao de tais relacionamentos tem o objetivo de definir explicitamente o tipo de interao que ocorre entre as classes. Associaes simples representam relacionamentos estruturais entre objetos de classes diferentes, convencionais ou georreferenciadas. Relacionamentos espaciais representam relaes topolgicas, mtricas, de ordem e fuzzy. Algumas relaes podem ser derivadas automaticamente, a partir da forma geomtrica do objeto, no momento da entrada de dados ou da execuo de alguma anlise espacial. Relacionamentos topolgicos so um exemplo dessa possibilidade. Outras relaes no entanto, precisam ser especificadas explicitamente pelo usurio, para permitir que o sistema armazene e mantenha atualizada aquela informao. Estas relaes so chamadas de explcitas (Peuquet, 1984). No modelo OMT-G, associaes simples so indicadas por linhas contnuas, enquanto relacionamentos espaciais so indicados por linhas pontilhadas (Figura 3.5a/b). Isso torna fcil a distino visual entre relacionamentos baseados em atributos alfanumricos e baseados na localizao e forma geomtrica dos objetos. O nome do relacionamento anotado sobre a linha, e uma seta usada para deixar clara a direo de leitura (por exemplo, na Figura 3.5b, l-se lote contm edificao). Os relacionamentos de rede so relacionamentos entre objetos que esto conectados uns com os outros. Relacionamentos de rede so indicados por duas linhas pontilhadas paralelas, entre as quais o nome do relacionamento anotado (Figura 3.5c). Os relacionamentos so em geral especificados entre uma classe de ns e uma classe de arcos, mas estruturas de redes sem ns podem ser definidas, especificando um relacionamento recursivo sobre uma classe de arcos (Figura 3.5d).
94
Edificao

Edificao Proprietrio Lote
Pertence a
Contm
(a) Associao simples
(b) Relacionamento espacial
Segmento de logradouro
Cruzamento Rede viria
Rodovia
Malha rodoviria
(c) Relacionamento de rede arco-n
(d) Relacionamento de rede arco-arco
Figura 3.5 Relacionamentos.
Com base em trabalhos anteriores (Cmara, 1995) (Egenhofer e Franzosa, 1991) (Egenhofer e Herring, 1990), o modelo OMT-G considera um conjunto de relacionamentos espaciais entre classes georreferenciadas. Em (Clementini et al., 1993), um conjunto mnimo de relacionamentos espaciais identificado, compreendendo somente cinco relacionamentos espaciais, a partir dos quais todos os outros podem ser especificados: toca, em, cruza, sobrepe e disjunto. Relacionamentos definidos com base nas matrizes de 4 intersees (Egenhofer e Franzosa, 1991) e de 9 intersees (Egenhofer, 1993) tm sido adotados de forma crescente pelos SIG e SGBD espaciais comerciais. Entretanto, consideramos que, eventualmente, um conjunto maior de relacionamentos necessrio devido a fatores culturais ou semnticos que so familiares para os usurios, incluindo relacionamentos de significado difuso, tais como perto de, ou ao norte de (Goyal, 2000). Alguns relacionamentos s so possveis entre determinadas classes, pois so dependentes da representao geomtrica. Por exemplo, o relacionamento contm pressupe que uma das classes envolvidas seja um polgono. Neste aspecto, as aplicaes tradicionais diferem das geogrficas, onde as associaes entre classes convencionais podem ser feitas livremente, sendo independente de fatores como comportamento geomtrico. O conjunto de conceitos que o usurio tem sobre cada objeto do mundo real sugere uma determinada representao porque existe uma interdependncia entre a representao, o tipo de interpretao e a finalidade que ser dada a cada entidade geogrfica. No modelo OMT-G
95
isto considerado para que sejam estabelecidas as relaes que envolvem classes georreferenciadas. Cardinalidade Os relacionamentos so caracterizados por sua cardinalidade. A cardinalidade representa o nmero de instncias de uma classe que podem estar associadas a instncias da outra classe. A notao de cardinalidade adotada pelo modelo OMT-G (Figura 3.6) a mesma usada na UML (Rational Software Corporation, 1997).
0..* 1
Nome da classe
Nome da classe
Zero ou mais
Exatamente um
Nome da classe
1..*
Nome da classe
0..1
Um ou mais
Zero ou um
Figura 3.6 Cardinalidade.
Generalizao e especializao Generalizao o processo de definio de classes mais genricas (superclasses) a partir de classes com caractersticas semelhantes (subclasses) (Elmasri e Navathe, 2004) (Laender e Flynn, 1994). A especializao o processo inverso, no qual classes mais especficas so detalhadas a partir de classes genricas, adicionando novas propriedades na forma de atributos. Cada subclasse herda atributos, operaes e associaes da superclasse. No modelo OMT-G, as abstraes de generalizao e especializao se aplicam tanto a classes georreferenciadas quanto a classes convencionais, seguindo as definies e a notao propostas na UML, em que um tringulo conecta a superclasse a suas subclasses. (Figura 3.7). Cada generalizao pode ter um discriminador associado, que indica qual
96
propriedade ou caracterstica est sendo abstrada pelo relacionamento de generalizao.
Figura 3.7 - Generalizao/especializao.
Uma generalizao (espacial ou no) pode ser especificada como total ou parcial (Laender e Flynn, 1994; Rational Software Corporation, 1997). Uma generalizao total quando a unio de todas as instncias das subclasses equivale ao conjunto completo de instncias da superclasse. A UML representa a totalidade atravs do uso dos elementos de restrio predefinidos como completo e incompleto, mas no modelo OMT-G foi adotada a notao introduzida em (Laender e Flynn, 1994), na qual um ponto colocado no pice do tringulo para denotar a totalidade (Figura 3.8). Alm disso, o modelo OMT-G tambm adota a notao OMT (Rumbaugh et al., 1991) para os elementos de restrio predefinidos como disjunto e sobreposto da UML, ou seja, em uma generalizao disjunta o tringulo deixado em branco e em uma generalizao sobreposta o tringulo preenchido. Portanto, a combinao de disjuno e totalidade gera quatro tipos de restries aplicveis a generalizao/especializao. A Figura 3.8 apresenta exemplos de cada combinao. Agregao A agregao uma forma especial de associao entre objetos, onde se considera que um deles formado a partir de outros. A notao grfica usada no modelo OMT-G segue a empregada na UML (Figura 3.9). Uma agregao pode ocorrer entre classes convencionais, entre classes
97
georreferenciadas ou entre uma classe convencional e uma classe georreferenciada (Figura 3.10). Quando a agregao ocorre entre classes georreferenciadas, necessrio usar a agregao espacial.
Figura 3.8 Exemplos de generalizao espacial.
Figura 3.9 Agregao na notao UML.
Figura 3.10 Agregao entre uma classe convencional e uma georreferenciada.
98
A agregao espacial um caso especial de agregao na qual so explicitados relacionamentos topolgicos todo-parte (Abrantes e Carapua, 1994) (Ksters et al., 1997). A utilizao desse tipo de agregao impe restries de integridade espacial no que diz respeito existncia do objeto agregado e dos sub-objetos. Alm de o modelo ganhar mais clareza e expressividade, a observao dessas regras contribui para a manuteno da integridade semntica do banco de dados geogrfico. Muitos erros no processo de entrada de dados podem ser evitados, se procedimentos baseados nessas restries forem implementados. A agregao espacial indica que a geometria de cada parte deve estar contida na geometria do todo. No permitida a superposio entre geometria das partes, a geometria do todo deve ser totalmente coberta pela geometria das partes, configurando assim, uma partio do plano ou subdiviso planar (Davis Jr., 2000) (Preparata e Shamos, 1985). A notao para essa primitiva apresentada na Figura 3.11, onde mostra uma situao em que quadras so compostas de lotes, ou seja, as quadras so geometricamente equivalentes unio dos lotes contidos nelas.
Figura 3.11 Agregao espacial (todo-parte).
Generalizao conceitual A generalizao1, no sentido cartogrfico, pode ser definida como uma srie de transformaes que so realizadas sobre a representao da informao espacial, cujo objetivo melhorar a legibilidade e aumentar a facilidade de compreenso dos dados por parte do usurio do mapa. Por exemplo, um objeto do mundo real pode ser diversas representaes espaciais, de acordo com a escala de visualizao. Uma cidade pode ser
1
No se deve confundir a generalizao cartogrfica com a generalizao utilizada como um tipo de abstrao usado nos modelos de dados semnticos e orientados a objetos ELMASRI, R.; NAVATHE, S. Fundamentals of Database Systems. Pearson Education, 2004..
99
representada em um mapa de escala pequena por um ponto, e como um polgono em um mapa de escala maior (Davis Jr. e Laender, 1999). Neste sentido, o termo representao usado no sentido de representao da forma geomtrica do objeto geogrfico. Definir se a representao deve ser simples ou mais elaborada depende da percepo que o usurio tem do objeto correspondente no mundo real, e como essa representao afeta os relacionamentos espaciais que podem ser estabelecidos com outros objetos modelados. Considerando a necessidade de tais relacionamentos, pode haver a demanda para mais de uma representao para um dado objeto. Isso acontece, por exemplo, quando a informao geogrfica precisa ser compartilhada entre diversas aplicaes em um ambiente corporativo (ou cooperativo). Portanto, no desenvolvimento de aplicaes geogrficas, existem situaes em que duas ou mais representaes para um objeto do mundo real precisam coexistir. Isso significa que, dependendo da viso do usurio, necessrio ter formas geomtricas distintas para representar o mesmo objeto geogrfico, com a mesma resoluo e ao mesmo tempo. Alm disso, freqente a necessidade de se representar o mesmo objeto com graus variveis de resoluo e detalhamento, configurando representaes adequadas para diferentes faixas de escalas. A primitiva de generalizao conceitual foi includa no modelo OMTG para registrar a necessidade de representaes diferentes para um mesmo objeto. Nesse tipo de relacionamento, a superclasse no tem uma representao especfica, j que poder ser percebida de maneiras diferentes, conforme especificado nas subclasses. Essas so representadas por formas geomtricas distintas, podendo herdar os atributos alfanumricos da superclasse e ainda possuir atributos prprios. O objetivo permitir a especificao de relacionamentos independentes envolvendo cada alternativa de representao considerada. A generalizao conceitual pode ocorrer em duas variaes: de acordo com a forma geomtrica (Figura 3.12a) ou de acordo com a escala (Figura 3.12b). A variao de acordo com a forma utilizada para registrar a existncia de mltiplas representaes para uma classe, independente de escala. A descrio geomtrica da superclasse deduzida a partir do uso
100
das subclasses. Por exemplo, um rio pode ser percebido como um espao entre suas margens, como um polgono de gua ou como um fluxo (linha direcionada), formando a rede hidrogrfica (Figura 3.12a). A variao de acordo com a escala usada na representao de diferentes aspectos geomtricos de uma classe, cada aspecto corresponde a uma faixa de escalas. Uma cidade pode ser representada por suas fronteiras polticas (um polgono) em uma escala maior, e por um smbolo (um ponto) em uma escala menor (Figura 3.12b).
Rio
Forma
Eixo de rio
Margens
rea inundada
Segmento de rio
(a) Variao de acordo com a forma (sobreposto)

Cidade
Escala
Sede municipal
Fronteiras municipais
(b) Variao de acordo com a escala (disjunto)
Figura 3.12 - Generalizao conceitual.
Uma estrutura como a apresentada na Figura 3.12 rara em esquemas de aplicaes geogrficas, porque as decises quanto modelagem de so freqentemente (e erroneamente) tomadas j pensando na apresentao final, conforme exigido pela aplicao que est sendo modelada. Ou seja, o esquema muitas vezes concebido visando
101
um tipo especfico de visualizao, antecipando uma exigncia da aplicao. Esta tendncia acaba por inibir usos que exijam representaes alternativas, ou aplicaes que compartilhem dados geogrficos (Davis Jr., 2000). 3.4.3 Diagrama de transformao O diagrama de transformao, proposto para o modelo OMT-G em (Davis Jr. e Laender, 1999), adota uma notao semelhante proposta na UML para os diagramas de estados e de atividades (Rational Software Corporation, 1997), e usado para especificar transformaes entre classes. Como tanto a origem quanto o resultado das transformaes so sempre as representaes de cada classe, o diagrama de transformao tambm est no nvel conceitual de representao. Observe que o diagrama de transformao no pretende descrever aspectos dinmicos da aplicao, como a interface com o usurio e a execuo de consultas, restringindo-se manipulao de representaes. Os diagramas de transformao so baseados nas primitivas de classe, conforme definidas para os diagramas de classes. As classes que esto envolvidas em algum tipo de transformao so conectadas por meio de linhas contnuas, com setas que indicam a direo da transformao. Os operadores de transformao (TR) envolvidos e seus parmetros, quando houver, so indicados por meio de texto sobre a linha que indica a transformao. No diagrama de transformao, pode-se indicar se o resultado da transformao precisa ou no ser materializado. Classes resultantes muito simples, ou que so passos intermedirios em uma transformao mais complexa, freqentemente no precisam ser materializadas, e podem ser armazenadas apenas temporariamente. Tais classes temporrias so indicadas usando linhas tracejadas em seu contorno. As classes que so resultantes de alguma transformao e que precisam ser materializadas (devido complexidade do processo ou s necessidades especficas da aplicao) so denotadas com linhas contnuas, exatamente como no diagrama de classes. As transformaes indicadas no diagrama de classes podem relacionar qualquer nmero de classes originais, bem como qualquer nmero de classes resultantes, dependendo da natureza da operao de
102
transformao. Cadeias de transformaes tambm podem ser definidas, permitindo, dessa forma, a especificao de processos complexos de anlise espacial. Um operador de transformao adequado para o diagrama de transformao pode ser basicamente qualquer algoritmo que manipula e modifica a representao de um objeto. Algumas operaes podem ser melhor caracterizadas como operaes TR quando existe apenas uma classe de origem e uma classe resultante, e a classe resultante ou (1) de natureza diferente da classe original (ou seja, pertence a uma classe georreferenciada diferente), ou (2) menos detalhada que a classe original, mantendo a natureza da representao (Davis Jr. e Laender, 1999). A especificao de transformaes no diagrama de transformao em geral exigida quando as primitivas de generalizao conceitual e de agregao espacial so usadas no diagrama de classes. Essas duas primitivas so indicativas da possibilidade de produzir uma representao a partir de outras. Um estudo das possveis transformaes entre representaes de geoobjetos e geo-campos pode ser visto em (Davis Jr., 2000) (Davis Jr. e Laender, 1999). Os operadores aplicados para cada transformao so baseados em algoritmos definidos nas reas de geometria computacional, generalizao cartogrfica e anlise espacial. A Seo 3.7 traz um exemplo do uso de diagramas de transformao. 3.4.4 Diagrama de apresentao O diagrama de apresentao para o modelo OMT-G pertence ao nvel de apresentao. Em contraste com o conceito de representao, o termo apresentao usado no sentido de determinar o aspecto visual ou grfico (envolvendo parmetros como cor, tipo de linha, espessura da linha e padro de hachura), de geo-objetos e geo-campos, no papel ou na tela do computador. No diagrama de apresentao esto reunidos os requisitos definidos pelo usurio quanto s alternativas de apresentao e sada para cada objeto geogrfico. Essas alternativas podem incluir apresentaes criadas especificamente para visualizao em tela, para impresso na forma de
103
mapas ou cartas, para interpretao visual em um processo de anlise, e outras. Cada apresentao definida a partir de uma representao contida no diagrama de classes ou no diagrama de transformao do nvel de representao. Operaes de transformao para apresentao (TA) so especificadas, permitindo obter o aspecto visual desejado a partir da simples forma geomtrica, definida para a representao. Observe-se que a operao TA no modifica a alternativa de representao definida previamente, nem muda o detalhamento definido no nvel de representao. Se isso for necessrio, uma nova representao tem de ser criada a partir de uma representao existente, usando as ferramentas de especificao de mltiplas representaes (como a primitiva de generalizao conceitual) e registrando essa demanda nos diagramas de classes e de transformao. O diagrama de apresentao necessita de apenas trs primitivas. A primeira a prpria primitiva de classes, definida para os diagramas de classes e de transformao. A segunda usada para indicar a operao TA, de maneira semelhante usada para denotar as transformaes no diagrama de transformao. composta de uma linha tracejada simples, com uma seta que indica o sentido da operao, sobre a qual especificado o operador a ser usado. No processo de especificao dessa expresso de transformao, quaisquer caractersticas geomtricas ou atributos alfanumricos que foram definidos no nvel de representao para a classe podem ser usadas como parmetros. As linhas indicando operaes TA so tracejadas para distingui-las visualmente das operaes TR, especificadas no diagrama de transformao com linhas contnuas. A terceira primitiva serve para especificar uma apresentao, e contm duas sees. A seo superior indica o nome da classe, o nome da apresentao, e a aplicao na qual usada. Nessa seo pode-se especificar uma faixa de escalas onde a apresentao ser usada. A segunda dividida em duas partes: esquerda, um pictograma indica o aspecto visual dos objetos aps a transformao e direita so lanadas especificaes mais precisas quanto aos atributos grficos, incluindo cor da linha, tipo e espessura de linha, padro de preenchimento, cor de preenchimento, e nome do smbolo (Figura 3.13). A especificao dos atributos grficos pode ser feita j considerando a codificao de smbolos
104
usada pelo sistema de informao geogrfica subjacente. Pode existir qualquer nmero de pictogramas na seo esquerda da primitiva de especificao de apresentaes, cada qual associada a um valor ou faixa de valores obtidos a partir das caractersticas de cada objeto. Nesse caso, a seo da direita deve detalhar os atributos grficos de cada apresentao gerada. Atributos comuns podem ser especificados apenas uma vez, enquanto atributos variveis so especificados como listas de valores individuais. Como no caso do diagrama de transformao, os resultados das transformaes (ou seja, as apresentaes) so indicados com linhas tracejadas quando no precisam ser materializados no banco de dados e com linhas contnuas no caso contrrio.
Figura 3.13 Diagrama de apresentao para a classe cidade ponto.
Cada classe georreferenciada especificada no diagrama de classes precisa ter pelo menos uma apresentao correspondente especificada no diagrama de apresentao. Caso exista mais de uma apresentao para uma dada representao, uma delas deve ser identificada como a default. Alternativamente, cada usurio ou aplicao pode eleger sua apresentao default.
Restries de integridade espaciais
105
As operaes TA mais comuns envolvem a simples definio de atributos grficos. No entanto, outros operadores mais sofisticados, muitos dos quais derivados de operaes da cartografia temtica (classificao, simbolizao, exagero, deslocamento, destaque) tambm podem ser empregados. Uma descrio detalhada dos operadores TA pode ser encontrada em (Davis Jr., 2000) (Davis Jr. e Laender, 1999). A Seo 3.7 exemplifica o uso deste diagrama. 3.5 Restries de integridade espaciais No modelo OMT-G, existem diversas restries de integridade que so implcitas s primitivas do modelo ou que podem ser deduzidas a partir da anlise dos diagramas. Assim, restries de integridade topolgica so definidas atravs de regras para geo-campos (Seo 3.5.1), relacionamentos espaciais (Seo 3.5.2), relacionamentos em rede (Seo 3.5.3) e para agregao espacial (Seo 3.5.4). Da mesma forma, restries de integridade semntica so definidas atravs de regras associadas a relacionamentos espaciais. J as restries de integridade definidas pelo usurio podem ser modeladas como mtodos associados a cada classe. No esto includas aqui restries de integridade referentes s formas geomtricas vetoriais bsicas (pontos, linhas e polgonos), fundamentais em SIG e SGBD espaciais, pois consideramos que so inerentes sua implementao em qualquer produto. Listamos a seguir as restries de integridade inerentes s demais primitivas e conceitos do modelo OMT-G, baseadas em trabalhos anteriores (Borges et al., 1999) (Davis Jr. et al., 2001, 2005). 3.5.1 Restries de integridade para geo-campos As restries de integridade R1 a R5 so decorrentes do conceito de geocampo e de da semntica inerente a cada uma das representaes suportada pelo modelo OMT-G. R1 Restrio de Preenchimento do Plano. Seja C um geo-campo e seja P um ponto tal que P F . Ento o valor V(P) = f(P, C), i.e., o valor de C em P,
pode ser univocamente determinado.
R2 Isolinhas. Seja C um geo-campo. Sejam v 0 , v1 , K , v n n+1 pontos no plano. Sejam a 0 = v 0 v1 , a1 = v1 v 2 , K , a n 1 = v n 1 v n n segmentos,
106
conectando os pontos. Esses segmentos formam uma isolinha L se, e somente se, (1) a interseo dos segmentos adjacentes em L ocorre apenas no ponto extremo compartilhado pelos segmentos (i. e., ai ai +1 = vi +1 ), (2) segmentos no adjacentes no se interceptam (ou seja, ai a j = para todo i, j tais que j i + 1 ), e (3) o valor de C em cada ponto P tal que P a i , 0 i n 1 , constante. R3 Tesselao. Seja C um geo-campo. Seja T = {t0, t1, t2, ..., tn} um conjunto de clulas de forma regular que cobrem C. T uma tesselao de C se, e somente se, para qualquer ponto P F , existe exatamente uma clula correspondente t i T e, para cada clula ti, o valor de C determinado. R4 Subdiviso Planar. Seja C um geo-campo. Seja A = {A0, A1, A2, ..., An} um conjunto de polgonos tais que Ai F para todo i, sendo 0 i n 1 . A forma uma subdiviso planar que representa C se, e somente se, para qualquer ponto P F existir exatamente um polgono Ai correspondente, Ai A , para o qual o valor de C determinado (ou seja, os polgonos no se sobrepem e cobrem C completamente). R5 Malha Triangular. Seja C um geo-campo. Seja T = {T0, T1, T2, ..., Tn} um conjunto de tringulos tais que Ti F para todo i, sendo 0 i n 1 . T forma uma malha triangular que representa C se, e somente se, para qualquer ponto P F , existir exatamente um tringulo Ti correspondente, Ti T , e o valor de C determinado em todos os vrtices de Ti. Restries de integridade referentes a relacionamentos topolgicos Restries referentes a relacionamentos espaciais foram originalmente propostas para o modelo OMT-G baseadas em (Clementini et al., 1993), conforme apresentado em (Borges et al., 2002). Uma descrio detalhada destes relacionamentos est apresentada na Seo 2.9 deste livro. 3.5.3 Restries de integridade para estruturas em rede Estruturas em rede, ou seja, formadas por arcos e ns (unidirecionados ou bidirecionados) esto sujeitas s restries usuais impostas a grafos, enquanto estruturas de dados. Como o modelo OMT-G considera 3.5.2
Mapeamento para esquemas de implementao
107
tambm o caso de redes formadas apenas por arcos, so apresentados a seguir duas restries de integridade correspondentes a esses casos. R6 Redes arco-n. Seja G = {N, A} uma estrutura de rede, composta de um conjunto de ns N = {n0, n1, ..., np} e um conjunto de arcos A = {a0, a1, ..., aq}. Membros de N e membros de A so relacionados de acordo com as seguintes restries: (1) para cada n ni N deve existir pelo menos um arco a k A ; (2) para cada arco a k A devem existir exatamente dois ns i j . R7 Redes arco-arco. Seja G = {A} uma estrutura de rede, composta de um conjunto de arcos A = {a0, a1, ..., aq}. A seguinte restrio se aplica: Cada arco a k A deve estar relacionado a pelo menos um outro arco
ai A n ,n N
, sendo k i .
3.5.4 Restries de integridade referentes agregao espacial A restrio a seguir necessria para garantir a correta semntica de relacionamentos todo-parte no banco de dados. R8 Agregao espacial. Seja P = {P0 , P1 , K , Pn } um conjunto de geoobjetos. P forma outro objeto, W , por agregao espacial se, e somente se (1) Pi W = Pi para todo i tal que 0 i n , e (2) W U Pi = W , e ainda
i =0
(3) ((Pi toca Pj) (Pi disjunto Pj)) = VERDADEIRO para todo i, j tais que i j . 3.6 Mapeamento para esquemas de implementao Apresentamos a seguir uma proposta de mapeamento de esquemas OMT-G no nvel de representao conceitual para esquemas de implementao. Em seguida, faremos algumas consideraes sobre alternativas de estruturao fsica para corresponder a classes georreferenciadas.
108
3.6.1
Mapeamento de esquemas conceituais OMT-G para esquemas de implementao Na fase de mapeamento, necessrio o conhecimento de qual SGBD ser usado na aplicao. No caso deste captulo, a fim de simplificar a explicao, consideramos por enquanto um SGBD espacial objetorelacional genrico, em que os dados alfanumricos e geogrficos esto codificados num mesmo registro, e os dados geogrficos so codificados de acordo com as especificaes do OpenGIS Consortium (1999). Como veremos na prxima seo, possvel optar entre algumas organizaes fsicas diferentes; esta opo pode ser feita aps a concluso do mapeamento, ou em uma etapa posterior de tuning do banco de dados. Inicialmente, faremos um mapeamento das classes de objetos presentes no diagrama de classes do OMT-G para estruturas objetorelacionais adequadas. Em seguida, cuidaremos da escolha de estruturas de dados para a implementao das alternativas de representao previstas no modelo OMT-G. Por fim, faremos o mapeamento dos relacionamentos necessrios. Observe que relacionamentos espaciais em geral no precisam ser materializados no esquema de implementao, uma vez que a associao entre os objetos envolvidos pode ser feita por meio de algoritmos geomtricos (vide Captulo 2 deste livro). A Tabela 3.1 uma adaptao da tabela de correspondncia entre os modelos ER e relacional apresentada em (Elmasri e Navathe, 2004), e resume uma correspondncia bsica entre os construtores dos modelos OMT-G e objeto-relacional.
Tabela 3.1 - Mapeamento entre primitivas OMT-G e objeto-relacionais Modelo OMT-G Classe Georreferenciada Modelo Objeto-relacional Relao entidade com representao geomtrica associada (vide Seo 3.6.2); se do tipo geo-campo, restries de integridade referentes representao adotada (R1 a R5) Relao entidade
Classe Convencional
109
Associao simples com cardinalidade 1:1 ou 1: N Associao simples com cardinalidade N : M Relacionamento espacial topolgico
Par chave estrangeira-chave primria Relao relacionamento e dois pares chave estrangeira-chave primria Restrio de integridade relativa ao tipo de relacionamento espacial (R6 a R12)
Relacionamento em rede arco- Dois pares chave estrangeira-chave n primria entre a relao arco e a relao n (n anterior e n posterior); restrio de integridade espacial adequada (R13) Relacionamento em rede arco- Dois pares chave estrangeira-chave arco primria em auto-relacionamento sobre a relao arco; restrio de integridade espacial adequada (R14) Agregao Agregao espacial Generalizao / especializao Atributo simples Atributo composto Atributo multivalorado Atributo-chave Mtodos ou operaes Par chave estrangeira-chave primria entre a classe parte e a classe todo Restrio de integridade relativa a agregao espacial (R15) Restries de integridade entre subclasses e superclasse (Elmasri e Navathe, 2004 Cap. 7) Atributo simples (coluna) Conjunto de atributos simples componentes Relao e chave estrangeira Chave primria (ou candidata)
Triggers ou programas associados
110
Detalhamos a seguir os quatro principais passos do mapeamento de esquemas conceituais OMT-G para esquemas de implementao, nos quais a correspondncia expressa na Tabela 3.1 empregada. Passo 1: Mapeamento de classes georreferenciadas e convencionais. Para cada classe convencional presente no diagrama, criar uma tabela, sendo que cada atributo alfanumrico da classe transformado em uma coluna da tabela. Escolher um dos atributos-chave para ser a chave primria da tabela; caso nenhum atributo atenda aos requisitos de noduplicidade e inexistncia de valores nulos, um novo atributo precisa ser criado para essa finalidade. O mesmo procedimento se aplica a classes georreferenciadas, decidindo-se adicionalmente a alternativa de representao segundo os tipos geomtricos disponveis no banco de dados escolhido. A Tabela 3.2 apresenta uma correspondncia entre os tipos geomtricos bsicos do modelo OMT-G e os propostos pelo Consrcio OpenGIS (1999). Naturalmente, as representaes de geo-campos exigem mais do que apenas a codificao geomtrica: atributos devem ser includos de modo a armazenar o valor do geo-campo associado a cada elemento da representao.
111
Tabela 3.2 Tipos Geomtricos

Representao OMT-G Geo-objeto Geo-objeto Geo-objeto Geo-objeto Geo-objeto Geo-objeto Geo-campo Geo-campo Geo-campo Geo-campo Geo-campo Ponto Linha Polgono N de rede Arco unidirecionado Arco bidirecionado Amostras Isolinhas Subdiviso planar Triangulao Tesselao Representao OpenGIS (Simple Features Specification) Point LineString Polygon Point LineString LineString Point LineString e/ou Polygon Polygon Point (vrtices) e Polygon (tringulos) GeoRaster, campo binrio longo
Observe-se que tesselaes no OMT-G podem corresponder a dois tipos de representao fsica sutilmente diferentes: imagens digitais e grades regulares. Assim, caso a representao conceitual seja uma tesselao, pode-se optar entre uma representao matricial prpria do SGBD (como a GeoRaster do OracleTM Spatial) ou um campo binrio longo, contendo dados binrios em um determinado formato de imagem ou grade. Em ambos os casos, necessrio ter recursos para recuperar o valor de uma determinada clula individualmente. Passo 2: Mapeamento das associaes simples. Para cada relacionamento por associao simples entre classes, de cardinalidade 1:1, escolher uma das classes e incluir nela a chave primria da outra, no papel de chave estrangeira. Para associaes de cardinalidade 1:N, incluir na tabela correspondente classe do lado N, como chave estrangeira, a
112
chave primria da tabela correspondente classe do lado 1. No caso de associaes de cardinalidade N:M, criar uma tabela intermediria, contendo as chaves primrias de ambas as tabelas envolvidas, no papel de chaves estrangeiras de suas respectivas tabelas, e formando, juntas, a chave primria da nova tabela. O tratamento de associaes simples independe da existncia ou no de representao geomtrica na tabela. Tratar desta forma tambm os relacionamentos de agregao convencionais. Passo 3: Mapeamento de relacionamentos espaciais. Na maioria dos casos, relacionamentos espaciais explicitados em diagramas de classe OMT-G (incluindo agregaes espaciais) no so materializados no esquema fsico. Por outro lado, constituem declaraes do relacionamento esperado entre instncias das classes envolvidas, e freqentemente denotam restries de integridade espaciais. Assim, o mapeamento ideal de relacionamentos espaciais no causa alteraes diretamente nas tabelas construdas at este passo, mas requer a implementao de controles dinmicos (triggers) ou estticos (verificaes offline de consistncia). Passo 4: Mapeamento de generalizaes e especializaes. Em esquemas OMT-G, tanto a superclasse quanto as subclasses recebem, se forem georreferenciadas, o mesmo tipo de representao geomtrica. Assim, o mapeamento de generalizaes e especializaes o mesmo para classes convencionais e georreferenciadas, e pode ainda ser estendido para generalizaes conceituais. Subclasses especializadas constituem subconjuntos das instncias das superclasses, contendo eventualmente atributos prprios. Nesses casos conveniente que as subclasses sejam tabelas distintas por motivos de gerenciamento da informao geogrfica e de visualizao. Apesar de estarmos considerando o uso de um banco de dados objeto-relacional deve-se ter em mente que a visualizao e a facilidade de manipulao das tabelas deve sempre nortear o modelo lgico e fsico de um banco de dados geogrfico. O mapeamento pode ser feito de acordo com uma das seguintes opes: Opo 1. Criar uma tabela para a superclasse, contendo todos os seus atributos e sua chave primria. Criar uma tabela para cada subclasse,
113
usando a mesma chave primria da superclasse, e tambm estabelecendo-a como chave estrangeira em relao tabela correspondente superclasse. Neste caso, a representao geogrfica dever ficar nas subclasses. Esta abordagem conveniente para subclasses que necessitam sempre serem visualizadas de forma distinta como por exemplo, com simbologia diferente ou tipo de trao diferente. Tambm conveniente para que visualizao seja automtica no precisando depender de nenhum comando especfico para que isto acontea. Quando as subclasses herdam todos os atributos da superclasse e no possuem atributos especficos, ou quando recebem alguma numerao seqencial essa opo deve ser usada. Um exemplo do uso de numerao seqencial o caso dos ns da rede de esgoto, onde cada n recebe uma numerao de cadastro independente do seu tipo. Opo 2. Criar uma tabela para cada subclasse, contendo todos os seus atributos e tambm todos os atributos herdados da superclasse, inclusive a chave primria. No criar tabela para a superclasse. Essa abordagem conveniente para subclasses que contenham atributos prprios e visualizao distinta. Opo 3. Criar uma nica tabela contendo todos os atributos da superclasse, inclusive a chave primria, e todos os atributos de cada subclasse. Acrescentar dois atributos (discriminador), um para indicar o tipo da subclasse e outro para indicar a qual subclasse pertence cada linha da tabela. Apesar desta opo ser usada em projetos fsicos de banco de dados relacionais, ela no adequada a aplicaes geogrficas por requerer outros tipos de controle para acesso e visualizao correta dos dados. A alternativa 1 mais conveniente para especializao/generalizao total e disjunta, quando as subclasses possurem alguma identificao nica gerenciada pela superclasse. J a alternativa 2 mais conveniente para especializao/generalizao total e disjunta, onde as subclasses possuem atributos prprios. No caso de sobreposio, a alternativa 1 mais conveniente, uma vez que os atributos em comum ficam na tabela da superclasse. Normalmente, em casos de sobreposio, existe um conjunto de atributos que so comuns.
114
3.6.2 Alternativas de estruturao de tabelas Para efetivar adequadamente um mapeamento entre um esquema lgico e um esquema fsico dentro das definies do OpenGIS Consortium, necessrio discutir algumas alternativas de implementao. O Simple Features Specifications (SFS) do OGC (1999) se restringe codificao da forma geomtrica dos objetos, incluindo as coordenadas geogrficas de seus vrtices e a definio do sistema de coordenadas. No faz parte das especificaes do OGC a organizao fsica das tabelas, sendo deixada para o projetista a tarefa de decidir qual a melhor alternativa para receber os componentes espaciais e alfanumricos de cada classe de objetos constante do esquema conceitual. Dependendo do volume relativo de dados e da intensidade do uso, o projetista pode optar por deixar a representao geomtrica integrada ou separada dos atributos convencionais. Vamos aqui assumir que a representao geomtrica possa ser armazenada em uma coluna de uma tabela, atravs de um mecanismo objeto-relacional, uma extenso especial, ou mesmo um campo binrio longo. Com isso, configuram-se trs alternativas: 1. Armazenamento de todas as representaes geomtricas de todos os objetos de todas as classes em uma nica tabela, relacionando esta tabela por meio de uma chave estrangeira com diversas outras tabelas, cada qual contendo os atributos alfanumricos de uma classe especfica (Figura 3.14). 2. Armazenamento da representao geomtrica em uma coluna de uma tabela, relacionada com outra tabela contendo os atributos alfanumricos da classe de objetos atravs de uma chave estrangeira (Figura 3.15); 3. Armazenamento da representao geomtrica e dos atributos alfanumricos de uma classe de objetos como colunas da mesma tabela (Figura 3.16);
115
GEOMETRIA_TOTAL Geometria Nome da Tabela 1 TABELA1_ATRIBUTOS Atrib11 Atrib12 ... id 1 id
TABELA2_ATRIBUTOS Atrib21 Atrib22 ... id 1
TABELA3_ATRIBUTOS Atrib31 Atrib32 ... id 1
Figura 3.14 Alternativa 1: geometrias concentradas em uma nica tabela (Fonte: (Davis Jr. e Oliveira, 2002)).
TABELA1_GEOMETRIA Geometria 1 id TABELA1_ATRIBUTOS Atrib1 Atrib2 ... id 1
Figura 3.15 Alternativa 2: um par de tabelas para cada classe georreferenciada (Fonte: (Davis Jr. e Oliveira, 2002)).
TABELA1_GEORREF Geometria Atrib1 Atrib2 ... id
Figura 3.16 Alternativa 3: geometria e atributos na mesma tabela (Fonte: (Davis Jr. e Oliveira, 2002)).
A alternativa 1 tende a introduzir um desequilbrio no SGBD, fazendo com que todas as consultas e operaes envolvendo dados geomtricos passem pela nica tabela que os armazena. Em um banco de dados dotado de um volume razoavelmente grande de dados geogrficos, essa tabela pode rapidamente se tornar um gargalo para todo o sistema.
116
Por outro lado, pode-se imaginar que a indexao espacial e as operaes topolgicas entre classes de objetos sejam eventualmente beneficiadas pela integrao das representaes geomtricas em uma nica tabela. tambm possvel imaginar vantagens quanto ao acesso s tabelas de atributos alfanumricos, que se tornam menos volumosas pela separao das representaes geomtricas. Esse esquema foi adotado por alguns SIG no passado, com relativo sucesso. A alternativa 2 destaca-se por sua flexibilidade, apesar de exigir a navegao entre tabelas ou a realizao de operaes de juno para que se possa resgatar a estrutura completa de cada objeto geogrfico. A separao dos atributos alfanumricos em uma tabela independente facilita a integrao com aplicaes convencionais. A implementao da restrio de integridade referencial entre as duas tabelas , no entanto, indispensvel o que pode se constituir em um problema para a implementao de aplicaes exclusivamente alfanumricas e que pretendam operar sobre esses dados. A terceira alternativa a que mais se assemelha concepo de objetos geogrficos adotada pelo modelo OMT-G. Cada tupla de cada tabela passa a corresponder, aproximadamente, a uma instncia de um objeto, sendo que a tabela contm todas as instncias de uma determinada classe. Com isso, no so necessrias junes para acessar dados geomtricos e atributos, o que pode beneficiar aplicaes de anlise espacial ou mapeamento temtico, em particular aquelas que no exigem muitos dados alfanumricos. Esta alternativa corresponde ao mapeamento mais simples de se executar e opo mais conservadora quanto ao desempenho, considerando uma igual incidncia de operaes alfanumricas e espaciais. Observe-se que esquemas baseados na primeira alternativa podem ser facilmente mapeados para a segunda, dividindo a grande tabela de dados geomtricos em vrias (o que pode ser feito usando o mecanismo de vises). Tambm podem ser mapeados para a terceira, pela realizao de uma juno aps a separao da tabela geomtrica em vrias, o que tambm pode ser feito usando vises. O mesmo raciocnio pode ser empregado para implementar um mapeamento entre a alternativa 2 e a alternativa 3, ou vice-versa.
117
Uma alternativa adicional consiste na implementao de uma terceira tabela para viabilizar um relacionamento n:m entre representaes geomtricas e atributos alfanumricos, dando ao usurio a possibilidade de combinar esses aspectos de acordo com a sua necessidade (Figura 3.17). Essa terceira tabela deve manter duas chaves estrangeiras, uma chave da tabela de representaes geomtricas com outra da tabela que contm os atributos, que juntas compem sua chave primria. Com isso possvel, por exemplo, manter simultaneamente uma representao cartogrfica e uma representao esquemtica de uma rede de distribuio de energia. A situao oposta (vrias tuplas de atributos relacionadas a uma nica representao geomtrica) tambm til. Existem diversas aplicaes que armazenam sries temporais de dados, por exemplo na rea de meteorologia: cada tupla alfanumrica conteria dados meteorolgicos obtidos em uma localidade em um determinado dia e horrio, a tupla geomtrica traria a localizao da estao meteorolgica, e a chave composta seria formada pelo identificador da estao meteorolgica e pela data e hora da medio.
TABELA1_ENTIDADE 1 idG + idA 1
TABELA1_GEOMETRIA Geometria
n idG
m idA
TABELA1_ATRIBUTOS Atrib1 Atrib2 ...
Figura 3.17 Alternativa 4: mltiplas representaes e/ou mltiplos conjuntos de atributos.
No entanto, a opo de manter mais de uma geometria em uma mesma tabela pode ser implementada usando os bancos de dados espaciais atuais. Nesse caso, seria utilizada em tabelas que contenham sempre um ou mais tipos de representao, como por exemplo a frente principal de um lote e o contorno do lote. importante que, em tabelas desse tipo, as instncias disponham sempre das representaes
118
consideradas no esquema conceitual, viabilizando a implementao das restries de de integridade espaciais. 3.7 Discusso de um exemplo Para exemplificar o uso das principais primitivas do modelo OMT-G, apresentamos nesta Seo um exemplo de modelagem, apresentado originalmente em (Davis Jr., 2000). A aplicao proposta combina aspectos de interesse em trs diferentes contextos: cadastro tcnico municipal (CTM), em que os usurios esto interessados na estruturao da ocupao do solo urbano em quadras, lotes e vias pblicas; gerenciamento de transportes e trnsito, em que o interesse est na estruturao do sistema virio; mapeamento em escala regional, em que os usurios se interessam apenas pelos principais aspectos de ocupao do territrio e acessos, em especial a malha rodoviria. Alguns objetos do ambiente urbano so necessrios nos trs contextos, como por exemplo o sistema virio. No entanto, cada um deles percebe esses objetos de uma maneira diferente, gerando a necessidade de mais de uma representao. Para os usurios da rea de cadastro tcnico municipal, os principais objetos so as quadras e lotes da cidade. Particularmente no caso dos lotes, adotamos trs diferentes alternativas para representao. A primeira e mais simples delas utilizando pontos. No caso de Belo Horizonte, esta forma de representao foi adotada no incio da construo do banco de dados geogrfico para o cadastro, a partir de uma metodologia que envolvia uma rpida referncia visual planta cadastral convencional, transformada em imagem e colocada no background (Davis Jr., 1993). Essa representao suficiente para que se possa localizar cada lote, porm no permite que se verifique topologicamente as relaes de vizinhana e de incluso em uma quadra. A segunda alternativa de representao consiste em traar apenas a testada do lote, usando uma poligonal. Esta alternativa quase to simples quanto a primeira quanto ao esforo de converso de dados, porm permite que se realize alguns
Discusso de um exemplo
119
tipos adicionais de anlise, como a de vizinhana, e fornece um dado geomtrico, que a largura do lote no segmento frontal. Por fim, a terceira alternativa de representao usa polgonos que definem todas as fronteiras entre o lote e seus vizinhos. a representao ideal, pois permite verificar todas as confrontaes e ainda fornecer parmetros geomtricos bsicos, como a rea do lote. No entanto, a mais custosa em termos de converso de dados. A convivncia das trs formas de representao de lotes em um mesmo banco de dados se justifica do ponto de vista da formao incremental dos componentes do cadastro urbano. O relacionamento dos lotes e quadras com o sistema de endereamento da cidade, atravs da malha viria, tambm desejvel, para que seja possvel simplificar a tarefa de localiz-los em campo e tambm para facilitar a comunicao com os proprietrios e outros cidados. Para que se possa trabalhar com transportes e trnsito, fundamental poder contar com todas as informaes relevantes quanto malha viria, incluindo a localizao de cada logradouro e cada cruzamento entre logradouros. Na presente aplicao, a malha viria bsica est representada por uma rede, em que arcos bidirecionais representam os segmentos de logradouro entre cruzamentos, que por sua vez constituem os ns. Observe-se que, por simplicidade, optou-se por no modelar a malha de circulao viria, composta por arcos unidirecionais e que atendem a todas as restries da legislao de trnsito quanto ao sentido de fluxo. Cada trecho de logradouro recebe uma classificao de acordo com o Plano de Classificao Viria, um componente do Plano Diretor do municpio que define vias de ligao regional, arteriais, coletoras e locais. Essa classificao depende basicamente do volume de trfego e da funo primria de cada trecho de logradouro. Observe-se que a classificao um atributo do trecho e no do logradouro inteiro, pois existem situaes em que parte do logradouro recebe trfego intenso e parte tem caractersticas de via local. Considerando apenas as vias mais importantes para a circulao, concebe-se uma nova rede, esta adequada para o planejamento da circulao de veculos entre regies da cidade. Por fim, os responsveis pelo mapeamento regional esto interessados em obter os limites da rea urbanizada da cidade, usualmente denominados mancha urbana, alm das ligaes da cidade a outras por
120
meio de rodovias e outros meios de transporte de cargas. As ferrovias foram deixadas de fora do problema por simplicidade, mas as rodovias que atravessam a cidade fazem parte da malha viria concebida para a aplicao de transportes e trnsito. Alm disso, considerando as escalas em que se pretende construir o mapeamento regional, interessante poder contar com (1) uma representao simplificada do polgono que compe os limites entre a cidade e suas vizinhas, e (2) uma representao da cidade como ponto, para a gerao de mapas temticos sobre transportes rodovirios. Considerando as necessidades descritas, foi construdo o diagrama de classes para a aplicao (Figura 3.18). No diagrama, a primitiva de generalizao conceitual do modelo OMT-G foi usada duas vezes, uma para a classe Municpio, que pode ter representaes pontuais ou poligonais, em subdiviso planar (esta em dois diferentes nveis de detalhamento), e outra para a classe Lote CTM, que podem ser representados usando pontos, linhas ou polgonos. Existe tambm uma primitiva de agregao, que indica que as instncias da classe Quadra CTM sero criadas pela agregao de instncias de Lote CTM. A classe Rodovia est relacionada classe de vias principais, assumindo a regra de que todos os trechos de rodovia so classificados como vias de ligao regional. A classe Via principal, por sua vez, um subconjunto da classe Trecho, pois nem todo trecho de logradouro pertence malha viria principal. Com isso, nem todos os ns de cruzamento constituem intersees na malha viria principal. O diagrama de classes indica, assim, que existe uma superposio parcial entre a malha de logradouros e a malha viria principal, mas no determina a forma de estruturao do banco de dados geogrfico quanto a esse aspecto.
121
Figura 3.18 Diagrama de classes.
122
O diagrama de transformao correspondente ao diagrama de classes da Figura 3.18 pode ser criado em blocos, cada qual correspondendo a um grupo de transformaes demandado pela aplicao. O primeiro desses blocos diz respeito agregao de Lote CTM para formar Quadra CTM, e relao contm entre Quadra CTM e Mancha Urbana (Figura 3.19). No caso da agregao, optou-se por usar o operador de generalizao cartogrfica denominado Fuso, com tolerncia de espaamento igual a zero. Isso faz com que o seu comportamento seja idntico ao de um operador de unio de polgonos, conforme definido na rea de geometria computacional. A opo pela implementao do operador Fuso pode ser feita considerando que seu uso j necessrio na aplicao, para a transformao que leva criao da mancha urbana, desta vez considerando uma tolerncia de 15 metros. Esse valor de tolerncia faz com que desapaream da mancha urbana todas as ruas cuja largura seja inferior a 30 metros, caso da maioria das vias locais e mesmo algumas avenidas de menor porte. Apenas logradouros mais largos permanecero visveis aps a aplicao do operador. A Figura 3.20 apresenta um exemplo de aplicao desse operador a um grupo de quadras.
Lote CTM polgono numQuadraCTM numLoteCTM Colapso Fuso Extrao Seg.Frontal Fuso(0 m)
Quadra CTM numQuadraCTM
Quadra CTM numQuadraCTM Fuso(15 m)
Mancha urbana
Figura 3.19 Diagrama de transformao 1. bloco.
O segundo bloco de transformaes dinmicas refere-se criao da malha viria principal a partir da malha de logradouros (Figura 3.21). Como a malha de logradouros mais detalhada e precisa ser mantida
123
atualizada para benefcio das aplicaes de transportes e cadastro, seus arcos e ns so considerados representaes primrias, a partir das quais as representaes secundrias correspondentes malha viria principal so criadas. O processo consiste em, inicialmente, selecionar as instncias de Trecho classificadas como vias de ligao regional ou arteriais, ou seja, componentes do sistema virio principal, e em duplicar toda a classe Cruzamento. Em seguida, os ns que so desnecessrios para a malha viria principal so eliminados, gerando a classe Cruzamento vias principais, e juntando os segmentos de arcos onde os ns foram eliminados, produzindo a classe Via principal. A eliminao feita sempre que um n for encontrado com exatamente zero ou dois arcos conectados: no primeiro caso, o n no cumpre funo alguma na rede, e no segundo ele no configura mais um cruzamento entre vias. O terceiro bloco de transformaes corresponde generalizao conceitual sobre as classes Municpio e Lote CTM (Figura 3.22). No primeiro caso, admite-se que a classe Fronteiras municipais seja a mais genrica e a mais detalhada, e portanto a partir dela pode-se produzir a classe Fronteiras municipais simplificadas, usando um operador de simplificao de polgonos com tolerncia de 10 metros, e a classe Municpio ponto, usando o operador colapso. A tolerncia foi escolhida a partir da definio da escala de trabalho para o mapeamento regional pretendido, no caso equivalente a 1:50.000. A tolerncia corresponde a metade da largura de uma linha traada com pena 0,4mm. Esse valor foi escolhido considerando a deduo do tamanho do menor objeto visvel (smallest visible object, ou SVO) (Li e Openshaw, 1992). Naturalmente, o tamanho do SVO expresso nas unidades de medida da tela ou do mapa, e portanto pode ser traduzido em medidas reais atravs da aplicao do fator de escala. Como no caso da classe Fronteiras municipais, a classe Lote CTM polgono foi escolhida como representao primria. A partir dela podese gerar a classe Lote CTM ponto, usando o operador Colapso, e a classe Lote CTM frente, usando um operador especial que determina qual o segmento frontal de cada lote poligonal no caso, segmentos frontais so aqueles que no so compartilhados pelos lotes adjacentes. Observe-se que as representaes produzidas pelo operador colapso no precisam ser materializadas, uma vez que seu processamento bastante rpido.
124
(a)
(b)
(c)
Figura 3.20 Fuso.
(d)
Seleo(Logradouro(numLogradouro).tipoLograd = "ROD") JunoArcosDivididos Simplificao(40m)
125
Rodovia numLogradouro
Trecho numLogradouro numSeqTrecho tipoVia Malha de logradouros
Seleo(tipoVia="LR" ou tipoVia="A")
Via temporria numLogradouro tipoVia JunoArcosDivididos
Via principal numLogradouro tipoVia
Cruzamento Superposio ElimNsDesnecessrios
Cruzamento temporrio ElimNsDesnecessrios ElimNsDesnecessrios

Cidade Fronteiras municipais codMunicpioIBGE populaoMunicpio rea Simplificao Colapso Fronteiras municipais simplificadas codMunicpioIBGE populaoMunicpio Colapso codMunicpioIBGE populaoMunicpio
Simplificao(10m)
Colapso Lote CTM polgono numQuadraCTM numLoteCTM Colapso Fuso Extrao Seg.Frontal
Lote CTM ponto numQuadraCTM numLoteCTM
Extrao do segmento frontal
Lote CTM frente numQuadraCTM numLoteCTM
Malha viria principal Cruzamento vias principais
Malha temporria
126
Cada uma das classes que compem os diagramas de classes e de transformao precisam ter pelo menos uma apresentao definida no diagrama de apresentao. Alm dessa apresentao default, cada classe pode ter um nmero indeterminado de apresentaes alternativas, de acordo com as necessidades da aplicao. possvel ter, por exemplo, uma apresentao voltada para visualizao em tela e outra voltada para a sada plotada em um mapa. As classes Fronteiras municipais e Cidade ponto so associadas a duas apresentaes cada, uma para visualizao em tela e outra para usos especficos (Figura 3.23). As apresentaes em tela estabelecem um limiar de escala, de modo que em escalas at 1:25.000 as fronteiras entre municpios sero visualizadas, entre 1:25.000 e 1:50.000 sero apresentadas as fronteiras simplificadas, e em escalas menores, a partir de 1:50.000, sero apresentados os smbolos.
Fronteiras Municipais Default Tela (esc > 1:25.000) ApresentaoArea() Fronteiras municipais codMunicpioIBGE populaoMunicpio rea Simplificao Colapso Fronteiras Municipais Densidade demogrfica Anlise de demanda por transportes 0-10 Classificao(populaoMunicpio/Area) Cor da linha = preto Espessura da linha = 1 Preenchimento = slido 20-50 Cor de preenchimento = 50-100 {branco, cinza 25%, cinza 50%, cinza 75%, preto} > 100 10-20 Cor da linha = preto Espessura da linha = 1 Preenchimento = nenhum
127
Fronteiras municipais simplificadas codMunicpioIBGE populaoMunicpio
Fronteiras municipais simplificadas Default Tela (esc <= 1:25.000 e esc > 1:50.000) ApresentaoArea() Cor da linha = preto Espessura da linha = 1 Preenchimento = nenhum
Cidade ponto Default Tela (esc <= 1:50.000) ApresentaoSimbolo() Cor = preto Nome do smbolo = S03 Cidade ponto codMunicpioIBGE populaoMunicpio
Cidade ponto Faixas de populao Mapa rodovirio < 10
Simbolizao(Populao / 1000)
10-20 20-50 50-100 > 100
Cor = preto Nome do smbolo = {S02, S03, S04, S05, S06}
Figura 3.23 Diagrama de apresentao- 1. bloco.
128
Para a classe Rodovia, foi definida apenas uma apresentao, em que estradas de terra so distinguidas visualmente de estradas asfaltadas. Tambm a classe Mancha urbana conta com apenas uma apresentao, que procura distinguir levemente a rea urbanizada da rea rural (Figura 3.24).
Rodovia Default / Tipo de pavimento Tela / Mapa rodovirio / Mapa regional Classificao(tipoPavimento) Asfalto Terra Cor = {preto, vermelho} Tipo de linha = contnua Espessura = 0.4mm
Rodovia numLogradouro tipoPavimento
Mancha urbana ApresentaoArea()
Mancha urbana Default Tela / Mapa regional Cor da linha = amarelo Espessura da linha = 1 Preenchimento = slido Cor de preenchimento = amarelo
Figura 3.24 Diagrama de apresentao 2. bloco.
Em seguida, as classes que compem a malha de vias principais tm sua apresentao definida. A classe Via principal conta com duas apresentaes, sendo que na primeira as vias de ligao regional e arteriais, mais importantes na hierarquia de classificao viria, so diferenciadas usando a espessura da linha, e na segunda apenas as vias de ligao regional so destacadas. A apresentao correspondente classe Cruzamento vias principais usa um smbolo muito pequeno, o que faz com que suas instncias efetivamente desapaream na tela. O usurio poder perceber os cruzamentos de vias visualmente, sem a necessidade de um smbolo mais evidente, o que traria apenas poluio visual (Figura 3.25).
Via principal Default Tela Classificao(tipoVia) Lig. regional Arterial Via principal numLogradouro tipoVia Cor da linha = preto Tipo de linha = contnua Espessura da linha = {0,4mm, 0,8mm}
129
Via principal Vias de ligao regional Mapa de principais acessos Classificao(tipoVia) Lig. regional Arterial Cor da linha = {preto, transparente} Tipo de linha = contnua Espessura da linha = {0mm, 0,4mm}
Cruzamento vias principais ApresentaoSmbolo()
Cruzamento vias principais Default Tela Cor = preto Nome do smbolo = S10
Figura 3.25 Diagrama de apresentao -3. bloco.
Para a classe Trecho so definidas duas variaes de apresentao. A primeira define uma classificao com base na hierarquizao do sistema virio. A classe Cruzamento, que com Trecho compe a malha de logradouros, apresentada usando um smbolo circular simples, porm visvel. Em ambos os casos, a visualizao s permitida em escalas superiores a 1:5000, pois fora dessa faixa a densidade de elementos na tela seria excessivamente alta (Figura 3.26). Por fim, todas as demais classes anteriormente definidas recebem uma apresentao correspondente. Pelo menos uma apresentao tem que estar definida para cada classe, e na Figura 3.27 isso foi feito para as classes Quadra CTM, Lote CTM polgono, Lote CTM frente e Lote CTM ponto. Observe-se a definio da simbologia para a classe Lote CTM frente, em que utilizado um recurso comum em SIG e cartografia: o lanamento de smbolos ao longo de linhas. No caso, foi inserido um smbolo no incio da linha, para estabelecer um marco visual que a separe da frente do lote vizinho. O intervalo entre smbolos foi
130
especificado usando um valor intencionalmente muito alto, para garantir que o smbolo no venha a ser usado mais de uma vez na frente do mesmo lote. importante destacar que a especificao dos parmetros de cada apresentao pode ser baseada nos recursos conhecidos do SIG onde a aplicao ser implementada.
Trecho Default / Tipo de via Tela (esc >= 1:10000) Classificao(tipoVia) Lig. Regional Arterial Trecho numLogradouro numSeqTrecho tipoVia tipoPavimento Coletora Local
Cor = vermelho Tipo de linha = contnua Espessura = {1.2mm, 0.8mm, 0.4mm, 0.2mm}
Trecho Tipo de pavimento Tela (esc >= 1:10000) Classificao(tipoPavimento) Asfalto Terra Cor = {preto, vermelho} Tipo de linha = contnua Espessura = 0.4mm
Cruzamento ApresentaoSmbolo()
Cruzamento Default Tela (esc >= 1:10000) Cor = preto Nome do smbolo = S12
Leituras suplementares
Quadra CTM Default Tela Apresentaorea() Cor da linha = preto Espessura da linha = 1 Preenchimento = nenhum
131
Quadra CTM numQuadraCTM
Lote CTM polgono numQuadraCTM numLoteCTM
Lote CTM polgono Default Tela Apresentaorea() Cor da linha = preto Espessura da linha = 1 Preenchimento = nenhum
Lote CTM frente numQuadraCTM numLoteCTM
Lote CTM frente Default Tela ApresentaoLinha() Cor da linha = preto Espessura da linha = 1 Intercalar smbolo(S02, incio 0, intervalo 10000m)
Lote CTM ponto numQuadraCTM numLoteCTM
ApresentaoSmbolo()
Lote CTM ponto Default Tela Cor = azul Nome do smbolo = S15
3.8 Leituras suplementares Neste capitulo, apresentamos o OMT-G, um modelo de dados orientado a objetos para modelagem de aplicaes geogrficas, e tcnicas para transformar esquemas OMT-G em esquemas de implementao, supondo um SGBD objeto-relacional compatvel com o padro OGC. O modelo OMT-G oferece primitivas para modelar a geometria e topologia dos dados geogrficos. Devido ao uso de pictogramas representando a geometria dos objetos, o esquema resultante mais compacto, intuitivo e de fcil compreenso. Alm do mais a combinao de diagramas de classes, transformao, apresentao faz com que a distncia entre a modelagem conceitual e a implementao de aplicaes geogrficas seja
132
reduzida, permitindo uma definio mais precisa dos objetos requisitados, suas operaes, seus parmetros de visualizao. Aos leitores interessados em um maior aprofundamento neste tema, recomendamos uma reviso das referncias mais citadas ao longo do captulo. Para obter uma viso mais detalhada de operaes de transformao, veja (Davis Jr., 2000) (Davis Jr. e Laender, 1999). Exemplos adicionais de modelagem usando OMT-G podem ser encontrados em numerosos trabalhos, dentre os quais (Bertini e Czar Neto, 2004) (Davis Jr. et al., 2003) (Martins Netto, 2003) (Preto, 1999) Souza et al., 2004) (Voll, 2002). Comparaes entre modelos de dados para aplicaes geogrficas podem ser encontrados em (Borges, 1997) (Borges et al., 2001) (Lisboa Filho, 1997). Lembramos ainda aos leitores que o modelo OMT-G foi inicialmente chamado de GeoOMT (Borges, 1997), e que existem algumas publicaes que se referem a ele por este nome. O uso de ontologias no projeto e construo de sistemas de informao geogrficos, algo que no foi abordado neste captulo, mas que parece estar um passo adiante das atuais tcnicas de modelagem conceitual, apresentado e discutido em (Fonseca, 2001) (Fonseca et al., 2000) (Fonseca et al., 2002). Uma discusso a respeito da conexo que existe entre modelagem conceitual e ontologias pode ser encontrada em (Fonseca et al., 2002).
Referncias
133
Referncias
ABITEBOUL, S.; HULL, R. IFO: a formal semantic database model. ACM Transactions on Database Systems, v. 12, n.4, p. 525-565, 1987. ABRANTES, G.; CARAPUA, R. Explicit representation of data that depend on topological relationships and control over data consistency. In: Fifth European Conference and Exhibition on Geographical Information Systems - EGIS/MARI'94. 1994. p. BDARD, Y.; CARON, C.; MAAMAR, Z.; MOULIN, B.; VALLIRE, D. Adapting data models for the design of spatio-temporal databases. Computers, Environment and Urban Systems, v. 20, n.1, p. 19-41, 1996. BERTINI, G. C.; CZAR NETO, J. Uma modelagem orientada a objeto para o Mapa Urbano Bsico de Belo Horizonte. Informtica Pblica, v. 6, n.1, p. 33-51, 2004. BORGES, K. A. V. Modelagem de dados geogrficos - uma extenso do modelo OMT para aplicaes geogrficas.Belo Horizonte: Fundao Joo Pinheiro, 1997.Dissertao de mestrado, Escola de Governo, 1997. BORGES, K. A. V.; DAVIS JR., C. A.; LAENDER, A. H. F. OMT-G: an object-oriented data model for geographic applications. GeoInformatica, v. 5, n.3, p. 221-260, 2001. BORGES, K. A. V.; DAVIS JR., C. A.; LAENDER, A. H. F., 2002. Integrity constraints in spatial databases. In: DOORN, J. H.; RIVERO, L. C., eds., Database Integrity: Challenges and Solutions: Hershey (PA), Idea Group Publishing, p. 144-171. BORGES, K. A. V.; LAENDER, A. H. F.; DAVIS JR., C. A. Spatial data integrity constraints in object oriented geographic data modeling. In: 7th International Symposium on Advances in Geographic Information Systems (ACM GIS'99). Kansas City, 1999. p. 1-6. CMARA, G. Modelos, linguagens e arquiteturas para bancos de dados geogrficos.So Jos dos Campos: INPE, 1995.Tese de doutorado, 1995. CHEN, P. The entity-relationship model - toward a unified view of data. ACM Transactions on Database Systems, v. 1, n.1, p. 9-36, 1976. CLEMENTINI, E.; DIFELICE, P.; VAN OOSTEROM, P. A small set of formal topological relationships suitable for end-user interaction. In: 3rd Symposium on Spatial Database Systems. 1993. p. 277-295.
134
COCKROFT, S. A taxonomy of spatial data integrity constraints. GeoInformatica, v. 1, n.4, p. 327-343, 1997. DAVIS JR., C. A. Address base creation using raster-vector integration. In: URISA Annual Conference. Atlanta (GA), 1993. p. 45-54. DAVIS JR., C. A. Mltiplas representaes em sistemas de informao geogrficos.Belo Horizonte (MG): UFMG, 2000.Departamento de Cincia da Computao, 2000. DAVIS JR., C. A.; BORGES, K. A. V.; LAENDER, A. H. F. Restries de integridade em bancos de dados geogrficos. In: III Workshop Brasileiro de GeoInformtica (GeoInfo 2001). Rio de Janeiro (RJ), 2001. p. 63-70. DAVIS JR., C. A.; BORGES, K. A. V.; LAENDER, A. H. F., 2005. Deriving spatial integrity constraints from geographic application schemas. In: RIVERO, L. C.; DOORN, J. H.; FERRAGINE, V. E., eds., Encyclopedia of Database Technologies and Applications: Hershey (PA), Idea Group Publishing. DAVIS JR., C. A.; FONSECA, F.; BORGES, K. A. V. A flexible addressing system for approximate urban geocoding. In: V Simpsio Brasileiro de GeoInformtica (GeoInfo 2003). Campos do Jordo (SP), 2003. p. em CDROM. DAVIS JR., C. A.; LAENDER, A. H. F. Multiple representations in GIS: materialization through geometric, map generalization, and spatial analysis operations. In: 7th International Symposium on Advances in Geographic Information Systems (ACM GIS'99). Kansas City, 1999. p. 60-65. DAVIS JR., C. A.; OLIVEIRA, P. A. SIG interopervel e distribudo para administraes municipais de grande porte. Informtica Pblica, v. 4, n.1, p. 121-141, 2002. EGENHOFER, M. A Model for Detailed Binary Topological Relationships. Geomatica, v. 47, n.3 & 4, p. 261-273, 1993. EGENHOFER, M. J.; FRANZOSA, R. D. Point-set topological spatial relations. International Journal of Geographic Information Systems, v. 5, n.2, p. 161-174, 1991. EGENHOFER, M. J.; HERRING, J. A mathematical framework for the definition of topological relationships. In: 4th International Symposium on Spatial Data Handling. 1990. p. 803-813. ELMASRI, R.; NAVATHE, S. Fundamentals of Database Systems. Pearson Education, 2004.
Referncias
135
FONSECA, F. Ontology-Driven Geographic Information Systems.Orono: University of Maine, 2001.Ph.D. Thesis, Dept of Spatial Information Science and Engineering, 2001. FONSECA, F.; EGENHOFER, M.; DAVIS, C.; BORGES, K. Ontologies and Knowledge Sharing in Urban GIS. Computer, Environment and Urban Systems, v. 24, n.3, p. 232-251, 2000. FONSECA, F.; EGENHOFER, M.; DAVIS, C.; CMARA, G. Semantic Granularity in Ontology-Driven Geographic Information Systems. AMAI Annals of Mathematics and Artificial Intelligence - Special Issue on Spatial and Temporal Granularity, v. 36, n.1-2, p. 121-151, 2002. FRANK, A. U. Spatial concepts, geometric data models, and geometric data structures. Computers & Geosciences, v. 18, n.4, p. 409-417, 1992. FRANK, A. U.; GOODCHILD, M. F., 1990, Two perspectives on geographical data modeling, Santa Barbara (CA), National Center for Geographic Information and Analysis (NCGIA). GOYAL, R. K. Similarity assessment for caardinal directions between extended spatial objects. Orono, Maine: University of Maine, 2000.PhD Thesis, 2000. KSTERS, G.; PAGEL, B.; SIX, H. GIS application development with GeoOOA. International Journal of Geographic Information Science, v. 11, n.4, p. 307-335, 1997. LAENDER, A. H. F.; FLYNN, D. J., 1994. A semantic comparison of modelling capabilities of the ER and NIAM models. In: ELMASRI, R.; KOURAMAJIAN, V.; THALHEIM, B., eds., Entity-Relationship Approach - ER'93, Springer-Verlag, p. 242-256. LI, Z.; OPENSHAW, S. Algorithms for automated line generalization based on a natural principle of objective generalization. International Journal of Geographic Information Systems, v. 6, n.5, p. 373-389, 1992. LISBOA FILHO, J., 1997, Modelos de dados conceituais para sistemas de informao geogrfica, Porto Alegre, UFRGS. MARK, D. M.; FRANK, A. U., 1990, Language issues for geographical information systems, National Center for Geographic Information and Analysis (NCGIA). MARTINS NETTO, V. Proposta de esquema conceitual para um banco de dados de limpeza urbana no municpio de Belo Horizonte.Belo Horizonte: PRODABEL, 2003.Monografia de especializao, Curso de Especializao em Informtica Pblica, 2003.
136
OLIVEIRA, J. L.; PIRES, F.; MEDEIROS, C. M. B. An environment for modeling and design of geographic applications. GeoInformatica, v. 1, n.1, p. 29-58, 1997. OPEN GIS CONSORTIUM, 1999, OpenGIS Simple Features Specification for SQL - Revision 1.1. PARENT, C.; SPACCAPIETRA, S.; ZIMANYI, E. Spatio-temporal conceptual models: data structures + space + time. In: 7th International Symposium on Advances in Geographic Information Systems (ACM GIS'99). Kansas City, 1999. p. 26-33. PEUQUET, D. J. A conceptual framework and comparison of spatial data models. Cartographica, v. 21, p. 66-113, 1984. PREPARATA, F. P.; SHAMOS, M. I. Computational geometry: an introduction. New York: Springer-Verlag, 1985. PRETO, A. G. MetaSIG: ambiente de metadados para aplicaes de sistemas de informaes geogrficos.Rio de Janeiro (RJ): Instituto Militar de Engenharia, 1999.Dissertao de mestrado, 1999. RATIONAL SOFTWARE CORPORATION, 1997, The Unified Modeling Language: notation guide, version 1.1. RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W. Object-oriented Modeling and Design. Prentice-Hall, 1991. SHEKHAR, S.; COYLE, M.; GOYAL, B.; LIU, D.; SARKAR, S. Data models in geographic information systems. Communications of the ACM, v. 40, n.4, p. 103-111, 1997. SOUZA, L. A.; DELBONI, T.; BORGES, K. A. V.; DAVIS JR., C. A.; LAENDER, A. H. F. Locus: um localizador espacial urbano. In: VI Simpsio Brasileiro de GeoInformtica (GeoInfo 2004). Sociedade Brasileira de Computao (SBC), Campos do Jordo (SP), 2004. p. 467-478. VOLL, V. L. Utilizao de SIG na anlise de aspectos sociais do garimpo de diamantes em Coromandel, MG.Belo Horizonte: UFMG, 2002.Monografia de especializao, Curso de Especializao em Geoprocessamento, 2002. WORBOYS, M. F.; HEARNSHAW, H. M.; MAGUIRE, D. J. Object-oriented data modelling for spatial databases. International Journal of Geographic Information Systems, v. 4, n.4, p. 369-383, 1990.
4 Modelos espao-temporais
Taciana de Lemos Dias Gilberto Cmara Clodoveu A. Davis Jr.
4.1
Introduo
Este captulo apresenta recentes estudos de modelos espao-temporais, correspondentes as iniciativas para modelar o comportamento de objetos em sua trajetria espao-temporal, visando sua representao em um sistema de informao. A maioria das aplicaes de tecnologia de geoinformao utiliza representaes estticas de fenmenos espaciais. Isto se deve ao fato de que a principal abstrao utilizada em Sistemas de Informao Geogrficas (SIG) o mapa. No entanto, um significativo conjunto de fenmenos espaciais, como o cadastro urbano, uso e ocupao da terra, fluxos hidrolgico e poluio so inerentemente dinmicos e as representaes estticas comumente utilizadas no os capturam de forma adequada. Deste modo, um dos grandes desafios da geoinformao o desenvolvimento de modelos espao-temporais, que sejam capazes de representar adequadamente fenmenos que variam tanto no espao como no tempo. Modelos espao-temporais renem dois aspectos distintos: a escolha de conceitos adequados do espao e do tempo e a construo de representaes computacionais apropriadas correspondentes a esses conceitos. No caso das representaes espaciais estticas, os Captulos 1 e 3 apresentam as diversas alternativas existentes, juntamente com detalhes de implementao e de modelagem de aplicaes. Neste captulo, damos
138
nfase representao temporal e construo de modelos semnticos apropriados ao tratamento de mudanas espao-temporais. A viso do espao (do grego choros) e do tempo (chronos) uma experincia subjetiva do ser humano. O espao e o tempo se misturam ao se descrever uma realidade (Kavouras, 2001). Podemos modelar a superfcie da terra usando geo-objetos, correspondentes a parcelas do solo, ou usando geo-campos, indicando a variao espacial da vegetao da mesma rea. Geo-objetos podem ser estticos, como uma montanha; mudar de lugar, como o traado de uma linha frrea, ou se movimentar, como um carro (Frank, 1997). Conforme a semntica associada ao geoobjeto, suas caractersticas espaciais (incluindo forma geomtrica e localizao) e no espaciais (atributos alfanumricos) podem sofrer alteraes ao longo do tempo. Para produzir uma representao do mundo real com o objetivo de elaborar um sistema de informao espao-temporal muitas questes precisam ser investigadas e respondidas (Cheylan, 2001). Essas questes envolvem a viso de mundo inerente ao sistema, as regras aplicveis, o comportamento dos objetos ao longo do tempo, a interpretao da variao do tempo, a natureza das mudanas e a influncia dos processos de medida. Por este motivo, o uso de ontologias para modelagem espaotemporal um dos principais temas de pesquisa nessa rea atualmente (Worboys e Duckhan, 2004) (Grenon e Smith, 2003). Os conceitos envolvidos no so bvios e tm se mostrado de difcil formalizao (Smith e Mark, 1998) (Frank, 2003) (Fonseca et al., 2002) (Fonseca, et al., 2003). Em particular quando lidam com aspectos espaciais e temporais simultaneamente, ontologias buscam capturar as propriedades dos objetos e os conceitos que determinam sob que condies eles so criados ou deixam de existir, e quais mudanas podem ocorrer em suas caractersticas (Grenon e Smith, 2003). Uma ontologia deve incluir categorias de espao e tempo, alm dos conceitos ligados ao histrico dos objetos e s intenes de mudana. Ontologias espao-temporais representam um conjunto de conceitos que lidam com a natureza do espao, do tempo e das interaes espao-temporais (Peuquet, 2001).
Representao do tempo
139
Ainda no existe um consenso sobre as tcnicas de modelagem de dados espao-temporais, ou mesmo sobre extenses das tcnicas de modelagem de dados geogrficos atualmente existentes para refletir as necessidades de aplicaes que envolvam simultaneamente tempo e espao. Optamos por apresentar alternativas de representao especficas, deixando a cargo do leitor a escolha do(s) modelo(s) que melhor se ajusta(m) s suas necessidades. 4.2 Representao do tempo
Uma representao temporal considera os aspectos de ordem, variao e granularidade (Edelweiss e Oliveira, 1994) que sero analisados a seguir. 4.2.1 Ordem
Quanto ordem, o tempo pode ser consecutivo e linearmente ordenado, ramificado ou circular (Worboys e Duckhan, 2004). O tempo linearmente ordenado possui uma ordenao entre quaisquer dois pontos: se t e t so dois pontos diferentes no tempo, e < o operador de ordem de precedncia temporal, apenas uma das expresses verdadeira: (1) t < t ou (2) t < t (Figura 4.1).
t t < t
Figura 4.1 Tempo consecutivo e linearmente ordenado .
O tempo ramificado implica na possibilidade de existncia de diferentes histrias futuras ou passadas. Podem existir vrias verses do passado correspondentes a uma situao do presente, ou existir vrios cenrios para uma situao futura (Figura 4.2).
140
CENRIO1 PASSADO FUTURO CENRIO 2

PASSADO VERSO 1
VERSO 2 VERSO 3 VERSO 4
FUTURO
(a)
(b)
Figura 4.2 Tempo ramificado (Fonte: adaptado de Worboys e Duckhan , 2004).
O tempo ramificado no futuro possui diferentes sucessores (Figura 4.2 a), e ramificado no passado possui diferentes antecessores (Figura 4.2 b). A maioria das representaes da realidade utiliza um passado linear e um futuro ramificado (Edelweiss e Oliveira, 1994). Eventos recorrentes so representados pelo tempo circular. Neste caso, a periodicidade de sua ocorrncia faz com que sempre se volte mesma referncia de tempo. Um exemplo o ciclo anual de produo de mudas de plantas como mostra a Figura 4.3.
PRIMAVERA
VERO
INVERNO
PODA ADUBA
OUTONO
COLOCA SEMENTEIRA TIRA MUDA
Figura 4.3 Tempo circular.
Representao do tempo
141
4.2.2
Variao
Quanto variao, o tempo pode ser contnuo ou discreto. Entendemos, em geral, que o tempo contnuo por natureza. Para sua representao computacional, necessrio utilizar uma representao discreta do tempo, na qual a variao temporal corresponde a uma linha de tempo, composta por uma seqncia de chronons consecutivos e com idntica durao. Um chronon um intervalo temporal que no pode ser decomposto. Ele considerado a menor unidade de durao do tempo de um sistema. A durao de tempo pode ser fixa, como uma hora, ou varivel, como um ms (Figura 4.4).
Chronon = 1 ano
Chronon = 1 ms
Figura 4.4 Diferentes granularidades temporais.
Um eixo temporal uma seqncia de pontos consecutivos com tempo de variao discreto, linear e finito. A variao do tempo discreto classificada como ponto-a-ponto, escada e funo (Renolen, 1997). A variao ponto-a-ponto considera valores vlidos do tempo somente nos pontos temporais definidos. Na variao escada, o valor vlido do tempo ocorre desde o momento de sua definio at o momento em que outro valor definido. A variao do tempo discreto pode ser determinada por uma funo de interpolao para determinar valores em pontos onde no se tem valor, configurando a variao por funo. Esses tipos de variaes so mostradas na Figura 4.5.
142
Contnuo
e
Ponto-a-ponto
e
Escada
e
Funo
e
Figura 4.5 Variao do tempo contnuo e discreto.
4.2.3
Granularidade
A granularidade temporal um parmetro que corresponde durao de um chronon. Pode-se considerar, simultaneamente, diferentes granularidades (ano, ms, dia e minuto), para possibilitar uma melhor representao da realidade. Pesquisas de opinio, por exemplo, podem ser realizadas anualmente ou mensalmente (Edelweiss e Oliveira, 1994), porm esperamos obter uma representao mais fiel ao fenmeno real com a granularidade mensal. Os elementos primitivos de representao da granularidade do tempo so instante, intervalo e elemento temporal. A granularidade depende da variao do tempo considerada. Para o tempo continuamente varivel, um instante um ponto no tempo cuja durao infinitesimal, sendo que entre dois pontos no tempo sempre existir outro ponto. Se a variao de tempo for discreta, um instante representado por um chronon no eixo temporal. Um intervalo um subconjunto de pontos do eixo temporal equivalente ao tempo decorrido entre dois pontos. Considerando o tempo discreto, o intervalo representado por um conjunto finito de chronons consecutivos; no caso de tempo contnuo, existem infinitos instantes de tempo em um intervalo. Um elemento temporal a unio finita de intervalos de tempo, produzindo um novo elemento temporal para as operaes de conjunto de unio, interseo e complemento (Langran, 1993). O tempo pode ainda ser absoluto ou relativo. O tempo absoluto est associado a um fato com granularidade definida. O tempo considerado relativo quando se refere validade de outro fato. A definio do tempo pode tambm ser explcita ou implcita. Ela explicitada atravs de um
Dimenso temporal
143
rtulo temporal (timestamp) associado a cada valor de atributo de um objeto. A definio de tempo necessria para utilizao de uma linguagem de lgica temporal implcita, como no caso do tempo relativo (Edelweiss e Oliveira, 1994). 4.3 Dimenso temporal
A dimenso temporal determina as representaes de tempo num banco de dados. Essas dimenses auxiliam na definio da composio histrica do geo-objeto. Uma anlise de dados espao-temporais requer uma distino entre o momento em que o evento ocorreu, conforme a representao adotada (tempo de validade), e o momento em que essa ocorrncia foi registrada no banco de dados (tempo de transao), que indica a partir de quando a informao correspondente ao evento se tornou disponvel para o usurio. Por motivos diferentes, importante, por exemplo, saber quando dados que indicam a possibilidade de um desastre foram inseridos no banco de dados e quando eles foram coletados ou identificados em campo. As informaes temporais, nesse caso, permitem analisar se dados que indicam um possvel desastre foram identificadas e/ou registrados no banco de dados em tempo de apoiar o processo de tomada de deciso. 4.3.1 Tempo em bancos de dados
Os SGBD podem ser classificados, (Tabela 4.1), de acordo com seu suporte dimenso temporal (Worboys e Duckhan, 2004) (Snodgrass, 1992). Eles podem ser estticos (instantneos), de tempo de validade (histricos), de tempo de transao (rollback) e bitemporais (Snodgrass, 1990) (Al-Taha e Barrera, 1994) (Edelweiss e Oliveira, 1994). Um SGBD esttico tambm denominado banco de dados de instantneos, por no suportar nenhuma dimenso temporal. Neste caso, o SGBD suporta um nico estado, o mais recente, e no possvel realizar comparaes entre estados. Um SGBD de tempo de validade registra fatos de acordo com o tempo de ocorrncia do evento, e possibilita uma recuperao de histrico. No possvel recuperar o instante em que os dados foram inseridos no banco de dados. Um SGBD de tempo de transao registra o instante da insero de dados no banco,
144
possibilitando uma recuperao de dados para desfazer uma transao (rollback). No entanto, no realiza o registro de quando o fato ocorreu. Um SGBD bitemporal registra tanto o tempo de validade quanto o de transao, sem qualquer interao entre eles, no sendo possvel uma atualizao do passado. possvel acessar o histrico das transaes realizadas e da ocorrncia dos eventos. O tempo pode ser associado a cada valor no banco de dados. O tempo de validade pode ser representado em um banco de dados temporal por um ponto no tempo e com variao por escada ou intervalo de tempo. O tempo de transao representado por um chronon nico.
Tabela 4.1 Classificao de SGBD de acordo com a dimenso temporal (Fonte: adaptado de Snodgrass, 1992). Sem tempo de Transao Banco de dados esttico Banco de dados por tempo de validade Com tempo de Transao Banco de dados por tempo de transao Banco de dados bitemporal
Sem tempo de Validade Com tempo de Validade
Worboys (1998) props um modelo conceitual para objetos espaotemporais denominado complexo espao-bitemporal. Este complexo resultante da composio de classes primitivas de geo-objetos com os componentes temporais dos geo-objetos. O componente temporal dado por uma estrutura, denominada elemento bitemporal (BTE), cuja semntica representa simultaneamente o geo-objeto de acordo com o tempo de validade do evento e com o tempo de transao do banco de dados (Figura 4.6). Um BTE a unio de um conjunto finito de produtos cartesianos (ID x IE) de intervalos de tempo de banco de dados (ID) e de chronons de evento (IE), assumindo que o domnio temporal contm elementos de - a +, representando desde o passado indefinido a um futuro incerto (Worboys, 1994).
Dimenso temporal
145
1997 Tempo de Validade1996 do Evento 1995 1994 1994 1995 1996 1997 Tempo de Transao do Banco de Dados
Figura 4.6 Elemento Bitemporal (Fonte: adaptado de Worboys e Duckham, 2004).
Por esse modelo, geo-objetos so decompostos em representaes geomtricas espaciais primitivas, como pontos e linhas, associadas a um elemento bitemporal. Assim, um complexo espao-bitemporal pode ser representado atravs de duas dimenses espaciais e duas dimenses temporais, como mostra a Figura 4.7. Na Figura 4.7, em 1995 todos os elementos primitivos espaciais pertenciam ao banco de dados e eram eventos vlidos. O ponto P2 era valido em 1994 e foi registrado em 1995. Em 1994 teve o registro do ponto P3 e das linhas L2 e L3 no banco de dados, e estes eram um evento vlido em 1994 e 1995. Foi registrado no banco de dados em 1995 o ponto P2, vlido em 1994 e 1995.
1995 1994 1994 1995 P1 L1 P2 L2 L4 1995 P4 L3 P3 1994 1994 1995 1995 1994 1994 1995
Figura 4.7 Complexo espao-bitemporal (Fonte: adaptado de Worboys e Duckham, 2004).
146
Um complexo espao-bitemporal possibilita as operaes Lifetime, Max-S-Project e Min-S-Project. A operao Lifetime projeta um objeto espao-temporal em um perodo temporal ou bitemporal no qual ele possua existncia. A operao Max-S-Project projeta o objeto espaotemporal sobre toda a sua extenso espacial ou sobre todas as partes do objeto que j possuram existncia em algum intervalo de tempo. A MinS-Project projeta o objeto espao-temporal em sua maior extenso comum, que corresponde s partes que possuram existncia em todo o tempo de vida do objeto (Worboys, 1998). As consultas temporais utilizam lgica temporal para recuperar os valores (tempo de transao e/ou de validade). Nas consultas sobre um elemento temporal, o espao visto como um conjunto de identificadores, correspondendo a pesquisas em banco de dados temporais. Muitas consultas demandam recuperaes histricas complexas. A seleo pode ser feita sobre dados, espao, valores temporais ou ambos. O grande desafio dos pesquisadores na rea de recuperao de informao espao-temporal explorar a consistncia e completeza das propostas existentes e buscar solues em relao integridade espaotemporal, consultas de multi-verses ou de verses histricas longas e complexas (Cheylan, 2001). 4.3.2 Relacionamentos espao-temporais
A representao do tempo e do espao implica na combinao de relacionamentos temporais e espaciais em uma estrutura integrada (Claramunt e Juang, 2000). Os relacionamentos entre intervalos temporais utilizam operadores booleanos de igualdade e desigualdade de instantes, de maneira semelhante definio das matrizes de 4 e 9 intersees usadas em relacionamentos espaciais (Egenhofer e Franzoza, 1991). As relaes entre intervalos de tempo implicam na definio de um operador de precedncia, associado a um conjunto de operadores tpicos da teoria de conjuntos, tais como unio, interseo, incluso e igualdade. Allen (1983) definiu sete relaes (Figura 4.8): before (antes de), meets (toca), during (durante), finishes (finaliza junto com), equal (igual a), overlaps (sobrepe) e starts (inicializa junto com). Claramunt e Juang (2000) apresentaram 56 possveis relacionamentos espao-
Identidade, vida e evoluo de geo-objetos
147
temporais atravs da combinao desses sete relacionamentos temporais e dos 8 relacionamentos espaciais derivados da matriz de 4 intersees.
Figura 4.8 Predicados temporais (Fonte: adaptado de Allen, 1993).
4.4 4.4.1
Identidade, vida e evoluo de geo-objetos Identidade de geo-objetos
A identidade uma caracterstica imutvel de um geo-objeto. Ela fundamental para a representao espao-temporal, pois possibilita a distino entre geo-objetos independentemente de sua estrutura, valores e atributos, incluindo a atributos chave. Por exemplo, a identidade de uma pessoa no muda se o nmero de sua carteira de motorista for alterado. Note a diferena entre o conceito de identidade e o de identificador, ou de chave primria, usual em bancos de dados, que empregado no sentido de atributo cujo valor no se repete. Consideramos aqui que o valor de qualquer atributo pode mudar, dentro das regras semnticas que levaram sua definio durante a modelagem; por outro lado, a mudana da identidade de um objeto s ocorre em situaes particulares, em que se pode afirmar que a natureza do objeto mudou o suficiente para que consideremos seu novo estado como sendo um objeto inteiramente diferente. Por exemplo, quando um lote urbano dividido em dois, uma das partes pode reter a identidade do lote original (no caso, apenas um dos seus atributos mudou: a forma
148
geomtrica). A outra parte constitui um lote novo, e que portanto recebe uma nova identidade. A existncia de um geo-objeto est associada manuteno da sua identidade ao longo do tempo. As premissas das propostas para se implementar mudanas baseadas em identidade de geo-objetos so os critrios de imutabilidade, reusabilidade e singularidade da identidade. O registro das mudanas que ocorrem em geo-objetos esto fundamentadas pelos conceitos de orientao por objetos e de bancos de dados temporais. Essas propostas se baseiam na ordem temporal de estados de identidade e o vnculo temporal com os predecessores ou com o geo-objeto original (Al-Taha e Barrera, 1994). 4.4.2 Vida e evoluo de geo-objetos
Segundo Frank et al. (2001) as mudanas de geo-objetos podem ser de vida, genealogia e movimento. A noo de vida corresponde ao conjunto das mudanas de caractersticas de um geo-objeto durante sua existncia, caracterizada pela sua identidade. Um lote, por exemplo, pode ter alterados o seu proprietrio ou sua zona de uso do solo, sem que se torne um novo lote. Essas mudanas, portanto, fazem parte do registro de eventos que ocorreram ao longo da vida do lote. A genealogia corresponde a um link temporal para o gerenciamento de sucessivas verses temporais de um objeto, como no caso em que se usa um rtulo temporal (timestamp). similar a uma rvore genealgica familiar, no sentido em que um geo-objeto pode dar origem a outro, permanecendo ligado a ele como seu predecessor. O movimento contempla mudanas de expanso ou contrao, deformao e localizao, como as que ocorrem na ampliao ou reduo de subdivises administrativas, no deslocamento simultneo ao derretimento de um iceberg, ou no caso de objetos que se deslocam constantemente, como veculos. Cheylan (2001) props quatro classificaes para as mudanas espaciais elementares. A primeira classificao a dos geoobjetospermanentes. Eles recebem esse nome por que permanecem
149
inalteradas a sua forma e localizao e podem ser alteradas as suas caractersticas no-espaciais. A segunda classificao a dos geo-objetos variveis. Seu tamanho e topologia podem variar sem gerar novos geoobjetos. Neste caso, so mantidas a forma e a identidade dos geo-objetos e so geradas mltiplas verses da mesma unidade espacial no tempo. A terceira classificao a dos geo-objetos modificveis. Sua modificao ocorre atravs da recomposio de um determinado espao, adotando operaes de partio dinmica (diviso e juno). Os objetos podem mudar a forma, topologia e gerar novos objetos. Isso ocorre com os lotes urbanos e seus limites dentro de uma mesma quadra (Figura 4.9).
Figura 4.9 Situaes de mudanas espaciais no tempo (Fonte: adaptada de Cheylan, 2001).
A quarta classificao a dos geo-objetos que mudam ou dinmicos. Eles admitem mudanas na forma, topologia, atributo, localizao e podem gerar novos objetos.
150
O conceito de vida vlido para todas as situaes de mudanas, mas suficiente somente para o tipo de mudana de geo-objetos permanentes. A noo de movimento afeta os geo-objetos que variam e mudam, mas suficiente somente para os que variam. A noo genealgica afeta os geoobjetos que modificam e mudam, mas suficiente somente para os que modificam (Cheylan, 2001). Algumas regras de mudanas durante a vida ou existncia de um geoobjeto, so determinadas pelas operaes que definem como ele adquire, muda ou perde a identidade ao longo do tempo (Figura 4.10). Essas operaes so denominadas construtores temporais, e podem ocorrer em um geo-objeto ou entre geo-objetos diferentes (Medak, 1999).
Perde a existncia temporariamente Passa a existir
Volta a existir
Perde a existncia e permanece a sua Histria
t1
t2
t3
eixo temporal
Figura 4.10 Linha da vida - Lifeline (Fonte: adaptada de Medak, 2001).
Uma mudana pode ser incremental ou contnua. Em uma escala microscpica, todo geo-objeto sofre mudanas constantemente. Mas, em uma escala macroscpica, importante uma distino entre duas situaes conceituais: (a) geo-objetos cujas propriedades podem ser consideradas estveis, durante um certo tempo, at que ocorre uma mudana instantnea (por exemplo, quando um lote muda de proprietrio); (b) geo-objetos cujas propriedades mudam constantemente, porm as representaes so apenas capazes de capturar instantneos temporais (snapshots) (por exemplo, no registro da
151
temperatura do ar em uma estao meteorolgica). No primeiro caso, considera-se que o objeto estvel entre mudanas e, no segundo, o objeto est sujeito a mudanas contnuas. Quanto sua existncia diante da ocorrncia de mudanas, os geoobjetos podem ser classificados como continuants e ocurrents. Objetos continuant so capazes de permanecer com a mesma identidade e de existir por um longo tempo, como um lote, um planeta ou um animal. Por outro lado, objetos ocurrent acontecem em um determinado tempo e tm curta durao, como, por exemplo, um evento da picada de um mosquito, uma ao de remembramento de lotes, um processo de deslizamento de terra ou a atividade de cortar uma rvore (Worboys, 2005). Geo-objetos associados a parties definidas por convenes humanas, como no caso de informaes sobre a realidade de um sistema de cadastro urbano, demandam consultas complexas, do tipo selecionar os lotes pblicos que foram criados pela juno de lotes particulares e que perderam parte de sua rea para formar logradouro(s). Por esta razo, alguns pesquisadores tm dedicado especial ateno elaborao de construtores capazes de modelar e gerenciar relacionamentos temporais entre objetos, considerando sua identidade. (Al-Taha e Barrera, 1994) (Hornsby e Engenhofer, 1997) (Hornsby e Engenhofer, 1998) (Hornsby e Engenhofer, 2000). A evoluo de geo-objetos somente pode ser recuperada pela identidade de um geo-objeto ou sua localizao espacial. A identidade de um geo-objeto tem sido apresentada como uma parte da semntica associada aos processos de mudanas espao-temporais. Apresentamos, a seguir, as operaes propostas considerando a identidade de geo-objetos. Pode-se recuperar toda a evoluo histrica de um geo-objeto atravs de sua identidade, desde que haja uma conexo genealgica entre objetos. Alternativamente, pode-se determinar as mudanas ocorridas em um determinado espao conhecendo-se apenas sua localizao. fundamental poder determinar, em qualquer situao, que mudanas permitem que o geo-objeto permanea o mesmo (i.e., mantenha a sua
152
identidade apesar das mudanas) e que mudanas fazem com que o objeto evolua para outro(s), deixando de existir com aquela identidade. 4.4.3 Operaes de mudana baseadas na identidade
Para demonstrar as possveis mudanas de estado relativas identidade de objetos, Hornsby e Egenhofer (1997, 1998, 2000) desenvolveram uma linguagem visual pictrica, denominada CDL (Change Description Language). A CDL permite descrever cenrios atravs da seqncia de transies da identidade de objetos ao longo do tempo. Trata-se de um modelo qualitativo, baseado na seqncia temporal dos eventos, e que possui extenses para representar relacionamentos espaciais, associaes entre geo-objetos e propriedades de geo-objetos. A Figura 4.11. apresenta algumas primitivas da CDL. Existem primitivas que indicam que um geo-objeto pode nunca ter existido, existe no tempo atual ou existiu em algum tempo anterior, mas no possui existncia no tempo atual. O geo-objeto pode possuir um vinculo temporal com a sua histria ou no. A primitiva de transferncia de propriedade corresponde cpia de propriedades e transio de estados em mesmo geo-objeto ou entre geo-objetos diferentes. A transmisso do tipo emisso corresponde substituio de um geo-objeto por outro do mesmo tipo, mantendo as propriedades, e a transio do tipo separao subentende um cenrio de diviso da geometria.
153
A
Objeto no existe e no possui histria Objeto existe
A
Objeto no existe e possui histria
(a)
Transio do tipo separao
Transferncia Transio entre Transioentre de propriedade mesmo objeto objetos diferentes
Transio do tipo emisso
(b)
Figura 4.11 a) Primitivas de estados da identidade de geo-objetos e b)Primitivas de tipos de transio (Fonte: adaptada de Hornsby e Egenhofer (1997, 2000)).
A CDL usada aqui para facilitar o entendimento das semelhanas e diferenas existentes entre as diversas propostas de operaes de mudana baseadas na identidade descritas na literatura (Clifford e Croker, 1988) (Chu et al., 1992) (Al-Taha e Barrera, 1994) (Hornsby e Egenhofer, 1997, 1998 e 2000) (Medak, 1999 e 2001) (Al-Taha, 2001). As propriedades de um geo-objeto podem ser transmitidas para outro geo-objeto j existente ou criado especificamente para receb-las. No ltimo caso, o geo-objeto origem em geral destrudo, porm mantido como predecessor do novo geo-objeto. Um geo-objeto pode dar origem a um novo geo-objeto ou ser substitudo por outro objeto. So criados links temporais entre os geo-objetos origem e os seus sucessores. As primeiras operaes de identidade definidas foram create e destroy. A operao create cria o vnculo temporal (predecessores) com o(s) objeto(s) origem, sendo que somente um geo-objeto que nunca existiu pode no possuir predecessores. A operao destroy elimina o geo-objeto e a sua histria. Clifford e Croker (1988) acrescentaram as operaes kill e reincarnate. A operao kill suspende a existncia de um geo-objeto temporariamente, sem destruir a sua identidade, e a operao reincarnate ressuscita um
154
geo-objeto suspenso. Essas operaes so apresentadas na Tabela 4.2, com os nomes das operaes por autor e a sua representao em CDL.
Tabela 4.2 Operadores bsicos de identidade de geo-objetos Al-taha e Barrera (1994) create destroy kill reincarnate Hornsby e Engenhofer (1997) create destroy eliminate reincarnate Medak (1999) create remove destroy resume CDL (2000)
A
A
A A
Chu et al. (1992) propuseram as operaes evolution, fission e fusion (Tabela 4.3). A operao evolution substitui a identidade atual por uma nova identidade. A fission cria novas identidades a partir de um geoobjeto existente com o sentido de subdiviso. A fusion cria uma nova identidade a partir de outras, com o sentido de fuso. Essas operaes destroem todos os geo-objetos origem. Hornsby e Engenhofer (1997 e 1998) incluram as operaes generate, mix e splinter (Tabela 4.3). As operaes generate e mix possuem a semntica da operao fusion, porm na operao generate todos os geoobjetos origem so preservados. Na operao mix, nem todos so destrudos. A operao splinter possui a mesma semntica da fission, porm mantm a existncia do geo-objeto origem.
Identidade, vida e evoluo de geo-objetos Tabela 4.3 Operadores de identidade de geo-objetos Al-taha (1994) evolve e Barrera Hornsby e Engenhofer Medak (1997) (1999) metamorphose evolve
155
CDL (2000)
B
A
A
fuse
merge
fusion
generate
B
A
mix
fission
divide
fission
A
B A
splinter
A
Al-Taha e Barrera (1994) acrescentaram ainda as operaes spawn e identify (Tabela 4.4). A operao spawn gera novas identidades a partir de um geo-objeto existente, e s difere da operao evolution porque mantm o geo-objeto origem. A operao identify funde um conjunto de
156
geo-objetos em um dos geo-objetos do conjunto, destruindo os demais (Al-Taha, 2001).

Tabela 4.4 Operadores de identidade Spawn e Identify Al-taha e Barrera Hornsby e Engenhofer Medak (1994) (1997) (1999) spawn spawn
A
CDL (2000)
B
A
C
identify
Medak (1999) formalizou uma proposta de 14 operadores de identidade que contemplam as propostas de Hornsby e Engenhofer (1997, 1998) e de Al-Taha e Barrera (1994), acrescentando a operao restructure. A operao restructure (Figura 4.12) foi criada para processos de reestruturao que envolvem vrios objetos. So criados novos objetos atravs de um processo de rediviso interna de um espao. Essa operao no mantm a ligao de cada objeto origem com o seu sucessor. Um exemplo dessa operao uma rediviso de lotes em uma quadra.
(a)
(b)
Figura 4.12 Unificao dos lotes A, B, C originais (a) atravs da operao reestruct gerando os Lotes D, F, E.
Exemplo de modelo espao-temporal: cadastro urbano
157
Medak (1999) concluiu que as operaes bsicas para a mudana de um simples geo-objeto so as operaes relacionadas a sua existncia (Tabela 4.2): create, resume, suspend e destroy. Pois, com essas operaes pode-se obter as outras operaes propostas. As propostas de operao baseada na identidade de geo-objetos evoluram muito em termos da identidade do geo-objeto, permitindo que (a) um geo-objeto seja suspenso para ser recuperado no futuro, no sentido de retormar a existncia do geo-objeto; (b) existam vnculos temporais entre identidades de geo-objetos para composio da histria do geo-objeto; (c) as operaes propostas sejam obtidas atravs da composio de um conjunto de operaes bsicas. No entanto, mesmo tendo sido desenvolvidas considerando objetos espaciais, essas propostas no so detalhadas o bastante para considerar o efeito das operaes sobre as propriedades espaciais e no espaciais dos objetos e os seus relacionamentos. 4.5 Exemplo de modelo espao-temporal: cadastro urbano
Um sistema de informao cadastral geralmente, uma ferramenta de responsabilidade pblica. Ele essencial para a administrao das cidades e para os planejamentos urbanos e sociais, envolvendo reas responsveis pelas informaes legais, sociais, administrativas, econmicas e de meio ambiente (Al-Taha, 2001). Apresentamos, a seguir, um exemplo baseado na realidade do Cadastro Tcnico Municipal (CTM) do municpio de Belo Horizonte. Esse exemplo refere-se a um projeto de implantao de uma linha de metr de superfcie, hoje existente, sendo que as datas apresentadas so fictcias. Os geo-objetos considerados so: linha de metr (para representar a rea de um segmento da linha de metr), lote, quadra, logradouro (representando trecho de logradouro) e rea remanescente. reas remanescentes, para o CTM, so sobras de reas oriundas de um processo de desapropriao. Elas so remanescentes por no possurem rea suficiente e nem as caractersticas necessrias, determinadas pela lei de regulamentao do solo, para serem definidas como um lote urbano.
158
Adotamos tambm o polgono como representao espacial e o ano para a representao da granularidade temporal. A Figura 4.13 mostra o impacto da mudana na realidade da cidade. Essa mudana pode ser observada atravs da representao vetorial dos geo-objetos antes da implantao da linha de metr (Figura 4.13 a) e da imagem aps a sua implantao (Figura 4.13 b). A imagem mostra que a rea interna aos limites da linha de metr passou por grandes mudanas: foram demolidos trechos de logradouros e edificaes; deixaram de existir lotes, quadras e logradouros; e, surgiram a rea do metr e a linha de metr.
(a)
(b)
Figura 4.13 rea afetada pela linha de metr antes (a) e depois da sua implantao (b) (Fonte: cadastro CTM da Prodabel).
4.5.1
Elemento temporal
Demonstramos a seguir a importncia de ter o elemento bitemporal associado representao espacial para informaes urbanas. Foi registrado no banco de dados do CTM, em 2/5/1996, que a previso de implantao da linha de metr seria em 20/3/1998. Depois, em 1/10/1998, registrou-se que a linha de metr foi implantada em 3/9/1998. Mas, em 7/12/1998 descobriu-se que o dado de implantao estava incorreto, pois a implantao tinha ocorrido em 3/5/1998 (Tabela 4.5).
Exemplo de modelo espao-temporal: cadastro urbano Tabela 4.5 Tempo bitemporal. Tempo do (tD) 2/5/1996 1/10/1998 7/12/1998 BD Tempo de Evento Significado (tE) 20/3/1998 Implantao prevista 3/9/1998 Implantao 3/5/1998 Correo Implantao
159
Para o planejamento urbano importante saber qual era o tempo previsto para implantao da linha de metr e quando ele foi realmente implantado (tempo de evento). E, alm disso, extremamente relevante identificar o perodo em que a informao de implantao do projeto esteve errada no banco de dados (1/10/1998 a 7/12/1998), tempo de transao. Pois, durante esse perodo, a informao disponvel para apoiar tomada de deciso estava incorreta. O elemento bitemporal possibilita essa distino, porm ainda objeto de pesquisa a possibilidade da alterao do tempo de transao para corrigir a histria passada. 4.5.2 Mudanas espao-temporais
Na Figura 4.14 ilustramos algumas mudanas no parcelamento do solo, durante o perodo de 1994 a 2000. Em 1995, ocorreu uma ao de remembramento dos lotes LA e LB, que originou (criou) o lote LD. Um remembramento pode ocorrer por uma solicitao do proprietrio quando adquire lotes adjacentes. Neste caso, realizada uma operao de juno da geometria. Em 1996, criou-se um projeto para implantao de uma linha de metr de superfcie nessa rea. A linha de metr (LT1) do projeto foi implantada (criada) em 1998. E, ao mesmo tempo, os geoobjetos que deram origem a essa linha de metr perderam a sua existncia. Esses geo-objetos foram: o trecho de logradouro R1, o lote LE e parte dos lotes LC e LF. Tambm, devido a mesma ao, surgiram as reas remanescentes A1 e A2 com a rea restante do logradouro R1 e do lote LF. Alem disso, foi alterada a rea e geometria do lote LC. A seguir, em 2000, uma outra ao de remembramento do lote LD com a rea A1 foi realizada. Essa ao deu origem ao lote LG.
160
LA LB
Q3 LC R1
Q3 LD LC R1 LE LF
Q3 LD LC R1 LE LF
Q3 LD LC LC A1 LT1
Q3 LG LC LT1
LE LF
A2
A2
1994
1995
1996
1998
2000
Figura 4.14 Situaes de mudanas espaciais no tempo pela implantao da linha de metr.
A Figura 4.15 apresenta a CDL do exemplo com as respectivas operaes realizadas e os seus objetos resultantes. Alguns objetos resultantes so intermedirios ( como o LH) por isso no aparecem na Figura 4.14. Eles so gerados para determinar uma melhor composio da histria desses geo-objetos.
LA
FUSION (MERGE)
LA LD LB LC LD
FISSION (SPLINTER)
LD LH LC
LD LH LC
FUSION (MERGE)
LD
LB LC
LC
LC LG
FISSION (SPLINTER)
A1
FUSION (MERGE)
A1
LT1 LT1
R1 LE
R1 LE
R1
R1 LE
R1 LE A2 LF 1998 2000 A2
FISSION (SPLINTER)
A2 LF
LF 1994
LF 1995 1996
LF
Figura 4.15 CDL das operaes baseadas na identidade realizadas para implantao da linha de metr.
Exemplo de modelo espao-temporal: cadastro urbano
161
Sobre a situao apresentada na Figura 4.14, podemos imaginar as seguintes consultas relacionadas vida e evoluo dos geo-objetos: 1. Quais eram as configuraes espaciais dos lotes da quadra Q3 em 1994? 2. Quais eram as configuraes espaciais dos lotes da quadra Q3 utilizadas na cobrana do IPTU entre 1996 e 2000? 3. Quais foram todas as configuraes espaciais do lote LC no perodo de 1994 at hoje? 4. Quais foram os lotes que ficaram sem gua das 8:00 da manh do dia 12 de janeiro at s 20:00 do dia 15 de janeiro de 1998? 5. Quais foram cronologicamente os proprietrios do lote LD? 6. Quais foram s sucessivas taxas anuais de IPTU cobradas do lote LC? 7. Quais foram os imveis que foram desapropriados entre 1998 e 2000? 8. Quais so as quadras que possuem lotes com reas alteradas pela implantao da linha de metr LT1? 9. Quando a pavimentao do logradouro R1 correspondeu a um percentual maior que 40%? 10. Quais os perodos de tempo em que o lote LD no obteve o beneficio de iluminao pblica no ano de 1998? 11. Quais aes geraram mudanas na quadra Q3 entre 1994 e 2000? 12. Quais foram os lotes que deixaram de existir no perodo de 1996 a 2000? 13. Quais lotes foram criados entre 1994 e 1995? 14. Quais geo-objetos deram origem a linha de metr? 15. Como essas aes foram realizadas? Quais foram os objetos origem dessa ao e os objetos resultantes? Como as alteraes
162
foram realizadas nos objetos? Quais foram as operaes utilizadas para gerar a alterao? Qual a lgica utilizada pela operao? Essas consultas buscam recuperar o estado de um geo-objeto, a Histria de uma regio espacial especfica ou de geo-objetos e de um elemento temporal. Como tambm, informaes sobre as aes que promoveram as mudanas. Esse exemplo mostra que ainda so necessrios avanos nas pesquisas para capturar todos os aspectos da dinmica de geo-objetos espaotemporais. Uma ontologia de mudana deve responder a perguntas como (1) que mudanas ocorreram em cada objeto? (2) quando essas mudanas ocorreram?, (3) como as mudanas foram geradas?, (4) quais regras determinaram essas mudanas? e (5) quais foram as causas da mudana? Criar modelos para suportar ontologias de mudanas essencial para que se possam obter informaes dessas mudanas e dos geo-objetos envolvidos (Dias et al., 2004). 4.6 Exemplo de modelo espao-temporal: queimadas na Amaznia
No Brasil, a queima de biomassa vegetal constitui uma prtica de manejo, principalmente, para a criao de gado e a expanso da fronteira agrcola. As queimadas esto amplamente inseridas no processo produtivo da Amaznia e do Cerrado brasileiro e so fatores que impulsionam a expanso agropecuria nestas regies. As queimadas ocorrem todo ano durante a estao seca, sendo no final deste perodo em que ocorre a maior incidncia. A ocorrncia de queimadas acarreta inmeros impactos ambientais, por isso a modelagem de um banco de dados geogrficos que contemple o aspecto temporal de questes relacionadas a desmatamentos e queimadas de grande importncia para a anlise e combate a estes problemas. Essa seo apresenta como exemplo, uma proposta de modelagem de um banco de dados espao-temporal para dados de queimadas. A descrio completa desse trabalho pode ser encontrada em Correia et al. (2004). A modelagem espao-temporal das queimadas foi feita considerandose os focos de calor como eventos isolados que podem ou no ser
Exemplo de modelo espao-temporal: queimadas na Amaznia
163
conectados espacial e temporalmente, formando assim queimadas com variao espao-temporal. Os focos de calor so obtidos atravs de imagens de sensoriamento remoto. Para tanto, cada pixel da imagem onde foram identificados os focos de calor, representado por um ponto com uma regio contgua ao seu redor representando o tamanho nominal dos pixels da imagem (Figura 4.16). Com isso, possvel acompanhar a evoluo dos focos de calor e de queimadas. Ao se realizar uma consulta, pode-se tanto analisar focos de calor quanto queimadas.
Figura 4.16 Modelagem espao-temporal de focos de calor e queimadas.
Alm dos dados de focos de calor, o banco de dados foi projetado de forma a armazenar dados de uma base cartogrfica, dados de legislao, cadastro de imveis e dados de fiscalizao. O processo de desmatamento representado por polgonos que representam talhes de reas desmatadas e que, normalmente, evoluem ao longo do tempo em um processo incremental. Para incluso do processo de desmatamento foi definido um conjunto de operaes sobre as geometrias de entrada do sistema, para possibilitar a construo dos relacionamentos topolgicos e temporais entre os geo-objetos, usando a abordagem descrita em Dias et al. (2004) (juno, separao e destruio).
164
Todos os dados foram incorporados a um SIG de arquitetura em camadas, ou seja, onde os dados descritivos e espaciais so guardados em tabelas relacionais armazenadas em um SGBD objeto-relacional. Sobre esse modelo lgico foi possvel implementar consultas espao-temporais de interesse como : Quais so as reas desmatadas no perodo de 01-062004 a 09-06-2004 e posteriormente queimadas em 17-06-2004? ou As queimadas agrcolas foram mais intensas do que as queimadas florestais no perodo de 01-06-2004 a 09-06-2004 no municpio 9?. A Tabela 4.6 mostra os passos necessrios para a resposta primeira pergunta usando comandos SQL Structured Query Language.
Tabela 4.6 Operaes espaciais para obteno das reas desmatadas entre 01 a 09-06-2004 e posteriormente queimadas em 17-06-2004 Etapas
Seleo dos polgonos das reas desmatadas entre 01-06-2004 e 09-062004 Seleo dos pontos de queimadas em 17-06-2004
Comando SQL
Select object_id, spatial_data into temporary desmatamento from te_polygons_desmatamento where geom_id=(select geom_id from temp_desmatamento where initial_time >= '200406-01' and initial_time <= '2004-06-09'); Select object_id, spatial_data into temporary queimadas from te_points_focos where object_id=(select object_id from att_focos where initial_time = '2004-06-17');
Select t1.object_id, t2.object_id from Seleo das reas desmatadas e depois queimadas t1, desmatamento t2 where within(t1.spatial_data, t2.spatial_data); queimadas
Essas consultas espao-temporais preliminares forneceram os resultados esperados, sinalizando para uma modelagem adequada, o que possibilitou a integrao de dados histricos de desmatamentos e queimadas. Mas faz-se necessrio a ampliao das consultas espao-
165
temporais, com o objetivo de avaliar, mais detalhadamente, o modelo lgico implementado nesse exemplo. 4.7 Leituras suplementares
Como visto neste captulo, o uso de modelos espao-temporais necessrio para uma grande variedade de aplicaes de geoinformao. Devido complexidade envolvida na representao combinada de espao e tempo, estes modelos ainda esto em desenvolvimento, e trata-se de uma rea de pesquisa extremamente ativa. Os principais temas de pesquisa incluem: ontologias de mudana de geo-objetos, modelos espaciais dinmicos, e modelos para objetos mveis. A questo de ontologias de mudana abordada nos artigos de Frank (2003), Grenon e Smith (2003), Worboys e Hornsby (2004), Worboys (2005) e Dias et al. (2004). O tema especfico de identidade de geoobjetos discutido em Medak (1999) e Hornsby e Egenhofer (2000). A questo de aes e atividades discutida em Kuhn (2001). A questo de modelagem dinmica espacial, no discutida em detalhe neste captulo, apresentada em Burrough (1998) e Couclelis (1985). Exemplos de aplicaes so apresentados em Almeida et al. (2003) e Pedrosa et al. (2002). Os problemas de modelagem de objetos mveis so discutidos no Captulo 5 do livro e revisados no artigo de Guting et al. (2003).
166
Referncias
ALLEN, J. F. Maintaining Knowledge about Temporal Intervals. ACM Communications, 26, pp. 832-843, 1983. ALMEIDA, C. M. D.; MONTEIRO, A. M. V.; CAMARA, G.; SOARESFILHO, B. S.; CERQUEIRA, G. C.; PENNACHIN, C. L.; BATTY, M. Empiricism and Stochastics in Cellular Automaton Modeling of Urban Land Use Dynamics. Computers, Environment and Urban Systems, v. 27, n.5, p. 481-509, 2003. Al-TAHA, K., 2001. Identities through time. In: FRANK, A. U.; RAPER, J. e CHEYLAN, J. eds., Life and Motion of Socio-Economic Units, London: Taylor & Francis. AL-TAHA, K; BARRERA, R., 1994. Identities through time. In: International Workshop on Requirements for Integrated Geographic Information Systems, New Orleans, Lousiana, pp. 1-12. BURROUGH, P., 1998. Dynamic Modelling and Geocomputation. In: LONGLEY, P.; BROOKS, S.; MCDONNELL, R.; MACMILLAN, B., eds., Geocomputation: A Primer: New York, John Wiley. CHEYLAN, J., 2001. Time, actuality, novelty and history, In: FRANK, A. U.; RAPER, J. e CHEYLAN, J. eds., Life and Motion of Socio-Economic Units, London: Taylor & Francis. CHU, W. W.; IEONG, I. T.; TAIRA, R. K.; BREANT, C. M., 1992. A temporal evolutionary object-oriented data model for medical image management. Proceedings of the Fifth Annual IEEE 5th Symposium on Computer-Based Medical Systems, Durham, North Carolina. CLARAMUNT, C.; JIANG, B. A representation of relationships in temporal spaces. In: ATKINSON, P. e MARTIN, D. eds., Innovations in GIS VII: GeoComputation, Taylor and Francis, pp. 41-53, 2000. CLIFFORD, J.; CROKER, A. Objects in Time. Database Engineering, v.7, n.4, 189-196. 1988. CORREIA, A. H.; PIROMAL, R. A. S.; QUEIROZ, G. R.; de SOUZA, R. C. M. Modelagem de um Banco De Dados Espao Temporal para Desmatamentos e Queimadas. Anais XII SBSR, Goinia, Brasil, 16-21 abril 2005, INPE, p. 2619-2627.
Referncias
167
COUCLELIS, H. Cellular Worlds: A Framework for Modeling Micro-Macro Dynamics. Environment and Planning A, v. 17, p. 585-596, 1985. DIAS, T.; CAMARA, G.; FONSECA, F.; DAVIS, C. Bottom-Up Development of Process-Based Ontologies. In: GIScience 2004, 2004,College Park, MA. AAG. EDELWEISS, N.; OLIVEIRA, J. P. M , 1994. Modelagem de Aspectos Temporais de Sistemas de Informao. Recife, UFPE-DI. P. EGENHOFER, M. J.; FRANZOSA, R. Point-Set Topological Spatial Relations. International Journal of Geographical Information Systems, v. 5, n.2, p. 161-174, 1991. FONSECA, F.; DAVIS, C.; CAMARA, G. Bridging Ontologies and Conceptual Schemas in Geographic Applications Development. Geoinformatica, v. 7, n.4, p. 355-378, 2003. FONSECA, F.; EGENHOFER, M.; AGOURIS, P.; CMARA, G. Using Ontologies for Integrated Geographic Information Systems. Transactions in GIS, v. 6, n.3, p. 231-257, 2002. FRANK, A. U., 1997. Spatial ontology: A geographical information point of view. In STOCK, O. ed., Spatial and Temporal Reasoning, pages 135153. Kluwer Academic Publishers, Dordrecht. FRANK, A. U., 2003, Ontology for Spatio-temporal Databases. In: KOUBARAKIS, M.; SELLIS, T., eds., Spatio-Temporal Databases: The Chorochronos Approach: Lecture Notes in Computer Science: Berlin Heidelberg New York, Springer-Verlag, p. 9-78. FRANK, A. U., RAPER, J., CHEYLAN, J. Life and Motion of Socio-Economic Units. ESF Series, London, Taylor & Francis, p. 353. 2001. GRENON, P.; SMITH, B. SNAP and SPAN: Towards Dynamic Spatial Ontology, Spatial Cognition and Computation, v.4, n.1, p.69104. 2003. GTING, R. H.; BOHLEN, M. H.; ERWIG, M.; JENSEN, C. S.; LORENTZOS, N.; NARDELLI, E.; SCHNEIDER, M.; VIQUEIRA, J. R. R., 2003. Spatio-temporal Models and Languages: An Approach Based on Data Types. In: KOUBARAKIS, M., ed., Spatio-Temporal Databases: Berlin, Springer. HORNSBY, K.; EGENHOFER, M. J., 1997. Qualitative Representation of Change. In: FRANK, A. U. e HIRTLE eds. Spatial Information Theory - A
168
Theoretical Basis for GIS (International Conference COSIT'97), SpringerVerlag, Berlin-Heidelberg, 15-33. HORNSBY, K.; EGENHOFER, M. J., 1998. Identity-Based Change Operations for Composite Objects. In: POIKER, T. K. e CHRISMAN, N. eds. Proceedings of 8th Internal Symposium on Spatial Data Handling, July 11-15, Vancouver. HORNSBY, K.; EGENHOFER, M. J., Identity-Based Change: A Foundation for Spatio-Temporal Knowledge Representation. International Journal of Geographical Information Science. v.14, n.3, p.207-224. 2000. KAVOURAS, M., 2001. Understanding and Modelling Spatial Change. In: FRANK A. RAPER J. e CHEYLAN J.P. eds.: Life and Motion of SocioEconomic Units, Chapter 4. London: Taylor & Francis, GISDATA Series 8. KUHN, W. Ontologies in support of activities in geographical space. International Journal of Geographical Information Science, v. 15, n.7, p. 613-631, 2001. LANGRAN. G. Time in Geographic Information Systems. Washington, DC, Taylor & Francis, 1993. MEDAK, D. Lifestyles - A New Paradigm in Spatio-Temporal Databases. Ph.D. Thesis. Technical University of Vienna, 1999. MEDAK, D., 2001. Lifestyles. In: FRANK, A. U.; RAPER, J. e CHEYLAN, J. eds., Life and Motion of Socio-Economic Units, London: Taylor & Francis, p.353. PEDROSA, B.; CMARA, G.; FONSECA, F.; SOUZA, R. C. M. TerraML - A Cell-Based Modeling Language for an Open-Source GIS Library. In: II International Conference on Geographical Information Science (GIScience 2002). Proceedings, AAG, 2002, Boulder, CO, 2002. PEUQUET, D. J. Making Space for Time: Issues in Space-Time Data Representation. GeoInformatica v. 5, n. 1, p.11-32, 2001. RENOLEN, A. Temporal Maps and Temporal Geographical Information Systems. Review of Research. Department of Surveying and Mapping (IKO) The Norwegian Institute of Technology. November, 1995 revised February 1997.
Referncias
169
SMITH, B.; MARK, D. Ontology and Geographic Kinds. In: International Symposium on Spatial Data Handling. Vancouver, Canada, 1998. p. 308320. SNODGRASS, R. T., 1992. Temporal Databases. In: FRANK, A. U.; CAMPARI, I. e FORMENTINI, U. eds. Theories and Methods of SpatioTemporal Reasoning in Geographic Space, Springer-Verlag, HeidelbergBerlin. p. 22-64. SNODGRASS, R. T. Temporal databases: Status and research directions. SIGMOD RECORD, v.19, n.4, p. 8389, 1990. WORBOYS, F. M. F. A unified model of spatial and temporal information, Computer Journal, v.37, n.1, p.26-34, 1994. WORBOYS, F. M. F..; DUCKHAM, M. GIS: A Computing Perspective. CRC Press, Boca Raton, Florida, Taylor Francis Ltd. 1995, 376 p. WORBOYS, M. F. Event-oriented approaches to geographic phenomena. accepted for publication in International Journal of Geographic Information Systems, 2005. Disponvel em : http://www.spatial.maine.edu/~worboys/downloads.htm. WORBOYS, M. F., 1998. A Generic Model for Spatio -Bitemporal Geographic Information. In: EGENHOFER, M. J., GOLLEDGE, E. R. G. eds. Spatial and Temporal Reasoning in Geographics Information Systems. New York, Oxford University Press: 25-39. WORBOYS, M. F.; HORNSBY, K. From Objects to Events: GEM, the Geospatial Event Model. In: EGENHOFER, M. J.; FREKSA, C. e MILLER, H. J. eds. Third International Conference, GIScience 2004, 2004, Adelphi, MD, USA. Springer, p. 327-343.
5 Arquiteturas e linguagens
Karine Reis Ferreira Marco Antonio Casanova Gilberto Ribeiro de Queiroz Olga Fradico de Oliveira
5.1
Introduo
Este captulo inicialmente apresenta uma viso geral de sistemas de gerncia de banco de dados (SGBDs) e resume os principais conceitos da linguagem SQL. Em seguida, aborda a evoluo das arquiteturas de SIG. Por fim, apresenta os principais operadores espaciais e discute a definio de linguagens de consulta espacial. Ao longo dos anos, as implementaes de SIGs seguiram diferentes arquiteturas, distinguindo-se principalmente pela estratgia adotada para armazenar e recuperar dados espaciais. Mais recentemente, tais arquiteturas evoluram para utilizar, cada vez mais, recursos de SGBDs. Por seu lado, a pesquisa na rea de Banco de Dados passou, j h algum tempo, a preocupar-se com o suporte a aplicaes no convencionais (Schneider, 1997), incluindo as aplicaes SIG. Uma aplicao classificada como no convencional quando trabalha com outros tipos de dados, alm dos tradicionais, como tipos de dados espaciais, temporais e espao-temporais. Uma das vertentes de pesquisa tem sido exatamente a definio de linguagens de consulta para tratar tais tipos de dados.
170
5 Arquiteturas e Linguagens
5.2
Preliminares
5.2.1 Sistemas de gerncia de banco de dados Um sistema de gerncia de banco de dados (SGBD) oferece servios de armazenamento, consulta e atualizao de bancos de dados. A Tabela 5.1 resume os requisitos mais importantes para SGBDs e a Tabela 5.2 lista as principais tecnologias desenvolvidas para atend-los.
Tabela 5.1 Principais requisitos para SGBDs
Requisito Facilidade de uso Correo Facilidade de manuteno
Definio a modelagem do banco de dados deve refletir a realidade das aplicaes, e o acesso aos dados deve ser feito de forma simples os dados armazenados no banco de dados devem refletir um estado correto da realidade modelada alteraes na forma de armazenamento dos dados devem afetar as aplicaes o mnimo possvel
Confiabilidade atualizaes no devem ser perdidas e no devem interferir umas com as outras Segurana Desempenho o acesso aos dados deve ser controlado de acordo com os direitos definidos para cada aplicao ou usurio o tempo de acesso aos dados deve ser compatvel com a complexidade da consulta
Tabela 5.2 Principais tecnologias para SGBDs
Requisito Facilidade de uso Correo Facilidade de manuteno
Tecnologia linguagem de definio de dados e linguagem de consulta baseadas em modelo de dados de alto nvel restries de integridade, triggers e assertivas especificao do banco de dados em nveis, isolando os detalhes de armazenamento das aplicaes
Preliminares
171
Confiabilidade
transaes atmicas implementadas atravs de mecanismos para controle de concorrncia e mecanismos de recuperao em caso de falhas nveis de autorizao e controle de acesso otimizao de consultas, baseada em mtodos de acesso e de armazenamento eficientes, gerncia eficaz do buffer pool e modelos de custo, entre outras tecnologias
Segurana Desempenho
O mercado para SGBDs concentra-se em duas tecnologias, SGBDs Relacionais (SGBD-R) e SGBDs Objeto-Relacionais (SGBD-OR), com uma pequena fatia para SGBDs Orientados-a-Objeto (SGBD-OO). Os SGBD-R seguem o modelo relacional de dados, em que um banco de dados organizado como uma coleo de relaes, cada qual com atributos de um tipo especfico. Nos sistemas comerciais atuais, os tipos incluem nmeros inteiros, de ponto flutuante, cadeias de caracteres, datas e campos binrios longos (BLOBs). Para esses tipos encontram-se disponveis uma variedade de operaes (exceto para o tipo BLOB), como operaes aritmticas, de converso, de manipulao textual e operaes com data. Os SGBD-R foram concebidos para atender as necessidades de aplicaes manipulando grandes volumes de dados convencionais. De fato, tais sistemas no oferecem recursos para atender as necessidades de aplicaes no convencionais. A mera simulao de tipos de dados no convencionais em um SGBD-R pode ter efeitos colaterais, como queda de desempenho, dificuldade de codificao e posterior manuteno da aplicao (Stonebraker, 1996). Os SGBD-OR estendem o modelo relacional, entre outras caractersticas, com um sistema de tipos de dados rico e estendvel, oferecendo operadores que podem ser utilizados na linguagem de consulta. Possibilitam ainda a extenso dos mecanismos de indexao sobre os novos tipos. Essas caractersticas reduzem os problemas ocorridos na simulao de tipos de dados pelos SGBD-R, tornando os SGBD-OR uma soluo atrativa para aplicaes no convencionais.
172
5.2.2 A linguagem SQL A linguagem SQL (Structured Query Language) adotada pela maioria dos SGBD-R e SGBD-OR comerciais. Desenvolvida inicialmente pela IBM na dcada de 70, a linguagem sofreu sucessivas extenses, culminando com a publicao do padro conhecido por SQL:1999 (ver Tabela 5.3).
Tabela 5.3 Breve histrico de SQL Ano Verso Caractersticas linguagem original, adotada no prottipo de mesmo nome, desenvolvido pela IBM extenso de SEQUEL, adotada no System R da IBM padro publicado pela ANSI em 1986 ratificado pela ISO em 1987 extenso do SQL-86 padro publicado pela ANSI e pela ISO extenso do SQL-92 padro aprovado em 1999 pela ISO, resultado de 7 anos de trabalho, e publicado em maio de 2001
1974 SEQUEL 1976 SEQUEL 2 1986 SQL-86 (SQL1) 1989 SQL-89 1992 SQL-92 (SQL2) 1996 SQL-92 / PSM 2001 SQL:1999
SQL formada basicamente por duas sub-linguagens: Linguagem de definio de dados (SQL DDL): fornece comandos para definir e modificar esquemas de tabelas, remover tabelas, criar ndices e definir restries de integridade. Linguagem de manipulao de dados (SQL DML): fornece comandos para consultar, inserir, modificar e remover dados no banco de dados.
Preliminares
173
A Tabela 5.4 apresenta alguns comandos em SQL.

Tabela 5.4 Comandos em SQL Comando select insert update delete commit roolback create alter drop Descrio Recupera dados de uma ou mais tabelas Servem para incluir, alterar e eliminar registros de uma tabela, respectivamente Responsveis pelo controle de transaes, permitem que o usurio desfaa (rollback) ou confirme (commit) alteraes em tabelas Usados para definir, alterar e remover tabelas de um banco de dados Tipo DML DML
DML
DDL
No contexto de SQL, usaremos os termos tabela em lugar de relao, e coluna em lugar de atributo, seguindo a prtica mais comum. Os tipos de dados de SQL mais comumente utilizados so char(n), int, float, date e time. Estes representam, respectivamente, um conjunto de caracteres de tamanho definido, um nmero inteiro, um nmero real, uma data (composta por dia, ms e ano) e um instante de tempo (composto por horas, minutos e segundos). Uma restrio especifica um critrio de consistncia para o banco de dados, podendo ser definida a nvel de coluna ou a nvel de tabela. A restrio de nulidade sobre uma coluna A de uma tabela T indica que nenhuma linha t de T pode ter o valor de A nulo. Uma chave primria K (primary key) de uma tabela T formada pelo nome de uma nica coluna ou por uma lista de nomes de colunas de T. Indica que quaisquer duas linhas t e t de T no podem ter valores idnticos de K, ou seja, t[K]t[K]. Uma chave estrangeira F (foreign key) de uma tabela T para uma tabela U, com chave K, tambm formada pelo nome de uma nica
174
coluna ou por uma lista de nome de colunas de T. Indica que, para cada linha t de T, deve haver uma linha u de U tal que t[F]=u[K].
Figura 5.1 Relaes cidade e estado.
A seguir, apresentaremos alguns exemplos de SQL, baseados nas tabelas cidade e estado, ilustradas na Figura 5.1 e definidas como:
CREATE TABLE estado ( sigla CHAR(2) NOT NULL, nome CHAR(30), area FLOAT, PRIMARY KEY(sigla) ) CREATE TABLE cidade ( codigo INT NOT NULL, nome CHAR(30) NOT NULL, estado CHAR(2), area FLOAT, PRIMARY KEY(codigo), FOREIGN KEY(estado) REFERENCES estado(sigla) )
No exemplo anterior, codigo a chave primria da tabela cidade, e de cidade atua como uma chave estrangeira referenciando a chave sigla da tabela estado. Assim, garantimos que somente os valores que ocorrem na coluna sigla de estado podem ser usadas como valores na coluna estado em cidade. Ainda, nessa tabela, as colunas codigo e nome no podem conter valores nulos.
estado
Para alterar a definio de uma tabela, usamos o comando

TABLE:
ALTER
Preliminares
175
ALTER TABLE estado ADD regio CHAR(20)
Para remover tanto a definio quanto os dados de uma tabela, usamos o comando DROP TABLE:
DROP TABLE cidade
Para remover apenas os dados, usamos o comando DELETE:

DELETE * FROM estado
Para inserir uma nova linha, usamos o comando INSERT:

INSERT INTO estado VALUES (MG, Minas Gerais, 10000000)
Para alterar dados j existentes, usamos o comando UPDATE:

UPDATE estado SET area = 20000000 WHERE sigla = MG
Para consultar os dados, usamos o comando SELECT, cuja sintaxe resumida a seguir (ver a Tabela 5.5):
SELECT [distinct] {*, coluna [alias], expresses [alias], funes [alias], ...} from {tabelas [alias],} [where condio] [group by colunas] [having condio] [order by colunas [asc | desc]]
onde os colchetes representam clusulas opcionais, as chaves indicam que os elementos podem aparecer repetidas vezes e a barra vertical indica que as opes so mutuamente exclusivas (ou uma ou outra).
Tabela 5.5 Sintaxe dos comandos Opes
distinct * coluna
Descrio Indica que as linhas duplicadas devem ser eliminadas do resultado da consulta. Indica que todas as colunas de todas as tabelas da clusula from devem ser includas nas linhas da resposta da consulta. Coluna de uma tabela listada na clusula from que deve ser
176
includa em cada linha da resposta da consulta.

expresses funes
Expresses aritmticas envolvendo uma ou mais colunas das tabelas listadas na clusula from. Funes definas em SQL como, por exemplo, funes de agregao, que calculam estatsticas sobre colunas numricas (avg, min, max, count, dentre outras). Nome alternativo para uma coluna ou expresso, usado para melhorar a legibilidade do comando, ou para nomear diretamente uma coluna da resposta da consulta. Uma ou mais tabelas envolvidas na consulta. Nome alternativo para uma tabela, usado para melhorar a legibilidade, ou para permitir o uso da mesma tabela mais de uma vez na clusula from. Pode ser precedido por as. Especifica uma condio qual as linhas das tabelas listadas na clusula from devem satisfazer para gerar uma linha da resposta da consulta. Indica que o resultado deve ser agrupado pelas colunas especificadas. Limita os grupos a serem mostrados queles satisfazendo a condio. Ordenao que ser aplicada ao resultado da consulta, podendo ser crescente (asc) ou decrescente (desc).
alias (select) tabelas alias (from) condio (where) group by colunas condio (having) order by
As consultas a seguir ilustram o uso do comando select: Q1. Selecione todos os nomes dos estados.
SELECT nome FROM estado
Q2.
Selecione todos os nomes das cidades, sem repetio.

SELECT DISTINCT nome FROM cidade
Arquiteturas de SIGs
177
Q3.
Recupere os nomes e as reas das cidades que possuam a sigla de estado igual a MG e populao maior que 50.000 habitantes.
SELECT nome, area FROM cidade WHERE estado = MG AND populacao > 50000
Q4.
Retorne todas as cidades e o estado ao qual pertence.

SELECT C.nome, E.nome FROM cidade AS C, estado AS E WHERE C.estado = E.sigla
Q5.
Calcule a mdia das reas de todas as cidades.

SELECT AVG(area) FROM cidade
Q6.
Retorne o nome de cada estado e a soma das reas de todas as cidades desse estado.
SELECT E.nome, SUM(C.area) FROM estado AS E, cidade AS C WHERE E.sigla = C.estado GROUP BY E.nome
Alm do comando select, os comandos delete e update podem usar a clusula where como, por exemplo: Q7. Remova as cidades cuja populao menor que 1000 habitantes.
DELETE FROM cidade WHERE populacao < 1000
Q8.
Altere a populao do estado de Minas Gerais para 5000000.

UPDATE estado SET populacao = 500000 WHERE codigo = MG
5.3
A partir desta seo, usaremos os conceitos introduzidos na Tabela 5.6 e definidos em detalhe ao longo das sees seguintes ou em outros captulos deste texto.
178
Tabela 5.6 Resumo dos principais conceitos relativos a bancos de dados espaciais
Conceito geometria matricial
Definio uma matriz de elementos, usualmente pertencentes a um sub-conjunto dos nmeros reais um elemento do 2, considerado como um espao topolgico. Pontos, linhas e regies so particulares geometrias.
geometria vetorial
geometria atributo espacial objeto espacial
uma geometria vetorial ou matricial um atributo de um objeto cujo domnio seja um conjunto de geometrias. qualquer objeto com um atributo espacial. Os geo-objetos so uma classe particular de objetos espaciais.
componente espacial ou geometria de um objeto banco de dados espacial consulta espacial
valor de um atributo espacial de um objeto.
um banco de dados armazenando, entre outros, objetos espaciais. uma consultas definida sobre um banco de dados espacial.
Existem basicamente duas principais formas de integrao entre os SIGs e os SGBDs, que so a arquitetura dual e a arquitetura integrada. A arquitetura dual, mostrada na Figura 5.2 armazena as componentes espaciais dos objetos separadamente. A componente convencional, ou alfanumrica, armazenada em um SGBD relacional e a componente
179
espacial armazenada em arquivos com formato proprietrio. Os principais problemas dessa arquitetura so: Dificuldade no controle e manipulao das componentes espaciais; Dificuldade em manter a integridade entre a componente espacial e a componente alfanumrica; Separao entre o processamento da parte convencional, realizado pelo SGBD, e o processamento da parte espacial, realizado pelo aplicativo utilizando os arquivos proprietrios; Dificuldade de interoperabilidade, j que cada sistema trabalha com arquivos com formato proprietrio.
Figura 5.2 Arquitetura Dual
Figura 5.3 Arquitetura Integrada
A arquitetura integrada, mostrada na Figura 5.3, consiste em armazenar todos os dados em um SGBD, ou seja, tanto a componente espacial quanto a alfanumrica. Sua principal vantagem a utilizao dos recursos de um SGBD para controle e manipulao de objetos espaciais, como gerncia de transaes, controle de integridade, concorrncia e linguagens prprias de consulta. Sendo assim, a manuteno de integridade entre a componente espacial e alfanumrica feita pelo SGBD.
180
Esta ltima arquitetura pode ainda ser subdividida em trs outras: baseada em campos longos, em extenses espaciais e combinada. A arquitetura integrada baseada em campos longos utiliza BLOBs para armazenar a componente espacial dos objetos. Como comentado anteriormente, um SGBD-R ou -OR trata um BLOB como uma cadeia de bits sem nenhuma semntica adicional. Portanto, esta arquitetura apresenta algumas desvantagens: um BLOB no possui semntica; um BLOB no possui mtodos de acesso; SQL oferece apenas operadores elementares de cadeias para tratar BLOBs.
Portanto, ao codificar dados espaciais em BLOBs, esta arquitetura torna a sua semntica opaca para o SGBD. Ou seja, passa a ser responsabilidade do SIG implementar os operadores espaciais, capturando a semntica dos dados, e mtodos de acesso que possam ser teis no processamento de consultas, embora seja bastante difcil incorpor-los ao sistema de forma eficiente. A arquitetura integrada com extenses espaciais consiste em utilizar extenses espaciais desenvolvidas sobre um SGBD-OR. Esta arquitetura oferece algumas vantagens: permite definir tipos de dados espaciais, equipados com operadores especficos (operadores topolgicos e mtricos); permite definir mtodos de acesso especficos para dados espaciais;
Exemplos desta arquitetura so o Oracle Spatial (Murray, 2003) e PostGIS , descritos em maior detalhe no Captulo 8 deste livro. Embora largamente baseados nas especificaes do OpenGIS (OGC, 1996), estas implementaes possuem variaes relevantes entre os modelos de dados, semntica dos operadores espaciais e mecanismos de indexao. As extenses espaciais utilizadas nas arquiteturas integradas possuem as seguintes caractersticas :
Operaes espaciais
181
fornecem tipos de dados espaciais (TDEs) em seu modelo de dados, e mecanismos para manipul-los; estendem SQL para incluir operaes sobre TDEs, transformando-a de fato em uma linguagem para consultas espaciais; adaptam outras funes de nvel mais interno ao SGBD para manipular TDEs eficientemente, tais como mtodos de armazenamento e acesso, e mtodos de otimizao de consultas.
Normalmente, essas extenses tratam somente objetos espaciais cuja componente espacial seja uma geometria vetorial, utilizando BLOBs para armazenar dados matriciais, com todos os problemas j citados. De fato, no caso de aplicativos SIG que manipulam objetos com geometrias tanto matriciais quanto vetoriais, possvel a utilizao de uma arquitetura integrada combinada, formada pela combinao das duas ltimas. Ou seja, as geometrias vetoriais so armazenadas utilizando-se os recursos oferecidos pelas extenses e as geometrias matriciais so armazenadas em BLOBs. As funcionalidades para manipulao de geometrias matriciais so fornecidas por uma camada externa ao SGBD, de modo a complementar os recursos ausentes, at o momento, nas extenses. Um exemplo desta arquitetura, a TerraLib (Cmara et al., 2000), ser discutida em detalhe nos Captulos 12, 13 e 14. 5.4 Operaes espaciais
As consultas espaciais baseiam-se em relacionamentos espaciais de vrios tipos: mtricos, direcionais e topolgicos. Por serem dois conceitos de natureza distinta, as operaes sobre as componentes espaciais de geocampos e geo-objetos tambm so diferentes. Abordaremos nesta seo apenas operaes sobre as geometrias vetoriais de geo-objetos. Portanto, no que se segue, omitiremos o adjetivo vetorial. As operaes espaciais podem ser classificadas em (Rigaux et al., 2002): Operao unria booleana: mapeia geometrias em valores booleanos. Como exemplos, temos: Convex, que testa se uma geometria convexa; e Connected, que testa se uma geometria est conectada.
182
Operao unria escalar: mapeia geometrias em valores escalares. Como exemplos, temos: Length, que computa o comprimento ou permetro de uma geometria; e rea, que computa a rea de uma geometria. Operao unria espacial: mapeia geometrias em geometrias. Como exemplos, temos: Buffer, que retorna uma nova geometria a partir de uma distncia em torno de uma geometria especfica; ConvexHull, que retorna uma geometria convexa a partir da geometria; MBR, que retorna o mnimo retngulo envolvente de uma geometria; e Centroid, que retorna o centride de uma geometria. Operao binria booleana: tambm chamada de predicado espacial ou relacionamento espacial, mapeia pares de geometrias em valores booleanos. Esta classe pode ser dividida em: Relacionamento topolgico: um relacionamento que no alterado por transformaes topolgicas, como translao, rotao e mudana de escala. Como exemplos, temos: contm (contains), disjunto (disjoint), intercepta (intersects), cruza (crosses), como apresentado na Seo 2.9. Relacionamento direcional: um relacionamento que expressa uma noo de direo. Como exemplos, temos: acima de (above), ao norte de (northOf), dentre outras; Relacionamento mtrico: um relacionamento que expressa uma noo mtrica. Por exemplo, o relacionamento que retorna Verdadeiro se duas geometrias esto a menos de uma determinada distncia uma da outra. Operao binria escalar: mapeia pares de geometrias em valores escalares. Por exemplo, distance computa a distncia entre duas geometrias. Operao binria espacial: mapeia pares de geometrias em geometrias. Como exemplos, temos as operaes de conjunto, como interseo (Intersection), unio (Union) e diferena (Difference). Operao n-ria espacial: mapeia n-tuplas de geometrias em geometrias. Por exemplo, a operao ConvexHull pode pertencer a essa classe quando receber mais de uma geometria como parmetro de entrada.
Linguagens de consulta espacial
183
5.5
Como SQL-89 no acomodava consultas espaciais, vrias propostas surgiram na dcada de 90 para estender a linguagem, notadamente (Egenhofer, 1994) (OGIS, 1995). Segundo Frank e Mark (1991), as extenses devem considerar dois pontos bsicos: embora seja possvel estender SQL com operadores espaciais, a semntica destes operadores deve ser formalmente definida; embora seja possvel estender SQL para incluir controle de apresentao de geometrias, aconselha-se projetar uma linguagem separada para lidar com esta questo.
Esta seo apresenta inicialmente uma breve classificao para consultas espaciais. Em seguida, discute algumas extenses para incluir suporte a consultas espaciais na linguagem SQL, incluindo o padro publicado pela ISSO, chamado SQL/MM Spatial. 5.5.1 Tipos de consultas espaciais A eficcia das estratgias de otimizao de consultas espaciais depende fundamentalmente da complexidade e freqncia das consultas. Embora estes fator seja de difcil caracterizao, esta seo sugere uma classificao das consultas espaciais bastante til para o estudo do problema, seguindo (Brinkhoff et al., 1993). Dentre os tipos de consultas, destacamos os seguintes: seleo espacial: dado um conjunto de objetos espaciais D e um predicado de seleo espacial sobre atributos espaciais dos objetos em D, determine todos os objetos em D cujas geometrias satisfazem . juno espacial: dados dois conjuntos de dados espaciais, D e D', e um predicado de seleo espacial , determine todos os pares (d,d')DD' cujas geometrias satisfazem . Identificamos ainda os seguintes casos particulares importantes de seleo espacial: seleo por ponto: dado um ponto P e um conjunto de objetos espaciais D, determine todos os objetos em D cujas geometrias contm P.
184
seleo por regio: dada uma regio R e um conjunto de objetos espaciais D, determine todos os objetos em D cujas geometrias esto contidos em R. seleo por janela: dado um retngulo R com os lados paralelos aos eixos e um conjunto de objetos espaciais D, determine todos os objetos em D cujas geometrias esto contidos em R. Um predicado de seleo espacial uma expresso booleana B(x) com uma varivel livre, x, varrendo geometrias, tal que B(x) envolve apenas operaes espaciais. Semelhantemente, um predicado de juno espacial J(x,y) uma expresso booleana com duas variveis livres, x e y, varrendo geometrias, tal que J(x,y) envolve apenas operaes espaciais. Um exemplo de seleo espacial seria: S1. Selecione as regies da Frana adjacentes regio de Midi-Pirenes. A Figura 5.4 ilustra o resultado desta consulta, onde a regio de MidiPirenes aparece em cinza escuro, e as regies adjacente, em cinza claro.
Figura 5.4 Operao de seleo espacial.
Exemplos de juno espacial seriam: J1. Para cada estrada da Amaznia, selecione as reservas indgenas a menos de 5 km de uma estrada. J2. Para as cidades do serto cearense, selecione quais esto a menos de 10 km de algum aude com capacidade de mais de 50.000 m3 de gua
185
5.5.2 SF-SQL A SF-SQL, proposta pelo OGC - Open Geoscience Consortium , especifica um conjunto de tipos de geometrias vetoriais, operaes topolgicas e operaes mtricas. A proposta especifica ainda um esquema de tabelas para metadados das informaes espaciais. Ela introduz o conceito de "tabela com feies" para representao dos dados geogrficos. Nesta tabela, os atributos no espaciais so mapeados para colunas de tipos disponveis na SQL-92, e os atributos espaciais para colunas cujo tipo de dados baseado no conceito de "tipos de dados geomtricos adicionais para SQL". A representao dos atributos espaciais pode seguir dois modelos, chamados SQL-92 e SQL-92 com Tipos Geomtricos. O primeiro modelo utiliza uma tabela para representar os atributos espaciais. O segundo utiliza tipos abstratos de dados especficos para geometrias, estendendo os tipos da SQL. Hierarquia de tipos de geometrias da SF-SQL A Figura 5.5 ilustra a hierarquia de tipos da SF-SQL. Este diagrama o mesmo tanto para o modelo da SQL-92 quanto para o da SQL-92 com Tipos Geomtricos. Alguns tipos so abstratos como: Curve, Surface, MultiSurface e MultiCurve. Um tipo especial a GeometryCollection, que pode ser composta por mais de um tipo de geometria (tipo heterogneo). Os outros so tipos bsicos, como Point, LineString e Polygon, que podem formar tipos de colees homogneas como MultiPoint, MultiLineString e MultiPolygon, respectivamente. Cada um destes tipos possui uma srie de atributos, mtodos e definies que so apresentadas na especificao.
186
Figura 5.5 Hierarquia de tipos de geometrias da SF-SQL .
Relacionamentos Topolgicos A SL-SQL basicamente adota os relacionamentos topolgicos introduzidos na Seo 2.9, definidos como mtodos do tipo Geometry. H ainda um outro relacionamento, chamado relate, que recebe a geometria a ser comparada e um segundo parmetro que representa um padro da matriz de interseo, na forma de uma cadeia de nove caracteres, representando um teste para interseo entre fronteira, interior e exterior. Ele retorna o inteiro 1 (TRUE) se as geometrias forem relacionadas espacialmente de acordo com os valores especificados na matriz. Considere, por exemplo, a seguinte consulta espacial: Q. Selecione os municpios que fazem fronteira com o municpio de Belo Horizonte. Esta consulta pode ser expressa em SF-SQL da seguinte forma:
SELECT M1.name FROM Municipio M1,Municipio M2

WHERE Touch(M1.location,M2.location)=1 AND M2.Name =Belo Horizonte
187
Outros Operadores Espaciais Alm dos relacionamentos topolgicos, SL-SQL inclui outros mtodos para o tipo Geometry. Entre eles, esto: distance(outraGeometria:Geometry):Double retorna a distncia entre as geometrias buffer(distncia:Double):Geometry retorna uma geometria definida por um mapa de distncia convexHull():Geometry retorna um polgono convexo com todos os pontos da geometria intersection(outraGeometria:Geometry):Geometry retorna a geometria resultante da interseo das geometrias union(outraGeometria:Geometry):Geometry retorna a geometria resultante da unio de duas geometrias difference(outraGeometria:Geometry):Geometry retorna a geometria resultante da diferena entre as geometrias Os tipos Surface e MultiSurface possuem ainda os seguintes mtodos: area ():double rea de uma regio centroid():point um ponto representando o centride da geometria pointOnSurface():point um ponto que esteja na superfcie Tabelas com Feies A especificao da SF-SQL prope o esquema de metadados mostrado na Figura 5.6 para representar conjuntos de geo-objetos em tabelas com atributos dos tipos de geometrias anteriormente descritos: SPATIAL_REF_SYS, tabela armazenando dados sobre cada sistema de referenciamento espacial (SRS) utilizado no banco de dados.
188
GEOMETRY_COLUMNS, tabela de metadados para as colunas geomtricas das tabelas com feies (feature tables).
Figura 5.6 Esquema de Metadados da SF-SQL .
Cada atributo do tipo Geometry (ou de seus sub-tipos), de cada tabela com feies, deve estar associado a um SRS, de tal forma que seja possvel determinar o sistema de referenciamento espacial utilizado para representar cada geometria armazenada na tabela. Isso essencial para que os mtodos possam verificar a compatibilidade dos sistemas de referenciamento espacial utilizados pelas geometrias. 5.5.3 Spatial SQL A linguagem Spatial SQL, desenvolvida por Egenhofer (Egenhofer, 1994), representa um outro exemplo de linguagem de consulta espacial baseada em SQL. Spatial SQL divide-se em duas sub-linguagens, uma para consulta e outra para apresentao de objetos espaciais, buscando aproximar-se da forma como os seres humanos conceitualizam o espao geogrfico. A sub-linguagem de consulta estende SQL com operadores e relacionamentos espaciais. Distingue-se de outras extenses por preservar os conceitos de SQL e por conseguir um tratamento de alto nvel dos objetos espaciais.
189
Exemplos de operaes disponveis na Spatial SQL so: Operadores unrios: fornecem, por exemplo, dados de limite, interior, comprimento, rea e volume de objetos. Operadores binrios: fornecem, por exemplo, distncia e direo. Funes de agregao: operam sobre conjuntos de objetos, como as funes de mnimo e mdia.
Os relacionamentos topolgicos so baseados na matriz de 9intersees. (ver Seo 2.9) Podemos citar como exemplo: overlap (sobreposio), inside (dentro) e cover (cobertura). A sub-linguagem de apresentao, chamada Graphical Presentation Language (GPL), baseia-se em um trabalho anterior (Egenhofer e Frank, 1988) e especifica como o resultado de uma consulta pode ser visualizado e manipulado em um ambiente grfico. GPL permite ao usurio definir as caractersticas do ambiente grfico, fornecendo operaes e relacionamentos espaciais. Possui ainda mtodos para referenciar objetos, apresentados na tela, atravs de apontamento. Uma seqncia de comandos escritos em Spatial SQL, adaptada de (Egenhofer, 1994), mostrada abaixo. Os comandos exibem um mapa de Grove Street em Orono, com suas construes, limites de terrenos e rodovias. Para a visualizao, utiliza-se verde para as residncias, azul para os prdios comerciais e preto para os limites de terrenos. Utiliza-se tambm os nomes das ruas para identific-las. Definio do ambiente grfico:
SET LEGEND COLOR black PATTERN dashed FOR SELECT boundary (geometry) FROM parcel; SET LEGEND COLOR green, blue FOR SELECT residence.geometry, commercial.geometry FROM residence.type=Residential AND commercial.type=Commercial;
190
Identificao da janela de interesse e definio da visualizao:

SELECT FROM WHERE geometry road town.name = Orono;
SET WINDOW
SET CONTEXT FOR road.geometry, SELECT parcel.geometry, road.name, building.geometry FROM road, parcel, building;
Exibio de um novo mapa e recuperao dos dados:
SET MODE new; SELECT road.geometry FROM road, town WHERE town.name = Orono AND road.name = Gove Street AND road.geometry INSIDE town.geometry
Este exemplo ilustra vrios pontos interessantes de Spatial SQL. Alm de oferecer operaes espaciais, Spatial SQL separa as etapas de consulta e visualizao em etapas menores, permitindo que o usurio reuse um ambiente em diversas consultas. Porm, a linguagem possui uma sintaxe complexa, principalmente para os usurios finais de SIGs, alm de supor a existncia de uma interface grfica capaz de apresentar e manipular dados em GPL. 5.5.4 SQL/MM Spatial A especificao da ltima verso de SQL, designada pelo nome de SQL:1999 (Melton, 2002), divide-se em vrias partes. A SQL/MM (MM para MultiMedia) compreende extenses para tratar de texto, dados espaciais e imagem esttica ou em movimento. A especificao da SQL/MM (ISO, 2000; Melton e Eisenberg, 2001; Stolze, 2003) tambm se desdobra em vrias partes, bastante independentes entre si. A SQL/MM Spatial define tipos e mtodos para tratar geometrias no 2. SQL/MM tambm modela sistemas de
191
referenciamento espacial (SRS). Revises futuras trataro de tipos de geometrias no 3, ou mesmo em dimenses superiores. A especificao da SQL/MM Spatial est alinhada com outros esforos de padronizao para SIGs, notadamente o ISO Technical Committee, TC 211 (Geomatics) e o OGC - Open Geoscience Consortium. Em particular, a especificao segue a hierarquia de tipos geomtricos definidos pelo OGC, discutida na Seo 5.6.2. A especificao do SQL/MM consistentemente usa o prefixo ST para os nomes de todas as tabelas, tipos, mtodos e funes, para indicar Spatial and Temporal. De fato, a inteno original da especificao era adotar um modelo de dados espao-temporal. Porm, durante o desenvolvimento do SQL/MM, decidiu-se que a componente temporal transcendia o escopo das aplicaes espaciais e que, portanto, deveria ser incorporado ao SQL:1999 em separado, formando a sub-linguagem SQL/Temporal (ISO, 2001). Porm, esta parte do SQL:1999 foi abandonada, e a proposta de padro, retirada. A Figura 5.7 mostra a hierarquia de tipos geomtricos de SQL/MM Spatial, adaptada da hierarquia definida pela OGC, onde os tipos sombreados no so instanciveis. A hierarquia de tipos geomtricos da SQL/MM Spatial difere, porm, da hierarquia da OGC em alguns pontos: adota ST_LineString em substituio a Line e LinearRing; oferece arcos circulares e regies cujas fronteiras so arcos circulares; omite a indicao de que tipos so agregaes de outros tipos. Voltando Figura 5.7, no bvio uma geometria do tipo ST_MultiPoint seja uma agregao de geometrias do tipo ST_Point.
192
Figura 5.7 Hierarquia de tipos do SQL/MM Spatial (Stolze, 2003).
A especificao do SQL/MM Spatial agrupa os mtodos implementando as operaes espaciais em quatro categorias (compare com a classificao introduzida naSeo 5.4): mtodos convertendo geometrias para formatos de exportao e vice-versa; mtodos computando propriedades mtricas de geometrias; mtodos implementando relacionamentos topolgicos; mtodos gerando geometrias a partir de outras.
Os tipos possuem ainda mtodos que permitem extrair informaes bsicas sobre as suas instncias, como as coordenadas de um ponto. Por exemplo, considere a seguinte tabela:
CREATE TABLE cidade ( nome VARCHAR(30), populacao INTEGER, localizacao ST_GEOMETRY )
A consulta abaixo retorna a rea da Cidade de Belo Horizonte:

SELECT localizacao.area FROM city WHERE nome = 'Belo Horizonte'
193
A expresso localizacao.area retorna o valor do atributo area da instncia do tipo estruturado ST_Geometry armazenada na coluna localizacao da linha da tabela cidade tal que a coluna nome possui valor Belo Horizonte.
Figura 5.8 Esquema de metadados da SQL/MM Spatial (Stolze, 2003).
A Parte 3 da especificao do SQL/MM Spatial define um esquema de metadados, semelhante ao esquema definido para o SF-SQL, ilustrado no diagrama entidade-relacionamento da Figura 5.8. O esquema de metadados compreende as seguintes tabelas: ST_GEOMETRY_COLUMNS, armazena metadados descrevendo as colunas geomtricas das tabelas do banco de dados (idntica tabela GEOMETRY_COLUMNS da SF-SQL, definida pela OGC). ST_SPATIAL_REFERENCE_SYSTEMS, armazenando dados sobre cada sistema de referenciamento espacial (SRS) utilizado no banco de dados (idntica tabela SPATIAL_REF_SYS da SFSQL). ST_UNITS_OF_MEASURE, armazena as unidades de medida utilizadas no banco de dados.
194
ST_SIZINGS, semelhante tabela SIZINGS do SQL99, define as meta-variveis, e seus valores, especficas para a componente especial do banco de dados.
Por fim, a segunda verso do padro da SQL/MM dever incluir suporte Geography Markup Language (GML), definida pela OGC, e suporte a ngulos e direes. 5.6 Direes de pesquisa
5.6.1 Consultas espao-temporais Como o nome indica, consultas espao-temporais tratam de dados convencionais, espaciais e temporais. Tais consultas recuperam dados a respeito do estado, da histria e da evoluo dos objetos ao longo do tempo. Para exemplificar os dados temporais, utilizaremos o monitoramento do desmatamento da Amaznia realizado periodicamente pelo PRODES (Sistema de Deteco de Desmatamentos) e mostrado em Correia et al. (2005). Como exemplos dessa evoluo temporal, temos reas que em um determinado momento eram parte da floresta e algum tempo depois foram desmatadas. Essas reas podem alterar seu tamanho ou sua forma em outras observaes. Existe tambm a possibilidade de uma rea desmatada ser replantada ou sofrer outros tipos de regenerao. Um banco de dados espao-temporal que modela os dados de desmatamento poderia conter vrias imagens semelhantes, e os dados relativos a essas imagens. Aliando esses dados a informaes, como reservas indgenas ou hidrografia, pode-se pensar em consultas que incluem a dimenso espacial como: a) Quais so as reas de reservas indgenas prximas a reas desmatadas? b) Quais so as reas de preservao de hidrografia que possuem desmatamentos? Quando inclumos a dimenso temporal e buscamos combin-la com a dimenso espacial, as consultas se tornam mais complexas. Podemos
Direes de pesquisa
195
pensar em consultas que tratem a evoluo ao longo do tempo dos objetos envolvidos, como: a) Quais so as reas desmatadas no perodo de 01-01-1990 a 31-121999 e posteriormente recuperadas? b) Quais so as reas desmatadas no ltimo bimestre que ficam a menos de 50 Km de distncia de estradas ou rios? Na primeira consulta nos deparamos com o desafio de definir as reas que eram florestas e foram desmatadas na dcada de 90. Dentro dessas reas, procuramos quais evoluram e deixaram de ser reas desmatadas. Na segunda consulta tambm nos deparamos com outro desafio, o de definir quais reas foram desmatadas e como essas reas se relacionam com estradas e rios prximos. Essas duas consultas ilustram questes complexas de serem modeladas pelas linguagens disponveis, e mostram que as linguagens de consulta espao-temporais ainda tm muitos desafios a superar. 5.6.2 lgebra para objetos mveis Uma lgebra para objetos mveis, ou seja, objetos que se movem continuamente ao longo do tempo, apresentada em Gting et al (2003). Essa lgebra foi implementada no ambiente SECONDO, um SGBD extensvel e modular, que permite a utilizao de diversas lgebras (Guting et al., 2004).
Figura 5.4 Exemplos de representaes de mpoint e mregion (Fonte: adaptada de Guting et al., 2004 ).
Dois tipos bsicos de objetos mveis so (ver Figura 5.4):
196
moving point (mpoint): descreve um objeto cuja relevncia est nas posies ocupadas no espao ao longo do tempo. Um exemplo de um mpoint o deslocamento de um veculo. moving region (mregion): descreve uma rea que possui extenso e se modifica, por exemplo, crescendo ou se movimentando. Um exemplo pode ser o movimento de uma tempestade.
Operaes podem ser definidas envolvendo tipos convencionais e os tipos bsicos de objetos mveis. Por exemplo, temos: intersection: mpoint mregion mpoint retorna um mpoint formado pela parte de um mpoint que estiver dentro de uma mregion. trajectory: mpoint line projeta um mpoint no plano, retornando uma line, definida como uma curva em espao bidimensional. deftime: mpoint periods retorna um intervalo de tempo, do tipo periods, definido por determinado mpoint. Por fim, considere as seguintes tabelas:
flights (id:string,from:string,to:string,route:mpoint) weather (id:string,kind:string,area:mregion)
Exemplos de consultas sobre estas tabelas so: Q1. Selecione todos os vos partindo de Dsseldorf que percorrem mais de 5000 Km
SELECT id FROM flights WHERE from = DUS AND length(trajectory(route)) > 5000
Q2. Que horas o vo BA488 atravessou a tempestade de neve de identificador S16?

SELECT deftime(intersection(f.route,w.area))
FROM flights as f, weather as w WHERE f.id = BA488 AND w.id = S16
197
5.7
H inmeros livros-texto sobre bancos de dados e a linguagem SQL. Recomenda-se, em especial, os textos sobre SQL:1999 (Melton e Simon, 2001) (Melton, 2002). O primeiro trata dos conceitos relacionais bsicos da linguagem, enquanto que o segundo aborda as extenses objetorelacionais, incluindo suporte a consultas espaciais. Um pouco da histria do desenvolvimento de bancos de dados espaciais pode ser avaliada atravs de referncias bsicas sobre a rea, como Gting (1994) e Medeiros (1994). Recomenda-se tambm a leitura dos livros-texto de Rigaux e Voisard (2001) e Shekhar (2002). Conforme discutido na Seo 5.3, a arquitetura integrada com extenses espaciais mostra-se promissora. O Oracle Spatial (Murray, 2003), o DB2 Spatial Extender (Adler, 2001) e o PostGIS so exemplos desta arquitetura, que merecem um estudo detalhado. O documento descrevendo a arquitetura de referncia do Open Geoscience Consortium (Percivall, 2003) apresenta uma abordagem para o problema de interoperabilidade em SIGs, assunto do Captulo 10. A definio de relacionamentos topolgicos foi extensamente estudada, incluindo a matriz de 4-intersees e suas variantes (Egenhofer e Franzosa, 1995), a matriz de 9-Intersees (Egenhofer et al., 1994), a matriz de 9-Intersees estendida dimensionalmente (Paiva, 1998) e o trabalho de Clementini et al. (1993) adotado pela SF-SQL e SQL/MM Spatial. Quanto a linguagens de consulta espacial, Stolze (2003) apresenta uma anlise sucinta, porm criteriosa, do padro SQL/MM Spatial. Alm dos tpicos abordados acima, h linguagens de consulta endereando outros tipos de dados geogrficos, ou ambientes com necessidades especficas. Como exemplo, podemos citar linguagens de consulta para redes georeferenciadas, como a rede de distribuio de gua de uma cidade, onde a noo de espao Euclidiano no adequada (Papadias et al., 2003). H tambm toda uma linha de pesquisa sobre
198
consultas dependentes de localizao em ambientes para computao mvel (Ayse et al., 2001) (Zhang et al., 2003) (Manical et al., 2004).
Referncias
199
Referncias
ADLER, D.W. DB2 Spatial Extender - Spatial data within the RDBMS. 27th International Conference on Very Large Data Bases, 2001. Morgan Kaufmann Publishers Inc. p. 687-690 AYSE, Y.; DUNHAM, H. M.; KUMAR, V. M. Location dependent query processing. In: 2nd ACM international workshop on Data engineering for wireless and mobile access. Santa Barbara, CA, USA, 2001. p. 47-53. BRINKHOFF, T.; HORN, H.; KRIEGEL, H.-P.; SCHNEIDER, H. A Storage and Access Architecture for Efficient Query Processing in Spatial Database Systems. In: Third International Symposium on Advances in Spatial Databases. Lecture Notes In Computer Science 692. SpringerVerlag London, UK, 1993. p. 357-376. CMARA, G.; SOUZA, R.; PEDROSA, B.; VINHAS, L.; MONTEIRO, A. M.; PAIVA, J.; CARVALHO, M. T.; GATTASS, M. TerraLib: Technology in Support of GIS Innovation. In: II Brazilian Symposium on Geoinformatics, GeoInfo2000. So Paulo, 2000. p. CLEMENTINI, E.; DI FELICE, P.; VAN OOSTEROM, P., 1993. A Small Set of Formal Topological Relationships Suitable for End-User Interaction. In: ABEL, D.; OOI, B. C., eds., SSD '93: Lecture Notes in Computer Science, v. 692: New York, NY, Springer-Verlag, p. 277-295. CORREIA, A. H.; PIROMAL, R. A. S.; QUEIROZ, G. R.; SOUZA, R. C. M., 2005, Modelagem de um banco de dados espao-temporal para desmatamento e queimadas, XII Simpsio Brasileiro de Sensoriamento Remoto, Goinia. EGENHOFER, M. Spatial SQL: A Query and Presentation Language. IEEE Transactions on Knowledge and Data Engineering, v. 6, n.1, p. 86-95, 1994. EGENHOFER, M.; FRANK, A. Towards a Spatial Query Language: User Interface Considerations. In: 14th International Conference on Very Large Data Bases. Los Angeles, CA, 1988. p. 124-133. EGENHOFER, M.; P. DI FELICE; CLEMENTINI, E. Topological Relations between Regions with Holes. International Journal of Geographical Information Systems, v. 8, n.2, p. 129-144, 1994.
200
EGENHOFER, M.; FRANZOSA, R. On the Equivalence of Topological Relations. International Journal of Geographical Information Systems, v. 9, n.2, p. 133-152, 1995. FRANK, A.; MARK, D., 1991. Language Issues for GIS. In: MAGUIRE, D.; GOODCHILD, M.; RHIND, D., eds., Geographical Information Systems, Volume 1: Principles: London, Longman, p. 147-163. GTING, R. An Introduction to Spatial Database Systems. VLDB Journal, v. 3, n.4, p. 357-399, 1994. GTING, R. H.; BEHR, T.; ALMEIDA, V. T. D.; DING, Z.; HOFFMANN, F.; SPIEKERMANN, M., 2004, SECONDO: An Extensible DBMS Architecture and Prototype, Fernuniversitt Hagen. GTING, R. H.; BOHLEN, M. H.; ERWIG, M.; JENSEN, C. S.; LORENTZOS, N.; NARDELLI, E.; SCHNEIDER, M.; VIQUEIRA, J. R. R., 2003. Spatio-temporal Models and Languages: An Approach Based on Data Types. In: KOUBARAKIS et al. ed., Spatio-Temporal Databases: Berlin, Springer. ISO, 2001, Information Technology Database Languages SQL Part 7: Temporal (SQL/Foundation), International Organization for Standardization. MANICAL, H.; CAMARGO, S. M.; CIFERRI, A. D. C.; CIFERRI, R. R. Processamento de Consultas Espaciais Baseado em Cache Semntico Dependente de Localizao. In: VI Simpsio Brasileiro de Geoinformtica GeoInfo 2004. Campos de Jordo, SP, 2004. MEDEIROS, C. B.; PIRES, F. Databases for GIS. ACM SIGMOD Record, v. 23, n.1, p. 107-115, 1994. MELTON, J.; SIMON, A. SQL: 1999 Understanding Relational Language Components. Morgan Kaufmann, 2001. MELTON, J. Advanced SQL 1999: Understanding Object-Relational, and Other Advanced Features. New York, NY, USA: Elsevier Science Inc., 2002. MELTON, J.; EISENBERG, A. SQL Multimedia and Application Packages (SQL/MM). SIGMOD Record, 2001. MURRAY, C., 2003, Oracle Spatial Users Guide and Reference 10g Release 1 (10.1), Redwood City, Oracle Corporation, p. 602. OGC, ed., 1996, The OpenGIS Guide - Introduction to Interoperable Geoprocessing. Boston, Open GIS Consortium, Inc. OGIS, 1995, OpenGIS simple features specification for SQL revision 1.1.
Referncias
201
PAIVA, J. A. C. Topological Equivalence and Similarity in MultiRepresentation Geographic Database. University of Maine,1998. PAPADIAS, D.; ZHANG, J.; MAMOULIS, N.; Y., T. Query Processing in Spatial Network Databases. In: 29th Very Large Data Base Conference. Berlin, Germany, 2003. PERCIVALL, G., 2003, OpenGIS Reference Model, Open Geoscience Consortium. RIGAUX, P.; SCHOLL, M.; VOISARD, A. Spatial Databases with Application to GIS. San Francisco: Morgan Kaufmann, 2002. SCHNEIDER, M. Spatial data types for database systems. Berlin Hidelberg: Springer-Verlag, 1997. SHEKHAR, S.; CHAWLA, S. Spatial Databases: A Tour. New York: Prentice-Hall, 2002. STOLZE, K. SQL/MM Spatial: The Standard to Manage Spatial Data in Relational Database Systems. In: BTW 2003, Datenbanksysteme fr Business, Technologie und Web. Leipzig, Alemanha, 2003. p. 247-264. STONEBRAKER, M. Object-relational DBMSs: the next great wave. San Francisco: Morgan Kaufmann, 1996. ZHANG, J.; ZHU, M.; PAPADIAS, D.; TAO, Y.; LEE, D. L. Location-based spatial queries. In: 2003 ACM SIGMOD International Conference on Management of Data. San Diego, CA, USA, 2003. p. 443-454.
6 Mtodos de acesso para dados espaciais

Clodoveu A. Davis Jr. Gilberto Ribeiro de Queiroz
6.1 Introduo Este captulo aborda alguns dos mtodos de acesso espacial mais tradicionais, denominados k-d trees, grid files, quad-trees e R-trees. Mtodos de acesso espacial, ou ndices espaciais, so estruturas de dados auxiliares, mas essenciais para o processamento eficiente de consultas espaciais. De fato, normalmente uma consulta espacial envolve apenas uma pequena parcela do banco de dados. Neste caso, percorrer todo o banco pode ser bastante ineficiente. Portanto, um plano de execuo para a consulta tipicamente comea com uma fase de filtragem, que identifica quais objetos podem satisfazer a qualificao da consulta. Esta fase depende da existncia de ndices espaciais, em geral definidos sobre aproximaes das geometrias dos objetos. 6.2 Preliminares sobre mtodos de acesso Uma forma comum de indexarmos um conjunto de dados atravs do uso de rvores de pesquisa. As mais simples e conhecidas so as rvores binrias, como: AVL, Red Black e Splay Tree (Cormen et al., 1990), que so rvores balanceadas, ou seja, todos os caminhos desde a raiz at as folhas possuem o mesmo comprimento. Essas estruturas permitem que algumas operaes, como a localizao de um elemento, sejam executadas em tempo logartmico O(log n). A Figura 6.1 ilustra a representao de uma rvore binria balanceada, onde as cidades esto organizadas segundo a ordem alfabtica de seus nomes. Esse tipo de estrutura empregado para uso em memria principal.
202
Figura 6.1 rvore binria balanceada.
No caso de grandes bancos de dados onde a memria principal pode no ser suficiente para armazenar todos os ns da rvore, comum armazen-la em disco. Nesse caso utilizamos uma representao que procura minimizar o acesso a disco. A forma mais comum, e mais largamente empregada pelos sistemas comerciais atuais, a representao do ndice atravs de uma rvore B+ (Comer, 1979). Conforme podemos observar na Figura 6.2, essa estrutura tenta minimizar o nmero de acessos a disco durante o processo de pesquisa agrupando vrias chaves em um nico n, denominado de pgina.
Figura 6.2 ndice unidimensional B-Tree. Fonte: adaptada de Garcia-Molina et al., (2001).
Em comum, tanto a rvore binria quanto a B+, so estruturas unidimensionais, isto , elas pressupem que a chave de pesquisa seja
Preliminares sobre mtodos de acesso
203
formada por apenas um atributo ou pela concatenao de vrios atributos. Em sistemas que trabalham com informaes multidimensionais (mais de um atributo), como os sistemas de bancos de dados espaciais, estas estruturas no so diretamente aplicveis. Para esses sistemas existe uma classe de mtodos conhecidos como mtodos de acesso multidimensionais. No caso dos bancos de dados espaciais, estes mtodos esto ligados ao processamento de consultas tpicas como: consulta por apontamento (encontrar os objetos que contm um dado ponto), consultas por regio (encontrar os objetos dentro de uma janela ou retngulo) e consultas com predicados topolgicos (encontrar os objetos vizinhos de um determinado objeto). Uma idia fundamental dos ndices espaciais o uso de aproximaes, isto , a estrutura do ndice trabalha com representaes mais simples dos objetos, como o menor retngulo envolvente (REM) do objeto. Dessa forma, a maneira mais comum de processar as consultas dividir o processamento em duas etapas: uma de filtragem e outra de refinamento (Figura 6.3). Na etapa de filtragem so usados mtodos de acesso espaciais. O principal objetivo do uso destes mtodos o de reduzir e rapidamente selecionar os possveis candidatos que satisfaam a consulta. A reduo do espao de busca muito importante, pois a etapa seguinte, a de refinamento, envolve a aplicao de algoritmos geomtricos computacionalmente complexos e custosos e que so aplicados geometria exata dos candidatos selecionados na etapa anterior.
Figura 6.3 Processamento de consultas espaciais. Fonte: adaptada de Gaede e Gnther (1998).
204
6.3 k-d Tree A k-d tree uma rvore binria, ou seja, cada n interno possui dois descendentes no importando a dimensionalidade k do espao envolvido. Originalmente, esta rvore apresentada em Bentley (1975), como uma alternativa a um problema mais genrico do que o geomtrico dos bancos de dados espaciais: o de busca baseado em vrios atributos. Em um banco de dados tradicional, uma consulta como: encontrar todos os empregados nascidos entre 1950 e 1955 que recebem entre R$3.000,00 e R$5.000,00, poderia ser vista como uma pesquisa em duas dimenses, considerando cada atributo, neste caso data de nascimento e salrio, como uma das componentes do espao (Figura 6.4a). No caso dos sistemas de bancos de dados espaciais, essa consulta equivale a encontrar todos os pontos no interior do retngulo definido pelos intervalos (3000:5000)x(1950:1955) (Figura 6.4b).
Figura 6.4 Busca em dois atributos (a) Interpretao geomtrica da busca (b).
Dada uma chave formada por k atributos (k dimenses), onde ki o valor da i-sima componente da chave, a idia bsica da k-d tree a seguinte: A cada n da rvore associamos uma chave e um discriminador; O discriminador um valor entre 0 e k-1 que representa a dimenso ao longo da qual o espao ser subdividido, ou seja, a componente ki que ser empregada para definio da ordem na rvore; Todos os ns do mesmo nvel so associados ao mesmo valor de discriminador;
k-d Tree
205
O n raiz est associado ao discriminador 0, aos dois descendentes diretos, discriminador 1, e assim por diante, at o k-simo nvel que est associado ao discriminador k-1; A partir do nvel k+1 o ciclo comea se ser repetido, sendo associado o discriminador 0 a este nvel.
A ordem imposta por essa rvore tal que, dado um n qualquer P de discriminador j, qualquer n descendente (L) da sub-rvore esquerda possui um valor de chave cuja componente kj menor do que a componente kj do n P; Da mesma forma, qualquer n descendente (R) da sub-rvore direita possui um valor de chave cuja componente kj maior do que a componente kj do n P. Para o caso de pontos no espao bidimensional, como o da Figura 6.5, a k-d tree ou 2-d tree que corresponde decomposio do espao ao longo das dimenses x e y, compara os valores da componente x nos nveis pares da rvore e da componente y nos nveis mpares.
Figura 6.5 Sedes de alguns municpios do Estado de Minas Gerais.
Assim, se adotarmos uma ordem arbitrria de entrada dos pontos correspondentes s sedes municipais, podemos construir a rvore da Figura 6.6 da seguinte forma:
206
Considerando Araguari a primeira cidade a ser inserida na rvore, esta ocupar a raiz; Sendo Arapor, a prxima, como ela possui um valor de coordenada x menor do que a de Araguari, esta inserida esquerda. Aqui, como a raiz ocupa um nvel par (0), comparamos os valores da componente x das coordenadas das sedes municipais. Nova Ponte possui um valor x maior, e, portanto, inserida direita. No caso de Cachoeira Dourada, ela possui um valor de x menor do que Araguari (comparao em um nvel par), e um valor de y menor do que Arapor (comparao no nvel mpar 1), e por isso inserida esquerda desta. Esse processo realizado at que todas as cidades estejam armazenadas na rvore.
Figura 6.6 Representao em forma de rvore para as sedes da Figura 6.5.
A partio do espao representada pela k-d tree do exemplo acima pode ser vista na Figura 6.7.
k-d Tree
207
Figura 6.7 Representao planar para as sedes da Figura 6.5.
Um dos problemas que podemos observar na k-d tree da Figura 6.6 que ela depende da ordem em que os ns so inseridos. No pior caso, podemos acabar obtendo uma rvore completamente desbalanceada, que apresenta a mesma profundidade do nmero de elementos inseridos. Uma forma de contornar este problema adotar um mtodo que otimize a construo da rvore. Uma forma de construir a rvore mais balanceada escolher o elemento que ocupa a posio mdia ao longo da componente em diviso. A Figura 6.8 ilustra uma rvore construda tomando-se o elemento central em relao componente em cada nvel da diviso.
Figura 6.8 Representao em rvore (balanceada) para as sedes.
208
Na Figura 6.9, podemos observar que Itapajipe possui o mesmo nmero de elementos do lado esquerdo e direito e por isso foi tomada como o primeiro elemento a ser inserido na rvore da Figura 6.8. Limeira do Oeste pode ser tomada como elemento mdio entre os elementos esquerda de Itapajipe quando comparamos ao longo do eixo y.
Figura 6.9 Representao planar para as sedes da Figura 6.5.
A pesquisa por intervalos na 2-d tree do exemplo anterior pode ser realizada da seguinte forma: 1. Seja um retngulo de coordenadas inferior esquerda (x1:y1) e superior direita (x2:y2) contendo o intervalo de pesquisa, partindo da raiz, temos que verificar: 2. Se o n corrente encontra-se no intervalo ele reportado; 3. Se ele for um n em um nvel par (caso do n raiz): a. Se a coordenada x1 do retngulo de pesquisa for menor do que a coordenada x do n, aplicamos recursivamente os passos a partir do passo 2, sub-rvore esquerda; b. Se a coordenada x2 do retngulo de pesquisa for maior do que a coordenada x, aplicamos recursivamente os passos a partir do passo 2, sub-rvore direita;
Grid File
209
4. Se ele for um n em um nvel mpar: a. Se a coordenada y1 do retngulo de pesquisa for menor do que a coordenada y do n, aplicamos recursivamente os passos a partir do passo 2, sub-rvore esquerda; b. Se a coordenada y2 do retngulo de pesquisa for maior do que a coordenada y, aplicamos recursivamente os passos a partir do passo 2, sub-rvore direita; Na literatura, encontramos diversas variantes dessa estrutura. Friedman et al. (1977) apresentam uma variante em que os elementos (registros ou pontos) so armazenados apenas nos ns folha, sendo que os ns internos contm apenas os valores usados para particionar o espao. Robinson (1981), combinando a B-Tree, adaptou esta estrutura para armazenamento em memria secundria, chamando esta nova estrutura de kdB-Tree. 6.4 Grid File Uma das tcnicas mais interessantes para facilitar a pesquisa em dados convencionais o hashing. Este mtodo, chamado tambm de transformao de chave, consiste em criar uma srie de receptculos (chamados habitualmente de buckets), que recebero os identificadores dos itens que se quer pesquisar. Estes buckets so numerados seqencialmente de 1 a n, e portanto sua implementao mais natural sob a forma de arranjo (Figura 6.10). Cada identificador que chega, seja para ser inserido, seja para ser pesquisado, transformado em um nmero de 1 a n, identificando o bucket correspondente a ele. Ento, s se precisa inser-lo no bucket (no caso de insero) ou procurar um elemento com identificador igual que j esteja dentro do bucket. Quanto maior for o valor de n, menos itens existiro em mdia dentro de cada bucket, e o resultado da pesquisa ser mais rpido. No entanto, a escolha do valor de n e da funo de transformao ideal problemtica, pois no se deseja provocar uma distribuio irregular dos itens pelos buckets. Em geral, recomenda-se utilizar n primo, e uma funo de transformao que (1) seja simples de ser computada, e (2) produza uma distribuio uniforme de sadas entre 1 e n.
210
1 2 3 4
...
Figura 6.10 Hashing.
O mtodo de indexao chamado grid file (Nievergelt et al., 1984). estende o conceito de hashing para duas dimenses. Ou seja, em vez de n buckets, teremos uma grade regular que cobre todo o espao de pesquisa. O mtodo foi originalmente concebido para possibilitar pesquisas convencionais, como no caso do hashing, porm utilizando duas variveis distintas. No caso geogrfico, natural imaginar quadrados sobre a superfcie da Terra, que funcionam como os buckets do hashing (Figura 6.11). A partir de cada elemento da grade (que pode ser modelada na memria com o uso de uma matriz no lugar do vetor utilizado no hashing) so organizadas listas lineares contendo os identificadores dos objetos que esto localizados naquela rea.
Figura 6.11 Grid File.
Grid File
211
Alguns tipos de pesquisas podem ser feitas com muita facilidade utilizando grid files. Por exemplo, deseja-se saber quais pontos esto a menos de M metros de um determinado ponto P. Para isto, basta calcular as coordenadas de dois pontos auxiliares, um deles subtraindo M de ambas as coordenadas, e no outro somando: x1 = xP - M y1 = yP - M x2 = xP - M y2 = yP - M Depois, determina-se qual a linha e a coluna dos quadrados que contm os pontos x1 e x2. Todos os pontos procurados estaro nos quadrados compreendidos entre os limites expressos pelas linhas e colunas encontradas. Naturalmente, deve-se calcular a distncia de cada ponto encontrado a P, para verificar o atendimento restrio de distncia, pois a pesquisa na realidade foi feita usando um quadriltero, e no com um crculo.
(x2, y2)
(x1, y1)
Figura 6.12 Localizao de pontos por proximidade.
212
A principal limitao deste mtodo, superada pelos mtodos que sero apresentados a seguir, o fato de somente poder lidar com pontos, ou com objetos que caibam inteiramente em um quadrado. No um mtodo adequado para lidar com linhas ou polgonos, mas bastante eficiente e simples de implementar para o tratamento de dados puntuais. 6.5 Quad-tree A quad-tree um tipo de estrutura de dados organizada em rvore, em que cada n ou tronco gera sempre (e exatamente) quatro folhas, como mostrado na Figura 6.13 (Samet, 1984). O SIG, utilizando esta estrutura de dados para realizar a indexao espacial, considerar que cada n corresponder a uma regio quadrada do espao. Esta regio ser subdividida, novamente em quatro partes, gerando mais um nvel na rvore, e assim sucessivamente, at que se chegue a ter um ou nenhum objeto geogrfico dentro dos quadrados resultantes da subdiviso.
A
B
C
1 2
1 1
3 4 5 6
2
7 8 9 10
3
11 12 13 14
4
15 16
Figura 6.13 Quad-tree.
Na Figura 6.13 existem trs nveis (A, B e C) na quad-tree. A cada um destes nveis corresponder um quadrado geogrfico, conforme apresentado na Figura 6.14.
C1 C2 C3 C4
B1
C5 C6 C7
B2
C8
A1
C9 C10 C11 C12
B3
C13 C14 C15
B4
C16
Figura 6.14 Subdiviso do espao por uma quad-tree.
Tiling
213
Esta subdiviso poder continuar indefinidamente, de forma recursiva: basta considerar um quadrado do nvel C como sendo o quadrado A1, e reaplicar o processo. Observe-se que o resultado final ser uma rvore que ter um nmero varivel de nveis, de acordo com a regio geogrfica: regies mais densas formaro mais nveis, e regies menos densas tero menos nveis. O processamento de consultas por regio (janela ou retngulo) nessa estrutura inicia-se a partir da raiz, selecionando apenas as ramificaes cujos quadrados estiverem em contato com o retngulo da regio. Se nenhuma estiver, todas as ramificaes abaixo daquele n so descartadas. Se alguma estiver, toda a ramificao abaixo daquele ponto selecionada, e sucessivamente testada, at que se alcance os objetos geogrficos. 6.6 Tiling Este processo semelhante ao anterior, com a diferena de que as subdivises no prosseguem indefinidamente. O processo consiste em, conhecendo-se a priori os limites geogrficos da base de dados, criar camadas de tiles, ou ladrilhos, quadrados, de dimenses fixas. O nmero de camadas e a largura dos ladrilhos de cada camada so determinados pelo usurio, de modo a corresponder da melhor maneira possvel variedade de dimenses dos objetos geogrficos que sero encontrados na base de dados. O nmero total de ladrilhos endereveis limitado pelo sistema, para melhorar sua performance. Cada objeto ser associado a um ladrilho, que ser o menor ladrilho que contiver inteiramente o objeto. Assim, a cada ladrilho, de cada camada, sero associados diversos objetos, formando uma lista. No momento do display, testa-se os limites da janela de visualizao contra a lista de ladrilhos, selecionando aqueles que tenham pelo menos uma extremidade contida no retngulo. Os objetos associados a cada um destes ladrilhos sero, ento, recuperados na base de dados para apresentao.
214
Com estes limites previamente calculados, evita-se percorrer freqentemente uma estrutura de dados como a quad-tree, que geralmente tem que ser mantida em disco. A Figura 6.15 ilustra a estrutura bsica do tiling.
Camada 0: toda a base de dados
Camada 1: largura 10000
Figura 6.15 Tiling.
6.7 R-tree A R-tree, ou rvore-R, uma estrutura de dados hierrquica derivada da rvore-B. As diferenas esto centradas na natureza das chaves: valores numricos ou alfanumricos simples, no caso das rvores-B, e pontos extremos de retngulos, no caso das rvores-R (Guttman, 1984). O que a rvore-R busca organizar no exatamente o contorno ou a forma grfica do objeto, e sim o seu retngulo envolvente mnimo (minimum bounding rectangle, MBR). Este retngulo formado a partir da observao dos limites geomtricos mnimo e mximo do contorno do objeto, e expresso pelas coordenadas dos seus pontos inferior esquerdo e superior direito (Figura 6.16). No caso de objetos puntuais, estes extremos vo coincidir com as coordenadas do prprio objeto (portanto formando um retngulo nulo), mas isto no compromete o mtodo.
R-tree
215
Figura 6.16 Objeto poligonal e seu retngulo envolvente mnimo.
A rvore-R possui parmetros para determinar a quantidade de chaves (retngulos) que podero ocorrer em cada bloco de armazenamento, analogamente rvore-B, em funo do tamanho da pgina de armazenamento em disco. As regras bsicas para formao de uma rvore-R so semelhantes s da rvore-B. Todas as folhas aparecem sempre no mesmo nvel da rvore. Ns internos contm a delimitao de retngulos que englobam todos os retngulos dos ns nos nveis inferiores (Figura 6.17). Uma rvore-R de ordem (m, M) conter entre m e M entradas em cada n da rvore (m < M / 2), exceto a raiz, que ter pelo menos dois ns (a menos que a rvore s tenha uma entrada). Um problema com as rvores-R que a ordem de insero dos objetos interfere na forma final da rvore, e portanto vai interferir tambm com o resultado das operaes de subdiviso dos ns para manter o balanceamento. Existem algumas tcnicas para tentar otimizar este comportamento da rvore-R, mas sempre com algum custo adicional em termos de processamento.
216
R1
R2
R3
R4
R5
R6
R1
R5
B
R3 Q
I D H G F A
R2
R6
R4
Figura 6.17 rvore-R e retngulos correspondentes.
Pesquisas na rvore-R so relativamente simples de serem executadas. O nico problema que um grande nmero de ns pode ter que ser examinado, pois um retngulo pode estar contido em vrios outros, mesmo que o objeto esteja contido em apenas um n folha. Por exemplo, na Figura 6.17 a identificao do retngulo que contm o ponto Q dever varrer a rvore nvel a nvel. Inicialmente, inspecionamos a raiz e constatamos que Q pode estar tanto em R1 quanto em R2, e portanto devemos prosseguir a pesquisa em ambas as direes no segundo nvel. Pesquisando os filhos de R1, verificamos que Q s pode estar contido em R3. Continuando a pesquisa, no chegamos a concluso alguma, uma vez que Q est dentro do retngulo D, que tem apenas uma parte dentro de R3, e no acessado por ele. Continuando a pesquisa a partir de R2,
217
verificamos que Q somente poderia estar dentro de R5. Pesquisando R5, encontramos D, o nico MBR que contm Q efetivamente. Observe-se, no entanto, que Q pode no estar dentro do objeto cujo MBR D: esta constatao depende ainda de um teste adicional, que verificar se o ponto pertence ao polgono do objeto, agora sim levando em considerao a geometria deste. Existem diversas variaes das rvores-R, cada uma tentando aperfeioar um aspecto diferente. No entanto, muitas vezes estas variaes introduzem desvantagens, ou uma maior complexidade de implementao, fazendo com que a rvore-R original acabe sendo a opo mais usual. 6.8 Leituras suplementares Uma fonte importante de leitura complementar so os trabalhos de Gaede e Gnther (1998) e, mais recentemente, Vitter (2001), que apresentam uma reviso detalhada da maioria dos ndices existentes. H inmeras variantes de R-trees, sendo a R*-tree a mais popular (Beckmann et al., 1990). Uma comparao entre os mtodos de acesso espacial mais comum pode ser encontrada em (Kriegel et al., 1990). Por fim, as TV-trees (Lin et al., 1994) e as X-trees (Berchtold et al., 1996) so exemplos de mtodos de acesso para dados de dimenses superiores a dois.
218
Referncias
BECKMANN, N.; KRIEGEL, H. P.; SCHNEIDER, R.; SEEGER, B. The R*-tree: An Efficient and Robust Access Method for Points and Rectangles. In: ACM SIGMOD, p. 322-331, 1990. BENTLEY, J. L. Multidimensional binary search trees used for associative searching. Communications of the ACM, v. 18, n. 9, p. 509-517, 1975. BERCHTOLD, S.; KEIM, D. A.; KREIGEL, H.-P. The X-Tree: An Index Structure for High-Dimensional Data. In Proc. 22nd Int. Conf. on Very Large Databases (VLDB96), 1996. COMER, D. The ubiquitous B-Tree. ACM Computing Surveys, v. 11, n. 2, p. 121-137, 1979. CORMEN, T. H.; LEISERSON, C. E.; RIVEST, R. L. Introduction to algorithms. E.U.A.: McGraw-Hill, 1990. FRIEDMAN, J. H.; BENTLEY, J. L.; FINKEL, R. A. An algorithm for finding best matches in logarithmic expected time. ACM Transactions on Mathematical Software, v. 3, n. 3, p. 209-226, 1977. GAEDE, V.; GNTHER, O. Multidimensional access methods. ACM Computing Surveys, v. 30, p. 170-231, 1998. GARCIA-MOLINA, H.; ULLMAN, J. D.; WIDOM, J. Implementao de sistemas de bancos de Dados. Rio de Janeiro: Campus, 2001. GUTTMAN, A. R-Trees: A Dynamic Index Structure for Spatial Searching. In: Annual Meeting ACM SIGMOD. Boston, MA, 1984. p. 47-57. KRIEGEL, H.-P.; SCHIWIETZ, M.; SCHNEIDER, R.; SEEGER, B. Performance comparison of point and spatial access methods. Proceedings of the first symposium on Design and implementation of large spatial databases. Santa Barbara, California, United States. p. 89 114, 1990 . LIN, K.-I.; JAGADISH, H. V.; FALOUTSOS, C. The TV-tree an index structure for highdimensional data. VLDB Journal: Very Large Data Bases, v.3, n.4, p.517542, 1994. NIEVERGELT, J.; HINTERBERGER, H.; SEVCIK, K. The GRID FILE: An Adaptable, Symmetric Multi-Key File Structure. ACM Transactions on Database Systems (TODS), v. 9, n.1, p. 38-71, 1984. ROBINSON, J. T. Physical storage structures: The K-D-B-tree: a search structure for large multidimensional dynamic indexes. In: 1981 ACM
Referncias
219
SIGMOD international conference on Management of data. ACM Press, Washington, 1981. p. SAMET, H., 1984. The Quadtree and Related Hierarchical Data Structures. ACM Computing Surveys, v. 16, p. 187-260. VITTER, J.S. External Memory Algorithms and Data Structures. ACM Computing Surveys, v.33, n. 2, p. 209-271, 2001.
7 Processamento de consultas e gerncia de transaes

Marco Antonio Casanova
7.1 Introduo Este captulo aborda dois aspectos da implementao de um sistema de gerncia de bancos de dados geogrficos: processamento de consultas espaciais e gerncia de transaes. O texto enfatiza as questes que necessitam solues distintas daquelas empregadas em sistemas convencionais. Um dos principais componentes de todo sistema de gerncia de bancos de dados, o processador de consultas, recebe uma consulta e prepara um plano de execuo, consistindo de operaes de mais baixo nvel, implementadas pelo subsistema de armazenamento. A parte do plano responsvel pelo processamento dos objetos geogrficos tipicamente comea com uma fase de filtragem, que identifica quais objetos podem satisfazer a qualificao da consulta. Esta fase pode utilizar ndices espaciais, em geral definidos sobre aproximaes das geometrias dos objetos. A fase de refinamento do plano recupera para memria principal a geometria exata dos objetos identificados na fase anterior, computando quais deles de fato satisfazem a qualificao da consulta. A fase final do plano aplica transformaes aos objetos retornados na fase anterior, produzindo a resposta final da consulta. Um segundo componente importante de todo sistema de gerncia de banco de dados implementa a noo de transao atmica, tipicamente de curta durao. No caso de sistemas de informao geogrfica, a interao com o banco de dados comumente mais longa exigindo uma reviso dos mecanismos de controle de transaes, principalmente a criao de mecanismos para versionamento, atualizao cooperativa e bloqueio parcial de objetos.
220
Referncias para problemas especficos sobre processamento de consultas e gerncia de transaes encontram-se ao longo do texto e sugestes para leitura adicional, ao final do captulo. 7.2 Estratgia para processamento centralizado de consultas Um dos principais componentes de todo sistema de gerncia de bancos de dados o processador de consultas que, ao receber uma consulta Q, prepara um plano de execuo para Q consistindo de operaes de mais baixo nvel, implementadas pelo subsistema de armazenamento. O principal componente do processador de consultas, por sua vez, um otimizador capaz de gerar planos alternativos para execuo de consultas, estimar o custo de cada plano e escolher o de menor custo estimado. O otimizador incorpora heursticas que limitam o espao de busca, evitando uma exploso combinatorial de planos alternativos. Seguindo (Brinkhoff et al., 1993), a parte do plano responsvel pelo processamento da componente espacial de uma consulta contm trs fases (ver Figura 7.1): Fase 1: Filtragem Um banco de dados geogrfico normalmente contm estruturas de dados auxiliares, chamadas de ndices espaciais, estruturas de indexao espacial ou simplesmente ndices, que facilitam a localizao dos dados cuja componente espacial satisfaz qualificao de uma consulta. Reservamos o termo mtodo de indexao espacial para designar uma famlia de estruturas de indexao espacial. De fato, diversos mtodos de indexao espacial foram discutidos no Captulo 6. O desempenho deste passo depende da distribuio espacial dos dados e da forma como a estrutura decompe o espao, sendo que em geral baixo o fator de seletividade. Dada a complexidade da componente espacial e da semntica dos prprios operadores espaciais, em geral os ndices trabalham apenas com aproximaes das componentes espaciais (por exemplo, o retngulo mnimo envolvente). Assim, o uso de ndices para resolver a parte espacial de uma consulta apenas filtra, dos conjuntos de dados armazenados no banco de dados, aqueles que certamente no satisfazem qualificao da consulta, sendo necessrio um segundo passo.
Estratgia para processamento centralizado de consultas
221
Consulta espacial
ndice espacial
Candidatos
Filtro geomtrico
acertos
falsos acertos
candidatos
Componente responsvel pelo acesso geometria exata
Componente responsvel pelo processamento da geometria exata
falsos acertos
IDs das respostas
Geometrias das respostas
Figura 7.1 Processamento de consultas espaciais (Kriegel et al., 1993).
222
Fase 2: Refinamento Uma vez identificados os dados que se candidatam a satisfazer a qualificao da consulta, as geometrias exatas das componentes espaciais dos dados so trazidas para memria principal. sobre estas geometrias que so ento executados os operadores espaciais especificados na qualificao. As estruturas de armazenamento e indexao devem preferencialmente permitir que seja trazida para memria principal apenas a parte das componentes espaciais necessria execuo dos operadores. O desempenho deste passo depende da quantidade de dados recuperados, da sua complexidade e do custo dos operadores a aplicar, que em geral elevado. Fase 3: Ps-Processamento Depois de identificados os dados que satisfazem qualificao da consulta, usualmente necessrio pass-los para as camadas superiores da arquitetura onde sofrero processamento posterior ou sero visualizados. Assim, o sistema deve oferecer um mecanismo eficiente para passar a geometria das componentes espaciais dos dados, na sua totalidade ou em parte, para as camadas superiores. Cabe ao subsistema de armazenamento implementar os mtodos de armazenamento, que governam a utilizao das pginas fsicas em memria secundria, onde residem tanto as componentes espaciais dos dados quanto os prprios ndices espaciais. Este subsistema deve equacionar dois problemas: espao de armazenamento: a representao interna de uma componente espacial pode necessitar um espao substancial, ocupando mais de uma pgina fsica; contigidade fsica: as pginas fsicas de uma mesma componente espacial ou de componentes contguas no espao devem ser vizinhas em memria secundria, diminuindo o custo de acesso. Uma estratgia para resolver estes problemas consiste em armazenar a geometria exata das componentes espaciais dos dados fora dos ndices, digamos, em um segmento comum de pginas fsicas. Esta forma de
Exemplos de otimizao de consultas
223
armazenamento leva a ndices mais compactos e no impe limitaes ao tamanho das componentes, resolvendo assim o problema de espao de armazenamento. Porm, para enderear o problema de contigidade fsica, necessrio definir uma estratgia de gerncia para o segmento de pgina fsicas de tal forma que componentes vizinhas no espao geogrfico tenham as suas geometrias armazenadas em pginas prximas e, idealmente, que permita armazenar nas mesmas pginas diferentes tipos de geometrias. 7.3 Exemplos de otimizao de consultas Esta seo aborda, por meio de exemplos, o problema de otimizao de consultas espaciais, luz dos comentrios feitos na Seo 7.2. 7.3.1 Exemplo de processamento de seleo por regio Considere um banco de dados geogrfico sobre cidades brasileiras consistindo de apenas um conjunto de geo-objetos, CIDADES. Para cada cidade (do mundo real), h um objeto em CIDADES, cujos atributos convencionais correspondem aos dados convencionais da cidade e cuja localizao dada por um par ordenado indicando a latitude e longitude da cidade; ou seja, a localizao destes geo-objetos representada por um ponto em coordenadas geogrficas. No que se segue, suporemos que estas coordenadas esto armazenadas junto com o prprio geo-objeto, embora as operaes sobre elas possam se beneficiar de um ndice espacial sobre CIDADES. Considere agora a consulta Q, formulada informalmente como: Q. Selecione o nome e populao de todas as cidades a menos de 50km da cidade de Belo Horizonte e com mais de 50 mil habitantes. Esta consulta seria definida atravs do comando:
SELECT d.nome, d.populacao FROM d Cidade, c Cidade WHERE c.nome = "Belo Horizonte" and distance(d,c) < 50 and d.populacao > 50.000
Esta consulta exemplifica uma seleo por regio, definida por um crculo de raio de 50km, cujo centro est na localizao geogrfica da
224
cidade de Belo Horizonte. H essencialmente trs planos de execuo mais plausveis para esta consulta (entre outros possveis), discutidos a seguir. Considere inicialmente o plano de execuo P1: P11. Determine a posio b de Belo Horizonte; P12. Determine o conjunto C' de todas as cidades a 50km de b; P13. Determine o subconjunto C de C' de cidades com mais de 50 mil habitantes. As subconsultas P11 e P13 no envolvem nenhum operador espacial e, portanto, so subconsultas convencionais de Q para este plano. J a subconsulta P12 envolve o operador de distncia e a nica subconsulta espacial de Q em P1. O processamento de P1 comea com a execuo da subconsulta convencional P11, que retorna a localizao da cidade de Belo Horizonte, o ponto b. Suponha que o banco de dados inclua um ndice espacial sobre CIDADES, que chamaremos de ID-CIDADES, invisvel aos usurios, que facilite identificar todos os objetos de CIDADES cuja localizao esteja a uma certa distncia de um dado ponto. Suponha ainda que o ndice espacial seja impreciso para este caso, no sentido de tambm retornar objetos que no esto distncia especificada do ponto. Esta impreciso tpica de mtodos de indexao espacial, e contrasta com os mtodos de indexao tradicionais, que so precisos. O processamento da subconsulta P12 segue em trs passos: P121. Atravs de ID-CIDADES, determine que objetos em CIDADES podem estar a menos de 50km de b, criando o conjunto I. P122. Leia da memria secundria para a memria principal a representao interna dos objetos indicados por I, criando o conjunto C''. P123. Determine que elementos de C'' esto de fato a menos de 50km de b, criando o conjunto C'. Os elementos de I so apontadores para a localizao em memria secundria da representao interna de objetos em CIDADES. Alm
225
disto, como supomos que o ndice no exato, I poder apontar para objetos a mais de 50km de b. J os elementos de C' e C'' so representaes internas de objetos em CIDADES, armazenadas em memria principal. Assim, o passo P121 corresponde fase de filtragem P122 e P123, fase de leitura e refinamento. O processamento da subconsulta P13 agora simples, bastando extrair de cada elemento de C' os valores dos atributos de interesse e eliminando aqueles que no possuem mais de 50 mil habitantes, criando assim o conjunto C, que a resposta da consulta Q. Os elementos de C sero pares de valores, correspondendo ao nome e populao de uma cidade. O processamento de P121, P122, P123 e P3 poder ser concatenado em pipeline, ou seja, cada elemento identificado em P121 poder ser imediatamente processado por P122 e filtrado por P123, eventualmente gerando um par em C, ao ser tratado em P13. Isto evita a criao explcita dos resultados intermedirios I, C' e C'', levando a uma razovel economia no processamento global da consulta. O segundo plano, P2, inverte a ordem de execuo das restries de Q: P21. Determine a posio b de Belo Horizonte; P22. Determine o conjunto C' de todas as cidades com mais de 50 mil habitantes; P23. Determine o subconjunto C de C' de cidades a 50km de b. Os elementos de C' sero triplas em memria principal indicando o nome, populao e localizao de objetos em CIDADES com mais de 50 mil habitantes. O processamento da subconsulta convencional P22 ser particularmente eficiente se partirmos do pressuposto que o banco de dados inclui um ndice convencional sobre CIDADES, que chamaremos de ID-POP, invisvel aos usurios, que permita identificar todos os objetos de CIDADES cuja populao esteja em uma faixa de valores. Tal ndice ser provavelmente preciso, no sentido de retornar exatamente o subconjunto de cidades cuja populao est na faixa de valores dada. Porm, note que o conjunto C' corresponder a todas as cidades brasileiras com mais de 50 mil habitantes. Neste caso, a execuo de P22 d-se da seguinte forma:
226
P221. Atravs de ID-POP, determine que objetos em CIDADES possuem populao com mais de 50 mil habitantes, criando o conjunto J; P222. Leia da memria secundria para a memria principal a representao interna dos objetos indicados por J, selecionando seu nome, populao e localizao e criando o conjunto C'. O processamento da subconsulta P23 ento simplificado, bastando selecionar do conjunto C' (suposto j em memria principal) aqueles elementos que esto de fato a menos de 50km de b, criando o conjunto C. Novamente, o processamento de P221, P222 e P23 poder ser sincronizado, evitando a criao de J e C'. O terceiro plano, P3, constri dois conjuntos independentemente para, em seguida, computar a sua interseo: P31. Determine a posio b de Belo Horizonte; P32. Determine o conjunto C' de todas as cidades com mais de 50 mil habitantes; P33. Determine o conjunto C'' de cidades a 50km de b; P34. Determine a interseo C de C' e C''. A execuo detalhada deste plano uma combinao da discutida para os dois planos anteriores. At este ponto, descrevemos apenas o detalhamento de trs planos plausveis para execuo da consulta. A estimativa do custo de cada plano depende essencialmente de estimar o nmero de objetos identificados pelo ndice ID-CIDADES e pelo ndice ID-POP e est fora do escopo deste texto. Por exemplo, o plano P1 ser mais vantajoso do que P2 se IDCIDADES for razoavelmente eficiente, ou seja, no retornar muitas cidades que no esto a menos de 50km de Belo Horizonte, e se o nmero de cidades brasileiras com mais de 50 mil habitantes for muito grande. Ou seja, se a construo da resposta intermediria registrada no conjunto I for mais barata do que a registrada no conjunto J. 7.3.2 Exemplo de processamento de juno espacial Suponha agora que o banco de dados geogrfico contm tambm um conjunto de geo-objetos, AEROPORTOS, tal que, para cada aeroporto
227
brasileiro, h um objeto em AEROPORTOS cujos atributos convencionais correspondem aos dados convencionais do aeroporto e cuja localizao dada novamente pela latitude e longitude do aeroporto. Suponha ainda que o banco inclua um ndice espacial sobre AEROPORTOS, chamado ID-AEROPORTOS, que permita identificar todos os aeroportos cuja localizao esteja a uma certa distncia de um dado ponto. Considere a seguinte consulta "Selecione todas as cidades que so sede de municpios e que so atendidas por aeroportos pavimentados''. Esta consulta exemplifica uma juno espacial. Para torn-la mais precisa, suponha que uma cidade atendida por um aeroporto se a cidade dista menos de 50km do aeroporto. A consulta reformulada seria ento: Q. Selecione o nome de cada cidade e o nome de cada aeroporto tais que a cidade sede de municpio, o aeroporto pavimentado e a cidade dista menos de 50km do aeroporto. Novamente h vrios planos de execuo possveis para esta consulta, sendo os principais discutidos a seguir. Todos os planos, sob certo aspecto, reduzem o processamento da juno espacial ao processamento de vrias selees por regio. Considere o plano P1 inicialmente: P11. Determine o conjunto R contendo o nome n e localizao l de cada aeroporto pavimentado; P12. Inicialize o conjunto C como vazio; P13. Para cada elemento (n,l)R, faa: P131. Determine o conjunto dos nomes c de cidades que so sede de municpio e que esto a menos de 50km de l, acrescentando o par (c,n) a C. O processamento de P1 comea com a execuo da subconsulta convencional P11, que retorna o nome e a localizao de todos os aeroportos pavimentados. Para cada um destes, executa-se uma seleo por regio para determinar as sedes dos municpios que esto a menos de 50km do aeroporto. O processamento destas selees segue ento de acordo com uma das estratgias discutidas no exemplo anterior.
228
O segundo plano, P2, simtrico a este, recuperando primeiro o conjunto de todas as cidades que so sede de municpio para depois determinar quais aeroportos pavimentados esto a menos de 50km de cada cidade. Como supusemos que h um ndice espacial sobre o conjunto de aeroportos, este segundo plano compete com o primeiro. A determinao de qual dos dois planos mais vantajoso depende de qual conjunto for menos numeroso: os aeroportos pavimentados ou as cidades que so sede de municpio. O terceiro plano, P3, primeiro constri de forma independente dois conjuntos para, em seguida, computar a sua interseo: P31. Determine o conjunto R contendo o nome n e localizao l de cada aeroporto pavimentado; P32. Determine o conjunto S contendo o nome c e localizao s de cada sede de municpio; P33. Determine o conjunto C tal que (c,l) C se e somente se (n,l)R e (c,s)S e a distncia de l a s menor do que 50km. O passo P33 esconde uma iterao sobre os elementos de R e sobre os elementos de S. Em um caso, por exemplo, a cada elemento de R, todos os elementos de S seriam visitados para determinar quais satisfazem a condio imposta. Logo, o plano P3 nada mais do que uma reformulao do plano P1. possvel, no entanto, implementar outras formas de computar o passo P33 que tornam o plano P3 diferente dos demais. Discutiremos a seguir, brevemente, como aplicar o mtodo de varredura do espao para computar este passo. Intuitivamente, este mtodo consiste em varrer o espao em uma dada direo processando todos os objetos encontrados. No caso abaixo, usaremos um meridiano, varrendo o plano em ordem crescente de valor de longitude: P331. Ordene inicialmente os elementos de R e S em valor crescente da longitude das suas localizaes; P332. Para cada elemento de menor longitude ainda no processado, faa: P3321. Suponha que este elemento seja um par (n,l)R (se for um par (c,s)S, o processamento inteiramente semelhante);
229
P3322. Determine todos os pares (c,s)S tais que a distncia de l a s menor do que 50km; P3323. Considere o par (n,l) e todos os pares (c,s) encontrados como processados. Novamente a escolha entre os planos depende de uma estimativa do custo de cada um, discusso que est fora do escopo deste texto. 7.3.3 Exemplo de processamento de superposio de geo-campos Considere agora que o banco de dados geogrfico contm dois geocampos temticos, SOLOS e VEGETAO, indicando os tipos de solo e de vegetao do Estado de So Paulo. Suponha que os geo-campos possuam representaes por subdiviso planar. Suponha ainda, por simplicidade, que as duas representaes utilizem a mesma escala e projeo de tal forma que seja possvel operar sobre elas sem converso. Considere agora a consulta Q, formulada como: Q. Crie um geo-campo temtico com o remanescente de mata atlntica em latossolo roxo na regio B onde B uma janela, ou seja, um retngulo definido por um par (ie,sd), no mesmo sistema de coordenadas cartogrficas das representaes, indicando o canto inferior esquerdo e superior direito do retngulo. Esta consulta difere das anteriores por criar um campo temtico a partir de dois outros armazenados no banco de dados, tendo uma restrio dada por um retngulo. Discutiremos a execuo de apenas um plano, P1, para esta consulta: P11. Utilizando SOLOS, crie o campo temtico SOLOS-B indicando os tipos de solo em B; P12. Utilizando VEGETAO, crie o campo temtico VEGETAO-B indicando os tipos de vegetao em B; P13. Crie o campo temtico VEGET-REM, resposta da consulta, aplicando uma variante da operao de superposio de campos a SOLOS-B e VEGETAO-B; Ao contrrio dos exemplos anteriores em que a otimizao do plano dependia da existncia de ndices espaciais, o processamento ser facilitado aqui se supusermos a existncia de estruturas de
230
armazenamento eficientes para as representaes que facilitem recuperar as parcelas das representaes que cobrem o retngulo B. Suponha ento que as representaes envolvidas sejam armazenadas em estruturas que permitam trazer para memria principal apenas as pginas que contm os dados de vegetao ou solos na regio B ou, pelo menos, em uma regio B' que cubra B e seja significativamente menor do que a regio abrangida pelas representaes. Em uma implementao mais simples, o subsistema de armazenamento recuperar as pginas apropriadas, filtrando-as se necessrio, e materializar as representaes vetoriais dos campos SOLOS-B e VEGETAO-B. Sobre estes campos intermedirios, o processador de consultas aplicar ento a operao de superposio de representaes apropriada para criar o campo temtico VEGET-REM, resposta da consulta. J em uma implementao mais sofisticada, o subsistema de armazenamento tratar os campos SOLOS-B e VEGETAO-B como vises no materializadas dos campos originais. Mais explicitamente, quando o processador de consultas executar a operao de superposio de representaes, o subsistema de armazenamento recuperar, para memria principal, as pginas contendo os dados de vegetao ou solos medida que se tornem necessrias para a operao, sendo de fato criada apenas a representao do campo temtico VEGET-REM. 7.4 Computao de operaes bsicas Conforme discutido brevemente na Seo 7.2, dada uma consulta Q, o processador de consultas responsvel por preparar um plano de execuo para Q, consistindo de operaes de mais baixo nvel, implementadas pelo subsistema de armazenamento. Esta seo aborda ento implementaes alternativas para duas das principais operaes que um subsistema de armazenamento deve oferecer, que correspondem diretamente seleo e juno espaciais. As implementaes dependem da utilizao ou no de ndices espaciais e, conseqentemente, exibem desempenho bastante diferenciado.
Computao de operaes bsicas
231
7.4.1 Computao de selees espaciais Uma seleo espacial uma expresso da forma [B(x)], onde B(x), chamado de predicado de seleo, uma expresso booleana com apenas uma varivel livre, x, tal que B(x) envolve operaes espaciais. Dado um conjunto S de geo-objetos, [B(x)](S)=S se e somente se S o conjunto de todos os objetos sS tais que B(s) verdadeira. Um exemplo de seleo espacial a expresso [distancia(x,p)<100], onde x a varivel livre e p uma constante do tipo ponto. Seja S um conjunto de geo-objetos no que se segue. Usaremos r.e.m. para abreviar o termo retngulo envolvente mnimo. A estratgia mais simples para computar [B(x)](S), denominada seleo por pesquisa exaustiva, apresentada em pseudo-cdigo na Figura 7.2. Consiste em trazer a representao geomtrica de cada objeto sS para memria principal e testar se B(s) verdadeira. Possui custo proporcional cardinalidade de S, se os objetos de S no estiverem agrupados em memria secundria, ou proporcional ao nmero de pginas ocupadas por S, em caso contrrio. Esta estratgia adotada quando no h ndices para S, ou quando a cardinalidade de S suficientemente pequena para no justificar estratgias mais sofisticadas.
SELEO_POR_PESQUISA_EXAUSTIVA(S,B;R) S - conjunto de geo-objetos B - expresso booleana envolvendo comparaes espaciais com apenas uma varivel livre x R - subconjunto de S dos objetos satisfazendo B Inicio R = Para cada s em S faa Inicio Recupere s para memria principal Se s satisfaz B, acrescente s a R Fim Fim
Figura 7.2 Seleo por pesquisa exaustiva.
232
Conforme discutido no Captulo 6, quando a cardinalidade esperada de S suficientemente grande e a freqncia de acesso a S alta, costuma-se definir um ndice para acelerar o acesso aos objetos de S. A estratgia para computar [B(x)](S), denominada seleo por ndice, apresentada em pseudo-cdigo na Figura 7.3 e possui duas etapas. A etapa de filtragem utiliza um ndice para selecionar parte dos objetos de S, criando um conjunto P de apontadores para objetos em S. A etapa de refinamento recupera para memria principal a representao geomtrica de cada objeto s apontado por P, acrescentando s resposta, se B(s) for verdadeira.
SELEO_POR_INDICE(S,B,I,C;R) - conjunto de geo-objetos - predicado de seleo - ndice sobre S - expresso booleana envolvendo comparaes espaciais com apenas uma varivel livre que pode ser resolvida por I R - conjunto dos objetos de S que satisfazem B Inicio R, P = FILTRO(I,C;P) % Etapa 1: Filtragem Para cada p em P faa % Etapa 2: Refinamento Inicio Recupere o objeto s de S apontado por p Se s satisfizer B, acrescente s a R Fim Fim FILTRO(I,C;P) Inicio P = Acrescente a P todos os apontadores para objetos de S que satisfazem C, usando I S B I C Fim
Figura 7.3 Seleo por ndice.
Normalmente, o ndice no resolve B diretamente, mas uma outra expresso booleana C, tambm com uma varivel livre, tal que:
233
(1) para todo geo-objeto s, se C(s) = falso ento B(s) = falso Assim, se um geo-objeto s no selecionado pelo ndice (ou seja, C(s) falso), ento s no pertence resposta da seleo (ou seja, B(s) tambm falso). Porm, o ndice pode selecionar um objeto s que no pertence resposta (ou seja, pode existir um geo-objeto s tal que C(s)B(s)). O resto desta seo refina a funo auxiliar FILTRO para rvores-R. Dados dois inteiros m>1 e n>1, recorde que uma rvore-R de ordem (m,n) para S uma rvore de busca balanceada tal que (veja exemplo na Figura 7.4): todas as folhas esto no mesmo nvel; cada folha contm entre n/2 e n entradas; cada n interior contm entre m/2 e m filhos, exceto a raiz, que contm entre 2 e m filhos; para cada objeto sS, existe uma (nica) entrada em uma (nica) folha M, consistindo de um ponteiro para s em conjunto com o r.e.m. de s; dizemos que s apontado por M; cada n interior N contm uma entrada para cada filho M de N, consistindo de um ponteiro para M e o r.e.m. de M, ou seja, o r.e.m. de todos os retngulos armazenados em M.
1 A
B
C H 3 G F I
D E
2
A B C D
3 G H I J
Figura 7.4 Exemplo de uma rvore-R.
A computao de [B(x)](S) guiada pelos retngulos armazenados na rvore-R, dependendo evidentemente da expresso booleana B.
234
Considere, por exemplo, a computao da seleo [contem(x,p)](S), onde p uma constante do tipo ponto. Voltando Figura 7.4, para determinar quais objetos sS contm p, proceda da seguinte forma. Observe inicialmente que os retngulos 1 e 3, armazenados na raiz, contm p; estes retngulos correspondem ao primeiro e ao segundo filho da raiz. Em seguida, repita o processo descendo por estes ns. Assim, descendo pelo primeiro filho da raiz, observe que o retngulo C contm p e acrescente o ponteiro a ele associado a uma lista temporria L. Descendo pelo terceiro filho da raiz, observe que nenhum retngulo a armazenado contm p. Como ltimo passo, recupere para memria principal o objeto s apontado pelo (nico) ponteiro em L e teste se s de fato contm p; se contiver, [contem(x,p)](S) ={s}; caso contrrio, [contem(x,p)](S)=. De forma geral, o uso de rvores-R como ndices coloca um desafio adicional pois as folhas da rvore armazenam retngulos aproximando a geometria dos objetos, e no a geometria em si. Alm disto, cada n interior N contm uma entrada para cada filho M de N, consistindo de um ponteiro para M e o r.e.m. dos retngulos armazenados em M. Portanto, para que rvores-R possam ser utilizadas na etapa de filtragem, devemos definir um segunda expresso booleana C, que chamaremos de companheira de C, tal que: (2) para todo geo-objeto s, para todo retngulo r tal que r igual ou contm o r.e.m. de s, se C(r) = falso ento C(s) = falso Dizemos que uma expresso booleana C(x), com uma varivel livre x varrendo geo-objetos, pode ser filtrada por rvores-R se somente se possvel definir uma expresso booleana companheira para C. Note que C no a expresso booleana C da Figura 7.3. Porm, de (1) e (2) podemos deduzir diretamente que (3) para todo geo-objeto s, para todo retngulo r tal que r igual ou contm o r.e.m. de s, se C(r) = falso ento B(s) = falso Ou seja, apesar de trabalhar com retngulos, atravs da noo de expresso companheira, as arvores-R podem ser utilizadas como filtros. Freqentemente, C a prpria expresso C. Por exemplo, se tivermos C(x)=contem(x,k), onde x uma varivel varrendo geo-objetos e k uma
235
constante espacial, ento C(r)=contem(r,k), para todo retngulo que contm ou igual ao r.e.m. de x. Porm, isto nem sempre verdade. Tome, por exemplo, C(x)=toca(x,k), onde x uma varivel varrendo geo-objetos e k uma constante espacial. Neste caso, C(x) no implica em C(r), para todo retngulo que contm ou igual ao r.e.m. de x. Por exemplo, teramos que definir C como: C(r) = superpe(r,k) toca(r,k) Em outras situaes, no realmente possvel definir C de tal forma a tornar rvores-R teis para filtrar C(x). Por exemplo, tomemos C(x) = disjunto(x,k), onde x uma varivel varrendo geo-objetos e k uma constante espacial. Para este operador, teramos que definir C como: C(r) = disjunto(r,k) superpe(r,k) o que seria intil como filtro. De posse destas noes, o refinamento da funo auxiliar FILTRO para rvores-R imediato e mostrado na Figura 7.5. Note que esta funo continua a receber a expresso booleana C sobre objetos de S, por compatibilidade com FILTRO, e internamente determina (por um processo no especificado) a expresso C companheira de C, que supese existir. O pseudo-cdigo apresentado consiste de um caminhamento em amplitude na rvore, com o auxlio da varivel Q, eliminando os ns cujos r.e.m. no satisfazem C, e retornando os apontadores para objetos, contidos nas folhas, cujos r.e.m.s satisfazem C. Portanto, consistentemente com a estratgia de seleo por ndice, esta funo no acessa a geometria dos objetos. Por fim, simplificadamente, o custo de uma pesquisa por ndice, utilizando rvores-R, proporcional ao nmero de ns da rvore-R lidos, somado ao nmero de objetos apontados pela rvore-R cujo retngulo envolvente satisfaz C. Uma anlise detalhada pode ser encontrada em (Aboulnaga e Naughton, 2000) (Kriegel et al., 1990) (Ciferri et al., 1995).
236
FILTRO_ARVORE_R(A,C;P)
A - apontador no nulo para raiz de uma rvore-R sobre um conjunto de geo-objetos S. Cada n N uma estrutura da forma: lt(N) lista de entradas; rem(N) r.e.m. das entradas em lt(N) Cada entrada E uma estrutura da forma: N interior: pt(E) apontador para a raz de uma sub-rvore de A rem(E) retngulo envolvente mnimo da sub-rvore apontada por E Folha: pt(E) apontador para um objeto em S rem(E) retngulo envolvente mnimo do objeto apontado por E C - expresso booleana envolvendo comparaes espaciais com apenas uma varivel livre que pode ser filtrada por A P - conjunto de apontadores para objetos de S Inicio Determine a expresso C companheira de C P = Q = {A} Enquanto Q faa: Inicio Selecione q em Q, removendo-o de Q Se q for uma folha, Para cada entrada E em ls(q), Se C(rem(E)), acrescente pt(E) a P Seno Para cada entrada E em ls(q), Se C(rem(E)), acrescente pt(E) a Q Fim Fim
Figura 7.5 Filtro por rvores-R.
237
7.4.2 Computao de junes espaciais Uma juno espacial uma expresso da forma [J(x,y)], onde J(x,y), chamado de predicado de juno, uma expresso booleana envolvendo apenas comparaes espaciais com duas variveis livres x e y. Dados dois conjuntos S e T de geo-objetos, [J(x,y)](S,T)=R se e somente se R o conjunto de todos os pares de objetos (s,t)ST tais que J(s,t) verdadeira. Um exemplo de juno espacial a expresso [distancia(x,y)<100], onde x e y so variveis. O predicado de juno define o conjunto de pares de geo-objetos, x e y, que esto a menos de 100 e a mais de 50 (metros) um do outro. Computar [J(x,y)](S,T) mais complexo do que computar junes no espaciais pois no h uma ordem total entre geo-objetos que preserve proximidade espacial. Ou seja, no h uma funo que mapeie qualquer par (S,T) de conjuntos de geo-objetos em uma seqncia Q de geoobjetos tal que todo objeto em ST ocorre uma nica vez em Q e, para todo (s,t)ST, se s e t esto espacialmente prximos, ento s e t esto prximos em Q. Esta caracterstica dos geo-objetos afeta as estratgias tradicionais para computar juno, tornando-as inaplicveis ou menos eficientes. Esta seo discute algumas estratgias para computar juno espacial, seguindo basicamente (Brinkhoff et al., 1993) (Brinkhoff et al., 1994) (Gunther et al., 1993) (Patel e DeWitt, 1996). Considere inicialmente a estratgia de juno por pesquisa exaustiva para computar [J(x,y)](S,T), apresentada na Figura 7.6. Esta estratgia consiste em duas iteraes aninhadas varrendo todos os pares de objetos (s,t) em ST, testando J(s,t) para cada um deles. Ou seja, consiste de uma pesquisa exaustiva sobre ST, o espao de busca de [J(x,y)](S,T). Esta estratgia levanta dois problemas bsicos relativos computao de uma juno espacial. Primeiro, a transferncia dos geo-objetos da memria secundria para memria principal pode ser uma operao de alto custo, quando as geometrias dos objetos so extensas. Esta transferncia pode, de fato, forar a liberao de geo-objetos de T para permitir a reutilizao de espao na rea de trabalho em memria
238
principal. Desta forma, o mesmo objeto em T poder ser transferido vrias vezes para memria principal. No pior caso, cada objeto em T ser lido n vezes, onde n a cardinalidade de S. Assim, o prprio aninhamento das iteraes torna-se ainda mais ineficiente. Segundo, o teste do predicado de juno pode tambm ser uma operao de alto custo, principalmente se a geometria dos objetos consistir de um grande nmero de pontos. O problema agravado pelo fato de que este teste ser realizado para todos os pares (s,t)ST.
JUNO_POR_PESQUISA_EXAUSTIVA(S,T,J;R) S,T J R - conjuntos de objetos espaciais - expresso booleana envolvendo comparaes espaciais com duas variveis livres - conjunto de pares de objetos em ST que satisfazem J
Inicio R = Para cada s em S faa Inicio Recupere s de memria secundria para memria principal Para cada t em T faa Inicio Se t no est em memria principal, recupere t de memria secundria para memria principal Se J(s,t), acrescente (s,t) a R Fim Fim Fim
Figura 7.6 Juno por pesquisa exaustiva.
Uma segunda estratgia para computar [J(x,y)](S,T), chamada de juno por particionamento e intercalao (Patel e DeWitt, 1996), opera
239
em duas etapas, filtragem e refinamento, sem recorrer a ndices. De forma semelhante seleo espacial, assumiremos que a etapa de filtragem aplica-se a um predicado K(x,y) tal que, para todo x, y, se K(x,y) verdadeiro ento J(x,y) tambm verdadeiro. Alm disto, o predicado K deve ser tal que: (4) para todo par (s1,s2) de geo-objetos, com r.e.m.s r1 e r2 respectivamente, se r1 e r2 no se superpem ento K(s1,s2) = falso O passo inicial da etapa de filtragem cria e armazena em memria secundria dois conjuntos temporrios, S0 e T0, da seguinte forma. Cada geo-objeto sS lido para memria principal, gerando um objeto s0S0 da forma s0=(p,r), onde p o identificador de s em memria secundria, denotado id(s0), e r o r.e.m. de s, denotado rem(s0). O mesmo processo aplicado a T, gerando T0. O prximo passo desta etapa determina todos os pares de objetos (s0,t0)S0T0 tais que rem(s0) e rem(t0) se superpem. Para cada par (s0,t0) que passar no teste, o par de identificadores (id(s0),id(t0)) acrescentado resposta desta fase. Se os conjuntos temporrios S0 e T0 puderem ser simultaneamente trazidos para memria principal, uma tcnica de varredura do plano (Preparata e Shamos, 1988) poder ser adotada para determinar quais retngulos se superpem. Por exemplo, um conjunto de retngulos pode ser varrido em ordem crescente da coordenada do canto inferior esquerdo, como ilustra a Figura 7.7. Um algoritmo, baseado em uma tcnica de varredura, para determinar quais pares de retngulos (r,s)A1A2 se superpem apresentado na Figura 7.8.
240
r1 r4
r5 r4
r3
r6
X(r1) X(r4)
X(r5)
X(r6) X(r3)
X(r2)
Ordem de varredura: r1, r4, r2, r5, r3, r6
Figura 7.7 Exemplo de varredura do plano para retngulos.

VARREDURA_DO_PLANO(A1,A2;B) A1,A2 - conjuntos de retngulos com lados paralelos aos eixos x e y; xe(r) e xd(r) denotam as coord. x dos vrtices esquerda e direita de r B - (r,s)A1A2 tal que r e s se sobrepem Inicio R = C = A1 A2 Ordene C crescentemente por xe(r) Enquanto C faa Inicio Seja rC com menor valor de xe(r) Remova r de C e suponha que rAi % A(i+1) : soma mdulo 2 Para cada sA(i+1) at que xe(s)>xd(r) faa % xe(r)xe(s)xd(r): r e s se superpem no eixo x Se r e s tambm se superpem no eixo y, acrescente (r,s) a B Fim Fim
Figura 7.8 Tcnica de varredura para determinar superposio de retngulos.
Se os conjuntos no puderem ser trazidos para memria principal, ento cada conjunto deve ser particionado em p conjuntos no
241
necessariamente disjuntos S1,...,Sp e T1,...,Tp, respectivamente. Estes novos conjuntos so tais que Sk e Tk, para k=1,...,p, podem ser simultaneamente trazidos para memria e, para todo (s0,t0)S0T0 tais que rem(s0) e rem(t0) se superpem, se s0Sk ento t0Tk. A criao destas parties segue a seguinte ttica (Patel e DeWitt, 1996): (a) Ao criar S0 e T0, determine R, o r.e.m. de todos os retngulos em S0 e T0. (b) Considerando o tamanho da rea de trabalho disponvel em memria principal e o tamanho de cada elemento em S0 e T0, determine o nmero p de partes em que R deve ser dividido, criando retngulos R1,...,Rp (ver Figura 7.9). (c) Os conjuntos S1,...,Sp e T1,...,Tp so criados da seguinte forma: para cada k[1,p], para cada s0S0, s0Sk se e somente se rem(s0) e Rk se superpem para cada k[1,p], para cada t0T0, t0Tk se e somente se rem(t0) e Rk se superpem O nmero p de partes em que R deve ser dividido pode ser estimado da seguinte forma. Sejam |S0| e |T0| as cardinalidades de S0 e T0, respectivamente. Seja M o espao disponvel em memria principal e N o tamanho de cada objeto em S0 e T0. Como necessrio manter Sk e Tk simultaneamente em memria principal, temos que: p = (|S0| + |T0|)*N/M Aps o particionamento, para cada k[1,p], os conjuntos Sk e Tk so suficientemente pequenos para serem simultaneamente trazidos para memria principal. Novamente a tcnica de varredura do plano pode ser adotada para determinar todos os pares de objetos (sk,tk)SkTk tais que rem(sk) e rem(tk) se superpem. Para cada par (sk,tk) que passar no teste, (id(sk),id(tk)) acrescentado resposta desta fase. Isto conclui a etapa de filtragem. O resultado um conjunto F de pares de identificadores de objetos em S0T0.
242
Partio 0
Partio 1
Partio 2
Partio 3
Figura 7.9 Diviso dos conjuntos originais contendo os r.e.m.s.
A etapa de refinamento procede da seguinte forma. Para evitar acesso aleatrio aos objetos de S e T, os pares no resultado F da etapa de filtragem so ordenados tendo como chave a primeira coordenada seguida da segunda coordenada. Duplicatas so eliminadas neste processo, gerando o conjunto G. Em seguida, para cada par (d,e)G, o objeto sS tal que d=id(s) trazido para a rea de trabalho, se j l no estiver. Para cada par (f,g)G tal que f=d, o objeto tT tal que g=id(t) tambm trazido para a rea de trabalho. Se J(s,t) for satisfeito, ento o par (s,t) finalmente adicionado resposta de [J(x,y)](S,T). Como na seleo espacial, uma outra forma de reduzir o custo de computar uma juno espacial [J(x,y)](S,T) consiste em utilizar ndices. Uma estratgia genrica, denominada juno por ndice, tambm possui duas etapas, exceto que a estratgia utiliza um ndice para a etapa de filtragem. A Figura 7.10 apresenta a estratgia em pseudo-cdigo e a Figura 7.11 ilustra a estratgia esquematicamente. De acordo com (Brinkhoff et al., 1994), a Etapa 2 a de maior custo, tanto em termos de acesso a memria secundria para recuperar a geometria exata dos objetos, quando em termos de tempo de processamento para computar o predicado de juno. Note que a estratgia, como apresentada na Figura 7.10, apenas um framework, que deve ser refinado com implementaes especficas em cada etapa. Para a etapa de filtragem, por exemplo, (Brinkhoff et al.,
243
1993) (Brinkhoff et al., 1994) usam rvores-R* e (Patel e DeWitt, 1996) (Lo e Ravishankar, 1996) propem uma estrutura baseada em hash. J para a etapa de refinamento, (Brinkhoff et al., 1994) adota um algoritmo de varredura do plano, conforme anteriormente apresentado. O resto desta seo discute o refinamento da etapa de filtragem para o caso em que os ndices so rvores-R. (Brinkhoff et al., 1993) (Brinkhoff et al., 1994) (Gunther et al., 1993). Seja K(x,y) o predicado a ser filtrado pelas rvores-R. Novamente, para que rvores-R possam ser utilizadas, devemos definir uma segunda expresso booleana K, que chamaremos de companheira de K, tal que: (5) para todo par (s1,s2) de geo-objetos, para todo par (r1,r2) de retngulos tais que ri igual ou contm o r.e.m. de si, para i=1,2, se K(r1 ,r2) = falso ento K(s1,s2) = falso O refinamento proposto, apresentado como filtro de juno por rvoreR na Figura 7.12, consiste de uma dupla pesquisa por amplitude nas duas rvore-R. A varivel Q contm apenas os pares de retngulos (r1,r2) tais que K(r1,r2)=verdadeiro. Pela propriedade acima de K e pela construo das rvores-R, para todo par (s,t)ST, se K(s,t)=verdadeiro, ento (pt(s),pt(t))P, onde P a resposta devolvida pelo filtro (mas o converso falso, ou seja, poder existir (s,t)ST tal que K(s,t)=falso e (pt(s),pt(t))P pelo prprio fato das rvores-R trabalharem com aproximaes, ou seja, no serem filtros exatos.
244
JUNO_POR_INDICES(S,T, J,U,V,K;R) - conjuntos de objetos espaciais - expresso booleana envolvendo comparaes espaciais com duas variveis livres U,V - ndices sobre S e T, respectivamente K - expresso booleana envolvendo comparaes espaciais com duas variveis livres a ser filtrada por U e V R - conjunto de pares de objetos em ST que satisfazem J Inicio R = % Etapa 1: Filtragem por ndice - Use os ndices espaciais U e V sobre S e T para computar o conjunto R1 de pares de retngulos, u e v, tais que K(u,v) % Etapa 2: Refinamento - Para cada entrada (u,v) em R2, acesse as geometrias do par de objetos (s,t) correspondente a (u,v) - se J(s,t), acrescente (s,t) resposta R Fim S,T J
Figura 7.10 Juno por ndices.
245
Conjunto S
Conjunto T
Filtragem por ndice ndice espacial U ndice espacial V
Refinamento
Pares candidatos
Componente responsvel pelo acesso geometria exata
Componente responsvel pelo processamento da geometria exata
falsos acertos
IDs das respostas
Geometrias das respostas
Figura 7.11 Esquema da juno por ndices. Fonte: adaptado de Kriegel et al., (1993).
246
FILTRO_DE_JUNCAO_POR_ARVORE_R(A,B,K;P) A,B- apontadores para as razes de duas rvores-R sobre conjuntos de geo-objetos S e T (com a estrutura indicada na Figura 7.5). Supe-se que A e B no sejam nulos. K - expresso booleana envolvendo comparaes espaciais com duas variveis livres que pode ser filtrada por rvores-R P - conjunto de pares de apontadores para objetos de S e T Inicio Determine a expresso K companheira de K P = Q = {(A,B)} Enquanto Q faa: Inicio Selecione (p,q) em Q, removendo-o de Q Se p e q forem folhas, Para cada entrada E em ls(p), Para cada entrada F em ls(q), Se K(rem(E),rem(F)), acrescente (pt(E),pt(F)) a P Se p for folha e q for n interior, Para cada entrada F em ls(q), Se K(rem(p),rem(F)), acrescente (p,pt(F)) a Q Se q for folha e p for n interior, Para cada entrada E em ls(p), Se K(rem(E),rem(q)), acrescente (pt(E),q) a Q Fim Fim
Figura 7.12 Filtro de juno por rvore-R.
247
7.4.3 Computao de superposies de mapas temticos Um polgono simples se e somente se no h um par de arestas noconsecutivas compartilhando um ponto. Um polgono simples com furos um polgono simples ou um par (p,F) onde p um polgono simples e F um conjunto no vazio de polgonos simples com furos tais que, para todo qF, q est contido no interior de p e, para todo q, qF, q e q so disjuntos.
polgono simples
polgono simples com furos polgono no-simples
Figura 7.13 Exemplos de polgonos (Kriegel et al., 1992).
Seja o conjunto dos polgonos simples com furos. Um conjunto de temas qualquer conjunto finito no vazio. Um mapa temtico vetorial sobre um conjunto de temas T uma funo parcial M:T tal que, para todo p,qdom(M), p e q so disjuntos. Denotaremos por [T] o conjunto dos mapas temticos sobre um conjunto de temas T. Esquemas de armazenamento, em memria secundria, para mapas temticos vetoriais so variantes dos esquemas de armazenamento de polgonos onde cada polgono possui um atributo indicando o seu tema. Desta forma, ndices para conjuntos de polgonos podem ser utilizados diretamente para indexar os domnios dos mapas temticos. Sejam T, U e V conjuntos de temas e f: TUV uma funo total. A superposio de mapas temticos induzida por f a funo [f]:[T][U][V] definida como [f](M,N)=O se e somente se
248
dom(O) o conjunto dos polgonos com furos obtidos pela interseo dois-a-dois de um polgono em dom(M) com um polgono em dom(N); O(p)=f(q,r) se e somente se p faz parte da interseo de q e r
H trs questes que devem ser levadas em considerao na computao da superposio [f](M,N)=O de dois mapas temticos vetoriais: (1) M e N so normalmente grandes e, portanto, devem ser trazidos progressivamente para memria principal; (2) alm da geometria, necessrio armazenar e recuperar o tema de cada polgono nos domnios de M e N; (3) a etapa de refinamento deve ser seguida por um ps-processamento para computar os polgonos no domnio do mapa resultante O e o valor associado a cada um destes polgonos. Apesar destas questes, estratgias para computar [f](M,N) podem ser obtidas modificando-se as estratgias para juno espacial apresentadas anteriormente, considerando-se como predicado de juno a superposio de polgonos, e acrescentando-se uma etapa de psprocessamento como indicado acima. De fato, variantes da estratgia para computar [f](M,N) denominada particionamento por varredura do plano (Kriegel et al., 1992) podem ser derivadas da juno por particionamento e intercalao e da juno por ndice. 7.5 Gerncia da rea de trabalho
7.5.1 Principais questes na gerncia da rea de trabalho A definio de uma estratgia para gerncia da rea de trabalho em memria principal suscita algumas questes importantes, discutidas nesta seo, para que efetivamente contribua para um melhor desempenho do processador de consultas. No que segue, usaremos o termo objeto para designar indistintamente, pginas fsicas, objetos lgicos ou conjuntos destes. Em primeiro lugar, h a questo do tipo de objeto fsico ou lgico que ser mantido na rea de trabalho. Normalmente, os sistema de gerncia de banco de dados objeto-relacionais trabalham com pginas fsicas na rea de trabalho, enquanto que os sistemas orientados-a-objeto
Gerncia da rea de trabalho
249
estritos podem trabalhar com pginas fsicas, objetos lgicos ou conjuntos de objetos. Uma estratgia de gerncia da rea de trabalho chamada de semntica quando trabalha com objetos lgicos ou conjuntos de objetos e utiliza caractersticas destes objetos ou conjuntos para implementar seus algoritmos. Associada a esta primeira questo, est a deciso de que nvel de granularidade a estratgia de gerncia adota. A estratgia pode controlar pginas fsicas ou objetos lgicos individualmente, ou trabalhar com segmentos fsicos, compostos por pginas fsicas e segmentos semnticos, compostos por objetos lgicos. A terceira questo a poltica de substituio dos objetos mantidos na rea de trabalho. A maioria dos sistemas usa uma variante da estratgia usualmente chamada LRU Least Recentently Used, que prope substituir o objeto que est h mais tempo na rea de trabalho. Uma variante desta estratgia ser discutida na seo seguinte. Alm destas, h a questo de criar polticas de antecipao que tragam objetos para a rea de trabalho antes de serem solicitados por uma consulta. Naturalmente, uma boa poltica de antecipao pode acelerar o processamento de consultas, mas depende de um bom entrosamento com o processador de consultas. 7.5.2 rea de trabalho utilizando segmentos semnticos Esta seo discute as caractersticas bsicas de estratgias para gerncia da rea de trabalho que a organizem em segmentos lgicos, seguindo (Ren et al., 2003). Ao processar uma nova consulta Q, o relacionamento entre o seu resultado e os segmentos lgicos na rea de trabalho recai nos 4 casos mostrados na Figura 7.14. No caso 4, o resultado de Q est inteiramente contido na rea de trabalho e nenhum novo objeto precisa ser trazido de memria secundria. Porm, informao adicional mantida junto aos segmentos lgicos poder ser atualizada para refletir o processamento de Q. Em todos os outros casos, o resultado de Q dever ser, em parte ou na sua totalidade, adicionado rea de trabalho e, novamente, informao adicional ser gerada ou atualizada.
250
rea de trab. rea de trab. consulta caso 1 consulta caso 2 rea de trab. consulta caso 3
rea de trab. consulta
caso 4
Figura 7.14 Relacionamentos entre o resultado de uma nova consulta e a rea de trabalho (Ren et al., 2003).
Mais precisamente, suponha que o contedo da rea de trabalho possa ser representado pelo predicado C e seja R o resultado de uma consulta Q, com predicado de consulta QP. A poltica de incluso determina como tratar R em presena de C: 1. (QPC): o resultado de Q deve ser inteiramente includo na rea de trabalho (Caso 1 da Figura 7.14). 2. (QPC): o resultado de Q dever ser ignorado pois est inteiramente contido na rea de trabalho (Caso 4 da Figura 7.14). 3. Nenhum dos casos acima: o resultado de Q dever ser parcialmente includo na rea de trabalho (Casos 2 e 3 da Figura 7.14). Usualmente, as implementaes da poltica de incluso testam o resultado de uma consulta contra cada segmento semntico em separado e tentam chegar a uma concluso. Suponha que R, o resultado da consulta, se superpe a um segmento semntico S. A poltica de colapsamento determina como tratar este tipo de superposio, escolhendo entre 3 opes: 1. Colapsar totalmente R e S, criando um novo segmento semntico S1=RS. 2. Colapsar parcialmente R e S, criando dois novos segmentos semnticos, S1=R e S2=SR. 3. No colapsar R e S, criando trs novos segmentos semnticos, S1=RS, S2=SR e S3=SR.
251
Colapsar totalmente R e S reduz o nmero de segmentos lgicos na rea de trabalho, o que simplifica a sua gerncia e reduz o tempo de processamento do critrio de incluso. Por outro lado, esta poltica tende a criar segmentos lgicos muito grandes, embora s uma parte dos objetos no segmento seja efetivamente usada. No colapsar R e S produz o efeito inverso pois tende a gerar segmentos lgicos com uma granularidade muito fina. Colapsamento parcial normalmente a melhor escolha pois abre a possibilidade de balancear o tamanho dos segmento lgicos. A poltica de substituio determina qual segmento semntico deve ser removido da rea de trabalho quando o resultado de uma nova consulta no puder ser acomodado. Assumindo a poltica de colapsamento parcial, a poltica de substituio tradicional, LRU, de remover o segmento lgico que est h mais tempo na rea de trabalho no adequada pois os objetos em um segmento resultam das respostas de vrias consultas e, portanto, possuem diferentes tempos de residncia na rea de trabalho. Neste caso, a poltica LRU pode ser substituda por uma verso mais sofisticada, chamada de LRU dinmica, ou D-LRU (Ren et al., 2003). Brevemente, seja R novamente o resultado de uma consulta e S um segmento semntico que se sobrepe a R. Suponha que S seja decomposto em S1=RS, S2=SR e S3=SR. A poltica D-LRU mantm a data de S para o segmento S2 e cria S1 e S3 com a data de execuo de Q. Se a rea de trabalho no pode acomodar o resultado R da consulta, os segmentos mais antigos so descartados, como na poltica LRU tradicional, at que haja espao livre suficiente. H estratgias mais sofisticadas que utilizam uma noo de distncia semntica para selecionar o objeto a substituir, como a apresentada em (Dar et al., 1996). 7.5.3 Exemplo de estratgia de gerncia da rea de trabalho Esta seo exemplifica o uso dos conceitos apresentados na seo anterior para construir uma estratgia de gerncia da rea de trabalho que melhore o desempenho de aplicaes de explorao visual dos dados,
252
tpicas de sistemas de informao geogrfico. Esta seo segue basicamente (Doshi et al., 2003). Suponha que, na aplicao de explorao visual dos dados, o usurio interaja diretamente com uma janela de visualizao atravs das operaes usuais de aproximao, afastamento, deslocamento e enquadramento (zoomin, zoom-out, panning, fitting). Estas operaes geram ento consultas aos dados. A rea de trabalho armazena segmentos semnticos, definidos por conjuntos de geo-objetos. Cada segmento semntico est associado ao r.e.m. dos objetos nele contidos. O resto desta seo discute, em detalhe, polticas de antecipao de acesso aos geo-objetos. Em uma aplicao de explorao visual dos dados, uma poltica de antecipao especialmente interessante por duas razes: (1) o usurio passa considervel tempo analisando os dados visualizados, deixando o processador e o disco ociosos; logo, possvel utilizar o processador e o disco para pr-carregar dados sem afetar a explorao dos dados; (2) dadas as caractersticas das operaes, possvel prever qual ser o prximo movimento do usurio. Em geral, uma poltica de antecipao deve trabalhar gradativamente, medida que descobre novas caractersticas do comportamento do usurio ou dos dados acessados. No incio do processo de explorao visual, pouca ou nenhuma informao est disponvel. Com o tempo, mais caractersticas do comportamento do usurio ou dos dados acessados tornam-se evidentes, melhorando a qualidade dos dados trazidos antecipadamente para a rea de trabalho. Mais especificamente, para aplicaes de explorao visual dos dados, assumimos que a poltica de antecipao deve detectar se o usurio: (1) tende a manter a direo da operao de deslocamento (da janela de visualizao) ou alter-la; (2) se os dados sob anlise visual possuem regies de interesse s quais o usurio tende a voltar. Baseadas nestas suposies, podemos definir as seguintes polticas de antecipao (Doshi et al., 2003): P1 aleatria; P2 direo de deslocamento; P3 foco do usurio.
253
A poltica de antecipao aleatria, ilustrada na Figura 7.15 (a), escolhe aleatoriamente a direo do deslocamento da janela de visualizao, dando pesos iguais s quatro possveis direes. Esta poltica naturalmente se aplica quando no possvel detectar caractersticas teis no comportamento do usurio ou do acesso aos dados. A poltica de antecipao baseada na direo de deslocamento, ilustrada na Figura 7.15(b), semelhante anterior, exceto que d maior peso a uma direo, se o usurio moveu a janela de visualizao duas vezes seguidas naquela direo. J a poltica de antecipao baseada no foco do usurio mais sofisticada e utiliza indicaes sobre o prximo deslocamento e sobre regies de interesse do usurio. Uma regio considerada como uma regio de interesse em uma sesso de trabalho quando o usurio a visita mais do que k vezes, onde k um parmetro da poltica. Uma regio de interesse descrita por uma data e um retngulo. Enquanto nenhuma regio de interesse estiver prxima da janela de visualizao, esta poltica trabalha de forma semelhante poltica baseada na direo de deslocamento. Quando alguma regio de interesse torna-se prxima janela de visualizao, esta poltica antecipa a carga dos objetos na direo da regio de interesse, e no na direo dos ltimos deslocamentos. Esta poltica reflete ento a intuio de que o usurio provavelmente governa a visualizao em direo regio de interesse e l permanecer por algum tempo. Por fim, a poltica de substituio combina a estratgia de D_LRU com a poltica de antecipao. Assim, os segmentos semnticos mais antigos e fora da direo indicada pela poltica de antecipao devem ser descartados primeiro, at que seja liberada memria suficiente para acomodar os novos a serem trazidos para memria principal.
254
p = 1/4
p = 1/4
p = 1/4
p = 1/4
movimento anterior
movimento atual
previso de movimento
Janela Corrente
Regies de interesse
Figura 7.15 Relacionamentos entre o resultado de uma nova consulta e a rea de trabalho (Ren et al., 2003).
7.6
Gerncia de transaes
7.6.1 Transaes em bancos de dados geogrficos Em aplicaes convencionais de banco de dados, um usurio modifica os dados atravs de uma seqncia de operaes elementares que devem ser executadas como um todo. As operaes so tipicamente curtas e envolvem um volume pequeno de dados. Por exemplo, uma transferncia de fundos implementada atravs de duas atualizaes, em contas bancrias distintas, que devem ser ambas executadas ou ambas canceladas, para evitar erros.
Gerncia de transaes
255
Esta situao configura uma transao, ou seja, uma seqncia de operaes que o sistema de gerncia de banco de dados deve processar at o fim, ou garantir que o banco de dados no reflita nenhuma delas, desfazendo aquelas que tenham sido total ou parcialmente executadas. Alm disto, o sistema deve processar as operaes sem interferncia de outras transaes e garantir que, se as operaes comeam em um estado consistente do banco de dados, elas terminam em um estado tambm consistente. Mecanismos para garantir estas propriedades foram amplamente investigados no contexto de aplicaes convencionais. Os usurios de bancos de dados geogrficos tambm executam transaes desta natureza, principalmente ao modificar os atributos convencionais de objetos. Porm, eles podem apresentar um padro de comportamento muito diferente, mais prximo do encontrado em ambientes de desenvolvimento de software, projeto de circuitos VLSI e criao de documentos hipermdia, entre outros. Nestes ambientes, uma equipe de usurios trabalha cooperativamente para produzir uma nova configurao dos objetos. Cada usurio cria uma parte de um todo em vrias etapas, possivelmente trabalhando sobre uma situao j existente, que no pode ser congelada. Alm disto, a equipe pode criar configuraes alternativas dos objetos, ou seja, modificaes que no necessariamente sero efetivadas. O conjunto de modificaes criado pela equipe de usurios configura uma transao longa e aninhada. Neste contexto, o termo transao freqentemente utilizado como sinnimo de sesso de trabalho. A transao longa pois normalmente o trabalho da equipe se desenvolve por muito tempo, possivelmente semanas. Ela cooperativa porque envolve modificaes criadas por usurios distintos, de forma coordenada. Finalmente, a transao pode conter colees completas de modificaes organizadas em subtransaes aninhadas. Informalmente, uma transao T contm uma subtransao aninhada T quando um parte das operaes de T agrupada e tratada como uma transao T de tal forma que as operaes em T possam ser desfeitas ou refeitas pelo sistema como um todo, ou tornadas condicionalmente visveis a outros usurios.
256
Por exemplo, considere um banco de dados geogrfico contendo dados sobre topografia, vegetao, reas de preservao ambiental e rede viria de uma regio. Suponha que uma equipe de dois engenheiros esteja desenvolvendo o traado de um novo oleoduto, cada um trabalhando em trechos diferentes e contguos do oleoduto. Este projeto envolve ento trabalho cooperativo, de longa durao, sobre os objetos no banco, configurado como uma nica transao longa, contendo duas subtransaes aninhadas, uma para cada membro da equipe. Este exemplo ser elaborado de forma um pouco diferente na Seo 7.6.3. 7.6.2 Mecanismos para implementao de transaes Esta seo discute alguns mecanismos genricos propostos para implementao de transaes com as caractersticas descritas na seo anterior, incluindo tratamento de verses. A descrio segue (Dias et al., 1995) (Soares et al., 1993). Esta seo opcional, podendo o leitor passar diretamente para a Seo 7.6.3. Paralelamente aos mecanismos sofisticados para manipulao de dados, descritos abaixo, o usurio poder ainda manipular diretamente tais dados, para cobrir casos simples como, por exemplo, atualizao do valor de um atributo convencional. Em geral, um ambiente para trabalho cooperativo deve permitir tanto compartilhamento de conjuntos de dados entre usurios quanto a definio de conjuntos privativos a um grupo de usurios. Para tanto, supomos que os dados esto organizados em uma hierarquia de bancos de dados e que cada dado s pertence a um destes bancos. Se B filho de B na hierarquia, dizemos que B um banco subordinado a B. (Note que a hierarquia possui um nmero arbitrrio de nveis). Cada banco est associado a um grupo de usurios com permisso para realizar um certo conjunto de operaes sobre os dados no banco ou em bancos subordinados a ele. Esta hierarquia de bancos reflete o fato de transaes conterem outras transaes aninhadas. Assim, um grupo de usurios poder criar um banco de dados para conter os dados com que ir trabalhar e, recursivamente, criar outros bancos subordinados a este, associando-os a transaes aninhadas conduzidas por subgrupos de usurios.
Gerncia de transaes
257
Ortogonalmente a estes conceitos, consideramos que um dado pode estar em um de trs estados: pronto, trabalho ou obsoleto (respectivamente, committed, uncommitted ou obsolete). Um dado d pode ainda estar associado a um conjunto de outros dados, tratados como suas verses, e organizados sob forma de uma rvore, onde d a raiz. Esta rvore mantida de tal forma que, se uma verso est pronta, todos os seus ancestrais na rvore tambm esto prontos; e, se uma verso obsoleta, todos os seus descendentes tambm so obsoletos. Os dados so manipulados atravs do elenco de operaes descritas a seguir. A operao update permite atualizar um dado em trabalho, sem alterar o seu estado. A operao commit transforma em pronto um dado em trabalho. A operao delete remove um dado d de um banco B. Se d for um dado em trabalho, ele efetivamente destrudo; se d for um dado pronto, ele tornado obsoleto. O usurio tambm pode remover um banco B, provocando a remoo de todos os dados e bancos subordinados a B, recursivamente. O sistema se encarregar de manter dados obsoletos apenas enquanto eles forem referenciados por outros dados. H trs operaes para criao de dados: create cria um dado d completamente novo em um banco B; create-version cria uma nova verso d de um dado d pronto ou em trabalho no mesmo banco de dados B que contm d; check-out cria um novo dado d em B como uma verso de um dado pronto d existente em B, onde B um banco subordinado a B. O usurio tambm poder utilizar esta operao para criar em bloco verses de um conjunto de dados. Note que o usurio no pode mover d de B para B, mas apenas usar a operao check-out para criar uma verso d de d em B. Em todos estes trs casos, d considerado um dado em trabalho aps a sua criao. A operao check-in permite mover um dado pronto d de um banco B para o banco B a que B se subordina. O usurio tambm poder utilizar esta operao para mover em bloco um conjunto de dados de um banco para outro. H duas variantes desta operao. A primeira delas, check-in de adio, de fato move d de B para B, exceto se d for uma verso de um dado d existente em B e d no tiver sido modificado, caso em que d descartado, evitando assim a criao de uma rplica de d em
258
B. A segunda, check-in por substituio, move d de B para B, se d for um novo dado, ou move d de B para B e remove o dado d existente em B (atravs da operao delete, se d for uma verso de d e d tiver sido modificado). Esta ltima operao corresponde portanto tradicional operao de atualizao. Estas operaes mantm as rvores de verses consistentes atravs de aes colaterais. Assim, a operao commit aplicada a um dado se propaga recursivamente para todos os seus ancestrais na rvore, transformando-os tambm de dados em trabalho para prontos. A operao delete aplicada a um dado se propaga recursivamente para todos os seus descendentes na rvore, destruindo-os ou tornando-os obsoletos. Este efeito pode ser provocado tambm por uma operao de check-in por substituio ao chamar implicitamente uma operao delete. Note que as rvores de verses cruzam a hierarquia de bancos de dados. Portanto, quando um usurio executa uma operao de commit sobre um dado em um banco B, ele poder afetar um dado que pertence ao banco a que B se subordina, e assim recursivamente. Assim, o usurio dever possuir permisso para executar commit tambm sobre dados nestes outros bancos. Porm, a operao delete no causa problemas. Por definio, se o usurio possui permisso para aplicar a operao de delete sobre dados de B, ele tambm possui permisso para aplicar delete a dados em bancos subordinados a B, recursivamente. A mesma observao se aplica operao de check-in por substituio. Assim, como efeito colateral de uma operao sobre um dado d, um usurio poder interferir com bancos de dados de outros usurios que contm verses de d. Para minimizar este problema, podemos lanar mo de mecanismos de controle de acesso, permitindo o bloqueio de dados em trs modos: compartilhado, exclusivo e verso-exclusivo. Quando um usurio (ou grupo de usurios) bloqueia um dado em modo compartilhado, ele indica uma potencial inteno de substitu-lo por outra verso; em modo exclusivo, ele probe outros usurios de substitu-lo por outra verso; em modo verso-exclusivo, ele probe outros usurios de criar verses do dado. Este recurso se integra s operaes descritas anteriormente. Em uma operao de check-out que cria um novo dado d em B como uma verso de um dado d em B; d bloqueado em modo compartilhado para o
Gerncia de transaes
259
usurio que executa a operao. Ao executar um check-in por substituio sobre d, se d tiver sido modificado, o bloqueio de d escalonado para o modo exclusivo e os outros usurios que possuam bloqueios compartilhados sobre d tm seus bloqueios descartados. Isto os impede de retornar verses de d, forando-os a refazer o check-out, agora sobre d (dado que substituiu d). Esta discusso simplificada, pois no explora em detalhe as referncias cruzadas entre dados, quer seja porque um dado uma componente de outro, quer seja porque h um relacionamento explcito entre ambos. Tambm no considera a criao de verses ou o bloqueio de partes de um conjunto de dados. Esta extenso particularmente importante pois geo-objetos ou geo-campos freqentemente cobrem reas geogrficas maiores do que a regio de interesse do usurio. A seo seguinte apresenta um exemplo de modificao de um banco de dados geogrfico que utiliza extenses das operaes acima descritas cobrindo este ponto. 7.6.3 Exemplo de transao sobre banco de dados geogrfico Considere um banco de dados geogrfico B contendo, para o Estado do Rio de Janeiro: um geo-campo T capturando a sua topografia; uma coleo de geo-objetos chamada de REAS-DE-PRODUO, cujos elementos descrevem as reas de proteo, descritas por uma representao por subdiviso planar P; e duas colees de geo-objetos, REDE-VIRIA e OLEODUTOS, com a descrio das estradas e oleodutos, cujas localizaes encontram-se em uma representao complexa V. Suponha agora que uma equipe tenha sido designada para elaborar uma proposta para um oleoduto do terminal da Petrobrs no Municpio de Angra dos Reis para o Porto de Sepetiba, sem cruzar reas de proteo ambiental e aproveitando ao mximo os cortes j feitos para as estradas. O trabalho da equipe configura uma transao longa e cooperativa, construda interativamente com descrito a seguir.
260
Inicialmente a equipe define uma janela R cobrindo toda a regio de trabalho. Em seguida, define o banco de dados privado B e cria, atravs da operao check-out, verses TR e VR dos objetos T e V apenas para a regio R e uma verso OL de OLEODUTOS. Suponha que a equipe tenha permisso apenas para consultar as colees REAS DE PROTEO e REDE-VIRIA e a representao P. Em seguida, a equipe define o oleoduto, inserindo um novo geoobjeto O em OL, e alterando VR para incluir a representao de O. A equipe tambm modifica o geo-campo TR para indicar os novos cortes necessrios passagem do oleoduto (mas no modifica P, por restries de projeto). Ao trmino, a equipe introduz o resultado do projeto no banco original B atravs da operao de check-in por substituio, estendida para tratar de verses que se referem apenas a uma parte da rea geogrfica coberta pelos objetos. Em paralelo, uma segunda equipe poder estar trabalhando no traado de uma nova estrada no Municpio de Angra dos Reis, com restries semelhantes s anteriores: a estrada no poder cruzar reas de proteo ambiental e dever aproveitar ao mximo os cortes j feitos para oleodutos. Novamente, a equipe define uma janela S cobrindo sua regio de trabalho e define o banco de dados privado E, criando, atravs da operao check-out, verses TS e VS dos objetos T e V apenas para a regio S e uma verso RV de REDE-VIRIA. De forma semelhante, esta equipe define a estrada, inserindo um novo geo-objeto E na coleo RV, alterando $V_S$ para incluir a representao de E, e modificando o geo-campo TS para indicar novos cortes necessrios passagem da nova estrada. Ao trmino, a equipe tentar introduzir o resultado deste segundo projeto no banco original B, atravs da operao de check-in por substituio. Duas situaes podero ocorrer. Primeiro, se as regies R e S forem disjuntas, ento o trabalho de uma equipe no afeta diretamente o da outra e a alterao do banco B ocorrer normalmente. Porm, a
261
implementao da operao de check-in por substituio dever ser suficientemente sofisticada para alterar V e T apenas para a regio S de tal forma que no destrua as modificaes efetuadas nestes campos pela equipe que criou o oleoduto. Segundo, se as regies R e S no forem disjuntas, o trabalho de uma equipe potencialmente afeta o da outra. guisa de ilustrao, faamos uma anlise mais detalhada desta situao. A primeira equipe altera V acrescentando a representao de O e a segunda acrescentando a representao de E. Portanto, se o sistema versionar as componentes de V, e no V como um todo, ser simples implementar a operao de checkin por substituio de tal forma que o trabalho de uma equipe no interfira com o da outra do ponto de vista de V: basta reconhecer que ambas as equipes simplesmente criaram novas componentes de V. Argumento semelhante se aplica a T, exceto que, neste caso, como T um geo-campo, ser necessrio analisar a representao utilizada para T. Por exemplo, se a representao for por isolinhas, ser necessrio versionar as isolinhas em si; assim uma equipe no interferir com a outra se alterarem isolinhas distintas. Naturalmente, toda esta discusso sobre a operao de check-in por substituio afetada pelos mecanismos de controle de acesso, que tambm devero ser revistos para acomodar os refinamentos baseados no uso de regies ou de componentes. 7.7 Leituras suplementares Resumos dos principais aspectos de implementao de sistema de gerncia de bancos de dados geogrficos podem ser encontrados em referncias gerais (Guting, 1994) (Medeiros e Pires, 1994) (Shekhar et al., 1999) (Rigaux et al., 2001) (Shekhar, 2002). Descries de extenses dos principais sistema de gerncia de bancos de dados para tratar dados geogrficos encontram-se em (Ravada e Sharma, 1999) (David, 2001). Polticas especficas para otimizao de consultas espaciais podem ser encontradas em referncias seminais sobre o assunto (Aref e Samet, 1991) (Kriegel et al., 1993) (Brinkhoff et al., 1993) (Brinkhoff et al., 1994). Em particular, a idia bsica de processar uma consulta espacial em vrios passos, atravs de aproximaes da geometria dos objetos, foi introduzida
262
em (Kriegel et al., 1993). Propostas de benchmarks para consultas espaciais podem ser encontrados em (Stonebraker et al. 1993) (Cifferi, 1995). Uma biblioteca de algoritmos para processamento de consultas espaciais apresentada em (Bercken et al. 2001). A questo do processamento de consultas para objetos representados em alta resoluo discutida em (Kriegel et al., 2003). H bem poucas referncias sobre gerncia de transaes para o caso especfico de sistemas de gerncia de bancos de dados geogrficos. Porm, o padro de transaes para estas aplicaes semelhante s chamadas transaes longas e aninhadas (Lynch, 1983) (Weikum, 1991), tpicas de ambientes de desenvolvimento de software, ambientes de projeto de VLSI e hipertexto, entre outros. Um modelo semntico, genrico para transaes, que se aplica tambm a bancos de dados geogrficos, foi proposto em (Brayner et al., 1999). Um modelo de transaes recente e especfico para bancos de dados geogrficos encontra-se (Kadri-Dahmani e Osmani, 2003). A discusso sobre processamento de consultas espaciais apresentada neste captulo aborda apenas aplicaes convencionais envolvendo dados geogrficos. H, no entanto, uma vasta gama de aplicaes de outra natureza, que necessitam revisar a semntica das consultas e, conseqentemente, as tcnicas de processamento de consultas. Podemos apontar aplicaes que necessitam: tratar objetos espaotemporais (Kim et al., 2002); trabalhar com dados geogrficos representando redes, onde a noo de espao Euclidiano no adequada (Papadias et al., 2003); considerar consultas dependentes de localizao em ambientes para computao mvel (Ayse et al., 2001) (Zhang et al., 2003) (Manical et al., 2004); e processar objetos mveis (Porkaew et al., 2001 ) (Chon et al., 2002).
Referncias
263
Referncias
ABOULNAGA, A.; NAUGHTON, J. F. Accurate estimation of the cost of spatial selections. In: 16th International Conference on Data Engineering. San Diego, CA, USA, 2000. p. 123-134. AREF, W.; SAMET, H. Optimization for Spatial Query Processing. In: 17th International Conference on Very Large Data Bases. Morgan Kaufmann Publishers Inc., Barcelona, Spain, 1991. p. 81-90. AYSE, Y.; DUNHAM, H. M.; KUMAR, V. M. Location dependent query processing. In: 2nd ACM international workshop on Data engineering for wireless and mobile access. Santa Barbara, CA, USA, 2001. p. 47-53. BERCKEN, J.; BLOHSFELD, B.; DITTRICH, J.-P.; KRAMER, J.; SCHAFER, T.; SCHNEIDER, M.; SEEGER, B. XXL - A Library Approach to Supporting Efficient Implementations of Advanced Database Queries. In: 27th International Conference on Very Large Data Bases. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2001. p. 39-48. BRAYNER, A.; HARDER, T.; RITTER, N. Semantic Serializability: A Correctness Criterion for Processing Transactions. Data & Knowledge Engineering, v. 31, n.1, p. 1-24, 1999. BRINKHOFF, T.; HORN, H.; KRIEGEL, H.-P.; SCHNEIDER, H. A Storage and Access Architecture for Efficient Query Processing in Spatial Database Systems. In: Third International Symposium on Advances in Spatial Databases. Lecture Notes In Computer Science. Springer-Verlag London, UK, 1993a. p. 357-376. BRINKHOFF, T.; KRIEGEL, H.-P.; SCHNEIDER, H.; SEEGER, B. GENESYS: A System for Efficient Spatial Query Processing. In: 1994 ACM SIGMOD International Conference on Management of Data. Minneapolis, MI, USA, 1994a. p. 519. BRINKHOFF, T.; KRIEGEL, H.-P.; SCHNEIDER, R.; SEEGER, B. Multistep Processing of Spatial Joins. In: 1994 ACM SIGMOD International Conference on Management of Data. Minneapolis, USA, 1994b. p. 197-208. BRINKHOFF, T.; KRIEGEL, H.-P.; SEEGER, B. Efficient Processing of Spatial Joins. In: 1993 ACM SIGMOD International Conference on Management of Data. Washington, DC, USA, 1993b. p. 237-246.
264
CHON, D. H.; AGRAWAL, D.; EL ABBADI, A. Query Processing for Moving Objects with Space-Time Grid Storage Model. In: Third International Conference on Mobile Computing. 2002. p. 121. CIFFERI, R. Um Benchmark Voltado a Anlise de Desempenho de Sistemas de Informaes Geogrficas. Campinas, SP, Brasil: UNICAMP, 1995. Departamento de Cincia da Computao, 1995. DAR, S.; FRANKLIN, M. J.; JONSSON, B. T.; SRIVATAVA, D.; TAN, M. Semantic Data Caching and Replacement. In: 22th International Conference on Very Large Data Bases. Morgan Kaufmann Publishers Inc., 1996. p. 330-341. DAVID, W. A. DB2 Spatial Extender - Spatial data within the RDBMS. In: 27th International Conference on Very Large Data Bases. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2001. p. 687-690. DIAS, E.; GRANADO, S.; MAGALHES, G. Uso de Verses na Garantia de Consistncia em Ambientes Mistos de Projetos e Operao. In: Simpsio Brasileiro de Banco de Dados. 1995. p. 321-334. DOSHI, P. R.; RUNDENSTEINER, E. A.; WARD, M. O. Prefetching for Visual Data Exploration. In: Eighth International Conference on Database Systems for Advanced Applications. 2003. p. 195. GUNTHER, O.; BECKER, L.; HINRICHS, K.; FINKE, U. Efficient computation of spatial joins. In: 9th International Conference on Data Engineering. Vienna, Austria, 1993. p. 50-59. GUTING, R. An Introduction to Spatial Database Systems. VLDB Journal, v. 3, n.4, p. 357-399, 1994. KADRI-DAHMANI, H.; OSMANI, A. Updating Data in GIS: How to Maintain Database Consistency? In: Enterprise Information Systems IV. Kluwer Academic Publishers, Ciudad Real, Spain, 2003. p. 163-169. KIM, H. D.; RYU, H. K.; PARK, H. C. Design and implementation of spatiotemporal database query processing system. Journal of Systems and Software, v. 60, n.1, p. 37-49, 2002. KRIEGEL, H.-P.; BRINKHOFF, T.; SCHNEIDER, R. An Efficient Map Overlay Algorithm Based on Spatial Access Methods and Computational Geometry. In: Geographic Database Management Systems. SpringerVerlag, Capri, 1992. p. 194-211. KRIEGEL, H.-P.; BRINKHOFF, T.; SCHNEIDER, R. Efficient Spatial Query Processing in Geographic Database Systems. Data Engineering Bulletin, v. 16, n.3, p. 10-15, 1993.
Referncias
265
KRIEGEL, H.-P.; PFEIFLE, M.; POTKE, M.; SEIDL, T. Spatial Query Processing for High Resolutions. In: 8th International Conference on Database Systems for Advanced Applications (DASFAA03). Kyoto, Japan, 2003. p. 17. KRIEGEL, H.-P.; SCHIWIETZ, M.; SCHNEIDER, R.; SEEGER, B. Performance comparison of point and spatial access methods. In: First Symposium on Design and Implementation of Large Spatial Databases.Lecture Notes in Computer Science. Springer-Verlag, Santa Barbara, CA, USA, 1990. p. 89-114. LO, M.-L.; RAVISHANKAR, C. V. Spatial hash-joins. In: 1996 ACM SIGMOD International Conference on Management of Data. Montreal, Quebec, Canada, 1996. p. 247-258. LYNCH, N. A. A New Correctness Criterion for Database Concurrency Control. ACM Transactions on Database Systems, v. 8, n.4, p. 484-502, 1983. MANICAL, H.; CAMARGO, S. M.; CIFERRI, A. D. C.; CIFERRI, R. R. Processamento de Consultas Espaciais Baseado em Cache Semntico Dependente de Localizao. In: VI Simpsio Brasileiro de Geoinformtica GeoInfo 2004. Campos de Jordo, SP, 2004. p. MEDEIROS, C. B.; PIRES, F. Databases for GIS. ACM SIGMOD Record, v. 23, n.1, p. 107-115, 1994. PAPADIAS, D.; ZHANG, J.; MAMOULIS, N.; Y., T. Query Processing in Spatial Network Databases. In: 29th Very Large Data Base Conference. Berlin, Germany, 2003. p. PATEL, J. M.; DEWITT, D. J. Partition based spatial-merge join. In: 1996 ACM SIGMOD International Conference on Management of Data. Montreal, Quebec, Canada, 1996. p. 259-270. PORKAEW, K.; LAZARIDIS, I.; MEHROTRA, S. Querying Mobile Objects in Spatio-Temporal Databases. In: 7th International Symposium on Advances in Spatial and Temporal Databases.Lecture Notes In Computer Science. Springer-Verlag, Redondo Beach, CA, USA, 2001. p. 59-78. PREPARATA, F. P.; SHAMOS, M. I., eds., 1985, Computational Geometry: An Introduction: New York, NY, Springer-Verlag. RAVADA, S.; SHARMA, J. Oracle8i Spatial: Experiences with Extensible Databases. In: 6th International Symposium on Advances in Spatial Databases. Springer-Verlag, London, UK, 1999. p. 355-359.
266
REN, Q.; DUNHAM, M. H.; KUMAR, V. Semantic Caching and Query Processing. IEEE Transactions on Knowledge and Data Engineering, v. 15, n.1, p. 192-210, 2003. RIGAUX, P.; SCHOLL, M.; VOISARD, A. Spatial Databases with Application to GIS. San Francisco: Morgan Kaufmann Publishers Inc, 2001. SHEKHAR, S.; CHAWLA, S.; RAVADA, S.; FETTERER, A.; LIU, X.; LIU, C. T. Spatial Databases: Accomplishments and Research Needs. IEEE Transactions on Knowledge and Data Engineering, v. 11, n.1, p. 45-55, 1999. SOARES, L.; CASANOVA, M.; RODRIGUES, N. Um Modelo Conceitual Hipermdia com Ns de Composio e Controle de Verses. In: VII Simpsio Brasileiro de Engenharia de Software. 1993. p. 365-381. STONEBRAKER, M.; FREW, J.; GARDELS, K.; MEREDITH, J. The Sequoia 2000 Benchmark. In: 1993 ACM SIGMOD International Conference on Management of Data. Washington, D.C., USA, 1993. p. 211. WEIKUM, G. Principles and Realization Strategies of Multilevel Transaction Management. ACM Transactions on Database Systems, v. 16, n.1, p. 132180, 1991. ZHANG, J.; ZHU, M.; PAPADIAS, D.; TAO, Y.; LEE, D. L. Location-based spatial queries. In: 2003 ACM SIGMOD International Conference on Management of Data. San Diego, CA, USA, 2003. p. 443-454.
8 SGBD com extenses espaciais

Gilberto Ribeiro de Queiroz Karine Reis Ferreira
8.1 Introduo Este captulo apresenta duas extenses espaciais de SGBD convencionais, uma da comunidade de software aberto (PostGIS) e outra comercial (Oracle Spatial). O PostGIS (Ramsey, 2002) estende o PostgreSQL, seguindo as especificaes da SFSSQL. O PostgreSQL um sistema de gerncia de banco de dados objeto-relacional, gratuito e de cdigo fonte aberto (Stonebraker et al, 1990). Foi desenvolvido a partir do projeto Postgres, iniciado em 1986, na Universidade da Califrnia em Berkeley. O Spatial (Ravada e Sharma, 1999) (Murray, 2003) estende o modelo objeto-relacional do sistema de gerncia de banco de dados Oracle. Esta extenso baseia-se nas especificaes do OpenGIS. 8.2 Cenrios Esta seo apresenta alguns cenrios que sero empregados ao longo do captulo para ilustrar os principais recursos das extenses espaciais consideradas. Os exemplos que iremos apresentar, representam as informaes de distritos, bairros e rede de drenagem da cidade de So Paulo; os municpios que formam a grande So Paulo (So Caetano do Sul, Suzano, Guarulhos entre outras). A Figura 8.1 mostra a parte geomtrica dos distritos de So Paulo. Para cada distrito associaremos um polgono e os atributos cdigo do distrito (COD), sigla de abreviao (SIGLA) e o nome do distrito (DENOMINACAO). Aos pontos que representam bairros da cidade de So Paulo (Figura 8.2) iremos associar
268
os atributos nome do bairro (BAIRRO) e o nome do distrito (DISTR). s linhas da Figura 8.3 (mapa de drenagem) associaremos um nico atributo, a classe de drenagem (CLASSE). E, aos polgonos dos municpios da grande So Paulo, os atributos cdigo do municpio (CODMUNIC), nome do municpio (NOMEMUNICP) e populao (POPULACAO).
Figura 8.1 Mapa de Distritos da Cidade de So Paulo.
Figura 8.2 Mapa de Bairros da Cidade de So Paulo.
Cenrios
269
Figura 8.3 Mapa de drenagem.
Figura 8.4 Mapa dos Municpios da Grande So Paulo.
A partir dessas informaes, iremos construir alguns cenrios envolvendo consultas espaciais que sero utilizados durante a explicao dos recursos de cada uma das extenses. Cenrio 1: Recuperar o nome de todos os municpios da grande So Paulo que so vizinhos ao municpio de So Paulo. A Figura 8.5 ilustra esse cenrio, com o municpio de So Paulo destacado em preto e os municpios vizinhos destacados em cinza claro.
Figura 8.5 Municpios vizinhos cidade de So Paulo.
270
Cenrio 2: Recuperar o nome de todos os municpios da grande So Paulo que so vizinhos ao distrito Anhanguera da cidade de So Paulo. A Figura 8.6 ilustra este cenrio, com o distrito Anhanguera de So Paulo destacado em preto e os municpios vizinhos a este distrito, destacados em cinza claro.
Figura 8.6 Municpios vizinhos ao distrito Anhanguera.
Cenrio 3: Recuperar o nmero de bairros contidos no distrito Graja. A Figura 8.7 ilustra o cenrio, com o distrito Graja destacado em cinza escuro e os municpios contidos neste distrito de cinza claro.
Figura 8.7 Bairros contidos no distrito de Graja.
Figura 8.8 Buffer de 3Km ao redor de um rio e distritos nesta regio de influncia.
PostGIS para PostgreSQL
271
Cenrio 4: Recuperar todos os distritos que esto num raio de 3km de um determinado rio. A Figura 8.8 ilustra o resultado desta consulta, com o rio selecionado destacado em branco e os distritos em cinza escuro contidos no raio de 3 Km do rio. A linha em cinza escuro ao redor do rio selecionado representa um buffer gerado com o qual os distritos foram testados (relacionamento intercepta). Cenrio 5: Recuperar todos os bairros que estejam a menos de 3 Km do bairro Boacava. 8.3 PostGIS para PostgreSQL
8.3.1 Caractersticas principais do PostgreSQL O PostgreSQL um sistema gerenciador de banco de dados objetorelacional, gratuito e de cdigo fonte aberto, desenvolvido a partir do projeto Postgres, iniciado em 1986, na Universidade da Califrnia em Berkeley, sob a liderana do professor Michael Stonebraker. Em 1995, quando o suporte a SQL foi incorporado, o cdigo fonte foi disponibilizado na Web (http://www.postgresql.org). Desde ento, um grupo de desenvolvedores vem mantendo e aperfeioando o cdigo fonte sob o nome de PostgreSQL. Em sua verso de distribuio oficial, ele apresenta tipos de dados geomtricos (Figura 8.9), operadores espaciais simples e indexao espacial atravs de uma R-Tree nativa ou atravs de R-Tree implementada no topo do mecanismo de indexao GiST (Hellerstein et al, 1995).
POINT LSEG PATH BOX POLYGON CIRCLE
Figura 8.9 - Tipos Geomtricos do PostgreSQL.
272
A implementao da R-Tree nativa possui uma severa limitao em seu uso, uma coluna do tipo polgono no pode exceder 8Kbytes. Na prtica, muito comum um SIG manipular dados representados, por exemplo, por polgonos maiores do 8Kbytes cada, o que torna o uso desse ndice invivel. Uma alternativa o uso da segunda R-Tree. O mtodo de indexao chamado GiST foi introduzido por Hellerstein et al (1995) e implementado no PostgreSQL. Atualmente, ele mantido por Signaev e Bartunov (http://www.sai.msu.su/~megera/postgres/gist) e no possui restries de tamanho do dado a ser indexado. GiST uma abreviao de Generalized Search Trees, consistindo em um ndice (rvore balanceada) que pode fornecer tanto as funcionalidades de uma B-Tree quanto de uma R-Tree e suas variantes. A principal vantagem desse ndice a possibilidade de definio do seu comportamento. Quanto aos poucos operadores espaciais existentes, estes realizam a computao apenas sobre o retngulo envolvente das geometrias e no diretamente nelas. J os tipos de dados simples, como polgonos, no permitem a representao de buracos, no existindo tambm geometrias que permitam representar objetos mais complexos como os formados por conjuntos de polgonos. Portanto, a integrao de um SIG atravs desses tipos geomtricos requer muito esforo implementao de novas operaes espaciais como unio, interseo, testes topolgicos sobre a geometria exata, definio de um modelo de suporte a polgonos com buracos, entre outras. Mas, como dito anteriormente, um dos pontos fortes desse SGBD seu potencial de extensibilidade, o que possibilitou o desenvolvimento de uma extenso geogrfica mais completa, chamada PostGIS. Antes de entrar em maiores detalhes dessa extenso, apresentaremos um pouco do mecanismo de extensibilidade para que o leitor possa entender melhor o ncleo da extenso PostGIS. 8.3.2 Extensibilidade do PostgreSQL O mecanismo de extensibilidade do PostgreSQL permite incorporar capacidades adicionais ao sistema de forma a torn-lo mais flexvel para o
273
gerenciamento de dados para cada classe de aplicao. No caso dos SIG, isso significa a possibilidade do desenvolvimento de uma extenso geogrfica capaz de armazenar, recuperar e analisar dados espaciais. A seguir sero apresentados alguns passos envolvidos na criao de uma extenso do PostgreSQL. Os exemplos foram adaptados do tipo de dados POLYGON existente na distribuio oficial. 8.3.2.1 Tipos de dados definidos pelo usurio A extenso de tipos de dados no PostgreSQL pode ser feita em linguagem C (Kernighan e Ritchie, 1990) atravs da definio de uma estrutura de dados, que responsvel pela representao do tipo em memria. O trecho de cdigo abaixo ilustra a definio de um tipo chamado TeLinearRing, que representa uma linha fechada composta por um conjunto de coordenadas (do tipo TeCoord2D). Os tipos definidos pelo usurio podem ser de tamanho fixo ou varivel, como no caso do exemplo abaixo (varivel):
typedef struct { int32 size; int32 ncoords_; TeCoord2D coords_[1]; } TeLinearRing; //struct length //number of coords //variable length array
Alm da estrutura de dados, necessrio definir outras duas rotinas1 que fazem a converso do tipo de acordo com a sua representao em memria para ASCII e vice-versa. Estas rotinas so conhecidas como funes de entrada e sada, e elas associam uma representao textual externa para o dado. Essas funes so utilizadas internamente para permitir que o tipo seja usado diretamente em comandos SQL. Por exemplo, para o tipo TeLinearRing, poderamos optar pelo seguinte formato de representao: [(X1, Y1), (X2, Y2), ..., (Xn, Yn)]. O trecho de cdigo abaixo ilustra a implementao de uma rotina de entrada para o tipo TeLinearRing2:
00 01 PG_FUNCTION_INFO_V1(TeLinearRing_in); Datum TeLinearRing_in(PG_FUNCTION_ARGS)
1 2
A partir da verso 7.4, pode-se definir das funes de I/O no formato binrio. As funes number_of_coords e decode sero omitidas por questes de espao.
274
02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

{ char* str = PG_GETARG_CSTRING(0); TeLinearRing* ring; int ncoords; int size; char* s; if((ncoords = number_of_coords(str, ))) <= 0) elog(ERROR, "Bad TeLinearRing external representation '%s'", str); size = offsetof(TeLinearRing, coords_[0]) + sizeof(ring->coords_[0]) * ncoords; ring = (TeLinearRing*)palloc(size); MemSet((char *) ring, 0, size); ring->size = size; ring->ncoords_ = ncoords; if((!decode(ncoords, str, &s, &(ring->coords_[0]), [, ])) || (*s != '\0')) elog(ERROR, "Bad TeLinearRing external representation '%s'", str); if(!is_TeLinearRing(ring)) { pfree(ring); ring = NULL; elog(ERROR, "In a TeLinearRing the first point must be the same as the last point '%s'", str); } PG_RETURN_TeLine2D_P(ring); }
Os passos envolvidos na definio desta rotina so: Na linha 02, podemos observar que a rotina recebe um polgono (TeLinearRing) na forma textual (str). Na linha 06, a funo number_of_coords determina quantas coordenadas formam a fronteira do polgono. Na linha 11, alocada memria suficiente para um polgono com o nmero de coordenadas determinado na linha 06. Finalmente, na linha 14, a string decodificada e as coordenadas so armazenadas no vetor de coordenadas da fronteira do polgono.
275
A funo de sada mais simples, recebe o dado na representao interna, devendo convert-lo para a representao externa. O trecho de cdigo abaixo ilustra a funo de sada para o tipo TeLinearRing:
PG_FUNCTION_INFO_V1(TeLinearRing_out); Datum TeLinearRing_out(PG_FUNCTION_ARGS) {TeLinearRing *ring = (TeLinearRing*) PG_GETARG_TeLinearRing_P(0); char* str; str = palloc(ring->ncoords_ * (P_MAXLEN + 3) + 2); if(!encode(ring->ncoords_, ring->coords_, str, [, ], "Unable to format TeLinearRing")) elog(ERROR, "Unable to format TeLinearRing"); PG_RETURN_CSTRING(str); }
Depois de criado o tipo, uma biblioteca compartilhada deve ser gerada para ser integrada dinamicamente ao servidor de banco de dados. necessrio registrar o tipo atravs do comando SQL: CREATE TYPE, informando as rotinas de entrada e sada:
CREATE FUNCTION telinearring_in(opaque) RETURNS telinearring AS '/opt/tepgdatatypes.so' LANGUAGE 'c'; CREATE FUNCTION telinearring_out(opaque) RETURNS opaque AS '/opt/tepgdatatypes.so' LANGUAGE 'c'; CREATE TYPE telinearring ( alignment = double, internallength = VARIABLE, input = telinearring_in, output = telinearring_out, storage = main );
Agora podemos utilizar o tipo TeLinearRing dentro de comandos SQL, como: Criar uma tabela com uma coluna do tipo TeLinearRing:
CREATE TABLE tab_poligonos_simples (id INTEGER, geom TeLinearRing);
276
Inserir um quadrado (4 x 4):

INSERT INTO tab_poligonos_simples VALUES(1, [(0, 0), (4, 0), (4, 4), (0, 4), (0, 0)]);
Recuperar todos os polgonos:

SELECT * FROM tab_poligonos_simples; Resultado: id | geom -----------------------------------------1 | [(0, 0), (4, 0), (4, 4), (0, 4), (0, 0)]
8.3.2.2 Funes e operadores definidos pelo usurio Alm da flexibilidade do sistema de tipos, o PostgreSQL permite a criao de mtodos que operem sobre as instncias dos tipos definidos. Essas funes podem ser integradas ao servidor informando o nome da funo, a lista de argumentos e o tipo de retorno. Essas informaes so registradas no catlogo do sistema. O trecho de cdigo abaixo ilustra a definio de uma funo para calcular a rea de um polgono simples representado por um TeLinearRing.
PG_FUNCTION_INFO_V1(TeLinearRingArea); Datum TeLinearRingArea(PG_FUNCTION_ARGS) {TeLinearRing *r = (TeLinearRing *) PG_DETOAST_DATUM(PG_GETARG_DATUM(0)); double area = 0.0; int npoints = 0; int loop; npoints = r->ncoords_; for(loop = 0; loop < (npoints - 1); ++loop) { area += ((r->coords_[loop].x_ * r->coords_[loop + 1].y_) (r->coords_[loop + 1].x_ * r->coords_[loop].y_)); } area *= 0.5; PG_RETURN_FLOAT8(area); }
Assim como os tipos, as funes tambm devem ser colocadas em uma biblioteca compartilhada para poderem ser integradas ao servidor de banco de dados. necessrio registrar a funo atravs do comando SQL: CREATE FUNCTION, como mostrado abaixo:

CREATE FUNCTION area(telinearring) RETURNS float4 AS '/opt/tepgfunctions.so', 'telinearringarea' LANGUAGE 'c' WITH (isstrict);
277
Outra funcionalidade importante oferecida pelo PostgreSQL que os nomes das funes podem ser sobrecarregadas desde que os parmetros sejam de tipos diferentes. Depois de criada uma funo, possvel definir um operador para ela atravs do comando SQL: CREATE OPERATOR. A importncia da definio do operador est ligada ao otimizador de consultas que pode usar as informaes contidas na definio do operador para decidir a melhor estratgia para a consulta (ou simplificao desta). Outra funcionalidade oferecida pelo PostgreSQL a definio de funes agregadas, que podem ser construdas de forma anloga s funes sobre tipos, porm so registradas com o comando SQL: CREATE AGGREGATE. 8.3.2.3 Extenso do mecanismo de indexao O PostgreSQL possui quatro mecanismos de indexao (B-Tree, RTree, GiST e HASH). Esses ndices podem ser usados para os tipos de dados e funes definidos pelo usurio, bastando para isso registrar no catlogo do sistema as informaes das operaes necessrias a cada ndice. Por exemplo, para um tipo que deseje ser indexado pela B-Tree, necessrio indicar ao sistema as operaes de comparao <, <=, =, >= e > para que o ndice saiba como realizar buscas. O exemplo abaixo ilustra a implementao do operador < para o tipo TeCoord2D (coordenada com os campos x_ e y_), sendo que os demais operadores diferem apenas forma da chamada:
static int tecoord2d_cmp_internal(TeCoord2D* a, TeCoord2D* b) { if(a->x_ < b->x_) return -1; if(a->x_ > b->x_) return 1; if(a->y_ < b->y_) return -1; if(a->y_ > b->y_) return 1; return 0;
278
}
PG_FUNCTION_INFO_V1(tecoord2d_lt); Datum tecoord2d_lt(PG_FUNCTION_ARGS) { TeCoord2D *a = (TeCoord2D*) PG_GETARG_POINTER(0); TeCoord2D *b = (TeCoord2D*) PG_GETARG_POINTER(1); PG_RETURN_BOOL(tecoord2d_cmp_internal(a, b) < 0); } Datum tecoord2d_cmp(PG_FUNCTION_ARGS) { TeCoord2D *a = (TeCoord2D*) PG_GETARG_POINTER(0); TeCoord2D *b = (TeCoord2D*) PG_GETARG_POINTER(1); PG_RETURN_INT32(tecoord2d_cmp_internal(a, b)); }
Agora, podemos registrar a funo e definir o operador atravs da seguinte seqncia de comandos:
CREATE FUNCTION tecoord2d_lt(TeCoord2D, bool AS 'filename', 'tecoord2d_lt' LANGUAGE C IMMUTABLE STRICT; TeCoord2D) RETURNS
CREATE FUNCTION tecoord2d_cmp(TeCoord2D, TeCoord2D) RETURNS integer AS 'filename', 'tecoord2d_cmp' LANGUAGE C IMMUTABLE STRICT; CREATE OPERATOR < ( leftarg = TeCoord2D, rightarg = TeCoord2D, procedure = tecoord2d_lt, commutator = > , negator = >= , restrict = scalarltsel, join = scalarltjoinsel );
E, por ltimo, criamos a classe de operao requerida pelo ndice Btree:

CREATE OPERATOR CLASS tecoord2d_ops DEFAULT FOR TYPE TeCoord2D USING btree AS OPERATOR 1 < , OPERATOR 2 <= , OPERATOR 3 = , OPERATOR 4 >= , OPERATOR 5 > , FUNCTION 1 tecoord2d_cmp(TeCoord2D, TeCoord2D);
279
8.3.3 A extenso espacial PostGIS do PostgreSQL A comunidade de software livre vm desenvolvendo a extenso espacial PostGIS, construda sobre o PostgreSQL. Atualmente, a empresa Refractions Research Inc (http://postgis.refractions.net) mantm a equipe de desenvolvimento dessa extenso, que segue as especificaes da SFSSQL. 8.3.3.1 Tipos de dados espaciais A Figura 8.10 ilustra os tipos espaciais suportados pelo PostGIS e embutidos na SQL do PostgreSQL.
GEOMETRY
POINT LINESTRING POLYGON
GEOMETRYCOLLECTION MULTIPOINT MULTILINESTRING MULTIPOLYGON
Figura 8.10 - Tipos de dados espaciais do PostGIS.
Esses tipos possuem a seguinte representao textual:

Point: (0 0 0) LineString: (0 0, 1 1, 2 2) Polygon: ((0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0), ( 1 0 0, ...), ...) MultiPoint: (0 0 0, 4 4 0) MultiLineString: ((0 0 0, 1 1 0, 2 2 0), (4 4 0, 5 5 0, 6 6 0)) MultiPolygon: (((0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0), (...), ...), ...)
280
GeometryCollection: (POINT(2 2 0), LINESTRING((4 4 0, 9 9 0))
Como exemplo, mostraremos os comandos em SQL para gerar tabelas para armazenar os atributos e as geometrias3: Dos distritos de So Paulo, mostrados na Figura 8.1.
CREATE TABLE distritossp ( cod SERIAL, sigla VARCHAR(10), denominacao VARCHAR(50), PRIMARY KEY (cod) ); SELECT AddGeometryColumn('terralibdb', 'distritossp', 'spatial_data', -1, 'POLYGON', 2);
Dos bairros de So Paulo, mostrados na Figura 8.2.

CREATE TABLE bairrossp ( cod SERIAL, bairro VARCHAR(40), distr VARCHAR(40), PRIMARY KEY (cod) ); SELECT AddGeometryColumn('terralibdb', 'bairrossp', 'spatial_data', -1, 2);
'POINT',
Do mapa de drenagem, mostrado na Figura 8.3:

CREATE TABLE drenagemsp ( cod SERIAL, classe VARCHAR(255) NULL, PRIMARY KEY (cod) ); SELECT AddGeometryColumn('terralibdb', 'drenagemsp', 'spatial_data', -1, 'LINESTRING', 2);
Do mapa de municpios da grande So Paulo (Figura 8.4)

CREATE TABLE grande_sp ( cod nomemunicp populacao PRIMARY KEY SERIAL, VARCHAR(255) NULL, INTEGER, (cod)
Aqui consideramos a existncia de um banco de dados chamado terralibdb

); SELECT AddGeometryColumn('terralibdb', 'spatial_data', -1, 'POLYGON', 2);
281
'grande_sp',
Observe que a criao de uma tabela com tipo espacial construda em duas etapas. Na primeira, definimos os atributos bsicos (alfanumricos) e na segunda, usamos a funo AddGeometryColumn para adicionar a coluna com o tipo espacial. Essa funo implementada no PostGIS e especificada no OpenGIS, realiza todo o trabalho de preenchimento da tabela de metadado geometry_columns. Os parmetros dessa funo so: nome do banco de dados; nome da tabela que ir conter a coluna espacial; nome da coluna espacial; sistema de coordenadas em que se encontram as geometrias da tabela; tipo da coluna espacial, que serve para criar uma restrio que verifica o tipo do objeto sendo inserido na tabela; dimenso em que se encontram as coordenadas dos dados. As tabelas de metadado do PostGIS seguem as especificaes da SFSSQL e so representadas pelas seguintes tabelas:
Tabela 8.1 Tabela de metadado do sistema de coordenadas
spatial_ref_sys
Attribute
srid auth_name auth_srid srtext proj4text
Type
INTEGER VARCHAR(256) INTEGER VARCHAR(2048) VARCHAR(2048)
Modifier
PK
282
Tabela 8.2 Tabela de metadado das tabelas com colunas espaciais
geometry_columns
Attribute
f_table_catalog f_table_schema f_table_name f_geometry_column coord_dimension srid type
Type
VARCHAR(256) VARCHAR(256) VARCHAR(256) VARCHAR(256) INTEGER INTEGER VARCHAR(30)
Modifier
PK PK PK PK
FK
Aps criar as tabelas de dados, podemos inserir as informaes usando o comando SQL INSERT. Para isso, podemos usar a representao textual das geometrias em conjunto com a funo GeometryFromText que recebe a representao textual e mais o sistema de coordenadas em que se encontra a geometria:
INSERT INTO bairrossp (bairro, spatial_data) VALUES('JARDIM DOS EUCALIPTOS', GeometryFromText('POINT(321588.628426 7351166.969244)', -1)); INSERT INTO drenagemsp (classe, spatial_data)VALUES('RIOS', GeometryFromText('LINESTRING(344467.895137 7401824.476217, 344481.584686 7401824.518728, 344492.194756 7401825.716359, ), -1)); INSERT INTO distritossp (denominacao, sigla, spatial_data) VALUES('MARSILAC', MAR, GeometryFromText('POLYGON((335589.530575 7356020.721956, 335773.784959 7355873.470174, ))', -1));
Podemos tambm recuperar as informaes em cada tabela. Por exemplo, o comando abaixo seleciona a linha do bairro Vila Mariana:
283
SELECT bairro, AsText(spatial_data) geom FROM bairrossp WHERE bairro = VILA MARIANA; Resultado: bairro | geom --------------+-----------------------------------VILA MARIANA | POINT(334667.138663 7388890.076491) (1 row) |
Aqui, empregamos a funo AsText para obter a representao textual, pois a partir das verses mais recentes o PostGIS utiliza o formato binrio do OpenGIS (WKB) como o padro nas consultas. 8.3.3.2 Indexao espacial As colunas com tipos espaciais podem ser indexadas atravs de uma R-Tree construda no topo do GiST. A sintaxe bsica para criao de um ndice a seguinte:
CREATE INDEX sp_idx_name ON nome_tabela USING GIST (coluna_geometrica GIST_GEOMETRY_OPS);
Para as tabelas do nosso exemplo, poderamos construir os seguintes ndices espaciais:

CREATE CREATE CREATE CREATE INDEX INDEX INDEX INDEX sp_idx_bairros sp_idx_bairros sp_idx_bairros sp_idx_bairros ON ON ON ON bairrossp distritossp drenagemsp grande_sp USING USING USING USING GIST GIST GIST GIST (SPATIAL_DATA GIST_GEOMETRY_OPS) (SPATIAL_DATA GIST_GEOMETRY_OPS) (SPATIAL_DATA GIST_GEOMETRY_OPS) (SPATIAL_DATA GIST_GEOMETRY_OPS)
Os ndices espaciais so usados em consultas que envolvam predicados espaciais, como no caso de consultas por janela, onde um retngulo envolvente informado e as geometrias que interagem com ele devem ser recuperadas rapidamente. O operador && pode ser usado para explorar o ndice espacial. Por exemplo, para consultarmos os municpios da grande So Paulo que interagem com o retngulo envolvente de coordenadas: 438164.882699,
284
7435582.150681 e 275421.967006, 7337341.000355, podemos construir a seguinte consulta:

SELECT * FROM grande_sp WHERE 'BOX3D(438164.882699 7435582.150681, 275421.967006 7337341.000355)'::box3d && spatial_data);
Com o uso do operador &&, apenas alguns registros precisaro ser pesquisados para responder pergunta acima. 8.3.3.3 Consultas espaciais Outro grande destaque desta extenso o grande nmero de operadores espaciais disponveis, entre alguns deles podemos citar: Operadores topolgicos conforme a Matriz de 9-Intersees DE:
equals(geometry, geometry) disjoint(geometry, geometry) intersects(geometry, geometry) touches(geometry, geometry) crosses(geometry, geometry) within(geometry, geometry) overlaps(geometry, geometry) contains(geometry, geometry) relate(geometry, geometry):
retorna a matriz de interseco.
Operador de construo de mapas de distncia:

buffer(geometry, double, [integer])
Operador para construo do Fecho Convexo:

convexhull(geometry)
Operadores de conjunto:
intersection(geometry, geometry) geomUnion(geometry, geometry) symdifference(geometry, geometry)

difference(geometry, geometry)
285
Operadores Mtricos:
distance(geometry,geometry) area(geometry)
Centride de geometrias:
Centroid(geometry)
Validao (verifica se a geometria possui auto-intersees):

isSimple(geometry)
O suporte aos operadores espaciais fornecido atravs da integrao do PostGIS com a biblioteca GEOS (Geometry Engine Open Source) (Refractions, 2003). Essa biblioteca uma traduo da API Java JTS (Java Topology Suite) (Vivid Solutions, 2003) para a linguagem C++. A JTS uma implementao de operadores espaciais que seguem as especificaes da SFSSQL. Para exemplificar o uso desses operadores e funes, mostraremos os comandos em SQL para executar as consultas dos cenrios de 1 a 5, apresentados no incio desse captulo. Cenrio 1 Usando o operador touches, uma possvel consulta seria:
SELECT d2.nomemunicp FROM grande_sp d1, grande_sp d2 WHERE touches(d1.spatial_data, d2.spatial_data) AND (d2.nomemunicp <> 'SAO PAULO') AND (d1.nomemunicp = 'SAO PAULO'); Resultado: nomemunicp COTIA ITAPECERICA DA SERRA EMBU-GUACU SANTANA DE PARNAIBA SANTO ANDRE GUARULHOS MAIRIPORA (21 rows)
nomemunicp JUQUITIBA ITAQUAQUECETUBA EMBU TABOAO DA SERRA BARUERI CAJAMAR OSASCO
nomemunicp CAIEIRAS SAO BERNARDO DO CAMPO DIADEMA SAO CAETANO DO SUL MAUA FERRAZ DE VASCONCELOS POA
Na consulta acima, o operador touches retorna verdadeiro caso as geometrias de d2 toquem na geometria de So Paulo. Esse um exemplo
286
de juno espacial entre duas relaes (no nosso caso a mesma relao foi empregada duas vezes). Todas as geometrias da relao d1, com exceo da geometria So Paulo, foram avaliadas no teste topolgico touches, pois o ndice espacial no foi empregado. Em tabelas com grandes nmeros de objetos, importante a utilizao desse ndice. Ele pode ser explorado empregando-se o operador && em conjunto com os predicados da consulta anterior. Nossa consulta pode ser reescrita como:
SELECT d2.nomemunicp FROM distritossp d1, distritossp d2 WHERE touches(d1.spatial_data, d2.spatial_data) AND (d2.nomemunicp <> 'SAO PAULO') AND (d1.spatial_data && d2.spatial_data) AND (d1.nomemunicp = 'SAO PAULO');
Cenrio 2 Novamente iremos empregar o operador touches:

SELECT grande_sp.nomemunicp FROM distritossp, grande_sp WHERE touches(distritossp.spatial_data, grande_sp.spatial_data) AND (distritossp.spatial_data && grande_sp.spatial_data) AND (distritossp.denominacao = 'ANHANGUERA'); Resultado: nomemunicp BARUERI SANTANA DE PARNAIBA CAJAMAR
nomemunicp OSASCO CAIEIRAS
(5 rows)
Cenrio 3 Para este cenrio, podemos utilizar o operador contains:

SELECT FROM WHERE AND AND COUNT(*) bairrossp pt, distritossp pol contains(pol.spatial_data, pt.spatial_data) (pol.spatial_data && pt.spatial_data) pol.denominacao = 'GRAJAU';
Resultado: count 52 (1 row)
287
Cenrio 4 Aqui empregaremos os operadores buffer e intersects:

SELECT grande_sp.nomemunicp FROM grande_sp, drenagemsp WHERE intersects(buffer(drenagemsp.spatial_data, 3000), grande_sp.spatial_data) AND drenagemsp.cod = 59; Resultado: Denominao denominacao denominacao AGUA RASA JAGUARA SANTANA ALTO DE PINHEIROS JAGUARE SAO DOMINGOS BARRA FUNDA LAPA SE BELEM LIMAO TATUAPE BOM RETIRO MOOCA VILA FORMOSA BRAS PARI VILA GUILHERME CANGAIBA PENHA VILA LEOPOLDINA CARRAO PERDIZES VILA MARIA CASA VERDE PIRITUBA VILA MATILDE CONSOLACAO REPUBLICA VILA MEDEIROS FREGUESIA DO O RIO PEQUENO JACANA SANTA CECILIA (34 rows)
Cenrio 5 A resposta a essa pergunta poderia ser traduzida, de incio, na seguinte consulta:
SELECT b1.bairro FROM bairrossp b1, bairrossp b2 WHERE (distance(b1.spatial_data, b2.spatial_data) < 3000) AND b1.bairro <> 'BOACAVA' AND b2.bairro = 'BOACAVA' order by b1.bairro; Resultado: Bairro ALTO DA LAPA ALTO DE PINHEIROS BELA ALIANCA BUTANTA JAGUARE LAPA (18 rows)
bairro PINHEIROS SICILIANO SUMAREZINHO VILA ANGLO BRASILEIRA VILA HAMBURGUESA VILA IDA
bairro VILA INDIANA VILA IPOJUCA VILA LEOPOLDINA VILA MADALENA VILA RIBEIRO DE BARROS VILA ROMANA
No entanto, podemos reescrever essa mesma consulta de forma mais eficiente, utilizando o ndice espacial. A estratgia bsica montar um retngulo de 6Km por 6Km centrado no bairro BOACAVA, de forma
288
que somente seja necessrio calcular a distncia para os pontos que estejam dentro do retngulo. Reescrevendo a consulta temos:
SELECT b1.nome, astext(b1.spatial_data) FROM bairros b1, bairros b2 WHERE (distance(b1.spatial_data, b2.spatial_data) < 3000) AND (expand(b2.spatial_data, 3000) && b1.spatial_data) AND b1.nome <> 'BOACAVA' AND b2.nome = 'BOACAVA' ORDER BY b1.nome;
8.4 Oracle Spatial Oracle Spatial (Murray, 2003) uma extenso espacial desenvolvida sobre o modelo objeto-relacional do SGDB Oracle. Este modelo permite definir novos tipos de dados atravs da linguagem de definio de dados SQL DDL, e implementar operaes sobre esses novos tipos, atravs da linguagem PL/SQL (Urman, 2002), uma extenso da SQL (Lassen et al, 1998). Esta extenso baseada nas especificaes do OpenGIS e contm um conjunto de funcionalidades e procedimentos que permitem armazenar, acessar, modificar e consultar dados espaciais de representao vetorial. O Oracle Spatial formado pelos seguintes componentes: Um modelo prprio de dados chamado MDSYS que define a forma de armazenamento, a sintaxe e semntica dos tipos espaciais suportados. Mecanismo de indexao espacial. Um conjunto de operadores e funes para representar consultas, juno espacial e outras operaes de anlise espacial. Aplicativos administrativos. 8.4.1 Tipos de dados espaciais O modelo de dados do Spatial consiste em uma estrutura hierrquica de elementos, geometrias e planos de informao (layers). Cada plano formado por um conjunto de geometrias, que por sua vez so formadas por um conjunto de elementos.
Oracle Spatial
289
Cada elemento associado a um tipo espacial primitivo, como ponto, linha ou polgono (com ou sem ilhas), os quais so mostrados na Figura 8.11.
Figura 8.11 Tipos espaciais primitivos do Oracle Spatial. Os tipos espaciais bidimensionais so compostos por pontos formados por duas ordenadas X e Y, freqentemente correspondentes longitude e latitude. A extenso tambm suporta o armazenamento e indexao de tipos tridimensionais e tetradimensionais, mas as funes e operadores s funcionam para os tipos bidimensionais. Uma geometria pode ser formada por um nico elemento, ou por um conjunto homogneo (multipontos, multilinhas ou multipolgonos) ou heterogneo (coleo) de elementos. Um plano de informao formado por uma coleo de geometrias que possuem um mesmo conjunto de atributos. Baseado no modelo objeto-relacional, o Spatial define um tipo de objeto, para representar dados espaciais, chamado SDO_GEOMETRY, como mostrado a seguir.
CREATE TYPE sdo_geometry AS OBJECT ( SDO_GTYPE NUMBER, SDO_SRID NUMBER,
290
SDO_POINT SDO_ELEM_INFO SDO_ORDINATES

SDO_POINT_TYPE, SDO_ELEM_INFO_ARRAY, SDO_ORDINATE_ARRAY);
Este objeto contm a geometria em si, suas coordenadas, e informaes sobre seu tipo e projeo. Em uma tabela espacial, os atributos alfanumricos da geometria so definidos como colunas de tipos bsicos (VARCHAR2, NUMBER, DATE, dentre outros), e a geometria como uma coluna do tipo SDO_GEOMETRY. Em uma tabela espacial, cada instncia do dado espacial armazenada em uma linha, e o conjunto de todas as instncias dessa tabela forma um plano de informao. O objeto SDO_GEOMETRY composto pelos seguintes atributos:
SDO_GTYPE:
formado por quatro nmeros, onde os dois primeiros indicam a dimenso da geometria e os outros dois o seu tipo. Os tipos podem ser: 00 (no conhecido), 01 (ponto), 02 (linha ou curva), 03 (polgono), 04 (coleo), 05 (multipontos), 06 (multilinhas) e 07 (multipolgonos); SDO_SRID: utilizado para identificar o sistema de coordenadas, ou sistema de referncia espacial, associado geometria; SDO_POINT: definido utilizando um objeto do tipo SDO_POINT_TYPE, que contm os atributos X, Y e Z para representar as coordenadas de um ponto. Somente preenchido se a geometria for do tipo ponto, ou seja, se os dois ltimos nmeros do SDO_GTYPE forem iguais a 01;
SDO_ELEM_INFO:
um vetor de tamanho varivel que armazena as caractersticas dos elementos que compem a geometria. As coordenadas de cada elemento so armazenadas em um vetor varivel chamado SDO_ORDINATES e so interpretadas atravs de trs nmeros armazenados no SDO_ELEM_INFO: o SDO_STARTING_OFFSET: indica qual a posio da primeira coordenada do elemento no SDO_ORDINATES; o SDO_ETYPE: indica o tipo do elemento; o SDO_INTERPRETATION: indica como o elemento deve ser interpretado juntamente com o SDO_ETYPE.
Oracle Spatial
291
um vetor de tamanho varivel que armazena os valores das coordenadas da geometria. Como exemplo, mostraremos os comandos em SQL para gerar tabelas para armazenar os atributos e as geometrias: Dos distritos de So Paulo, mostrados na Figura 8.1
CREATE TABLE DistritosSP ( cod NUMBER(32) NOT NULL , sigla VARCHAR2(20), denominacao VARCHAR2(200), spatial_data MDSYS.SDO_GEOMETRY, PRIMARY KEY (cod))
SDO_ORDINATES:
Dos bairros de So Paulo, mostrados na Figura 8.2.

CREATE TABLE BairrosSP ( geom_id NUMBER(32) NOT NULL, bairro VARCHAR2(200), distr VARCHAR2(200), spatial_data MDSYS.SDO_GEOMETRY, PRIMARY KEY (geom_id))
Do mapa de drenagem, mostrado na Figura 8.3

CREATE TABLE DrenagemSP ( geom_id NUMBER(32) NOT NULL, classe VARCHAR2(100) NULL, spatial_data MDSYS.SDO_GEOMETRY, PRIMARY KEY (geom_id))
As tabelas criadas anteriormente contm colunas de tipos bsicos como NUMBER e VARCHAR2 para armazenar atributos, e uma coluna do tipo SDO_GEOMETRY para armazenar geometrias. Note que no preciso especificar, na criao, o tipo de geometria que ser armazenado. Mostramos a seguir alguns exemplos de comandos SQL para inserir dados nessas tabelas criadas:
INSERT INTO DistritosSP (cod, sigla, denominacao, spatial_data) VALUES (1, 'VMR', 'VILA MARIA' MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY( 1, 1003, 1 ), MDSYS.SDO_ORDINATE_ARRAY(6,10, 10,1, 14,10, 10,14, 6,10)))
292
INSERT INTO DrenagemSP ( geom_id, classe, spatial_data) VALUES (1, 'RIO', MDSYS.SDO_GEOMETRY(2002, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY( 1, 2, 1 ), MDSYS.SDO_ORDINATE_ARRAY(10,10, 10,14, 6,10, 14,10))) INSERT INTO BairrosSP ( geom_id, bairro, distr, spatial_data) VALUES ( 1, 'JARDIM SHANGRILA', 'GRAJAU' MDSYS.SDO_GEOMETRY(2001, NULL, MDSYS.SDO_POINT_TYPE(32.628, 736.944, NULL ), NULL, NULL))
Observe que para incluir uma geometria atravs de um comando SQL preciso montar um objeto SDO_GEOMETRY. Atravs do atributo SDO_GTYPE, podemos identificar qual o tipo da geometria contida no SDO_GEOMETRY. A geometria inserida na tabela DistritosSP um polgono (SDO_GTYPE=2003), na DrenagemSP uma linha (SDO_GTYPE=2002) e na BairrosSP um ponto (SDO_GTYPE=2001), todos bidimensionais. Alm disso, todas as geometrias so formadas por um nico elemento cujo tipo pode ser identificado atravs dos atributos SDO_ETYPE e SDO_INTERPRETATION. A Tabela 8.3 apresenta os tipos de elementos possveis. Note que a primeira coordenada de um polgono tem que ser igual ltima, e seus anis externos (SDO_ETYPE=1003) devem estar no sentido anti-horrio, e os internos (SDO_ETYPE=2003), no sentido horrio. Nesse exemplo no estamos usando o sistema de coordenadas fornecido pela extenso (SDO_SRID=NULL). Atravs de um comando SQL simples, possvel recuperar o objeto SDO_GEOMETRY. A seguir mostraremos uma consulta e o resultado retornado pelo Spatial:
SELECT spatial_data FROM DistritosSP WHERE denominacao = 'PARELHEIROS' Resultado: SPATIAL_DATA -------------------------------------------------------SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(370139,955, 7408390,5, 369854,277, 7407971,06, 370014,832, 7408419,18, 370139,955, 7408390,5, 369854,277, 7407971,06, 370014,832, 7408419,18, 370139,955, 7408390,5))
Oracle Spatial
293
Tabela 8.3 Tipos de elementos espaciais

SDO_ ETYPE 0 1 1 2 2 1003 ou 2003 1003 ou 2003 1003 ou 2003 1003 ou 2003 4 SDO_ INTERPRETATION Nenhum valor 1 n>1 1 2 1 2 3 4 n>1
Descrio do tipo
Tipo no suportado Ponto Conjunto de n pontos Linha formada por vrtices conectados por segmentos retos Linha formada por vrtices conectados por arcos circulares Polgono simples composto por vrtices conectados por segmentos retos Polgono simples composto por vrtices conectados por arcos circulares Retngulo otimizado composto por dois pontos Crculo formado por trs pontos da circunferncia Linha composta por alguns vrtices conectados por segmentos de reta e outros por arcos Polgono composto por alguns vrtices conectados por segmentos de reta e outros por arcos
1005 ou 2005
n>1
O modelo MDSYS apresenta dois conjuntos de tabelas de metadados que so utilizadas por funcionalidades internas da extenso, como por exemplo, nas consultas espaciais: Tabelas de metadados sobre geometrias armazenadas, chamadas USER_SDO_GEOM_METADATA e ALL_SDO_GEOM_METADATA. Tabelas de metadados sobre indexao espacial, chamadas
USER_SDO_INDEX_METADATA e ALL_SDO_INDEX_INFO.
294
As tabelas de metadados sobre geometrias armazenam, para cada tabela espacial: o seu nome (TABLE_NAME); o nome da coluna de tipo geomtrico (COLUMN_NAME); todas as dimenses das geometrias, cada uma com um mnimo retngulo envolvente e uma tolerncia (DIMINFO); e o sistema de coordenadas (SRID). Sua estrutura mostrada a seguir:
TABLE_NAME COLUMN_NAME DIMINFO SRID VARCHAR2(32), VARCHAR2(32), SDO_DIM_ARRAY, NUMBER
Aps criar e inserir os dados em uma tabela espacial, o usurio deve registrar seu metadado. A seguir, mostraremos um exemplo de um comando em SQL para inserir o metadado referente tabela espacial DistritosSP criada anteriormente.
INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'DistritosSP' ,'spatial_data' , MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT('X',275.9670,429.567,0.0005), MDSYS.SDO_DIM_ELEMENT('Y',833.0355,582.15,0.0005)), NULL)
Note que as geometrias armazenadas na tabela DistritosSP possuem duas dimenses X e Y, portanto, existem duas entradas no vetor SDO_DIM_ARRAY, uma para cada dimenso contendo seu mnimo retngulo envolvente e sua tolerncia. 8.4.2 Indexao espacial Indexao espacial, como qualquer outro tipo de indexao, fornece mecanismos para limitar o conjunto de busca, aumentando assim a performance das consultas e da recuperao dos dados espaciais. O Spatial fornece dois tipos de indexao espacial, R-tree e Quadtree, podendo ser utilizados simultaneamente. Porm, o Oracle recomenda fortemente o uso de R-tree ao invs de Quadtree, por causa do seu desempenho. Mais informaes sobre tipos de indexao espacial podem ser encontrados no Captulo 6. O usurio pode criar uma R-tree utilizando os parmetros default do MDSYS ou especificando cada parmetro como, por exemplo, o tamanho da memria utilizada e o nmero de dimenses a serem indexadas. A
Oracle Spatial
295
sintaxe de um comando em SQL pra gerar uma R-tree com parmetros default do MDSYS :
CREATE INDEX index_name ON table_name (spatial_column_name) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
Como exemplo, mostraremos os comandos em SQL usados para gerar os ndices espaciais das tabelas criadas anteriormente:
CREATE INDEX DistritosSP_IDX ON DistritosSP(SPATIAL_DATA) INDEXTYPE IS MDSYS.SPATIAL_INDEX CREATE INDEX DrenagemSP_IDX ON DrenagemSP (SPATIAL_DATA) INDEXTYPE IS MDSYS.SPATIAL_INDEX CREATE INDEX BairrosSP_IDX ON BairrosSP(SPATIAL_DATA) INDEXTYPE IS MDSYS.SPATIAL_INDEX
Ao inserir, remover ou modificar geometrias de uma tabela, a performance do ndice espacial gerado inicialmente pode ser degradada. Para isso, a extenso fornece um conjunto de funes para avaliar a performance dos ndices, como a funo SDO_TUNE.QUALITY_DEGRADATION, e para reconstru-lo, usando o comando ALTER INDEX REBUILD. Aps a criao de ndices espaciais, a extenso atualiza, automaticamente, as tabelas de metadados sobre indexao citadas na Seo 8.2.1.1. Essas tabelas so mantidas pela extenso e no devem ser alteradas pelos usurios. 8.4.3 Consultas espaciais O Oracle Spatial utiliza um modelo de consulta baseado em duas etapas, chamadas de primeiro e segundo filtro, como mostrado na Figura 8.12. O primeiro filtro considera as aproximaes das geometrias, pelo critrio do mnimo retngulo envolvente (MBR), para reduzir a complexidade computacional. Este filtro de baixo custo computacional e seleciona um subconjunto menor de geometrias candidatas, que ser passado para o segundo filtro. O segundo filtro trabalha com as geometrias exatas, por isso computacionalmente mais caro e s aplicado ao subconjunto resultante do primeiro filtro. Retorna o resultado exato da consulta.
296
Figura 8.12 Modelo de Consulta.
Para executar consultas e operaes espaciais, o Oracle Spatial fornece um conjunto de operadores e funes que so utilizados juntamente com a linguagem SQL. Os operadores, alguns mostrados na Tabela 8.4, so usados na clusula WHERE e utilizam indexao espacial. Portanto, s podem ser executados sobre colunas espaciais j indexadas. As funes, algumas mostradas na Tabela 8.5, so definidas como subprogramas em PL/SQL, e utilizadas na clusula WHERE ou em subconsultas, podendo ser executadas sobre colunas espaciais no indexadas. Devido ao fato dos operadores sempre explorarem a indexao, recomendvel us-los, em lugar de funes, quando possvel.
Tabela 8.4 Principais operadores espaciais
Operador
SDO_FILTER
SDO_RELATE
Descrio Implementa o primeiro filtro do modelo de consulta, ou seja, verifica se os mnimos retngulos envolventes das geometrias tm alguma interao entre si. Avalia se as geometrias possuem uma determinada relao topolgica. Verifica se duas geometrias esto dentro de uma determinada distncia. Identifica os n vizinhos mais prximos de uma geometria
SDO_WITHIN_ DISTANCE SDO_NN
Oracle Spatial
297
A sintaxe de cada operador mostrada a seguir:

SDO_FILTER (geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY)
SDO_RELATE (geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2) SDO_WITHIN_DISTANCE (geometry1 SDO_GEOMETRY, aGeom SDO_GEOMETRY, params VARCHAR2); SDO_NN (geometry1 SDO_GEOMETRY, aGeom SDO_GEOMETRY, param [, number NUMBER]);
VARCHAR2,
Os operadores SDO_FILTER e SDO_RELATE recebem os parmetros em comum: geometry1: uma coluna do tipo SDO_GEOMETRY de uma tabela que deve estar indexada. geometry2: um objeto do tipo SDO_GEOMETRY. Esse objeto pode ser uma instncia em memria ou estar armazenado em alguma tabela espacial, que no precisa ser indexada. Alm dos parmetros citados anteriormente, o SDO_RELATE recebe ainda o tipo da relao topolgica a ser computada (param), que pode ser
EQUAL, DISJOINT, OVERLAPBDYINTERSECT, TOUCH, INSIDE, ON, CONTAINS, COVERS, COVERREDBY, OVERLAPBDYDISJOINT e ANYINTERACT. Este operador baseado no Modelo de 9-Intersees mostrado no capitulo 2. Os operadores SDO_WITHIN_DISTANCE e SDO_NN recebem os parmetros em comum: geometry1: uma coluna do tipo SDO_GEOMETRY de uma tabela que deve estar indexada. aGeom: uma instncia do tipo SDO_GEOMETRY.
Alm
dos
SDO_WITHIN_DISTANCE
parmetros em comum, os operadores e SDO_NN recebem outros, como a distncia a ser
298
considerada e o nmero de vizinhos que devem ser retornados. A extenso ainda fornece alguns operadores que no sero abordados neste capitulo, como por exemplo, SDO_JOIN, SDO_TOUCH, SDO_INSIDE, SDO_ON, dentre outros. As funes fornecidas pelo Spatial podem ser agrupadas em: Relao (verdadeiro/falso) entre duas geometrias: RELATE e WITHIN_DISTANCE. Validao:
VALIDATE_GEOMETRY_WITH_CONTEXT, VALIDATE_LAYER_WITH_CONTEXT.
Operaes sobre uma geometria:

SDO_ARC_DENSIFY, SDO_AREA, SDO_BUFFER, SDO_CENTROID, SDO_CONVEXHULL, SDO_LENGTH, SDO_MAX_MBR_ORDINATE, SDO_MIN_MBR_ORDINATE, SDO_MBR, SDO_POINTONSURFACE.
Operaes sobre duas geometrias:

SDO_DISTANCE, SDO_DIFFERENCE, SDO_INTERSECTION, SDO_UNION, SDO_XOR.
Tabela 8.5 Algumas funes espaciais. Funo

SDO_BUFFER
Descrio Gera uma nova geometria ao redor ou dentro de uma outra, considerando uma distncia passada como parmetro. Calculam, respectivamente, a rea e o permetro ou comprimento de uma geometria. Calcula a distncia entre duas geometrias. Geram uma nova geometria resultante da interseo, unio e diferena, respectivamente, entre outras duas.
SDO_AREA SDO_ LENGTH SDO_DISTANCE SDO_INTERSECTION SDO_UNION SDO_DIFFERENCE
Oracle Spatial
299
Para exemplificar o uso desses operadores e funes, mostraremos os comandos em SQL para executar as consultas dos cenrios de 1 a 5, apresentados no incio desse captulo. Cenrio 1 Essa consulta realizada sobre as geometrias da tabela espacial MunicipiosSP. Para respond-la, podemos usar tanto o operador SDO_RELATE quanto o operador SDO_TOUCH na clusula WHERE da SQL:
SELECT t1.nomemunicp FROM MunicipiosSP t1, MunicipiosSP t2 WHERE SDO_RELATE (t1.spatial_data, t2.spatial_data, 'mask=TOUCH') = 'TRUE' AND t2.nomemunicp = 'SAO PAULO' SELECT t1.nomemunicp FROM MunicipiosSP t1, MunicipiosSP t2 WHERE SDO_TOUCH (t1.spatial_data, t2.spatial_data) = 'TRUE' AND t2.nomemunicp = 'SAO PAULO' Resultado: nomemunicp COTIA ITAPECERICA DA SERRA EMBU-GUACU SANTANA DE PARNAIBA SANTO ANDRE GUARULHOS MAIRIPORA (21 rows)
nomemunicp JUQUITIBA ITAQUAQUECETUBA EMBU TABOAO DA SERRA BARUERI CAJAMAR OSASCO
nomemunicp CAIEIRAS SAO BERNARDO DO CAMPO DIADEMA SAO CAETANO DO SUL MAUA FERRAZ DE VASCONCELOS POA
Cenrio 2 Essa consulta realizada sobre as geometrias de duas tabelas espaciais distintas, MunicipiosSP e DistritosSP. Podemos usar tanto o operador SDO_RELATE quanto o operador SDO_TOUCH na clusula WHERE:
SELECT t1.nomemunicp FROM MunicipiosSP t1, DistritosSP t2 WHERE SDO_RELATE (t1.spatial_data, t2.spatial_data, 'mask= TOUCH') = 'TRUE' AND t2.denominacao = 'ANHANGUERA' SELECT t1.nomemunicp FROM MunicipiosSP t1, DistritosSP t2 WHERE SDO_TOUCH (t1.spatial_data, t2.spatial_data) = 'TRUE' AND t2.denominacao = 'ANHANGUERA'
300
Resultado: nomemunicp BARUERI SANTANA DE PARNAIBA CAJAMAR (5 rows)
nomemunicp OSASCO CAIEIRAS
Cenrio 3 Essa consulta utiliza a funo de agregao juntamente com o operador SDO_RELATE ou SDO_INSIDE.
SELECT COUNT(*) FROM BairrosSP t1, DistritosSP t2 WHERE SDO_RELATE (t1.spatial_data, t2.spatial_data, 'mask=INSIDE') = 'TRUE' AND t2.denominacao = 'GRAJAU'
COUNT
SELECT COUNT(*) FROM BairrosSP t1, DistritosSP t2 WHERE SDO_INSIDE (t1.spatial_data, t2.spatial_data) = 'TRUE' AND t2.denominacao = 'GRAJAU' Resultado: count 52 (1 row)
Cenrio 4 Para realizar essa consulta utilizamos dois operadores espaciais, SDO_BUFFER e SDO_RELATE. Para gerar o buffer, o operador usar a tolerncia definida na tabela de metadados. Observe que o operador SDO_RELATE recebe como parmetro a combinao de trs relaes topolgicas.
SELECT t1.denominacao FROM DistritosSP t1, DreanagemSP t2, user_sdo_geom_metadata m WHERE SDO_RELATE (t1.spatial_data, SDO_GEOM.SDO_BUFFER(t2.spatial_data, m.diminfo, 3000), 'mask=INSIDE+TOUCH+ OVERLAPBDYINTERSECT') = 'TRUE' AND m.table_name = ' DreanagemSP ' AND m.column_name = 'spatial_data' AND t2.geom_id = 55 Resultado: denominacao denominacao denominacao AGUA RASA JAGUARA SANTANA
ALTO DE PINHEIROS BARRA FUNDA BELEM BOM RETIRO BRAS CANGAIBA CARRAO CASA VERDE CONSOLACAO FREGUESIA DO O JACANA (34 rows) JAGUARE LAPA LIMAO MOOCA PARI PENHA PERDIZES PIRITUBA REPUBLICA RIO PEQUENO SANTA CECILIA SAO DOMINGOS SE TATUAPE VILA FORMOSA VILA GUILHERME VILA LEOPOLDINA VILA MARIA VILA MATILDE VILA MEDEIROS
301
Cenrio 5 Esta consulta utiliza a funo SDO_DISTANCE na clusula WHERE.

SELECT t1.BAIRRO FROM BairrosSP t1, BairrosSP t2 WHERE SDO_GEOM.SDO_DISTANCE (t1.spatial_data, t2.spatial_data, 0.00005) < 3000 AND t2.bairro = 'BOACAVA' Resultado: bairro ALTO DA LAPA ALTO DE PINHEIROS BELA ALIANCA BUTANTA JAGUARE LAPA (18 rows)
bairro PINHEIROS SICILIANO SUMAREZINHO VILA ANGLO BRASILEIRA VILA HAMBURGUESA VILA IDA
bairro VILA INDIANA VILA IPOJUCA VILA LEOPOLDINA VILA MADALENA VILA RIBEIRO BARROS VILA ROMANA DE
8.5 Leituras suplementares Alm das extenses apresentadas neste captulo, ainda temos o IBM DB2 Spatial Extender (IBM, 2002), o Informix Spatial e Geodetic Datablade (IBM, 2003) e a extenso do MySQL (Yarger et al, 1999). A extenso espacial deste ltimo SGBD encontra-se em construo (MySQL AB, 2003). O seu projeto segue as especificaes da SFSSQL, e os nicos recursos disponibilizados at o momento so os tipos de dados espaciais semelhantes aos fornecidos pelo PostGIS (Point, LineString,
302
Polygon, MultiLineString, MultiPolygon, MultiPoint e GeometryCollection) e o mecanismo de indexao atravs de R-Tree. O quadro abaixo apresenta um resumo comparativo entre os SGBDs com suporte espacial:
Tabela 8.6 Quadro Comparativo entre os SGBDs com Suporte Espacial. Recurso Oracle Spatial SFSSQL R-Tree e QuadTree PostgreSQL comTipos Geomtricos Tipos simples R-Tree nativa ou R-Tree sobre GiST No PostgreSQL comPostGIS SFSSQL R-Tree sobre GiST MySQL
Tipos espaciais Indexao espacial
SFSSQL R-Tree
Operadores topolgicos Operadores de conjuntos Operador de buffer region Transformao entre sistemas de coordenadas Tabelas de metadados das colunas geomtricas
Matriz 9Intersees Sim Sim Sim
No No No
Matriz 9Intersees DE Sim Sim Sim
Em desenv.
Em desenv. Em desenv. No
Sim (diferente do OGIS)
No
Sim (conforme OGIS)
No
Referncias
303
Referncias
HELLERSTEIN, J. M.; NAUGHTON, J. F.; PFEFFER, A. Generalized search trees for databases systems. In: international Conference in VLDB, 21., set. 1995, Zurich, Switzerland. Proceeding. San Francisco: Morgan Kaufman, 1995, 562-573. IBM. IBM DB2 Spatial Extender: user's guide and reference. Disponvel em: <http://www.ibm.com.br>. Acesso em: jun. 2002. IBM. Working with the geodetic and spatial datablade modules. Disponvel em: <http://www.ibm.com>. Acesso em: out. 2003. KERNIGHAN, B. W.; RITCHIE, D. M. C: a linguagem de programao padro ANSI. Brasil: Campus, 1990. LASSEN, A. R. O., J.; OSTERBYE, K., 1998, Object Relational Modeling, Centre for Object Technology (COT). MURRAY, C., 2003, Oracle Spatial Users Guide and Reference 10g Release 1 (10.1), Redwood City, Oracle Corporation, p. 602. MySQL AB. MySQL reference manual. Disponvel em: <http://www.mysql.com>. Acesso em: nov. 2003. RAMSEY, P. PostGIS manual. Disponvel em: <http://postgis.refractions.net/documentation>. Acesso em: jan. 2002. RAVADA, S.; SHARMA, J. Oracle8i Spatial: experiences with extensible databases. In: International Symposium on Spatial Databases, 6., jul. 1999, Hong Kong, China. Proceedings Berlin: Springer-Verlag, 1999, p. 355359. REFRACTIONS Inc. GEOS API documentation. Disponvel em: <http://geos.refrcations.net>. Acesso em: nov. 2003. STONEBRAKER, M.; ROWE, L. A.; HIROHAMA, M. The implementation of Postgres. IEEE Transactions on Knowledge and Data Engineering, v. 2, n. 1, p. 125-142, mar. 1990. URMAN, S. Oracle 9i Programacao PL/SqL. Rio de Janeiro: Editora Campos, 2002. 552 p. VIVID SOLUTIONS. JTS technical specifications. Disponvel em: <http://www.vividsolutions.com/jts/jtshome.htm>. Acesso em: nov. 2003. YARGER, R. J.; REESE, G.; KING, T. MySQL & mSQL. EUA: O'Reilly, 1999.
9 Integrao e interoperabilidade entre fontes de dados geogrficos

Marco Antonio Casanova Daniela Francisco Brauner Gilberto Cmara Paulo de Oliveira Lima Jnior
9.1 Introduo Este captulo aborda inicialmente o problema bsico de intercmbio de dados geogrficos. Em seguida, apresenta um breve resumo da arquitetura e das tecnologias relacionadas a integrao e interoperabilidade no contexto de dados geogrficos, ilustrado com exemplos. Focaliza ento a definio de mapeamentos entre fontes de dados. Um exemplo simples ilustra as dificuldades encontradas para criar mapeamentos entre fontes que apresentem heterogeneidade nos dados, tanto em formato e estrutura, quanto em interpretao ou significado. Por fim, o captulo trata da construo de mediadores capazes de distribuir consultas entre diversas fontes e combinar os resultados devolvidos em uma nica resposta para o usurio. O Captulo 10 tratar em detalhe as questes de interoperabilidade especificas para o contexto da Internet, enquanto que o Captulo 11 resumir as propostas do Open Geospatial Consortium (OGC) endereando interoperabilidade. A motivao para este e os prximos dois captulos nasce do crescente volume de fontes independentes de dados geogrficos, interligadas entre si, fato que abre uma oportunidade nica para intercmbio de dados em tempo hbil, reduzindo custos e agilizando processos de deciso. No
Intercmbio de dados geogrficos
306
entanto, para tal, as aplicaes devem ser capazes de interpretar e processar dados oriundos de diversas fontes, bem como localizar e acessar as prprias fontes. Referncias para problemas especficos sobre integrao e interoperabilidade entre fontes de dados geogrficos encontram-se ao longo do texto e sugestes para leitura adicional, ao final do captulo. 9.2 Intercmbio de dados geogrficos
9.2.1 Problemas inerentes ao intercmbio de dados geogrficos Entendemos por intercmbio de dados a capacidade de compartilhar e trocar informaes e processos entre diferentes usurios de informao. O grande desafio do intercmbio de dados enfrentar a diversidade de modelos conceituais1 dos SIGs disponveis no mercado. Esta diversidade faz com que muitas organizaes produtoras de informao georreferenciada sigam regras conceituais vinculadas ao sistema por elas utilizado. O resultado um ambiente heterogneo, onde cada organizao tem sua maneira de organizar a informao espacial. A falta de modelos conceituais comuns acarreta problemas na troca de dados entre organizaes utilizando SIGs distintos. Estes problemas incluem distoro de dados, perdas de qualidade da informao e de definies de atributos e informao sobre georreferenciamento. A tarefa de compartilhamento de dados geogrficos deve envolver processos para garantir que a informao no seja perdida ou corrompida na transferncia, e ferramentas para prevenir inconsistncias resultantes de conjuntos de dados redundantes. Dada a variedade de usurios e diversidade do uso do dado espacial e sistemas de computao, conveniente dispor de mecanismos de intercmbio para compartilhar dados entre diferentes sistemas de computao. Em SIGs, realizar intercmbio de dados no uma tarefa simples, devido a complexidade da informao geogrfica envolvida, ocorrendo incompatibilidades em vrios nveis. O problema vem sendo estudado em
1
Segundo Thom (1998) entende-se por modelos conceituais a semntica do funcionamento de cada SIG, e a maneira como os dados devem estar organizados.
307
9 Integrao e interoperabilidade
diferentes nveis, como a converso entre formatos de dados prprios de cada SIG, a converso entre semnticas de bancos de dados distintos e o desenvolvimento ou uso de modelos gerais de dados geogrficos propostos por diferentes organizaes. 9.2.2 Converso sinttica de dados geogrficos O armazenamento dos dados geogrficos em um SIG organizado em estruturas prprias que descrevem caractersticas dos dados, por exemplo, coordenadas dos pontos que formam um polgono representando geometricamente uma dada entidade geogrfica. As entidades geogrficas possuem uma representao geomtrica ou geometria e atributos associados. A geometria vetorial baseada nas primitivas: ponto, linha e polgonos, que podem ser derivadas para formar estruturas mais complexas. A Figura 9.1 mostra exemplos de geometrias vetoriais.
Figura 9.1 Geometrias vetoriais usadas em SIGs. Normalmente a organizao dos dados nos SIGs distribuda em camadas (layers ou planos de informao), onde cada camada contm uma varivel geogrfica distinta, por exemplo uma imagem de satlite de uma regio, os municpios desta regio, a sua geomorfologia, ou hidrologia. Cada camada representada internamente em estruturas lgicas prprias de cada SIG e armazenada em arquivos distintos de acordo com o formato prprio do sistema utilizado. Este esquema de codificao e os arquivos de sistema ou de exportao possuem uma sintaxe prpria para descrever as entidades (geometria e atributos), ou seja, a forma de escrever o dado. Consideramos este esquema prprio de cada sistema para armazenar e documentar seus dados, o nvel sinttico. Tradicionalmente, muito do trabalho realizado em intercmbio de dados geogrficos trata de transformaes estruturais (Gardels, 1996). A abordagem mais bsica a converso sinttica direta de formatos, que
308
procura realizar a interpretao e traduo dos arquivos de informao geogrfica em diferentes formatos, permitindo que um sistema compreenda os dados provenientes de outros sistemas. Isto eficiente desde que o desenvolvedor da converso tenha conhecimento dos formatos envolvidos para no comprometer a qualidade dos dados no processo de converso. Cada sistema tem sua prpria definio e nomenclatura para as diferentes formas de geometria. A Figura 9.2 mostra dois trechos de arquivos em diferentes formatos de exportao. O lado esquerdo um fragmento de um arquivo com extenso .E00 proveniente do software Arc/Info o da direita um fragmento de um arquivo de extenso .MIF proveniente do software MapInfo. Ambos descrevem uma mesma entidade, com a mesma geometria e as mesmas coordenadas, mas com uma sintaxe prpria.
Figura 9.2 Arquivos diferentes - E00 x MIF. Entendendo a estrutura especfica de um formato, possvel escrever um cdigo que trata as caractersticas de cada sistema envolvido, viabilizando a converso ou importao direta, atingindo desta forma um grau de interoperabilidade no nvel sinttico. Por fim, cabe salientar que, apesar dos avanos no uso de gerenciadores de dados geogrficos, a primeira gerao de SIGs possui suporte limitado a
309
banco de dados e utiliza arquivos para armazenamento e exportao de dados espaciais, o que torna possvel encontrar um acervo relevante de dados espaciais em arquivos de diferentes formatos. Assim, a abordagem mais bsica para intercmbio de dados geogrficos a converso sinttica direta, que procura realizar a traduo dos arquivos de informao geogrfica entre diferentes formatos. Para permitir este tipo de converso, os SIGs trabalham com duas alternativas: Oferecer um formato de exportao ASCII de fcil legibilidade, como DXF (Autocad), MID/MIF (MapInfo), E00 (Arc/Info) e SPR (Spring); Documentar as estruturas de dados internas, como o caso do SHP (ArcView). 9.2.3 Uso de metadados Metadados so dados sobre os dados, descrevem o contedo, condio, histrico, localizao e outras caractersticas do dado, (FGDC, 2001). O objetivo do seu uso ter um mecanismo para identificar qual dado existe, a sua qualidade, como acess-lo e us-lo. Assim, os metadados tratam a interoperabilidade em nvel de gerenciamento da informao, facilitando a recuperao de uma informao contida em um banco de dados. Por exemplo, uma base de dados contendo mapas com a informao sobre aptido climtica ao plantio de vrias culturas pode incluir, em seus metadados, uma descrio referente ao tipo de cultura contido nos mapas, por exemplo: Aptido climtica ao plantio de abacaxi ou Aptido climtica ao plantio de algodo, o que identifica o tipo de cultura a que o dado se refere, facilitando a consulta ao banco. H propostas de padres nos Estados Unidos e no Canad (FGDC, 2001), com o objetivo de fornecer terminologia e definies comuns para conceitos relacionados aos metadados geogrficos. A seguir descrevemos a proposta do FDGC, como exemplo de esquema de metadados. O FGDC (Federal Geographic Data Committee) um comit entre agncias para promover a coordenao do uso, troca e disseminao de dados espaciais nos EUA. O FGDC (2001) prope um padro que
310
especifica os elementos necessrios para suportar os principais usos de metadados: ajudar a manter um investimento interno em dado espacial, pelas organizaes; prover informao sobre o domnio de dados de uma organizao; prover informao para processar e interpretar dados transferidos de uma fonte externa. O padro estabelece um conjunto comum de terminologia e definies para a documentao do dado geogrfico, incluindo elementos para os seguintes tpicos: identificao, qualidade do dado, organizao espacial do dado, referncia espacial, informao sobre entidade e atributo, distribuio e referncia do metadado (NSDI, 1997). O padro permite ao usurio saber: qual dado est disponvel, se o dado atende suas necessidades especficas, onde achar o dado e como acessar o dado. Muitos dados esto disponveis com este formato de metadados nos EUA onde, estados, governos locais ou do setor privado so incentivados a adotar o padro para documentar seus dados. O FGDC tambm patrocina a criao de uma Clearinghouse (National Geospatial Data Clearinghouse) um Website que guia usurios ao melhor dado espacial para seus projetos por meio de pesquisa a metadados. A inteno no centralizar todos os dados geogrficos em um local, mas prover links na Internet para distribuir Websites onde os dados so produzidos e mantidos. Gerenciadores documentam e disponibilizam seus dados, de acordo com o padro, para a Clearinghouse, assim usurios podem achar facilmente uma informao, o que promove interoperabilidade entre organizaes. Como sua nfase na disponibilidade da informao, o padro FGDC no especifica a maneira pela qual a informao est organizada nem o processo de transferncia. Com exceo da parte de entidades e atributos, que pode revelar parte do significado do dado, as demais partes no descrevem a semntica da informao espacial. O grande problema da proposta do FGDC, e do uso de metadados em geral, a excessiva nfase em informaes que descrevem o processo de produo dos dados. Com relao sintaxe, o padro limita-se a indicar qual o formato em que os dados esto disponveis. No aspecto semntico, suas informaes so muito limitadas, pois o FGDC no adota o modelo padro de geoinformao (campos e objetos). Adicionalmente, o padro
311
do FGDC reflete os compromissos inevitveis do projeto de comit, pois requer uma excessiva quantidade de informaes (de aplicao questionvel), com dezenas de formulrios. Em resumo, a substancial burocracia envolvida em adotar o padro FGDC no se traduz em benefcios proporcionais. Estes fatos talvez expliquem porque sua adoo ainda est limitada e porque o consrcio OpenGIS prope seu prprio formato para metadados. 9.2.4 Uso de ontologias O grande fator limitante de converso de dados so as diferenas de entendimento entre comunidades de usurios distintas. Diferentes vises da realidade geogrfica sempre existiro por pessoas com culturas diferentes, pois a prpria natureza complexa e leva a percepes distintas. Neste caso seria interessante conviver com estas diferentes formas de conhecimento sobre a realidade e tentar criar mecanismos para implementar e combinar diferentes vises, ou seja, representar o conhecimento geogrfico no computador buscando interoperabilidade pela equivalncia semntica dos conceitos entre sistemas distintos. Neste sentido, so propostos trabalhos relacionados a Ontologias e seu uso para interoperabilidade e concepo de SIGs baseados em Ontologias (Fonseca et al., 2000). A Ontologia uma disciplina filosfica que vem desde o estudo feito por Aristteles sobre as categorias e a metafsica, e pode ser definida como o estudo do Ser e de suas propriedades. Para a comunidade de Inteligncia Artificial, ontologias so teorias que especificam um vocabulrio relativo a um certo domnio (Fonseca et al., 2000) e descrevem uma dada realidade usando o conjunto de premissas de acordo com o sentido intencional das palavras deste vocabulrio. O uso de ontologias no desenvolvimento e uso de sistemas de informao leva ao que chamamos de Sistemas de Informao baseados em ontologias (Guarino, 1998). Fonseca et al., (2000) prope um SIG baseado em ontologias, composto por um editor de ontologias, por um servidor de ontologias, por ontologias especificadas formalmente e por classes derivadas de ontologias. A Figura 9.3 mostra o esquema de um SIG baseado em ontologias.
312
Figura 9.3 Esquema de SIG baseado em ontologias (Fonseca et al., 2000).
Na viso apresentada acima, os especialistas especificam formalmente seu conhecimento em ontologias, que so administradas por um servidor de ontologias. As ontologias so traduzidas para componentes de software por tcnicas de orientao a objetos, constituindo um conjunto de classes, gerenciadas por desenvolvedores de classes, que formam uma estrutura hierrquica representando o mundo geogrfico (Fonseca et al., 2000). Desenvolvedores de aplicaes utilizam o conhecimento traduzido em componentes de software (classes) para criar SIGs que tambm podem ser usados para troca de informaes. O servidor permite o folheamento de ontologias e comunica-se com SIGs por meio de mediadores responsveis por extrair informaes destes e criar instncias das classes que vo conter tal informao e o conhecimento extrado das ontologias. Segundo Fonseca et al. (2000) a interoperabilidade semntica poderia ser resolvida atravs do uso de classes derivadas de ontologias, onde toda a manipulao de informaes seria feita baseada nas definies das entidades geogrficas presentes nas ontologias. A interoperabilidade plena requer no s uma equivalncia sinttica entre as entidades representadas pelos sistemas, mas inclui tambm a equivalncia de conceitos e significados destas entidades. Por exemplo,
313
duas comunidades de informao podem utilizar nomes diferentes para o mesmo conceito (como no caso de rio e curso de gua). Ou ainda, um nico conceito para uma comunidade (i.e., rio) pode ser expresso com nveis maiores de detalhe por outra (i.e., rios perenes, rios temporrios, riachos). Neste sentido, necessrio que os formatos de intercmbio de dados disponham de um mecanismo que suporte o conceito de Ontologias e comunidades de informao geogrfica. Com isto, interpretaes diferentes de uma mesma realidade geogrfica possam ser identificadas e facilmente trocadas. 9.3 Estratgias para integrao e interoperabilidade e exemplos
9.3.1 Estratgias para integrao e interoperabilidade As estratgias para tratar dos problemas de integrao e interoperabilidade entre sistemas de informao geogrfica podem ser classificadas em quatro categorias principais (Gupta et al., 1999). A abordagem mais simples consiste em definir catlogos de metadados e dicionrios geogrficos. Um catlogo de metadados armazena descries de colees de dados armazenadas em diversas fontes (Nebert, 2002), oferecendo servios de localizao, consulta e gerncia de metadados, assim como servios de solicitao de dados, que so repassados s fontes. Um catlogo, no entanto, tipicamente no armazena os dados em si. Um dicionrio geogrfico (gazetteer) (Atkinson, 2002) define um vocabulrio consistindo do identificador, localizao e parte dos atributos dos geo-objetos de interesse. Um dicionrio geogrfico tipicamente cobre uma regio bem definida, como um pas, por exemplo. A estratgia de federao (Sheth e Larson, 1990) assume que as fontes de dados mantm autonomia, mas cooperaram para oferecer suporte a operaes globais, que acessam dados em mais de uma fonte. Uma federao fracamente acoplada se a responsabilidade de criar e manter a federao dos usurios, no existindo controle centralizado. J uma federao fortemente acoplada quando existe controle centralizado para acesso s fontes de dados. A estratgia de armazm de dados (data warehouse) (Miller e Han, 2001) consiste em: (1) extrair os dados das diversas fontes; (2) transformar os
Estratgias para integrao e interoperabilidade e exemplos
314
dados extrados para um modelo comum; (3) armazenar os dados transformados em um nico repositrio. Este enfoque vivel quando o nmero de fontes pequeno e relativamente estvel, no necessitando constantes atualizaes nos dados extrados. O processo de transformao pode se tornar particularmente difcil face heterogeneidade dos dados, conforme j discutido na Seo 9.2. A estratgia de mediao (Gupta et al., 1999) baseia-se em uma arquitetura de 3 nveis: camada de adaptao, com as fontes de dados acessadas atravs de adaptadores; camada de aplicao, com as aplicaes que desejam acessar as fontes; camada de mediao, com um ou mais mediadores, que registra as fontes de dados conhecidas, e processa as consultas produzidas pelas aplicaes. A estratgia de mediao ser discutida em detalhe na Seo 9.5. Por fim, a estratgia hbrida combina a estratgia de armazm de dados com mediao. Por exemplo, a arquitetura descrita em (Voisard e Schweppe, 1998) considera 4 camadas: a camada de aplicao, que recebe requisies das aplicaes; a camada de servios virtuais, que oferece um viso uniforme do sistema (um banco de dados virtual); a camada de servios concretos, que gerencia as tarefas dos vrios componentes; e a camada de servios de sistema, que trata de servios internos do sistema. 9.3.2 Exemplo de catlogo de metadados e dicionrio geogrfico O projeto da Alexandria Digital Library (ADL) (Smith e Frew, 1995) (Smith, 1996) (Frew et al., 2000) exemplifica a construo combinada de um catlogo de metadados e de um dicionrio geogrfico, disponvel na Web. Os metadados para informao geo-referenciada combinam elementos dos padres de metadados USMARC e FGDC (USMARC, 1976) (FGDC, 2001), j discutido na Seo 9.2.3. O primeiro o padro de metadados adotado para bibliotecas convencionais do governo dos EUA, enquanto que o segundo define metadados primariamente para catalogar objetos geogrficos em formato digital, e adotado pelas agncias do governo dos EUA. A especificao completa dos metadados mantidos pela ADL contm cerca de 350 campos.
315
O dicionrio geogrfico da ADL contm nomes e caractersticas de acidentes geogrficos oriundos do US Geological Survey's Geographic Names Information System e do US Board of Geographic Names. O primeiro lista o nome de cerca de 1,8 milhes de acidentes geogrficos, organizados hierarquicamente em 15 categorias. J o segundo contm os nomes de cerca de 4,5 milhes de acidentes geogrficos, inclusive acidentes submarinos. A arquitetura da ADL (ver Figura 9.4) segue um modelo de 3 nveis: servidores ADL gerenciam as colees de dados; mediadores ADL implementam servios sobre as colees de dados; clientes ADL oferecem os servios aos usurios finais. Mais detalhadamente, um servidor ADL responsvel por manter uma coleo de metadados descrevendo os objetos catalogados e por implementar os mecanismos de consulta aos metadados, de acordo com os servios definidos pela ADL. Uma entrada no catlogo pode incluir referncias a representaes digitais do objeto, disponveis online ou offline, ou a representaes no-digitais. Os servidores so autnomos, desde que ofeream os servios definidos pela ADL. Assim, uma instituio pode implementar um servidor ADL e publicar os seus dados atravs de um mediador ADL. Um cliente ADL responsvel por oferecer os servios ADL aos usurios finais, quer sejam usurios humanos ou agentes de software. Um cliente ADL deve manter o estado das sesses e suportar interaes complexas com os usurios finais. A pea central da arquitetura o mediador ADL, que esconde a heterogeneidade dos servidores ADL atravs de uma coleo de servios padronizados, oferecidos aos clientes ADL. Estes servios so o cerne do projeto, pois expem a funcionalidade pretendida para o catlogo e o dicionrio geogrfico da ADL. Os servios do mediador ADL no mantm estados de sesses. Ou seja, cada chamada a um servio do mediador tratada como uma transao por si s, e qualquer relacionamento entre duas chamadas deve ser codificado nos seus parmetros. Esta deciso de projeto simplifica a implementao do mediador, mas torna mais difcil implementar consultas que so refinadas em sucessivas interaes com o usurio.
316
Cliente
cliente
HTTP sesso, consulta, contedo, colees, metadados Controle de acesso

KNF
log record
user ID session ID
Gerador de mapas
Query Mapping
Retrieval Mapping Result Merge

SQL
mediador
Query Fanout
Log da sesso
log record ODBC/SQL
Acesso Banco
BD do usurio
servidores
Query View Retrieval Views Query View Retrieval Views Query View Retrieval Views
Dicionrio geogrfico
Catlogo
(Outras colees)
Figura 9.4 Arquitetura da ADL (Frew et al., 2000).
9.3.3 Exemplo de armazm de dados geogrficos O Projeto TerraServer (Barclay, 2000) exemplifica a construo de um armazm de dados geogrficos, combinado com um dicionrio geogrfico. O TerraServer representa o maior repositrio pblico de imagens de sensoriamento remoto e mapas topogrficos disponvel na Web. O TerraServer foi projetado para atender simultaneamente a milhares de acessos atravs da Web. Um usurio pode pesquisar o repositrio de quatro formas diferentes:
317
1. Clicando em um mapa de baixa resoluo da Terra, que indica onde h dados armazenados no repositrio. 2. Indicando o nome de um local. 3. Indicando as coordenadas de interesse. 4. Selecionando o nome de um local de uma lista de locais bem conhecidos. O repositrio do TerraServer foi criado a partir de quatro fontes: USGS Digital Ortho-Quadrangles (DOQ): imagens areas em cinza ou infravervelho na resoluo de 1m. As imagens foram orto-retificadas de tal forma que 1 pixel corresponde a 1m2. Este acervo cobre aproximadamente 40% do territrio dos EUA, correspondendo a 3 milhes de quilmetros quadrados. USGS Digital Raster Graphics (DRG): verses digitalizadas dos mapas topogrficos do USGS. As imagens foram re-amostradas de tal forma que 1 pixel corresponda potncia de 2 mais prxima. Este acervo cobre todo o territrio dos EUA, correspondendo a 10 milhes de quilmetros quadrados. Imagens do SPIN-2: imagens em cinza na resoluo de 1,56m, originrias de satlites militares russos. As imagens foram rotacionadas, com o norte para cima, mas no esto orto-retificadas; foram reamostradas de tal forma que 1 pixel corresponde a 2m2. Este acervo cobre parte da Europa Ocidental, EUA e o Oriente, correspondendo a 1 milho de quilmetros quadrados. Encarta Shaded Relief: mapa em cores naturais do globo terrestre, indicando o relevo, obtido do CD-ROM da Enciclopdia Encarta. A imagem cobre continuamente o globo entre +80 e -80 de latitude, em uma resoluo de aproximadamente 1km2 por pixel. A arquitetura do TerraServer segue as trs camadas usuais: Cliente: um navegador normal que suporte HTTP 1.1 e HTML 3.2. Aplicao: processa as requisies HTTP , repassando-as ao servidor de banco de dados. Servidor de banco de dados: armazena os dados, servindo as requisies da aplicao.
318
A aplicao gera pginas dinamicamente, em HTML 3.2, e as envia ao navegador. Um usurio pode realizar operaes de aproximao, afastamento e deslocamento nas imagens recebidas, sem necessidade de recursos especiais. O banco de dados armazena mapas e imagens recortados em unidades menores, chamadas de blocos (tiles) nesta seo. Os blocos so agrupados logicamente em colees contguas, chamadas de cenas. Os blocos so indexados por tema, resoluo, cena e localizao. O banco de dados mantm uma tabela para cada tema e resoluo. Cada linha de cada uma destas tabelas contm os metadados de um bloco e um campo do tipo BLOB (binary long object), armazenando o prprio bloco, no formato JPEG ou GIF. Cada bloco armazenado no banco de dados, redundantemente, em resolues mais baixas, formando uma pirmide de 7 nveis (ver Captulo 13 para detalhes de armazenamento piramidal). O acervo do USGS/DOQ compatvel com resolues de 1 a 64m; o acervo do USGS/DRG, de 2 a 128m; e o acervo do SPIN, de 1 a 64m. O banco de dados tambm armazena um dicionrio geogrfico, permitindo ao usurio localizar cenas por nome de locais. O dicionrio contm cerca de 1,5 milhes de nomes, incluindo sinnimos, e relaciona cada nome com o sistema de coordenadas utilizado pelo TerraServer. O dicionrio contm ao todo 4 milhes de linhas e ocupa 3.3 GB. O TerraServer entrou em operao em junho de 1998 e atualmente est entre os 1000 Web sites mais visitados. A mdia diria situa-se em: perto de 40 mil visitas; 3,6 milhes de acessos a blocos; 69GB transferidos. 9.3.4 Exemplo de mediador A Misso ao Planeta Terra (Mission to Planet Earth - MTPE) um programa da NASA para estudar processos ligados a mudanas climticas, a partir de dados gerados por inmeros satlites orbitando o planeta Terra. O EOS Data and Information System (EOSDIS) (Kobler, 1995) o componente responsvel por prover acesso fcil e rpido aos dados gerados no contexto do MTPE.
319
O EOSDIS um sistema distribudo, organizado em trs segmentos principais: o Flight Operations Segment (FOS) gerencia e controla os satlites e instrumentos do EOS; o Communications and System Management Segment (CSMS) fornece a infraestrutura de comunicao e gerncia do sistema; e o Science Data Processing Segment (SDPS) trata do armazenamento, processamento e distribuio dos dados. Em mais detalhe, o SDPS o componente do EOS responsvel por: aquisio de dados brutos; gerao de dados derivados a partir dos dados brutos; arquivamento e distribuio dos dados derivados aos usurios. O SDPS est organizado em sete subsistemas principais: Aquisio: recebe dados brutos e dispara processos para arquiv-los e process-los. Servidor de dados: fornece servios de arquivamento fsico e distribuio de dados, via FTP ou mdia removvel. Planejamento. fornece servios para planejamento das atividades. Processamento: executa os processos para gerao de dados derivados. Cliente: fornece uma interface para pesquisar e recuperar dados. Interoperabilidade: fornece servios para pesquisar e localizar servios de dados. Gerncia de dados: fornece servios para localizar e acessar dados. O projeto Misso ao Planeta Terra gera vrios Terabytes de dados diariamente e acumula um volume total de dados que chega a vrios Petabytes, em formatos prprios, coletivamente chamados HDF-EOS. Portanto, o armazenamento e disseminao dos dados gerados representa um substancial desafio. O projeto NASA HDF-EOS Web GIS Software Suite (NWGISS) (Di et al., 2001) visa exatamente tornar os dados gerados pelo EOSDIS disponveis a outras aplicaes que sigam as especificaes do OGC (ver Captulo 11 para um resumo dos padres definidos pelo OGC e mencionados nesta seo). A arquitetura do NWGISS (ver Figura 9.5) consiste de trs componentes principais: um servidor de mapas; um servidor de geo-campos (coverage server); e um servidor de catlogo. O NWGISS inclui ainda um cliente OGC WCS.
320
Cliente compatvel com OGC

Protocolos OGC
Interface integrada para servios OGC

Geo-campo Mapa Descrio Metadados
Servidor de geo-campos
Servidor de mapas
XML Capability
Servidor de catlogo
arquivos HDF-EOS
Gerador de descries
Catlogo
Figura 9.5 Arquitetura do NWGISS.
O servidor de mapas do NWGISS implementa os servios definidos no OGC WMS para todos os tipos de dados do formato HDF-EOS. Em particular, gera o geo-referenciamento do mapa em tempo de execuo, se necessrio. Da mesma forma, o servidor de geo-campos do NWGISS implementa os servios definidos no OGC WCS para trs formatos de dados, HDF-EOS, NITF e GeoTIFF. O servidor re-amostra, recorta e remonta geo-campos em tempo real, bem como transforma geo-campos de formato. O cliente de geo-campos do NWGISS implementa a especificao do cliente OGC WCS. O cliente atua como um mediador para acessar geocampos, nos formatos HDF-EOS, NITF e GeoTIFF, armazenados em servidores OGC WCS, no se limitando ao servidor OGC WCS implementado pelo NWGISS. O cliente permite acessar, visualizar, georetificar, re-projetar e reformatar geo-campos. Como mediador, o cliente NWGISS bastante limitado pois permite apenas selecionar geo-campos de mais de uma fonte, utilizando seus descritores, e visualiz-los em conjunto, entre outras operaes.
321
9.4
Mapeamentos entre fontes de dados
9.4.1 Estratgias para definio de mapeamentos Para interpretar e processar dados obtidos de diversas fontes, as aplicaes devem ser capazes de tratar dados heterogneos, tanto em formato e estrutura, quanto em interpretao ou significado. De fato, a heterogeneidade estrutural e semntica so problemas que bancos de dados distribudos vem enfrentando desde longa data (zsu e Valduriez, 1999). Uma primeira estratgia para resolver o problema de tratar dados heterogneos consiste em gerar mapeamentos entre pares de fontes de dados. Esta estratgia torna-se impraticvel quando o nmero de fontes aumenta, ou quando no se conhece priori as fontes disponveis. Uma segunda estratgia prope uma descrio comunitria dos dados, chamada esquema global ou federado, esquema mediado ou esquema de referncia, dependendo do enfoque adotado para atingir interoperabilidade (ver Seo 9.3.1). A esta descrio comunitria so ento mapeadas as descries das fontes de dados, chamadas de esquemas locais ou esquemas exportados, novamente dependendo do enfoque adotado. Esta estratgia simplifica o problema pois evita criar mapeamentos dois-a-dois entre os esquemas locais, mas ainda requer que as fontes sejam conhecidas priori. Uma terceira estratgia, proposta mais recentemente, adota ontologias para formalizar o esquema de referncia e os esquemas locais. Utiliza ainda tcnicas de alinhamento entre ontologias para simplificar a gerao dos mapeamentos (Wache et al., 2001) (Uschold e Grninger, 2001) (Mena et al. 2000). Por fim, a definio dos mapeamentos entre as descries locais e a descrio comunitria pode se beneficiar de uma anlise dos metadados das fontes. Porm, segundo Haas & Carey (2003), a inexistncia de metadados um dos motivos para o fracasso de tentativas para atingir interoperabilidade entre fontes de dados. Alm disso, metadados no necessariamente garantem a no ambigidade dos termos, pois um mesmo termo pode ser usado em diferentes contextos, em diferentes lnguas ou at mesmo de forma errnea. Uma possvel soluo seria
322
enfatizar o uso, uniforme e rigoroso, de metadados para completar a descrio dos conceitos pertinentes s fontes de dados. A prpria descrio comunitria pode atuar como um vocabulrio compartilhado, servindo de referencial priori para a definio dos esquemas locais (Brauner, 2005). 9.4.2 Exemplo de definio de mapeamentos Esta seo exemplifica questes compartilhadas pelas estratgias de federao, armazm de dados e mediao no que diz respeito definio de mapeamentos. Usaremos os termos esquema de referncia para designar a descrio comunitria das fontes de dados e esquema local para descrever os dados visveis em cada fonte de dados. Assumiremos que as descries contero definies de classes de objetos, denotando conjuntos, e de propriedades dos objetos, denotando funes mapeando objetos em objetos ou objetos em valores de dados. Adotaremos a notao de teoria de conjuntos quando necessrio. Desta forma, evitaremos escolher um particular modelo de dados para descrever os esquemas locais e o esquema de referncia. Um esquema local descreve as classes e propriedades dos dados que uma fonte deseja compartilhar, e o esquema de referncia descreve as classes e propriedades dos dados oferecidos aos usurios como uma viso unificada das fontes. O esquema de referncia contm ainda mapeamentos entre as classes e propriedades do esquema de referncia e as classes e propriedades de cada fonte. H dois problemas que devem ser tratados na definio dos mapeamentos: identificao de objetos: como definir uma forma universal de identificar os objetos nas vrias fontes e, em particular, como identificar a ocorrncia do mesmo objeto em fontes diferentes. transformao das propriedades: como re-mapear os valores das propriedades oriundos de uma ou mais fontes para o esquema de referncia, ou entre si. Como exemplo, considere duas fontes de dados, FA e FB, descrevendo aeroportos. Suponha que o esquema local EA da fonte FA contenha (onde
323
C o conjunto de caracteres adotado e denota o conjunto dos nmeros reais): (1) classes: Aeroporto propriedades: Cdigo: Aeroporto C3 Cidade: Aeroporto C50 Loc: Aeroporto 2 e que o esquema local EB da fonte FB contenha: (2) classes: Airport propriedades: Code: Airport C3 Name: Airport C20 Coord: Airport 2 Considere que o esquema de referncia ER contenha: (3) classes: R-Aeroporto propriedades: R-Cdigo: R-Aeroporto C3 R-Loc: R-Aeroporto 2 R-Nome: R-Aeroporto C20 Suponha que as propriedades Cdigo, de EA, e Code, de EB, de fato armazenem os cdigos universais dos aeroportos, com trs caracteres. O mapeamento entre ER, EA e EB pode ento ser definido, por exemplo, como: (4) R-Aeroporto = {xAeroporto / y(yAirport Cdigo(x) = Code(y))} (5) (xAeroporto)(R-Cdigo(x) = Cdigo(x)) (6) (xAeroporto)(R- Loc(x) = Loc(x)) (7) (xAeroporto)( R-Nome(x) = n (yAirport)(R-Cod(x) = Code(y) Name(y) = n)) Note que a sentena (4) indica que a classe R-Aeroporto de ER definida com base na classe Aeroporto de EA. Assim, um aeroporto s estar disponvel atravs do esquema de referncia se e somente se for um aeroporto cadastrado na fonte FA, por fora da forma como o mapeamento foi definido (ver sentena (4)). Portanto, um aeroporto cadastrado na fonte FB que no existir na fonte FA no ser visvel atravs de ER.
324
Assim, as sentenas (5) e (6) podem transferir diretamente as propriedades de aeroportos definidas em EA para o esquema de referncia ER. Note que, arbitrariamente, ER no contm a cidade do aeroporto. De fato, em geral, o esquema de referncia no a unio dos esquemas locais. A sentena (7) mais complexa pois a fonte FB pode conter aeroportos no cadastrados na fonte FA. Portanto, necessrio verificar se o aeroporto existe na fonte FA ao transferir a propriedade Name de EB para o esquema de referncia ER. Assuma agora que as propriedades Cdigo e Code no representem os cdigos universais dos aeroportos. Isto impediria identificar diretamente, via o cdigo, quando dois aeroportos nas fontes FA e FB so o mesmo aeroporto. No entanto, se assumirmos que as propriedades Loc e Coord contm as coordenadas dos aeroportos no mesmo sistema de georeferenciamento, ento podemos substituir a sentena (7) por: (8) (xAeroporto)( R-Nome(x) = n (yAirport)(Prox(Loc(x),Coord(y)) Name(y) = n)) onde Prox uma relao de proximidade espacial que verdadeira se e somente se dois pontos no espao tiverem as mesmas coordenadas dentro de uma certa tolerncia. De fato, a adoo de um sistema universal de geo-referenciamento oferece tambm um sistema universal de identificao de objetos geogrficos, ou pelo menos permite definir relacionamentos universais entre objetos geogrficos. Se assumirmos agora que as propriedades Loc e Coord contm as coordenadas dos aeroportos em sistemas de geo-referenciamento distintos, mas h suficiente informao nos metadados de Loc e Coord sobre os sistemas adotados, ento devemos substituir a sentena (7) por: (9) (xAeroporto)( R-Nome(x) = n (yAirport)(Prox(Remap(Loc(x)), Coord(y)) Name(y) = n)) onde Remap uma funo que re-mapeia as coordenadas dadas por Loc para o sistema de geo-referenciamento adotado para Coord. Este um exemplo simples do problema de transformao das propriedades, no contexto de dados geogrficos. A Seo 9.3.3 apresenta outros exemplos, quando discute a fase de transformao dos dados.
325
9.5
Construo de mediadores
9.5.1 Arquitetura de mediadores Conforme adiantado na Seo 9.3.1, uma particular estratgia para integrar um conjunto de fontes de dados heterogneas baseia-se na construo de um sistema de mediao com uma arquitetura em 3 camadas (ver Figura 9.6): Camada de Aplicao: compreende as aplicaes que desejam acessar as fontes. Camada de Mediao: contm um ou mais mediadores fornecendo servio de mediao para fontes de dados. Um mediador centraliza informaes fornecidas por adaptadores, criando um esquema mediado das fontes de dados. O mediador tambm decompe as consultas submetidas pelas aplicaes em consultas a serem executadas pelos adaptadores, e rene os resultados parciais para formar a resposta consulta original. Camada de Adaptao: contm os adaptadores responsveis pelo acesso s fontes de dados. Cada adaptador esconde a heterogeneidade da fonte de dados, tornando o acesso fonte transparente para o mediador. Para cada fonte de dados existe um adaptador que exporta algumas informaes sobre a fonte, tais como: seu esquema, informaes sobre seus dados e sobre seus recursos para processamento das consultas. Ao participar de um sistema de mediao, uma fonte de dados, atravs do seu adaptador, deve ser capaz de expor um esquema exportado, descrevendo os dados que deseja tornar visveis. Deve tambm oferecer servios que permitam: (1) processar consultas sobre o esquema exportado; (2) transformar os resultados locais para os padres definidos para intercmbio de dados no sistema de mediao; e (3) aceitar temporariamente dados externos, convertendo-os para o formato local. Por sua vez, o sistema de mediao deve ser capaz de expor um esquema mediado com a descrio comunitria dos dados, sobre o qual as aplicaes definiro consultas ao sistema. O sistema deve ser capaz de executar consultas definidas sobre o esquema mediado, aplicando as transformaes necessrias sobre os dados geogrficos, alm dos servios usuais para definio e controle da execuo de sub-consultas s fontes de
326
dados, combinao dos resultados e reestruturao dos dados convencionais. Esta seo aborda estes pontos em separado, seguindo (Gupta et al., 2000).
Camada de Aplicao
MediadorB MediadorA Camada de Mediao
Adaptador1
SGBD Relacional
Adaptador2
SGBD OO
Adaptador3
Sistema de arquivos
Camada de Adaptao
Figura 9.6 Arquitetura mediador-adaptador (Gupta et al., 2000). 9.5.2 Servios de adaptao
Acesso ao esquema exportado

Uma fonte de dados, atravs do seu adaptador, deve ser capaz de expor um esquema exportado, descrevendo os dados que deseja tornar visveis, e o mapeamento entre este esquema e o esquema mediado. No caso de dados geogrficos, o esquema exportado deve conter substancialmente mais informao para os atributos geogrficos, conforme discutido a seguir. Seja Q uma consulta sobre o esquema mediado. O mediador utiliza os esquemas exportados e os mapeamentos existentes no esquema mediado para selecionar fontes de dados e decompor Q em sub-consultas a serem enviadas s fontes selecionadas.
327
O processo de escolha das fontes dever levar em considerao o custo de converter os dados geogrficos armazenados em cada fonte para o formato adequado para processar a consulta. Diferentemente de dados convencionais, este custo poder ser bastante alto e variar substancialmente de fonte para fonte, inclusive quanto preciso do processo de converso. Portanto, cada esquema exportado e o esquema mediado devem conter informao adicional sobre os atributos geogrficos para subsidiar a deciso da escolha da fonte e da transformao necessria. Em geral, cada atributo geogrfico G deve estar associado a um esquema de representao, semelhante noo de measurement framework definida em (Chrisman, 1997). O esquema de representao de G pode associar dois tipos de informao a G: (1) metadados, de forma semelhante aos esquemas de metadados discutidos na Seo 9.2.3 em outro contexto; (2) outros atributos cujos valores so necessrios para interpretar o valor de G. O esquema de representao pode estar diretamente associado a G, ou ser herdado do objeto O ao qual G se aplica, ou da coleo de objetos a que pertence O. A Seo 9.5.4 apresenta exemplos do processamento de consultas em um mediador que utiliza esquemas de representao.
Processamento de consultas sobre o esquema exportado

Uma fonte de dados, atravs do seu adaptador, deve ser capaz de processar consultas sobre o esquema exportado, devolvendo os resultados no formato definido pelo mediador. O formato utilizado pelo mediador para passar uma consulta para o adaptador deve ser especificado priori, quando o sistema de mediao criado. Por exemplo, o sistema de mediao pode adotar o padro WFS, definido pela OGC (ver Captulo 11), que especifica como as consultas devem ser passadas para as fontes de dados.
Transformao de dados
Uma fonte de dados, atravs do seu adaptador, deve ser capaz de aplicar transformaes aos dados antes de envi-los ao mediador. A transformao mais bsica consiste em converter os dados locais para o formato de intercmbio de dados adotado pelo sistema de mediao. Por
328
exemplo, o sistema de mediao pode adotar o padro GML, definido pela OGC (ver Captulo 11), que especifica um formato de transporte para dados geogrficos. De forma geral, uma transformao de dados qualquer funo f: DnR em que os argumentos de f representam tanto dados armazenados na fonte, quanto parmetros governando a transformao a ser aplicada aos dados. Junto com a interface da transformao, o adaptador deve expor um modelo de custo, a ser utilizado pelo mediador ao montar o plano de processamento de uma consulta. Em geral, o modelo de custo captura a complexidade computacional da transformao, em funo dos parmetros de entrada e de uma estimativa do volume de dados recebidos como entrada e do volume de dados produzidos pela transformao. 9.5.3 Servios de mediao
Acesso ao esquema mediado

O mediador deve ser capaz de expor o esquema mediado s aplicaes, e fornecer meios para mant-lo. Em particular, deve permitir o cadastramento de uma nova fonte de dados, com seu esquema exportado e mapeamento para o esquema mediado. As questes levantadas pela exposio do esquema mediado s aplicaes so semelhantes quelas relativas exposio do esquema exportado. Em particular, o esquema mediado deve associar cada atributo geogrfico G a um esquema de representao.
Processamento de consultas sobre o esquema mediado

Um mediador deve ser capaz de processar consultas sobre o esquema mediado, devolvendo os resultados nos formatos solicitados pelas aplicaes. O mediador executa os seguintes passos ao processar uma consulta Q definida sobre o esquema mediado:
329
Seleo de fontes: baseando-se nos mapeamentos armazenados no esquema mediado e nos atributos utilizados na consulta, o mediador seleciona conjuntos de fontes capazes de produzir o resultado da consulta. Otimizao: para cada conjunto de fontes, o mediador utiliza os mapeamentos do esquema mediado para criar um plano, contendo sub-consultas de tal forma que cada uma possa ser inteiramente processada por uma fonte no conjunto, e que juntas produzam o resultado da consulta original. o mediador estima o custo de processamento de cada plano e escolhe o de menor custo estimado. Execuo: o mediador controla a execuo do plano escolhido no passo de otimizao. Outras estratgias mais sofisticadas envolvendo transferncias temporrias de dados de uma fonte para outra, por exemplo, podem ser definidas de forma similar s estratgias de otimizao de consultas utilizadas em um banco de dados distribudo (zsu e Valduriez, 1999).
Servios adicionais
Um mediador pode utilizar as informaes sobre as fontes de dados que armazena para oferecer servios adicionais s aplicaes. Um primeiro exemplo de servio adicional seria prover uma interface abrangente para que os usurios ou aplicaes possam explorar o esquema mediado, incluindo os metadados mantidos sobre as fontes de dados. Desta forma, o mediador atuaria de forma semelhante a um catlogo de metadados, conforme ilustrado na Seo 9.3.2 e discutido em detalhe (Brauner, 2005). Um exemplo deste tipo de servio adicional, designado por processamento cooperativo de consultas, consistiria em aplicar transformaes nas consultas submetidas para: corrigir as consultas; resolver ambigidades; gerar consultas alternativas, quando a consulta
330
submetida falha; fornecer explicaes sobre as respostas; complementar as consultas fornecendo informao adicional explicitamente solicitada. 9.5.4 Exemplos de processamento de consultas sobre o esquema mediado Considere duas fontes de dados, FA e FB, descrevendo aeroportos. Suponha que os esquemas sejam definidos da seguinte forma: (10) Esquema exportado por FA: classes: Aeroporto propriedades: Cdigo: Aeroporto C3 Cidade: Aeroporto C50 Loc: Aeroporto 2 Rudo: Aeroporto 22 onde Cdigo o cdigo universal de 3 letras identificando os aeroportos nos diversos pases; Rudo(x) associa um geo-campo vetorial a cada aeroporto x representando o nvel de rudo no entorno do aeroporto, e armazenado como uma grade regular de amostras pontuais (indicado na funo apenas como um conjunto de pontos no 2 , assumindo que o espaamento da grade o mesmo para todos os aeroportos); (11) Esquema exportado por FB: classes: Airport propriedades: Code: Airport C3 Name: Airport C20 Coord: Airport 2 Noise: Airport (2) onde Code um cdigo prprio da fonte FB (ou seja, no o cdigo universal); Noise(x) associa um geo-campo vetorial a cada aeroporto x representando o nvel de rudo no entorno do aeroporto, e
331
armazenado como curvas de nvel (representadas como elementos do conjunto (2)); (12) Esquema mediado EM : classes: R-Aeroporto propriedades: R-Cdigo: R-Aeroporto C3 R-Loc: R-Aeroporto 2 R-Nome: R-Aeroporto C20 R-Rudo: R-Aeroporto 22 () onde R-Rudo(x) = (g,c) se e somente se g for a grade regular com amostras de rudo do aeroporto x, dada pela fonte FA, e c for a curva de nvel do rudo do aeroporto x, se este for cadastrado na fonte FB, ou for o conjunto vazio, em caso contrrio: Considere ainda os seguintes mapeamentos, idnticos aos da Seo 9.4.2: (13) R-Aeroporto = {xAeroporto / y(yAirport Cdigo(x) = Code(y))} (14) (xAeroporto)(R-Cdigo(x) = Cdigo(x)) (15) (xAeroporto)(R- Loc(x) = Loc(x)) (16) (xAeroporto)(R-Nome(x) = n (yAirport)(Prox(Remap(Loc(x)), Coord(y)) Name(y) = n)) e um ltimo mapeamento capturando o significado pretendido para RRudo: (17) (xAeroporto)(R-Rudo(x) = (Rudo(x),c) ((yAirport)(Prox(Remap(Loc(x)), Coord(y))) c = Noise(y))) (yAirport)(c = ))) Considere a seguinte consulta: Q1 : Qual o nome e a localizao do aeroporto com cdigo GIG? O mediador proceder ento da seguinte forma: Seleo de fontes: de (14), (15) e (16), o mediador necessita acessar as duas fontes.
332
Otimizao: novamente de (14), (15) e (16), o mediador decompe Q1 em duas sub-consultas, Q1A e Q1B, a serem enviadas a FA e FB, respectivamente: Q1A : Selecione a localizao p=Loc(x) do aeroporto x tal que Cdigo(x)=GIG Q1B : Selecione o nome n=Name(y) do aeroporto y tal que Prox(p, (Coord(y))) considere um nico plano: P1 : Envie Q1A fonte FA; Espere o resultado contendo a localizao p do aeroporto; Re-mapeie a localizao p para o sistema adotado na fonte FB, gerando uma nova representao p da localizao do aeroporto. Envie Q1B fonte FB; Espere o resultado contendo o nome n do aeroporto; Devolva a resposta (n,p); Execuo: o mediador executa o plano P1. Esta breve descrio deixa em aberto um ponto importante. necessrio que o mediador tenha acesso ao esquema de representao de Loc e Coord para que possa re-mapear p do sistema de georeferenciamento de FA para o sistema de FB. Da mesma forma, o adaptador da fonte FB, ou a prpria fonte FB, deve ter acesso ao esquema de representao de Coord para poder computar apropriadamente o relacionamento Prox. Caso este segundo problema no possa ser resolvido por FB ou seu adaptador, o mediador deve gerar um plano alternativo, substituindo a qualificao Prox(p, (Coord(y))) por dist(p, (Coord(y))<k, onde o mediador decide o valor de k a partir dos esquemas de georeferenciamento de Loc e Coord. Considere agora a seguinte consulta: Q2 : Obtenha o nvel de rudo, em curvas de nvel, do aeroporto na localizao p.
333
O mediador proceder ento da seguinte forma: Seleo de fontes: de (17), o mediador pode acessar qualquer uma das duas fontes. Otimizao: novamente de (17), h pelo menos 4 planos possveis. O primeiro plano acessa a fonte FA atravs da consulta: Q2A1 : Selecione o nvel de rudo C=Rudo(x) do aeroporto x tal que Loc(x)=p O plano consiste de: P2A1 : Envie Q2A1 fonte FA; Espere o resultado contendo o nvel de rudo C do aeroporto; Transforme (no mediador) C para curvas de nvel C; Devolva a resposta C; O segundo plano acessa a fonte FA atravs da consulta, que j inclui a transformao: Q2A2 : Selecione o nvel de rudo C=Rudo(x) do aeroporto x tal que Loc(x)=p, re-mapeando-o para curvas de nvel O plano consiste de: P2A2 : Envie Q2A2 fonte FA; Espere o resultado contendo o nvel de rudo C do aeroporto; Devolva a resposta C; O terceiro plano acessa a fonte FB atravs da consulta: Q2A1 : Selecione o nvel de rudo D=Noise(x) do aeroporto x tal que Coord(x)=p O plano consiste de: P2B1 : Re-mapeie p para p no sistema adotado em FB; Envie Q2B1 fonte FB; Espere o resultado com o nvel de rudo C do aeroporto; Se existir, devolva C como resposta; Caso contrrio, execute o plano P2A; O quarto plano acessa a fonte FB atravs da consulta: Q2A2 : Selecione o nvel de rudo D=Noise(x) do aeroporto x tal que Coord(x)=Remap(p)
Leituras Suplementares
334
O plano consiste de: P2B2 : Envie Q2B2 fonte FB; Espere o resultado com o nvel de rudo C do aeroporto; Se existir, devolva C como resposta; Caso contrrio, execute o plano P2A1 (ou o plano P2A2); o mediador deve estimar o custo de processar os planos e escolher um deles. Execuo: execute o plano escolhido no passo de otimizao. Novamente, a descrio deixa vrios pontos em aberto. Por exemplo, os planos P2A1 e P2A2 diferem na capacidade do mediador e do adaptador de FA transformarem o geo-campo armazenado em FA de uma grade regular para curvas de nvel. Dependendo da capacidade de cada um destes componentes, um dos dois planos prevalecer. Alm disto, esta transformao pode ser muito mais cara do que tentar acessar diretamente a curva de nvel armazenada em FB, mesmo correndo o risco de no encontrar o aeroporto em FB e ter que recorrer a FA de qualquer maneira. Portanto, os planos P2B1 e P2B2 podem ser muito mais eficientes do que os primeiros dois planos. Da mesma forma, os planos P2B1 e P2B2 diferem em qual componente realizar a converso de p para o sistema de geo-referenciamento adotado por FB. Em qualquer um dos casos, novamente necessrio que o mediador tenha acesso aos esquemas de representao de Rudo e Noise para decidir qual dos planos vivel, ou de menor custo. 9.6 Leituras Suplementares Recomenda-se inicialmente um estudo da srie de padres relativos a dados geogrficos publicados pela International Standards Organization (ISO): ISO 19115 Geographic Information Metadata standard ISO 19107:2003 Geographic Information Spatial Schema
335
ISO 19109 Geographic Information Rules for Application Schema ISO 19110 Geographic Information Methodology for Feature Cataloguing ISO 19111:2003Geographic Information Spatial Referencing by Coordinates ISO 19112:2003 Geographic Information Spatial Referencing by Geographic Identifier
Em particular, o ISO 19115 define um esquema de metadados para descrever informao geogrfica e servios. O modelo em UML deste padro est disponvel como o ISO TC211 Harmonized Model. Estes padres podem ser encontrados sob forma de ontologias em Islam et. al. (2004). H vrias ontologias bastante interessantes definindo vocabulrios geogrficos. Duas delas merecem destaque: CYC Geographic Vocabulary, disponvel em: http://www.cyc.com/cyc-2-1/vocab/geography-vocab.html Alexandria Digital Library Feature Type Thesaurus, disponvel em: http://www.alexandria.ucsb.edu/gazetteer/FeatureTypes/ver07030 2/index.htm) Descries de vrias arquiteturas e tecnologias para facilitar a integrao e interoperabilidade entre fontes de dados geogrficos podem ser encontradas na literatura. Abordagens gerais para o problema de integrao e interoperabilidade cobrem desde catlogos de dados geogrficos a mediadores capazes de processar consultas a fontes distintas (Abel, 1998) (DeVogele et al., 1998) (Bishr, 1998) (Laurini, 1998) (Jacobsen e Voisard, 1998) (Bergmann et al., 2000) (Tanin et al., 2002). Enfoques baseados em XML ou em Web services podem ser encontrados em (Gupta et al., 1999) (Gupta et al., 2000) (Alameh, 2003) (Manpuria et al., 2003). H inmeras iniciativas baseadas nos padres do OGC, como (Boucelma et al., 2002) (Essid et al., 2004), para citar algumas referncias. Mais recentemente, vrias abordagens para construo de mediadores baseadas em ontologias foram propostas na tentativa de explorar o maior poder de expresso das linguagens para
336
descrever ontologias e as tecnologias para alinhamento de ontologias (Mena et al., 2000) (Wiegand e Zhou, 2001) As reas de armazm de dados e minerao de dados espaciais merecem ateno especial pelo potencial das aplicaes. Um ponto de partida o livro texto de Miller e Han (2001).
337
Referncias
ABEL, D. J.; OOI, B. C.; TAN, K.-L.; TAN, S. H. Towards integrated geographical information processing. International Journal of Geographical Information Science, v. 12, n.4, p. 353-371, 1998. ALAMEH, N. Chaining Geographic Information Web Services. IEEE Internet Computing archive, v. 7, n.5, p. 22-29, 2003. ATKINSON, R. F., J., 2002, Gazetteer Service Profile of the Web Feature Service Implementation Specification, Open Geoscience Consortium. BARCLAY, T.; GRAY, J.; SLUTZ, D. Microsoft TerraServer: A Spatial Data Warehouse. ACM SIGMOD Record, v. 29, n.2, p. 307-318, 2000. BERGMANN, A.; BREUNIG, M.; CREMERS, A. B.; SHUMILOV, S. Towards an Interoperable Open GIS. In: International Workshop on Emerging Technologies for Geo-Based Applications. Ascona, Switzerland, 2000. p. 283-296. BISHR, Y. Overcoming the semantic and other barriers to GIS interoperability. International Journal of Geographical Information Science, v. 12, n.4, p. 299-314, 1998. BOUCELMA, O.; LACROIX, Z. E. M. A WFS-Based Mediation System for GIS Interoperability. In: 10th ACM international Symposium on Advances in Geographic Information Systems. McLean, VA, USA, 2002. p. 23-28. BRAUNER, D. F. Uma Arquitetura para Catlogos de Objetos baseados em Ontologias. Rio de Janeiro: Pontifcia Universidade Catlica do Rio de Janeiro, 2005.Departamento de Informtica., 2005. DEVOGELE, T. P., C.; SPACCAPIETRA, S. On spatial database integration. International Journal Geographical Information Science, v. 12, n.4, p. 335352, 1998. DI, L.; YANG, W.; DENG, M.; DENG, M.; MCDONALD, K. The prototype NASA HDF-EOS Web GIS Software Suite (NWGISS). In: NASA Earth Science Technologies Conference. Greenbelt, Maryland, USA, 2001. p. ESSID, M.; BOUCELMA, O.; COLONNA, F. M.; LASSOUED, Y. Query Processing in a Geographic Mediation System. In: 12th Annual ACM International Workshop on Geographic Information Systems. ACM Press New York, Washington DC, USA, 2004. p. 101-108. FEDERAL GEOGRAPHIC DATA COMMITTEE (FGDC). Content Standard for Digital Geospatial Metadata WorkBook. Reston, VA. Disponvel em: <http://www.fgdc.gov/metadata/constan.html>.
Referncias
338
FONSECA, F.; EGENHOFER, M.; BORGES, K. Ontologias e Interoperabilidade Semntica entre SIGs. In: Workshop Brasileiro em Geoinformtica (GeoInfo2000), 2., So Paulo, 2000. Anais. So Jos dos Campos: INPE, 2000. p. 45 - 52. FREW, J.; FREESTON, M.; FREITAS, N.; HILL, L.; JANE, G.; LOVETTE, K.; NIDEFFER, R.; SMITH, T.; ZHENG, Q. The Alexandria Digital Library architecture. International Journal on Digital Libraries, v. 2, n.4, p. 259-268, 2000. GARDELS, K. The Open GIS Approach to Distributed Geodata and Geoprocessing. In: Third International Conference/Workshop on Integrating GIS and Environmental Modeling. Santa Fe, NM, USA, 1996. p. 21-25. GUARINO, N. Formal ontology and information systems. Amsterdam, Netherlands: IOS Press, 1998, p.3-15. GUPTA, A.; MARCIANO, R.; ZASLAVSKY, I.; BARU, C. Integrating GIS and Imagery through XML-Based Information Mediation. In: International Workshop on Integrated Spatial Databases. Portland, ME, USA, 1999. p. 211. GUPTA, A.; ZASLAVSKY, I.; MARCIANO, R. Generating Query Evaluation Plans within a Spatial Mediation Framework. In: 9th International Symposium on Spatial Data Handling. Beijing, China, 2000. p. 8a18-8a31. HAAS, L.; CAREY, M. Will federated databases ever go anywhere? In: Lowell Database Research Self-Assessment Meeting. Lowell, Massachusetts, USA, 2003. ISLAM, A.S.; BERMUDEZ, L.; BERAN, B; FELLAH, S.; PIASECKI, M, Ontologies for ISO Geographic Information Standards. http://loki.cae.drexel.edu/~wbs/ontology/2004/09/bug/iso-19115/index.htm JACOBSEN, A. H.; VOISARD, A. CORBA Based Open Geographic Information Systems. In: European Conference on Parallel and Distributed Systems. 1998. p. KOBLER, B.; BERBERT, J.; CAULK, P.; HARIHARAN, P. C. Architecture and design of storage and data management for the NASA Earth observing system Data and Information System (EOSDIS). In: 14th IEEE Symposium on Mass Storage Systems. Monterey, California, USA, 1995. p. 65. LAURINI, R. Spatial multi-database topological continuity and indexing: a step towards seamless GIS data interoperability. International Journal of Geographical Information Science, v. 12, n.4, p. 373-402, 1998. MANPURIA, V.; ZASLAVSKY, I.; BARU, C. Web Services for Accuracy-Based Spatial Query Rewriting in a Wrapper-Mediator System. In: Fourth
339
International Conference on Web Information Systems Engineering Workshops (WISEW'03). Rome, Italy, 2003. p. 63-71. MAPINFO, MapInfo Professional User's Guide - Appendix J: MapInfo Interchange Format. [online] <www.mapinfo.com/community/free/ library/interchange_file.pdf>. Mar. 2001. MAPINFO, MapInfo Professional.GIS Software. Troy, New York, 2002. MARC, 1976, A MARC Format, in OFFICE, L. O. C. M. D., ed., Washington, D.C., Library of Congress Information Systems Office. MENA, E.; ILLARRAMENDI, A.; KASHYAP, V.; SHETH, A. OBSERVER: An Approach for Query Processing in Global Information Systems based on Interoperation across Pre-existing Ontologies. International Journal on Distributed And Parallel Databases (DAPD), v. 8, n.2, p. 223-272, 2000. MILLER, J. H.; HAN, J. Geographic Data Mining and Knowledge Discovery. Bristol, PA, USA: Taylor & Francis, Inc., 2001. NATIONAL SPATIAL DATA INFRASTRUCTURE (NSDI). Geospatial Metadata. Disponvel em: <http://www.fgdc.gov/publications/documents/ metadata/metafact.pdf>. NEBERT, D., 2002, Catalog Services Specification, Version 1.1.1, OpenGIS Implementation Specification, Open Geoscience Consortium. ZSU, M. T.; VALDURIEZ, P. Principles of distributed database systems. Prentice-Hall, Inc., 1999. SHETH, A.; LARSON, J. Federated database systems for managing distributed, heterogeneous and autonomous databases. ACM Computing Surveys, v. 22, n.3, p. 183-236, 1990. SMITH, T. R. A Digital Library for Geographically Referenced Materials. IEEE Computer, v. 29, n.5, p. 54-60, 1996. SMITH, T. R.; FREW, J. Alexandria Digital Library. Communications of the ACM, v. 38, n.4, p. 61-62, 1995. SPRING - Sistema de Processamento de Informaes Georreferenciadas. Verso 3.5. [S.I.]: Instituto Nacional de Pesquisas Espaciais (INPE), 2001. 1 CDROM. TANIN, E.; BRABEC, F.; SAMET, H. Remote Access to Large Spatial Databases. In: 10th ACM International Symposium on Advances in Geographic Information Systems. McLean, Virginia, USA, 2002. p. 5-10. THOM, R. Interoperabilidade em geoprocessamento: Converso entre modelos conceituais de sistemas de informao geogrfica e comparao
Referncias
340
com o padro OpenGIS. 1998. 196 f. (INPE-7266-TDI/708). Dissertao (Mestrado em Computao Aplicada) Instituto Nacional de Pesquisas Espaciais, 1998. USCHOLD, M.; GRNINGER, M. Ontologies: Principles, methods and applications. Knowledge Engineering Review, v. 11, n.2, p. 93 -155, 2001. USMARC, 1976, A MARC Format, in OFFICE, L. O. C. M. D., ed., Washington, D.C., Library of Congress Information Systems Office. VOISARD, A.; SCHWEPPE, H. Abstraction and Decomposition in Interoperable GIS. International Journal of Geographic Information Science, v. 12, n.4, p. 315 - 333, 1998. WACHE, H.; VGELE, T.; VISSER, U.; STUCKENSCHMIDT, H.; SCHUSTER, G.; NEUMANN, H.; HBNER, S. Ontology-Based Integration of Information A Survey of Existing Approaches. In: IJCAI-01 Workshop: Ontologies and Information Sharing. Seattle, WA, USA, 2001. p. 108 -117. WIEGAND, N.; ZHOU, N. Ontology-Based Geospatial XML Query System. In: 4th AGILE Conference on Geografical Information Science. 2001.
10 Disseminao de dados geogrficos na Internet

Clodoveu A. Davis Jr. Ligiane Alves de Souza Karla A. V. Borges
10.1 Introduo Este captulo explora diversas possibilidades de disseminao de dados geogrficos atravs da Internet. Apresenta inicialmente a arquitetura de trs camadas, tpica de sistemas de informao baseados na Web. Em seguida, discute as trs principais formas de disseminao de dados geogrficos: (1) a disseminao direta, usando caractersticas grficas tpicas dos browsers, complementadas ou no por ferramentas e recursos adicionais; (2) as bibliotecas digitais de informaes geogrficas; e (3) uma viso da emergente rea de infra-estruturas de dados espaciais. Por fim, tece algumas consideraes finais, destacando principalmente o outro lado da disseminao de dados geogrficos na Internet: os mecanismos de busca voltados para localizao e dados geogrficos. A Internet rapidamente se tornou o meio preferencial para disseminao de dados. Sua (quase) universalidade, associada a custos de acesso cada vez mais baixos, motivou o desenvolvimento de toda uma nova classe de sistemas de informao, com uma arquitetura diferenciada em relao a seus predecessores. Esse movimento se estende aos dados geogrficos: atualmente, todos os principais fornecedores de software para SIG dispem de alternativas para acesso a dados geogrficos atravs da Web. Apesar dessa forte tendncia, constata-se uma grande variedade de estilos de implementao, recursos tecnolgicos e arquiteturas internas das solues, cada qual refletindo um conjunto de preocupaes e voltada para um nicho de aplicao mais ou menos especfico.
342
De forma coerente com a multiplicidade cultural da Internet, todas as alternativas encontram-se em uso, cada qual em seu nicho; no se pode apontar uma nica alternativa tecnolgica vencedora, ou preponderante sobre todas as demais. Existe ainda muito espao para a expanso dessa rea de conhecimento e do mercado dela decorrente. 10.2 Arquitetura de sistemas de informao baseados na Web A arquitetura dos SGBD acompanhou, de modo geral, as tendncias de descentralizao e modularizao observadas nas arquiteturas de hardware (Elmasri e Navathe, 2004). Na era dos mainframes, os SGBD eram igualmente monolticos, incluindo todas as funes de acesso aos dados no mesmo ambiente em que eram processadas as aplicaes e produzidas as telas de interface com o usurio. Com a queda dos preos dos equipamentos e ascenso dos computadores pessoais, passamos a ter a possibilidade de transferir parte do processamento para um equipamento que era, anteriormente, um mero terminal burro. Isso levou ao desenvolvimento da arquitetura cliente/servidor, inicialmente concebida no apenas para o gerenciamento de dados, mas para que se pudesse dispor de mquinas capazes de prestar qualquer tipo de servio especializado em uma rede de computadores, tais como gerenciamento de impresso, de arquivos, de backup, entre outros (Figura 10.1). Nessa arquitetura, os processos relacionados com o acesso do usurio aos servios so chamados processos cliente, enquanto os processos que lidam com os recursos especializados so denominados processos servidor. Observe que essa denominao frequentemente confundida com a designao de computadores de maior ou menor porte o que s vezes se justifica pois, na maioria dos casos, equipamentos encarregados de executar processos servidores para uma grande quantidade de processos cliente precisariam, em princpio, ser mais robustos e poderosos.
Arquitetura de sistemas de informao baseados na Web
343
Cliente
Cliente Rede Local
Cliente
Cliente
Servidor de impresso
Servidor de arquivos
Servidor de backup
Figura 10.1 Arquitetura cliente/servidor (2 camadas). Fonte: adaptado de (Elmasri e Navathe, 2004).
A arquitetura cliente-servidor adapta-se bem s necessidades de SGBD, e est hoje totalmente incorporada aos produtos comerciais. Nesse caso, o servidor de banco de dados prov, como servio, respostas a consultas enviadas por processos cliente. Por esse motivo, em SGBD relacionais, o servidor de banco de dados tambm denominado servidor de consultas, ou servidor SQL (Elmasri e Navathe, 2004). Assim, de acordo com a arquitetura cliente-servidor aplicada aos SGBD, a camada do cliente fica com as funes de gerenciamento da interface com o usurio, de dicionrio de dados, de interfaceamento com linguagens de programao, entre outras, em um nvel mais alto. A camada do servidor gerencia as funes de armazenamento em disco, controle de concorrncia, backup e recuperao de dados, e outras funes de mais baixo nvel (Figura 10.2). Entre essas duas camadas, a comunicao ocorre por meio do estabelecimento de uma conexo atravs da rede. Uma das alternativas para essa conexo o uso de um padro de conectividade, denominado Open Database Connectivity (ODBC), que neutraliza, por meio de uma interface comum de programao (ou API, Application Programming Interface), as diferenas entre os diversos programas envolvidos, desta forma evitando a incompatibilidade. Um padro de conectividade
344
semelhante, denominado JDBC, foi criado para que clientes escritos na linguagem Java pudessem tambm acessar os SGBD por meio de uma interface padronizada.
Cliente
Cliente Rede Local
Cliente
Cliente
Servidor de Banco de Dados
Servidor de Banco de Dados
Figura 10.2 Arquitetura cliente/servidor aplicada a SGBD. Fonte: adaptado de (Elmasri e Navathe, 2004).
A arquitetura cliente-servidor original tem sido denominada arquitetura de duas camadas, j que seus componentes esto logicamente distribudos entre dois nveis, o do cliente e o do servidor. A simplicidade e a facilidade de adaptao de arquiteturas anteriores para o funcionamento em duas camadas justificam sua grande popularidade. Por outro lado, sua escalabilidade pode deixar a desejar, caso exista a necessidade de se ter um nmero muito grande de clientes para um servidor. Isso levou proposio e implementao da arquitetura de trs camadas, tipicamente empregada em sistemas baseados na Web. A arquitetura de trs camadas acrescenta, entre a camada do cliente e a camada do servidor, uma camada intermediria, que recebe o nome de middleware, ou servidor de aplicaes (application server) (Figura 10.3). Em bancos de dados, essa camada responsvel por manter regras de negcio, restries e outros elementos necessrios para a aplicao. Desta forma, a as trs camadas so compostas, basicamente, de interface com o usurio
Disseminao direta
345
(cliente), regras de negcio (aplicao) e acesso a dados (servidor). Como um servidor de aplicao pode tambm controlar o acesso de usurios aos dados, e rotear as requisies para algum servidor selecionado por ele sem a interferncia do usurio, a arquitetura de trs camadas possibilita melhorar sensivelmente a escalabilidade dos sistemas de informao apoiados em um SGBD.
Camada 1 Cliente: interface humano-computador, browser
Camada 2 Servidor de aplicao ou servidor Web: programas aplicativos, regras de negcio, pginas Web
Camada 3 Servidor de bancos de dados: SGBD, armazenamento
Figura 10.3 Arquitetura de trs camadas. Fonte: adaptado de (Elmasri e Navathe, 2004).
10.3 Disseminao direta A World-Wide Web (Web) foi originalmente concebida, de forma bastante despretensiosa para os padres atuais, para trabalhar com documentos contendo texto, e eventualmente imagens (Berners-Lee et al., 1994). De fato, alm da possibilidade de navegao usando hipertexto, os primeiros clientes de servidores Web os hoje onipresentes browsers permitiam apenas a apresentao de imagens simples, em formato GIF ou JPEG. O protocolo HyperText Transfer Protocol (HTTP) e a linguagem de
346
marcao HyperText Markup Language (HTML), base do funcionamento da Web, permitem a elaborao, o preenchimento online e o envio do contedo de formulrios de cliente para servidor, provendo assim alguma interatividade, embora bem mais limitada que os recursos usualmente encontrados em aplicaes grficas convencionais. Ao longo da evoluo da Web, algumas alternativas para acesso a dados geogrficos foram sendo implementadas dentro dessas limitaes. A evoluo dos padres ligados Internet, capitaneados pelo World-Wide Web Consortium (W3C)1, acompanhados pela evoluo tecnolgica na rea de sistemas distribudos, possibilitou uma enorme ampliao dessas alternativas, em particular aps o surgimento da linguagem Java (Sun Microsystems, 1994). Apresentamos, nas subsees a seguir, as principais alternativas utilizadas histrica e atualmente para disseminao de dados geogrficos atravs da Web. 10.3.1 Mapas estticos em formato de imagem A forma mais bsica de disseminao de dados geogrficos na Web , naturalmente, a publicao de mapas estticos em formato de imagem, embutidas em pginas Web. Apesar de a interatividade ser nula, possvel produzir e manter disponveis, para consulta e referncia histrica, grandes conjuntos de mapas temticos. A existncia de documentos eletrnicos contendo mapas estticos possibilita o desenvolvimento de esforos de preservao (Thomaz, 2004) independentes dos bancos de dados de onde (espera-se) eles tenham se originado. A Figura 10.4 apresenta um exemplo de uso dessa alternativa.
http://www.w3c.org
Disseminao direta
347
Figura 10.4 Mapa esttico, publicado em formato JPEG. Fonte: Web site do Ministrio dos Transportes (www.transportes.gov.br).
10.3.2 Mapas gerados a partir de formulrios Muito adotada na segunda metade da dcada de 1990, esta alternativa consiste em oferecer ao usurio um formulrio para preenchimento. Neste formulrio so solicitadas informaes quanto regio geogrfica de interesse (muitas vezes solicitando uma referncia explcita a um nmero de mapa em uma coleo ou articulao), composio do mapa (camadas que deveriam aparecer) e mesmo alguns elementos de composio visual (cores, espessura de linhas, cores ou hachuras de preenchimento). Quando o usurio termina o preenchimento do formulrio, as informaes so transmitidas a um servidor, que recupera os dados necessrios e converte o mapa final para um formato de imagem, como GIF ou JPEG. Esta imagem ento inserida numa pgina Web criada dinamicamente, e transmitida para o usurio. Considerando um nvel mnimo de interatividade, esta alternativa talvez a mais natural do ponto de vista dos browsers, uma vez que requer apenas a apresentao de imagens. No entanto, uma alternativa limitada, por diversos motivos. Em primeiro lugar, porque no permite que o usurio navegue pelo mapa, interagindo diretamente com os objetos apresentados, sem que haja a necessidade de re-gerao da imagem. Alm disso, a transmisso de imagens apresenta um compromisso entre
348
tamanho, qualidade e resoluo, por um lado, e a velocidade de transmisso, pelo outro. Por fim, existe o problema de sobrecarga no servidor, que precisa construir o mapa em formato matricial, muitas vezes a partir de dados vetoriais, e transmiti-lo para o cliente. Este ltimo fator claramente reduz a escalabilidade dessa soluo. Observe que qualquer operao simples, como zoom ou pan, exige a formao de um novo mapaimagem (sempre com processamento no servidor) e nova transmisso. Um exemplo desse tipo de recurso est apresentado parcialmente na Figura 10.5, referente a um gerador de mapas do United States Geological Survey (USGS). Alm de prover as coordenadas de um retngulo envolvente para a rea que deseja visualizar, o usurio deve decidir sobre (1) acrescentar ou no uma borda ao redor da rea escolhida, (2) a maneira de lanar pontos sobre o mapa, (3) a incluso ou no de dados topogrficos, (4) o lanamento de texto sobre o mapa, indicando as coordenadas onde faz-lo, (5) a incluso ou no de limites polticos, e (6) a incluso ou no de rios. Apenas ento o usurio pode clicar um boto e disparar o processo de montagem da imagem.
Figura 10.5 Mapa baseado em formulrio. Fonte: http://stellwagen.er.usgs.gov/mapit/. O gerador de mapas baseado na biblioteca de cdigo aberto GMT (http://gmt.soest.hawaii.edu/).
Disseminao direta
349
10.3.3 Navegao baseada em mapas-chave Outra alternativa para acesso a dados geogrficos na Web a que apresenta para o usurio um mapa chave, em formato de imagem. O usurio deve indicar com o mouse uma regio de seu interesse, gerando uma navegao para outro mapa ou imagem mais detalhado, ou clicar em cones perifricos imagem para navegar para regies adjacentes, mantendo a escala de visualizao. Eventualmente, podem existir cones que ativam funes mais sofisticadas, como medio na tela, identificao de elementos ou ativao/desativao de camadas. Esta abordagem permite um grau um pouco maior de flexibilidade, mas no resolve os problemas principais da alternativa anterior, ou seja, custos de processamento e transmisso, alm de no resolver completamente o problema de navegao. O grau de interatividade com o usurio baixo, j que, nesse modelo, no h interao direta entre o usurio e um banco de dados propriamente dito, apenas com o que seria a materializao, em formato de imagem, de um instantneo (snapshot) de parte do contedo do banco. No exemplo apresentado na Figura 10.6, a barra de atividade que aparece no centro da tela indica que o servidor est compilando o mapa em formato de imagem para envio ao cliente, na prxima etapa da interao.
Figura 10.6 Navegao baseada em mapas-chave. Fonte: Web site do IBGE, servidor de mapas (www.ibge.gov.br).
350
Outro exemplo apresentado na Figura 10.7, este o mapa digital do municpio de Porto Alegre, desenvolvido usando o software gratuito e de fonte aberto MapServer (mapserver.gis.umn.edu). A Figura 10.7a apresenta uma tela inicial, em que o usurio informa parmetros para uma consulta. O resultado aparece na Figura 10.7b.
(a)
(b)
Figura 10.7 Mapa digital oficial de Porto Alegre, desenvolvido com MapServer.
10.3.4 Transmisso de dados vetoriais Uma alternativa mais interessante do que a transmisso de imagens a transmisso de objetos geogrficos com representao vetorial. Desta maneira, o usurio fica livre para decidir a regio de interesse, bem como para ativar ou desativar as camadas que deseja. Os objetos vetoriais transmitidos so mantidos na memria da mquina cliente, para que possam ser reaproveitados no caso de operaes de zoom ou pan, ganhando tempo para aumentar a interatividade. O usurio pode tambm interagir diretamente com os objetos do mapa, consultando atributos e acessando funes de atualizao de dados. Outra possibilidade interessante a aplicao ao mapa vetorial do conceito de hipermapa, simulando nos smbolos e objetos vetoriais disponveis a operao dos links de hipertexto comuns nas pginas da Web. Por exemplo, bastaria clicar sobre o smbolo de um hospital num
Disseminao direta
351
mapa urbano para consultar seus atributos associados, ou para navegar diretamente para a pgina do hospital na Internet. A transmisso de dados geogrficos em formato vetorial pela Internet tem um obstculo: nenhum dos browsers atuais est preparado (nativamente) para receber e apresentar informaes neste formato. Para que isso seja possvel, existem duas alternativas. A primeira, adotada por alguns desenvolvedores de SIG, consiste em criar um plug-in, ou seja, um programa que funciona no computador do usurio, conectado ao browser. Este plug-in reconhece os dados vetoriais medida em que chegam, geralmente agrupados em um arquivo com formato padronizado, ou usando um formato especfico de codificao de objetos, e os exibe na tela. Esta alternativa tem a desvantagem de exigir que o usurio faa o download dos plug-ins a partir do site do desenvolvedor e os instale. Como os plug-ins so especficos para os principais browsers do mercado, que esto em constante evoluo, preciso atualiz-los periodicamente. Em uma variao mais drstica desta alternativa, existem browsers completos, desenvolvidos pelos fabricantes de software para SIG, construdos em torno da transmisso de dados vetoriais. A Figura 10.8 apresenta um exemplo.
Figura 10.8 Visualizao composta utilizando plug-in ActiveX de um software comercial. Fonte: http://geo.sampa.prodam.com.br.
352
Outra alternativa consiste em criar uma aplicao (applet) na linguagem Java (Fonseca e Davis, 1999), que transmitida no momento do acesso e executada na mquina do usurio, dispensando procedimentos complicados de instalao ou mesmo a ocupao de rea em disco. A aplicao desaparece da mquina do usurio no momento em que desativada. Assim, novas verses no precisam ser distribudas, pois estaro disponveis instantaneamente a partir do momento de sua instalao no servidor. Os dados so recebidos e tratados objeto por objeto, facilitando a implementao de caches locais. Cada objeto precisa ser transmitido uma nica vez, sendo que operaes posteriores de zoom ou pan podem apenas utilizar os dados j presentes na cache. Este tipo de arquitetura j foi inclusive proposta como modelo de interoperabilidade (Fonseca e Davis, 1997) (Fonseca e Davis, 1999). Atualmente, implementada por diversos produtos, dentre os quais o ALOVmap, um publicador de mapas gratuito que pode funcionar tanto isolado em um computador, quanto atravs de um servidor Web (Figura 10.9).
Figura 10.9 Mapa do Afeganisto apresentado pelo software ALOVmap. Fonte: http://alov.org/Afgan/afgan.html.
Disseminao direta
353
Figura 10.10 JUMP: Java Unified Mapping Platform, um aplicativo para visualizao e manipulao de dados geogrficos na Internet. Fonte: www.jump-project.org.
Outro exemplo o projeto Java Unified Mapping Platform (JUMP), um produto de fonte aberto para visualizao e manipulao de dados geogrficos atravs da Internet, e que conta com suporte a alguns dos principais padres do OGC (ver Captulo 11), como a linguagem GML e o modelo de objetos (Figura 10.10). Em 2004, o W3C (organismo de padronizao da WWW) aprovou a especificao final da linguagem Simple Vector Graphics (SVG) (WorldWide Web Consortium (W3C, 2000), atravs da qual possvel apresentar grficos vetoriais usando um browser comum. Atualmente, esse tipo de recurso exige a instalao de um plug-in, pois o padro muito recente e ainda no foi incorporado s verses atualmente em uso dos browsers. A linguagem SVG baseada em XML, assim como a linguagem Geography Markup Language (GML), esta padronizada pelo OGC (OpenGIS Consortium, 2004), conforme discutido no Captulo 11. A combinao entre GML e SVG cria timas oportunidades para disseminao de dados geogrficos na Internet. possvel, por exemplo, transformar um conjunto de dados GML em um arquivo SVG para
354
visualizao na Web, determinando os parmetros dessa transformao em um arquivo XSLT (eXtensible Stylesheet Language Transformations)(W3C, 1999). Um exemplo desse tipo de aplicao foi apresentado em (Mathiak, Kupfer et al., 2004). possvel codificar apresentaes bastante complexas usando SVG, contando inclusive com recursos de animao, som e um refinado acabamento grfico, o que permite antever uma gama de tipos diferentes de apresentao para dados geogrficos, com recursos que iro muito alm dos tradicionais mapas estticos da cartografia. A Figura 10.11 apresenta um exemplo de uso de SVG para apresentao de dados. Por fim, a Figura 10.12 sumariza as alternativas de acesso a bancos de dados geogrficos atravs da Internet.
Figura 10.11 Visualizao usando SVG. Fonte: www.atlasmercadologico.com.br.
Biblioteca digital de informaes geogrficas
355
Software cliente especfico
Browser simples
Browser + Java
Cliente conectado Internet
Internet
Servidor Web
Browser + plug-in Firewall
Browser + SVG Servidor de Bancos BD Geogrfico de Dados Geogrficos
Figura 10.12 Disseminao de dados geogrficos atravs da Internet resumo das alternativas.
10.4 Biblioteca digital de informaes geogrficas Os SIG esto evoluindo para alm de sua comunidade de usurios tradicionais e se tornando parte integrante da infra-estrutura de sistemas de informao de muitas organizaes. Uma conseqncia positiva desse fato o aumento significativo no nmero e no volume das fontes de dados espaciais disponveis para acesso atravs de redes de computadores. Essa evoluo representa um novo paradigma na forma de utilizao da informao geogrfica, baseado no conceito de biblioteca digital de informaes geogrficas (BDG), ou centros de dados geogrficos, que so bibliotecas digitais especializadas em dados geo-referenciados, fornecendo uma infra-estrutura para a criao, estruturao, armazenamento, organizao, processamento, recuperao e distribuio de dados georeferenciados (Cmara et al., 1996) (Oliveira et al., 1999). 10.4.1 Alexandria Digital Library O projeto da Alexandria Digital Library (ADL) (UCSB, 2005) j foi discutido no Captulo 9 como um exemplo de um catlogo de metadados combinado com um dicionrio geogrfico. A ADL , principalmente, um dos mais importantes projetos de criao de uma biblioteca digital de informaes geogrficas. A ADL fornece acesso pblico a um acervo de mais de 15.000 itens digitais e no digitais
356
(mapas, imagens e dados espaciais) do Map and Imagery Laboratory (MIL) da Universidade da Califrnia e tambm a outros acervos. Recordando a discusso do Captulo 9, sua arquitetura segue o modelo de trs camadas: servidores gerenciam as colees de dados espaciais, um middleware implementa os servios de acesso s colees via protocolo HTTP e clientes so utilizados pelos usurios da biblioteca para a consulta e navegao pelas colees (Frew, et al. 2000). Na interface de consulta Web da ADL (Figura 10.13), o usurio pode utilizar um mapa para selecionar a rea de interesse da sua pesquisa e tambm especificar, para a busca ao catlogo, um conjunto de palavraschave, o perodo, o tipo do objeto (se mapa, dado, imagem, etc.), seu formato, a fonte original, e o mtodo de ranking utilizado na resposta. Os dados sobre os itens localizados so ento exibidos, incluindo um link para o dado espacial, se esse estiver disponvel.
Figura 10.13 Biblioteca Geogrfica Digital Alexandria.
Biblioteca digital de informaes geogrficas
357
10.4.2 Maine Library of Geographic Information Nesta BGD, o estado norte-americano do Maine torna disponveis, para acesso pblico, dados geogrficos em formato digital sobre seu territrio (Maine Digital Geographic Library, 2005). Destaca-se a qualidade dos metadados da biblioteca, de acordo com uma diviso em sete itens: identificao, qualidade dos dados, organizao dos dados, sistema de referncia utilizado, informaes dos atributos dos dados, informaes de distribuio e referncia dos metadados. A busca (Figura 10.14) pode ser feita com uso de palavras-chave ou pela seleo de um dos cinco grupos temticos disponveis: cidades, condados, quadrculas, unidades hdricas ou todo o estado. Cada um desses grupos possui uma relao de dados digitais disponveis. A seleo de um grupo mostra a lista dos dados acompanhada de seus respectivos metadados e endereos para download dos dados, quase sempre em formato shape.
Figura 10.14 Biblioteca Geogrfica Digital do Maine.
358
10.4.3 GeoConnections Discovery Portal Mantida por um entidade canadense, formada por membros do governo e da iniciativa privada, esta BDG tem por objetivo de longo prazo o desenvolvimento de uma infra-estrutura para a divulgao de dados espaciais, especialmente os que se referem ao territrio do Canad (Natural Resources Canada, 2005). Esto disponveis tanto dados gratuitos quanto com valor associado. O sistema de busca capaz de localizar dados pesquisando por rea, assunto, palavra-chave, perodo de tempo ou por qualquer combinao desses itens. O resultado de uma consulta pode ser observado na Figura 10.15. Os metadados apresentam um bom nvel de detalhamento, e trazem informaes sobre a identificao dos dados, sua distribuio e as referncias dos metadados.
Figura 10.15 Geoconnections Discovery Portal.
Infra-estruturas de dados espaciais
359
10.5 Infra-estruturas de dados espaciais O acesso informao tem sido uma das grandes dificuldades de todo pesquisador, usurio, desenvolvedor ou especialista envolvido em temas ligados representao computacional do espao. Inicialmente, nos primrdios do geoprocessamento, o problema se concentrava na construo dos bancos de dados geogrficos: fontes de dados, processos de converso, tcnicas e tecnologias para levantamento de dados em campo (Montgomery e Schuch, 1993). Com o aumento gradual do volume de informao digital disponvel em meio digital, encontrar padres para facilitar o intercmbio de dados passou a ser o problema (Lima, 2002) (Lima et al., 2002) (United States Geological Survey, 2005) (Davis Jr., 2002), conforme discutido no Captulo 9. Rapidamente, no entanto, percebeu-se que o intercmbio puro e simples dos dados no seria suficiente, se o receptor no tivesse como avaliar se os dados atendem ou no s suas necessidades. Isso levou ao estabelecimento de padres e ao incio de esforos de desenvolvimento de metadados espaciais (Soares, 1999). Mas, mesmo com os metadados, permaneciam ainda eventuais dvidas sobre aspectos semnticos ligados aos dados, problemas esses resultantes de vises variadas do mundo por pessoas de diferentes origens e formaes. Esse problema, juntamente com o anterior, motivou o desenvolvimento de estudos de interoperabilidade semntica (Fonseca, 1999) (Vckovski, 1998), j aludido no Captulo 9. Atualmente, mesmo sem haver concluses definitivas sobre os problemas de semntica, existe um movimento para criar infra-estruturas de dados espaciais (IDE) (Bernard, 2005) (Smits, 2002). Diversas iniciativas tm buscado compreender melhor os processos segundo os quais elementos da infra-estrutura espacial so desenvolvidos e utilizados. Uma dessas iniciativas o projeto INSPIRE (Infrastructure for Spatial Information in Europe) (Smits, 2002), que pretende tornar a informao geogrfica digital mais acessvel e interopervel para uma ampla gama de aplicaes, usando uma arquitetura baseada em servios. Outra delas a Global Spatial Data Infrastructure Association (GSDI), uma organizao que pretende promover o desenvolvimento de uma infraestrutura de dados espaciais em escala planetria, como suporte
360
conduo de aes de desenvolvimento sustentvel e impacto social, econmico e ambiental (GSDI Association, 2005). A idia principal das infra-estruturas de dados espaciais oferecer servios de acesso informao geogrfica, com base em grandes catlogos de acervos de informao, tornando indiferentes, aos olhos do cliente da IDE, o local, meio e estrutura fsica de armazenamento. Como o acesso aos dados realizado apenas atravs de servios, possvel encapsular a estrutura fsica dos dados, seguindo um dos preceitos da orientao por objetos. O usurio tambm no precisaria conhecer o local onde os dados esto armazenados, pois cada provedor de dados se encarrega de registrar, junto a um servio de catalogao, que dados possui, onde esto, como esto organizados, e onde esto os metadados. Basta, ento, que o usurio consulte um servio para determinar se os dados que procura esto disponveis, consulte outro para avaliar detalhes sobre a fonte e o processo de captura usando outro servio e, caso esteja satisfeito com as caractersticas dos dados, acione um terceiro servio para recuper-los. O foco no conceito de IDE uma conseqncia natural da evoluo da Web e de sua arquitetura, diante das diretrizes que vm sendo traadas por seu rgo normatizador, o W3C. Em sua concepo inicial, o objetivo da Web era fornecer contedo exclusivo para uso e interpretao humanos. Isso significa que, em sua origem, o foco de desenvolvimento da Web restringiu-se a questes relacionadas apresentao. O crescimento explosivo da Web, entretanto, fez surgir uma enorme demanda por aplicaes que fossem capazes de operar e interagir nesse ambiente. A apresentao deixou de ser a preocupao central para dividir seu lugar com o contedo. As primeiras abordagens para a interoperao entre aplicaes na Web, porm, possuam um carter ad hoc e baseavam-se na explorao da prpria infra-estrutura bsica da Internet. Muitas vezes, essa interoperao era realizada atravs de APIs que incorporavam mdulos encarregados de extrair o contedo de pginas Web (McIlraith et al., 2001). Essa mudana de foco da apresentao para o contedo foi cristalizada no conceito da Web Semntica, uma extenso da Web na qual a informao possui um significado bem definido, possibilitando que
Infra-estruturas de dados espaciais
361
computadores e pessoas trabalhem em cooperao (Berners-Lee, 2001). Alguns passos importantes em direo Web Semntica j foram dados, como o uso crescente do padro XML para o intercmbio de dados e a especificao de uma grande quantidade de servios Web. Percebe-se, assim, que a rea de geoinformao tambm tem se movimentado em direo Web Semntica, tanto por meio dos padres da OGC, quanto por iniciativa da comunidade de pesquisa em geoinformao (Egenhofer, 2002). O conceito de servio Web surgiu para prover uma arquitetura sistemtica e mais ampla para a interao entre aplicaes, fundamentada sobre os protocolos Web j existentes e o padro XML (Curbera et al., 2002). O funcionamento proposto para as IDE aproxima-se bastante da arquitetura de servios do OpenGIS Consortium, abordados no Captulo 11. No modelo OGC (Figura 10.16), rgos pblicos, empresas e instituies geradoras de informao espacial proveriam acesso aos seus dados atravs de servios Web de diversas naturezas, conforme o tipo de dado e as peculiaridades de seu uso. Cada servio registrado em um servidor central, atravs do qual os usurios podero descobrir sobre a existncia ou no de determinado dado ou servio, e obter o caminho de acesso a servidores de metadados, atravs dos quais podero verificar se a qualidade e demais caractersticas do dado atendem ou no s suas necessidades. Podero tambm, eventualmente, escolher entre diversos provedores do mesmo tipo de servio. Observe que os servios podem ser ou no baseados em dados: servios para transformao de coordenadas, por exemplo, podem prover apenas o processamento de dados do usurio. Outros servios so totalmente baseados em dados, porm no os fornecem diretamente para o usurio, possibilitando assim que o administrador do servio tenha a liberdade de estrutur-lo internamente da maneira que achar melhor.
362
OGC Services Registry

Metadados sobre os servios
XML
Usurios
XML / GML
Web Services OGC
Universidade
ONG
Governo Federal
Governo Estadual
Governo Municipal
Provedor Comercial de Dados
Provedores de Informao Geogrfica
Figura 10.16 Arquitetura de servios OGC.
10.6 Leituras Suplementares A grande variedade de alternativas para disseminao de dados geogrficos pela Internet no deixa dvidas quanto enorme demanda que existe por informao espacial simples de acessar, de obter e usar. A atual disposio de pases desenvolvidos em promover a criao de infra-estruturas de dados espaciais reflete essa demanda: trata-se do reconhecimento de que a informao um bem da sociedade que, estando disponvel no tempo certo, com qualidade adequada, de maneira livre e a baixo custo, pode fomentar uma ampla gama de iniciativas, pblicas, privadas, individuais ou do terceiro setor. Sugerimos aos leitores um aprofundamento sobre infra-estruturas de dados espaciais, seguindo projetos como o INSPIRE e outros, alm de um maior aprofundamento nas propostas do OGC para arquiteturas de sistemas geogrficos apoiadas em servios Web (OpenGIS Consortium, 2003 ). Resta ainda comentar sobre o outro lado da disseminao cada vez mais ampla de dados na Web: a necessidade de localizar esses dados. Existem
363
hoje muitas iniciativas no sentido de ampliar o escopo das busca tradicionais, tais como Google, Yahoo ou Altavista. Os dois primeiros tm em operao servios de busca apoiados em nomes de locais (local.google.com e local.yahoo.com), que combinam buscas por palavrachave com um sistema de pginas amarelas. Algumas iniciativas de extrair o contexto geogrfico presente no contedo de uma pgina Web esto sendo conduzidas (Laender et al., 2005), visando, entre outras coisas, produzir ndices espaciais para a localizao de pginas Web (Jones et al., 2002) e constituindo uma rea denominada recuperao da informao espacial (spatial information retrieval). Por enquanto, sabe-se principalmente que o interesse em se contar com uma Web local muito grande, e que isso s ser viabilizado quando conseguirmos entender melhor a maneira segundo a qual as pessoas relacionam-se com a geografia em seu dia-a-dia (Hiramatsu e Ishida, 2001).
364
Referncias
BERNARD, L.; CRAGLIA, M. SDI: From Spatial Data Infrastructure to Service Driven Infrastructure. In: Research Workshop on Cross-Learning between Spatial Data Infrastructures (SDI) and Information Infrastructures (II),2005,Enschede, Holanda. BERNERS-LEE, T.; CAILLIAU, R.; LUOTONEN, A.; NIELSEN, H. F.; SECRET, A. The World-Wide Web. Communications of the ACM, v. 37, n.8, p. 76-82, 1994. BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The Semantic Web. Scientific American, v. 184, n.5, p. 34-43, 2001. CMARA, G.; CASANOVA, M.; HEMERLY, A.; MAGALHES, G.; BAUZER-MEDEIROS, C., 1996, Anatomia de Sistemas de Informao Geogrfica, Curitiba, Sagres. CURBERA, F.; DUFTLER, M.; KHALAF, R.; NAGY, W.; MUKHI, N.; WEERAWARANA, S. Unraveling the Web Services Web: an introduction to SOAP, WSDL and UDDI. IEEE Internet Computing, v. 6, n.2, p. 86-93, 2002. DAVIS JR., C. A., 2002, Intercmbio de Informao Geogrfica: a experincia de padronizao e cooperao em Minas Gerais. In: PEREIRA, G. C., ROCHA, M. C. F., ed., Dados Geogrficos: aspectos e perspectivas: Salvador (BA), Rede Baiana de Tecnologias da Informao Espacial (REBATE), p. 43-54. EGENHOFER, M. Toward the semantic geospatial web. In: 10th ACM international symposium on Advances in geographic information systems table of contents, 2002, McLean, Virginia, USA. ELSMARI, R.; NAVATHE, S. Fundamentals of Database Systems. Pearson Education, 2004. FONSECA, F.; EGENHOFER, M.; BORGES, K. Ontologias e Interoperabilidade Semntica entre SIGs. In: Workshop Brasileiro em Geoinformtica (GeoInfo2000), 2., So Paulo, 2000. Anais. So Jos dos Campos: INPE, 2000. p. 45 - 52. FONSECA, F. T.; DAVIS JR., C. A. Using the Internet to access geographic information: an OpenGIS interface prototype. In: International Conference on Interoperating Geographic Information Systems (Interop 97), 1997, Santa Barbara (CA). NCGIA and OpenGIS Consortium (OGC), p. 283-293.
Referncias
365
FONSECA, F.; DAVIS, C., 1999, Using the Internet to Access Geographic Information: An OpenGis Prototype. In: GOODCHILD, M.; EGENHOFER, M.; FEGEAS, R.; KOTTMAN, C., eds., Interoperating Geographic Information Systems: Norwell, MA, Kluwer Academic Publishers, p. 313-324. FREW, J.; FREESTON, M.; FREITAS, N.; HILL, L.; JANE, G.; LOVETTE, K.; NIDEFFER, R.; SMITH, T.; ZHENG, Q. The Alexandria Digital Library Architecture. International Journal on Digital Libraries, v. 2, n.4, p. 259-268, 2000. GSDI ASSOCIATION, 2005, Global Spatial Data Infrastructure Web Site. HIRAMATSU, K.; ISHIDA, T. An Augmented Web Space for Digital Cities. In: IEEE Symposium on Applications and the Internet (SAINT 2001),2001,San Diego (CA). p. 105-112. JONES, C. B.; PURVES, R.; RUAS, A.; SANDERSON, M.; SESTER, M.; VAN KREVELD, M.; WEIBEL, R. Spatial information retrieval and geographic ontologies: an overview of the SPIRIT project. In: 25th Annual ACM SIGIR Conference on Research and Development on Information Retrieval,2002, Tampere, Finland. LAENDER, A. H. F.; BORGES, K. A. V.; CARVALHO, J. C. P.; MEDEIROS, C. M. B.; SILVA, A. S.; DAVIS JR., C. A., 2005, Integrating Web Data and Geographic Knowledge into Spatial Databases. In: MANOLOPOULOS, Y.; PAPADOPOULOS, A.; VASSILAKOPOULOS, M., eds., Spatial Databases: technologies, techniques and trends: Hershey (PA), Idea Group Publishing. LIMA, P. GeoBR: Intercmbio Sinttico e Semntico de Dados Espaciais.So Jos dos Campos: INPE, 2002.Dissertao de Mestrado, 2002. LIMA, P.; CMARA, G.; QUEIROZ, G. R. GeoBR: Intercmbio Sinttico e Semntico de Dados Espaciais. In: IV Simpsio Brasileiro de GeoInformtica (GeoInfo 2002),2002,Caxambu (MG). p. 139-146. MAINE DIGITAL GEOGRAPHIC LIBRARY, 2005. MATHIAK, B.; KUPFER, A.; NEUMANN, K. Using XML languages for modeling and Web-visualization of geographical legacy data. In: GeoInfo 2004,Campos do Jordo (SP). Sociedade Brasileira de Computao (SBC). MCILRAITH, S. A.; SON, T. C.; ZENG, H. Semantic Web Services. IEEE Intelligent Systems, v. 16, n.2, p. 46-53, 2001. MONTGOMERY, G. E.; SCHUCH, H. C. GIS Data Conversion Handbook. John Wiley & Sons,1993.
366
NATURAL RESOURCES CANADA, 2005, GeoConnections Discovery Portal. OLIVEIRA, J. L.; GONALVES, M. A.; MEDEIROS, C. M. B. A framework for designing and implementing the user interface of a geographic digital library. International Journal on Digital Libraries, p. 190-206, 1999. OPENGIS CONSORTIUM, 2003, OpenGIS Reference Model. OPENGIS CONSORTIUM, 2004, Geography Markup Language (GML) 3.1.0. SMITS, P., 2002, INSPIRE Architecture and Standards Position Paper, Architecture and Standards Working Group. SOARES, V. G.; SALGADO, A. C. Consultas visuais em sistemas de informaes geogrficas baseadas em padres de metadados espaciais. In: I GeoInfo 1999,Campinas (SP). SUN MICROSYSTEMS, 1994, The Java language: a white paper. THOMAZ, K. P. A preservao de documentos eletrnicos de carter arquivstico: novos desafios, velhos problemas.Belo Horizonte: UFMG, 2004.Tese de Doutorado, Escola de Cincia da Informao, 2004. UCSB, 2005, The Alexandria Digital Library. UNITED STATES GEOLOGICAL SURVEY, 2005, USGS Spatial Data Transfer Standard Information Site. VCKOVSKI, A. Interoperable and Distributed Processing in GIS. CRC Press,1998. WORLD-WIDE WEB CONSORTIUM (W3C), 1999, XSL Transformations (XSLT) Version 1.0. WORLD-WIDE WEB CONSORTIUM (W3C), 2000, Scalable Vector Graphics (SVG) 1.0 Specification.
11 O Open Geospatial Consortium

Clodoveu A. Davis Jr. Karla A. V. Borges Ligiane Alves de Souza Marco Antonio Casanova Paulo de Oliveira Lima Jnior
11.1 Introduo Este captulo resume o modelo conceitual, o formato de intercmbio de dados e os servios propostos pelo Open Geospatial Consortium (OGC). O Open Geospatial Consortium (OGC, 2005a) um consrcio com mais de 250 companhias, agncias governamentais e universidades, criado para promover o desenvolvimento de tecnologias que facilitem a interoperabilidade entre sistemas envolvendo informao espacial e localizao (Gardels, 1996) (Percivall, 2003). Os produtos do trabalho do OGC so apresentados sob forma de especificaes de interfaces e padres de intercmbio de dados. 11.2 Modelo conceitual O modelo conceitual do OGC baseado em uma classe abstrata denominada feature. Uma feature considerada pelo OpenGIS uma abstrao de um fenmeno do mundo real; uma feio geogrfica se associada com uma localidade relativa Terra. A classe abstrata FEATURE tem duas especializaes FEATURE WITH GEOMETRY, que almeja capturar o conceito de geo-objetos, e COVERAGES, que pretende capturar o conceito de geo-campos.
368
Figura 11.1 Subtipos de feature, adaptado de (OGC, 1999).
Figura 11.2 Relao entre Feature e Coverage, adaptado de (OGC, 1999).
O padro OpenGIS relaciona diretamente cada tipo de coverage com uma geometria particular, num relacionamento de especializao. Isto faz com que o contedo semntico de uma coverage, ou seja, os tipos de dados geogrficos representados, sejam confundidos com seu contedo sinttico, a estrutura de dados utilizada. Esta relao incoerente com a definio proposta pelo padro OpenGIS para coverage, que fala em funo, domnio e intervalo.
Geography Markup Language
369
Figura 11.3 Subtipos de Coverage, adaptado de (OGC, 1999).
11.3 Geography Markup Language Seguindo a tendncia do uso de padres para intercmbio de dados, o OpenGIS usa o padro XML (eXtensible Markup Language) para definir uma forma de codificar dados geogrficos. Para isso especificou a linguagem GML (Geography Markup Language) (Cox, 2003). A GML (Geography Markup Language) foi especificada para o transporte e armazenamento de informao geogrfica, incluindo propriedades espaciais e no espaciais das feies geogrficas (OGC, 1999). O objetivo da GML oferecer um conjunto de regras com as quais um usurio pode definir sua prpria linguagem para descrever seus dados. Para tanto, a GML baseada em esquemas XML (XML Schema). O esquema XML define os elementos (tags) usados em um documento que descreve os dados. Sua verso 3.0 inclui esquemas que contm os modelos de geometria, feies (features) e superfcies. Os esquemas esto publicados nas especificaes do OGC (Cox, 2003) os principais so os seguintes: BasicTypes: que engloba uma srie de componentes simples e genricos para representao arbitraria de atributos, nulos ou no. Topology: o qual especifica as definies do esquema geomtrico dos dados, bem como sua descrio.
370
CoordinateReference Systems: para sistemas de referncia de coordenadas. Temporal Information and Dynamic Feature: Este esquema estende aos elementos caractersticas temporais dos dados geogrficos e suas funes dinamicamente definidas. Definitions and Dictionaries: definies das condies de uso dentro de documentos com certas propriedades ou informaes de referentes propriedade padro.
Metadata: Este esquema utilizado para definir as propriedades dos pacotes de dados que podem ser utilizados atravs de outros dados j existentes. De posse destes esquemas, um usurio pode definir o seu prprio esquema para sua aplicao. Mas h algumas exigncias a seguir para obter conformidade: Desenvolvedores de esquemas de aplicao devem assegurar que seus tipos so subtipos dos correspondentes tipos da GML: gml:AbstractFeatureType ou gml:AbstractFeatureCollectionType para feies e gml:AbstractGeometryType ou gml:GeometryCollectionType para a geometria. Um esquema de aplicao no pode mudar o nome, definio ou tipo de dado dos elementos obrigatrios da GML; Definies de tipos abstratos podem ser livremente estendidas ou restritas; Esquema de aplicao deve estar disponvel a qualquer um que receba o dado estruturado por aquele esquema; Os esquemas relevantes devem especificar um namespace que no deve ser http://www.opengis.net/gml. Desta forma um desenvolvedor de esquemas pode criar seus prprios tipos e tags e uma aplicao GML poder fazer uso dos dados. Por exemplo, consideramos dois arquivos, um para o esquema (exemplo.xsd) e outro com os dados (exemplo.xml):
Geography Markup Language
371
Figura 11.4 Trecho de um esquema de aplicao.
A Figura 11.4 um fragmento de um arquivo exemplo.xsd que define um esquema de aplicao, mostrando a criao de um tipo, no caso hidrografia. Seguindo as regras, a linha 3 faz com que hidrografia seja subtipo de gml:AbstractFeatureType. Este tipo pode ser usado na criao de uma tag, por exemplo:
Figura 11.5 Criao de uma tag.
O fragmento mostrado na Figura 11.5 parte do mesmo esquema e define a criao de uma tag <rio> do tipo hidrografia que pode ser usada para descrever um determinado rio no arquivo exemplo.xml. Tambm definido que o elemento tem o atributo substitutionGroup igual a gml:_Feature, o que garante a uma aplicao a leitura dos dados. O ex em ex:hidrografia indica que o nome hidrografia do domnio ex, declarado no incio do arquivo:
372
Figura 11.6 Exemplo de namespace.
No incio do arquivo foi definido o namespace ex, como mostra a linha 4 da Figura 11.6. Um fragmento do arquivo contendo os dados ilustrado pela Figura 11.7:
Figura 11.7 Fragmento de um arquivo de dados em XML. As tags <gml:description> (linha 2) e <gml:name> (linha 3) da Figura 11.7 no foram criadas no esquema de aplicao, mas sim herdadas do tipo AbstractFeatureType, j que hidrografia deste tipo e <rio> foi definido como hidrografia. Para a transferncia de dados necessria a transferncia do arquivo com o esquema tambm, s assim uma aplicao que procura por <_Feature> poder saber que <rio>
<_Feature>.
Descrio dos servios
373
Os esquemas da GML sozinhos no so adequados para criar uma instncia de documento. Estes devem ser estendidos pela criao de esquemas de aplicao para domnios especficos, seguindo as regras descritas na especificao. Isto exige um investimento na elaborao de esquemas. A GML possui pontos, linhas, polgonos e colees geomtricas (MultiPoint, MultiPolygon) definidos por coordenadas cartesianas uni, bi ou tridimensionais associados a eventuais sistemas de referncia espacial. Mas as localizaes espaciais so definidas apenas por coordenadas cartesianas, coordenadas projetivas no esto previstas. 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 situao: dois usurios de domnios diferentes representam uma determinada entidade, pela GML, como <rio> e <curso_de_agua>. Em uma troca de dados entre os usurios, os esquemas tambm devem ser compartilhados, pois s assim uma aplicao poder saber que <rio> ou <curso_de_agua> so da classe <_Feature> definida pelo esquema Feature.xsd da GML, e ento process-los adequadamente. Desta forma o problema de acesso aos dados resolvido. Mas no h como saber que <rio> <curso_de_agua> e vice-versa. O aspecto semntico no considerado de forma efetiva a promover a interoperabilidade. Para amenizar este problema, pode-se acrescentar tags que descrevem as entidades e suas relaes, ou que identifiquem sinnimos. 11.4 Descrio dos servios 11.4.1 Framework arquitetural dos servios As especificaes do OGC baseiam-se em um framework arquitetural, chamado de OpenGIS Services Framework (Percivall, 2003), que especifica o escopo, objetivos e comportamento de uma srie de componentes. Neste sentido, o framework representa uma arquitetura de referncia para desenvolvimento de aplicaes geogrficas, no esprito da ISO 19119. A definio dos componentes segue o paradigma de Web services e, portanto, est sujeita a restries conceituais e de implementao. As
374
restries conceituais endeream funcionalidade e incluem orientao a servios, auto-descrio dos servios e operao sem estados persistentes (stateless operation). As restries de implementao endeream questes relativas a interoperabilidade, incluindo a adoo de formatos de intercmbio em XML, utilizao de protocolos comuns Internet. Porm, convm salientar que os servios originalmente especificados pelo OGC no seguem as recomendaes do W3C para definio de servios Web, como SOAP para intercmbio de dados, WSDL para descrio dos servios e UDDI para registro dos servios. Apenas, mais recentemente, a srie de propostas de especificao conhecidas coletivamente como OpenGIS Web Service 2 initiative (Sonnet, 2004) definiram interfaces que utilizam os padres do W3C. Porm, tais especificaes ainda so tratadas como propostas de mudana. Ainda, recentemente, a OGC iniciou um experimento em larga escala para testar o conceito de Web semntica geospacial (OGC, 2005b). Brevemente, o OpenGIS Services Framework compreende (ver Figura 11.8): Padres de Codificao: especificaes de formatos de intercmbio e armazenamento de dados geogrficos, incluindo descries de sistemas de geo-referenciamento, geometria, topologia, e outras caractersticas. O Geography Markup Language (GML) um formato de documentos XML para intercmbio de dados geogrficos. Servios do cliente: componentes que, do lado do cliente, interagem com os usurios e que, do lado do servidor, interagem com os servidores de aplicao e de dados. Servios de registro: componentes que oferecem mecanismos para classificar, registrar, descrever, pesquisar, manter e acessar informao sobre os recursos na rede. Incluem o Web Registry Service (WRS). Servios de processamento de workflow: componentes que oferecem mecanismos para composio de servios que operam sobre dados e metadados geogrficos. Incluem o Sensor Planning Service (SPS) e o Web Notification Service (WNS). Servios de visualizao: componentes que oferecem suporte especfico para visualizao de dados geogrficos, resultando em produtos como
Descrio dos servios
375
mapas, vises em perspectiva do terreno, imagens anotadas, vises dinmicas de dados espao-temporais. Incluem o Web Map Service (WMS), o Coverage Portrayal Service (CPS) e o Style Management Service (SMS). Servios de dados: componentes que oferecem os servios bsicos de acesso aos dados geogrficos. Incluem o Web Object Service (WOS), o Web Feature Service (WFS), o Sensor Collection Service (SCS), o Image Archive Service (IAS) e o Web Coverage Service (WCS). O resto desta seo resume os servios definidos pelo OGC. Para maiores detalhes, recomenda-se uma visita ao Website do OGC (OGC, 2005a).
Localiza
Discovery Client
Map Viewer Client
Imagery Exploitation Client
Value-Add Client
SWE Client
Symbol Management Client
Acessa
Servios do cliente
GML
(2.1 and 3.0)
Style Metadata SensorML Image Metadata
SLD Obs & Meas
Service Metadata Sensor Type Registry Sensor Instance Registry Service Type Registry Sensor Instance Registry Other Type Registry Other Instance Registry
Padres
Servios de registro Publica
SCS
WFST
WCS
WMS
CPS
SPS
WNS
Servios dados
de
WOS
IAS
Servios de visual.
SMS
Servios de processamento
= OGC/IP Interface
Figura 11.8 Componentes do OGC Web Service Framework.
376
Cliente
Servidor
requisio <GetCapabilities> documento <WFS_Capabilities>
requisio <DescribeFeatureType> documento <schema>
requisio <Transaction> documento <WFS_TransactionResponse>
Figura 11.9 Exemplo de execuo do servio WFS.
11.4.2 Web Feature Service A especificao OpenGIS Web Feature Service (WFS) define um servio para que clientes possam recuperar objetos (features) espaciais em formato GML de servidores WFS. O servio pode ser implementado pelo servidor em duas verses: bsica, onde apenas operaes de consulta ficam disponveis, ou transacional, que implementa o servio completo, que inclui operaes de insero, excluso, atualizao, consulta de objetos (features) geogrficos. As seguintes operaes so definidas para o servio: getCapabilities: descreve as caractersticas do servidor. describeFeatureType: descreve a estrutura dos tipos de objeto que podem ser servidos. getFeature: retorna instncias dos objetos disponveis na base de dados. O cliente pode selecionar quais objetos deseja por critrios espaciais ou no. transaction: utilizado para a execuo de operaes de modificao dos objetos (insero, excluso e atualizao).
Descrio dos servios
377
lockFeature: bloqueia uma ou mais instncias durante uma transao. A Figura 11.9 ilustra uma seqncia de execuo tpica do servio WFS. Como em todos os demais servios, tanto as requisies quanto as respostas so documentos XML. 11.4.3 Web Coverage Service Para o acesso a dados que representam fenmenos com variao contnua no espao, o consrcio OpenGIS criou a especificao OpenGIS Web Coverage Service (WCS). O servio especfico para o tratamento de dados modelados como geo-campos, em complementao ao servio WFS, que trata de dados modelados como geo-objetos, isto , que representam entidades espaciais discretas e bem definidas. importante mencionar que o servio no retorna imagens das coverages como resposta das requisies, mas sim dados sobre a semntica dos fenmenos representados. Trs operaes so implementadas no servio: getCapabilities: fornece uma descrio do servidor e informaes bsicas acerca das colees de dados disponveis. describeCoverage: recupera uma descrio completa das coverages. getCoverage: recupera uma coverage (valores e propriedades de um conjunto de localizaes geogrficas) no servidor.
11.4.4 Web Map Service A especificao OpenGIS Web Map Service (WMS) define um servio para a produo de mapas na Internet. Neste sentido, o mapa uma representao visual dos dados geogrficos e no os dados de fato. Os mapas produzidos so representaes geradas em formatos de imagem, como PNG, GIF e JPEG, ou em formatos vetoriais, como o SVG. Quando o cliente requisita um mapa utilizando o servio, um conjunto de parmetros deve ser informado ao servidor: as camadas desejadas, os estilos que devem ser aplicados sobre as camadas, a rea de cobertura do mapa, a projeo ou sistema de coordenadas geogrficas, o formato da imagem gerada e tambm o seu tamanho. O servio possui as seguintes operaes:
378
getCapabilities: obtm os metadados do servidor, que descrevem o contedo e os parmetros aceitos. getMap: obtm a imagem do mapa que corresponde aos parmetros informados. getFeatureInfo: recupera informaes sobre um elemento (feature) particular de um mapa.
11.4.5 Catalog Service A Internet possui uma vasta quantidade de informao geoespacial distribuda em vrios formatos e mantida por inmeras instituies. A organizao dessa informao com base na construo de catlogos uma forma de facilitar sua distribuio, localizao e acesso. A especificao OpenGIS Catalog Services (OCS) introduz um servio para a publicao e busca em colees de informaes descritivas (metadados) de dados espaciais e objetos relacionados. Os metadados de um catlogo representam as caractersticas dos recursos que podem ser pesquisados e apresentados para a avaliao e processamento tanto de homens quanto de mquinas. Na especificao, definida uma linguagem de consulta comum a todas as interfaces do servio, a Common Catalog Query Language, que possui uma sintaxe semelhante a uma clusula Where do SQL. Um esquema de metadados bsico (core metadata schema), baseado na norma ISO19115 - Geographic Information Metadata, proposto para facilitar a interoperabilidade dos catlogos. Assim, uma mesma consulta pode ser executada em diferentes catlogos. Um conjunto de atributos mnimo definido para as consultas e tambm para as respostas das consultas. As operaes disponveis no servio so as seguintes: getCapabilities: permite que um cliente recupere metadados descrevendo as caractersticas do servidor. query: operao que executa uma consulta no catlogo e retorna um conjunto de zero ou mais referncias que satisfazem consulta. present: recupera os metadados de uma ou mais referncias.
Descrio dos servios
379
describeRecordType: retorna a definio do tipo de uma ou mais referncias. getDomain: retorna a domnio (tipos de valores possveis) de um atributo. initialize: utilizado para iniciar uma sesso interativa, para a qual um identificador nico gerado. close: encerra uma sesso interativa. status: recupera a situao de uma operao iniciada anteriormente, ainda em execucao ou j encerrada. cancel: permite que um cliente cancele uma operao. transaction: utilizada para que um cliente solicite um conjunto de aes de insero, remoo ou alterao de itens do catlogo. harvestResource: operao que tenta recuperar recursos de uma localizao especfica e que pode ser reprocessada de tempos em tempos. order: permite que um cliente execute uma operao de compra de um recurso, negociando preo e outros fatores.
11.4.6 Web Terrain Service A especificao OpenGIS Web Terrain Service (WTS) , na verdade, uma especializao do WMS que incorpora modelos de elevao de terreno, com perspectiva e renderizao tridimensional de mapas. O resultado produzido, assim como no WMS, uma representao pictrica dos dados geogrficos. As operaes getCapabilities e getMap seguem a definio do WMS. A diferena fica por conta da incluso da operao getView: getView: obtm uma cena 3D, que uma viso de um lugar a partir do ponto de vista de um observador. A operao exige o fornecimento de alguns parmetros para a composio da cena: o ponto de interesse, a distncia e o ngulo entre o ponto de interesse e o observador da cena, o ngulo representando o campo de viso e o azimute.
380
11.4.7 Web Coordinate Transformation Service Este servio especifica uma interface para a converso de dados de um sistema de coordenadas espaciais (CRS - coordinate reference system) para outro. O servio recebe como entrada objetos geogrficos digitais, que podem ser objetos vetoriais (features) ou matriciais (coverages), que esto georreferenciados em um CRS e retorna os mesmos objetos em outro CRS especificado. O OpenGIS Web Coordinate Transformation Service (WCTS) define sete operaes que podem ser requisitadas pelos clientes. getCapabilities: como em todos os outros servios Web do OpenGis, esta operao retorna as propriedades do servidor. transform: requisio para a transformao de coordenadas de um conjunto de objetos. O CRS dos objetos deve ser informado, assim como o novo CRS desejado. isTransformable: o retorno dessa requisio indica se o servidor WCTS consegue processar a transformao entre dois CRS especificados e tambm se podem ser processados tanto features quanto coverages. getTransformation: utilizada para que um cliente consulte as definies das transformaes que o servidor pode processar de um CRS para outro. describeTransformation: esta requisio recupera a definio de uma ou mais transformaes pelo seu identificador. describeCRS: um cliente pode recuperar a definio de um ou mais CRS com essa requisio. describeMethod: recupera uma ou mais definies de mtodos das operaes.
11.4.8 Geolinking Service Um geolink ocorre quando a geometria de um objeto espacial no armazenada juntamente com seus dados alfanumricos, mas apenas um identificador geogrfico para a geometria (por exemplo, o nome de uma cidade). O identificador geogrfico se refere, portanto, a uma geometria armazenada em outro banco de dados. O servio de Geolinking tem por
Descrio dos servios
381
objetivo executar um join entre os atributos alfanumricos e as geometrias que compartilham uma chave em comum (o identificador geogrfico). Os identificadores geogrficos podem incluir nomes de lugares, cdigos postais, cdigos de rea telefnicos e outros. Muitos bancos de dados corporativos possuem dados dessa natureza, mas no utilizam seu potencial geogrfico. O OpenGIS Geolinking Service uma alternativa para o georreferenciamento dessas bases de dados. A especificao ainda est em fase de discusso. As operaes do servio so: getCapabilities: recupera informaes gerais sobre o servidor. geoLink: usado para instruir o servidor a acessar um conjunto de dados especfico para o geolink e processar o join solicitado. 11.4.9 Web Gazetteer Service Esta especificao adiciona ao protocolo WFS alguns recursos especficos para a implementao de interfaces para consulta, insero e atualizao de objetos armazenados em gazetteers digitais (Souza et al., 2004). Os recursos explorados que vo alm do WFS so: o acesso aos relacionamentos hierrquicos entre os termos do gazetteer, baseado nos conceitos de termo mais geral (BT broader term), termo mais especfico (NT narrower term) e termo relacionado (RT related term); e a recuperao de propriedades especficas de gazetteers, tais como o tipo dos lugares. Trata-se de outro servio ainda em fase de discusso. Os operaes so as mesmas do WFS, com pequenas modificaes. 11.4.10 Web Registry Service Um problema derivado da aceitao e implementao pela comunidade dos servios Web propostos pelo OpenGIS passa a ser a localizao dos servidores espalhados pela rede. A soluo encontrada para o problema foi a especificao de mais um tipo de servio Web. O objetivo da especificao OpenGIS Web Registry Service (WRS) propor um servio capaz de fornecer uma estrutura para a localizao dos servidores na Web. Os administradores dos servidores os registrariam em um ou mais servidores WRS para que esses pudessem ser encontrados. O catlogo do WRS fornece a localizao e as caractersticas dos servidores
382
OpenGIS nele registrados. No seria necessrio sequer executar a operao getCapabilities em cada servidor, j que o WRS informa aos clientes as caractersticas de cada servidor cadastrado. Essa especificao ainda se encontra em fase de discusso. Eis as operaes do servio: getCapabilities: retorna as caractersticas do servidor. getDescriptor: retorna os servidores registrados que atende consulta. registerService: registra um servidor OpenGIS no servidor WRS.
11.5 Leituras complementares O documento OpenGIS Reference Model (Percivall, 2003) oferece um bom resumo da proposta de trabalho do OGC. Para detalhes sobre os servios, recomenda-se uma visita ao website do OGC (OGC, 2005a).
Referncias
383
Referncias
COX, S.; DAISEY, P.; LAKE, R.; PORTELE, C.; WHITESIDE, A. (ed), 2003. OpenGIS Geography Markup Language (GML) Implementation Specification. Open Geospatial Consortium, Inc. GARDELS, K., 1996. The Open GIS Approach to Distributed Geodata and Geoprocessing. In: Third International Conference/Workshop on Integrating GIS and Environmental Modeling. Santa Fe, NM, USA, 1996. p. 21-25. OGC, 1999. The OpenGIS Abstract Specification Topic 6: The Coverage Type and its Subtypes. Open Geospatial Consortium, Inc. OGC, 2005a, OpenGIS Consortium Inc. OGC, 2005b, OGC to Begin Geospatial Semantic Web Interoperability Experiment. Press Release, 12/04/2005. http://www.opengeospatial.org/ press/? page=pressrelease&year=0&prid=222 PERCIVALL, G. (ed), 2003. OpenGIS Reference Model. Document number OGC 03-040 Version: 0.1.3. Open Geospatial Consortium, Inc. SONNET, J. (ed), 2004. OWS 2 Common Architecture: WSDL SOAP UDDI. Discussion Paper OGC 04-060r1, Version: 1.0.0. Open Geospatial Consortium, Inc. SOUZA, L. A.; DELBONI, T.; BORGES, K. A. V.; DAVIS JR., C. A.; LAENDER, A. H. F. Locus: Um Localizador Espacial Urbano. In: VI Simpsio Brasileiro de GeoInformtica (GeoInfo 2004),2004,Campos do Jordo (SP). Sociedade Brasileira de Computao (SBC), p. 467-478.
12 Descrio da TerraLib
Lbia Vinhas Karine Reis Ferreira
12.1 Introduo Esse captulo descreve a biblioteca TerraLib em seus aspectos mais relevantes em termos de bancos de dados geogrficos, incluindo o modelo conceitual do banco de dados, o modelo de armazenamento de geometrias e dados descritivos, e os mecanismos de manipulao do banco em diferentes nveis de abstrao. A TerraLib um projeto de software livre que permite o trabalho colaborativo entre a comunidade de desenvolvimento de aplicaes geogrficas, servindo desde prototipao rpida de novas tcnicas at o desenvolvimento de aplicaes colaborativas. Sua distribuio feita atravs da Web no site www.terralib.org. TerraLib uma biblioteca de classes escritas em C++ para a construo de aplicativos geogrficos, com cdigo fonte aberto e distribuda como um software livre. Destina-se a servir como base para o desenvolvimento cooperativo na comunidade de usurios ou desenvolvedores de SIGs Sistemas de Informao Geogrfica. TerraLib fornece funes para a decodificao de dados geogrficos, estruturas de dados espao-temporais, algoritmos de anlise espacial alm de propor um modelo para um banco de dados geogrficos (Cmara et al. 2002). A arquitetura da biblioteca mostrada na Figura 12.1. Existe um mdulo central, chamado kernel, composto de estruturas de dados espaotemporais, suporte a projees cartogrficas, operadores espaciais e uma interface para o armazenamento e recuperao de dados espao-temporais em bancos de dados objeto-relacionais, alm de mecanismos de controle de vizualizao. Em um mdulo composto de drivers a interface de
384
recuperao e armazenamento implementada. Esse mdulo tambm contm rotinas de decodificao de dados geogrficos em formatos abertos e proprietrios. Funes de anlise espacial so implementadas utilizando as estruturas do kernel. Finalmente, sobre esses mdulos podem ser construdas diferentes interfaces aos componentes da TerraLib em diferentes ambientes de programao (Java, COM, C++) inclusive para a implementao de servios OpenGIS como o WMS Web Map Server (OGIS, 2005).
Interface Interface COM Interface C++ Servios OGIS
Funes
Kernel Controle de Visualizao Estruturas Espaotemporais Acesso a Arquivos e SGDBs
Driver E/S
Arquivos Externos
SGDB
Figura 12.1 Arquitetura da TerraLib.
Uma das caractersticas mais importantes da TerraLib a sua capacidade de integrao a sistemas de gerenciamento de bancos de dados objeto-relacionais (SGBD-OR) para armazenar os dados geogrficos, tanto sua componente descritiva quanto sua componente espacial. Essa integrao o que permite o compartilhamento de grandes bases de dados, em ambientes coorporativos, por aplicaes customizadas para diferentes tipos de usurios. A TerraLib trabalha em um modelo de arquitetura em camadas (Davis e Cmara, 2001), funcionando como a camada de acesso entre o banco e a aplicao final. Como exemplo de um aplicativos geogrfico construdo sobre a TerraLib, podemos citar o TerraView (INPE/DPI, 2005). Na Figura 12.2 ilustramos como o TerraView utiliza a TerraLib como camada de acesso a
Modelo conceitual
385
um banco de dados sob o controle de um SGDB-OR como o MySQL (MYSQL, 2005), por exemplo.
Arquitetura em camadas
Aplicativo
Exemplo TerraView
TerraView
Camada de Acesso
TerraLib
SGDB
MySQL
Figura 12.2 Exemplo de uso da TerraLib como camada de acesso ao banco de dados.
Enquanto biblioteca de software, a TerraLib compilada em um ambiente multiplataforma, Windows e Linux, e em diferentes compiladores C++. A TerraLib usa extensivamente os mecanismos mais atuais da linguagem C++, como a STL Standard Template Libray, classes parametrizadas e programao multi-paradigma (Stroustroup, 1997 ). Esse captulo ilustrado com trechos de cdigo C++ que utilizam a TerraLib. Vale lembrar, que esses exemplos, por questo de clareza, contm apenas os trechos mais relevantes para ilustrar a informao sendo destacada. Maiores detalhes sobre as classes, estruturas de dados e funes da biblioteca, usadas nos exemplos, podem ser obtidos na documentao de cdigo da TerraLib disponvel em www.terralib.org. 12.2 Modelo conceitual A TerraLib prope no somente um modelo de armazenamento de dados geogrficos em um SGBD-OR, mas tambm um modelo conceitual de banco de dados geogrfico, sobre o qual so escritos seus algoritmos de processamento. As entidades que formam o modelo conceitual so:
386
Banco de Dados representa um repositrio de informaes contendo tanto os dados geogrficos quanto o seu modelo de organizao. Um banco de dados pode ser materializado em diferentes SGDBs Sistemas Gerenciadores de Bancos de Dados, comerciais ou de domnio pblico. O nico requisito da TerraLib que o SGDB possua a capacidade de armazenar campos binrios longos, ou uma extenso prpria capaz de criar tipos abstratos espaciais, e que possa ser acessado por alguma camada de software. Layer um layer representa uma estrutura de agregao de um conjunto de informaes espaciais que so localizadas sobre uma regio geogrfica e compartilham um conjunto de atributos, ou seja, um layer agrega coisas semelhantes. Como exemplos de layers podem ser citados os mapas temticos (mapa de solos, mapa de vegetao), os mapas cadastrais de objetos geogrficos (mapa de municpios do Distrito Federal) ou ainda dados matriciais como cenas de imagens de satlites. Independentemente da representao computacional adotada para tratar o dado geogrfico, matricial ou vetorial, um layer conhece qual a projeo cartogrfica da sua componente espacial. Layers so inseridos no banco de dados atravs da importao de arquivos de dados geogrficos em formatos de intercmbio como shapefiles, ASCII-SPRING, MID/MIF, GeoTiff, JPEG ou dbf. A biblioteca fornece as rotinas de importao desses arquivos. Layers tambm podem ser gerados a partir de processamentos executados sobre outros layers j armazenados no banco. Representao trata do modelo de representao da componente espacial dos dados de um layer e pode ser do tipo vetorial ou matricial. Na representao vetorial, a TerraLib distingue entre representaes formadas por pontos, linhas ou reas e tambm outras representaes mais complexas formadas a partir dessas como clulas e redes. Para representaes matriciais, a TerraLib suporta a representao de grades regulares multi-dimensionais. A TerraLib permite que um mesmo geo-objeto de um layer possua diferentes representaes vetoriais (ex. um municpio pode ser representado pelo polgono que define os seus limites, bem como pelo ponto onde est localizado em sua sede). A entidade representao da
Modelo conceitual
387
TerraLib guarda informaes como o seu menor retngulo envolvente ou a resoluo horizontal e vertical de uma representao matricial. O termo representao espacial, no contexto da TerraLib, muitas vezes usado de maneira anloga ao termo geometria. Projeo Cartogrfica serve para representar a referncia geogrfica da componente espacial dos dados geogrficos. As projees cartogrficas permitem projetar a superfcie terrestre em uma superfcie plana. Diferentes projees so usadas para minimizar as diferentes deformaes inerentes ao processo de projeo de um elipside em um plano. Cada projeo definida a partir de certo nmero de parmetros como o Datum planimtrico de referncia, paralelos padro e deslocamentos (Snyder, 1987). Tema serve principalmente para definir uma seleo sobre os dados de um layer. Essa seleo pode ser baseada em critrios a serem atendidos pelos atributos descritivos do dado e/ou sobre a sua componente espacial. Um tema tambm define o visual, ou a forma de apresentao grfica da componente espacial dos objetos do tema. Para o caso de dados com uma representao vetorial a componente espacial composta de elementos geomtricos como pontos, linhas ou polgonos. Para os dados com uma representao matricial, sua componente espacial est implcita na estrutura de grade que a define, regular e com um espaamento nas direes X e Y do plano cartesiano. Os temas podem definir tambm formas de agrupamento dos dados de um layer, gerando grupos, os quais possuem legendas que os caracterizam. Vista serve para definir uma viso particular de um usurio sobre o banco de dados. Uma vista define quais temas sero processados ou visualizados conjuntamente. Alm disso, como cada tema construdo sobre um layer com sua prpria projeo geogrfica, a vista define qual ser a projeo comum para visualizar ou processar os temas que agrega. Visual um visual representa um conjunto de caractersticas de apresentao de primitivas geomtricas. Por exemplo, cores de preenchimento e contorno de polgonos, espessuras de contornos e linhas, cores de pontos, smbolos de pontos, tipos e transparncia de preenchimento de polgonos, estilos de linhas, estilos de pontos, etc.
388
Legenda uma legenda caracteriza um grupo de dados, dentro de um tema, apresentados com o mesmo visual, quando os dados do tema so agrupados de alguma forma. As entidades que formam o modelo conceitual esto representadas tanto nas classes que compe a biblioteca quanto em um conjunto de tabelas no banco de dados. A seo seguinte mostra como as entidades do modelo conceitual so representadas nas classes da TerraLib. 12.3 Classes do modelo conceitual O conceito de um banco de dados TerraLib independente do SGDB onde ser fisicamente armazenado e implementado em uma classe abstrata chamada TeDatabase. Essa classe abstrata contm os mtodos necessrios para criar, popular e consultar um banco de dados. A classe TeDatabase derivada em classes concretas, chamadas drivers, que resolvem para diferentes SGDBs comerciais e de domnio pblico, as particularidades de cada um de forma que as aplicaes possam criar bancos de dados em diferentes gerenciadores. A TerraLib fornece alguns drivers em sua distribuio padro, como mostrado na Figura 12.3. Drivers para outros gerenciadores podem ser criados atravs da implementao dos mtodos virtuais definidos na classe.
Figura 12.3 Drivers para bancos de dados fornecidos pela TerraLib.
Tipicamente, as aplicaes que usam a TerraLib processam ponteiros para a classe TeDatabase, inicializados com instancias concretas de algum driver como mostrado no Exemplo 12.1.
Classes do modelo conceitual
389
TeDatabase* myDb = 0; if (op == ado) myDb = new TeAdo(); // Usa ACCESS atravs da biblioteca ADO else myDb = new TeMySQL(); // Usa MySQL
Exemplo 12.1 A classe TeDatabase.
Um Layer existe em memria como uma instncia da classe TeLayer. Um exemplo de criao de um layer atravs da importao de um arquivo de dados em formato MID/MIF mostrado no Exemplo 12.2. O arquivo contm os dados de um cadastro de municpios de um estado e a rotina de importao vai criar um layer no banco de dados com as geometrias e atributos dos municpios descritos no arquivo.
TeLayer* lmun = TeImportMIF("../data/Municipios.mid",myDb,"Municipios");
Exemplo 12.2 Importao de um arquivo de dados.
Uma Representao existe em memria como uma instncia da estrutura TeRepresentation. Cada layer possui a informao de quais as representaes geomtricas (ou geometrias) possui. Assim, aps a execuo do cdigo acima podemos recuperar algumas informaes sobre a representao geomtrica dos municpios como o seu menor retngulo envolvente (ver Exemplo 12.3).
TeRepresentation* munPol = lmun->getRepresentation(TePOLYGONS); // recupera o menor retngulo envolvente das geometrias do tipo // polgono do layer de municpios TeBox = mumPol->box_;
Exemplo 12.3 A classe TeRepresentation.
390
Uma Projeo existe em memria como uma instncia da classe A TerraLib tambm fornece uma classe para descrever um datum planimtrico chamada de TeDatum. A TeProjection uma classe abstrata que define mtodos para converter coordenadas de uma projeo para coordenadas geogrficas (latitude e longitude) e vice-versa. A TerraLib fornece em sua distribuio um conjunto de especializaes da classe TeProjection representando as projees mais comuns como UTM, Mercator ou Policnica. O Exemplo 12.4 mostra como converter coordenadas entre uma projeo UTM, Datum SAD69 e uma projeo Policnica, Datum WGS84.
TeProjection. TeDatum dSAD69 = TeDatumFactory::make("SAD69"); TeDatum dWGS84 = TeDatumFactory::make("WGS84"); TeUtm* pUTM = new TeUtm(dSAD69,-45.0*TeCDR); TePolyconic* pPolyconic = new TePolyconic(dWGS84,-45.0*TeCDR); TeCoord2D pt1(340033.47, 7391306.21); // Converso de UTM para policnica pUTM->setDestinationProjection(pPolyconic); // Converte uma coordenada de UTM para coordenada geogrfica TeCoord2D ll = pUTM->PC2LL(pt1); // Converte de geogrfica para policnica TeCoord2D pt2 = pPolyconic->LL2PC(ll); // Converte uma coordenada de policnica para coordenada UTM pPolyconic->setDestinationProjection(pUTM); ll = pPolyconic->PC2LL(pt2); pt1 = pUTM->LL2PC(ll); // em projeo UTM
Exemplo 12.4 Converso de coordenadas para diferentes projees.
A classe TeLayer possui a indicao de qual a sua projeo cartogrfica como mostrado no Exemplo 12.5.
Classes do modelo conceitual
391
TeProjection* munProj = lmun->projection();
Exemplo 12.5 Recuperao da projeo de um layer.
Temas existem em memria como instncias da classe TeTheme e Vistas como instncias da classe TeView. O Exemplo 12.6 mostra como criar uma nova vista e um novo tema a partir do layer criado no Exemplo 12.2.
// Cria uma vista com a mesma projeo do layer TeView* view = new TeView("Municipios ", user); view->projection(munProj); // salva a vista no banco de dados myDb->insertView(view)) // cria um tema com todos os objetos do layer TeTheme* theme = new TeTheme("t_municipios ", lmun); view->add(theme);
Exemplo 12.6 Criao de um Tema.
Uma ilustrao que resume o relacionamento entre as principais classes que formam o modelo conceitual da TerraLib mostrado na Figura 12.4. Um banco TerraLib formado por um conjunto de layers, cada layer possui uma projeo cartogrfica. Em um banco podem ser criadas n vistas e cada vista possui sua prpria projeo cartogrfica. Cada vista pode conter n temas sendo que cada tema criado a partir de um layer.
392
Figura 12.4 Relacionamento entre as classes do modelo conceitual de TerraLib.
12.4 Modelo do banco de dados Fisicamente, um banco de dados TerraLib formado por um conjunto de tabelas em um SGBD-OR, onde so armazenados tanto os dados geogrficos (suas geometrias e seus atributos) quanto um conjunto de informaes sobre a organizao desses dados no banco, ou seja, o modelo conceitual da biblioteca. Essas tabelas podem ser divididas em dois tipos: 1. Tabelas de Metadados: possuem nome e formato pr-definido e so usadas para guardar o modelo conceitual da TerraLib; 2. Tabelas de Dados: so usadas para guardar os dados em si, tanto em sua componente espacial quanto descritiva. As tabelas de metadados so automaticamente criadas quando se cria um novo banco TerraLib. Para acessar bancos de dados j existentes, as aplicaes abrem conexes a eles, uma aplicao pode manter conexes a mais que um banco de dados ao mesmo tempo. Ao criar ou abrir uma conexo a um banco de dados as aplicaes devem informar os parmetros exigidos pelo SGDBOR onde est armazenado o banco, como mostra o Exemplo 12.7. Ao final da execuo da aplicao todas as conexes devem ser fechadas.
// Criando um novo banco TerraLib TeDatabase* db = new TeMySQL(); db->newDatabase(dbname, user, password, host);
Modelo do banco de dados
393
// Acessando um banco de dados j criado db->connect(host,user,pass,dbname,0); //... processamento // Fecha a conexo db->close();
Exemplo 12.7 Criao e conexo a um banco TerraLib.
As tabelas de metadados servem para armazenar os conceitos descritos na Seo 12.2. Cada layer criado no banco gera um registro na tabela chamada TE_LAYER, o campo layer_id contm a identificao nica de cada layer no banco de dados. Os outros campos dessa tabela armazenam o nome e o mnimo retngulo envolvente do layer, ou seja, o mnimo retngulo envolvente de todas as geometrias associadas ao layer. Cada representao geomtrica associada a um layer gera um registro na tabela TE_REPRESENTATION. Cada tabela de atributos associada a um layer gera um registro na tabela TE_LAYER_TABLE. Cada vista criada no banco de dados gera um registro em uma tabela chamada de TE_VIEW. Cada instncia de projeo cartogrfica armazenada no banco na tabela TE_PROJECTION. Layers e vistas possuem referncia a um registro da tabela de projees. Cada tema criado gera um registro na tabela TE_THEME. Cada tema possui uma referncia para vista no qual est definido. Para compreender melhor as tabelas do modelo de metadados e os relacionamentos entre elas interessante observar o contedo dessas tabelas aps a execuo de uma seqncia tpica de operaes: Criar um banco de dados; Importar um dado geogrfico de um arquivo para um layer do banco de dados; Criar uma vista; Criar um tema usando o layer criado e inseri-lo na vista.
394
A Figura 12.5 mostra as tabelas do modelo conceitual e seus relacionamentos aps a execuo da seqncia de operaes. Por questes de simplicidade apenas alguns campos das tabelas so mostrados.As tabelas de dados sero descritas mais adiante aps falarmos sobre o modelo de geometrias e de atributos de TerraLib.
Figura 12.5 Principais tabelas do modelo conceitual da TerraLib.
12.5 Modelo de geometrias Conforme descrito na Seo 12.2, na TerraLib os dados geogrficos so agregados em layers. Layers so formados por conjuntos de objetos, onde cada objeto possui uma identificao nica, um conjunto de atributos descritivos e uma representao geomtrica. Essa seo descreve o modelo de classes de geometria da TerraLib. A classe base da qual derivam todas as geometrias de TerraLib chamada de TeGeometry. Cada geometria possui uma identificao nica, a referncia ao seu menor retngulo envolvente e sua projeo e a identificao do objeto geogrfico que representa. As geometrias vetoriais de TerraLib so construdas a partir de coordenadas bi-dimensionais representadas na classe chamada de TeCoord2D. Essas geometrias so:
Modelo de geometrias
395
Pontos: representados na classe TePoint, implementada como uma instncia nica de uma TeCoord2D; Linhas: composta de um ou mais segmentos so representadas na classe TeLine2D, implementada como um vetor de duas ou mais TeCoord2D; Anis: representados pela classe TeLinearRing, so linhas fechadas, ou seja, a ltima coordenada igual a primeira. A classe TeLinearRing implementada como uma instncia nica de uma TeLine2D que satisfaz a restrio de que a primeira coordenada seja igual a ltima;
Polgonos: representados pela classe TePolygon, so delimitaes de reas que podem conter nenhum, um ou mais buracos, ou filhos. So implementados como um vetor de TeLinearRing. O primeiro anel do vetor sempre o anel externo enquanto que os outros anis, se existirem, so buracos ou filhos do anel externo. A fim de otimizar a manuteno das geometrias em memria as classes de geometrias de TerraLib so implementadas segundo o padro de projeto handle/body onde a implementao separada da interface (Gamma et al., 2000). Alm disso, as implementaes so referncias contadas, ou seja, cada instncia de uma classe de geometria guarda o nmero de referncias feitas a ela, inicializado com zero quando a instncia criada. Cada vez que uma cpia dessa instncia solicitada apenas o seu nmero de referncias incrementado e, cada vez que uma instncia destruda, o nmero de referncias a ela decrementada. A instncia efetivamente destruda apenas quando esse nmero chega ao valor zero. Outro aspecto importante das classes de geometria da TerraLib que elas so derivadas ou da classe TeGeomSingle ou da classe TeGeomComposite, representando, respectivamente, que so geometrias com um nico elemento menor (como um TePoint) ou que podem ser compostas de outros elementos menores (como o caso de TePolygon, TeLine2D e TeLinearRing). Esse padro de compostos de elementos menores (Gamma et al. 2000) aplicado tambm em classes que formam conjuntos de pontos, linhas, polgonos e so representados nas classes
396
TePointSet, TeLineSet,
e TePolygonSet. Os padres de projeto so implementados com o recurso de classes parametrizadas como mostrado na Figura 12.6, o que torna o cdigo mais reutilizvel. As geometrias matriciais so representadas na classe TeRaster, que ser descrita por completo no Captulo 13.
Figura 12.6 Diagrama das principais classes de geometria da TerraLib (adaptado de Queiroz, 2003) Um exemplo de criao de geometrias em memria mostrado no Exemplo 12.8.
// Cria um conjunto de linhas TeLine2D reta; reta.add(TeCoord2D(500,500)); reta.add(TeCoord2D(600,500)); reta.add(TeCoord2D(700,500)); reta.objectId("reta"); TeLine2D ele; ele.add(TeCoord2D(700,700)); ele.add(TeCoord2D(800,600)); ele.add(TeCoord2D(900,600));
Modelo de geometrias
397
ele.objectId("ele"); TeLineSet ls; ls.add(reta); ls.add(ele); // Cria um conjunto de polgonos // Um polgono simples TeLine2D line; line.add(TeCoord2D(900,900)); line.add(TeCoord2D(900,1000)); line.add(TeCoord2D(1000,1000)); line.add(TeCoord2D(1000,900)); line.add(TeCoord2D(900,900)); TeLinearRing r1(line); TePolygon poly1; poly1.add(r1); poly1.objectId("spoli"); // Um polgono com um filho TeLine2D line2; line2.add(TeCoord2D(200,200)); line2.add(TeCoord2D(200,400)); line2.add(TeCoord2D(400,400)); line2.add(TeCoord2D(400,200)); line2.add(TeCoord2D(200,200)); TeLinearRing r2(line2); TeLine2D line3; line3.add(TeCoord2D(250,250)); line3.add(TeCoord2D(250,300)); line3.add(TeCoord2D(300,300)); line3.add(TeCoord2D(300,250));
398
line3.add(TeCoord2D(250,250)); TeLinearRing r3(line3); TePolygon poly2; poly2.add(r2); poly2.add(r3); poly2.objectId("cpoli"); TePolygonSet ps; ps.add(poly1); ps.add(poly2); // Cria um conjunto de pontos TePoint p1(40,40); p1.objectId("ponto1"); TePointSet pos; pos.add(p1);
Exemplo 12.9 Criao de geometrias vetoriais em memria.
A TerraLib implementa uma estrutura de dados de espaos celulares, que juntamente com o suporte para predicados temporais atende s necessidades de implementao de modelos dinmicos baseados em espaos celulares. Espaos celulares podem ser vistos ou como uma estrutura matricial generalizada onde cada clula armazena mais que um valor de atributo ou como um conjunto de polgonos que no se interceptam. Essa estrutura traz como uma vantagem a possibilidade de armazenar conjuntamente, numa nica estrutura, todo o conjunto de informaes necessrias para descrever um fenmeno espacial complexo, o que beneficia aspectos de visualizao e interface. Todas as informaes podem ser apresentadas da mesma forma que objetos geogrficos com representao vetorial. Para atender a essa necessidade, a TerraLib prope mais uma geometria chamada TeCell, que representa uma clula em um espao celular materializado na classe TeCellSet. O Exemplo 12.10 mostra como criar um espao celular a partir de um layer armazenado em um banco.
Modelo de armazenamento de geometrias
399
// Recupera o layer de municpios TeLayer* municipios = new TeLayer("Municipoios"); db_->loadLayer(municipios); // Cria um espao celular sobre a extenso do layer // de municpios, onde cada clula tem 100 x 100 metros TeLayer* espaco_cel 100, 100); = TeCreateCells(CellsMunic, municipios,
Exemplo 12.10 Criao de um espao celular.
Cada clula possui uma identificao nica e uma referncia a sua posio dentro do espao celular, a qual podem ser associados diferentes atributos conforme o modelo dinmico sendo construdo. 12.6 Modelo de armazenamento de geometrias A proposta da TerraLib, conforme mostramos na Figura 12.2, trabalhar em bancos de dados geogrficos que podem armazenar tanto atributos descritivos como atributos geomtricos (como pontos, linhas, polgonos e dados matriciais). Esses bancos de dados podem ser construdos em SGDBs que possuem extenses espaciais, ou seja, possuem a capacidade de criar tipos espaciais e manipul-los como tipos bsicos e fornecem mecanismos eficientes de indexao e consulta (Shekkar e Chawla, 2002). Podem tambm ser construdos em SGDBs que oferecerem somente a capacidade de criar tabelas com campos do tipo binrio longo. Na TerraLib esses dois tipos de SGDBs so usados de maneira transparente atravs da classe abstrata TeDatabase. O modelo de armazenamento de geometrias em um banco leva em conta questes relativas eficincia no seu armazenamento e na sua recuperao, e tambm a existncia ou no de um tipo espacial no SGDB. Todas as tabelas que armazenam as geometrias possuem os campos: geom_id: do tipo inteiro, que armazena a identificao nica da geometria; object_id: do tipo texto, que armazena a identificao nica do objeto geogrfico ao qual a geometria est relacionada;
400
armazena o dado geomtrico. O tipo desse campo depende do SGDB onde est armazenado o banco. Para SGDBs com extenso espacial o tipo fornecido pela extenso. Para SGDBs sem a extenso espacial um binrio longo. Para os SGDBs sem extenso espacial as tabelas de geometrias do tipo linhas e polgonos possuem outros campos para armazenar o mnimo retngulo envolvente da geometria (lower_x, lower_y, upper_x, upper_y todos do tipo real). Esses campos so indexados pelos mecanismos fornecidos pelo SGBD e sero usados pelas rotinas de recuperao como os indexadores espaciais do dado. Para os SGDBs com extenso, a coluna com o dado espacial indexada espacialmente pelo mecanismo oferecido pela extenso. A Figura 12.7 mostra a diferena entre uma tabela de geometria do tipo polgono criada em um banco sem extenso espacial e em um banco com extenso espacial. No segundo caso o tipo GEOMETRY representa o tipo espacial fornecido pela extenso. No caso das geometrias do tipo polgono, o modelo de armazenamento em campos longos, prev que cada anel do polgono armazenado em um registro da tabela. O anel externo contm a informao sobre o nmero de filhos que o polgono possui e os anis internos guardam a identificao de seu pai, ou seja, do anel externo no qual esto contidos. Essa forma de armazenamento permite a recuperao parcial de polgonos com um grande nmero de filhos (por exemplo, uma operao de zoom em um mapa em uma rea grande como a Amaznia legal, em uma escala pequena). Como so armazenados os retngulos envolventes de cada filho possvel recuperar somente o pai e os filhos que esto dentro do retngulo envolvente definido pelo zoom. Isso representa uma otimizao no processamento desse dado.
spatial_data:
Modelo de armazenamento de geometrias
401
Tabela de polgonos em SGDBs sem extenso espacial
Tabela de polgonos no Oracle Spatial
Figura 12.7 Modelo de armazenamento de geometrias do tipo polgonos (adaptado de Ferreira, 2003).
A Figura 12.8 mostra como so as tabelas que armazenam geometrias do tipo linhas e a Figura 12.9 as tableas para geometrias do tipo pontos.
Tabela de linhas em SGDBs sem extenso espacial Tabela de linhas no Oracle Spatial
Figura 12.8 Modelo de armazenamento de geometrias do tipo linhas.
402
Tabela de pontos em SGDBs sem extenso espacial
Tabela de pontos no Oracle Spatial
Figura 12.9 Modelo de armazenamento de geometrias do tipo pontos.
12.7 Atributos descritivos Os atributos descritivos dos objetos de um layer so representados em tabelas relacionais onde cada campo representa um atributo do objeto. Um dos campos deve conter a identificao do objeto e seus valores so repetidos nas tabelas de geometria permitindo assim a ligao entre os atributos descritivos e a geometria do objeto. Cada layer pode ter uma ou mais tabelas de atributos e ao serem inseridos no banco de dados cada tabela de atributo registrada na tabela de metadados chamada te_layer_table. Nessa tabela registrada tambm o nome do campo que a chave primria e identificador do objeto. Esse campo serve de ligao entre atributos e geometrias. Ao serem criados, os temas selecionam quais tabelas do layer iro usar. Quando a tabela de atributos no possui nenhuma informao temporal e cada registro representa os atributos de um objeto diferente, a tabela chamada de tabela esttica. Essas classificao semntica das tabelas de atributos uma caracterstica da TerraLib e tem por objetivo definir funes e processamentos dependentes desses tipos. Isso ficar mais claro adiante quando falarmos do processamento de dados espao-temporais. Algumas tabelas de atributos, chamadas tabelas externas, no representam nenhum objeto definido em um layer, mas podem possuir algum campo com valores coincidentes com os valores de um campo de uma tabela esttica de um layer. Atravs de uma operao de juno por esses campos coincidentes uma tabela externa pode acrescentar informaes aos objetos de um layer. Por isso, tabelas externas podem ser incorporadas ao banco e registradas como tal, ficando disponveis para serem usadas em todos os temas do banco.
Atributos descritivos
403
Em memria, as tabelas de atributos so instncias da classe TeTable. Essa classe sabe qual o nome, qual o tipo, quais so os campos e pode conter tambm o seu contedo. No Exemplo 12.11 mostramos como criar uma instncia da classe TeTable em memria e como adicionar alguns registros a essa tabela.
// Cria a lista de atributos da tabela TeAttributeList attList; TeAttribute at; at.rep_.type_ = TeSTRING; at.rep_.numChar_ = 16; at.rep_.name_ = "IdObjeto"; at.rep_.isPrimaryKey_ = true; attList.push_back(at); at.rep_.type_ = TeSTRING; at.rep_.numChar_ = 255; at.rep_.name_ = "nome"; at.rep_.isPrimaryKey_ = false; attList.push_back(at); at.rep_.type_ = TeREAL; at.rep_.name_ = "val1"; at.rep_.isPrimaryKey_ = false; attList.push_back(at); // Cria uma instncia da tabela em memria TeTable attTable("teste2Attr",attList,"IdObjeto","IdObjeto"); row.push_back("reta"); row.push_back("L reta"); row.push_back("11.1"); attTable.add(row); row.clear(); row.push_back("ele"); // um atributo do tipo real // um atributo do tipo string
404
row.push_back("L ele"); row.push_back("22.2"); attTable.add(row); row.clear(); row.push_back("spoli"); row.push_back("Pol simples"); row.push_back("33.3"); attTable.add(row); row.clear(); row.push_back("ponto1"); row.push_back("Um ponto"); row.push_back("55.5"); attTable.add(row); row.clear(); row.push_back("cpoli"); row.push_back("Pol buraco"); row.push_back("44.4"); attTable.add(row); row.clear();
Exemplo 12.11 Criao de uma tabela de atributos em memria.
As sees anteriores tiveram por objetivo explicar o modelo conceitual de um banco de dados geogrfico TerraLib e o modelo fsico de persistncia desse modelo conceitual e dos dados geogrficos. As sees seguintes trataro do acesso ao banco em diferentes nveis de abstrao: no nvel do layer (TeLayer), no nvel da banco de dados (TeDatabase) e no nvel de objetos geogrfico (TeQuerier). 12.8 Acesso ao banco de dados atravs do layer As rotinas de importao que inserem um arquivo de dados geogrfico so escritas usando os mtodos da classe TeLayer (ver Exemplo 12.2). Essa classe fornece mtodos para a insero de geometrias e atributos. Atravs desses mtodos os registros nas tabelas do modelo conceitual so
Acesso ao banco de dados atravs do layer
405
preenchidos corretamente, fazendo as referncias ao identificador do layer quando necessrio. O Exemplo 12.12 deve ser lido como uma seqncia do Exemplo 12.10 e do Exemplo 12.11 e mostra como criar um layer e como usar seus mtodos para inserir no banco de dados as geometrias e atributos criados em memria.
// Cria a definio da projeo do layer TeDatum mDatum = TeDatumFactory::make("SAD69"); TeProjection* pUTM = new TeUtm(mDatum,0.0); // Cria um novo layer chamado "teste" // myDb_ um ponteiro para um banco de dados j conectado TeLayer *layer1 = new TeLayer("teste",myDb_,pUTM); layer1->addGeometries(TeLINES,"tabelaLinhas"); // Insere as linhas criadas em memria layer1->addLines(ls); // Insere os polgonos criados em memria layer1->addPolygons(ps); // Insere os pontos criados em memria layer1->addPoints(pos); // cria a tabela de atributos criada em memria layer1->createAttributeTable(attTable); // salva a tabela de atributos no aco de dados layer1->saveAttributeTable(attTable))
Exemplo 12.12 Insero de geometrias e atributos no banco atravs da classe

TeLayer.
O Exemplo 12.12 mostra como controlar a insero de cada tipo de geometria (pontos, linhas ou polgonos) podendo inclusive especificar o nome para as tabelas de geometrias (como no caso da insero de linhas).
406
TE_LAYER
Layer_id 1 name teste2 repres_id 1 2 3 layer_id 1 1 1
TE_REPRESENTATION
geom_type TePOINTS TeLINES TePOLYGONS geom_table Points1 tabelaLinhas Polygons1
TE_LAYER_TABLE
Table_id 1 layer_id 1 attr_table teste2Attr unique_id IdObjeto attr_link IdObjeto
TESTE2ATTR
IdObjeto Reta Ele Spoli Ponto1 Cpoli nome L reta L ele Pol simples Um ponto Pol buraco val1 11.1 22.2 33.3 55.5 geom_id 1 2 geom_id 1 2 object_id spoli cpoli
POLYGONS1
spatial_data bbbbbbbbb bbbbbbbbb
TABELALINHAS
object_id reta ele spatial_data bbbbbbbbb bbbbbbbbb
POINTS1
geom_id 1 object_id ponto1 x 40 y 40
Figura 12.10 Contedo do banco aps a execuo do Exemplo 10.
interessante verificar o contedo do banco de dados aps a execuo do Exemplo 12.12. Devem ser notados o contedo das tabelas de metadados e as referncias feitas aos nomes das tabelas de geometrias, aos nomes das tabelas de atributos, ao identificador do layer, e o registro dos nomes de colunas usados para relacionar geometrias e atributos. Na Figura 12.10 so representados os contedos essas tabelas e seus relacionamentos. Para efeito de clareza nem todos os campos das tabelas so representados. As linhas contnuas representam relacionamentos fsicos entre os campos das tabelas e as linhas pontilhadas representam
A interface TeDatabase
407
relacionamentos em termos de contedo. Por exemplo, o nome da tabela de atributos e o nome do campo que faz o seu relacionamento com as tabelas de geometrias so registrados na tabela TE_LAYER_TABLE. A recuperao dos dados armazenados no banco, tambm pode ser feita diretamente atravs da classe TeLayer. Essa classe fornece alguns mtodos para recuperar as geometrias de um determinado tipo como mostrado no Exemplo 12.13.
TePolygonSet ps2; layer1->getPolygons(ps2); cout << "Numero de objetos com geometria do tipo poligono: " << ps2.size(); ps2.clear(); // recupera somente os polgonos associados ao objeto com o // identificador spoli layer1->loadGeometrySet("spoli");
Exemplo 12.13 Recuperao de geometrias atravs do layer.
Os mtodos para recuperao de geometrias e atributos atravs da classe so poucos, mas a classe TeDatabase uma interface completa de acesso ao banco de dados, essa interface ser descrita a seguir.
TeLayer
12.9 A interface TeDatabase A classe TeDatabase uma interface completa de manipulao do banco de dados atravs da qual possvel inserir, alterar e recuperar as entidades do modelo conceitual e os dados geogrficos. Ela contm todos os mtodos para criar as tabelas de metadados, as tabelas de geometrias bem como uma tabela de atributos como ilustrado no Exemplo 12.14. Esse exemplo mostra tambm como recuperar um layer do banco e posteriormente como remov-lo. A remoo do layer implica que todos os seus dados e metadados so fisicamente removidos do banco bem como todas as outras entidades do modelo conceitual que fazem referncia a ele. Por exemplo, ao remover um layer do banco todos os temas criados sobre esse layer devem ser removidos tambm.
408
db->createConceptualModel(); // cria todo o modelo conceitual // cria uma tabela que armazena geometrias do tipo polgono db->createPolygonGeometry(TabelaPoligonos); // cria uma tabela de atributos descritivos TeAttributeList meusAttributos; db->createTable(TabelaAtributos, meusAttributos); // cria uma nova coluna em uma tabela j existente TeAttributeRep novaColuna; novaColuna.type_ = TeSTRING; novaColuna.name_ = "novaCol"; novaColuna.numChar_ = 10; db->addColumn(TabelaAtributos, novaColuna); // recupera um layer do banco TeLayer *layer = new TeLayer("Distritos"); // carrega todas as informaes sobre o layer chamado Distritos db->loadLayer(layer); // remove o layer db->deleteLayer(layer->id());
Exemplo 12.14 Mtodos de criao e modificao de tabelas da classe TeDatabase.
A classe TeDatabase tambm fornece mtodos para a insero de geometrias e atributos nas tabelas do banco de dados como mostra o Exemplo 12.15.
TePolygonSet polyset; db->insertPolygonSet(tabPoligono, polyset); TeLineSet lineset; db->insertLineSet (tabLine, lineset);
A classe TeDatabasePortal
409
TePointSet pointset; db->insertPointSet(tabPoint, pointset); TeTable tabAttributes; insertTable(tabAttributes);
Exemplo 12.15 Inseres no banco atravs da classe TeDatabase.
A classe TeDatabase tambm capaz de submeter ao banco comandos escritos em SQL Structured Query Language como mostrado no Exemplo 12.16. Apesar da SQL ser considerada padro para SGDBs relacionais, podem existir algumas variaes em termos da capacidade de execuo de um comando SQL. O mtodo TeDatabase::execute retorna verdadeiro ou falso caso o comando foi executado com sucesso ou no, respectivamente. A classe TeDatabase armazena o erro retornado pelo SGDB resultante do ltimo comando executado sobre o banco.
string sql = UPDATE TabelaAtributos SET novaCol = xxx ; if (db->execute(sql)) cout << Comando executado com sucesso!; else cout << Erro: << db->errorMessage();
Exemplo 12.16 Execuo de um comando SQL.
Note que o mtodo TeDatabase::execute no deve ser usado para comandos que representam consultas ao banco, ou seja, que retornam valores ou registros, mas somente para comandos que alteram as tabelas e registros do banco. 12.10 A classe TeDatabasePortal A classe TeDatabase fornece um mecanismo mais flexvel de consulta ao banco de dados do que apenas atravs dos mtodos da classe TeDatabase. Esse mecanismo implementado pela classe TeDatabasePortal. Os
410
portais de consultas so criados a partir de qualquer instncia da classe TeDatabase que possua uma conexo aberta. Os portais podem submeter consultas SQL ao banco e disponibilizar os registros resultantes da consulta para a aplicao processar. Um banco pode criar quantos portais forem necessrios, porm aps serem consumidos os resultados todo portal deve ser destrudo. O Exemplo 12.17 mostra o uso tpico de um portal.
// Abre um portal no banco de dados TeDatabasePortal* portal = db->getPortal(); if (!portal) return; // Submete uma consulta sql a uma tabela string sql = SELEC * FROM TabelaAtributos; if (!portal->query(sql)) { cout << No foi possvel executar... << db->errorMessage(); delete portal; return; } // Consome todos os registros resultantes while (portal->fetchRow()) { cout << Atributo 1: << portal->getData(0) << endl; cout << Atributo 2: << portal->getData(nome) << endl; cout << Atributo 3: << portal->getDouble(2) << endl; } // Libera os portal para fazer uma nova consulta portal->freeResult(); // Submete uma nova consulta sql = 33.5; SELECT SUM(val1) FROM TabelaAtributos WHERE val1 >
if (portal->query(sql) && portal->fetchRow())
A classe TeDatabasePortal
411
cout << Soma: << portal->getDouble(0); delete portal;
Exemplo 12.17 Uso do TeDatabasePortal.
Analisando o exemplo vemos que aps a chamada do mtodo TeDatabasePortal::query os registros ficam disponveis para serem consumidos em seqncia. Um ponteiro interno posicionado em uma posio anterior ao primeiro registro. A cada chamada ao mtodo TeDatabasePortal::fetchRow o ponteiro interno incrementado e o valor verdadeiro retornado quando o ponteiro est em um registro vlido ou falso caso contrrio. Dessa forma possvel fazer o loop em todos os registros retornados. Os campos de um registro do portal podem ser acessados de duas formas: pela ordem do campo na seleo expressa na SQL (iniciando em zero), ou diretamente pelo nome do campo. O valor do campo pode ser obtido como uma string de caracteres atravs do mtodo TeDatabasePortal::getData independentemente do tipo do campo ou atravs dos mtodos que especificam o tipo de retorno (getDouble, getInt, getDate ou getBlob). Na segunda forma necessrio que a aplicao conhea o tipo do campo sendo acessado. A classe TeDatabasePortal tambm pode executar consultas sobre uma tabela de geometrias e acessar os campos resultantes como os tipos geomtricos da TerraLib, como mostrado no Exemplo 12.18.
// Submete uma consulta sobre uma tabela de geometrias string q =" SELECT * FROM Poligons11 WHERE object_id=cpoli; q += " ORDER BY parent_id, num_holes DESC, ext_max ASC"; if (!portal->query(q) || !portal->fetchRow())) { delete portal; return false; }
412
bool flag = true; do { TePolygon poly; flag = portal->fetchGeometry(poly); // usa o polgono retornado } while (flag); delete portal;
Exemplo 12.18 Uso de um portal para recuperar geometrias.
Essa seo mostrou como utilizar a interface TeDatabase para construir e consultar um banco de dados. As consultas expressas at agora foram sempre baseadas em critrios a serem atendidos sobre atributos descritivos porm, parte importante de um banco de dados geogrfico a consulta por critrios espaciais. A seo seguinte mostra como as operaes espaciais so tratadas na TerraLib. 12.11 Operaes espaciais A TerraLib oferece um conjunto de operaes espaciais sobre geometrias vetoriais e matriciais (uma reviso da literatura e descrio mais detalhada sobre operaes espaciais pode ser encontrada em Ferreira, 2003). As operaes espaciais implementadas na TerraLib podem ser divididas em: Determinao de relacionamentos topolgicos entre geometrias vetoriais: so baseados na matriz de 9-interseces dimensionalmente estendidas onde so formalizadas relaes como toca, intercepta, cobre, disjunto ou -coberto-por, como mostrado no Captulo5. Funes mtricas: como clculo de reas e comprimentos e buffers de distncia; Gerao de novas geometrias: como a gerao de centrides e geometrias convexas; Operaes que combinam geometrias: como diferena, unio e interseco e diferena simtrica;
Operaes espaciais
413
Operaes zonais e focais sobre geometrias matriciais: como a obteno de medidas estatsticas sobre uma regio de um dado matricial e operaes de recorde de uma regio do dado matricial. As operaes espaciais esto implementados em um conjuntos de mtodos da classe TeDatabase que funcionam como uma Interface Genrica de Operaes Espaciais. Essa interface genrica porque, atravs da classe TeDatabase, esses mtodos podem ser chamados da mesma maneira em drivers para SGDBs com extenso espacial ou sem extenso espacial. Drivers para SGDBs com extenso espacial implementam a interface de operaes especiais usando as funes da extenso espacial. Drivers que no possuem a extenso implementam a interface atravs de funes espaciais bsicas escritas sobre as classes de geometria, aps a sua recuperao do banco de dados. Na Figura 12.12 mostramos a diferena de execuo de uma operao espacial, clculo de rea de um objeto, executada em um driver sem extenso espacial (p. ex. ACCESS) e um driver com extenso espacial (p. ex. Oracle Spatial). As operaes sobre dados matriciais foram implementadas somente usando as classes da TerraLib, uma vez que as extenses espaciais ainda no fornecem as operao sobre dados matriciais. Uma descrio completa da interface genrica de operaes espaciais em um banco de dados geogrfico pode ser encontrada em Ferreira (2003).
(a) Banco sem extenso espacial
(b) Banco com extenso espacial
Figura 12.11 Representao da operao de clculo de rea (adaptado de
414 Ferreira, 2003).
O Exemplo 12.19 mostra a execuo de operaes espaciais unrias sobre uma tabela de geometrias do tipo polgono, que representam objetos que so municpios do estado de So Paulo, identificados pelo nome do municpio. Sobre um objeto escolhido (o municpio de So Paulo) so calculados um valor de rea e um buffer de distncia de 1000 metros do objeto. O resultado da operao um conjunto com dois polgonos onde o primeiro o buffer externo e o segundo o buffer interno.
string polyTable = Poligons11; // tabela de polgonos
// Consulta 1: calcular a rea do municpio de So Paulo // Chama uma funo unria sobre a tabela de polgonos vector<string> spId; spId.push_back(So Paulo); double area; db->calculateArea(polyTable, TePOLYGONS, spId, area); // Consulta 2: calcular um buffer de distncia de 1000 metros do municpio de So Paulo // Chama uma funo unria sobre a tabela de polgonos TePolygonSet& bufferSet; db->Buffer(polyTable, TePOLYGONS, spId, bufferSet, 1000.0); // identificadores dos objetos
Exemplo 12.19 Operaes espaciais unrias.
O Exemplo 12.20 mostra a execuo de operaes espaciais envolvendo mais uma tabela de geometrias, que contm geometrias do tipo linhas representando estradas estaduais. Essas operaes so baseadas em consultas sobre relaes topolgicas entre geometrias, no primeiro caso entre geometrias de uma mesma tabela e no segundo entre geometrias de duas tabelas diferentes. interessante notar que o resultado retornado em um portal de forma que a aplicao possa consumir cada geometria resultante uma a uma.
string lineTable = Lines12; // tabela de linhas
Operaes espaciais
415
TeDatabasePortal result = db->getPortal();
// portal
// Consulta 3: quais os municpios que tocam So Paulo? // Chama uma funo binria sobre a tabela de polgonos if (db->spatialRelation(polyTable, TeTOUCHES)) { bool flag = true; do { TePolygon poly; flag = result->fetchGeometry(poly); // polgono retornado } while (flag); } result->freeResult(); TePOLYGONS, spId, result,
// Consulta 4: quais as estradas que cruzam So Paulo? // Funo binria entre a tabela de polgonos e de linhas if (db->spatialRelation(polyTable, TePOLYGONS, spId, lineTable, TeLINES, result, TeINTERSECTS)) { bool flag = true; do { TeLine line; flag = result->fetchGeometry(line); // linha retornada } while (flag); }
Exemplo 12.20 Operaes Espaciais para a consulta de relacionamentos topolgicos.
O Exemplo 12.21 mostra as operaes Zonal e Recorte de um dado matricial. Na operao zonal, um conjunto de estatsticas (por exemplo soma, valor mximo, valor mnimo, contagem, mdia, varincia, etc.) calculado sobre a regio do dado matricial contida dentro de um polgono que representa a zona de interesse. O resultado fornecido em uma
416
estrutura prpria que armazena as estatsticas calculadas em cada dimenso do dado matricial. Na operao de recorte o dado matricial recortado pela zona de interesse, o resultado um novo layer no banco de dados. A implementao dessa funo foi feita usando o conceito de iterador sobre uma representao matricial, ou seja, um ponteiro que percorre todos os elementos do dado matricial. No caso da operao de recorte, foi usada uma especializao do conceito de iterador sobre dados matriciais, de forma que esse percorra somente os elementos que possuam uma certa relao com a regio de interesse. As relaes possveis so que a rea do elemento esteja toda dentro da regio, que a rea do elemento esteja toda fora da regio, que o centro do elemento esteja dentro da regio ou que o centro do elemento esteja fora da rea de interesse.
string rasterTable = RasterLayer12; TePolygon reg; TeStatisticsDimensionVect result; // Consulta 5: Calcular as estatsticas usando como regio de interesse // o polgono defindo em reg db->Zonal(rasterTable, reg, result); // Consulta 5: Recortar o dado matricial usando como regio de interesse o polgono // definido em reg TeStrategicIterator st = TeBoxPixelIn; db->Mask(rasterTable, reg, Recorte, st); do dado matricial // tabela de linhas
Exemplo 12.21 Operaes sobre dados matriciais.
As rotinas que implementam as operaes espaciais sobre as estruturas geomtricas tambm esto disponveis para serem usadas diretamente pelas aplicaes. Essas rotinas so funes parametrizadas de forma a poder serem chamadas com a mesma assinatura, tomando como
Dados espao-temporais
417
parmetros as diferentes classes de geometrias vetoriais, como mostrado no Exemplo 12.22. Uma descrio completa da das operaes espaciais da TerraLib est em Queiroz (2003).
TeLine line1; TeLine line2; bool res = TeOverlaps(line1, line2); TePolygon pol1; TePolygon pol2; res = TeOverlaps(pol1, pol2);
Exemplo 12.22 Chamada de operaes espaciais sobre geometrias.
12.12 Dados espao-temporais A TerraLib tem uma proposta de trabalhar com dados geogrficos espaciais e temporais, ou seja, de considerar a componente temporal dos dados geogrficos, quando houver. Como exemplos de dados espaotemporais podemos identificar: Eventos: ocorrncias independentes no espao e no tempo, que possuem um rtulo temporal de quando o evento ocorreu. Esse o caso de crimes que ocorrem em uma determinada localizao de uma cidade em uma determinada data e hora. Cada objeto espacial associado a um associado a um evento ter uma nica identificao no banco de dados; Objetos Mutveis: os quais possuem uma geometria fixa ao longo do tempo, porm seus atributos descritivos podem variar. Um exemplo desse tipo de objeto so os dados manipulados por modelos dinmicos baseados em espaos celulares, ou estaes fixas de coletas de dados; Objetos em Movimento: os quais possuem limites e localizaes, ou seja, geometrias que podem variar no tempo assim como seus atributos descritivos. Esse o caso quando se acompanha a evoluo de dos lotes de uma cidade, ou dos polgonos de desmatamento de uma regio.
418
No modelo de banco de dados geogrfico proposto pela TerraLib os dados so registrados semanticamente em funo da sua natureza temporal com o objetivo de possam ser construdas funcionalidades especficas relativas a essa natureza temporal. Entre essas funcionalidades esto includos os algoritmos de agrupamento temporal, visualizao de animaes ou criao de temas com restries temporais e ferramentas de modelagem dinmica. Assim, quando uma tabela de atributos, associada a um layer, inserida em um banco de dados, uma das informaes registradas na tabela de metadados TE_LAYER_TABLE qual o seu tipo, e dependendo desse tipo outras informaes so necessrias. Alm das tabelas estticas e externas descritas anteriormente (ver Seo 12.7) os outros tipos de tabelas so: Eventos: uma tabela de atributos de eventos. preciso registrar qual de seus campos possui a identificao nica do evento (e que faz a ligao com sua geometria) e quais de seus campos possuem a informao temporal da ocorrncia do evento. A informao temporal normalmente um intervalo (tempo inicial e tempo final), mas para rtulos temporais pontuais o tempo inicial igual ao tempo final; Atributos Variveis: uma tabela de atributos relacionada a dados do tipo objetos mutveis. preciso identificar quais o campo possui a identificao nica do objeto no banco (e que faz a ligao com sua geometria), qual campo identifica de maneira nica cada verso, ou instncia de atributos associada ao objeto, e quais campos possuem a informao temporal que determina o intervalo de validade dessa instncia. O modelo de armazenamento dos objetos em movimento ainda est sendo desenvolvido na TerraLib, uma vez que esse o caso mais complexo. Alm de se considerar a variao no tempo associado aos atributos dos objetos preciso considerar a variao associada s suas geometrias. Cada geometria tem que armazenar um intervalo (ou instante) de validade e necessrio propor um mecanismo de associao, em um determinado instante ou intervalo, entre a geometria e os atributos do objeto.
419
Nas classes da TerraLib o modelo de tratamento de dados espaotemporais est distribudo nas classes TeSTInstance, TeSTElement, TeSTElementSet e TeQuerier. A classe TeSTInstance da representa uma instncia, ou verso, no tempo de um elemento ou objeto geogrfico. Uma instncia contm o identificador do elemento ou objeto ao qual pertence, um intervalo de tempo de validade, suas geometrias e seus de atributos. Todas as instncias de um mesmo elemento ou objeto geogrfico so representadas pela classe TeSTElement. A classe TeQuerier implementa um mecanismo flexvel de consulta ao banco de dados e recuperao de objetos e suas instncias, dinmicos ou esttico no tempo. No segundo tipo cada objeto tem apenas uma nica instncia.
// Recupera o layer de estaes de coletas, ou armadilhas TeLayer* armadilhas = new TeLayer("LAYER_ARMADILHAS"); db_->loadLayer(armadilhas); // Preenche os parmetros da consulta // carregar todos os atributos dos objetos bool loadAllAttributes = true; // no carregar as geometrias dos objetos bool loadGeometries = false; TeQuerierParams loadAllAttributes); querierParams(loadGeometries,
// carregar as instncias dos objetos do layer querierParams.setParams(armadilhas); // Cria uma consulta a partir dos parmetros // Carrega as instncias de objetos do banco que atendem aos critrios da consulta TeQuerier querier(querierParams); querier.loadInstances(); // Retorna a lista mostra seus nomes dos atributos descritivos carregados e
420
unsigned int i; TeAttributeList attrList = querier.getAttrList(); for (i=0; i<attrList.size(); ++i) cout << attrList[i].rep_.name_ << endl; // Percorre as instncias selecionadas uma a uma TeSTInstance sti; while(querier.fetchInstance(sti)) { cout << " Object: " << sti.objectId() << endl << endl; // Mostra o nome e valor de cada atributo da instncia TePropertyVector vec = sti.getPropertyVector(); for (i=0; i<vec.size(); ++i) { string string } } attrName = vec[i].attr_.rep_.name_; attrValue = vec[i].value_; << " : " << attrValue << endl;
cout << attrName
Exemplo 12.23 Aplicao de um TeQuerier para recuperar as instncias dos objetos de um layer.
A classe TeQuerier contm uma srie de parmetros que definem quais instncias de quais objetos e quais atributos desses objetos devem ser recuperados. Uma vez definidos os parmetros do TeQuerier e aplicada a seleo, as aplicaes podem processar as instncias retornadas uma a uma. O Exemplo 12.23 mostra como criar um TeQuerier para recuperar todas os objetos de um layer e processar todas as instncias desses objetos. O layer utilizado no exemplo agrega objetos armadilhas para a coleta de ovos de um determinado inseto, causador de uma doena. A cada semana as armadilhas so visitadas e o nmero de ovos na armadilha e outros parmetros da so observados e inseridos no banco. Esse dado do tipo geometrias fixas e atributos variveis no tempo. A armadilha no muda, mas seu atributo quantidade de ovos varia a cada semana. Um TeQuerier tambm pode carregar todos objetos definidos em um tema, lembrando que um tema pode definir um subconjunto dos objetos de um layer. A seleo expressa no TeQuerier vai levar em conta as restries definidas no tema sendo recuperado. O Exemplo 12.24 mostra
421
uma consulta para recuperar todas as instncias, atributos e geometrias dos objetos pertencentes s armadilhas do tipo A.
// Recupera o tema com somente as armadilhas do tipo A TeTheme* armadilhasTipoA = new TeTheme("Armadilhas_A"); db_->loadTheme(bairros); // Preenche os parmetros da consulta // carregar todos os atributos dos objetos bool loadAllAtt = true; // carregar as geometrias dos objetos bool loadGeom = true; // carregar as instncias dos objetos do tema TeQuerierParams querierParams(loadGeom, loadAllAttr); querierParams.setParams(armadilhasTipoA); // Cria uma consulta e carrega as instncias // de objetos do banco que atendem aos critrios da consulta TeQuerier querier(querierParams); querier.loadInstances(); // Percorre as instncias selecionadas uma a uma TeSTInstance sti; while (querier.fetchInstance(sti)) { if (sti.hasPoints()) { TePointSet ponSet; sti.getGeometry(ponSet); for (unsigned int i=0; i<ponSet.size(); ++i) { cout << " Point : " << ponSet[i].location().x() << ", "; cout << ponSet[i].location().y() << endl; } } }
Exemplo 12.24 Aplicao de um TeQuerier para recuperar as instncias dos objetos de um tema.
422
O Exemplo 12.25 mostra como incluir uma restrio espacial nos parmetros da consulta a ser expressa no TeQuerier, mostra tambm como selecionar apenas alguns atributos dos objetos. O exemplo seleciona somente as instncias das armadilhas que esto dentro do polgono que delimita certo bairro, e para cada instncia de armadilha seleciona somente o atributo nro_ovos.
TePolygonSet limiteBairro; // Preenche os parmetros da consulta vector<string> attributes; attributes.push_back ("ARMADILHAS. NRO_OVOS"); bool loadGeom = true; // carregar as geometrias dos objetos TeQuerierParams querierParams(loadGeom, attributes); querierParams.setParams(armadilhas); // carregar as instncias dos objetos do tema querierParams.setSpatialRest(limiteBairro);
Exemplo 12.25 Definio de uma consulta com restrio espacial e com seleo de somente um atributo.
A classe TeQuerier tambm pode expressar agrupamentos de valores de atributos de as instncias por objeto, por restrio espacial ou ainda por unidades (chronons) de tempo. O Exemplo 12.16 mostra como agrupar por armadilha todas as instncias do seu atributo nro_ovos atravs de uma operao de soma.
// Cria uma definio de agrupamento do atributo nro_ovos // atravs da operao de soma TeGroupingAttr attributes; pair<TeAttributeRep,TeStatisticType> attr1(TeAttributeRep("ARMADILHAS.NRO_OVOS"), TeSUM); attributes.insert(attr1); // Opo 1: Consulta de instncias agrupadas por objeto
423
// Resultado vai ser uma nica instncia por objeto TeQuerierParams querierParams(loadGeom, attributes); querierParams.setParams(armadilhas);
Exemplo 12.26 Consulta de instncias agrupadas por objetos.
Os Exemplo 12.25 e 12.26 mostram como usar a classe TeQuerier para expressar uma seleo de objetos e suas instncias no tempo. Uma caracterstica importante que atravs desse mecanismo no necessrio armazenar em memria todas as instncias selecionadas, j que essas podem ser processadas e descartadas uma a uma. Cada instncia carregada para a memria somente quando requisita atravs do mtodo TeQuerier::fetchInstance. Uma alternativa para carregar para a memria todas as instncias de todos os objetos de uma seleo atravs da classe TeSTElementSet. Essa classe funciona como uma estrutura de agregao que armazena em memria as instncias dos objetos com suas geometrias e atributos descritivos, fornecendo mecanismos para o seu percorrimento. A TerraLib fornece algumas funes de preenchimento da estrutura TeSTElementSet como mostramos no Exemplo 12.27.
// Recupera o layer de estaes de coletas TeLayer* armadilhas = new TeLayer("LAYER_ARMADILHAS"); db_->loadLayer(armadilhas); // Cria um STElementSet para os objetos do layer de armadilhas TeSTElementSet steSet(armadilhas); // Carrega STElementSet carregando cada instncia com todos os seus atributos e sua geometria TeSTOSetBuildDB(&steSet, true, true); cout << "Nmero de elementos steSet.numElements() << endl; no conjunto: " <<
// Percorre elementos e suas intncias atravs de iteradores TeSTElementSet::iterator it = steSet.begin(); while ( it != steSet.end()) {
424
TeSTInstance st = (*it); cout << " Id do objeto : if (sti.hasPoints()) { TePointSet ponSet; sti.getGeometry(ponSet); for (unsigned int i=0; i<ponSet.size(); ++i) { cout << " Point : " << ponSet[i].location().x() << ", "; cout << ponSet[i].location().y() << endl; } } ++it; } " << st.objectId() << endl;
Exemplo 12.27 Criao de um TeSTElementSet.
Essa seo mostrou os mecanismos para tratar dados espao-temporais da TerraLib. Esses mecanismos so baseados no registro da caracterstica temporal das tabelas de atributos no banco de dados e expresso dos conceitos de objetos com uma identidade nica e persistente ao longo do tempo e de instncias no tempo de atributos e geometrias desses objetos. 12.13 Funes de processamento de dados geogrficos Essa Seo descreve resumidamente algumas das funes de processamento oferecidas pela TerraLib, implementadas usando as estruturas e mecanismos descritos nas sees anteriores. Matriz de Proximidade Generalizada: e uma extenso da matriz de proximidade usada em muitos mtodos de anlise espacial (Souza et. al, 2003). A TerraLib oferece as funes para gerar matriz de proximidade seguindo diferentes critrios, como por exemplo adjacncia ou distncia mnima, e para ponderar e fatiar a matriz segundo algum atributo. Alm disso, uma matriz de proximidade pode ser gerada a partir de um TeSTElementSet. Algoritmos de anlise espacial: incluem algoritmos para gerao de superfcies de kernel, ndices de correlao espacial como LISA, Moran e Bayesiano local e global. Para saber mais sobre anlise espacial de dados geogrficos consulte Bayley e Gatrell, (1995).
Funes de processamento de dados geogrficos
425
Operaes Geogrficas: combinam temas para gerar novos layers gerando novos atributos e novas geometrias vetoriais. Essas funes incluem a agregao de objetos por atributos, por exemplo, a agregao de municpios pelo atributo estado, gerando um layer de estados a partir de um layer de municpios. Incluem tambm funes de associao de dados por localizao, por exemplo, atribuindo ao layer de municpios valores de atributos calculados a partir de todas as ocorrncias de crime que acontecem dentro do municpio. Geocodificao de endereos: implementa o processo de associar uma coordenada geogrfica a um evento tendo por base um layer que contenha os endereos que se deseja encontrar. Deste modo, uma vez associado a uma localizao, o endereo pode ser usado para visualizao dos eventos sobre um mapa ou utilizado para anlises. Atualmente comeam a ser integrados na TerraLib funes de processamento de imagens como segmentao e classificao, e interpolao de superfcies a partir de amostras.
426
Referncias
BAILEY, T.; GATRELL, A. Interactive Spatial Data Analysis. London: Longman Scientific and Technical,1995. CMARA, G.; SOUZA, R. C. M.; PEDROSA, B.; VINHAS, L.; MONTEIRO, A. M. V.; PAIVA, J. A.; CARVALHO, M. T.; GATTASS, M. TerraLib: Technology in Support of GIS Innovation. In: II Simpsio Brasileiro em Geoinformtica, GeoInfo2000, 2000, So Paulo. DAVIS, C.; CMARA, G. Arquitetura de Sistemas de Informao Geogrfica. In: CMARA, G.; DAVIS, C.; MONTEIRO, A. M. V. (Org.). Introduo cincia da geoinformao. So Jos dos Campos: INPE, out. 2001. cap. 3. FERREIRA, K. R.; QUEIROZ, G. R.; PAIVA, J. A. C.; SOUZA, R. C. M.; CMARA, G. Arquitetura de Software para Construo de Bancos de Dados Geogrficos com SGBD Objeto-Relacionais. p. 57-67, 2002. XVII Simpsio Brasileiro de Banco de Dados. GAMMA, E.; HELM, R.; JOHNSON, R.; VLSSIDES, J. Design Patterns Elemens of Reusable Object-Oriented Software. Reading, MA: AddisonWesley,1995. 395 p. INPE-DPI. O aplicativo TerraView. Disponvel em: <http://www.dpi.inpe.br/terraview>. Acesso em: maio 2005. MySQL AB. MySQL reference manual. Disponvel em: <http://www.mysql.org>.Acesso em: abril 2005. Open GIS Consortium. Web Map Service Version 1.13. Disponvel em: <http://www.opengeospatial.org>. Acesso em: maio 2005. QUEIROZ, G. R. Algoritmos Geomtricos para Banco de Dados geogrficos: da teoria prtica na TerraLib.So Jos dos Campos, SP: INPE - Instituto Nacional de Pesquisas Espaciais, 2003. Dissertao de Mestrado, Computao Aplicada, 2003. SHEKHAR, S.; CHAWLA, S. Spatial Databases: A Tour. Prentice Hall,2002. SNYDER, J. P. Map Projections A Working Manual. Washington, DC, USA: United States Government Printing Office,1987. SOUZA, R. C.; CMARA, G.; AGUIAR, A. P. D. Modeling Spatial Relations by Generalized Proximity Matrices. In: V Simpsio Brasileiro de Geoinformtica, 2003, Campos do Jordo. Anais do GeoInfo 2003. So Jos dos Campos : SBC, 2003. STROUSTROUP, B. C++ Programming Language - 3rd Edition. Reading, MA: Addison-Wesley,1997. 911 p.
13 Tratamento de dados matriciais na TerraLib

Lbia Vinhas Ricardo Cartaxo Modesto de Souza
13.1 Introduo Esse captulo descreve a soluo adotada na biblioteca TerraLib (Cmara et al., 2000) para o tratamento de dados matriciais incluindo a decodificao de diferentes formatos e o seu armazenamento e recuperao em bancos de dados objeto-relacionais. Os bancos de dados geogrficos ainda possuem um desafio: o tratamento eficiente de dados matriciais, mais especificamente de dados de imagens de satlites. As imagens de sensoriamento remoto so uma das mais procuradas fontes de informao espacial para pesquisadores interessados em fenmenos geogrficos de larga escala. A variedade de resolues espectrais e espaciais das imagens de sensoriamento remoto grande, variando desde as imagens pancromticas do satlite IKONOS, com resolues espaciais de um metro, at as imagens polarimtricas de radar que em faro parte da nova gerao de satlites RADARSAT e JERS. Os recentes avanos da tecnologia de sensoriamento remoto, com o desenvolvimento de novas geraes de sensores, tm trazido considerveis avanos nas aplicaes de monitoramento ambiental e de planejamento urbano (Moreira, 2004). A construo de bancos de dados geogrficos capazes de manipular imagens de satlites tem sido amplamente estudado na literatura e a abordagem principal tem sido o desenvolvimento de servidores de dados especializados, como o caso do PARADISE (Patel et al., 1997) e do RASDAMAN (Reiner et al., 2002). A vantagem principal dessa abordagem a capacidade de melhora de desempenho no caso de grandes bases de dados de imagens. A principal desvantagem dessa abordagem a
426
necessidade de um servidor especfico o que sobrecarrega o SIG Sistemas de Informao Geogrfica. Alm das imagens de satlite os SIG tambm devem ser capazes de tratar outros tipos de geo-campos, cuja representao computacional mais adequada a matricial. Esses dados incluem grades numricas que representam fenmenos qualitativos contnuos, como superfcies de fenmenos fsicos (por exemplo, altimetria), ou sociais (por exemplo, excluso social). A Figura 13.1 mostra dois exemplos de dados geogrficos diferentes com representao matricial: uma foto area e uma superfcie de altimetria.
Figura 13.1 Exemplos de dados matriciais.
Os SIGs precisam trabalhar de maneira integrada com dados matriciais de diferentes naturezas e na mesma base de dados geogrfica, que pode conter tambm geo-objetos com representao vetorial. A implementao de um sistema de manipulao de dados matriciais, como grades e imagens de sensoriamento remoto, em um SGDB-OR, juntamente com funes para tratar outros tipos de dado espaciais de grande importncia para os SIG, e traz vantagens sobre sistemas especializados para construir bases de dados de imagens. A infra-estrutura objeto-relacional pode ser usada para construir um sistema de indexao espacial, o que permite a consulta e recuperao de dados matriciais integrada interface genrica de manipulao de dados matriciais. Atravs da indexao adequada, algoritmos de compresso e sistemas de cache um desempenho satisfatrio pode ser conseguido, para
Caractersticas dos dados matriciais
427
os SIGs manipulando bases de dados compostas de representaes matriciais e vetoriais. 13.2 Caractersticas dos dados matriciais Dados matriciais em TerraLib ser entendidos como qualquer dado representado em uma estrutura de matriz retangular com M linhas N colunas. Exemplos desse tipo de dado so grades regulares com valores de uma determinada grandeza (como uma grade de altimetria) ou imagens de sensoriamento remoto. Dados matriciais podem possuir outras dimenses alm das duas representadas no plano cartesiano das linhas e colunas. Ou seja, a cada elemento da matriz podem estar associados um ou mais valores. Por exemplo, as imagens multi-dimensionais de sensoriamento remoto possuem em cada elemento, ou pixel, da imagem o valor relativo a uma banda espectral do instrumento imageador que obteve a imagem. Por esse ser o caso mais tpico de dados matriciais multi-dimensionais, em TerraLib dizemos que um dado matricial possui M linhas M colunas B bandas, como representado na Figura 13.2.
Colunas Linhas
...
Bandas
Figura 13.2 Representao matricial multi-dimensional.
Cada posio da representao matricial chamada de elemento (equivalente a um pixel, no caso de imagens) e costuma ser ter sua posio identificada por um par (linha coluna), onde a posio (0,0) equivale linha mais superior e a coluna mais esquerda da matriz. Cada elemento,
428
em uma dimenso, pode conter um valor dentro de um determinado intervalo de valores possveis. Esse intervalo dependente do tamanho computacional (ou digital) reservado para seu armazenamento e todos os elementos possuem o mesmo tamanho. Alguns tamanhos possveis para cada elemento so: Unsigned Char: ocupa 8 bits por elemento. Pode armazenar valores entre 0 a 255; Short: ocupa 16 bits por elemento. Pode armazenar valores entre 32.68 to 32.67 Float: ocupa 32 bits por elemento. Pode armazenar valores entre 3.4E-38 a 3.4E+38 (7 dgitos);
Double: ocupa 64 bits por elemento. Pode armazenar valores entre 1.7E- 308 a 1.7E+308 (15 dgitos). No caso das imagens de sensoriamento remoto o tamanho do elemento relaciona-se com a resoluo espectral da imagem e no caso de outros tipos de dados esse valor relaciona-se com a preciso do dado que est sendo representado. Computacionalmente, a representao matricial no esparsa, ou seja, todo elemento da matriz possui um valor. Porm muitas vezes necessrio ser possvel a criao de uma representao esparsa, ou seja, uma representao onde em alguns pontos da matriz no existe um valor vlido. Isso pode ser feito atravs da escolha de um valor como indicativo da ausncia de dado naquele elemento da matriz. Esse valor deve pertencer ao intervalo de valores vlidos para os elementos da matriz e chamado de valor dummy ou nodata. A Figura 13.3 (a) mostra um dado matricial, com 3 linhas 3 colunas 1 banda. Se o valor 0 for considerado como valor dummy, podemos dizer que nas posies (0,1) e (2,2) no existem valores vlidos. Outra caracterstica dos dados matriciais e que os valores em cada elemento podem representar ndices para uma tabela de combinaes de valores, como no caso tpico de imagens do tipo paleta. O valor de cada elemento uma chave para uma tabela que contm uma tripla de valores R, G e B como mostrado na Figura 13.3(b).
Tratamento de dados matriciais em TerraLib
429
1 1 2
0 2 1
2 3 0
Chave 1 2 3
R 255 0 0
G 0 255 0
B 0 0 255
(a) Valores Dummy
(b) Tabela de cores
Figura 13.3 Caracterstica da representao matricial.
Finalmente, as representaes matriciais so caracterizadas pela resoluo de cada elemento da grade, ou seja, a extenso nas direes horizontal e vertical de cada elemento da matriz quando mapeado para a rea da superfcie da Terra que representa. No caso das imagens de satlite esses parmetros equivalem resoluo espacial da imagem. A seo seguinte descreve os mecanismo de tratamento de dados matriciais de TerraLib. 13.3 Tratamento de dados matriciais em TerraLib Imagens e/ou quaisquer outros tipos de dados com representao matricial so manipulados em TerraLib por trs classes bsicas: Uma classe genrica chamada TeRaster; Uma estrutura de dados que representa todos os parmetros que caracterizam um dado matricial TeRasterParams; Uma classe genrica de decodificao de formatos e acesso a dispositivos de armazenamento de dados matriciais chamada TeDecoder.
13.3.1 A classe TeRaster A classe TeRaster uma interface genrica de acesso aos elementos de um dado matricial. Seus dois mtodos bsicos so: setElement e getElement, os quais inserem e recuperam, respectivamente, valores de cada elemento da representao matricial como um valor real de dupla preciso. O Exemplo 13.1 mostra como criar uma representao matricial em
430
memria atravs da classe TeRaster. A representao matricial tem 10 linhas, 10 colunas, 2 bandas e cada elemento (em cada banda) pode conter um valor do tipo unsigned char.
TeRaster rasterMem(10,20,2,TeUNSIGNEDCHAR);
Exemplo 13.1 Criao de uma representao matricial em memria.
Antes que o dado esteja disponvel para ser manipulado, todas as inicializaes necessrias, como alocaes de memria, devem ser executadas e esto concentradas no mdodo TeRaster::init. Aps a chamada desse mtodo cada instncia da classe TeRaster possui um valor de estado que indica quais as operaes (leitura, escrita) podem ser executadas sobre ele. O Exemplo 13.2 mostra a chamada e teste de estado na criao de um dado matricial atravs da classe TeRaster.
// 1) cria um objeto raster
TeRaster rasterMem(10,20,2,TeUNSIGNEDCHAR);
// 2) faz inicializaes
rasterMem.init();
// 3) verifica resultado
if (rasterMem.status() == TeNOTREADY) return false;
Exemplo 13.2 Inicializao de um dado matricial.
13.3.2 A classe TeRasterParams Um dado matricial caracterizado por uma srie de parmetros que podem ser divididos nas seguintes categorias: Dimenso: nmero de linhas, nmero de colunas e nmero de bandas; Geogrficos: projeo cartogrfica, resoluo horizontal, resoluo vertical e menor retngulo envolvente de todo o dado. Como cada
431
elemento de um dado matricial tem rea, podemos identificar dois tipos de retngulo envolvente: o que passa pelo centro dos elementos das bordas (chamamos de box) e o que passa pelos extremos dos elementos das bordas da matriz (chamamos de bounding box) como representado na Figura 13.4;
Box
Bounding Box
Figura 13.4 Diferena entre box e bounding box. Caractersticas dos elementos: tamanho digital de cada valor de um elemento e interpretao do valor (paleta ou no); Armazenamento: nome de arquivo ou tabela de banco de dados onde est armazenado, tipo acesso permitido; Forma de decodificao: mecanismo usado para ler ou escrever um valor em um elemento.
A classe TeRasterParams contm um super conjunto de todos os possveis parmetros que descrevem um dado matricial, por isso cada objeto da classe TeRaster possui como um dos seus membros um objeto da classe TeRasterParams, que pode ser acessado atravs do mtodo TeRaster::params como mostro o Exemplo 13.3.
void describe(TeRasterParams& par) { cout << "Nome: " << par.fileName_ << endl; cout << "Modo de acesso: " << par.mode_ << endl; cout << "Nro bandas: " << par.nBands() << endl; cout << "Nro linhas: " << par.nlines_ << endl; cout << "Nro colunas: " << par.ncols_ << endl; cout << "Resolucao X: " << par.resx_ << endl;
432
cout << "Resolucao Y: " << par.resy_ << endl; cout << "Identificacao par.decoderIdentifier_<< endl; do decodificador: " <<
cout << "Projecao: " << par.projection()->name() << endl; cout << "Retangulo envolvente: "; TeBox bb = par.boundingBox(); cout << bb.x1_ << " " << bb.y1_ << " " << bb.x2_ << " " << bb.y2_ << endl; } TeRaster rasterMem(10,10,2,TeUNSIGNEDCHAR); rasterMem.init(); if (rasterMem.status() == TeNOTREAD) return 0; describe(rasterMem.params());
Exemplo 13.3 Parmetros do dado matricial.
Os diferentes formatos de armazenamento de dados matriciais podem trazer todos ou alguns dos parmetros citados acima. Vejamos como exemplo: Tiff: dados matriciais nesses formatos trazem informaes sobre o nmero de Linhas, o nmero de Colunas, o nmero de Bandas, o tipo dos elementos e a interpretao do elemento (se do tipo paleta e sua tabela de cores); GeoTiff: uma extenso do formato Tiff especfica para o armazenamento de dados geogrficos (grades numricas ou imagens) e traz alm das informaes do Tiff, a projeo e retngulo envolvente da imagem, o tipo e a resoluo espacial dos elementos, e a sua projeo cartogrfica. O GeoTiff o formato de intercmbio de dados matriciais do consrcio OpenGIS (OPENGIS, 2005); JPEG: formato para armazenamento de imagens, traz informaes sobre o nmero de Linhas, o nmero de Colunas e o nmero de
433
Bandas. O formato JPEG permite armazenar apenas dados com 1 ou 3 bandas e o tipo dos elementos sempre unsigned char; RAW: servem para armazenar grades ou imagens como arquivos binrios sem nenhuma formatao e no trazem nenhuma informao sobre a representao matricial.
A estrutura TeRasterParams armazena tambm o nvel de acesso ao dado, que pode assumir 3 opes: 1. r: somente leitura. Caso o dado no exista o mtodo TeRaster::init falhar; 2. c: criao de um novo. Caso o dado j exista, ser apagado e recriado. Ser garantido acesso para leitura e escrita; 3. w: leitura e escrita. Pressupe que o dado j exista. Caso contrrio o mtodo TeRaster::init falhar. 13.3.3 A classe TeDecoder A idia principal da classe TeRaster poder representar dados matriciais que podem estar em memria, em arquivos em diferentes formatos (como TIFF ou JPEG), ou ainda dentro do um banco de dados geogrfico. Com o objetivo de desacoplar a classe TeRaster das diferentes alternativas de armazenamento, as requisies de acesso aos elementos da representao matricial so tratadas pela classe TeDecoder. Esse mecanismo um exemplo de uso do padro de projeto Strategy (Gamma, Helm et al. 1995). A classe TeDecoder abstrata e TerraLib j fornece um conjunto de decodificadores de imagens e grades. Novos decodificadores podem ser criados atravs da especializao da classe TeDecoder implementando os mtodos init, clear, setElement e getElement. A Tabela 13.1 mostra as caractersticas das classes de decodificadores j implementadas em TerraLib.
434
Tabela 13.1 Decodificadores de Dados Matriciais implementados em TerraLib Decodificadores

TeDecoderMemory
Identificador Extenso Acesso MEM ---
Descrio
Criao Dados matriciais Leitura como uma matriz de valores em memria Escrita
TeDecoderJPEG
JPEG
.jpg Criao Dados matriciais .jpeg Leitura armazenados em arquivos no formato Escrita JPEG. Carregam todo o dado para memria .tif .tiff Criao Dados matriciais Leitura armazenados em arquivos no formato GeoTIFF ou TIFF Criao Dados matriciais Leitura armazenados em arquivos no formato Escrita ASCII Spring. Carregam todo o dado para memria Criao Dados matriciais Leitura armazenados em arquivos binrios Escrita raw, limitados a aproximadamente 2Gb de tamanho Criao Dados matriciais Leitura armazenados em arquivos binrios raw Escrita Criao Dados matriciais Leitura armazenados em um banco de dados Escrita TerraLib
TeDecoderTIFF
TIFF
TeDecoderSPR
SPR
.spr .txt
TeDecoderMemoryMap
MEMMAP
.raw
TeDecoderFile
FILE
.bin
TeDecoderDatabase
DB
---
435
A associao de um decodificador especfico a um dado matricial pode ser feita explicitamente, mas tambm foi implementado um mecanismo mais flexvel usando o padro de projeto Factory (Gamma, Helm et al. 1995). Existe uma fbrica de decodificadores que constri a instncia de decodificador correta de acordo com um ou mais parmetros do dado matricial. Um exemplo tpico de uso desse mecanismo automtico de seleo associao de extenses de arquivos a decodificadores especficos. Quando possvel, a associao de extenses de arquivos a decodificadores o que permite que um objeto da classe TeRaster possa ser instanciado a partir somente de um nome de arquivo. Essa associao pode ser modificada, conforme interesse do usurio da biblioteca, editando-se a funo TeInitRasterDecoders. O Exemplo 13.4 mostra o acesso a dois dados matricias, nesse caso arquivos de imagens em dois formatos diferentes, TIFF e JPEG, de forma transparente.
// Mostra os valores em um dado matricial void showRaster(TeRaster& rst) { int i,j,b; double val; // l e mostra valores { for (b=0; b<rst.params().nBands();++b)
cout << "\nValores na banda: " << b << \n; for (i=0; i<rst.params().nlines_; ++i) { for (j=0; j<rst.params().ncols_; ++j) { rst.getElement(j,i,val,b); cout << val << " "; cout << endl << endl; } } int main() { TeInitRasterDecoders(); if (!rasterTIF.init()) // inicializa decodificadores TeRaster rasterTIF("d:/Dados/TIFF/brasM.tif"); }
436
return 0; TeRaster rasterJPEG("d:/Dados/JPEG/brasilia.jpg"); if (!rasterJPEG.init()) return 0; cout << "Dados no arquivo TIFF: \n"; showRaster(rasterTIF); cout << "\n\nDados no arquivo JPEG: \n"; showRaster(rasterJPEG); }
Exemplo 13.4 Exemplo de uso da classe TeRaster.
A Figura 13.5 mostra o relacionamento entre as trs classes principais da interface de manipulao de dados matriciais de TerraLib. A classe TeRaster uma geometria como as geometrias vetoriais descritas no Captulo 12. Cada objeto da classe TeRaster possui uma instncia de um objeto da classe TeDecoder, e ambas possuem um objeto da classe TeRasterParams, ou seja, o decodificador tem uma verso dos parmetros do dado matricial que decodifica.
Figura 13.5 Relacionamento entre as classes da interface de manipulao de dados matriciais.
Esse mecanismo facilita a escrita de algoritmos de manipulao de dados matriciais porque flexvel o bastante para fornecer um acesso uniforme a diferentes formatos de dados matriciais como mostra o Exemplo 13.5.
437
//! Copia os valores em um dado raster para outro void copiaRaster(TeRaster& rstIn, TeRaster& rstOut) { int i,j,b; double val; for (b=0; b<rstIn.nBands();++b) { for (i=0; i<rstIn.nLines();++i) { for (j=0; j<rstIn.nCols();++j) { rstIn.getElement(j,i,val,b); rstOut.setElement(j,i,val,b); } } } } int main() { TeInitRasterDecoders(); // inicializa decodificadores TeRaster rasterTIF("d:/Dados/TIFF/brasM.tif"); if (!rasterTIF.init()) return 1; TeRasterParams par = rasterTIF.params(); parmetros par.fileName_ = "d:/Dados/JPEG/bras.jpg"; par.mode_ = 'c'; par.decoderIdentifier_ = "JPEG"; TeRaster rasterJPEG(par); if (!rasterJPEG.init()) return 1; // copia todos os // l valores
438
copiaRaster(rasterTIF, rasterJPEG); return 0; }
Exemplo 13.5 Criao de um dado matricial a partir de outro.
Pode se observar no exemplo acima que foram aproveitados todos os parmetros da imagem de origem com exceo de trs: o nome do arquivo destino, o modo de criao e a identificao do decodificador. O construtor do objeto TeRaster destino recebe uma instncia de TeRasterParams e no mais um nome de arquivo. Assim a nova imagem ser criada no formato JPEG no arquivo especificado. A funo de cpia continua usando apenas os mtodos TeRaster::setElement e TeRaster::getElement. Quando se deseja instanciar usar a classe TeRaster para acessar um dado cujo formato no inclui todas as informaes necessrias, existe a possibilidade de se instanciar esse objeto a partir de uma estrutura de parmetros e previamente preenchida. O Exemplo 13.6 mostra como acessar um dado matricial guardado como uma matriz binria em um arquivo raw. Como esse formato no possui nenhum tipo de descritor seus parmetros devem ser explicitamente informados.
TeDatum sad69 = TeDatumFactory::make("SAD69"); TeUtm* proj = new TeUtm(sad69,-45.0*TeCDR); TeRasterParams par; par.fileName_ = "D:/Dados/RAW/grade.raw"; par.decoderIdentifier_ = "MEMMAP"; par.nBands(1); par.mode_ = 'r'; par.setDummy(-9999.9); par.setDataType(TeFLOAT); par.topLeftResolutionSize(185350.0,824800.0,1000,500,10,10,true );
439
par.projection(proj); TeRaster grade(par); if (!grade.init()) return 1; //... usa dado grade.clear();
Exemplo 13.6 Criao de um objeto TeRaster a partir de parmetros.
O mtodo TeRaster::clear deve ser chamado ao final da utilizao do dado matricial. Esse mtodo libera memria ou quaisquer estruturas que foram alocadas na chamada do mtodo TeRaster::init. De maneira geral a ordem de passos para se utilizar um objeto da classe TeRaster a seguinte: 1. Definir parmetros 2. Instanciar um objeto TeRaster a partir dos parmetros 3. Chamar mtodo TeRaster::init 4. Verificar se estado do objeto o esperado 5. Utilizar objeto 6. Chamar mtodo TeRaster::clear Uma vez executado o mtodo TeRaster::init no se deve alterar os parmetros do dado matricial, pois as inicializaes feitas utilizaram os valores ento definidos. Qualquer modificao subseqente pode invalidar a capacidade de decodificao do dado requerendo uma nova chamada ao mtodo TeRaster::init como mostrado no Exemplo 13.7.
TeRasterParams par;
440
par.decoderIdentifier_ = "MEM"; par.nBands(1); par.mode_ = 'c'; par.setDummy(255); par.setDataType(TeUNSIGNEDCHAR); TeRaster rMem(par); if (!rMem.init()) elementos return 0; rMem.params().nlines_ = 200; rMem.params().ncols_ = 200; rMem.setElement(199,199,0); rMem.init() rMem.setElement(199,199,0); elementos // ERRO! // CERTO! Reinicializar raster // antes de acessar novos // altera nmero de elementos // aloca espao para 100
Exemplo 13.7 Reinicializando um objeto TeRaster.
13.3.4 Incluindo informaes geogrficas Para que o dado matricial seja geo-referenciado, ou seja, para que se possa identificar para cada linha e coluna uma localizao sobre a superfcie terrestre preciso que seu os parmetros contenham as informaes sobre uma projeo cartogrfica, as coordenadas de seu retngulo envolvente e a resoluo espacial de cada elemento em unidades da projeo. Esses dados devem ser informados nos parmetros ou obtidos do prprio formato de armazenamento e no devem ser alterados depois da inicializao sob pena de invalidar o geo-referenciamento. O Exemplo 13.8 mostra como incluir as informaes geogrficas em um dado matricial.
TeDatum sad69 = TeDatumFactory::make("SAD69"); TeUtm* proj = new TeUtm(sad69,-45.0*TeCDR);
441
TeRasterParams par; par.decoderIdentifier_ = "MEM"; par.nBands(1); par.mode_ = 'r'; par.setDummy(255); par.setDataType(TeUNSIGNEDCHAR); //define o retngulo envolvente do dado e sua resoluo par.lowerLeftResolutionSize(309695,7591957,20,20,3000,2000,true ); // define a projeo do dado par.projection(proj); TeRaster grade(par); if (!par.init()) return 1; for (i=0; i< grade.nLines();++i) { coordenada geogrfica for (j=0; j< grade.nCols();++j) { char mess[100]; TeCoord2D xy = grade.index2Coord(TeCoord2D(j,i)); sprintf(mess,"[%d,%d]:(%.2f,%.2f) ",i,j,xy.x(),xy.y()); cout << mess; } cout <<
} endl;
//
retorna
// de cada elemento
Exemplo 13.8 Associao de parmetros geogrficos.
Os parmetros geogrficos de um dado matricial que permitem sua navegao em coordenadas de uma determinada projeo cartogrfica (bounding box, box, nmero de linhas, colunas, resolues horizontais e verticais) so correlacionados e devem ser coerentes. A classe TeRasterParams possui os mtodos informar parte deles e
442
automaticamente boxResolution, etc.).
atualizar
os
outros
upperLeftResolutionSize,
(lowerLeftResolutionSize, boundingBoxResolution,
13.3.5 Remapeamento de dados raster Um objeto da classe TeRaster propriamente inicializado pode ser parmetro de funes que usam os seus mtodos getElement e setElement como mostrado anteriormente. A classe TeRasterRemap um exemplo de implementao de uma funo que copia um dado matricial para outro, resolvendo diferenas em termos de geometria. Essas diferenas podem ser em relao ao nmero de linhas, colunas, resolues diferentes ou retngulos envolventes diferentes, ou ainda, projees diferentes. A Figura 13.6 mostra o fluxo de operaes da classe TeRasterRemap.
DM_entrada DM_sada
projIn != projOut
resEnt != resSada boxEnt != boxSada
Copia
Remapeia
Reamostra
TeRasterRemap
getElement setElement
Figura 13.6 A classe TeRasterRemap.
O Exemplo 13.9 mostra trs casos de uso dessa funo: para degradar a resoluo de uma imagem, para recortar um pedao de uma imagem e para remapear (trocar de projeo) uma imagem.
#include "TeRasterRemap.h"
443
int main() { TeInitRasterDecoders(); TeRaster rEntrada("d:/Dados/TIFF/brasM.tif"); em projeo UTM if (!rEntrada.init()) { cout << "Erro obtendo dado de entrada!\n"; return 1; } TeRasterParams parS = rEntrada.params(); TeBox bb = parS.boundingBox(); double resx = parS.resx_*2.0; resoluo espacial double resy = parS.resy_*2.0; parS.boundingBoxResolution(bb.x1_,bb.y1_,bb.x2_,bb.y2_,resx,res y); parS.fileName_ = "d:/Dados/JPEG/subBras.jpg"; parS.decoderIdentifier_ = "JPEG"; de sada parS.mode_ = 'c'; TeRaster rSaida1(parS); if (rSaida1.init()) { TeRasterRemap reamostragem } parS = rEntrada.params(); parS.fileName_ = "d:/Dados/JPEG/zoomBras.jpg"; parS.decoderIdentifier_ = "JPEG"; // define box menor subamostra(&rEntrada,&rSaida1); // faz // troca formato // mantm box // degrada a // raster
subamostra.apply();
parS.boundingBoxResolution(184000.0,8247000.0,194500.0,8248000. 0, parS.resx_,parS.resy_);
444
parS.mode_ = 'c'; TeRaster rSaida2(parS); if (rSaida2.init()) { TeRasterRemap zoom(&rEntrada,&rSaida2); zoom.apply(); } parS = rEntrada.params(); parS.fileName_ = "d:/Dados/JPEG/latlongBras.jpg"; parS.decoderIdentifier_ = "JPEG"; TeDatum sad69 = TeDatumFactory::make("SAD69"); TeLatLong* latlong = new TeLatLong(sad69); parS.projection(latlong); parS.mode_ = 'c'; TeRaster rSaida3(parS); if (rSaida3.init()) { TeRasterRemap remap(&rEntrada,&rSaida3); remap.apply(); }
}
// faz recorte
// remapeia
Exemplo 13.9 A classe TeRasterRemap.
A funcionalidade da classe TeRasterRemap pode ser usada em diversos contextos como a importao de dados para um banco e o apresentao desse dado em uma janela de visualizao. 13.3.6 Iteradores sobre dados matriciais Um grande nmero de algoritmos de processamento de dados geogrficos no dependem de uma implementao particular de uma estrutura de dados, mas apenas de alguma propriedade semntica fundamental, como a capacidade de mover entre elementos de uma estrutura de agregao ou
445
comparao entre dois elementos da estrutura. Por exemplo, o algoritmo para calcular o histograma de um dado geogrfico no necessita conhecer se o dado est organizado como um conjunto de pontos, um conjunto de polgonos ou um conjunto de pixels. Tudo que necessrio a que a estrutura fornea a capacidade de percorrer uma lista de elementos e obter um valor pra cada um deles. Esse paradigma de desenvolvimento chamado de programao genrica (Austern 1998). Programao genrica visa o projeto de mdulos interoperveis baseados na separao entre algoritmos e estruturas de dados. A classe TeRaster fornece iteradores, ou seja, ponteiros generalizados que permitem o percorrimento de uma representao matricial. Em sua verso mais simples os iteradores de dados matriciais comeam na primeira linha e na primeira coluna do dado e a cada operao de avanar o iterador move-se para a prxima coluna at o fim da linha quando ento se move para a primeira coluna da linha seguinte. Iteradores so teis, pois permitem que sejam escritos algoritmos em funo dos iteradores e no de uma estrutura de dados em particular. O Exemplo 13.10 mostra como percorrer uma representao matricial atravs de iteradores.
TeRaster* img = new TeRaster("./dados/imagem.jpg"); TeRaster::iterator it = img.begin(); while (it != img.end()) { cout << (*it); }
Exemplo 13.10 Percorrimento de um dado matricial atravs de iterador.
Usando esse princpio, a classe TeRaster tambm fornece iteradores especializados para percorrimento dos elementos da representao matricial que esto delimitados por uma regio de interesse (definida como um TePolygon) como mostra o Exemplo 13.11 .
TeRaster* img = new TeRaster("./dados/imagem.jpg"); TePolygon region;
446
//... cria a regio de interesse TeRaster::iteratorPoly itB = img.begin(region); TeRaster::iteratorPoly itE = img.end(region); while (it != itE) { cout << (*it); }
Exemplo 13.11 Percorrimento de regio de um dado matricial limitada a uma regio.
As sees anteriores mostraram a interface de manipulao de dados matriciais oferecidas por TerraLib. A prxima seo trata das questes relativas ao armazenamento e recuperao de dados matriciais em um banco de dados TerraLib. 13.4 Dados matriciais em bancos de dados TerraLib Um banco TerraLib composto de um conjunto de planos de informao, ou layers, onde cada layer formado por um conjunto especfico de dado geogrfico (como um mapa de solos, uma imagem ou um mapa cadastral). Para o armazenamento desses dados em um SGBDOR Sistema Gerenciador de Banco de Dados Objeto-Relacional, cada layer est associado com um conjunto de tabelas que armazenam a componente descritiva e espacial do dado. Em um banco TerraLib vai existir uma tabela diferente para cada tipo de geometria associada a informao contida no layer (pontos, linhas, polgonos, clulas e representaes matriciais). O acesso ao dado espacial armazenado no SGDB-OR feito atravs de uma interface que encapsula as diferenas internas de cada SGDB-OR. Essa interface mapeia os tipos espaciais TerraLib em tipos caractersticos de cada SGDB-OR usando os mecanismos nativos de indexao e otimizao se disponveis. As duas classes abstratas que definem a interface de acesso aos dados espaciais so: TeDatabase e TeDatabasePortal que permitem: (a) estabelecimento de conexes com um servidor de banco de dados; (b) execuo de commandos SQL; (c) defino de indces; (d) definio de integridade referencial; (e) execuo
Dados matriciais em bancos de dados TerraLib
447
de consultas espaciais. Para saber mais sobre a interface de acesso a um banco de dados TerraLib o leitor deve recorrer ao captulo 12. O consrcio OpenGIS prope uma especificao de componentes capazes de tratar geo-campos, chamados de Grid Coverages, mas, diferentemente de geometrias vetoriais no prope um modelo de armazenamento desses dados em um banco de dados (OPENGIS, 2005). Trabalhos anteriores (Patel et al., 1997) (Reiner et al., 2002) mostram que a estratgia mais apropriada para trabalhar com grandes bases de dados de imagens uma combinao de diviso por blocos, ou tiling, e a criao de uma pirmide de multi-resoluo. Essa combinao tem sido usada tambm em alguns servidores de mapas via web (DPI/INPE, 2005) e (Barclay et al, 2000). O esquema de tiling usado como indexao espacial, de forma que quando se deseja recuperar uma parte da imagem apenas os blocos relevantes para essa parte sero recuperados. A pirmide de multi-resoluo til na visualizao de imagens grandes e evita acessos desnecessrios, nos nveis da pirmide onde a resoluo degradada, menos blocos so recuperados. Essa abordagem foi adotada em TerraLib de forma integrada a todo o mecanismo descrito nas sees anteriores de forma que um banco TerraLib possa guardar quaisquer dados com uma representao computacional matricial e no somente imagens. A TerraLib trata uma representao matricial como mais uma tipo de geometria, sendo assim, um layer possui um conjunto de objetos cuja componente espacial pode ser uma representao matricial. Muitas vezes, um layer representa um geo-campo e nesse caso a geometria se refere ao layer e no a objetos discretos que agrega. A tabela de representaes geomtricas contm um registro para indicar a existncia da representao matricial para o layer, esse registro, no campo geom_table informa o nome da tabela que contm as informaes sobre a representao matricial de cada objeto do layer. Essa tabela de representaes matriciais de um layer possui um conjunto de informaes gerais sobre a representao: nmero de linhas e colunas, sua resoluo espacial, a largura e altura (em nmero de elementos) dos blocos em que cada banda da representao espacial foi dividida e a indicao da possvel tcnica de compresso aplicada aos blocos. Finalmente, o campo spatial_data, aponta para a tabela de
448
geometrias matriciais onde os blocos que formam a representao esto armazenados. A Figura 13.7 mostra os relacionamentos entre as tabelas que compe o modelo de armazenamento de dados matriciais de TerraLib. Na tabela de geometrias matriciais, cada registro possui a identificao nica do bloco, seu retngulo envolvente e, em um campo binrio longo, o bloco comprimido ou no. Todos os blocos de uma tabela de geometrias matriciais possuem a mesma largura e a mesma altura. Esse modelo de armazenamento de dados matriciais pode ser implementado em qualquer SGDB-OR uma vez que no faz uso de nenhum recurso especial do banco. Poucos SGDBs com extenso espacial propem um modelo de armazenamento de dados matriciais, um deles a extenso espacial do Oracle como pode ser visto em ORACLE (2005).
449
Figura 13.7 Modelo de armazenamento de representaes matriciais de TerraLib.
13.4.1 Modelo de diviso em blocos O mecanismo de diviso do dado matricial em blocos visa a atender a dois requisitos especficos: (a) eficincia, conseguida pela capacidade de recuperao de parte do dado matricial; (b) flexibilidade, conseguida dada pela capacidade de acrescentar novos dados matriciais a uma representao j armazenada (por exemplo, ao se fazer o mosaico de duas cenas de imagens de satlite). TerraLib disponibiliza duas formas de diviso de dados matriciais em blocos: no expansvel e expansvel. Essas duas formas diferentes de
450
diviso implicam em diferentes maneiras de se mapear um elemento da representao matricial como um todo para um elemento dentro de bloco armazenado. A seguir explicamos as duas maneiras. a) No expansvel Significa que a diviso dos blocos feita a partir da linha 0 e coluna 0 da representao matricial. Cada bloco contm L A elementos, onde L a largura do bloco e A a sua altura. Cada bloco identificado pela sua ordem dentro da diviso total da representao, como mostra a Figura 13.8.
Figura 13.8 Diviso por blocos de maneira no expansvel.
451
Um elemento que est posio (j, i) da representao original est no bloco Bm,n tal que m=INT(i/ L), n=INT(j/ A), onde INT(x) representa a parte inteira de x. Observa-se na figura que a ltima linha de blocos e a ltima coluna de blocos (B...,n e Bm,..) podem no estar completos, ou seja, no existem valores na representao matricial para preencher todo o bloco. Isso acontece se o nmero de linha da representao no mltiplo de A ou o nmero de colunas da representao no mltiplo de L. Esses elementos do bloco so preenchidos com o valor dummy. Ao se escolher a opo de diviso por blocos no expansvel, no ser possvel acrescentar, ou mosaicar, posteriormente novos dados matriciais ao dado armazenado. b) Expansvel Significa que a diviso dos blocos no feita na referncia das linhas e colunas, mas sim a partir posies arbitrrias calculadas de acordo com as coordenadas geogrficas do dado matricial. Isso permite que novos dados matriciais possam ser acrescentados a uma representao matricial j armazenada, desde que seus parmetros geogrficos sejam coerentes. A identificao de cada bloco dada por seu posicionamento dentro de uma diviso da rea geogrfica referente ao dado matricial em blocos de tamanho L*ResX e A*ResY, onde ResX e ResY so as resolues espaciais do dado matricial, iniciando na posio 0,0 do sistema de referncia geogrfica do dado. O esquema de diviso de blocos de maneira expansvel ilustrado na Figura 13.9. importante notar que na diviso expansvel os limites dos blocos esto em uma referncia geogrfica e no relacionada linha e coluna de uma matriz. Isso o que permite reas de interseco geogrfica entre dois dados arquivos de imagens, por exemplo, sejam armazenados no mesmo bloco, como destacado na figura.
452
interseco
Figura 13.9 Diviso por blocos de maneira expansvel.
Um elemento que est posio (j, i) da representao original est no bloco Bm,n tal que m=INT(x/LG) e n=INT(y/AG) onde (x,y) a coordenada geogrfica de (j,i), LG=L*resX e AG=A*resY. Assim como no caso da diviso no expansvel alguns blocos ficam incompletos (observar a Figura 13.9) e so preenchidos com o valor dummy. Atravs do retngulo envolvente de cada bloco, possvel saber seu retngulo envolvente em termos de linhas e colunas da representao matricial total e assim encontrar a posio do elemento procurado dentro do bloco. O Exemplo 13.12 mostra o cdigo escrito para executar importar um arquivo de imagens para um banco TerraLib criando um novo layer. Depois um segundo arquivo importado indicando que deve ser armazenado na mesma representao e, portanto executando o mosaico. A Figura 13.10 mostra o resultado visual da operao.
453
TeRaster bras1(./dados/Brasilia1.tif); TeRaster bras1(./dados/Brasilia1.tif); TeLayer *msc = new TeLayer("Brasilia", db, bras1.projection()); TeImportRaster(msc,bras1,128,128,TeJPEG,"",255,TeExpansible)); TeImportRaster(msc,bras2,128,128,TeJPEG,"",255,TeExpansible))
Exemplo 13.12 Mosaico de dois arquivos de imagens para uma mesma representao matricial.
Os parmetros da rotina de importao indicam qual o tamanho dos blocos, qual o algoritmo de compresso, qual o valor a ser usado como dummy e qual o mtodo de diviso por blocos.
Figura 13.10 Resultado do mosaico de dois arquivos de imagens.
Os mecanismos de diviso por blocos e de mosaico so vlidos tanto para imagens quanto para grades numricas. 13.4.2 A estrutura de multi-resoluo As operaes de visualizao de dados matriciais grandes so limitadas pelos dispositivos de sada. Por exemplo, considere uma imagem com 20000 20000 pixels sendo mostrada em um display de 1000 1000 pontos. O usurio controlando a aplicao de visualizao pode comear obtendo uma viso geral da imagem e depois prosseguir ampliando reas menores de seu interesse. Em cada situao, ou seja, em cada ampliao, no deveria ser necessrio a recuperao simultnea de toda a imagem do banco de dados. Na situao ideal, a recuperao da imagem deveria ser
454
da ordem de magnitude da capacidade do dispositivo de sada. Esse requisito pode ser atendido se a imagem armazenada no banco de dados esteja organizada em uma estrutura de multi-resoluo. Combinada com o esquema de diviso por blocos, a pirmide de multi-resoluo armazena, em seu nvel mais baixo, os blocos com a resoluo total da imagem. Nos nveis mais altos so armazenados blocos com resoluo degradada. Dessa forma a aplicao pode controlar, de acordo com a capacidade do dispositivo de sada, em qual nvel recuperar os blocos de interesse. Com essa motivao, TerraLib implementa um esquema pirmide de multi-resoluo. Tradicionalmente so criadas resolues com fatores multiplicativos em potncia de dois, de forma que um nvel superior contenha do nmero de blocos necessrios para se armazenar o dado no nvel inferior (ou seja, de melhor resoluo) como mostrado na Figura 13.11.
Nvel 2 Resoluo R * 22 Nvel 1 Resoluo R * 21 Nvel 0 Resoluo R * 20 (original)
Figura 13.11 Exemplo de pirmide com resolues degradas de fator 2.
TerraLib permite que a aplicao informe qual o fator de degradao, a cada nvel, deseja aplicar para construir a pirmide como mostra o Exemplo 13.13.
// importa resoluo original res X= 30, res Y=30
TeImportRaster(nativade,nat,512,512,TeJPEG,"obj1"); TeBuildLowerResolution(nativade nat, 2, ,"obj1");

// resX = resY = 60
TeBuildLowerResolution(nativade nat, 4, ,"obj1");

// resX = resY = 120
455
TeBuildLowerResolution(nativade nat, 8, ,"obj1");

// resX = resY = 240
Exemplo 13.13 Importando resolues extras.
As resolues extras podem ser criadas nos dois modelos de diviso por blocos: expansvel e no expansvel. A resoluo do bloco tambm parte de sua identificao nica, por isso os blocos com resolues degradadas podem ser armazenados na mesma tabela que os blocos na resoluo original. 13.4.3 Processamento de consultas e recuperao de dados Assim como no caso das geometrias vetoriais (ver captulo 12), existem vrios nveis de acesso aos dados matriciais armazenados no banco de dados TerraLib. Atravs da classe TeDatabase e TaDatabasePortal, a aplicao pode submeter consultas SQL diretamente sobre a tabela de geometria matricial e pode consumir os registros retornados.
TeDatabase portal = db->getPortal(); // seleciona todos os blocos na resoluo original string sql = SELECT resolution_factor = 1; portal->query(sql); while (portal->fetchRow()) { char* blob; long size; portal-> getRasterBlock(blob, size); // usa o blob retornado } * FROM RasterLayert_O1_Raster WHERE
Exemplo 13.14 Consulta SQL sobre uma tabela de representao matricial.
O problema com essa abordagem que a aplicao fica responsvel por descompactar e decodificar o blob. Por isso, em um nvel conceitual mais
456
alto, a classe TeRaster possui um esquema de seleo dos blocos com um dado fator de resoluo e que interceptam um certo retngulo envolvente. O resultado da seleo consumido como se fosse um portal, porm o retorno uma instncia de decodificador j inicializado, que pode ser usado para construir uma representao matricial independente em memria como mostrado no Exemplo 13.15.
TeBox bb(183557, 8246310, 194987, 8258940); int resFac = 2; TeRasterParams parBlock; // seleciona os blocos com um certo fator de resoluo e que // interceptam um determinado retngulo envolvente if (raster->selectBlocks(bb, resFac,parBlock)) { // Processa cada bloco como um dado matricial independente em memoria TeRaster* block = new TeRaster; TeDecoderMemory* decMem = new TeDecoderMemory(parBlock); decMem->init(); do { flag = raster->fetchRasterBlock(decMem); block->setDecoder(decMem); } while (flag); raster->clearBlockSelection();
}
Exemplo 13.15 Esquema de seleo de blocos de uma determinada representao matricial.
Aumentando um pouco mais o nvel de abstrao, atravs da classe TeLayer possvel se obter a sua representao matricial como uma instncia da classe TeRaster que pode ento acessar seus elementos individualmente atravs dos mtodos setElement e getElement, ou atravs de iteradores como mostrado nos exemplos das sees anteriores. O Exemplo 13.16 mostra como pode ser feito esse acesso.
457
TeLayer img(Brasilia); db->loadLayer(img); TeRaster* bsbImg = img->raster(); // acessa elementos individuais da imagem double val; bsbImg->getElement(0,0,val,0);
Exemplo 13.16 Acessando uma representao matricial de um layer.
13.4.4 A classe TeDecoderDatabase No Exemplo 13.16, internamente criado um decodificador para um dado matricial armazenado em uma banco de dados TerraLib (representado pela classe TeDecoderDatabase), escondendo todos os detalhes de tabelas e compresses associados ao dado armazenado. O decodificador de dados matriciais em um banco de dados TerraLib levou em conta algumas questes de eficincia para permitir o acesso a elementos individuais da representao. Existe um mecanismo de cache de blocos em memria a fim de reduzir o nmero de acessos ao banco de dados. O identificador nico de cada bloco usado como chave no armazenamento no banco de dados e tambm no sistema de cache. Cada vez que a aplicao requisita o valor de um elemento com as coordenadas (i,j) na banda b, em uma resoluo r, se o bloco que contm o elemento no est na memria, recuperado e colocado no sistema de cache. No prximo acesso a um elemento, o sistema inicialmente verifica se o bloco que o contm est no sistema de cache. Se estiver no o valor do elemento recuperado diretamente da memria sem a necessidade de se acessar o banco novamente. O nmero mximo de blocos mantido no sistema de cache controlado pela aplicao. Quando necessrio trazer um bloco para o cache e no existe mais espao, o bloco menos recentemente usado liberado do cache, caso tenha sido modificado seu contedo atualizado no banco de dados. O sistema de cache implementado na classe TeDecoderVirtualMemory da qual a classe TeDecoderDatabase derivada. O sistema de troca de blocos no cache atual simples, onde os blocos mais usados so mantidos por mais tempo. No entanto, esse um ponto onde podem ser desenvolvidas outras estratgias mais adaptadas a cada caso.
458
A classe TeDecoderDatabase permite que dados matriciais armazenados em um banco de dados TerraLib possam ser usados da mesma maneira que dados matriciais armazenados em memria ou em arquivos em formatos proprietrios. Juntamente com a classe TeRasterRemap aplicaes como a importao de um dado matricial para o banco de dados ou a visualizao de um dado matricial em um dispositivo de sada facilmente implementada. A Figura 13.12 mostra o esquema usado para importar um dado matricial para um banco TerraLib.
Figura 13.12 Esquema da importao de um dado matricial para o banco.
13.5 Um exemplo de aplicao Na TerraLib, o esquema de manipulao de dados matriciais foi funciona em todos os sistemas gerenciadores de banco de dados que implementam a interface TeDatabase como ORACLE, MySQL, PostgreSQL e Access. Um exemplo de aplicao o SIG TerraView, que possui as funes para importar para um banco de dados TerraLib, visualizar e exportar dados matriciais em diversos formatos. A Figura 13.13 mostra um a tela do TerraView mostrando um layer com representao matricial, no caso uma imagem, sobreposta por uma dado vetorial, o limite dos estados da regio norte. A representao matricial do layer mostrado foi construda como um mosaico de duas imagens vindas de arquivos em formato GeoTiff. A
Um exemplo de aplicao
459
primeira imagem possui 7020 7984 pixels e 3 bandas, segunda imagem 7414 8239 pixels e tambm 3 bandas. Os dois arquivos GeoTiff juntos ocupavam 335Mb. As imagens foram divididas em blocos de 512 512 pixels e foram construdos cinco nveis de resoluo, cada nvel degradando a resoluo do nvel anterior de um fator de dois. Os blocos foram armazenados em um banco TerraLib armazenado no SGDB ACCESS, e comprimidos pelo formato JPEG com um nvel de qualidade de 75%. A tabela de geometrias matriciais ficou com um total de 1500 blocos ocupando um espao de armazenamento de 472 Mb. Para visualizar a imagem total foram decodificados cinco blocos com um fator de resoluo de 64 vezes a resoluo original.
Figura 13.13 Tela principal do TerraView.
A Figura 13.14 mostra o resultado da ampliao de aproximadamente um quarto da imagem e a aplicao precisou descomprimir 16 blocos com um fator de resoluo de oito vezes a resoluo original.
460
Figura 13.14 Primeira ampliao.
Finalmente, a Figura 13.15 mostra uma ampliao detalhada, para a qual a aplicao descomprimiu seis blocos na resoluo original.
Figura 13.15 Segunda ampliao.
461
A Figura 13.16 mostra a visualizao de uma grade de altimetria, armazenada segundo o mesmo esquema do armazenamento da imagem. A grade mostrada como se fosse uma imagem em tons de cinza onde o valor mais baixo da grade est mapeado para o preto e o valor mais alto est mapeado para o branco.
Figura 13.16 Visualizao da grade de altimetria.
462
Referncias
AUSTERN, M. (1998). Generic Programming and the STL : Using and Extending the C++ Standard Template Library. Reading, MA, AddisonWesley. BARCLAY, T.; GRAY, J.; SLUTZ, D. Microsoft TerraServer: A Spatial Data Warehouse. In: ACM SIGMOD International Conference on Management of Data,2000,Dallas, Texas, USA. ACM Press, p. 307-318. CMARA, G.; SOUZA, R. C. M.; PEDROSA, B.; VINHAS, L.; MONTEIRO, A. M. V.; PAIVA, J. A.; CARVALHO, M. T.; GATTASS, M. TerraLib: Technology in Support of GIS Innovation. In: II Simpsio Brasileiro em Geoinformtica, GeoInfo2000, 2000, So Paulo. DPI/INPE. Mosaico do Brasil. Disponvel em: <http://www.dpi.inpe.br/mosaico>. Acesso em: jan. 2005. GAMMA, E.; HELM, R.; JOHNSON, R.; VLSSIDES, J. Design Patterns Elemens of Reusable Object-Oriented Software. Reading, MA: AddisonWesley,1995. 395 p. MOREIRA, M. A. Fundamentos do Sensoriamento Remoto e Metodologias de Aplicao. UFV, 2003. Open GIS Consortium. OpenGis Implementation Especification: Grid Coverages. Revision 1.0. Disponvel em: <http://www.opengeospatial.org>. Acesso em: abril 2005. ORACLE Corporation. Managing Geographic Raster Data Using GeoRaster. Disponvel em <http://www.oracle.com>. Acesso em: abril 2005. PATEL, J., J. YU, et al. (1997). Building a Scalable Geo-Spatial DBMS: Technology, Implementation, and Evaluation. SIGMOD Conference, Tucson, Arizona. REINER, B., K. HAHN, et al. (2002). Hierarchical Storage Support and Management for Large-Scale Multidimensional Array Database Management Systems. 3th International Conference on Database and Expert Systems Applications (DEXA), Aix en Provence, France.
14 Desenvolvimento de aplicativos com a TerraLib

Marcelo Tlio Monteiro de Carvalho Mrio de S Vera
14.1 Introduo Este captulo descreve o TerraLib Development Kit - Tdk, cujo objetivo principal facilitar o desenvolvimento de aplicativos geogrficos que utilizem a TerraLib. A motivao do desenvolvimento do Tdk decorre de uma anlise dos objetivos da TerraLib. Recorde do captulo 12 que um dos principais objetivos do projeto TerraLib (www.terralib.org) oferecer suporte, atravs de uma biblioteca (modelos, estrutura de dados e algoritmos), para a pesquisa e o desenvolvimento de tecnologias inovadoras na rea da cincia da Geoinformao (ver Captulo 12). Um segundo objetivo importante estabelecer um ambiente colaborativo para o desenvolvimento de novas ferramentas e aplicativos que componham uma nova gerao de Sistemas de Informaes Geogrfica (SIGs). Para que este objetivo seja atingido de modo satisfatrio, precisamos tratar trs questes : A complexidade intrnseca do cdigo da TerraLib demanda um tempo grande de aprendizado e requer experincia de programao (ver Captulo 12). A TerraLib no oferecer suporte direto para o desenvolvimento de alguns componentes presentes em uma SIG bsico. Em uma viso abrangente, pode-se indicar que este tipo de aplicao deve apresentar os seguintes componentes, apesar da sua implementao poder variar para cada sistema: interface grficainterativa com o usurio, entrada e integrao de dados, armazenamento e recuperao de dados (organizados sob a
462
forma de um banco de dados geogrficos), funes de consulta, funes de anlise espacial e visualizao e plotagem. Destes componentes, a TerraLib no oferece suporte direto para a interface grfica-interativa com o usurio e para a visualizao e plotagem. A possibilidade de interoperar dados com outras aplicaes. Alm de uma base de cdigo aberto, uma comunidade de desenvolvimento de software deve poder utilizar padres da indstria para troca de dados e servios.
14.2 Motivao e estruturao de um SDK 14.2.1 Motivao para um SDK Um SDK (Software Development Kit) um conjunto de ferramentas que permite o desenvolvimento de aplicativos utilizando-se funcionalidades de um software ou de uma biblioteca referente a um domnio de aplicao especfico. Um SDK justificado quando queremos oferecer as funcionalidades de uma ferramenta, criada por especialistas em um domnio especfico, para acelerar o desenvolvimento de aplicativos que dependam de funcionalidades deste domnio. Normalmente, um SDK oferece APIs (Application Programming Interfaces) ou plugin, alm de utilitrios que agilizam a programao, como ferramentas para ajudar na depurao e, documentao detalhada. Um exemplo de um SDK para SIGs so as extenses do ArcGIS da ESRI (www.esri.com/software/arcgis). Uma API um conjunto de definies que permitem acesso s funcionalidades e servios de um determinado software ou biblioteca. Este conjunto pode ser disponibilizado como funes de uso comum (ex. funes para desenhar janelas e cones), permitindo que programadores no precisem programar tudo do incio. Uma boa API oferece um alto nvel de abstrao escondendo detalhes da implementao. Um plugin um pedao de programa desenvolvido para oferecer uma funcionalidade especfica. um mini-programa, que roda embutido e utilizando a interface de um programa principal. Normalmente, os plugins possuem uma definio dos limites de suas funcionalidades Um exemplo de plugin o SVG da Adobe (www.adobe.com/svg).
Motivao e estruturao de um SDK
463
De uma forma resumida, as principais vantagens de um SDK so: Permitir que os aplicativos possam ser desenvolvidos em menos tempo e em menos passos. Oferecer facilidades para construo de aplicaes sem a necessidade de muita experincia em programao. Oferecer suporte a vrias linguagens de programao. Facilitar a formao e manuteno de uma comunidade. Atravs de um SDK, a comunidade pode contribuir com sua criatividade. 14.2.2 Estruturao de um SDK Para poder oferecer as vantagens citadas acima, um SDK deve ser estruturado respeitando alguns requisitos: Modularidade o acoplamento entre os componentes oferecidos por um SDK deve ser pequeno, para que o programador tenha liberdade para utilizar somente os componentes que ele necessite. Reuso os componentes de um SDK devem ser extensveis, para que o programador possa, com alguma adaptao, reutiliz-los, de acordo com as necessidades especficas da sua aplicao. Alm disto, devem poder ser utilizados em diversos contextos e realizar diferentes tarefas. Interface com mltiplas linguagens de programao desejvel que um SDK disponibilize APIs para mais de uma linguagem de programao. Para isto, O SDK deve ser pensado como uma especificao genrica, a partir da qual as APIs devem ser implementadas. Isto garante a compatibilidade entre as implementaes, ao mesmo tempo que mantm a independncia. 14.2.3 O TerraLib Development Kit Conforme o exposto acima, fica evidente que seria desejvel a TerraLib possuir um SDK. Deste modo, iniciamos o projeto Tdk (TerraLib Development Kit), cujo objetivo principal facilitar o desenvolvimento de aplicativos geogrficos que utilizem a TerraLib. Para atingir este objetivo, projetamos o Tdk levando em considerao os seguintes requerimentos:
464
API Simplificada prover, para usurios que no sejam proficientes em programao com a TerraLib, uma API simplificada para acesso s suas funcionalidades mais comuns. O Tdk, no entanto, no oferece a mesma flexibilidade que o cdigo da TerraLib, de forma que deve ser permitido o acesso direto TerraLib. Arquitetura genrica a arquitetura do Tdk no deve depender de nenhuma tecnologia especfica (aberta ou proprietria). Idealmente o programador deve poder implementar a arquitetura proposta com a tecnologia mais apropriada ao contexto da sua aplicao (Web ou Desktop, JAVA ou C++). De uma forma simplista, a arquitetura do Tdk consiste em uma especificao de como implementar um ambiente de desenvolvimento para SIGs. Modelos reutilizveis e extensveis sugerir modelos funcionais que sejam teis para o desenvolvimento de SIGs (modelos para autenticao de usurios, acesso ao banco de dados atravs de mltiplas conexes, modelos para edio e impresso de mapas, entre outros). As solues propostas pelos modelos sugeridos devem poder ser usadas isoladamente e poder ser estendidas, para acomodar funcionalidades especficas da aplicao dos usurios. Compatibilidade com padres oferecer uma interface para o acesso TerraLib, compatvel com os padres publicados pelo Open GIS Consortium (OGC) (www.opengis.org). Isto permite que os programadores acostumados com o vocabulrio e a arquitetura do OGC, utilizem as funcionalidades do Terralib no desenvolvimento de suas aplicaes. Alm disto, para promover a interoperabilidade com aplicativos desenvolvidos com a TerraLib, o Tdk deve oferecer servios compatveis com as especificaes do OGC (como os servios WMS, WFS e WCS, de publicao de dados na Web). Com isto, esperamos resolver as trs questes levantadas acima e facilitar o desenvolvimento de um ambiente colaborativo para o desenvolvimento de SIGs avanados.
Fundamentos conceituais da arquitetura
465
14.3 Fundamentos conceituais da arquitetura Desenvolvemos o Tdk como uma extenso modular da TerraLib, direcionado a oferecer suporte para a implementao de funcionalidades de aplicativos no domnio de SIG. Isto se reflete no modelo de dados utilizado, concebido a partir do modelo de dados original da TerraLib. Embora seja desenvolvido em cima da biblioteca TerraLib, o Tdk no restrinje o acesso direto s suas funcionalidades, conforme mostrado na Figura 14.1.
Figura 14.1 O Tdk como extenso modular da TerraLib.
A arquitetura do Tdk especifica interfaces de programao (APIs) bem definidas e sugere modelos funcionais referentes implementao de funcionalidades comuns a aplicativos grfico-interativos de SIGs. Os elementos da arquitetura so descritos a seguir. 14.3.1 Modelo de dados Tdk Definimos o modelo de dados conceitual do Tdk a partir do modelo original da TerraLib (tema, layer, view, etc. Ver Captulo 12). O modelo do Tdk segue as especificaes de um composite (Gamma et al., 1995) e pode, portanto, ser estendido para acomodar novos componentes, conforme mostrado na Figura 14.2.
466
Figura 14.2 Diagrama hierrquico com o modelo de dados Tdk.
O elemento que define um objeto Tdk (TdkObject) a raiz do modelo e pode representar trs tipos bsicos de elementos: Geometria Uma representao geomtrica simples (um ponto, linha, polgono, imagem, ou qualquer outra representao geomtrica). Objeto Simples Um objeto geogrfico composto por n geometrias em atributos.
Coleo Um conjunto de objetos simples ou de outras colees. Esses elementos so organizados hierarquicamente segundo as regras de que um objeto simples agrupa um conjunto de geometrias e uma coleo agrupa objetos simples ou outras colees. Uma vez definida uma interface nica e comum a objetos e colees, torna-se possvel o tratamento uniforme entre estes elementos. 14.3.2 Interfaces de programao Como concebemos o Tdk dentro do paradigma de orientao a objetos (Rumbaugh et al., 1991), a presena de componentes na arquitetura naturalmente esperada. Neste contexto, componentes so classes projetadas a partir do conceito de reuso e que so acessados atravs de
Fundamentos conceituais da arquitetura
467
mtodos e operaes especificadas pela interface do componente. Os componentes devem ser extensveis. O Tdk oferece um conjunto de componentes agrupados em uma interface de programao. Notamos, no entanto, que em muitos casos, o uso devido de componentes requer um conhecimento grande sobre como utiliz-los, o que pode levar o programador a um aprofundamento em documentos tcnicos. Como alternativa, visando diminuir o tempo necessrio para se obter proficincia na utilizao do Tdk, projetamos uma segunda interface de programao, com caractersticas de programao procedural, atravs de mtodos que se comportam como funes. Esta interface oferece um conjunto de funcionalidades bem definidas, com um alto nvel de abstrao, escondendo a complexidade da implementao. Os mtodos oferecidos, chamados de servios, foram agrupados segundo seu contexto semntico, de forma que as funcionalidades possam ser facilmente localizadas e acessadas diretamente. Diferente dos componentes, os servios no podem ser estendidos. Em resumo, o Tdk oferece duas interfaces de programao (ver Figura 14.3), conforme descrevemos a seguir : uma API de componentes, atravs da qual se pode acessar um conjunto de classes que encapsulam dados e operaes definindo comportamento consistente a ser utilizado ou estendido; uma API de Servios, na qual as funcionalidades mais comuns so agrupadas de acordo com o seu contexto e a sua semntica e so acessveis atravs de uma interface simplificada. Idealmente, a API de servios deve referenciar tipos primitivos nas assinaturas de seus mtodos, de modo a no ser necessrio conhecimento prvio sobre componentes do Tdk, embora internamente os servios devam utiliz-los.
468
Figura 14.3 As interfaces de programao Tdk.
14.3.3 Modelos funcionais Os modelos funcionais sugerem estratgias de implementao para as funcionalidades de um sistema. No Tdk, projetamos modelos para atender s principais funcionalidades presentes em um tipo de aplicativo comum dentro do domnio de um SIG. Neste sentido, estamos falando de aplicaes grfico-interativas, que persistem seus dados em um banco de dados e que oferecem operaes bsicas de visualizao, impresso, consulta e edio. Para atender a este tipo de aplicao, o Tdk oferece trs modelos principais: i) um modelo de persistncia, que gerencia a comunicao com o banco de dados, ii) um modelo de interao, que estrutura a comunicao entre os elementos do sistema e possibilita a implementao das funcionalidades de visualizao, impresso, consulta e edio de uma forma integrada e iii) um modelo de apresentao, que define um conjunto de componentes GUI, implementadas sobre um pacote grfico-interativo externo. Existe ainda a inteno de oferecer um modelo temporal, para suporte aplicaes dinmicas. A concepo dos modelos funcionais no Tdk visa atender a um requisito de extensibilidade e reuso, oferecendo a possibilidade do programador adapt-lo s suas necessidades especficas.
Descrio tcnica dos elementos da arquitetura
469
Em termos de implementao, os modelos funcionais sero construdos utilizando-se as interfaces de programao Tdk, conforme ilustrado na Figura 14.4.
Figura 14.4 Os Modelos funcionais so implementados utilizando-se as interfaces de programao Tdk.
14.4 Descrio tcnica dos elementos da arquitetura Nesta seo estaremos refinando as definies apresentadas como fundamentos da arquitetura Tdk. Descrevemos, em detalhes, os principais elementos referenciados at aqui. Com objetivo didtico, estaremos exemplificando, atravs de codificao, o uso de alguns destes elementos. 14.4.1 API de componentes Alguns dos principais componentes oferecidos pelo Tdk so descritos abaixo: Componente referente a um Objeto Tdk (TdkObject) este componente consiste na raiz da rvore hierrquica de dados Tdk. Ele representa a
470
agregao das interfaces que impe comportamento a todos os elementos do modelo de dados Tdk (ex: TdkEventHandler, TdkPersistenceObject). Componente para interface de persistncia (TdkPersistenceObject) define o comportamento de uma classe aderente ao modelo de persistncia Tdk. As classes de aplicao devero implementar esta interface direta ou indiretamente. As classes pertencentes ao modelo dados Tdk implementam indiretamente esta interface atravs do TdkObject. Componente de identificao de objetos (TdkGlobalID) a idia de tratar todos os elementos, coleo ou folha, de uma base de dados geogrfica da mesma forma abre espao para a criao de um identificador nico para cada TdkObject. O Global ID (GID) foi criado com esse propsito. A idia do GID representar TkdObjects da mesma forma que o sistema de DNS representa URLs, dessa forma podemos ter um GID nico para cada TdkObject do sistema (inclusive sistemas que englobam vrios bancos de dados). O GID composto de: [Database Descriptor].[Object Type].[Object ID] Componente para fabricao de objetos (TdkObjectFactory) responsvel por criar instncias de TdkObjects dinamicamente. Todos os tipos criados por uma aplicao, que possurem uma classe representante definida pela prpria aplicao, devem ter mtodos construtores registrados nesta classe. Ela contm uma estrutura de dados que tem o nome da classe como chave e um ponteiro para uma funo que cria uma instncia da classe correspondente ao tipo. Componente Canvas Genrico (TdkCanvas) representa uma abstrao, independente de pacotes grficos, de um canvas (painel) para desenho que tem formas primitivas para a TerraLib. Em outras palavras, o TdkCanvas prov uma interface especfica para o desenho de geometrias TerraLib, que deve ser estendida para ter acesso s suas funcionalidades (ex. plotPoint, plotLine, plotPolygon, plotText, plotRaster). Como exemplo de implementao de um canvas genrico mostramos aqui o TdkCDCanvas. Este componente consiste na verso CD (www.tecgraf.puc-rio.br/cd) de um TdkCanvas. No cdigo apresentado a seguir mostramos como desenhar um ponto simplesmente :
471
/* declaraes omitidas : */ // TdkQtCanvas* canvas = new TdkQtCanvas(qtParent); //Armazena a geometria num container. TePolygonSet& polys= ((TdkGeographicObject*)object)->getPolygonsGeometry(); for(int j = 0; j < polys.size(); j++) canvas->plotPolygon(polys[j]); // qtParent - a janela Qt principal, na qual,este canvas estar associado. object um objeto Tdk com geometria representada por um conjunto de polgonos.
Codificao 14.1 Exemplo de implementao em C++ do componente TdkCanvas com o pacote grfico CD.
Componente de acesso ao banco de dados (TdkDatabase) os dados e metadados so armazenados no banco TerraLib em tabelas relacionais e refletidos nas classes definidas. As tabelas so divididas em dois grupos; tabelas de metadados, que so usadas para guardar o conceito Terralib e possuem formato pr-definido e as tabelas de dados, que so usadas para armazenar os dados geogrficos (componente espacial + descritiva). A TerraLib implementa um primeiro nvel de abstrao destes dados com a interface TeDatabase (ver Captulo 12), onde temos mtodos para manipular geometrias, layers, temas, etc.. Porm, a interface TdkDatabase que oferece um nvel mais alto de abstrao, introduzindo tipos como TdkMap e TdkProject, e escondendo do programador detalhes do modelo de dados TerraLib. Como exemplo de implementao do componente TdkDatabase apresentamos, a seguir, um cdigo de acesso a uma tabela existente em um banco de dados Oracle :
472
//... TdkOracleConDescriptor desc("oraserver", "tdkuser", "tdk123" , "gisdev"); TdkDatabase* oracleDriver = new TdkOracleImpl(desc); String tableName = myTable; oracleDriver->loadTable(tableName); //
Codificao 14.2 Exemplo de implementao em C++ de TdkDatabase para acesso a um banco Oracle.
Abstrao de uma aplicao bsica (TdkAplication) prov mtodos que oferecem funcionalidades bsicas para agilizar o processo de desenvolvimento de um SIG bsico, como a criao de um novo modelo de dados, de um novo projeto, funes para visualizao e consulta, impresso, etc.. O TdkApplication no prov mtodos de interface grfica, de modo que o programador pode escolher o toolkit para interface de sua preferncia. Como exemplo de implementao do componente TdkApplication apresentamos o cdigo a seguir, que configura o modo de interao de uma aplicao que utiliza o pacote grfico IUP (www.tecgraf.pucrio.br/iup) para responder interao com o usurio de forma a criar geometrias linhas no caso em uma base de dados TerraLib :
// Ihandle* btn = IupButton("", "CreateLineCb"); IupSetAttributes(btn, "TIP = \"Criar linha\", IMAGE = lines_image, IMPRESS = lines_press_image, IMINACTIVE = lines_inactive_image,
473
PRESSED = 0"); IupSetFunction("CreateLineCb", (Icallback)TdkIupApplication::CreateLine); //
Codificao 14.3 Exemplo de implementao em C++ do componente TdkApplication sob o pacote grfico IUP.
Componente de controle de interao (TdkController) componente raiz da hierarquia de componentes responsveis pela implementao da estratgia de resposta s aes do usurio. Todas as controladoras descritas adiante, no modelo de interao, iro implementar esta interface (TdkMapController,TdkInteractController etc...). 14.4.2 API de servios Alguns dos principais servios oferecidos pelo Tdk so descritos abaixo: Servio de persistncia disponibiliza funcionalidades de alto nvel que permitem persistir, consultar e atualizar as informaes em um banco de dados TerraLib. O cdigo a seguir ilustra o que necessrio para criar uma base de dados TerraLib completa, utilizando o Tdk. Modificar o cdigo para receber outro banco de dados, como o Oracle por exemplo, seria um trabalho muito simples, bastando trocar o descritor de conexo para o descritor Oracle (TdkOracleConDescriptor) de acordo com os parmetros necessrios para esta conexo (nome do servidor etc...).
// TdkAccessConDesc desc(C:/mydb.mdb); TdkPersistenceService.createTableModel(desc); //
Codificao 14.4 Exemplo de uso do Servio de persistncia em Java na criao de um banco de dados TerraLib.
474
Servio de processamento prov funcionalidades que auxiliam as tarefas de calcular, converter dados e selecionar reas georeferenciadas. Servio grfico oferece uma srie de funcionalidades para interface grfica baseadas no TdkCanvas. Servio de apresentao oferece mtodos para criao de dilogos de comunicao com o usurio. 14.4.3 Modelo de persistncia Conforme mencionado na Seo 1.2.3, o Tdk oferece um modelo funcional para a implementao do processo de gerncia da persistncia de dados em uma base TerraLib. Este modelo explora, principalmente, os conceitos de transparncia de localidade e automao da persistncia. Transparncia de localidade este conceito consiste em poder tratar dados de maneira uniforme, independente da sua origem. Automao da persistncia este conceito consiste em assumir a responsabilidade de controlar o acesso e atualizao dos dados a serem persistidos. Para implementar o conceito de transparncia de localidade, o modelo define o uso de um identificador global (TdkGlobalID) por todas as classes aderentes ao modelo de persistncia. Nesta identificao, a classe carrega a informao referente sua base TerraLib de origem como descrito na especificao funcional do Tdk (www.terralib.org/tdk). No domnio de SIGs, podemos imaginar uma aplicao deste conceito quando se deseja visualizar dados oriundos de bancos de dados distintos. Para implementar o conceito de automao da persistncia, foi criado um componente TdkPersistenceObject, que define uma interface nica com os mtodos a serem implementados por uma classe nova interessada em aderir ao modelo de persistncia. Este componente representado por um novo elemento, que foi acrescentado ao modelo de dados original (ver Figura 14.4), conforme mostrado na Figura 14.5.
475
Figura 14.5 O modelo de dados Tdk incluindo a classe TdkPersistenceObject.
Atravs da implementao deste ltimo conceito, a tarefa de persistncia dos dados da aplicao muito simplificada. Duas situaes podem ocorrer: i) o conjunto de elementos que definem o modelo conceitual Tdk suficiente para atender s demandas do aplicativo a ser desenvolvido. Neste caso, o programador no precisa se preocupar em implementar nenhum cdigo relacionado persistncia de seus dados numa base TerraLib. ii) o modelo original do Tdk estendido atravs de novos elementos necessrios ao domnio da aplicao. Neste caso, os componentes que representam os novos elementos devem implementar a interface nica definida pelo TdkPersistenceObject. Desta forma, estes componentes passam a aderir ao modelo de persistncia, ganhando a possibilidade de explicitar as particularidades referentes persistncia de seus atributos na base TerraLib. Sem a utilizao do conceito de automao, seria necessrio estender o componente da TerraLib
476
(TeDatabase) e definir os mtodos de persistncia para os novos elementos1, que representa uma tarefa bem mais complicada. Uma outra questo tratada pelo modelo de persistncia, se refere ao controle do ciclo de vida de componentes provenientes da extenso do modelo de dados do Tdk. Como fazer, por exemplo, para que ao carregar um tema TerraLib, composto por objetos definidos fora do modelo de dados Tdk, seja possvel instanciar esses objetos de forma automtica? Para enderear a situao descrita acima, o Tdk implementa o conceito de uma fbrica de objetos (ver Seo 1.3.1), que possibilita s classes aderentes ao modelo de persistncia registrar seus atributos simples e t-los, desta forma, gerenciados pelo Tdk. Apresentamos a seguir um exemplo da utilizao do modelo. Na codificao ilustrada abaixo realizamos a carga de um tema persistido para a manipulao em memria :
TdkAccessConDescriptor desc( "C:/mydb.mdb" ); TdkObjectGID tdkObjGID(1, "1", "TDK_ THEME", desc.getDbKey()); TdkTheme myTheme( tdkObjGID ); TdkPersistenceService::loadObject( &mTema );
Codificao 14.5 Carregando um objeto persistido para memria.
14.4.4 Modelo de interao Conforme mencionado na Seo 1.2.3, pretendemos atender demandas que surgem no desenvolvimento de aplicativos grfico-interativos. Para isto, projetamos um modelo, que sugere estratgias de implementao para o suporte s operaes que requeiram interao com o usurio. O modelo de interao do Tdk apresenta as seguintes caractersticas:
1
Como foi feito com TdkProject.
477
Flexibilidade - permite uma implementao genrica e independente de solues proprietrias. independente tambm do pacote grfico a ser utilizado; Independncia modular atravs da utilizao de um modelo de eventos, permite um desacoplamento entre os seus componentes; Para garantir estas caractersticas, concebemos o modelo com base no padro MVC de arquitetura (ver Figura 14.6) (Krasner e Pope, 1988).
MVC (Model,View,Controller) este padro bastante difundindo no domnio de aplicaes grfico-interativas e tem como principal objetivo organizar a interao entre os elementos participantes da implementao de uma determinada funcionalidade, garantindo o desacoplamento entre a interao do usurio e a representao do dado.
Figura 14.6 O padro MVC para desenvolvimento de aplicativos de visualizao.
Uma vez aplicado, o padro MVC resulta em uma diviso em camadas de contextos Modelo, Viso e Controle onde cada camada possui um papel bem definido na interao. No Modelo estaro os dados do domnio representado (ex: temas e objetos). A Viso representa a interface direta com o usurio como uma metfora de um conceito do
478
domnio (ex: legenda, mapa). Finalmente, o Controle determina a reao uma ao do usurio sobre os dados do Modelo (ex: zoom, pan). Como exemplo de aplicao do MVC, podemos imaginar, a visualizao de diversos mapas em uma aplicao de visualizao de dados geogrficos e, no entanto, todas essas visualizaes fazerem referncia ao mesmo dado representado na camada de dados que, por sua vez, representa o dado persistido no banco de dados. A Figura 14.7 apresenta a diviso das camadas de classes adotada pelo modelo de interao do Tdk, que so descritas em seguida.
Figura 14.7 As camadas referentes ao MVC do modelo de interao Camada de Visualizao (Visualization Layer) nesta camada apresentamos um conjunto de metforas do domnio da aplicao, responsveis pela interao direta com o usurio. No nos referimos aqui ao controle desta interao, mas sim a contextualizao das possveis aes que faz sentido realizar em cada entidade representada nesta camada (ex: uma legenda pode ter a ordem de seus temas trocada). Seguindo o padro MVC, nesta camada, estariam as vises (View) dos modelos (Model) pertencentes camada de dados. Como exemplos de componentes desta camada podemos citar o componente de visualizao de um tema TerraLib responsvel por encapsular atributos de visualizao como estilos de objetos selecionados. Camada de Controle (Control Layer) nesta camada acontece a mediao da interao entre usurio e aplicao. As aes do usurio, realizadas via
479
elementos da camada de visualizao, realizam algum tipo de operao sobre os dados representados, logicamente, pela camada de dados. A estratgia de reao, por parte do sistema, s aes do usurio so implementadas nesta camada. Estas estratgias so, inclusive, configurveis de acordo com o tipo de comportamento desejado na resposta do sistema. Exemplificando, um mouse click pode causar uma reao de criao de ponto ou seleo de objeto, dependendo da configurao da camada de controle. Seguindo o padro MVC, nesta camada esto as controladoras (Controllers) que definem o comportamento do sistema em reposta s acoes do usuario sob as vises (Views) dos dados (Model). Como exemplos de componentes desta camada podemos citar dentre outros : A controladora de interao com o Mapa visualizado A controladora de interao com a Legenda Uma observao final quanto a camada de controle do modelo de interao a adoo de um paradigma de programao orientada a eventos. Apesar do MVC no depender deste paradigma, j que seria possvel implement-lo utilizando chamadas de mtodos simples (callback methods), esta estratgia nos trouxe uma flexibilidade interessante. Com o uso de eventos, o cdigo responsvel pela notificao de uma determinada ocorrncia (ex: a troca de estilo de um objeto), assim como o cdigo que implementa a resposta uma ao do usurio (ex: mouse move), ficam completamente separados do cdigo funcional (business code). O modelo de eventos adotado foi sugerido pela arquitetura VIX (Santos, 2005) (Ver Figura 14.8). A arquitetura VIX A maioria dos sistemas grfico-interativos adota o modelo de orientao a eventos, difundido a partir de Smalltalk (Goldberg e Robson, 1983). Tipicamente, o fluxo de informaes neste tipo de aplicao segue um padro. A cada ao do usurio, so gerados eventos do sistema de interface que passam o controle para a aplicao. Com o intuito de facilitar o desenvolvimento de aplicativos com este tipo de interao, desejvel tratar os eventos de maneira uniforme, independente do tipo de ao que ele ir ocasionar. Isto levou adoo do conceito de objetos visuais interativos (VOs).
480
Pode-se entender um objeto visual como qualquer objeto que possua uma representao e um comportamento. Outro conceito importante o de espao visual (VS), que mapeia entidades que transmitem eventos para VOs e fornecem uma superfcie de visualizao onde eles so posicionados. Os VSs devem ser encarados como elementos de ligao entre o usurio e o VO que ele est manipulando. No processo de comunicao entre estes objetos, so utilizados dois mecanismos: Mensagens - atravs deste mecanismo os objetos podem trocar dados uns com outros (o VO deve saber responder s requisies do VS). Filtros - servem para modelar objetos que fazem a interface entre um VS e um VO. Um filtro repassa para o seu VO associado os eventos gerados em seu VS, podendo dar algum tratamento especial a esses eventos. Na implementao Tdk da arquitetura VIX, como parte estrutural do modelo de interao definimos dois novos elementos: uma interface nica para encapsular o cdigo referente a troca de mensagens entre os componentes (TdkEventHandler). uma abstrao de um objeto de edio (TdkLayoutObject) que servir de componente raiz para todos os elementos do modelo de dados Tdk presentes na implementao de funcionalidades de edio.
481
Figura 14.8 O modelo de eventos baseado no VIX
Apresentamos a seguir o modelo de dados do Tdk, com estes novos elementos.
Figura 14.9 O modelo de dados Tdk acrescido dos elementos referentes ao modelo de interao.
482
Para efeitos de ilustrao, mostramos abaixo uma implementao de resposta ao evento de scrolling (rolagem da barra de janela da interface com o usurio) do usurio, tratado pela controladora do mapa visualizado .
void TdkMapController:: handleVSEvent(TdkScrollEvent& event) { float x = event.getX(); float y = event.getY(); double dx = event.getDX(); double dy = event.getDY(); double xc = x + dx / 2.0; double yc = -y - dy / 2.0; mapDisplay_->center(xc, yc); mapDisplay_->draw(); }
Codificao 14.6 Tratamento de um scroll no visualizador de mapas pela classe controladora TdkMapController.
Camada de Dados (Data Layer) o principal objetivo da camada de dados o armazenamento lgico dos dados persistidos.Em termos de interao com as outras camadas, ela manipulada pela camada de visualizao e controle atravs do modelo de eventos.Seguindo o padro MVC esta camada armazena os componentes de modelo (Model). Como exemplo de um componente desta camada podemos citar a representao de um tema, armazenando em memria seus objetos e atributos. 14.4.5 Modelo de apresentao Este modelo apresenta um conjunto de componentes GUI, implementadas sobre um pacote grfico-interativo externo. Os componentes GUI so implementados da forma mais fina possvel, tendo comportamento e estado independentes de recursos especficos do pacote
Compatibilizao com o OGC
483
grfico. Desta forma, pretende-se minimizar o esforo diante de uma mudana de pacote grfico. Alm disto, tendo estado e comportamento descritos na camada funcional, a aplicao passa a ter mais flexibilidade sobre o comportamento do modelo. Como exemplos de componentes desta camada podemos citar: Dilogo para apresentao de atributos de um objeto. Menu de interao com o usurio. Dilogo para importao de dados.
14.5 Compatibilizao com o OGC Conforme mencionado na introduo (Seo 1.1.3), um dos requerimentos do Tdk oferecer suporte a padres do OGC. Este suporte oferecido de duas formas: Uma camada de interface para o modelo de dados do OGC, que permite os programadores acostumados com o vocabulrio e a arquitetura do OGC utilizarem as funcionalidades do Terralib. Servios do OGC. Um exemplo disto o servio WMS para publicao de dados na web. 14.5.1 Interface para programao com o OGC O Tdk oferece uma API que mapeia o modelo de dados do Tdk para o modelo de dados do OGC (www.opengeospatial.org). Sendo assim, possvel o desenvolvimento de aplicativos que utilizem as funcionalidades oferecidas pela TerraLib e que sejam compatveis com os padres publicados pelo OGC (Figura 14.10).
484
Figura 14.10 A interface do Tdk com o padro OGC.
14.5.2 Servio WMS O servio WMS (Web Map Servise) permite a publicao de mapas na Web, produzidos a partir de dados georeferenciados. O servio especifica um padro de como o cliente deve requisitar as informaes para o servidor e como este deve responder. Para esta comunicao so definidas trs operaes: GetCapabilities, GetMap e GetFeatureInfo (www.opengeospatial.org). GetCapabilities: permite ao cliente solicitar todas as metainformaes sobre a base de dados, tais como o nome dos mapas contidos, projeo, escala, estilo possveis dos mapas, formatos possveis dos mapas (GIF, JPEG, PNG), formato das informaes descritivas (FeatureInfo). Os parmetros da operao so recebidos via HTTP e a resposta deve ser um arquivo XML (text/xml) no mesmo protocolo. Segundo o protocolo WMS, esta operao deve ser implementada obrigatoriamente. GetMap: retorna o mapa propriamente dito. Com esta operao, o cliente do Web Service pode requisitar um mapa em particular. Para
Exemplos
485
isto basta usar as informaes que foram retornadas pelo GetCapabilities. Os parmetros da operao so recebidos via HTTP e a resposta deve ser um arquivo de imagem no formato solicitado, que pode ser um das opes: GIF, PNG ou JPEG. Esta operao tambm obrigatria. GetFeatureInfo: permite ao cliente realizar consultas nos mapas da base de dados. Os parmetros da operao so recebidos via HTTP e a resposta deve ser um arquivo no formato solicitado que pode ser um dos seguintes: texto, XML ou GML. Esta operao no obrigatria segundo o protocolo.
14.6 Exemplos A especificao definida pelo Tdk pode ser implementada em diversos contextos. Mostramos abaixo alguns exemplos, onde ilustramos o uso dos elementos de arquitetura Tdk na confeco de diferentes aplicativos. 14.6.1 Um sistema para visualizao, impresso, consulta e edio Ilustramos a seguir aspectos do processo de desenvolvimento de um aplicativo grfico-interativo, que possui operaes de visualizao, impresso, consulta e edio de dados geogrficos, a partir do Tdk. O processo consiste em estender as classes definidas pelo modelo de interao (ver Figura 14.11) para atender s funcionalidades da aplicao (zoom, impresso, criao de pontos e linhas, seleo de objetos, etc.) e a utilizao dos modelos de Persistncia e Apresentao.
486
Figura 14.11 A extenso do modelo de interao para o sistema VICE, onde capacitamos a aplicao com funcionalidades de seleo, zoom, criao de geometrias.
O aplicativo VICE - Sistema para Visualizao, Impresso, Consulta e Edio oferece a noo de modos de operaes de acordo com o contexto de utilizao do aplicativo (Visualizao e Consulta, Layout e Preview de Impresso. A utilizao do modelo funcional de interao, foi fundamental para a implementao destes modos de operaes. A seguir, apresentamos as telas (printscreen) referentes a cada um desses modos em funcionamento (Figuras 14.12, 14.13 e 14.14).
Exemplos
487
Figura 14.12 VICE - modo de Visualizao e Consulta.
Figura 14.13 VICE - modo de Layout.
488
Figura 14.14 VICE - modo de Preview de Impresso.
14.6.2 Aplicativos Java Desktop Como destacado na seo de requisitos do Tdk, sua arquitetura deveria ser independente de linguagens. No caso de Java, as implementaes necessrias para se ter o aplicativo descrito no exemplo anterior seriam bastante anlogas ao caso de C++. No entanto, devido impedncia sinttica entre as linguagens, devemos adicionar uma camada responsvel pela troca de dados entre o mundo C++ e o mundo Java, conforme mostramos na Figura 14.15.
Exemplos
489
Figura 14.15 A camada de acesso para abstrao da troca de dados entre Java e C++.
14.6.3 Aplicativos Web Um terceiro exemplo de produto desenvolvido com o Tdk o aplicativo Tdk Web Client (ver Figura 14.16), que consiste em um visualizador de mapas na Web, compatvel com o padro WMS. Este aplicativo acessa o servio WMS do Tdk (ver Seo 1.4).
Figura 14.16 Um produto Tdk de visualizao de Mapas na Web.
490
Referncias
GAMMA, E.; HELM, R.; JOHNSON, R.; VLSSIDES, J. Design Patterns Elemens of Reusable Object-Oriented Software. Reading, MA: AddisonWesley,1995. 395 p. GOLDBERG, A.; ROBSON. D. Smalltalk-80 : The Language and its Implementa-tion. Addison-Wesley, 1983. KRASNER, E., G.; POPE, S. T.; A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. Journal of ObjectOriented Programming, v. 1, n. 3, p. 26-49, 1988. RUMBAUGH, J.; BLAHA, M.; PERMERLANI, W.; EDDY, F.; LORENSON, W.; Object-Oriented Modeling and Design. Prentice Hall , Englewood Cliffs , NJ, 1991. SANTOS, A. L. S. C. VIX - Um Framework para Suporte a Objetos Visuais Interativos. Rio de Janeiro: Pontifcia Universidade Catlica do Rio de Janeiro, 2005.

Banco de Dados Geograficos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Banco de Dados Geograficos

Cargado por

Copyright:

Formatos disponibles

______________________________________

Bancos de Dados Geogrficos

Parte II Persistncia e Acesso

PARTE III - Interoperabilidade

PARTE IV TerraLib: uma biblioteca para aplicativos geogrficos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

Descrio geral de sistemas de informao geogrfica

1 Representao computacional de dados geogrficos

Entrada e Integr. Dados

Consulta e Anlise Espacial

Gerncia Dados Espaciais

Banco de Dados Geogrfico

Figura 1.1 Arquitetura de sistemas de informao geogrfica.

Traduzindo a informao geogrfica para o computador

Figura 1.2 Paradigma dos quatro universos.

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

Tipo de solo, vegetao, Seleo, uso do solo Comparao

1 Representao computacional de dados geogrficos

Classes de declividade, aptido de uso Altimetria Renda, populao, taxa de natalidade

Mediana, Mximo, Mnimo Diferena, Soma Operaes aritmticas

Intervalo Distncia Razo Valores absolutos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

Figura 1.7 Exemplos de redes simples e de redes com conexes bidirecionais.

1 Representao computacional de dados geogrficos

Figura 1.8 Modelo OO bsico para dados geogrficos.

Do universo ontolgico ao universo formal

1 Representao computacional de dados geogrficos

Domnios do Conhecimento Modelos Inferenciais Hipteses Testveis

Figura 1.10 Representaes vetoriais em duas dimenses.

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

Figura 1.15 Superfcie e malha triangular correspondente. (cortesia de Larcio Namikawa ).

isolinha contm uma linha 2D associada a um valor

1 Representao computacional de dados geogrficos

Figura 1.16 Hierarquia de classes para estruturas vetoriais.

Figura 1.17 Estrutura matricial.

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

Do universo formal para o universo estrutural

Figura 1.20 Geo-campo temtico em estruturas vetorial e matricial.

1 Representao computacional de dados geogrficos

Anlise, Simulao e Modelagem

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

1 Representao computacional de dados geogrficos

2 Algoritmos geomtricos e relacionamentos topolgicos

2 Algoritmos geomtricos e relacionamentos topolgicos

2 Algoritmos geomtricos e relacionamentos topolgicos

Programa 2.1 Tipos abstratos de dados para Ponto, Retngulo e Poligonal.

Figura 2.1 rea do tringulo abc.

2 Algoritmos geomtricos e relacionamentos topolgicos

1>0 2<0 3<0

1>0 2<0 3>0

1<0 2<0 3>0

1<0 2>0 3>0

Figura 2.2 Sinais das coordenadas baricntricas.

Figura 2.3 (a) Interseo dos REMs