Anatomia SIG

Anatomia de Sistemas de Informa o Geogr ca
por
Gilberto C mara1 Marco A. Casanova2 Andrea S. Hemerly2 Geovane C. Magalh es3 4 Claudia M. B. Medeiros4
;
Divis o de Processamento de Imagens INPE
Centro Latino Americano de Solu es para Educa o Superior e Pesquisa IBM Brasil
4
Departamento de Sistemas de Opera o CPqD TELEBR S
Instituto de Computa o UNICAMP
ii
Pref cio
Sistemas de Informa o Geogr ca, ou abreviadamente sigs, s o sistemas de informa o cons tru dos especialmente para armazenar, analisar e manipular dados geogr cos, ou seja, dados que representam objetos e fen menos em que a localiza o geogr ca uma caracter stica ine rente e indispens vel para trat -los. Dados geogr cos s o coletados a partir de diversas fontes e armazenados via de regra nos chamados bancos de dados geogr cos. Este texto trata da anatomia de um sig segundo tr s pontos de vista usu rio nal, pro jetista de aplica es e projetista de bancos de dados geogr cos. Em fun o destes m ltiplos enfoques, o texto est dividido em quatro partes, abordando respectivamente: aspectos concei tuais gerais; problemas de especi ca o de dados e de consultas; quest es de processamento e armazenamento de dados; e dois grandes projetos brasileiros envolvendo tecnologia de Geopro cessamento. Em detalhe, a parte I, dividida em tr s cap tulos, apresenta os principais conceitos neces s rios ao entendimento do resto do texto. Assim, o cap tulo 1 cont m um breve apanhado de quest es relativas a cartogra a e sensoriamento remoto. O cap tulo 2 apresenta conceitos gerais de sig, resumindo suas principais caracter sticas funcionais e incluindo quest es de modelagem de processos e de dados do mundo real. O cap tulo 3 introduz as principais classes de dados geogr cos. A parte II composta por quatro cap tulos. O cap tulo 4 concentra-se na modelagem de dados para bancos de dados geogr cos, propondo um modelo geral. O cap tulo 5 discorre sobre as principais opera es primitivas de manipula o de dados encontradas em um sig. O cap tulo 6 trata de linguagens de consulta. O cap tulo 7 discute a quest o de interfaces para sig, considerando os problemas de visualiza o do resultado de consultas e de arquitetura de interfaces. A parte III compreende tr s cap tulos. O cap tulo 8 analisa a arquitetura de um sig, a partir do modelo proposto na parte II. O cap tulo 9 discute as quest es de armazenamento e indexa o de dados geogr cos. O cap tulo 10 aborda gerenciamento de transa es e otimiza o de consultas, dois aspectos da implementa o de um sig. A parte IV discorre sobre dois projetos desenvolvidos no Brasil e sobre tend ncias de ar mazenamento distribu do de dados geogr cos. O cap tulo 11 descreve o sistema spring, um sig desenvolvido pelo INPE, cujo modelo e linguagem de consulta baseiam-se naqueles introduzidos na parte II do livro. O cap tulo 12 apresenta o projeto sagre, desenvolvido no
iii
iv CPqD TELEBR S, para gerenciamento da rede externa de telefonia. Encerrando o texto, o cap tulo 13 aborda a quest o de centros de dados geogr cos. Este texto foi escrito como parte das atividades do Projeto GEOTEC, um projeto mul ti-institucional dentro do Programa Tem tico em Ci ncia da Computa o e voltado para o desenvolvimento de ferramentas e tecnologias para Sistemas de Informa o Geogr ca. Os autores gostariam de agradecer ao CNPq MCT o apoio recebido para realiza o deste projeto. Os agradecimentos se estendem tamb m a Claudia Tocantins, Antonio Machado e Silva, Juliano Oliveira, Cristina Ciferri e Mariano Cilia pelas in meras contribui es diretas e indiretas prepara o do texto. A Maur cio Mediano cabe um agradecimento especial pela cuidadosa leitura da vers o nal do texto. Rio de Janeiro, abril de 1996 A.S.H. C.M.B.M. G.C. G.C.M. M.A.C.
Sum rio
PARTE I
1 Conceitos B sicos
1.1 Introdu o . . . . . . . . . . . . . . . . . . . . . . 1.2 Conceitos de Cartogra a . . . . . . . . . . . . . . 1.2.1 De ni es B sicas . . . . . . . . . . . . . . 1.2.2 Sistemas de Coordenadas . . . . . . . . . . 1.2.3 Proje es Cartogr cas . . . . . . . . . . . 1.2.4 Mapas e Cartas . . . . . . . . . . . . . . . 1.3 Conceitos de Sensoriamento Remoto . . . . . . . 1.3.1 Princ pios F sicos . . . . . . . . . . . . . . 1.3.2 Sensores a Bordo de Sat lites . . . . . . . 1.3.3 C maras Fotogr cas Aero-Transportadas 2.1 Introdu o . . . . . . . . . . . . . . . . 2.2 Conceitos B sicos . . . . . . . . . . . . 2.2.1 Caracteriza o e Componentes . 2.2.2 Processo de Implanta o . . . . 2.2.3 Breve Hist rico . . . . . . . . . 2.3 Aplica es . . . . . . . . . . . . . . . . 2.3.1 Classi ca o das Aplica es . . 2.3.2 Aplica es S cio-Econ micas . . 2.3.3 Aplica es Ambientais . . . . . 2.3.4 Aplica es de Gerenciamento . v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5 5 5 6 7 14 15 16 17 20
2 Sistemas de Informa o Geogr ca
21
21 22 22 24 25 27 27 28 31 34
vi
SUM RIO
3.1 Introdu o . . . . . . . . . . . . . . . . . . . . . 3.2 Caracter sticas Gerais de Dados Geogr cos . . 3.3 Campos e Objetos Geogr cos . . . . . . . . . . 3.3.1 Modelos de Campos e de Objetos . . . . 3.3.2 Representa es para Campos e Objetos . 3.4 Principais Classes de Dados Geogr cos . . . . 3.4.1 Mapas Tem ticos e Mapas Cadastrais . . 3.4.2 Redes . . . . . . . . . . . . . . . . . . . 3.4.3 Modelos Num ricos de Terreno . . . . . 3.4.4 Imagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Caracteriza o de Dados Geogr cos
37
37 37 39 39 40 41 41 42 43 44
PARTE II
4 Modelagem de Dados Geogr cos
4.1 Introdu o . . . . . . . . . . . . . 4.2 Um Modelo de Dados Geogr cos 4.2.1 N veis de Especi ca o . . 4.2.2 N vel Conceitual . . . . . 4.2.3 N vel de Representa o . . 4.2.4 Extens es ao Modelo . . . 4.3 Padr es para SIG . . . . . . . . . 4.3.1 Vis o Geral . . . . . . . . 4.3.2 O Padr o SAIF . . . . . . 4.3.3 O Padr o SDTS . . . . . . 4.3.4 O Padr o OGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
49
49 50 50 52 54 56 57 58 59 62 63 65 66 66 67
5 Opera es sobre Dados Geogr cos
5.1 Introdu o . . . . . . . . . . . . . . . . . . 5.2 An lise das Opera es sobre Geo-Objetos . 5.2.1 Papel das Representa es . . . . . 5.2.2 Relacionamentos Topol gicos . . .
65
SUM RIO
5.3 An lise das Opera es sobre Geo-Campos . . . . . 5.3.1 Opera es Pontuais . . . . . . . . . . . . . . 5.3.2 Opera es de Vizinhan a . . . . . . . . . . . 5.4 Opera es Mistas entre Geo-Campos e Geo-Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii 74 74 76 78
6 Recupera o de Dados Geogr cos
6.1 Introdu o . . . . . . . . . . . . . . . . . . . . 6.2 Vis o Geral de Linguagens de Consulta . . . . 6.2.1 Linguagens Textuais . . . . . . . . . . 6.2.2 Linguagens Visuais . . . . . . . . . . . 6.2.3 Ambientes Multimodais . . . . . . . . 6.2.4 Linguagens de Consulta sobre Imagens 6.3 A Linguagem LEGAL . . . . . . . . . . . . . 6.3.1 De ni o de Esquemas Conceituais . . 6.3.2 Cria o de Geo-Objetos e Geo-Campos 6.3.3 Consultas . . . . . . . . . . . . . . . . 6.3.4 Manipula o de Objetos e Cole es . . 7.1 Introdu o . . . . . . . . . . . . . . . . . . 7.2 Visualiza o de Dados Geogr cos . . . . 7.2.1 Considera es Gerais . . . . . . . . 7.2.2 Produ o Cartogr ca . . . . . . . 7.2.3 Apresenta o de Dados em LEGAL 7.3 Projeto de Interfaces . . . . . . . . . . . . 7.3.1 Arquitetura . . . . . . . . . . . . . 7.3.2 Linguagens . . . . . . . . . . . . . 7.3.3 Modelo do Usu rio . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
81
81 81 81 82 83 83 84 84 85 86 87
7 Apresenta o de Dados Geogr cos
91 91 91 94 98 99 101 102 103
91
viii
SUM RIO
PARTE III
8 Arquiteturas para SIG
8.1 8.2 8.3 8.4 Introdu o . . . . . . . . . . . . . . . . . . Uma Arquitetura em Camadas . . . . . . . Estrat gias de Implementa o . . . . . . . Arquiteturas Distribu das . . . . . . . . . 8.4.1 Arquiteturas Cliente-Multiservidor 8.4.2 Arquiteturas Orientadas-a-Servi os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
. . . . . . . . . . . . . . . . . . . . . . . .
107
107 107 109 112 112 113
9 Armazenamento de Dados Geogr cos

9.1 9.2 9.3 9.4
Introdu o . . . . . . . . . . . . . . . . . . . . . . . . . . Estrat gia Elementar de Armazenamento . . . . . . . . . Armazenamento de Representa es Matriciais . . . . . . Armazenamento e Indexa o de Representa es Vetoriais 9.4.1 Pontos . . . . . . . . . . . . . . . . . . . . . . . . 9.4.2 Ret ngulos . . . . . . . . . . . . . . . . . . . . . 9.4.3 Linhas Poligonais . . . . . . . . . . . . . . . . . . 9.4.4 Pol gonos . . . . . . . . . . . . . . . . . . . . . . 9.4.5 Representa es Vetoriais Complexas . . . . . . . .. .. .. es .. .. .. .. .. . . . . . . . . .
117
117 117 119 120 120 121 125 126 127 129 130 130 131 133 134 134 135 137
10 Processamento de Transa es e Consultas
10.1 Introdu o . . . . . . . . . . . . . . . . . . . . . . . 10.2 Ger ncia de Transa es . . . . . . . . . . . . . . . . 10.2.1 Transa es em SIG . . . . . . . . . . . . . . 10.2.2 Mecanismos para Implementa o de Transa 10.2.3 Exemplo . . . . . . . . . . . . . . . . . . . . 10.3 Processamento de Consultas . . . . . . . . . . . . . 10.3.1 Tipos de Consultas . . . . . . . . . . . . . . 10.3.2 Estrat gia para Processamento de Consultas 10.3.3 Exemplos de Otimiza o de Consultas . . .
129
SUM RIO
ix
PARTE IV
11 O Sistema SPRING
11.1 Introdu o . . . . . . . . . . . . . . . . . . . . 11.2 O Modelo de Dados do SPRING . . . . . . . . 11.2.1 N vel Conceitual . . . . . . . . . . . . 11.2.2 N vel de Representa o . . . . . . . . . 11.3 Interface Interativa e Linguagem de Consulta . 11.4 Funcionalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
145
. . . . . . . . . . . . . . . . . . . . .
145
145 146 146 148 149 150 153 153 155 155 156 157 158 160 164 164 165 167 167 169 172
12 O Projeto SAGRE
12.1 Introdu o . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Funcionalidade . . . . . . . . . . . . . . . . . . . . . . 12.3 Componentes e Arquitetura . . . . . . . . . . . . . . . 12.3.1 Principais Componentes . . . . . . . . . . . . . 12.3.2 Arquitetura do SAGRE . . . . . . . . . . . . . 12.4 Elementos Armazenados e Modelo de Dados . . . . . . 12.5 Caracter sticas da Manipula o de Dados . . . . . . . . 12.6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7 Mecanismos Internos . . . . . . . . . . . . . . . . . . . 12.7.1 Convers o dos Dados para Entrada no Sistema . 12.7.2 Controle de Vers es . . . . . . . . . . . . . . . . 13.1 13.2 13.3 13.4 Introdu o . . . . . . . . . . . . . . . . . . Cooperativa de Dados e Centro de Dados . Fun es de um Centro de Dados . . . . . . Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
153
13 Centros de Dados Geogr cos
167
SUM RIO
Lista de Figuras
1.1 1.2 1.3 1.4 1.5 1.6 1.7 Proje o estereogr ca polar . Proje o c nica de Lambert . Proje o de Mercator . . . . . Proje o plana . . . . . . . . Proje o c nica . . . . . . . . Proje o cil ndrica . . . . . . Cartas 1:1.000.000 - UTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 11 11 12 12 14
2.1 Arquitetura de Sistemas de Informa o Geogr ca . . . . . . . . . . . . . . . . . 24 4.1 N veis de especi ca o para troca de dados . . . . . . . . . . . . . . . . . . . . . 59 4.2 O modelo de dados parcial do SAIF . . . . . . . . . . . . . . . . . . . . . . . . 62 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 7.1 7.2 7.3 7.4 7.5 Exemplo da matriz de 4 interse es. . . . . . . . . . . . . . . . . . . . Topologias linha-regi o simples com a mesma matriz de 4 interse es. Exemplos de relacionamentos topol gicos . . . . . . . . . . . . . . . . Exemplo de opera o de pondera o. . . . . . . . . . . . . . . . . . . Exemplo de c lculo de ndice de diversidade. . . . . . . . . . . . . . . Exemplo de c lculo de m ximo zonal. . . . . . . . . . . . . . . . . . . Exemplo de c lculo de interse o espacial. . . . . . . . . . . . . . . . Exemplo de reclassi ca o por atributo. . . . . . . . . . . . . . . . . Apresenta es de uma mesma consulta em resolu es diferentes Apresenta es distintas de uma mesma representa o . . . . . . Exemplos de generaliza o . . . . . . . . . . . . . . . . . . . . . Exemplo de arquitetura de uma interface aberta para SIG . . . Enfoques no projeto de interface . . . . . . . . . . . . . . . . . . xi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 69 73 75 76 77 79 79 93 94 97 100 102
xii
LISTA DE FIGURAS
8.1 Arquitetura gen rica em camadas para um sig. . . . . . . . . . . . . . . . . . . 108 8.2 Arquitetura orientada-a-servi os para sig. . . . . . . . . . . . . . . . . . . . . . 114 9.1 9.2 9.3 9.4 9.5 9.6 11.1 11.2 11.3 11.4 11.5 11.6 11.7 Estrutura de um arquivo em grade. . . . . . . . . . . . . . . Particionamento do espa o determinado por uma rvore kd . Exemplo de uma rvore R . . . . . . . . . . . . . . . . . . . Exemplo de uma rvore R+ . . . . . . . . . . . . . . . . . . Exemplo de z-ordem . . . . . . . . . . . . . . . . . . . . . . Exemplo da decomposi o de um pol gono em c lulas. . . . . N vel conceitual do modelo de dados . . . . . . . . . . Exemplo de Atributos para Lotes . . . . . . . . . . . Exemplo de Atributos para MapaLotes . . . . . . . . Associa o de geo-objeto a mapa cadastral . . . . . . . Liga o entre geo-objeto e objeto n o espacial . . . . . Exemplo de de ni o de esquema conceitual no spring Exemplo de implementa o em LEGAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 121 122 124 127 127 146 147 147 147 148 150 151
12.1 Arquitetura do sagre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 12.2 Exemplo de tela base do sagre . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 12.3 Interface de atributos do sagre . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 13.1 Cooperativa de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Lista de Tabelas
1.1 An lise comparativa das proje es . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 Caracter sticas de sat lites cujos dados s o recebidos no Brasil . . . . . . . . . . 18 2.1 Evolu o da tecnologia de sigs . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1 Exemplos de an lise espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1 Relacionamentos topol gicos poss veis entre regi es simples . . . . . . . . . . . . 70 5.2 Regras para determina o de aptid o agr cola. . . . . . . . . . . . . . . . . . . . 75 7.1 Compara o entre cartogra a tradicional e cartogra a usando sig . . . . . . . . 95 8.1 Compara o entre as estrat gias de implementa o . . . . . . . . . . . . . . . . 109 11.1 Rela o entre n veis conceitual e de representa o . . . . . . . . . . . . . . . . . 149
LISTA DE TABELAS
PARTE I
Cap tulo 1 Conceitos B sicos

1.1 Introdu o
A implementa o de sigs requer integrar conhecimentos de diversas reas da Ci ncia da Compu ta o e de disciplinas relacionadas ao processamento de certos tipos espec cos de dados. Para melhor compreens o do texto, este cap tulo apresenta inicialmente alguns conceitos de b sicos de Cartogra a. Em seguida, enfoca a rea de Sensoriamento Remoto, abordando alguns t picos relevantes como, por exemplo, aquisi o de dados atrav s de sistemas com sensores passivos. Este cap tulo utiliza algumas refer ncias b sicas da rea MGR93a, ABC+91, Aro89, PM90 . Em particular, a se o 1.2 parcialmente baseada em SPR93 .
1.2 Conceitos de Cartogra a

1.2.1 De ni es B sicas
Vista do espa o, a Terra assemelha-se a uma esfera com os p los achatados. Na realidade, sua forma afetada pela gravidade, for a centr fuga de rota o e varia es de densidade de suas rochas e componentes minerais RSM78 . Devido complexidade de se trabalhar com a forma real da Terra, os cart grafos aproximam sua superf cie para um modelo do globo terrestre. Neste processo de aproxima o, inicialmente se constr i um ge ide, resultante da medi o do n vel dos oceanos. Em seguida, aproxima-se o ge ide por um elips ide de revolu o, mais regular. Um elips ide de revolu o um s lido gerado pela rota o de uma elipse em torno do eixo menor dos p los. Por m, pode-se considerar o pr prio elips ide ou transform -lo em uma esfera com a mesma superf cie, gerando ent o o globo terrestre. Estudos geod sicos apresentam valores diferentes para os elementos de um elips ide raio do equador, raio polar e coe ciente de achatamento. Assim, cada regi o deve adotar como refer ncia o elips ide mais indicado. No Brasil, adotou-se o elips ide de Hayford, cujas dimen s es foram consideradas as mais convenientes para a Am rica do Sul. Atualmente, no entanto, 5
CAP TULO 1. CONCEITOS B SICOS
utiliza-se com mais freq ncia o elips ide da Uni o Astron mica Internacional, homologado em 1967 pela Associa o Internacional de Geod sia, que passou a se chamar elips ide de refer ncia. Um datum um ponto onde a superf cie do elips ide de refer ncia toca a Terra, sendo caracterizado a partir de uma superf cie de refer ncia datum horizontal e de uma superf cie de n vel datum vertical. Para a de ni o do datum escolhe-se um ponto mais ou menos central em rela o rea de abrang ncia. No Brasil, os mapas mais antigos adotam o Datum de C rrego Alegre - MG e, mais recentemente, o Datum SAD 69 Datum Sul Americano de 1969, por m existem mapas feitos em ambos e at mesmo com datum locais. Apesar do globo terrestre mostrar dist ncias, reas, formas e dire es reais, ele n o o mais apropriado para lidar com processamentos sistem ticos. Para permitir tais processamentos, s o criadas proje es num plano ou seja, cada ponto do elips ide ou esfera projetado em uma superf cie plana. Esta superf cie o mapa pode ser apresentado em diferentes escalas. Escala a rela o entre as dimens es dos elementos representados em um mapa e a grandeza correspondente, medida sobre a superf cie da Terra. A escala uma informa o obrigat ria para qualquer mapa e geralmente est representada de forma num rica. As escalas num ricas ou fracion rias s o descritas por fra es cujos denominadores representam as dimens es naturais e os numeradores, as que lhes correspondem no mapa. A escala de 1 para 50.000 nota o 1:50.000 ou 1 50.000, por exemplo, indica que uma unidade de medida no mapa equivale a 50.000 unidades da mesma medida sobre o terreno. Assim, 1cm no mapa corresponde a 50.000cm ou 500m no terreno. Os termos
escala grande ou
escala pequena podem confundir. Para esclarec -los basta lembrar que escalas s o representadas por n meros fracion rios. Assim, uma escala 1:100.000 menor que uma escala de 1:20.000. Ainda, um objeto representado em um mapa em uma
escala pequena menor que o mesmo representado em um mapa em uma
escala grande. Um dos problemas ao se utilizar sigs reside no fato de que um mapa digital pode ser apresentado ou impresso em qualquer escala, independentemente da escala de origem em que os dados foram armazenados. Por m, caso a escala escolhida seja maior que a original, n o h naturalmente ganho de precis o. Por outro lado, se a escala escolhida for menor, detalhes e precis o podem ser perdidos. O processo de produ o de cartas em escala menor do que a de armazenamento dos dados denominado generaliza o, sendo discutido no cap tulo 7.
1.2.2 Sistemas de Coordenadas

Um objeto geogr co qualquer como uma cidade, a foz de um rio, o cume de uma montanha somente poder ser localizado se puder ser descrito em rela o a outros objetos cujas posi es sejam previamente conhecidas, ou se tiver sua localiza o determinada em uma rede coerente de coordenadas. Quando se disp e de um sistema de coordenadas xas, pode-se de nir a localiza o de qualquer ponto na superf cie terrestre. Os sistemas de coordenadas dividem-se em dois grandes grupos: sistemas de coordenadas geogr cas ou terrestres e sistemas de coordenadas planas ou cartesianas.
1.2. CONCEITOS DE CARTOGRAFIA
No sistema de coordenadas geogr cas ou terrestres, historicamente mais antigo, cada ponto da superf cie terrestre localizado na interse o de um meridiano com um paralelo. Meridianos s o c rculos m ximos da esfera cujos planos contem o eixo dos p los. O meridiano de origem tamb m conhecido como inicial ou fundamental usualmente aquele que passa pelo antigo observat rio brit nico de Greenwich. Ele escolhido convencionalmente como a origem das longitudes sobre a superf cie terrestre e como base para a contagem dos fusos hor rios, corres pondendo ao meridiano a 0o. Esta localiza o por m dependente do pa s, sendo que Mue86 lista em torno de 30 diferentes meridianos de origem. A leste do meridiano de origem, os meridianos s o medidos por valores crescentes at + 180o . A oeste, suas medidas s o decrescentes at o limite m nimo de - 180o . Paralelos s o c rculos da esfera cujos planos s o perpendiculares ao eixo dos p los. O Equador o paralelo que divide a Terra em dois hemisf rios: Norte e Sul. O paralelo a 0o corresponde ao Equador, 90o ao P lo Norte e - 90o , ao P lo Sul. Todos os meridianos se encontram em ambos os p los e cruzam o equador em ngulo reto. A dist ncia entre meridianos diminui do Equador para os p los. Os paralelos jamais se cruzam. Representa-se um ponto na superf cie terrestre por um valor de latitude e longitude. Lon gitude a dist ncia angular entre um ponto qualquer da superf cie terrestre e o meridiano de origem. Latitude a dist ncia angular entre um ponto qualquer da superf cie terrestre e a linha do Equador. Pontos que n o correspondem medi o m dia dos oceanos podem ter tamb m a altitude como terceiro par metro. Como o sistema de coordenadas geogr cas considera desvios angulares a partir do centro da Terra, n o um sistema conveniente para aplica es em que se buscam dist ncias ou reas. Para estes casos, utilizam-se outros sistemas de coordenadas, mais adequados, como, por exemplo, o sistema de coordenadas planas, descrito a seguir. O sistema de coordenadas planas, tamb m conhecido por sistema de coordenadas cartesia nas, baseia-se na escolha de dois eixos perpendiculares, usualmente denominados eixos horizon tal e vertical, cuja interse o denominada origem, estabelecida como base para a localiza o de qualquer ponto do plano. Nesse sistema de coordenadas, um ponto representado por dois n meros: um correspon dente proje o sobre o eixo x horizontal, associado principalmente longitude, e outro correspondente proje o sobre o eixo y vertical, associado principalmente latitude. Estas coordenadas s o relacionadas matematicamente s coordenadas geogr cas, de maneira que umas podem ser convertidas nas outras.
1.2.3 Proje es Cartogr cas

De ni es B sicas
Todos os mapas s o representa es aproximadas da superf cie terrestre, que projetam cada pon to do globo terrestre em uma superf cie plana. Para se obter essa correspond ncia, utilizam-se os sistemas de proje es cartogr cas.
H um grande n mero de proje es cartogr cas, uma vez que h uma variedade de modos de projetar em um plano os objetos geogr cos que caracterizam a superf cie terrestre. No entanto, imposs vel se fazer uma c pia plana da superf cie do globo terrestre sem des gur -la ou alter -la o que d origem no o de grau de deforma o de uma proje o. A deforma o nula nos locais onde a superf cie toca o globo. Dependendo do que se pretende analisar no mapa, cada tipo de proje o minimiza um certo tipo de deforma o, por exemplo, buscando conserva o dos ngulos ou uma proporcionalidade das superf cies. O paralelo padr o aquele onde as deforma es s o nulas, isto , a escala verdadeira, sendo utilizado como linha de controle no c lculo de uma proje o cartogr ca. A partir desse paralelo, as deforma es v o aumentando progressivamente sobre os paralelos e sobre os meridianos, com valores desiguais. A longitude de origem representada por uma linha reta, que constitui o eixo de simetria, no sentido vertical. A de ni o de longitude de origem depende da proje o adotada. A latitude de origem refere-se ao paralelo padr o mais pr ximo regi o de interesse. Dependendo da proje o utilizada, de ne-se ou n o a latitude de origem. Denomina-se transforma o cartogr ca projetiva a opera o de converter dados espaciais representados segundo um determinado sistema de proje o cartogr ca para outro sistema de proje o.
Classi ca o das Proje es

Os sistemas de proje o cartogr ca s o analisados segundo o tipo de superf cie adotada e grau de deforma o. A superf cie que toca o globo terrestre pode ser tangente, secante ou complexa. O caso de superf cie tangente, apesar de mais simples, acarreta mais distor es que os demais. A superf cie secante toca o globo ao longo de uma linha. Apesar de mais complexo, acarreta menos distor es pois a superf cie de contato maior. J uma superf cie complexa formada pela combina o de superf cies, o que diminui ainda mais as distor es por m aumenta a complexidade. Quanto ao tipo de superf cie de proje o adotada, classi cam-se as proje es em: planas ou azimutais, c nicas, cil ndricas e poli dricas, segundo se represente a superf cie curva da Terra sobre um plano, cone, um cilindro ou um poliedro tangente ou secante esfera terrestre. H tamb m um grupo de proje es, descritas pelo USGS
U. S. Geological Survey, que n o podem ser facilmente classi cadas e que s o denominadas miscel neas
miscellaneous ou espaciais, onde as ltimas foram desenvolvidas para acomodar visadas de sat lites. Na proje o plana ou azimutal, constr i-se o mapa imaginando-o projetado num plano tan gente ou secante Terra. Na proje o c nica, pode-se imaginar que o mapa inicialmente projetado sobre um cone tangente ou secante superf cie terrestre, que em seguida
desen rolado sobre um plano. O mesmo ocorre na proje o cil ndrica, onde a proje o imaginada sobre um cilindro. Em todas as proje es c nicas, os meridianos s o retas que convergem em um ponto que representa o v rtice do cone, e os paralelos s o circunfer ncias conc ntricas a
esse ponto. Em todas as proje es cil ndricas, os meridianos e os paralelos s o representados por retas perpendiculares. Exemplos destes tr s tipos de proje es s o mostrados nas guras 1.1 proje o plana este reogr ca polar, 1.2 proje o c nica de Lambert e 1.3 proje o de Mercator, cil ndrica. Quanto ao aspecto, a superf cie pode ser equatorial, polar, obl qua ou transversa. O aspecto equatorial ocorre quando a superf cie de proje o centrada em algum ponto do Equador. O aspecto polar resulta quando a superf cie de proje o centrada em um dos p los; o aspecto obl quo ou horizontal acontece quando a superf cie de proje o alinhada ao longo de qualquer outro ponto do globo. O aspecto transverso ocorre quando a superf cie de proje o cil ndrica e a linha central de proje o alinhada a um par de meridianos, ao inv s do Equador. Por m um aspecto dito normal se ele o mais simples para uma dada superf cie de proje o, ou seja, polar, no caso de azimutal; obl quo, no caso de c nica; e equatorial, no caso de cil ndrica. As guras 1.4, 1.5 e 1.6 apresentam uma compara o da representa o de um quarto de hemisf rio, segundo os diferentes sistemas de proje o. Cada m todo de proje o da superf cie terrestre preserva diferentes propriedades espaciais: rea, dire o, dist ncia e forma. A preserva o de uma propriedade implica normalmente na distor o das demais. Assim, quanto ao grau de deforma o das superf cies representadas, as proje es s o classi cadas em conformes ou isogonais, equivalentes ou isom tricas e eq idistan tes. As proje es conformes ou isogonais mant m delidade aos ngulos locais observados na superf cie representada por exemplo, Mercator. As proje es equivalentes ou isom tricas conservam as rela es de superf cie, n o havendo deforma o de rea por exemplo, C nica de Albers, Azimutal de Lambert. J as proje es equidistantes conservam a propor o entre as dist ncias, em determinadas dire es, na superf cie representada por exemplo, a Cil ndrica Eq idistante. A escolha de uma proje o deve se basear na precis o desejada, no impacto sobre o que se pretende analisar e no tipo de dado dispon vel. A tabela 1.1, adaptada de SPR93 , apresenta uma an lise comparativa das proje es.
10
Figura 1.1: Proje o estereogr ca polar
Figura 1.2: Proje o c nica de Lambert
11
Figura 1.3: Proje o de Mercator
Figura 1.4: Proje o plana
12
Figura 1.5: Proje o c nica
Figura 1.6: Proje o cil ndrica
13
Proje o Albers Bipolar
Classi ca o Aplica es C nica - cartas gerais e geogr cas Equivalente C nica Conforme
- indicada para base cartopogr ca con vel do continente americano Cil ndrica Cil ndrica - mapas mundi Eq idistante Eq idistante - mapas em escala pequena - trabalhos computacionais Gauss Cil ndrica - cartas topogr cas - altera reas por m as distor es Conforme - mapeamento b sico em escala n o ultrapassam 0.5 m dia e grande - preserva os ngulos - similar UTM com defasagem de 3o de longitude entre os meridianos centrais Estereogr ca Plana - mapeamento das regi es - preserva ngulos Polar Conforme polares - preserva forma de pequenas reas - mapeamento da Lua, Marte - oferece distor o de escalas e Merc rio Lambert C nica - cartas gerais e geogr cas - preserva ngulos Conforme - cartas militares - mant m a forma de reas pequenas - cartas aeron uticas do mundo praticamente inalterada - oferece grande precis o de escala Lambert Cil ndrica - Atlas - preserva ngulos Million Conforme - cartas ao milion simo - mant m a forma de reas pequenas praticamente inalterada - d grande precis o de escala Mercator Cil ndrica - cartas n uticas - preserva os ngulos Conforme - cartas geol gicas magn ticas - mant m a forma de reas pequenas - mapas mundi celestes meteorol gicas Miller Cil ndrica - mapas mundi - altera os ngulos Eq idistante - mapas em escalas pequenas - altera rea Polic nica C nica - mapeamento tem tico em - preserva dist ncias Eq idistante escalas pequenas - altera reas - altera ngulos - substitu da por UTM UTM Cil ndrica - mapeamento b sico em - preserva ngulos Conforme escalas m dias e grandes -altera reas por m as distor es - cartas topogr cas n o ultrapassam 0.5
Caracter sticas da proje o - preserva reas - garante precis o de escala - substitui com vantagens todas as outras c nicas equivalentes - preserva ngulos - uma adapta o da C nica de Lambert - altera reas - altera os ngulos
Tabela 1.1: An lise comparativa das proje es
14
Figura 1.7: Cartas 1:1.000.000 - UTM
A Proje o UTM
A proje o UTM
Universal Transverse Mercator de nida dividindo-se a Terra em 60 fusos de 6o de longitude. Para cada fuso, adota-se como superf cie de proje o um cilindro transverso com eixo perpendicular ao seu meridiano central, que assume ainda o papel de longitude de origem. Apesar da caracter stica
universal desta proje o, enfatiza-se que o elips ide de refer ncia varia em fun o da regi o da superf cie terrestre. O meridiano central de um fuso, o Equador e os meridianos situados a 90o do meridiano central s o representados por retas, enquanto que os demais meridianos e os paralelos s o repre sentados por curvas complexas. O meridiano central representado em verdadeira grandeza. A escala aumenta com a dist ncia em rela o ao meridiano central e torna-se in nita a 90o deste. Aplica-se ao meridiano central de cada fuso um fator de redu o de escala igual a 0,9996, para minimizar as varia es de escala dentro do fuso. Como conseq ncia, existem duas linhas apro ximadamente retas, uma a leste e outra a oeste, distantes cerca de 1o37' do meridiano central, representadas em verdadeira grandeza. H um mapeamento sistem tico do Brasil, feito na proje o UTM, nas escalas 1:250.000, 1:100.000 e 1:50.000. A gura 1.7 apresenta a distribui o das cartas 1:1.000.000 para o Brasil. Para saber a longitude de origem, o usu rio deve localizar a rea de interesse na gura e veri car a que fuso ela pertence. O meridiano central do fuso corresponder longitude de origem.
1.2.4 Mapas e Cartas

Os conceitos de mapa e carta n o possuem uma distin o r gida Oli95a . A palavra
mapa teve origem na Idade M dia e era exclusivamente empregada para designar representa es terrestres. Ap s o s culo XIV, os mapas mar timos passaram a ser denominados cartas, como por exemplo,
1.3. CONCEITOS DE SENSORIAMENTO REMOTO
15
as conhecidas
cartas de marear dos portugueses. Algumas de ni es consideram que um
mapa n o tem car ter cient co especializado, sendo destinado a ns culturais, ilustrativos ou mesmo comerciais. J
carta a representa o dos aspectos naturais ou arti ciais da Terra, destinada a ns pr ticos da atividade humana, permitindo a avalia o precisa de dist ncias, dire es e a localiza o geogr ca de pontos, reas e detalhes. Neste texto, os termos
mapa e
carta est o utilizados indistintamente, adotando a de ni o de car ter cient co. Baseado na ABNT Associa o Brasileira de Normas e T cnicas, Oli95a classi ca cartas como se segue. geogr cas:
topogr cas: confeccionadas mediante levantamento topogr co regular, ou compila
das de cartas topogr cas existentes, e que incluem os acidentes naturais e arti ciais, permitindo facilmente a determina o de altitudes. planim tricas: semelhantes s cartas topogr cas, por m n o apresentam indica o de altitudes. cadastrais e plantas: geralmente em escala grande, usadas para mostrar limites verdadei ros e usos das propriedades. aeron uticas: representam a superf cie da Terra com sua cultura e relevo de maneira a satisfazer especi camente as necessidades da navega o a rea. n uticas: resultam dos levantamentos dos mares, rios, canais e lagoas naveg veis e se destinam seguran a da navega o. especiais, por exemplo:
meteorol gicas: mostram as classi ca es clim ticas e as que, em servi o cont nuo,
di rio e sistem tico, cont m informa es meteorol gicas, observadas simultaneamen te em v rios lugares, al m das altera es progressivas nas condi es do tempo. de solo: identi cam e classi cam os diversos tipos de solos e sua distribui o geogr ca. de vegeta o: representam as caracter sticas e a distribui o da cobertura vegetal. de uso da Terra: representam a classi ca o e distribui o geogr ca dos diversos usos aos quais est sujeita a superf cie da Terra. globos: cont m representa es da superf cie da Terra em outra superf cie semelhante.
1.3 Conceitos de Sensoriamento Remoto

Esta se o rev brevemente conceitos de sensoriamento remoto, sob o ponto de vista de tecno logia para aquisi o de dados para sigs. Neste sentido, sensoriamento remoto de nido como
16
o conjunto de processos e t cnicas usados para medir propriedades eletromagn ticas de uma superf cie, ou de um objeto, sem que haja contato entre o objeto e o equipamento sensor. Existem diversos sistemas de aquisi o de dados, tais como c maras fotogr cas aerotrans portadas, sat lites, sistemas de radar, sonar ou microondas. Os sistemas podem ser ativos, como o caso dos sistemas de microondas, que registram a diferen a de freq ncia entre o sinal emitido por elas e o sinal recebido da superf cie efeito
Doppler, ou passivos, como o caso de c maras fotogr cas, que registram a re ect ncia ou emit ncia de uma superf cie. Esta se o se concentra em dados digitais coletados por c maras fotogr cas aerotranspor tadas e por sensores a bordo de sat lites.
1.3.1 Princ pios F sicos

Sistemas de imageamento s o sistemas f sicos destinados a produzir ou captar imagens, tais como c maras fotogr cas, c maras lmadoras, sensores a bordo de sat lites e outros MV89 . A imagem de uma cena formada atrav s de lentes sobre um plano, onde s o colocados sen sores que medem a intensidade da luz incidente. No caso da fotogra a, por exemplo, o lme fotogr co colocado no plano dos sensores. Os sensores respondem proporcionalmente quantidade de luz incidente, seja atrav s de uma rea o f sica, como no caso do lme fotogr co, ou atrav s de um sinal el trico corrente ou tens o, como no caso das c lulas fotoel tricas. A resposta de um sensor depende n o s da quantidade de luz como tamb m da freq ncia da luz. comum, portanto, descrever a caracter stica de um sensor atrav s de uma curva de resposta espectral, que fornece a intensidade da resposta para cada freq ncia ou comprimento de onda. A curva de resposta espectral varia do azul, verde e vermelho na faixa do vis vel, passando pelo infra-vermelho pr ximo, m dio e termal, e chegando a faixas de microondas. Existem diversas de ni es das propriedades b sicas de um sensor, levando a diferentes valores. Estas propriedades podem ser resumidas como se segue DS93 , onde algumas s o exclusivas para sat lites. resolu o espectral, dada pelo n mero de bandas do espectro eletromagn tico capturadas pelos sensores; resolu o radiom trica, dada pela capacidade do sensor de diferenciar n veis de energia do alvo quantiza o; resolu o espacial, dada pela rea espectralmente con vel da superf cie terrestre obser vada instantaneamente por cada sensor; resolu o temporal, dada pelo intervalo de tempo entre duas tomadas de imagem; campo instant neo de vis o ou IFOV
instantaneous eld of view, correspondendo ao ngulo s lido relativo visada de um elemento de imagem;

campo angular de vis o, correspondendo varredura completa de um sensor; cobertura espectral, dada pela localiza o espectral das bandas; fun o de espalhamento pontual PSF
point spread function; fun o de resposta temporal.
17
A resolu o espacial fun o do IFOV, do PSF, de condi es atmosf ricas, de propriedades da cena tais como contraste espectral e geometria do objeto observado, geometria do sensor, altitude e processamento do dado. Ela varia tamb m em fun o do objetivo ao qual o dado se destina, se detec o de um objeto, se identi ca o ou rotula o de um objeto detectado ou an lise de um objeto identi cado. Por exemplo, a resolu o espacial para an lise de um objeto pode ser inferior resolu o visando simplesmente a sua detec o. A resolu o temporal determinada pela altitude do sat lite, pela velocidade angular, pela inclina o de rbita relativa ao Equador, entre outras.
1.3.2 Sensores a Bordo de Sat lites

Sensores a bordo de sat lites permitem a realiza o de medidas consistentes multi-temporais, relativas a grandes reas, durante per odos de tempo que chegam a d cadas. Muitos sensores s o transportados em sat lites em rbitas pr ximas dos p los e sincronizadas com o sol, pois cruzam sempre o Equador na mesma hora solar, a m de atingirem uma cobertura global e uma geometria de ilumina o consistente. Este o caso dos sat lites das s ries Landsat e SPOT e do NOAA AVHRR. O intervalo de repeti o varia entre esses sat lites dependendo de sua altitude e velocidade. Outros sensores s o transportados em sat lites em rbitas geoestacion rias a m de proverem uma grande freq ncia de cobertura de uma mesma regi o. Este o caso dos sat lites meteorol gicos GOES. Esta se o apresenta inicialmente os principais sat lites cujos dados s o recebidos no Brasil e em seguida discute brevemente sistemas GPS Global Positioning System.
Principais sat lites no Brasil

Dentre os principais sat lites cujos dados s o recebidos no Brasil, destacam-se as s ries Landsat e SPOT, o TIROS NOAA, o Meteosat e o ERS. A China e o Brasil pretendem lan ar em 1997 o sat lite CBERS, com tr s sensores, similares ao MSS, ao TM e ao AVHRR, a serem discutidos nesta se o. A gera o de imagens a partir sat lites varia de diversas formas. A tabela 1.2, adaptada de Cam95 , apresenta caracter sticas gerais dos principais sat lites com seus sensores dispon veis no Brasil. O Landsat e o SPOT s o na verdade duas s ries de sat lites comumente usadas na obten o de imagens para ger ncia de recursos terrestres. O TIROS NOAA utilizado em ger ncia
18 Sat lite

Instrumento Resolu o Resolu o Resolu o Espectral Espacial Temporal LANDSAT MSS 4 80 m 16 dias TM 7 30 m 16 dias SPOT XS 3 20 m 26 dias PAN 1 10 m 26 dias TIROS NOAA AVHRR 5 1100 m 6 horas METEOSAT MSS 4 8000 m 30 minutos ERS SAR banda-C 1 25 m 25 dias Tabela 1.2: Caracter sticas de sat lites cujos dados s o recebidos no Brasil
de recursos terrestres e em estudos de vegeta o e aplica es meteorol gicas. O Meteosat possui aplica es na rea de meteorologia. O ERS-1, o primeiro a possuir um radar, destaca-se na ger ncia de recursos terrestres. Trata-se, no entanto, de um sat lite experimental, com cobertura limitada. No restante desta se o, os sat lites Landsat e SPOT s o discutidos em mais detalhes. O programa Landsat, inicialmente um programa de pesquisa da NASA, atualmente opera do comercialmente pela rma EOSAT
The Earth Observation Satellite Company. Ele inclui cinco sat lites diferentes, Landsat-1 a Landsat-5. O sat lite Landsat-6 n o obteve sucesso ao tentar atingir a sua rbita e o Landsat-7 est programado para 1998. A rbita dos sat lites Landsat pr xima dos p los e sincronizada com o sol. Os Landsat-4 e -5 foram postos em rbitas mais baixas 705km que os anteriores 920km a m de permitir imagens de melhor resolu o. O sensor MSS
Multi-Spectral Scanner, presente em toda a s rie Landsat, possui quatro bandas, do verde ao infra-vermelho pr ximo. Os Landsat-1 a -3 eram dotados do sensor RBV
Return Beam Vidicon camera, semelhante a uma c mara de televis o, que operava tr s bandas diferentes, do vis vel ao infra-vermelho pr ximo. Os Landsat-4 e -5 foram equipados com o sensor TM Thematic Mapper. O TM um aperfei oamento do MSS, adicionando mais bandas e melhorando as resolu es espectral, radiom trica e espacial. Ele possui 7 bandas, do vis vel ao infra-vermelho termal. O ETM
Enhanced Thematic Mapper, que estaria presente no Landsat-6, adicionaria ao TM uma banda pancrom tica preto e branco com resolu o de 15m. No caso dos sat lites Landsat-4 e -5, a banda TM 6 infra-vermelha termal possui resolu o de 120m. O programa SPOT
Systeme pour l'Observation de la Terre foi iniciado pelo governo franc s, e atualmente seu desenvolvimento e opera o s o de responsabilidade do CNES
Centre National d'Etudes Spatiales, incluindo os sat lites SPOT-1 a SPOT-3. Os sat lites SPOT tamb m possuem rbita sincronizada com o sol e pr xima dos p los, a 832km de altitude. Os SPOT-1 a -3 s o dotados do sensor HRV
High Resolution Visible, que registra tr s canais multiespectrais, do verde ao infra-vermelho pr ximo, ou um pancrom tico preto e bran
19
co, de alta resolu o. Espera-se que a pr xima gera o de sat lites SPOT possua resolu o de 5m em imagens pancrom ticas. Uma caracter stica importante do SPOT a sua capacidade de pivotear a partir de ordens recebidas da Terra, possuindo um espelho m vel, com visada lateral. Isto permite adquirir uma imagem de uma mesma rea 7 ou mais vezes dependendo da posi o em termos de latitude durante o seu ciclo de 26 dias. Devido a estes dispositivos ticos poss vel tamb m se obter pares estereosc picos de imagens imagens de uma mesma rea adquiridas sob ngulos diferentes, o que permite se realizar ortoreti ca o e obter dados tridimensionais. No processo de ortorreti ca o, as imagens s o completamente corrigidas, eli minando distor es provenientes do posicionamento do sensor e de caracter sticas da superf cie do terreno. Algumas rotinas de ortofotogra a exigem valores pr -determinados de sobreposi o de imagens. Enquanto o Landsat TM oferece melhor resolu o espectral e radiom trica, o que facilita a an lise de determinados fen menos, o SPOT oferece melhor resolu o espacial, especialmente em imagens pancrom ticas de 10m, e uma geometria mais est vel devido ao sensor utilizado. muito comum o uso conjugado das imagens do SPOT e do Landsat, usufruindo dos detalhes da banda pancrom tica do SPOT juntamente com a sensibilidade espectral do Landsat TM. importante observar que os sat lites est o ou estavam operacionais em per odos de tempo distintos os Landsat-1 a -3 foram descontinuados em 1983 e que nem todos os tipos de produ o de imagens estiveram dispon veis durante todo o per odo operacional dos sat lites.
GPS
GPS
Global Positioning System um sistema baseado em sat lites que prov a medi o de latitude, longitude e altura em qualquer ponto da Terra. Os sat lites enviam mensagens espec cas que s o interpretadas por um receptor GPS. A dist ncia entre o sat lite e o receptor GPS pode ser calculada a partir dos sinais enviados e da velocidade do sat lite. Para maior precis o, a localiza o do ponto em quest o determinada utilizando-se pelo menos quatro dist ncias e trigonometria. Se 21 sat lites estiverem em opera o1 , poss vel se medir coordenadas na Terra em qualquer hora do dia. A tecnologia de GPS foi criada com ns militares. Nos EUA, havia um servi o mais preciso para uso militar, e outro, para uso geral, menos preciso, degradando os sinais enviados pelos sat lites. Rapidamente, fornecedores de receptores para GPS transpuseram este problema ajustando o dispositivo a partir de medidas em pontos previamente conhecidos, criando o DGPS
Di erential GPS. Os receptores GPS variam em precis o e funcionalidade. Por exemplo, alguns incluem programas que fazem transforma es entres sistemas de coordenadas ou possuem dados de sa da compat veis com sistemas de sigs comuns no mercado. Outros dispositivos permitem a leitura com os receptores em movimentos e s o muito teis para realizar mapeamento de terrenos com ve culos.
1
Devido constela o de sat lites hoje existente, este requisito n o representa um problema.
20
1.3.3 C maras Fotogr cas Aero-Transportadas

Em um sig, fotogra as a reas possuem duas fun es principais: como componente gr co, servindo como fundo sobre o qual outras informa es s o apresentadas; e como fonte de dados, atualizando ou criando novos arquivos em escala grande ou servindo para controle de qualidade de dados j armazenados. Fotogrametria a ci ncia de se obter medidas acuradas e confeccionar mapas a partir de fotogra as Wol83 . Um projeto de mapeamento de terrenos utilizando fotogra as a reas inclui o planejamento de rotas para a aquisi o das fotogra as, a escolha de pontos de controle para georeferenciamento, a digitaliza o e gera o autom tica dos dados a partir da fotogra a. Fotogra as a reas s o obtidas a partir de um avi o voando em linhas paralelas, chamadas linhas de voo. O planejamento de voo usualmente garante que haja sobreposi o de fotos para a cobertura da rea estudada. Sobreposi es ocorrem lateralmente na ordem de 15 a 40 e adiante atr s na ordem de 55 a 65. Terrenos acidentados exigem maior sobreposi o. Com a sobreposi o adiante atr s, uma vista estereosc pica poss vel, criando para o usu rio uma imagem tridimensional. As fotogra as podem ser gravadas em lme positivos, negativos ou diapositivos, papel, vi dro ou em forma digital. As fotogra as podem ser preto e branco ou coloridas, em infra-vermelho ou em comprimento de onda vis vel, onde a escolha fun o da sensibilidade espectral do fen meno geogr co a ser analisado. Imagens em infra-vermelho foram desenvolvidas originalmente para ns militares, a m de se distinguir objetos camu ados na vegeta o. Atualmente, s o muito teis em estudos envolvendo a identi ca o de certas vegeta es e de vida selvagem. Imagens em preto e branco ou coloridas normais t m fun es similares para mapeamento em geral, sendo as primeiras mais baratas, por m as ltimas mais adequadas vis o humana para a diferencia o de objetos o homem capaz de distinguir em torno de 100 n veis de cinza e por volta de 10.000 cores. A escala de uma fotogra a e sua rea de cobertura s o fun es da dist ncia focal da c mara fotogr ca e da altura do voo. Dist ncias focais mais curtas e v os mais altos d o origem a fotos com escalas menores. Ortofotogra a o nome dado a uma fotogra a a rea que sofreu ortorreti ca o. Ortofotos s o bastante utilizadas em aplica es de mapeamento vide, por exemplo, o trabalho descrito em Fil93 .
Cap tulo 2 Sistemas de Informa o Geogr ca

2.1 Introdu o
Sistemas de Informa o Geogr ca sigs s o sistemas automatizados usados para armazenar, analisar e manipular dados geogr cos, ou seja, dados que representam objetos e fen menos em que a localiza o geogr ca uma caracter stica inerente informa o e indispens vel para analis -la Aro89, Bul94 . sigs comportam diferentes tipos de dados e aplica es, em v rias reas do conhecimento. Exemplos s o otimiza o de tr fego, controle cadastral, gerenciamento de servi os de utilidade p blica, demogra a, cartogra a, administra o de recursos naturais, monitoramento costeiro, controle de epidemias, planejamento urbano. A utiliza o de sigs facilita a integra o de dados coletados de fontes heterog neas, de forma transparente ao usu rio nal. Os usu rios n o est o restritos a especialistas em um dom nio espec co cientistas, gerentes, t cnicos, funcion rios de administra o de diversos n veis e o p blico em geral v m usando tais sistemas com freq ncia cada vez maior. Este cap tulo conceitua de forma geral o que s o Sistemas de Informa o Geogr ca e tra a um breve panorama das suas aplica es, apresentando exemplos gen ricos em v rias reas. O texto enfatiza diferen as importantes entre aplica es de reas diferentes, como a escala de trabalho adotada e as propriedades espacio-temporais consideradas. Dentre as refer ncias gen ricas sobre sigs merecem destaque especial os dois volumes de Geographical Information Systems, editados por D. J. Maguire, M. F. Goodchild e D. W. Rhind MGR93a , e a s rie de relat rios t cnicos do National Center for Geographic Information Analysis - NCGIA NCG89 . Outros exemplos s o as refer ncias ABC+91, Aro89, PM90 . No Brasil, devem ser lembrados os textos AS93, Par94, TMC92 . As refer ncias GB90, NCG89, Thi93 cont m dire es gerais para pesquisa em SIGs.
21
22
CAP TULO 2. SISTEMAS DE INFORMA O GEOGR FICA
2.2 Conceitos B sicos

2.2.1 Caracteriza o e Componentes
Devido sua ampla gama de aplica es, h diferentes formas de se caracterizar sigs MGR93a, Cow90, Aro89, SMSE87, Bur86 . Cada tipo de de ni o prioriza um aspecto distinto. O en foque de banco de dados de ne sig como um sgbd n o convencional, geogr co, que garante o gerenciamento de dados geogr cos. A abordagem
toolbox considera sig como sendo um conjunto de ferramentas e algoritmos para manipula o de dados geogr cos, tal como a pro du o de mapas. O enfoque orientado a processos utiliza o fato de que sigs s o cole es de subsistemas integrados, onde dados espaciais passam por uma seq ncia de processos de con vers o coleta, armazenamento e manipula o. Finalmente, diferentes de ni es priorizam a aplica o, caracterizando o sistema segundo o tipo de dado manuseado, ou a utiliza o, tais como sistemas espaciais para apoio tomada de decis es ou sistemas para an lise de dados geogr cos. As de ni es de sigs re etem, cada uma sua maneira, a multiplicidade de usos e vis es poss veis desta tecnologia e apontam para uma perspectiva interdisciplinar de sua utiliza o. A partir destes conceitos, poss vel indicar duas importantes caracter sticas de sigs. Primeiro, tais sistemas possibilitam a integra o, numa nica base de dados, de informa es geogr cas provenientes de fontes diversas tais como dados cartogr cos, dados de censo e cadastro urbano e rural, imagens de sat lite e modelos num ricos de terreno. Segundo, sigs oferecem mecanismos para recuperar, manipular e visualizar estes dados, atrav s de algoritmos de manipula o e an lise. Numa vis o abrangente, pode-se considerar que um sig tem os seguintes componentes: interface com usu rio; entrada e integra o de dados; fun es de processamento; visualiza o e plotagem; e armazenamento e recupera o de dados. A gura 2.1 indica o relacionamento entre estes componentes. Cada sistema, em fun o de seus objetivos e necessidades, implementa estes componentes de forma distinta, mas todos est o usualmente presentes num sig. Esta se o descreve brevemente tais componentes, deixando os detalhes para os outros cap tulos deste texto. Historicamente, o primeiro tipo de interface utilizado foi a linguagem de comandos que, mesmo podendo possuir um grande poder expressivo, torna-se complexa medida em que o sistema cresce em funcionalidade, o que di culta o seu uso. Para contornar este problema, muitos sistemas disp em de facilidades para a cria o de macro-comandos. A disponibilidade de ambientes computacionais interativos deu origem a interfaces baseadas em menus. Mais f ceis de operar, estas interfaces tendem a ter menor poder expressivo. Existem quatro formas principais de entrada de dados em sigs: a entrada de dados via caderneta de campo, a digitaliza o em mesa, a digitaliza o tica e a leitura de dados na forma digital, incluindo a importa o de dados em outros formatos. Historicamente, muitos levantamentos topogr cos, par metros de solos e outros utilizam cadernetas de campo para armazenar os resultados, que naturalmente devem ser inseridos no sistema ap s um controle
2.2. CONCEITOS B SICOS
23
de qualidade. Com o advento do GPS

Global Positioning System, discutido na se o 1.3.2, tornou-se poss vel realizar trabalhos de campo com alto grau de precis o e com registro digital direto. A digitaliza o de mesa ainda o modo mais utilizado para a entrada de dados a partir de mapas existentes. um processo usualmente custoso e demorado, envolvendo os passos de digitaliza o de linhas, ajuste de n s, gera o de topologia e rotula o identi ca o de cada dado geogr co. A digitaliza o tica feita por dispositivos de varredura scanners e vem sendo cada vez mais utilizada. A tecnologia mais comum baseada em c maras CCD charge coupled devices sendo necess rio o uso de dispositivos de boa resolu o para se conseguir resultados de qualidade. Ap s a obten o de dados em varredura s o utilizados algoritmos de convers o para o formato vetorial, sendo que muitos destes requerem a interven o humana parcial. Na importa o de dados digitais, muito importante aproveitar o investimento j feito, eventualmente por outras institui es, na coleta e armazenamento de dados geogr cos. No Brasil, as principais fontes de dados s o as bases do ibge, do inpe e do Centro de Cartogra a Automatizada do Ex rcito. As fun es de processamento s o naturalmente dependentes dos tipo de dados envolvidos. A an lise geogr ca engloba fun es como superposi o, pondera o, medidas rea, per metro, mapas de dist ncia, tabula o cruzada, dentre outras. O processamento digital de imagens envolve fun es como reti ca o, contraste, ltragem, realce e classi ca o. Modelos num ricos de terreno permitem a gera o de mapas de declividade e aspecto, c lculo de volumes, an lise de per s, al m da pr pria gera o do modelo a partir de pontos esparsos ou linhas, entre outras fun es. Opera es sobre redes incluem caminhos timos, caminhos cr ticos e liga o topol gica. J as consultas aos bancos de dados podem ser espaciais ou n o. Os ambientes de visualiza o de um sistema s o conseq ncia do paradigma adotado para a interface. Quanto produ o cartogr ca, alguns sistemas disp em de recursos altamente so sticados de apresenta o gr ca, englobando a de ni o de uma rea de plotagem, coloca o de legendas, textos explicativos e notas de cr dito. J o aparecimento de padr es
de facto, como o PostScript e o HPGL, vem facilitar o desenvolvimento de fun es de plotagem. Os dados de um sig s o geralmente organizados sob a forma de um banco de dados geogr cos. Tradicionalmente, os sigs armazenavam os dados geogr cos em arquivos internos. Este tipo de solu o vem sendo substitu da pelo uso cada vez maior de sgbd. Estes componentes se relacionam de forma hier rquica. No n vel mais pr ximo ao usu rio, a interface homem-m quina de ne como o sistema operado e controlado. No n vel intermedi rio, um sig deve ter mecanismos de processamento de dados espaciais entrada, edi o, an lise, visualiza o e sa da. No n vel mais interno do sistema, um sistema de ger ncia de bancos de dados geogr cos oferece armazenamento e recupera o dos dados espaciais e seus atributos. De uma forma geral, as fun es de processamento de um sig operam sobre dados em uma rea de trabalho de nida pelo usu rio. A liga o entre os dados geogr cos e as fun es de processamento do sig feita por mecanismos de sele o e consulta que de nem restri es sobre o conjunto de dados, que podem ser espaciais ou n o.
24
Interface
Entrada e Integr. Dados
Funes de Processamento
Visualizao Plotagem
Armazenamento e Recuperao
Banco de Dados Geogrficos
Figura 2.1: Arquitetura de Sistemas de Informa o Geogr ca
2.2.2 Processo de Implanta o

Sob certo ponto de vista, o processo de implanta o de um sig divide-se em tr s grandes fases: modelagem do mundo real; cria o do banco de dados geogr co; e opera o. A fase de modelagem do mundo real engloba a modelagem de processos e de dados e consiste em selecionar fen menos e entidades de interesse, abstraindo-os e generalizando-os. Diferentes conjuntos de fen menos podem ser escolhidos para descrever distintas vis es do mundo, para uma mesma regi o, em um dado instante. Um banco de dados geogr co um reposit rio da informa o coletada empiricamente sobre os fen menos do mundo real ea92, Ege95 . A cria o de um banco de dados geogr cos exige v rias etapas: coleta dos dados relativos aos fen menos de interesse identi cados na modelagem; corre o dos dados coletados devido, por exemplo, a erros introduzidos pelos dispositivos de coleta; e georeferenciamento dos dados associando a cada conjunto de dados informa o sobre sua localiza o geogr ca. Esta fase representa uma grande parcela do custo total do desenvolvimento de um sig, que pode ser minimizado por uma modelagem adequada. A fase de opera o refere-se tanto ao uso em si do sig, quanto ao desenvolvimento de aplica es espec cas por parte dos usu rios a partir dos dados armazenados, reconstruindo vis es particulares da realidade. Retornando primeira fase, modelagem de processos refere-se a uma modelagem matem tica que descreve opera es envolvendo a representa o e manipula o de dados, incluindo a simula o de fen menos naturais BX94b . Este tipo de modelagem come a com a sele o dos
2.2. CONCEITOS B SICOS
25
fen menos e de um modelo matem tico que permita descrev -los e simul -los, de nindo os dados a coletar. Em seguida, dados e modelo matem tico s o calibrados e re nados, em um processo iterativo, at atingir um n vel determinado de qualidade e adequa o BX94a . Os procedimentos de simula o num rica variam com a natureza da aplica o e com a extens o e escala do fen meno observado GPS93 . Um modelo de dados fornece ferramentas formais para descrever a organiza o l gica de um banco de dados, bem como de ne as opera es de manipula o de dados permitidas. Mo delagem de dados refere-se ao processo de abstrair os fen menos do mundo real para criar a organiza o l gica do banco de dados. No caso de aplica es geogr cas, as t cnicas tradicionais de modelagem devem ser estendidas para incluir quest es espec cas de dados geogr cos. Os primeiros trabalhos sobre modelos de dados geogr cos se ocupavam principalmente com estruturas geom tricas e espaciais. Os modelos propostos correspondiam a estruturas de dados so sticadas vide, por exemplo, a descri o de alguns destes
modelos em Aro89 . Esta concep o de modelo foi incorporada pela maioria dos sistemas comerciais atuais, onde o usu rio realiza a
modelagem dos dados de nindo diretamente estruturas de baixo n vel. Esta loso a re etida para os n veis mais altos de de ni o de dados, impedindo muitas vezes os usu rios de especi car as entidades de interesse. Entretanto, esta n o uma abordagem apropriada para modelagem de dados geogr cos pois os usu rios raramente s o especialistas em computa o, mas sim nos diferentes dom nios de aplica o. Al m deste ponto b sico, esta abordagem n o leva a modelos teis fase inicial de coleta e preprocessamento dos dados, nem a modelos que facilitem a reutiliza o dos dados por outras aplica es. O cap tulo 4 apresenta abordagens mais adequadas que minimizam estes problemas.
2.2.3 Breve Hist rico

O problema de an lise e manipula o de entidades que existem em um contexto espa o-temporal n o novo. A forma mais antiga e ainda mais comum de processar e apresentar este tipo de dado atrav s de mapas. Os elementos de um mapa s o em geral armazenados de forma georeferenciada segundo um sistema de coordenadas latitude, longitude e eleva o em rela o ao n vel do mar. A cria o de mapas exige levantamento de dados, medidas de seus valores e localiza o, padroniza o, armazenamento e nalmente apresenta o. Diversos mapas em papel podem ser processados de forma a correlacionar seus dados atrav s de sua sobreposi o sob forma de folhas transparentes. Todo esse processo produ o em papel, armazenamento, sobreposi o muito caro do ponto de vista de armazenamento e atualiza o manual. Desta forma, as primeiras tentativas de automatizar o processamento de dados georeferencia dos ocorreram, segundo ABC+91 , nos anos 50, na Gr Bretanha e nos USA, visando diminuir os custos de produ o e atualiza o de mapas. No primeiro caso, foi desenvolvido um sistema de produ o de mapas para pesquisa em bot nica, onde os dados haviam sido previamente perfurados em cart es. No segundo caso, tratava-se de um sistema desenvolvido em Chicago para mostrar gra camente o volume de tr fego em algumas vias da cidade. Os primeiros sigs propriamente ditos datam dos anos 60. Seu desenvolvimento, no Cana
26
d , fez parte de um plano estrat gico governamental de longo prazo para criar um invent rio automatizado de recursos naturais. Os principais objetivos eram o planejamento de recursos naturais e o uso do solo. Durante os anos 70, desenvolveram-se fundamentos matem ticos voltados para a cartogra a. Surgiu, ent o, a topologia aplicada, permitindo an lises espaciais entre elementos cartogr cos. At ent o, apenas grandes organiza es utilizavam sigs em sistemas de grande porte. Se gundo Tom94 , a maioria das aplica es estava voltada ao mapeamento digital, com fun es anal ticas. Nos anos 80, com a populariza o e barateamento das esta es de trabalho, compu tadores pessoais e bancos de dados, o uso de sig foi difundido com a incorpora o de muitas fun es de an lise espacial. Se o progresso tecnol gico, por um lado, facilitou o desenvolvimento de sigs, tamb m per mitiu aperfei oar os mecanismos de aquisi o de dados georeferenciados. Com isto, aumentou a complexidade de coleta, armazenamento, manipula o e visualiza o dos dados, em fun o do seu volume, variedade e heterogeneidade. Atualmente, as aplica es de sigs variam na extens o da rea geogr ca considerada que pode abranger desde um quarteir o em uma cidade at o globo terrestre; equipamento utilizado desde um computador pessoal at super-computadores; e abrang ncia de interesse particular at patroc nio de ag ncias governamentais abrangendo diferentes pa ses. Recentemente, aplica es sig come aram a incorporar novas tecnologias tais como sistemas especialistas JEM93 e t cnicas de orienta o a objetos Wor94a, AA93, GR93, MMS93, DRS93a, SA93, Her92, CSF92 . A refer ncia Cam95 considera a exist ncia de tr s gera es de sistemas de informa o geogr ca, resumidos na gura 2.1. A primeira gera o, baseada em CAD cartogr co, caracteriza-se por sistemas herdeiros da tradi o de Cartogra a, com suporte de bancos de dados limitado e cujo paradigma t pico de trabalho o mapa chamado de
cobertura ou de
plano de informa o. Esta classe de sistemas utilizada principalmente em projetos isolados, sem a preocupa o de gerar arquivos digitais de dados. Esta gera o tamb m pode ser caracterizada como sistemas orientados a projeto
project-oriented GIS. A segunda gera o de sigs, baseada em bancos de dados geogr cos, chegou ao mercado no in cio da d cada de 90 e caracteriza-se por ser concebida para uso em ambientes cliente-servidor, acoplado a gerenciadores de bancos de dados relacionais e com pacotes adicionais para processa mento de imagens. Desenvolvida em ambientes multiplataforma com interfaces em janelas, esta gera o tamb m pode ser vista como sistemas para suporte a institui es
enterprise-oriented GIS. O cap tulo 11 discute o sistema spring, que pode ser enquadrado nesta gera o. Pode-se prever, para o nal da d cada de 90, o aparecimento de uma terceira gera o de sigs, baseada em bibliotecas digitais geogr cas ou centros de dados geogr cos ver cap tulo 13, caracterizada pelo gerenciamento de grandes bases de dados geogr cos, com acesso atra v s de redes locais e remotas, p blicas ou privadas. Para esta terceira gera o, o crescimento dos bancos de dados geogr cos e a necessidade de seu compartilhamento com outras institui es requer o recurso de tecnologias como bancos de dados distribu dos e federativos. Estes
2.3. APLICA ES
27
sistemas dever o seguir os requisitos de interoperabilidade, de maneira a permitir o acesso de informa es espaciais por sigs distintos. A terceira gera o de sig pode ainda ser vista como o desenvolvimento de sistemas orientados troca de informa es entre uma institui o e os demais componentes da sociedade
society-oriented GIS. 1a gera o 2a gera o 3a gera o 1980-1990 1990-1997 1997 - ? tecnologia CAD, cartogra a BD, imagens sist. distribu dos uso principal desenho de mapas an lise espacial centro de dados ambiente projetos isolados cliente-servidor multi-servidores sistemas pacotes separados sistema integrado interoperabilidade Tabela 2.1: Evolu o da tecnologia de sigs
2.3 Aplica es
2.3.1 Classi ca o das Aplica es
O dom nio de aplica es em sig est se ampliando cada vez mais, acompanhando a evolu o dos dispositivos de coleta e as facilidades computacionais em geral. Um fen meno geogr co pode ser analisado de forma e precis o diferentes dependendo do objetivo da aplica o. Assim sendo, um mesmo conjunto de dados armazenados poder ter tratamentos distintos. Por exemplo, dados pluviom tricos coletados em um conjunto de esta es pluviom tricas ao longo do tempo podem ser interpolados para determinar a distribui o de chuvas em certas regi es durante um per odo, visando planejar atividades de plantio. Os mesmos dados podem ser combinados com informa es sobre a bacia hidrogr ca das regi es, declividade e permeabilidade do solo, para auxiliar estudos de eros o. Esta caracter stica causa um impacto direto na coleta, modelagem e armazenamento dos dados georeferenciados. Por outro lado, cada aplica o requer a manipula o de fen menos geogr cos distintos, associados a diferentes caracter sticas e propriedades que variam no espa o e no tempo. Al m disso, os usu rios sig t m tamb m uma grande variedade de per s, como cientistas especialistas em um determinado dom nio do conhecimento por exemplo, bi logos, ge logos, soci logos, t cnicos engenheiros, arquitetos ou especialistas em administra o e planejamento urbano. Em fun o desta amplitude de per s de usu rios, tipos de dados e necessidades das aplica es, sig tamb m precisam prover aos usu rios e projetistas de aplica es um conjunto adequa do de fun es de an lise e manipula o dos dados geogr cos. A partir de tais necessidades, surgem diferentes especializa es do termo sig como lis
Land Information Systems, nris
Natural Resource Information System, sis
Soil Information Systems. MGR93b classi ca as aplica es em: s cio-econ micas, envolvendo o uso da terra, seres humanos e a infraestrutura existente; ambientais, enfocando o meio ambiente e o uso de recursos
28
naturais; e de gerenciamento, envolvendo a realiza o de estudos e proje es que determinam onde e como alocar recursos para remediar problemas ou garantir a preserva o de determinadas caracter sticas. O cap tulo corrente est baseado nesta classi ca o. Em princ pio, a classe de aplica es determina a utiliza o de certas escalas, fontes de dados e, certamente, fun es de an lise. Aplica es s cio-econ micas s o geralmente voltadas para es calas grandes 1:200 a 1:20.000, ocupando-se de problemas localizados. Aplica es ambientais, por sua vez, s o em geral relacionadas a problemas em escalas menores 1:20.000 ou menores, com conseq ente perda de precis o de medida. Esta regra de escala, fonte e precis o dos dados nem sempre aplic vel: estudos ambientais podem se ocupar de regi es de pequena extens o, exigindo escalas maiores; estudos s cio-econ micos podem abranger migra es populacionais, em escala global. Em alguns casos, torna-se dif cil determinar a classe de uma aplica o: por exemplo, o estudo do impacto ambiental devido a correntes migrat rias envolve tanto fatores s cio-econ micos quanto f sicos.
2.3.2 Aplica es S cio-Econ micas

Aplica es s cio-econ micas tanto podem ser realizadas com o objetivo de planejamento an lise preliminar quanto de avalia o de mudan as em uma regi o em resposta a uma deter minada pol tica an lise posterior. Dentre as aplica es s cio-econ micas, segundo Ram94 , distinguem-se os grupos de origem: uso da terra, incluindo cadastros rurais, agroind stria e irriga o; ocupa o humana, envolvendo cadastros urbanos e regionais, sistemas para servi os de utilidade p blica; e atividades econ micas, agrupando marketing e ind strias. Enquadram-se na classe de aplica es s cio-econ micas os sistemas de informa o sobre uso da terra e os sistemas para mapeamento autom tico ger ncia de facilidades. Exemplos t picos s o o acompanhamento e invent rio de cadastros imobili rios rurais ou urbanos; de ni o de uma pol tica para uso de solo; aplica es envolvendo servi os de utilidade p blica redes de telefonia, eletricidade, esgotos, transportes; sistemas de aux lio navega o; estudos de marketing; e aloca o de recursos em geral para manuten o ou expans o da infraestrutura de uma regi o. Os dados utilizados em aplica es s cio-econ micas s o freq entemente obtidos atrav s de coletas censit rias, mapas urbanos digitalizados e fotogra as a reas. Aplica es que utilizam dados de censo, por exemplo, preocupam-se com distribui es estat sticas de popula es em um certo espa o, associadas infraestrutura existente. Neste caso, escalas menores s o aceit veis, dependendo da extens o da regi o estudada. Aplica es voltadas a planejamento de infraestru tura por exemplo, rede de telefonia ou tr fego exigem escalas de maior precis o: a coloca o de um transformador em um certo ponto em uma rede el trica deve ter precis o de metros; a de ni o de uma rota de nibus urbano precisa levar em considera o a largura das ruas para prever pontos de engarrafamento e locais de manobra. Segue uma discuss o em mais detalhes alguns tipos de aplica es s cio-econ micas.
2.3. APLICA ES
29
Sistemas de Informa es sobre Terra

Um sistema de informa o sobre uso da terra Dal93 , ou lis, abrevia o de
Land Information System, manipula basicamente limites de propriedades ou regi es, com mapas e descri es associados, contendo valor de venda, aluguel, transfer ncia, impostos, etc..., uso rural ou urbano, vegeta o, etc..., constru es, infraestrutura gua, g s, eletricidade, etc..., popula o e outros. Os dados em um lis devem ser os mais atualizados e completos poss veis, devido s conseq ncias sociais e econ micas que um registro mal feito acarreta, como disputas de terras e cobran a incorreta de impostos. O custo de levantamento destes dados bastante alto, chegando at a superar o valor da terra em casos extremos, e o processo muitas vezes lento. Entre os benef cios advindos do uso de um lis, t m-se a redu o dos casos de disputa de propriedades, a simpli ca o do processo de reforma agr ria, a monitora o do mercado de terras e uma maior e ci ncia na cobran a de impostos. Por exemplo, o estudo em ZFS89 avalia um conjunto de mudan as em uma regi o rural nos EUA. Dados de question rios respondidos pelas comunidades da regi o foram inseridos em um sig e analisados em conjunto com fatores como mudan as no uso de solo e na vegeta o, obtidos a partir de fotos a reas. A avalia o destes resultados permitiu a de ni o de novos crit rios para expans o imobili ria na regi o.
Sistemas para Servi os de Utilidade P blica

Existe um crescente uso de sigs pelos servi os de utilidade p blica no mundo, desde ferramentas mais simples para mapeamento autom tico e ger ncia de facilidades
AM FM - Automated Mapping and Facilities Management at sistemas so sticados, envolvendo simula o. A natureza dos servi os de utilidade p blica varia enormemente de pa s para pa s, re e tindo-se nos sigs utilizados. De modo geral, a ind stria prov servi os para consumidores comerciais e dom sticos, fazendo uso de alguma forma de mapeamento de sua rede. sigs per mitiram que estes registros geogr cos fossem relacionados a dados alfanum ricos. O tipo de planta, a complexidade da rede e a sua taxa de crescimento e atualiza o in uenciam a funcio nalidade do sig. Muitas plantas n o possuem uma localiza o precisa de objetos, o que pode acarretar complica es, caso seja necess rio sobrepor mapas. Mahoney Mah93 subdivide as aplica es relacionadas a servi os de utilidade p blica em redes de uxo, incluindo g s e gua, e redes de cabos, incluindo eletricidade, telecomunica es e televis o a cabo. Uma outra forma de classi car tais aplica es consiste em distinguir entre redes subterr neas e redes de superf cie. Os objetos de uma rede de uxo correspondem geralmente a dutos, possuindo atributos co mo di metro, material de constru o e idade de um duto. essencial que exista conectividade nas liga es da rede no banco de dados para a an lise da rede de uxo. As redes de cabos s o usualmente inferiores em tamanho, quando comparadas com as redes de uxo. Registros de eletricidade s o em geral separados por voltagem de transmiss o e distribui o. Em telecomu nica es, a rede deve manter registro da localiza o dos dutos f sicos em redes subterr neas,
30
permitindo identi car at consumidores individuais. Em termos de planejamento, necess rio saber a disponibilidade de espa o nos dutos. Em televis o a cabo, os servi os s o uma combina o de servi os para redes subterr neas e redes de superf cie. O georeferenciamento dos registros de servi os de utilidade p blica pode ser considerado de duas formas: atrav s de um mapa b sico topogr co, que funciona como um arcabou o espacial onde os dados s o georeferenciados; ou a partir da localiza o dos dutos de uxo ou cabos. O custo de aquisi o de um mapa b sico, a partir de um levantamento fotogr co a reo, por exemplo, geralmente bastante alto, chegando de 10 a 25 do custo total do projeto. Usualmente, a altura mantida nos pr prios mapas, evitando a necessidade de se lidar com dados tridimensionais, como mapas de topogra a, exceto quando opera es de coloca o de dutos s o necess rias. A escala de trabalho varia de 1:200 a 1:10.000 nas reas urbanas, admitindo-se escalas menores fora destas. As plantas geogr ca e de registros podem ser ar mazenadas em um sig em uma estrutura temporal, representando o presente, o passado e o planejado.
Sistemas de Censo
Sistemas de censo ajudam a monitorar mudan as nas caracter sticas da popula o e s o impor tantes para planejamento tanto a n vel global quanto local. Existem v rios m todos de se realizar censos. Censos exaustivos s o caros e usualmente feitos em intervalos de dez anos, quando uma s rie de perguntas relativas vida dos habitantes s o postas renda, acesso a telefone, eletrodom sticos, etc.... Naturalmente, an lises estat sticas derivadas durante o intervalo entre censos podem se tornar irreais devido desatualiza o dos dados. Tradicionalmente, o papel de sigs grande no est gio de p s-processamento das informa es, onde dados s o analisados e facilmente espacializados gerando mapas. Alguns pa ses, como os escandinavos, mant m seus dados constantemente atualizados, agre gando informa o de indiv duos, inclusive espacial, via endere o postal, em reas relevantes administrativamente. Para isso, fontes de informa o nascimentos, casamentos, mortes, mu dan as de casa s o devidamente registradas pelas autoridades. Uma terceira forma de se obter dados de censo explora a rela o entre extens o de rea ocupada e popula o, com a ajuda de cobertura por imagens de sat lite e fotogra as a reas, detectando-se manchas urbanas, e utilizando sigs. Esta t cnica n o fornece informa es s cio-econ micas e ine ciente para reas rurais. Merece destaque o sistema TIGER
Topologically Integrated Geographic Encoding and Referencing, do Census Bureau do EUA, que prov a mais detalhada rede de caracter sticas e cobertura administrativa dispon vel no pa s Rhi93 .
Outras Aplica es S cio-Econ micas

Sistemas de navega o, mar tima ou terrestre, tamb m podem se bene ciar bastante de sigs.
2.3. APLICA ES
31
A rea de navega o terrestre inclue sistemas experimentais de tr fego, reportando en garrafamentos, sistemas de monitoramento de frotas e sistemas de navega o para autom veis Whi93 . No ltimo caso, os sigs podem agregar funcionalidade de sistemas hiperm dia Cas93 , oferecendo facilidades como apresenta o de mapas, dire es verbais, caminhos, procura de des tinos por endere o e indica o de infraestruturas existentes. Na rea de navega o mar tima, o desenvolvimento de cartas n uticas digitais apresenta-se como um caminho natural para otimizar o uso dos recursos das embarca es Oli95a . De fato, o aumento do tr fego mar timo em determinadas regi es do planeta, aliado s condi es atmosf ricas e ao estado do mar, demanda cada vez mais o desenvolvimento de sistemas de aux lio navega o que minimizem a ocorr ncia de acidentes que possam, por exemplo, resultar na destrui o da natureza atrav s do derramamento de imensas cargas de leo ou elementos qu micos. As cartas n uticas s o fundamentais como instrumento de seguran a da navega o, al m de fonte de dados para pesquisa e an lise dos ambientes por elas representados. Outra aplica o s cio-econ mica para sigs s o sistemas de informa es de mercado. An lises de mercado necessitam muitas vezes de informa es espacialmente diferenciadas sobre consumidores e competidores. Sistemas de informa es de mercado bene ciam-se das funcio nalidades de sigs principalmente quando estes est o acoplados a ferramentas para an lise nanceira, sistemas de apoio decis o e sistemas especialistas.
2.3.3 Aplica es Ambientais

Algumas aplica es ambientais, conforme ressaltado por Fed93 , precedem o uso de computa dores. A modelagem espacial de fen menos hidrol gicos, por exemplo, come ou h mais de cem anos e o uso de t cnicas anal ticas em problemas biol gicos e ecol gicos foi iniciado nos anos 20. sigs vieram agilizar este processamento. As aplica es ambientais variam enormemente de rea. Baseado em Ram94 , distinguem-se dois grupos de origem: o meio ambiente, incluindo ecologia, clima, gerenciamento orestal e polui o; e o uso dos recursos naturais, envolvendo extrativismo vegetal, extrativismo mineral, energia, recursos h dricos e oce nica. Enquadram-se em aplica es de meio ambiente modelagem clim tica e ambiental, previ s o num rica do tempo, monitora o do des orestamento e monitora o da emiss o e a o de poluentes. Ilustrando tipos aplica es de uso de recursos naturais t m-se identi ca o e mapea mento mineral e petrol fero, planejamento e supervis o de redes hidroel tricas, gerenciamento costeiro e mar timo, e sistemas de informa o de recursos hidrol gicos. As aplica es podem ter abrang ncia em uma escala global, continental, regional ou at mesmo local. Aplica es ambientais s o em geral relacionadas a problemas em escalas menores que as s cio-econ micas 1:20.000 ou menores, com conseq ente perda de precis o de medida. Os dados s o principalmente obtidos atrav s de sensoriamento remoto, como fotos de sat lite ou imagens de radar, complementados por amostras coletadas no campo. Assim, por exemplo, a distribui o da vegeta o em uma regi o n o se ocupa de plantas individuais, mas das esp cies
32
dominantes. Segue uma discuss o em mais detalhes sobre alguns tipos de aplica es ambientais.
Sistemas de Informa o de Solos

sigs auxiliam sistemas de informa o de solos na cataloga o de per s de solo coletados, no
mapeamento atrav s de interpola o de dados gerando varia es espaciais, e no uso dessas informa es para an lise e modelagem Bur93 . O uso de sistemas de informa o de solos n o est limitado apenas a grandes cat logos nacionais, mas aplica-se tamb m a estudos locais, tais como estudos voltados para a agricultura em fazendas. A primeira fase do desenvolvimento de um sistema de informa o de solos consiste da cataloga o de per s. Per s de solos s o dif ceis de registrar pois amostras s o coletadas nos diversos horizontes que ocorrem na natureza. Por m, estes horizontes n o s o nem identi cados, nem classi cados de forma clara. Assim, o n mero de horizontes pode variar enormemente, mesmo em uma nica unidade de mapeamento. Sistemas voltados para cat logo de dados de solos est o entre os primeiros usos de sigs, trazendo como benef cio o desenvolvimento de padr es para cataloga o. A segunda fase do desenvolvimento de um sistema de informa o de solos consiste na de ni o de m todos rigorosos para mapeamento. Embora o fen meno da varia o espacial cont nua de propriedades de solos seja conhecido h bastante tempo, somente no nal da d cada de 70 que os cientistas de solos passaram a dedicar um esfor o maior a t cnicas de interpola o, in cluindo m todos geoestat sticos. A distribui o espacial de fen menos geol gicos, pontuais em uma escala regional, tais como dep sitos de minerais e epicentros s smicos, pode parcialmente ser explicada e prevista a partir de mapas e imagens mostrando vari veis geol gicas, geof sicas e geot cnicas. A terceira fase de quanti ca o de informa es de solos inclui, em diferentes dire es, o uso da informa o para an lise e modelagem e o uso de sistemas especialistas.
Estudo Ambiental de Mudan as Globais

Atualmente, um grande desa o mundial o programa de mudan as globais. Ele parte do pres suposto de que mudan as clim ticas, de fauna, ora e recursos naturais s podem ser explicados em uma escala global, de forma interdisciplinar, envolvendo bi logos, ecologistas, ge logos, geo f sicos e outros cientistas. Neste contexto, sigs desempenham um papel fundamental. Com estes novos estudos interdisciplinares, que consideram a Terra como um sistema nico completo, h necessidade da revis o de v rias fun es de um sig, desde o simples tratamento de proje es cartogr cas e problemas de representa o at quest es conceituais em modelagem de sistemas. Este esfor o mundial motivou uma coleta de dados em todo o planeta, com a coopera o de v rias na es. Bancos de dados de dados tem ticos globais est o sendo criados e integrados. Os dados globais podem ser divididos em tr s categorias: dados globais de refer ncia, de longa
2.3. APLICA ES
33
dura o, com escala temporal de d cadas a s culos por exemplo, par metros clim ticos, de solos, de densidade populacional; dados globais sin pticos para monitora o, de m dia dura o, com escala temporal de meses a anos, re etindo mudan as globais em uma escala espacial e temporal por exemplo, cobertura de neve, ventos e precipita o; e dados globais tipo s ries temporais para monitora o, consistindo de s ries temporais, ndices de medidas ou m dias para c lulas por exemplo, ndice de vegeta o e temperatura oce nica. Existem v rios programas globais que merecem destaque CHK93 , tr s das quais s o apre sentadas a seguir. A NASA possui uma iniciativa chamada
Miss o do Planeta Terra, que visa construir mo delos do sistema terrestre de forma a permitir gerenciamento do clima global. provavelmente o maior e mais completo dos programas globais. Os dados est o sendo coletados para diferentes regi es e em pocas distintas, sendo integrados de forma a permitir acesso em escala global por parte de cientistas, que construir o modelos matem ticos para avaliar a evolu o dos diversos fen menos de interesse. O programa inclui a cria o de uma infraestrutura de gerenciamento de dados georeferen ciados, permitindo a usu rios de diferentes per s cooperarem em suas pesquisas relativas ao meio ambiente. Esta infraestrutura, chamada EOSDIS
Earth Observation System Data and Information System, ser discutida em mais detalhe no cap tulo 13. O
Programa de Mudan as Globais e Clim ticas do NOAA tem o objetivo de prover previ s es con veis sobre mudan as clim ticas globais e suas implica es regionais em uma escala de tempo que varia de meses a s culos. Para isso, s o coletadas imagens de sat lites meteorol gicos, dados de esta es terrestres, entre outros. O ICSU
International Council of Scienti c Unions, integrado por v rias na es, possui o
Programa Internacional de Geosfera-Biosfera, que visa entender e descrever os processos f sicos, interativos e biol gicos que regulam o sistema terrestre, o ambiente nico que prov a vida, as mudan as que est o ocorrendo neste sistema, e o modo como elas s o in uenciadas pelas a es humanas.
Outras Aplica es Ambientais

Esta se o referencia diversas aplica es ambientais, ilustrando a variedade existente. CORINE um programa envolvendo 12 pa ses da Comunidade Europ ia com o objetivo de desenvolver um banco de dados ambiental em escala continental. Sua cria o foi uma rea o aos problemas de chuvas cidas, conserva o da natureza e con itos relativos ao uso da terra no Mediterr neo. Mou93 discute o programa desde a sua cria o, com as fases de an lise de requisitos e entrada de dados, at os passos futuros. WSS90 descreve v rios projetos ambientais que utilizam sigs nos EUA. Um exemplo o estudo do impacto que mudan as de zoneamento trouxeram qualidade da gua em uma regi o, utilizando dados coletados durante 37 anos. Um segundo projeto o uso de um sig para determinar o tra ado de estradas que atravessem parques nacionais, levando em considera o o
34
gradiente dos terrenos, o n mero e tipo dos cursos d' gua a serem cortados e a visibilidade do terreno. Outros exemplos incluem a adequa o de reas para cria o de esp cies em extin o, a previs o de mudan as naturais e o gerenciamento e monitora o de orestas nativas. O projeto apresentado em Kli94 discute a avalia o de diversas regi es com rela o sua adequa o para a cria o de parques de vida selvagem na Nova Zel ndia. As diferentes carac ter sticas de hidrogra a, facilidades de transporte, infraestrutura e vegeta o de cada regi o foram correlacionadas a fatores como quantidade de artefatos humanos, solid o, caracter sticas naturais e dist ncia de locais habitados. Com isso, determinou-se quais as reas mais adequa das para estabelecer acampamentos, turismo ecol gico e mesmo ca ada. Certos fatores por exemplo, dist ncia receberam peso distinto de acordo com o per l das pessoas que desejariam utilizar tais facilidades. Aplica es de modelagem hidrol gica est o principalmente voltadas a estudos sobre a qua lidade e a quantidade de gua em uma determinada regi o. Os dados envolvem n o apenas informa es sobre a geometria e topologia de bacias hidrogr cas, lagos e correntes subterr neas, mas tamb m fatores como composi o qu mica, caracteriza o das popula es da regi o analisada e fontes poluentes. O estudo do uxo de correntes exige informa es sobre declive, solo, cobertura vegetal, dentre outros. Dentre as aplica es relacionadas destacam-se gerencia mento de bacias hidrogr cas, modelagem de fontes subterr neas e de eros o.
2.3.4 Aplica es de Gerenciamento

Administra es municipais, regionais e nacionais t m cada vez mais utilizado sigs como uma ferramenta de aux lio tomada de decis es, tanto para a de ni o de novas pol ticas de planeja mento quanto para a avalia o de decis es tomadas. Como exemplo desta classe de aplica es h planejamento de tr fego urbano, planejamento e controle de obras p blicas, planejamento da defesa civil. crescente principalmente o uso de sigs como apoio ao planejamento ambiental ou urbano. Em muitos casos, tal planejamento auxiliado atrav s do acoplamento de sistemas especialistas a sigs. JEM93 enumera v rios exemplos de prot tipos que utilizam tal tipo de acoplamento, para estudos de impacto ambiental: o sistema EVA nos EUA, no caso espec co de conseq ncias de testes militares; o sistema italiano SILVIA e o sistema canadense SAGEE. Wor94b discute as vantagens do uso de sigs em diferentes n veis governamentais na Gr -Bretanha, mostrando a economia proporcionada. Esta economia caracterizada como mensur vel no reuso de dados e na rapidez de gera o de cen rios para aux lio tomada de decis es ou intang vel benef cios popula o, disponibilidade dos dados. MGR93b cont m exemplos do uso de sig para planejamento urbano, onde tais sistemas s o usados para, por exemplo, identi car regi es de expans o urbana, determinar localiza es de pr dios de servi os corpo de bombeiros, delegacias de pol cia e de nir locais de aterros sanit rios. O estudo de LHM94 mostra o uso de sig na Gr -Bretanha para aux lio avalia o de
2.3. APLICA ES
35
propriedades, visando an lise de mercado e taxa o governamental. BDN93 descreve a experi ncia da implanta o de sig na prefeitura municipal de Santo Andr , enquanto SQ93 aborda algumas condicionantes do sucesso de sigs e discute aspectos estrat gicos da concep o, projeto e implanta o destes sistemas na gest o municipal. O gerenciamento de recursos agr colas outra rea de destaque para sigs. AS93 apresenta in meros exemplos de aplica es na agricultura, tais como para an lise de reas de cultivo ou identi ca o de pocas de estiagem. O uso de sig na agricultura tamb m discutido por Roc95 .
36
Cap tulo 3 Caracteriza o de Dados Geogr cos

3.1 Introdu o
O termo dado espacial denota qualquer tipo de dados que descreve fen menos aos quais esteja associada alguma dimens o espacial. Por exemplo, as estruturas moleculares de um composto qu mico s o dados espaciais. Os dados utilizados em sigs pertencem a uma classe particular de dados espaciais: os dados geo-referenciados ou dados geogr cos. O termo denota dados que descrevem fatos, objetos e fen menos do globo terrestre associados sua localiza o sobre a superf cie terrestre, num certo instante ou per odo de tempo. Este cap tulo discute informalmente as principais categorias de dados utilizados em um sig preparando o leitor para a abordagem mais formal do cap tulo seguinte. Em particular, o cap tulo introduz as no es fundamentais de campo e objeto geogr co FG90, ea92, Cou92 .
3.2 Caracter sticas Gerais de Dados Geogr cos

Dados geo-referenciados s o comumente caracterizados a partir de tr s componentes fundamen tais Aro89, Dan90, Peu94 : caracter sticas n o-espaciais, descrevendo o fen meno sendo estudado, tais como o nome e o tipo da vari vel; caracter sticas espaciais, informando a localiza o espacial do fen meno, ou seja, seu geo-referenciamento, associada a propriedades geom tricas e topol gicas; caracter sticas temporais, identi cando o tempo para o qual tais dados s o considerados, isto , quando foram coletados e sua validade. A distribui o espacial dos dados geo-referenciados pode se restringir a uma, duas ou tr s dimens es. Exemplos s o medidas pluviom tricas em locais pr -determinados dados pontuais; 37
38
CAP TULO 3. CARACTERIZA O DE DADOS GEOGR FICOS
especi ca o de uma rede vi ria dados lineares; descri o de uma rea de vegeta o dados em 2D; ou fen menos atmosf ricos dados em 3D. Enquanto determinados fatores perma necem relativamente constantes ao longo do tempo por exemplo, tipo de solo ou bacia hi drogr ca, outros aspectos podem variar rapidamente, em fun o de mudan as pol ticas ou s cio-econ micas. Outro aspecto muito importante reside no fato de que os fen menos geo-referenciados n o existem sozinhos no espa o, ou seja, t o importante quanto localiz -los descobrir e representar os seus relacionamentos. Estes relacionamentos s o in meros e, de fato, dependem da percep o do usu rio. Tais relacionamentos s o muitas vezes imprecisos por exemplo,
perto,
direita de e dependentes do contexto. De uma forma geral, consultas a dados em sigs podem envolver tanto o estado de um fen meno quanto a sua distribui o espacial e temporal. As consultas podem se limitar a um fen meno espec co ou a relacionamentos espa o-temporais entre fen menos geogr cos distintos. As consultas t picas de aplica es sig podem ser caracterizadas como compostas ao longo de tr s eixos Peu94 : onde, o que e quando. Onde se refere a caracter sticas espaciais, enquanto o que se refere s caracter sticas n o espaciais. Cada consulta xa ao menos um dos eixos e faz variar os dados ao longo dos outros dois:
quando + onde ! o que: descreve o conjunto de fen menos geogr cos o que presentes em uma localiza o ou em um conjunto de localiza es onde, dada uma refer ncia temporal quando. Por exemplo,
Quais os tipos de uso de solo encontrados na Bacia do Rio Piracicaba no per odo 1980-1995? quando + o que ! onde: descreve uma localiza o ou seu conjunto onde ocupada por um ou v rios fen menos geogr cos o que em um dado conjunto de intervalos de tempo quando. Por exemplo,
Quais as reas no Estado de S o Paulo ocupadas por planta es de cana no per odo 1950-1980? o que + onde ! quando: descreve o conjunto de per odos quando em que um determi nado conjunto de fen menos geogr cos o que ocupou um conjunto de localiza es. Por exemplo,
Qual o per odo em que a regi o onde hoje se encontra a unicamp foi ocupada por uma planta o de caf ?
Na maior parte dos casos, a dimens o temporal xa, ou seja, os usu rios determinam o conjunto de dados para trabalho em um determinado instante e raramente executam opera es que envolvem varia es temporais. Alguns exemplos dos processos de an lise espacial t picos de um sig est o apresentados na tabela 3.1, adaptada de MGR93a .
3.3. CAMPOS E OBJETOS GEOGR FICOS

An lise Condi o Exemplo
Qual a popula o desta cidade? Localiza o
Onde est ...?
Quais as reas com declividade acima de 20? Tend ncia
O que mudou...?
Esta terra era produtiva h 5 anos? Roteamento
Por onde ir...?
Qual o melhor caminho para o metr ? Padr es
Qual o padr o...?
Qual a distribui o da dengue em Fortaleza? Modelos
O que sucede se...?
Qual o impacto no clima se desmatarmos a Amaz nia? Tabela 3.1: Exemplos de an lise espacial Pergunta Geral
O que est ...?
39
3.3 Campos e Objetos Geogr cos

3.3.1 Modelos de Campos e de Objetos
No contexto de aplica es de sig, o mundo real freq entemente modelado segundo duas vis es complementares: o modelo de campos e o modelo de objetos FG90, ea92, Cou92 . O modelo de campos eld model enxerga o mundo como uma superf cie cont nua, sobre a qual os fen menos geogr cos a serem observados variam segundo diferentes distribui es. Um campo formalizado como uma fun o matem tica cujo dom nio uma abstra o da regi o geogr ca e cujo contradom nio o conjunto de valores que o campo pode tomar. Caso se deseje incluir a varia o do campo ao longo do tempo, basta considerar que o dom nio da fun o um conjunto de pares p; t onde p representa um ponto da regi o geogr ca e t um instante de tempo. Por exemplo, um campo de nindo a cobertura vegetal de uma regi o ser modelado como uma fun o cujo dom nio uma abstra o da regi o e cujo contradom nio o conjunto de tipos de cobertura vegetal; a cada ponto da regi o, a fun o associa o tipo ou tipos de vegeta o nele predominante. Esta vis o enfatiza a descri o da varia o do fen meno geogr co sem se preocupar com a identi ca o de entidades independentes. O modelo de objetos object model representa o mundo como uma superf cie ocupada por objetos identi c veis, com geometria e caracter sticas pr prias. Estes objetos n o s o necessariamente associados a qualquer fen meno geogr co espec co e podem inclusive ocupar a mesma localiza o geogr ca. Artefatos humanos redes vi rias, edi ca es s o tipicamente modelados como objetos. A quest o da identidade fundamental para distinguir os campos dos objetos: por exemplo, existem milhares de reas no Brasil classi cadas como
vegeta o arbustiva valor de campo, mas apenas uma
unicamp objeto identi c vel. Outra distin o entre campos e objetos
40
o princ pio de restri o de preenchimento do plano planar enforcement, que postula que uma superf cie descrita por um campo est particionada em regi es disjuntas, onde a cada regi o est associado apenas um valor do fen meno geogr co representado. Este valor pode ser simples ou composto, dependendo da escala, dispositivo de coleta e fen meno geogr co considerado. A restri o de preenchimento planar n o precisa ser garantida no caso do modelo de objetos, pois estes podem ser tanto disjuntos quanto compartilhar o mesmo espa o. Por exemplo, sejam os casos de mapas de vegeta o e planta de um loteamento. Num mapa de vegeta o, cada ponto da regi o geogr ca est associado a um tipo espec co de vegeta o por exemplo,
arbustiva; na planta, objetos distintos podem conviver em uma mesma localiza o por exemplo, um lote e uma edi ca o.
3.3.2 Representa es para Campos e Objetos

A modelagem de dados geogr cos difere da tradicional n o apenas devido s caracter sticas es paciais, mas tamb m por envolver a quest o da representa o, que varia conforme a perspectiva do usu rio ou aplica o, ou segundo fatores meramente t cnicos. Isto freq entemente signi ca que diferentes representa es coexistem para um mesmo campo ou objeto Chr93 . Por exem plo, o objeto unicamp pode ser representado de forma diferente por top grafos, especialistas em educa o, em saneamento, ou ecologistas. Estas alternativas de representa o coexistir o mesmo quando os fatores t cnicos forem xados e o fen meno considerado n o mudar. Os fatores t cnicos que levam a m ltiplas representa es incluem, por exemplo, resolu o, escala e proje o cartogr ca. Em particular, o termo resolu o se refere ao n vel de abstra o com que se deseja considerar um campo ou objeto. Assim, a unicamp pode ser considerado como uma regi o at mica alto n vel de abstra o ou como composto por um conjunto de entidades os pr dios n vel de abstra o mais detalhado. Em alguns casos, a varia o de resolu o, como citado em Rig95 , pode ser implementada por mudan a de escala: a regi o da unicamp considerada at mica em uma escala pequena e composta por pr dios em uma escala maior. No entanto, nem sempre uma mudan a de escala su ciente para estabelecer correspond ncia entre duas representa es de um mesmo fen meno em resolu es diferentes. Do ponto de vista de implementa o de um sig, o gerenciamento de representa es m ltiplas deve ser considerado em v rios n veis: interface apresenta o, modelagem e estruturas de dados. A cada um desses n veis correspondem diferentes problemas: redund ncia de dados, consist ncia e multiplicidade de comportamentos de um mesmo campo ou objeto, em fun o de suas representa es. Al m destes pontos, deve-se levar em conta que uma representa o pode ser materializada, quando armazenada explicitamente no banco de dados, ou calculada, quando h uma fun o registrada no sig capaz de comput -la a partir de outra representa o. A dicotomia de modelagem de campos ou objetos se re ete, no n vel de representa o, no chamado debate raster versus vector Cou92 . Campos s o freq entemente representados no formato de tessela o ou matricial, ou seja, em uma matriz cujos elementos s o unidades poligonais regulares do espa o c lulas. Os relacionamentos topol gicos no espa o s o implicita mente determinados a partir da vizinhan a das c lulas e as coordenadas geogr cas s o obtidas
3.4. PRINCIPAIS CLASSES DE DADOS GEOGR FICOS
41
indiretamente a partir da posi o da c lula na matriz. A cada c lula corresponde um valor do campo representado ou seja, n o pode haver dois valores distintos para uma mesma c lula. O valor associado a cada c lula considerado como v lido para toda a regi o por ela representada, o que pode causar erros consider veis dependendo da escala de obten o dos dados coletados. O termo raster designa c lulas retangulares, mas na maioria das vezes usado como termo gen rico para a representa o matricial. C lulas retangulares s o tamb m chamadas de pixels. Outros formatos para c lulas s o tri ngulos e hex gonos KHFM93 . Opera es t picas neste tipo de representa o s o a sobreposi o de matrizes, combinando os valores das c lulas atrav s de fun es matem ticas, ou a abstra o de conjuntos de v rias c lulas adjacentes em uma nica c lula, cujo valor calculado a partir dos valores das c lulas selecionadas generaliza o. J um objeto geogr co tipicamente representados no formato vetorial, ou seja, sua geo metria descrita utilizando pontos, linhas e pol gonos. Naturalmente, deve haver uma trans forma o bem de nida entre o sistema de coordenadas utilizado na descri o geom trica e o sistema de coordenadas geogr cas adotado. Linhas s o formadas por seq ncias de pontos; e pol gonos abertos ou fechados por seq ncias de linhas. Opera es comuns neste tipo de repre senta o s o opera es topol gicas por exemplo, adjac ncia, inclus o e m tricas dist ncia, rea. Representa es vetoriais podem ter diferentes n veis de so stica o. Representa es n o estruturadas se restringem a armazenar listas de coordenadas sem qualquer preocupa o com otimiza o do processamento por exemplo, o modo spaghetti. Representa es topol gicas per mitem armazenar, associada localiza o, informa o sobre relacionamentos de contig idade e vizinhan a dos elementos armazenados SMSE87 .
3.4 Principais Classes de Dados Geogr cos

Esta se o discute brevemente algumas das principais classes para tratamento de dados geo gr cos em Geoprocessamento, tais como mapas tem ticos, mapas cadastrais, redes, modelos num ricos de terreno e imagens.
3.4.1 Mapas Tem ticos e Mapas Cadastrais

Mapas tem ticos s o mapas que mostram uma regi o geogr ca particionada em pol gonos, segundo os valores relativos a um tema por exemplo, uso do solo, aptid o agr cola. Os valores dos dados s o em geral inseridos no sistema por digitaliza o ou, de forma mais automatizada, a partir de classi ca o de imagens. A maior parte dos sistemas armazena dados para estes tipos de mapas usando uma represen ta o topol gica, onde as arestas determinam os limites entre regi es. A topologia constru da do tipo aresta-v rtice-face: arestas se conectam entre si atrav s de v rtices pontos inicial e nal e arestas que circundam uma rea de nem uma face pol gono ou regi o. Um mapa tem tico tamb m pode ser armazenado no formato matricial raster. Neste caso, a rea correspondente ao mapa dividida em c lulas de tamanho xo. Cada c lula ter um
42
valor correspondente ao tema mais freq ente naquela localiza o espacial. Em mapas tem ticos, os pol gonos apresentados s o resultado de fun es de an lise e classi ca o de dados e n o correspondem a elementos identi c veis do mundo real. Mapas cadastrais, ao contr rio, apresentam objetos identi c veis por exemplo, lotes de terreno. Por exemplo, os lotes de uma cidade s o elementos do espa o geogr co que possuem atributos por exem plo, propriet rio, valor venal, IPTU devido. Os dados s o em geral armazenados usando uma representa o topol gica.
3.4.2 Redes
Em Geoprocessamento, o conceito de rede denota as informa es associadas a servi os de uti lidade p blica, como gua, luz e telefone; redes relativas a bacias hidrogr cas; e rodovias. As informa es espaciais s o usualmente armazenadas em forma de grafo que armazena informa es sobre recursos que uem entre localiza es geogr cas distintas. Os grafos usam topologia arco-n , onde os arcos t m um sentido de uxo e os n s podem ser fontes ou sorvedouros. Como observa Goodchild Goo92 , uma rede um sistema de endere amento 1-D embutido no espa o 2-D. Para citar um exemplo, tome-se uma rede el trica, que tem, entre outros, os componentes: postes, transformadores, sub-esta es, linhas de transmiss o e chaves. As linhas de transmiss o ser o representadas topologicamente como os arcos de um grafo orientado, estando as demais informa es concentradas em seus n s. Opera es t picas sobre rede s o c lculo de caminho timo e cr tico. V rios algoritmos de c lculo de propriedades da rede podem ser resolvidos apenas considerando a topologia da rede e de seus atributos. A rea de redes um grande motivador para inova es em sig, merecendo destaque a integra o de dados, a segmenta o din mica, linguagem de visualiza o e a capacidade de adapta o. Outro aspecto necess rio para aplica es de redes a capacidade de de nir diferentes cortes l gicos de uma rede sem necessidade de replicar a estrutura topol gica da rede. Por exemplo, ao se asfaltar parte de uma estrada de terra, ser preciso atualizar esta informa o, sem ter de redigitalizar todas as coordenadas de localiza o da estrada. Esta capacidade, usualmente denotada por segmenta o din mica, permite separar os diferentes n veis de informa o relativos a uma mesma rede. O pacote m nimo dispon vel nos sistemas comerciais consiste tipicamente de c lculo de cami nho timo e cr tico. Este pacote b sico insu ciente para a realiza o da maioria das aplica es, pois cada usu rio tem necessidades completamente distintas. No caso de um sistema telef nico, uma quest o pode ser:
quais s o todos os telefones servidos por uma dada caixa terminal?. J para uma rede de gua, pode-se perguntar:
Se injetarmos uma dada percentagem de cloro na caixa d' gua de um bairro, qual a concentra o nal nas casas?
43
3.4.3 Modelos Num ricos de Terreno

O termo modelo num rico de terreno ou MNT utilizado para denotar a representa o uma grandeza que varia continuamente no espa o. Comumente associados altimetria, tamb m podem ser utilizados para modelar unidades geol gicas, como teor de minerais ou propriedades do solo ou subsolo como aeromagnetismo. Entre os usos de modelos num ricos de terreno, pode-se citar Bur86 : Armazenamento de dados de altimetria para gerar mapas topogr cos; An lises de corte-aterro para projeto de estradas e barragens; C mputo de mapas de declividade e exposi o para apoio a an lises de geomorfologia e erodibilidade; An lise de vari veis geof sicas e geoqu micas; Apresenta o tridimensional em combina o com outras vari veis. Uma das formas de obter dados relativos a uma grandeza que varia continuamente no espa o atrav s de sele o de pontos nos quais feita a amostragem da grandeza por exemplo, a composi o do solo de uma regi o determinada a partir de amostras retiradas de locais prede nidos. Outra forma de aquisi o de dados atrav s da digitaliza o de isolinhas a partir de mapas existentes ou valores computados a partir de imagens digitais, como o caso de altimetria. Isolinhas s o linhas de nidas como uma s rie de coordenadas x e y e rotuladas por uma grandeza z. Existem dois grupos b sicos de representa o para MNTs: grades regulares e grades trian gulares. Uma grade regular uma matriz de elementos com espa amento xo, onde a cada elemento associado o valor estimado da grandeza na posi o geogr ca coberta pelo elemen to. As grades regulares s o obtidas por interpola o das amostras ou, alternativamente, geradas por restituidores com sa da digital. Uma grade triangular uma estrutura topol gica vetorial do tipo arco-n , onde os n s s o conectados formando tri ngulos que n o se sobrep em e cobrem totalmente a rea de interesse. Uma grade triangular formada por conex o entre amostras, com distribui o espacial possivelmente irregular, utilizando algum m todo de triangula o. O m todo de triangula o mais comum o de Delaunay Tsa93, FG94 sujeita a restri es. Os procedimentos de interpola o espacial variam em fun o das suposi es, de suas limita es, do formato dos dados de entrada e do uso a que se destinam, usualmente supondo uma varia o gradual e cont nua das grandezas no espa o. Algumas rotinas mais so sticadas aceitam ser informadas sobre rupturas na distribui o espacial das grandezas por exemplo, um abismo no terreno no caso de altimetria. Para a gera o de grades regulares, os procedimentos de interpola o variam de acordo com a grandeza medida. No caso de altimetria, comum o uso de fun es de pondera o por inverso do quadrado da dist ncia, onde o valor de um elemento da matriz calculado como
44
a m dia entre os valores conhecidos de entrada, tal que os elementos mais pr ximos recebem maiores pesos. J para vari veis geof sicas, procedimentos de vari veis geof sicas, s o utilizados procedimentos de ltragem bidimensional ou de geoestat stica como a krigeagem. As grades triangulares s o normalmente melhores para representar a varia o do terreno, pois capturam a complexidade do relevo sem a necessidade de grande quantidade de dados redundantes, pois regi es mais acidentadas podem ser representadas por uma maior quantidade de n s. As grades regulares t m grande redund ncia em terrenos uniformes e di culdade de adapta o a relevos de natureza distinta no mesmo mapa, por causa da grade de amostragem xa. Os modelos num ricos de terreno tamb m podem ser convertidos para mapas tem ticos e para imagens. Em ambos os casos, a grandeza num rica quantizada, seja para um n mero pequeno de valores caso de mapas tem ticos, seja para a varia o associada a imagens valores discretos.
3.4.4 Imagens
Tradicionalmente, muitos sigs utilizam mapas como a forma b sica para a constru o dos ban cos de dados geogr cos e tratam imagens obtidas por sensoriamento remoto apenas como uma forma de captura indireta de informa o espacial a ser incorporada a tais mapas. Por m, com o desenvolvimento das reas de Sensoriamento Remoto e Processamento Digital de Imagens, aliadas a t cnicas para armazenamento, recupera o e apresenta o de imagens, estas passaram a ser utilizadas em conjunto, ou at mesmo em substitui o, a mapas. Uma imagem de um objeto real , em princ pio, cont nua tanto na varia o espacial como nos n veis de cinza. Para que uma representa o digital dessa imagem possa ser criada, necess rio discretiz -la tanto no espa o amostragem quanto na amplitude quantiza o. Uma imagem digital consiste em uma matriz de n meros digitais chamados de pixels uma abrevia o de
picture element. Cada pixel corresponde a um ret ngulo na superf cie da imagem original, n o-digital. Em uma imagem espectral, os pixels cont m valores relacionados re ect ncia ou emit n cia do solo e sua cobertura para a rea retratada pela imagem. De um modo geral, denomina-se imagem multiespectral a cole o de imagens de uma mesma cena, num mesmo instante, obtida por v rios sensores com respostas espectrais diferentes. As medidas registrados pelos sensores variam de fen meno para fen meno. Por exemplo, a banda TM 4 do Landsat ver se o 1.3, no infra-vermelho pr ximo especialmente boa para detectar diferen as na vegeta o e no solo, enquanto a banda TM 1, no azul, tem boa penetra o em corpos aquosos. J fotogra as a reas em infra-vermelho s o apropriadas para se distinguir objetos de vegeta o. A resolu o de uma imagem espectral, dada pela rea coberta por pixels, fun o do sensor, de caracter sticas da cena e do pr -processamento dos dados. Uma imagem de k bandas tem k n veis de cinza associados a cada pixel, um para cada banda espectral. Uma assinatura espectral representa um vetor de dimens o igual ao n mero
45
de bandas de uma imagem, cujas coordenadas s o medidas de radi ncia. Uma imagem colorida , na realidade, um conjunto de tr s imagens obtidas por tr s sensores com curvas de resposta espectral diferentes por exemplo, verde, azul e vermelho. A sensa o de cor que se experimenta devido exist ncia, na retina, destes tr s tipos de sensores. O processamento digital de imagens compreende um conjunto de opera es que permitem manipula es num ricas sobre imagens digitais. A aplica o de t cnicas de an lise de imagens pode permitir a identi ca o de qualquer fen meno, a partir dos dados fornecidos por uma variedade de sensores remotos atuando sobre determinada rea. Na an lise de imagens, a entrada do processamento uma imagem e a sa da uma descri o n o pict rica da imagem, num processo chamado de redu o de dados. Na manipula o num rica em geral, tanto a entrada quanto a sa da s o imagens. Existem duas grandes classes de opera es: a transforma o radiom trica, onde os valores dos pixels s o alterados sem mo di ca o da geometria; e a transforma o geom trica, onde a geometria da imagem alterada. Pode-se ter dois tipos de transforma o radiom trica: as pontuais, onde a transforma o do valor de um pixel s depende do valor do pixel na imagem original; e as de vizinhan a ou locais, onde o valor resultante do pixel depende tamb m dos valores dos pixels vizinhos. Por m, a manipula o de imagens pode tamb m dar origem a imagens tem ticas, onde os valores dos pontos n o correspondem a medidas f sicas, mas sim a c digos representando temas como
oresta,
gua e outros.
46
PARTE II
47
Cap tulo 4 Modelagem de Dados Geogr cos

4.1 Introdu o
Um modelo de dados deve fornecer ferramentas para descrever a organiza o l gica de bancos de dados, bem como de nir as opera es de manipula o de dados permitidas. Durante o desenvolvimento de uma aplica o espec ca, o processo de modelagem, quando bem conduzido, produz uma vis o abstrata da realidade. Isto facilita o acesso e a reutiliza o dos dados, bem como a expans o do banco de dados e a sua integra o com outros criados para aplica es distintas, mas que descrevem a mesma realidade. Todas estas observa es aplicam-se ao caso de sig, exceto que devem ser estendidas para incluir quest es espec cas a Geoprocessamento. Este cap tulo endere a o problema de modelagem em sig, apresentando um modelo de dados geogr cos espec co, que ser utilizado em outros cap tulos deste texto. O modelo de dados apresentado est organizado em n veis de abstra o, distinguindo claramente entre abstra es conceituais de um fen meno do mundo real e suas representa es. O modelo baseia-se nos trabalhos dos autores CFS+94, MJ93, MCS+ 94 e adota o enfoque multin vel de GV93 . O cap tulo termina com uma discuss o sobre algumas propostas de padroniza o para dados geogr cos Sur94, MW92, Car94 . Propostas mais antigas de modelos de dados geogr cos baseiam-se no modelo relacional de dados, por m estudos mais recentes recomendam o uso de modelos orientados a objetos. Al m de ex veis, tais modelos facilitam a especi ca o incremental de aplica es, caracter stica importante em sig. Atualmente, o modelo de dados orientado a objetos mais completo utilizado comercialmente o proposto pelo padr o saif, descrito no nal deste cap tulo. As refer ncias Chr90, Cou92, FR93, Goo91, KT92, RM92 cont m discuss es b sicas sobre modelagem de dados geogr cos enquanto que MMS93, WHM90, SV92, SA93, DRS93b, AA93, PMP93, Wor94a, Ege95 in cluem considera es envolvendo orienta o a objetos. As refer ncias Lan93a, MJ93, NTE92, Peu93, FCF92, Bot95 combinam aspectos temporais com modelagem de dados geogr cos, a refer ncia HS92a aborda aspectos de hiperm dia, e a refer ncia ZM92 endere a aspectos de intelig ncia arti cial. 49
50
CAP TULO 4. MODELAGEM DE DADOS GEOGR FICOS
4.2 Um Modelo de Dados Geogr cos

Esta se o descreve os aspectos estruturais de um modelo de dados geogr co que apresenta uma abordagem uni cada das vis es de campos e objetos e permite a exist ncia de m ltiplas representa es para um mesmo fen meno geogr co. O modelo separa a especi ca o em diferentes n veis de abstra o, liberando assim o usu rio da necessidade de se envolver com detalhes de implementa o f sica. Este modelo de dados utilizado no sistema spring 2.0, descrito no cap tulo 11. Para facilitar o entendimento do modelo, descrevemos seus detalhes utilizando terminologia de bancos de dados orientados a objetos. Note-se, no entanto, que a modelagem orientada a objetos n o obriga o armazenamento em um sgbd orientado a objetos, mas simplesmente visa dar ao usu rio maior exibilidade na modelagem incremental da realidade. Neste texto, utilizamos o modelo orientado a objetos baseado em classes de Bee89 . Um objeto uma inst ncia de uma classe e caracterizado por seu estado conjunto de valores de atributos e comportamento conjunto de opera es ou m todos que podem ser aplicados ao objeto. Um objeto o pode ser composto por outros objetos o1,...,on, caso em que o chamado complexo e o1 ,...,on s o os componentes de o. Este processo de composi o realizado atrav s da aplica o de construtores por exemplo, construtores de conjunto que permitem a especi ca o progressiva de objetos cada vez mais complexos a partir de componentes previamente de nidos. Objetos n o complexos s o denominados simples. As classes s o estruturadas em hierarquias de heran a; os ancestrais de uma classe C na hierarquia s o as superclasses de C e seus descendentes as subclasses de C . Os descendentes de uma classe herdam sua estrutura e comportamento.
4.2.1 N veis de Especi ca o

O modelo de dados adota uma estrat gia de especi ca o que identi ca quatro n veis de abs tra o:
n vel do mundo real: cont m os elementos da realidade geogr ca a serem modelados como,
por exemplo, rios, temperatura, redes telef nicas.
n vel conceitual: comporta o ferramental para modelar formalmente campos e objetos geo
gr cos em um n vel alto de abstra o. Este n vel determina as classes orientadas a objetos b sicas que dever o ser criadas no banco de dados. Neste n vel devem ser tam b m de nidas as opera es e a linguagem de manipula o de dados dispon veis para o usu rio. n vel conceitual a classes de representa es, que podem variar conforme a escala, a proje o cartogr ca escolhida, a poca de aquisi o do dado, ou mesmo conforme a vis o do usu rio ou aplica o, como j discutido no cap tulo 3.
n vel de representa o: associa as classes de campos e objetos geogr cos identi cadas no
4.2. UM MODELO DE DADOS GEOGR FICOS
51
n vel de implementa o f sico ou interno: de ne padr es, formas de armazenamento e
estruturas de dados para implementar as diferentes representa es. As decis es de im plementa o abordadas admitem um n mero muito grande de varia es, em fun o das aplica es s quais o sistema voltado, a disponibilidade de algoritmos e o desempenho do hardware. Este assunto ser discutido em detalhe no cap tulo 9.
Assim, um campo ou objeto geogr co especi cado formalmente pelo usu rio no n vel conceitual e associado a diferentes representa es, cada uma das quais por sua vez armazenada em uma variedade de estruturas f sicas. Com este modelo, as dicotomias tradicionais de mo delagem campos versus objeto e de representa o matricial versus vetorial podem ser devidamente equacionadas. Este enfoque multi-n vel de modelagem de dados geogr cos indica claramente que a in terface do usu rio em um sig deve re etir o n vel conceitual, mais pr ximo de sua realidade, ocultando tanto quanto poss vel os detalhes de representa o e implementa o. Isso faz com que o usu rio trabalhe com conceitos abstratos do mundo real, sem obrig -lo a entender os pro blemas de implementa o. Ao mesmo tempo, permite especi car opera es de diversos tipos para um mesmo objeto conceitual, que podem variar de acordo com o tipo de representa o adotada. Por outro lado, n o impede que um usu rio muito especializado crie novas opera es sobre representa es, espec cas para suas aplica es. Estes n veis podem ser comparados aos encontrados na arquitetura ansi-sparc de sistemas de bancos de dados ANS75 . Os n veis conceitual e de implementa o s o os mesmos daquela arquitetura, mas o n vel de representa o n o tem correspondente na rea de bancos de dados, pois o problema de representa o m ltipla raramente ocorre em aplica es convencionais. Esta modelagem multin vel exige, no entanto, decis es de mapeamento a cada n vel. A passagem do mundo real para o mundo conceitual depende do dom nio de aplica o e a passagem do n vel conceitual para o n vel de representa o, de decis es t cnicas mais detalhadas. Por exemplo, imagens de sat lite e grandezas geof sicas s o normalmente de nidas como campos, enquanto mapas cadastrais ou urbanos correspondem a objetos geogr cos Cam95 . Levantamentos tem ticos, por outro lado, podem se prestar a duas interpreta es, conforme seu uso: quando se tratar de trabalhos de invent rio, s o modelados como campos ou, mais especi camente como campos tem ticos. No caso de estudos detalhados em m dias e grandes escalas, onde cada regi o caracterizada por quali cadores espec cos por exemplo, em estu dos de fatores sanit rios, conveniente que estes levantamentos sejam associados a objetos geogr cos Cam95 . As duas se es seguintes deste cap tulo discutem os n veis conceitual e de representa o do modelo, deixando o tratamento das opera es e da linguagem de manipula o de dados para os cap tulos 5 e 6, respectivamente.
52
4.2.2 N vel Conceitual

O n vel conceitual do nosso modelo permite modelar o mundo real como uma cole o de clas ses orientadas a objetos, classi cadas em classes convencionais e classes georeferenciadas ou geo-classes. As inst ncias das geo-classes modelam campos e objetos geogr cos, enquanto as inst ncias das classes convencionais correspondem ao conceito padr o de classes em sgbd orien tados a objetos. Os objetos das classes convencionais s o denominados objetos n o espaciais. Uma mesma entidade do mundo real pode ser modelada em uma geo-classe ou n o, depen dendo da situa o. Por exemplo, um transformador em uma aplica o de rede el trica, quando n o estiver instalado e, portanto, for apenas um item de estoque, pode ser modelado como uma inst ncia de uma classe convencional, com atributos que descrevem suas caracter sticas tais como peso ou pot ncia. O mesmo transformador, quando instalado em um local da rede, dever ser considerado ent o como uma inst ncia de uma geo-classe. As conseq ncias desta dupla possibilidade de modelagem ser o discutidas na se o 4.2.4. Como a modelagem de dados tradicionais exaustivamente abordada na literatura de bancos de dados, de agora em diante nos ocuparemos apenas da modelagem de geo-classes. As inst ncias de geo-classes est o associadas a regi es da superf cie terrestre, chamadas geo-regi es. A geometria de uma geo-regi o descrita em um sistema de coordenadas apropria do, que deve ser expl cita ou implicitamente fornecido. Diferentes geo-regi es poder o estar descritas em sistemas de coordenadas distintos. No restante do texto, suporemos sempre um sistema de coordenadas planas, induzido por uma transforma o cartogr ca projetiva e uma dada escala, e consideraremos pontos e linhas poligonais polilinhas como geo-regi es degene radas. Existem duas hierarquias b sicas de geo-classes, cujas ra zes s o as classes GeoCampo e GeoObjeto. As inst ncias de GeoCampo, chamadas de geo-campos, descrevem campos geogr cos e possuem os seguintes atributos espaciais:
localiza o: descreve uma geo-regi o R, chamada de localiza o da inst ncia; contradom nio: descreve um conjunto de valores V , chamado de contradom nio da
inst ncia.
mapeamento: descreve uma fun o f : R 7! V , chamado de mapeamento da inst ncia,
modelando um campo geogr co sobre R que toma valores em V .
Estes atributos s o obrigat rios e formam a componente espacial do geo-campo. O projetista da aplica o poder de nir sub-classes da classe GeoCampo com novos atributos como, por exemplo, a data de coleta ou dispositivo utilizado. Os atributos convencionais de um geo-campo formam a sua componente convencional. O modelo oferece tr s subclasses de GeoCampo:
Tem tico: uma inst ncia desta classe chamada de um geo-campo tem tico e caracteri
za-se pelo contradom nio V ser um conjunto nito arbitr rio, cujos elementos de nem os
53
temas do geo-campo. Por exemplo, um geo-campo de pedologia de uma geo-regi o ca racterizado pelo conjunto de temas V = latosolo roxo, litosolo, cambisolo ... , conforme os tipos de solo encontrados.
Num rico ou MNT: uma inst ncia desta classe chamada de modelo num rico de terreno e possui como contradom nio um subconjunto dos reais. Um MNT pode ser
utilizado para modelar qualquer grandeza que varie continuamente no espa o, como uma vari vel geoqu mica ou o campo magn tico. DadoSensorRemoto: esta classe uma especializa o de Num rico. Uma inst ncia desta classe chamada de um dados de sensor remoto e possui como contradom nio um subconjunto dos naturais. A inst ncia recebe este nome pois corresponde em geral a dados obtidos atrav s da discretiza o da resposta recebida por um sensor passivo ou ativo de uma rea da superf cie terrestre, numa faixa do espectro eletromagn tico. As inst ncias de GeoObjeto, chamadas de geo-objetos, descrevem objetos geogr cos e possuem o seguinte atributo espacial:
localiza o: descreve uma geo-regi o, chamada novamente de localiza o da inst ncia.
A localiza o de um geo-objeto pode ser explicitamente armazenada ou pode ser computada e forma a componente espacial do geo-objeto. Os atributos convencionais de um geo-objeto formam a sua componente convencional. Novamente, o projetista da aplica o poder de nir subclasses de GeoObjeto com novos atributos. Um geo-objeto pode ser elementar, composto ou fraco. Um geo-objeto elementar um geo-objeto que n o possui outros geo-objetos como componentes e que sempre tem a sua locali za o explicitamente armazenada. Um geo-objeto composto um geo-objeto que cont m outros geo-objetos como componentes. Um geo-objeto composto pode possuir uma localiza o explici tamente armazenada, ou t -la calculada a partir das localiza es dos geo-objetos componentes. Um geo-objeto fraco um geo-objeto que existe somente enquanto zer parte de um geo-objeto composto. Por exemplo, podemos modelar estradas como geo-objetos e uma malha vi ria como um geo-objeto composto cujos geo-objetos componentes s o as estradas individuais. Se a malha vi ria cont m algumas estradas vicinais que n o s o su cientemente importantes para serem tratadas como geo-objetos independentes, estas podem ser modeladas como geo-objetos fracos em rela o malha. Alternativamente, se n o for necess rio especi car cada estrada compo nente, a malha inteira pode ser modelada como um geo-objeto elementar, cuja localiza o uma geo-regi o complexa. Note que n o feita nenhuma restri o quanto consist ncia entre a localiza o de um geo-objeto composto e a de seus componentes. Consideramos que esta consist ncia n o deva fazer parte do modelo, cabendo ao usu rio assegur -la. A no o de geo-objeto composto pode abranger diversos n veis de encapsulamento, depen dendo dos componentes e da localiza o considerados. O geo-objeto unicamp, por exemplo,
54
corresponde universidade, seus geo-objetos pr dios e objetos n o espaciais alunos. A universidade est situada no Estado de S o Paulo, que pode por sua vez ser tamb m mode lado como um geo-objeto composto com centenas de milhares de geo-objetos componentes e associa es entre os mesmos.
4.2.3 N vel de Representa o

Uma representa o especi ca a componente espacial de um geo-objeto ou de um geo-campo. Assim, uma representa o de um geo-campo especi ca a localiza o, o contradom nio e o ma peamento do geo-campo. J uma representa o de um geo-objeto especi ca apenas a sua localiza o, quando explicitamente de nida. Note que, em ambos os casos, a especi ca o da localiza o dever indicar detalhes como, por exemplo, a transforma o cartogr ca projetiva e a escala utilizadas. A discuss o nesta se o aborda informalmente estas quest es, evitando uma descri o longa dos detalhes. Existem duas hierarquias b sicas de classes de representa es, cujas ra zes s o as classes RepGeoCampo e RepGeoObjeto. As inst ncias destas classes s o chamadas de representa es de geocampos e de geoobjetos, respectivamente, e naturalmente descrevem representa es de geo-campos e geo-objetos. No resto desta se o discutiremos algumas classes destas hierar quias, remetendo o leitor a Cam95 para uma descri o completa. Para a classe RepGeoObjeto, o modelo oferece subclasses cujas inst ncias possuem atri butos cujos valores s o elementos geom tricos simples, como pontos, linhas e regi es com e sem buracos ver de ni o na se o 5.2.2, ou elementos complexos constru dos a partir destes. Discutiremos em mais detalhe as classes RepElementar e RepComplexa. Uma inst ncia de RepElementar de ne um elemento geom trico simples ponto, linha e regi o com e sem buracos em um sistema de coordenadas bem de nido. Esta inst ncia representar a localiza o de apenas um geo-objeto. No n vel de implementa o, esta inst ncia poder estar armazenada junto com o objeto ou n o, conforme discutido em detalhe no cap tulo 9. Uma inst ncia de RepComplexa de ne um conjunto C de elementos geom tricos simples ou complexos, em um sistema de coordenadas bem de nido, abstraindo em certo sentido a no o tradicional de mapa cartogr co. O modelo permite associar elementos ou mesmo sub conjuntos de C a geo-objetos distintos e interpret -los como representa es das localiza es destes geo-objetos. Em outras palavras, uma inst ncia de RepComplexa poder representar a localiza o de v rios geo-objetos e, no n vel de implementa o, tipicamente ser armazenada separadamente dos geo-objetos aos quais est associada. Por exemplo, podemos interpretar uma inst ncia c de RepComplexa, de nindo um conjun to L de linhas, como determinando a localiza o das estradas de uma regi o. Sejam E1; :::; En geo-objetos correspondendo a estradas espec cas. Ent o, o modelo permite associar linhas l1; :::; ln em L a E1; :::; En e interpret -las como representando as suas localiza es. Passando agora para representa es de geo-campos, as inst ncias de RepGeoCampo pos

suem os seguintes atributos, muito semelhantes aos dos geo-campos:
localiza o: descreve uma geo-regi o R, chamada de localiza o da inst ncia; dom nio: descreve um conjunto de objetos D;
55
contradom nio: descreve um conjunto de valores V que supomos incluir o valor inde
nido ;
mapeamento: descreve uma fun o g : D 7! V ;
O modelo oferece as seguintes subclasses principais de RepGeoCampo, que variam confor me a de ni o de D:

RepTessela o: D especi ca uma tessela o de R, ou seja, uma subdivis o de R em
c lulas regulares que n o se superp em e que cobrem completamente R.

RepGrade2D: D especi ca uma grade regular de pontos em R.
GradeTriangular: D especi ca uma grade triangular de pontos cobrindo R. SubDivis oPlanar: D especi ca uma parti o de R em regi es simples de nidas veto
rialmente, no sentido da se o 5.2.2 que n o se superp em e que cobrem completamente R.

RepIsoLinhas: D especi ca um conjunto de isolinhas, ou seja, um conjunto de linhas
fechadas que n o se cruzam nem se tocam, contidas em R.
RepPontos: D especi ca um conjunto de pontos contidos em R.
Uma inst ncia da classe RepTessela o chamada de uma representa o por tessela o, ou simplesmente uma tessela o. As inst ncias das outras classes s o denominadas de forma semelhante. As inst ncias destas classes cont m atributos que permitem construir uma aproxima o para o mapeamento do geo-campo representado, gerada atrav s de uma fun o de interpola o bem de nida. Em outras palavras, cada uma destas classes por sua vez apenas a raiz de uma hierarquia de classes, cada uma das quais associada a uma especi ca o precisa da fun o de interpola o utilizada e, no caso das duas primeiras classes, da tessela o ou formato da grade adotados. guisa de ilustra o, considere a exist ncia da classe RepImagem, especializa o de Rep Tessela o. Uma inst ncia desta classe caracteriza-se por especi car uma geo-regi o retan gular R e uma tessela o que divide R em ret ngulos regulares, dispostos em m linhas e n colunas. Dados i 2 1; m e j 2 1; n , existe ent o um e apenas um ret ngulo, denotado por ri;j . Neste caso, a fun o g mapeia cada ret ngulo ri;j em um ponto de V . Assim, podemos adotar uma fun o de interpola o simples que, dada a fun o g, induz o mapeamento parcial
56
f : R 7! V tal que, para todo ponto p 2 R, f p = gri;j sse gri;j 6= e p est no ret ngulo ri;j ; e f p inde nida sse gri;j = e p est no ret ngulo ri;j . Em outras palavras, a fun o g mais a informa o sobre como R divide-se em ret ngulos regulares su ciente para especi car a representa o do mapeamento associado ao geo-campo. Por m, o modelo de dados introduz uma classe, Representa, para capturar a associa o entre geo-campos ou geo-objetos e suas representa es. Cada inst ncia desta classe deve ser entendida como um objeto complexo associando um geo-campo ou geo-objeto o e uma repre senta o r, permitindo navegar de o para r e vice-versa, fazendo assim o papel de um hyperlink, em analogia a sistemas hiperm dia HS92a . Note que este esquema ex vel o su ciente para permitir que:
a mesma representa o induza as componentes espaciais de mais de um geo-campo ou geo-objeto; a componente espacial de um geo-campo ou geo-objeto seja induzida por v rias represen ta es; apenas uma parte da representa o induza a componente espacial do geo-campo ou geo-objeto, situa o novamente indicada por novos atributos. Retornando ao exemplo das estradas, seja c a inst ncia de RepComplexa, de nindo um conjunto L de linhas, e interpretada como determinando a localiza o das estradas de uma regi o. Considere que as estradas s o geo-objetos separados. Haver ent o uma s rie de ins t ncias de Representa associando tais estradas individuais a c e indicando quais linhas de L representam que estradas. Estas linhas espec cas de L fazem um papel semelhante a ncoras em sistemas hiperm dia, quando a inst ncia de Representa entendida como um hyperlink. Por m, observamos que a associa o entre um geo-objeto composto e uma representa o pode ser tanto direta, atrav s de uma inst ncia de Representa, quanto indireta atrav s de inst ncias que associem componentes do geo-objeto representa o. Por exemplo, suponha novamente uma malha vi ria modelada como um geo-objeto composto M , cujos geo-objetos componentes E1; :::; En s o as estradas individuais. Seja c a inst ncia de RepComplexa ante rior. Haver ent o uma associa o indireta entre M e c atrav s das inst ncias de Representa ligando estradas em M e c.
4.2.4 Extens es ao Modelo

O modelo proposto deve ser considerado como uma base sobre a qual diferentes extens es podem ser consideradas. Algumas destas extens es s o comentadas a seguir e correspondem a problemas em aberto. Fen menos georeferenciados s o, por natureza, vari veis no tempo. O modelo pode ser, assim, estendido para levar em considera o a dimens o temporal. Nessa extens o, tanto
4.3. PADR ES PARA SIG
57
geo-campos quanto geo-objetos passam a ser de nidos em fun o do instante de coleta dos dados correspondente no o de tempo v lido em bancos de dados temporais. Esta extens o implica, por sua vez, na solu o de v rios problemas que ainda est o em aberto e que fazem parte de pesquisa de ponta tanto em sig quanto em bancos de dados, desde o n vel de modelagem conceitual at o n vel de implementa o. Aos interessados sugere-se a leitura, por exemplo, de Sno92, SS94, Lan93b . O modelo parte do pressuposto que um fen meno pode ser modelado usando geo-classes e classes convencionais. Se a evolu o temporal for considerada, pode ocorrer que determinada inst ncia de uma classe convencional passe a fazer parte de uma geo-classe e vice-versa. Fre q entemente, um mesmo fen meno pode passar de georeferenciado a convencional v rias vezes durante sua vida, dependendo do instante em que for observado vide, por exemplo, o caso do transformador da se o 4.2.2. Do ponto de vista de bancos de dados, a quest o de migra o de objetos um problema em aberto. Uma alternativa para solucionar este problema seria eliminar a distin o entre classes con vencionais e geo-classes e supor a exist ncia de uma nica hierarquia, GeoClasse, em que as componentes espaciais possam ter valores nulos quando n o forem georeferenciadas. Esta alter nativa acarreta, por m, problemas para a de ni o das fun es de mapeamento de geo-campos, cujo dom nio geo-regi o pode ser inexistente. Al m disto, apesar de mais simples do ponto de vista de implementa o, tal alternativa complica a de ni o do modelo e, por conseguinte, traz maiores problemas para o usu rio. A discuss o do nosso modelo restrita ao espa o bidimensional. A extens o para 3D difere principalmente do ponto de vista de representa o. De fato, no n vel conceitual, a caracteriza o de geo-objetos ou geo-campos n o afetada, embora n o se possa mais considerar a de ni o adotada de geo-regi o. Por outro lado, as representa es dispon veis em 3D oferecem maior leque de variedade e, principalmente, maior n mero de op es de opera es a serem aplicadas. A maioria das aplica es sig est restrita ao espa o 2D, devido complexidade das fun es de an lise no espa o 3D, aos problemas de visualiza o e, principalmente, quest o da modelagem pelo usu rio. Esta ltima apresenta problemas tanto do ponto de vista de modelagem de processos geogr cos quanto de dados georeferenciados, inclusive de cunho cognitivo.
4.3 Padr es para SIG

Em geral, padr es facilitam o compartilhamento, a integra o e a transfer ncia de dados. Pa dr es para sig usualmente incluem padr es para linguagens de especi ca o, transfer ncia de dados, geocodi ca o e documenta o de metadados e formatos. Al m desses, est o surgindo tamb m padr es para qualidade de dados e bibliotecas de objetos espaciais. Esta se o apresenta um panorama da situa o de padr es sig em n vel mundial e descreve brevemente os principais padr es sig.
58
4.3.1 Vis o Geral

Padr es para sig v m sendo de nidos em diversos n veis: internacional, nacional, federal, industrial ou qualquer outra forma de especi ca o aberta ao p blico. Alguns s o legalmente estabelecidos enquanto outros s o padr es
de facto, ou seja, adotados por consenso por uma parte signi cativa da comunidade. A n vel internacional, a iso
International Organization for Standardization criou em 1994 o Comit T cnico iso 211 voltado para informa es geogr cas e geom tica. Atualmente, est desenvolvendo o padr o iso sql3, com extens es multim dia e espaciais, chamadas de sql mm Spatial ANS94 . J o iso 8211 BS 6690 especi ca uma descri o de arquivo para troca de informa es, formada por um dicion rio seguido dos dados propriamente ditos. Nos EUA, o FGDC
Federal Geographic Data Committee, ligado ao NIST
National Institute for Standards and Technology, promove o estabelecimento de padr es sig federais. O FGDC lidera os esfor os do programa NSDI
National Spatial Data Infrastructure, cujos objetivos principais s o desenvolver capacidade para Tos94 : 1 achar conjuntos de dados espaciais e identi car usos apropriados destes conjuntos de dados; 2 transferir ou mover dados sem perda de conte do ou estrutura; e 3 coletar dados para suportar m ltiplos prop sitos. O objetivo 1 foi contemplado com o desenvolvimento de padr es para metadados espaciais. O objetivo 2 est contemplado atrav s da ado o do sdts
Spatial Data Transfer Standard. O sdts MW92 foi adotado como FIPS
Federal Information Processing Standard 173 em 1992. Ainda no mbito federal, existem outros padr es populares nos EUA, v rios dos quais de origem militar. No n vel de ind stria e setores privados norte-americanos, o ANSI
American National Standards Institute criou o comit t cnico X3L1 em 1993 para o desenvolvimento de um padr o sig volunt rio. Entre os membros do X3L1 est o o cons rcio Open GIS, formado por vendedores, academia, governo e organiza es privadas da comunidade sig e de inform ti ca, que est promovendo o desenvolvimento do padr o ogis
Open Geodata Interoperability Speci cation. No Canad , o saif
Spatial Archive and Interchange Format foi aprovado como um pa dr o federal e estadual em 1993, atrav s de um processo do Comit em Geom tica do CGSB
Canadian General Standards Boards, tendo sido desenvolvido pela British Columbia Envi ronment, Lands, and Parks. O saif tem in uenciado o modelo de dados adotado pelo ogis e a parte espacial do sql mm. O DIGIWG Digital Geographic Information Work Group, composto por representantes da Organiza o do Tratado do Atl ntico Norte OTAN, desenvolveu o DIGEST, uma fam lia de padr es para troca de dados espaciais, originalmente voltada para aplica es militares, suportando dados vetoriais, incluindo topologia, e dados matriciais. O Comit T cnico 287 do CEN Comit Europeu de Padroniza o, que agrega 16 pa ses da Comunidade Europ ia, tem a miss o de de nir padr es para informa es geogr cas. O CER CO Comit Europeu de Representantes de Cartogra a O cial, uma organiza o de 20 pa ses, tem o objetivo de desenvolvimento de um formato de transfer ncia europeu. As propostas do
59
CERCO dever o ser consideradas pelo CEN. SMJ94 divide em diversos n veis as especi ca es para trocas de dados, segundo a gura 4.1 Aplica o
Middleware
Sintaxe e Sem ntica de uma Linguagem Objetos Complexos Formato de Dados Figura 4.1: N veis de especi ca o para troca de dados O midleware, entre a aplica o e os dados, deve conter ferramentas necess rias para se construir, por exemplo, sistemas abertos distribu dos embutindo sgbds e sigs. onde o ogis est situado. Os quatro n veis inferiores s o dedicados especi ca o de troca de dados. O primeiro n vel ocupado pela linguagem de especi ca o, com sintaxe e sem ntica bem de nidas, onde se situam o iso sql3 e o saif. Este n vel prov a portabilidade do modelo de uma aplica o. Os tr s n veis seguintes s o para transfer ncia de dados, onde o sdts se situa.
4.3.2 O Padr o SAIF

O padr o saif Sur94 prop e uma linguagem para especi ca o e troca de dados, baseada no modelo de orienta o a objetos. Ele bastante independente do esquema bin rio de codi ca o dos dados. O saif permite a de ni o de
pro les contendo regras e restri es sobre a linguagem. Seu uso facilita a tradu o de modelos de sigs e outros padr es para o saif e o compartilhamento de dados atrav s da ado o de um
pro le comum. O modelo de orienta o a objetos do saif incorpora conceitos de identidade, generaliza o, agrega o, heran a, associa es simples entre objetos, entre outros. N o contempla por m a especi ca o de fun es ou m todos que, por sua vez, est o sendo de nidas no padr o iso sql3, baseado no saif. Conceitualmente, o saif distingue entre representa es de fen menos do mundo real e repre senta es do espa o e tempo em que estes existem. Representa es de fen menos do mundo real s o chamadas de objetos geogr cos e podem ter diversos relacionamentos entre si. Estradas,
60
orestas, medi es de temperatura, derramamento de leo s o exemplos de objetos geogr cos. Seus relacionamentos podem indicar que estradas se cruzam, derramamentos de leo ocorrem durante uma tempestade e assim por diante. A posi o de cada fen meno no espa o represen tada por um objeto espacial. Se espa o e tempo forem considerados, a posi o representada por um objeto espa o-temporal. O modelo do saif oferece algumas classes construtoras geogr cas b sicas, a partir das quais outras podem ser criadas. Exemplos s o classes espaciais, temporais, geom tricas, para relacionamentos expl citos, para metadados incluindo qualidade dos dados e referenciamento espacial e temporal, para a de ni o de estruturas de tipos, para anota o, dentre outras. Descrevemos brevemente algumas classes construtoras de mais alto n vel.
GeographicObjects. Objetos desta classe representam algum fen meno do mundo real.
Sua localiza o no espa o e no tempo dada atrav s de relacionamentos com objetos das classes SpatialObject ou SpatiotemporalObject. Usu rios podem criar novas especializa es da classe GeographicObjects, que j possui as seguintes subclasses padr o:
SpatialDataSet. Objetos desta classe cont m uma s rie de inst ncias das classes
lhan a quanto a metadados ou a geo-referenciamento. Coverage. Objetos desta classe descrevem algum fen meno distribu do sobre uma regi o arbitr ria do espa o, podendo modelar fen menos cont nuos, como altitude, ou discretos, como uso de solo. T m a fun o de mapear uma posi o no espa o em um valor, atrav s de uma fun o espacial. Uma fun o espacial tem como dom nio sempre um conjunto de objetos da classe SpatialObject por m seu contra-dom nio pode ser qualquer conjunto, seja num rico ou de objetos. Como o saif n o oferece suporte para a de ni o de m todos ou fun es, apenas os aspectos estruturais dos dados podem ser modelados. A classe Coverage possui tr s subclasses padr o, que podem ser especializadas pelo usu rio: Raster. Subclasses desta classe s o usadas para descrever dados raster t picos, onde valores s o associados a posi es em uma grade por exemplo, imagens de sat lite. A grade pode ser de nida em termos de uma estrutura regular, multi-dimensional, retangular, hexagonal ou triangular. Field. Objetos desta classe descrevem a distribui o de um fen meno simples sobre uma dada por o do espa o, por exemplo, um modelo de eleva o digital. A geometria de uma inst ncia da classe SpatialObject representa uma regi o cont nua no espa o, quando associada a uma inst ncia da classe Field. PartitionedCoverage. Objetos desta classe s o usados para modelar uma s rie de fen menos geogr cos discretos, tais como tipos de oresta. Sua principal carac ter stica a n o superposi o dos fen menos, sejam esses bi- ou tridimensionais.
GeographicObjects e Annotation veja a seguir. Normalmente possuem alguma seme
61
Graph. Um objeto desta classe consiste em um conjunto de conex es entre objetos da
classe GeographicObjects, de nidas como relacionamentos. Exemplo destes podem ser rotas de avi es e rede de rodovias. GeographicComposite. Um objeto desta classe pode conter outros objetos da classe GeographicObjects. A recurs o permitida.
SpatialReferencing. Os objetos guardam informa es sobre sistema de coordenadas referen
tes a uma proje o horizontal por exemplo, UTM e Lambert e a de ni o de um valor vertical por exemplo dist ncia em metros a partir de um datum ou do centro da Terra, e sobre um sistema de refer ncias geod sicas, que de ne data horizontais e verticais.
SpatialObject. Cada objeto desta classe relaciona-se com um objeto da classe Geographi cObjects e com um objeto da classe SpatialReferencing. Logo, ele cont m informa o
puramente geom trica e tamb m a interpreta o desta no contexto do mundo real. Cons trutores espaciais m tricos por exemplo, dist ncia e vizinhan a e n o-m tricos por exemplo, topologia podem ser de nidos sobre estes objetos. N o permitida a especia liza o da classe por usu rios.
GeometricObject. Objetos desta classe representam abstra es matem ticas, como pontos,
linhas, pol gonos e tetraedros. Construtores espaciais topol gicos por exemplo, adjac n cia e inclus o podem ser diretamente aplicadas aos objetos. O saif prov uma vasta gama de subclasses para GeometricObject, de zero a quatro dimens es, mas n o permi tida a especializa o da classe por usu rios.
TimeObject. Os objetos representam um dado tempo, uma data, um intervalo, uma
dura o ou uma cole o de tais valores. O tempo pode ser especi cado como parte de uma coordenada e, assim, ser inclu do diretamente em uma geometria. Esta abordagem s pr tica quando um objeto pontual. N o permitida a especializa o da classe por usu rios.
TemporalObject, TemporalReference e SpatialTemporalObject. Refer ncias temporais de vem ser fornecidas quando existem objetos da classe TimeObject, ou o tempo for incor porado a coordenadas. Os objetos das classes TemporalObject e TemporalReferencing s o de nidos analogamente a objetos das classes SpatialObject e SpatialReferencing. J a clas se SpatialTemporalObject uma especializa o das classes SpatialObject e TemporalObject,
herdando portanto as suas propriedades.
Annotation. Textos e s mbolos devem ser espacialmente referenciados, tendo os objetos da classe Annotation uma estrutura semelhante aos da classe SpatialObject. SpatialRelationship e TemporalRelationship . Objetos destas classes permitem a de ni o
expl cita de relacionamentos espaciais e temporais entre objetos, oferecendo uma varieda de de associa es m tricas, topol gicas e temporais.
62

GeographicObject
SpatialDataSet
GeographicComposite
Coverage
Graph
Annotation
TemporalObject
SpatialObject
Raster
TimeObject
GeometricObject
Field
TemporalReferencing
SpatioTemporalObject
SpatialReferencing
PartirionedCoverage
Figura 4.2: O modelo de dados parcial do SAIF A gura seguinte representa gra camente na nota o OMT Rum91 parte das classes e associa es apresentadas. Maiores informa es sobre o padr o podem ser encontradas em SAI .
4.3.3 O Padr o SDTS

O sdts MW92 um padr o para transfer ncia de dados espaciais entre sistemas de computa dores possivelmente diferentes. Ele especi ca construtores de troca, formatos de endere amento, estrutura e conte do para dados geo-referenciados vetoriais e matriciais. O padr o sdts est descrito em tr s partes. A Parte 1 apresenta especi ca es l gicas requeridas para a transfer ncia de dados espaciais e possui tr s componentes principais: um modelo conceitual de dados espaciais, a descri o de componentes para qualidade de dados e a descri o de construtores l gicos para formatos de transfer ncia. A Parte 2 cont m uma esp cie de gloss rio de termos, com a de ni o de entidades, atributos, sin nimos e outros. A Parte 3 especi ca como implementar a Parte 1 usando o padr o isoansi 8211 de troca de dados. A tradu o entre um sistema de dados espaciais espec co e o sdts correspondente feita em etapas. Inicialmente uma vis o da informa o espacial traduzida nos conceitos e termos da Parte 2 e ent o representada como objetos espaciais, segundo de nido na Parte 1. Os objetos espaciais, juntamente com atributos e metadados, s o transferidos usando estruturas l gicas de nidas tamb m na Parte 1. Estas estruturas s o sicamente formatadas em arquivos, segundo o especi cado na Parte 3.
63
O modelo conceitual sdts possui tr s partes: um modelo de entidades espaciais, descrevendo entidades do mundo real, tais como cidades, fazendas, rodovias e seus atributos; um modelo de objetos espaciais, descrevendo um conjunto de objetos espaciais tais como pontos, linhas, pol gonos; e um modelo de fen menos espaciais, descrevendo o relacionamento entre os dois primeiros. interessante observar que o sdts reservou o termo
entidade para elementos do mundo real, o termo
objeto para o mundo digital e o termo
fei o
feature tanto para a entidade do mundo real como para sua representa o atrav s de um objeto. O sdts de ne cerca de 13 objetos espaciais simples, com 0, 1 e 2 dimens es, orientados para representa es em superf cies. Eles s o divididos em dois grupos. O primeiro cont m apenas objetos com geometria, sem topologia, sendo formado por pontos, segmentos de linhas dados por dois pontos, seq ncia de segmentos de linhas
strings, arcos de nidos por uma express o matem tica, an is geom tricos dados por arcos e
strings fechados, rea interior, pol gonos geom tricos com buracos, pixels e c lulas de grade. O segundo grupo cont m objetos com geometria e topologia, tais como n s, liga es entre n s
links, cadeias de nidas por segmentos de linha ou arcos limitados por n s, an is geom trico-topol gicos dados por uma seq ncia de cadeias, e pol gonos geom trico-topol gicos. O modelo admite agrega es. Assim, um objeto tridimensional pode ser constru do como um objeto composto a partir de dois objetos bidimensionais, segundo regras de nidas. Uma transfer ncia de dados espaciais signi ca uma troca de informa es sobre uma fei o, ou seja, entidades do mundo real e suas representa es espaciais. Para usar o sdts, um usu rio deve descrever sua vis o pr pria da realidade cartogr ca e geogr ca em termos de entidades e atributos e ent o relacionar as primitivas geom tricas e outras representa es digitais do seu sistema com os objetos espaciais sdts. A especi ca o l gica para transfer ncia de dados espaciais feita atrav s de m dulos, classi cados em: globais, provendo metadados, incluindo par metros necess rios para a inter preta o da transfer ncia por exemplo, t tulo, data, escala e proje o; qualidade de dados por exemplo, precis o de localiza o e consist ncia; atributos, em fun o do tipo do dado; objetos espaciais, seguindo o modelo conceitual; e representa es gr cas, com caracter sticas de apresenta o por exemplo, fonte e cor. Maiores informa es sobre o padr o podem ser encontradas em SDT .
4.3.4 O Padr o OGIS

O objetivo do ogis Car94 permitir que o usu rio tenha acesso a dados geogr cos local ou remotamente, sem estar limitado por modelos de dados propriet rios, formatos de arquivos ou sigs que gerenciam os dados, em uma dada localidade. O projeto do ogis utiliza tr s conceitos b sicos. Primeiro, todos os dados, processos e servidores s o objetos, baseados em uma tecnologia de objetos distribu dos tal como CORBA ou OLE Obj94, Bar92 que tratam da interoperabilidade, comunica o e ger ncia de objetos e servi os distribu dos. Segundo, um modelo de objetos geogr cos para informa es espaciais
64
proposto. Este modelo baseado no saif e compat vel com o sdts e o digest. Terceiro, o ogis permitir servi os a serem implementados fornecendo liga es entre o modelo de objetos e formatos de dados privados, de nindo uma interface de procedimentos padr o para cada elemento do modelo e provendo base ampla e consistente de fun es de Geoprocessamento. O arcabou o do ogis uma biblioteca de classes que podem instanciar objetos para modelar tanto dados como fun es da aplica o. Estes modelos s o o VGM
Virtual Geodata Model e APM
Applications Programming Model. O VGM segue o padr o iso sql3, que por sua vez baseado no saif, descrito na se o 4.3.2, estendendo-o com dados de cat logo semelhantes aos metadados de nidos pelo FGCD e fun es de Geoprocessamento, n o necessariamente encapsuladas por classes. Aplica es e servi os usam o VGM como um modelo de dados conceitual para acessar os dados geogr cos. Por exemplo, um gerente de acesso pode transformar um dado em formato arco-n privado em um objeto VGM , instanciando classes para geometrias, relacionamentos espaciais, conte dos tem ticos e metadados. O APM facilita a cria o e implementa o de aplica es e servi os. Aplica es s o de correntes de requisitos de um usu rio, de nidas por um engenheiro de aplica o. Servi os s o aplica es j pr -de nidas, que capacitam um servidor a interagir com outras aplica es clientes ou com outros servi os. Exemplos de aplica es e servi os s o os gerentes de acesso, servi os de transforma o, servi os de Geoprocessamento, aplica es ogis, aplica es j existentes e aplica es n o geogr cas. Aplica es em conformidade com ogis poder o usar dados acess veis em diversos sistemas de armazenamento com diferentes formatos, atrav s de servi os de gerentes de acesso.
Cap tulo 5 Opera es sobre Dados Geogr cos

5.1 Introdu o
A funcionalidade esperada de um sig quanto recupera o e manipula o de dados varia enormemente em fun o da rea de aplica o e do tipo de usu rio MGR93a . Por exemplo, na vis o de aplica es cartogr cas, o sig deve prover servi os de processamento e apresenta o de mapas; na vis o de aplica es cadastrais, o sig deve prover servi os pr ximos dos tradicionais de banco de dados; na rea de administra o de recursos naturais, o sig deve prover servi os so sticados de an lise espacial. A despeito destas disparidades, h v rias alternativas para categorizar as opera es de um sig de forma a facilitar a an lise das suas caracter sticas. Quanto ao resultado, h opera es de constru o, que criam novos objetos, opera es de atualiza o, que modi cam valores de atributos dos objetos aos quais s o aplicadas sem criar novos objetos, opera es escalares, que recebem como entrada um ou mais objetos e retornam um valor escalar e opera es booleanas, que recebem como entrada um ou mais objetos e retornam um valor booleano. Ortogonalmente, h opera es convencionais e espaciais, que dependem apenas da componente convencional ou tamb m da componente espacial dos objetos, respectivamente. As opera es booleanas espaciais tamb m s o chamadas de relacionamentos espaciais. Finalmente, as opera es podem ser agrupadas segundo as classes dos objetos envolvidos, sejam eles geo-campos geo-objetos ou ambos. Em lugar de apresentar uma lista exaustiva de opera es espaciais, este cap tulo discute como de nir certas categorias de opera es, enfatizando os aspectos pr prios de Geoprocessa mento em oposi o a Computa o Gr ca ou que s o peculiares ao modelo de dados apre sentado no cap tulo 4. Em particular, a se o 5.2.2 aborda em mais detalhe o problema de de nir relacionamentos topol gicos entre representa es vetoriais simples. Estas cole es de opera es s o a base para a de ni o de linguagens de consulta espacial de alto n vel, que permitem a manipula o de conjuntos de objetos a partir daquelas armazenadas no banco de dados geogr co. H v rios trabalhos sistematizando opera es em um sig Goo87, MD91, Bur92 , ou mesmo 65
66
CAP TULO 5. OPERA ES SOBRE DADOS GEOGR FICOS
enumerando as propriedades desej veis para uma lgebra de objetos geogr cos Gut94 . Po r m, em geral, estes trabalhos abordam o problema de duas perspectivas distintas: opera es de consulta sobre geo-objetos Ege94 , e opera es de manipula o sobre geo-campos Tom90 , sem uni car as duas vis es. Formaliza es dos relacionamentos espaciais entre representa es vetoriais podem ser encontradas ainda em CSE94, MEdF94 , refer ncias que tomaremos como base para a se o 5.2.
5.2 An lise das Opera es sobre Geo-Objetos

Esta se o analisa inicialmente o efeito que a introdu o de um n vel de representa o sepa rado provoca na de ni o de opera es sobre geo-objetos. Em seguida, discute em detalhe o problema de especi car relacionamentos topol gicos, uma quest o que recebeu ampla aten o na literatura de Geoprocessamento.
5.2.1 Papel das Representa es

No que tange a geo-objetos, a de ni o de opera es espaciais nada mais faz do que traduzir, a partir do n vel conceitual, opera es sobre representa es de localiza es a parte espacial de geo-objetos. As opera es sobre representa es variam enormemente de complexidade, j que a localiza o de um geo-objeto pode ser determinada por um simples ponto, em um extremo, ou como componente de uma representa o complexa, no outro extremo. Esta tradu o direta no caso da de ni o de opera es espaciais escalares e de relaciona mentos espaciais para geo-objetos, sendo necess rio apenas de nir uma forma de escolher entre representa o alternativas, realizar transforma es de escala e proje o cartogr ca sobre as representa es, se necess rio, e aplicar a opera o subjacente apropriada. Por exemplo, deter minar se um geo-objeto g1 est contido em outro g2 signi ca determinar se a representa o escolhida de g1 est contida na representa o escolhida de g2. A se o 5.2.2 analisa em detalhe a de ni o deste tipo de relacionamentos para representa es espaciais simples. J a de ni o de opera es de atualiza o ou constru o sobre geo-objetos suscita alguns problemas mais complexos, ilustrados pela an lise do seguinte exemplo. Considere uma classe Re, especializa o de RepElementar, e suponha que exista uma opera o : Re 7! Re. Seja G uma classe de geo-objetos e assuma que as localiza es dos geo-objetos em G tenham uma nica representa o em Re. As instancias da classe Representa induzem uma fun o repr : G 7! Re tal que reprg = r sse r; g um par em Representa. Podemos imediatamente introduzir, para G, uma opera o espacial de atualiza o tal que, aplicada a g 2 G, substitui a representa o da localiza o de g por reprg. Ou seja, altera o conjunto de inst ncias associado naquele momento a Representa, substituindo o par reprg; g por reprg; g. Uma opera o de constru o para G pode ser de nida de forma inteiramente semelhante. instrutivo analisar a de ni o de em detalhe. Em primeiro lugar, o usu rio deve estar consciente de que a de ni o de implicitamente escolhe Re como a fonte de representa es
5.2. AN LISE DAS OPERA ES SOBRE GEO-OBJETOS
67
para G, embora nada impe a que as inst ncias de G possuam representa es em outras classes. Em segundo lugar, ao aplicar a g, a suposi o de que as localiza es dos geo-objetos em G possuem uma nica representa o em Re desobriga o usu rio de escolher representa es espec cas de g. Se esta suposi o fosse eliminada, o usu rio seria obrigado a informar sobre quais representa es de g a opera o deveria ser aplicada, ou seja, a opera o passaria a ter dois novos par metros. Note que esta observa o de fato se aplica a quaisquer opera es sobre geo-objetos. Em terceiro lugar, como Re cont m representa es simples e fechada em , poss vel de nir a atualiza o de Representa de forma imediata. No caso mais geral, a de ni o de uma opera o de constru o ou de atualiza o para geo-objetos poder exigir a manipula o expl cita de representa es e de inst ncias do relacionamento Representa. Por exemplo, suponha uma representa o r de nida como um conjunto de pontos, linhas e regi es, e considere um geo-objeto g cuja localiza o representada por um subconjunto s destes elementos, situa o formalizada por uma inst ncia i de Representa relacionando r e g e tendo s como valor de um atributo espec co A. Relembrando, i age como um hyperlink entre r e g, onde o subconjunto s de r faz o papel da ncora em r. Neste caso, uma opera o de atualiza o da localiza o de g poder escolher um outro subconjunto de r para representar a localiza o de g, sem alterar r propriamente dito, mas alterando o valor do atributo A de i, ou modi car algum elemento em s, alterando portanto a pr pria representa o r. Em resumo, a de ni o de opera es de atualiza o ou constru o sobre geo-objetos en volve n o apenas opera es de atualiza o ou constru o sobre representa es, mas tamb m opera es sobre o relacionamento Representa. Por outro lado, a de ni o de opera es es paciais escalares e de relacionamentos espaciais para geo-objetos depende apenas de opera es subjacentes sobre representa es e de uma forma de escolher entre representa es alternativas.
5.2.2 Relacionamentos Topol gicos

Esta se o faz uma breve an lise da quest o de relacionamentos espaciais em geral, envolvendo representa es de geo-objetos, analisando a seguir, em detalhe, como de nir relacionamentos topol gicos entre pontos linhas e regi es simples, assunto fundamental para a de ni o de linguagens de consulta espacial. Ela segue as refer ncias EF91, CdFvO93, Cam95 e sua leitura opcional. Existem v rios tipos de relacionamentos espaciais de nidos sobre geo-objetos, dentre os quais encontramos os relacionamentos direcionais e os topol gicos. Os relacionamentos direcio nais, como
acima de e
perto de, retornam um valor booleano e descrevem como os geo-objetos est o posicionados uns em rela o aos outros. A de ni o de um relacionamento direcional em geral envolve um marco de refer ncia, um objeto de refer ncia e o objeto em quest o. O marco de refer ncia determina a dire o na qual o objeto em quest o est localizado em rela o ao objeto de refer ncia. Estudos sobre senten as espaciais em linguagem natural revelam que os re lacionamentos direcionais dependem de aspectos cognitivos, que variam culturalmente FM91 .
68
Os relacionamentos topol gicos, como

dentro de e
adjacente a, retornam um valor boo leano e s o invariantes face a transforma es biun vocas e bicont nuas, como transforma es de escala, transla o e rota o. A de ni o de um conjunto m nimo de relacionamentos topo l gicos objeto de muito debate na literatura. Freeman Fre75 de ne um conjunto de treze relacionamentos:
esquerda de,
direita de,
acima mais alto que, sobre,
abaixo sob,
atr s,
pr ximo a,
longe de,
ao lado de adjacente a,
tocando,
dentro de,
fora de,
entre. Feutchwangler Feu93 lista seis:
adjac ncia,
proximidade,
subdivis o,
sobreposi o,
vizinho mais pr ximo e
sub-regi o. Egenhofer e Herring EH90 prop em:
disjunto,
encontram,
igual,
dentro de,
cont m,
cobre,
coberto por e
sobreposi o. Finalmen te, Clementini et al. CdFvO93 indicam cinco relacionamentos:
dentro de,
superposto a,
tocando,
cruzando e
disjunto. A quest o da de ni o de relacionamentos topol gicos discutida em detalhe no resto desta se o. No que se segue, o espa o topol gico considerado ser o 2 e as de ni es ser o todas breves e informais. Os elementos top logicos simples s o de tr s tipos: um ponto; uma linha simples, que n o se intercepta a si mesma e que ou circular ou possui apenas dois pontos terminais; uma regi o simples, que conectada, ou seja, que n o a uni o de conjuntos disjuntos de pontos, e que n o cont m buracos. A dimens o de um conjunto de elementos topol gicos simples dada por:
dim = $ dim = 0 $
cont m pelo menos um ponto e nenhuma linha ou regi o simples dim = 1 $ cont m pelo menos uma linha e nenhuma regi o simples dim = 2 $ cont m pelo menos uma regi o simples
=;
A fronteira de um elemento topol gico simples !, denotada por !, de nida da seguinte forma:
! = ; $ ! um ponto ou ! uma linha circular ! = fP; Qg $ ! uma linha n o circular e P e Q s o seus pontos terminais ! = L $ ! uma regi o simples e L a linha circular formada por todos os pontos de acumula o de !.
O interior de um elemento topol gico !, denotado por !0, de nido como
!0 = ! , !.
Para caracterizar os relacionamentos entre duas regi es simples, A e B , Egenhofer e Herring EH90 introduziram o m todo da matriz de 4 interse es, que analisa se o conjunto de nido em cada entrada da matriz vazio ou n o uma entrada n o vazia indicada por :;:
69
Para o exemplo da gura 5.1, em que duas regi es, A e B , se tocam apenas nas fronteiras A e B , a matriz ser :

' $ &
A
A A0
B A B 0 = :; ; B A0 B 0 ; ;
Figura 5.1: Exemplo da matriz de 4 interse es. Como o m todo s considera se uma entrada vazia ou n o e como h quatro entradas na matriz, existem dezesseis 24 poss veis combina es, apresentadas na tabela 5.1, das quais oito s o v lidas e duas s o sim tricas, resultando em seis relacionamentos v lidos entre regi es: dis joint, in, touch, equal, cover e overlap. Note que as combina es exclu das violam propriedades das regi es simples. Por exemplo, a combina o na segunda linha da tabela exclu da pois, se os interiores de A e B se interceptam, a fronteira de A deveria interceptar o interior de B , ou vice-versa. O m todo da matriz de 4 interse es n o diferencia entre algumas situa es n o equivalentes, como as da gura 5.2, que possuem a mesma matriz apesar de representar relacionamentos distintos
inclus o e
cruzamento:

' &
A
L L0
A L A0 = ; :; A L0 A0 :; :;
A
$ ' $ &
L
Figura 5.2: Topologias linha-regi o simples com a mesma matriz de 4 interse es. Para equacionar problemas como este h v rias abordagens na literatura, das quais discuti remos duas, o m todo estendido da matriz de 4 interse es e o c lculo de relacionamentos. O m todo estendido da matriz de 4 interse es, discutido em CSE94, Cam95 , considera a dimens o de cada entrada da matriz de 4 interse es, em lugar de apenas avaliar se ela vazia
70

A
A overlap B Tabela 5.1: Relacionamentos topol gicos poss veis entre regi es simples
ou n o. Por exemplo, nas situa es ilustradas na gura 5.2, temos dim L A = 1, no caso de
inclus o, e dim L A = 0, no caso de
cruzamento, embora em ambos os casos L A 6= ;. Como a dimens o de cada entrada admite agora quatro poss veis valores correspondentes aos quatro poss veis valores da dimens o e como h quatro entradas na matriz, temos um total de 256 44 combina es, das quais somente 52 s o aplic veis CdFvO93 . Novamente, as combina es n o aplic veis s o aquelas que apresentam inconsist ncias, de forma semelhante quela da segunda linha da tabela 5.1. No entanto, mesmo com esta redu o dr stica, o n mero de combina es aplic veis ainda elevado demais e, portanto, n o pr tico criar um nome para o relacionamento de nido por cada uma delas e torn -lo dispon vel aos usu rios de um sig atrav s de uma linguagem de consulta espacial de alto n vel. Por outro lado, este m todo tem o m rito de ser exaustivo e, portanto, de servir de balizador para outros m todos de an lise. O c lculo de relacionamentos CdFvO93 de ne cinco relacionamentos entre elementos to pol gicos simples - disjoint, in, touch, cover e overlap - e tr s fun es - boundary, from e to - e permite a composi o de express es booleanas complexas a partir deles. Por exemplo, se L e A s o uma linha e uma regi o simples, respectivamente, a seguinte express o v lida:
; ; ; ; ; ; ; ; :; :; :; :; :; :; :; :;
A B 0 A0
; ; ; ; :; :; :; :; ; ; ; ; :; :; :; :;
; :; :; ; ; :; :; ; ; :; :; ; ; :; :;
B A0 B 0 nome do relacionamento ; ; A disjoint B
:; ; :; ; :; ; :; ; :; ; :; ; :; ; :;
A in B A in B A touch B A equal B A cover B A cover B
L disjoint boundaryA _ L touch boundaryA

A linguagem de consulta espacial conter ent o estes relacionamentos e fun es e dever permitir a composi o de express es booleanas. CdFvO93 prova que o c lculo de relaciona mentos su ciente para exprimir todas as combina es admitidas como aplic veis pelo m todo
71
estendido da matriz de 4 interse es. Os relacionamentos e fun es admitidos no c lculo de relacionamentos s o de nidos no resto desta se o e ilustrados na gura 5.3. No que se segue, !1 e !2 denotam dois elementos topol gicos simples dos tipos indicados em cada caso. O relacionamento disjoint, aplic vel a dois elementos de quaisquer tipos, tal que:
!1 disjoint !2 $ !1 !2 = ;
O relacionamento touch, aplic vel a dois elementos dos tipos regi o e regi o, linha e regi o, linha e linha, ponto e regi o, ponto e linha, tal que
!1 touch !2 $ !1 !2 6= ; ^ !10 !20 = ;

O relacionamento overlap, aplic vel a dois elementos do mesmo tipo, tal que
!1 overlap !2 $ !1 !2 6= !1 ^ !1 !2 6= !2 ^ dim!10 !20 = dim!10 = dim!20

O relacionamento in, aplic vel a dois elementos dos tipos regi o e regi o, linha e regi o, ponto e regi o, ponto e linha, tal que
!1 in !2 $ !10 !20 6= ; ^ !1 !2 = !1

O relacionamento cross, aplic vel a dois elementos dos tipos linha e regi o, linha e linha, tal que
!1 cross !2 $ !1 !2 6= !1 ^ !1 !2 6= !2 ^ dim!10 !2 0 = maxdim!10; dim!20 , 1

A fun o boundary, aplic vel a um elemento topol gico simples A do tipo rea, retorna a linha circular que comp e a fronteira de A. As fun es from e to s o aplic veis a um elemento topol gico simples L do tipo linha n o circular e retornam os seus pontos terminais. Por de ni o, fromL retorna o ponto terminal de L com a menor coordenada em X ou, caso os dois pontos terminais tenham a mesma coordenadas em X , o ponto terminal de L com a menor coordenada em Y , e toL retorna o outro ponto como L n o circular, estas fun es est o bem de nidas. Note que necess rio de nir arti cialmente duas fun es para tratar os pontos terminais separadamente, em lugar
72
de estender a fun o boundary para linhas, pois os relacionamentos topol gicos admitem como argumento um ponto, mas n o um conjunto com dois pontos. Por exemplo, as situa es da gura 5.2 s o descritas pelas express es
L in A ^ L overlap boundaryA L cross A ^ fromL in A

Em geral, o c lculo de relacionamentos permite de nir com precis o relacionamentos topo l gicos complexos, sem introduzir um elenco muito extenso de conceitos, e portanto oferece um bom ponto de partida para a de ni o de linguagens de consulta espacial de alto n vel. No entanto, ele precisa ser estendido para cobrir outros elementos topol gicos mais complexos, como regi es com buracos, conforme apontado em CdFvO93 .
73
' $ &
A B A B A B B A A @ @@ B @@ @@
@ @@B A @@ @
A disjoint B A A touch B B

B
r
A
@@ @@ B @
, B ,, , A , ,A
A overlap B B
A A , B @ , @ ,B B @
@@ @@ A @@ @@ A @@ @@
B
A in B B
A cross B
Figura 5.3: Exemplos de relacionamentos topol gicos .
74
5.3 An lise das Opera es sobre Geo-Campos

Esta se o discute brevemente como de nir opera es sobre geo-campos, explorando o fato de que geo-campos s o fun es, uma caracter stica enfatizada na descri o do modelo de dados. Esta abordagem mais abstrata apresenta vantagens quando comparada, por exemplo, com o enfoque das linguagens MAP Map Analysis Package, proposta por Dana Tomlin Tom90 , e GRID, dispon vel no sistema ARC INFO. Resumidamente, MAP apresenta um conjunto de opera es sobre representa es matriciais de geo-campos tem ticos e num ricos. GRID uma implementa o de MAP que, embora muito ex vel, tem o s rio inconveniente de ser fracamente tipada. Em GRID, um geo-campo tem tico com representa o matricial chamado de
grade de inteiros, e um geo-campo num rico com representa o matricial, de
grade de pontos utuantes, o que estabelece uma confus o entre o geo-campo e sua representa o. A discuss o concentra-se em apenas duas categorias de opera es, chamadas de pontuais e de vizinhan a.
5.3.1 Opera es Pontuais

Uma opera o pontual quando o resultado um geo-campo cujo valor em cada ponto p depende apenas dos valores em p dos geo-campos de entrada. Uma opera o pontual especi cada por um mapeamento entre os contradom nios dos geo-campos de entrada e o contradom nio do geo-campo de sa da. Mais precisamente, seja R uma regi o e V1 ; :::; Vn+1 conjuntos quaisquer. Seja : V1 ::: Vn 7! Vn+1 . Para i = 1; :::; n + 1, seja Ci a classe de todos os geo-campos que possuem R como localiza o e Vi como contradom nio. Denote o mapeamento de ci 2 Ci por fc . A fun o induz ent o uma opera o pontual : C1 ::: Cn 7! Cn+1 tal que, para todo ci 2 Ci, i 2 1; n , c1; :::; cn = cn+1 sse cn+1 o geo-campo em Cn+1 com mapeamento fc +1 : R 7! Vn+1 tal que, para todo ponto p 2 R, fc +1 p = fc1 p; :::; fc p. Guiando-se pelas classes de geo-campos introduzidas pelo nosso modelo, exemplos de ope ra es pontuais un rias s o: as opera es de pondera o, mapeando um geo-campo tem tico em um num rico; as de reclassi ca o, mapeando um geo-campo tem tico em um tem tico; e as de fatiamento e fatiamento em classes, mapeando um geo-campo num rico em um tem ti co. A gura 5.4 ilustra a convers o de um geo-campo tem tico de solos, com contradom nio V1 = fLe; Li; Ls; Aqg, em um geo-campo tem tico ponderado de solos, com contradom nio V2 = 0:0; 1:0 , atrav s de uma opera o de pondera o de nida pelo mapeamento fLe; 0:60; Li; 0:20; Ls; 0:35; Aq; 0:10g. Como um exemplo mais complexo, tome-se a opera o especi cada pelo conjunto hipot tico de regras expresso na tabela 5.2 que mapeia um geo-campo tem tico de solo, com contradom nio xo V1 = fLe; Li; Ls; Aqg, um geo-campo num rico de precipita o, com contradom nio V2 = 0; 10000 , e um geo-campo num rico de declividade, com contradom nio V3 = 0; 100 , em um
i n n n
5.3. AN LISE DAS OPERA ES SOBRE GEO-CAMPOS

geo-campo tem tico de aptid o agr cola, com contradom nio xo V4 = fLe; Li; Ls; Aqg.
Aptid o boa m dia inadequada Tipo de Solo Precipita o M dia Declividade latossolo roxo ou litossolo 100mm 0-5 cambissolo 100-50mm 5-10 aquoso 50mm 10
75
Tabela 5.2: Regras para determina o de aptid o agr cola.
Le Li Ls Aq
0.35 0.35 0.20 0.35 0.20 0.20
0.35 0.35 0.10
Figura 5.4: Exemplo de opera o de pondera o.
76
5.3.2 Opera es de Vizinhan a

Uma opera o de vizinhan a quando o resultado um geo-campo cujo valor em cada ponto p depende dos valores dos geo-campos de entrada em uma vizinhan a de p. Exemplos incluem: c lculo do valor m nimo, m ximo, m dio e modal na vizinhan a em torno de cada ponto; ltros para processamento de dados de sensor remoto; interpola o espacial para geo-campos num ricos como m dias por vizinho mais pr ximo; c lculo de declividade e exposi o para geo-campos num ricos; ndices de diversidade para geo-campos tem ticos, onde o valor de sa da est associado ao n mero de vizinhos, pertencentes a classes distintas, de um ponto de entrada. As opera es de classi ca o, que mapeiam um dado de sensor remoto em um geo-campo tem tico, tamb m podem ser consideradas opera es de vizinhan a, pois o problema neste caso justamente determinar regi es homog neas em torno dos pontos. Como ilustra o de uma opera o de vizinhan a, tomemos o caso de um ndice de biodi versidade, estimado de tal forma que seja maior em reas de contato ecol gico entre regi es homog neas. A gura 5.5 apresenta um geo-campo tem tico de vegeta o e mostra o ndice de diversidade computado para uma parte do geo-campo. Um caso especial de opera es de vizinhan a s o as opera es zonais em que as vizinhan as s o induzidas por um geo-campo tem tico. Seja um geo-campo tem tico sobre uma regi o R. Intuitivamente, a fun o de vizinhan a L tal que, para todo p 2 R, L p = V sse V o maior subconjunto de R tal que o valor do geo-campo em todos os pontos de V o mesmo que em p e V um subconjunto conectado, ou seja, V n o a uni o de subconjuntos disjuntos de R. A gura 5.6 exempli ca uma opera o de m ximo zonal de nida sobre um geo-campo num rico, onde um geo-campo tem tico utilizado para induzir as vizinhan as, e retornando o maior valor do geo-campo num rico para cada vizinhan a.
Flor. Vrzea Floresta Densa

Rebrota
1 1 1
2 3 2
1 2 1
Cerrado
Figura 5.5: Exemplo de c lculo de ndice de diversidade.
5.3. AN LISE DAS OPERA ES SOBRE GEO-CAMPOS
77
Le Li Ls Aq
5.0
7.0
7.5 15.0
10.0 12.0
15.0 15.0
20.0
Mapa de solos (restrio) 7.5 15.0 7.5
Declividade (dado de entrada) 7.5 15.0 Mximo Zonal
15.0
15.0
20.0
20.0
Figura 5.6: Exemplo de c lculo de m ximo zonal.
78
5.4 Opera es Mistas entre Geo-Campos e Geo-Objetos

Esta ltima se o introduz exemplos de opera es mistas, envolvendo ao mesmo tempo geo-campos e geo-objetos. Uma opera o de intersec o espacial overlay recebe como entrada geo-campos e produz como sa da uma cole o de geo-objetos, tendo tipicamente como atributos convencionais os valores dos geo-campos de entrada. Esta situa o comum em aplica es de zoneamento, onde se aplica a interse o entre geo-campos tem ticos para se obter regi es homog neas, que s o ent o identi cadas como geo-objetos. A gura 5.7 ilustra a opera o
Determine as regi es homog neas da Austr lia, como interse o espacial dos geo-campos de vegeta o, geomorfologia e solos. Na literatura, este tipo de interse o espacial muitas vezes classi cado erroneamente como um tipo particular de jun o espacial cf. Gut94 . Como veremos na se o 10.3.1, a opera o de jun o espacial parte de dois conjuntos de geo-objetos e produz, como resultado, pares de geo-objetos j existentes que satisfazem restri o desejada. J o tipo de interse o espacial aqui discutido cria novos geo-objetos a partir de geo-campos. Deste modo, embora haja seme lhan as entre os algoritmos utilizados para implement -las, a opera o de interse o espacial conceitualmente diferente das opera es booleanas entre geo-campos e opera es de jun o espacial entre conjuntos de geo-objetos. Nas de ni es que se seguem, adotamos as seguintes conven es: R denota uma geo-regi o; O denota um geo-objeto cuja localiza o um ponto, linha ou regi o contido em R; denota um conjunto de geo-objetos de uma mesma classe C tal que a uni o das localiza es dos objetos em cobre completamente R e as localiza es s o mutuamente disjuntas; A denota um atributo da classe C ; denota uma fun o que mapeia os valores do atributo A em um outro conjunto de valores. A opera o de reclassi ca o por , quando aplicada a , gera um geo-campo tal que, para cada ponto p 2 R, p = v sse v o valor do atributo A do nico geo-objeto em cuja localiza o espacial cobre p. O exemplo da gura 5.8 ilustra a cria o de um geo-campo tem tico com o crescimento demogr co da Am rica do Sul, gerado a partir dos valores do atributo demografia dos geo-objetos que representam os pa ses da Am rica do Sul, reclassi cando os valores em tr s faixas: de 0 a 2 a.a, de 2 a 3 a.a. e mais de 3 a.a.. A reclassi ca o por atributos tamb m chamada de fus o Gut94 . A opera o de gera o de mapas de dist ncias, quando aplicada a O e R, produz um geo-campo num rico indicando as dist ncias de cada ponto em R a O. Por m, uma opera o zonal induzida por de nida exatamente como na se o 5.3.2, exceto que utiliza a fun o de vizinhan a L tal que, para todo p 2 R, L p o conjunto de pontos que pertencem localiza o do nico geo-objeto em cuja localiza o espacial cobre p. Um exemplo informal de uma opera o zonal deste tipo seria:
Dado um geo-campo num rico com a altimetria e um mapa de geo-objetos com os munic pios do Vale do Para ba, crie um novo geo-campo num rico onde cada munic pio ser representado por sua altitude m dia.
5.4. OPERA ES MISTAS ENTRE GEO-CAMPOS E GEO-OBJETOS
79
GM2 GM1 GM3 geomorfologia vegetao solos VG2 VG1 VG3 TS1
TS2
AAAAAAA AAA AAAA AAAA AAA AAAA AAAAAAA AAA
TS3
AAAA AAAA AAA AAAA AAAA AAAA AAA AAAA AAAA AAA AAAA AAAA AAAA AAA AAAA AAAA AAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAA AAA AAAAAAAA AAAAAAAA AAAAAAA AAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA R-II R-III AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA R-I AAA AAAA AAAAAAAA AAAAAAA AAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAA AAAA AAA AAAA AAAA AA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAA AAAA R-IV AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAA AA AAAA AAAAAAAA AAAA R-V AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAAAAAA AAAAAA AA AAAA AAAA AA AAAA AAAA AA AAAA AAAA AAAAAAAA AAAAAAAA AAAA AA AAAAAA AAAAAAAA AA AAAA R-VI
idreg 1203000 1203001
nome geom. veg R-III R-IV GM2 GM3 VG3 VG1
solo TS2 TS1
Figura 5.7: Exemplo de c lculo de interse o espacial.
A AA AAAAA A AAAAAAAAA AAAAAAAA AAAAA AAAA AA A AAA AAAA AAA AAAAAAAAAAA AAA AAAAAAAAAA AAAAAAAAA AAAA A AAAAAA AAA AAAA AAAA AAA Crescimento demogrfico AAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAA AAA AA AAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAA AA AAAA AAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA A AAAAAAAAAAAAAAA AAA AA AAAA AAAA AAAA AAAA AA A AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAA A AAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AA AAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAA AA AAAAAA de 0 a 2% a.a AAA AAAA AAAA AAAA AAAA AAA AAA AA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA AAAA A AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAA AA A AA AA A AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAA A AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA A AAA AAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAA AAAA AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAA AAAA AAAA AAAA AAAA AAAA A AAAA AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA A AAAAAA de 2 a 3% a.a AAAA AAAA AAAA AAAA AAA AAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAA AA A AAAA AAAA AAAA AAAA AAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAA A AAAA AAAAAAAAAAA AAAA AAAA AAAAAA AA AAAA A AAAA AAAA AAA AAAA AA AAAAAAAAAAAAAAAA AAAAA A AAAAA AAAAAAAAAA AAAA AAA AA AAAA AAAA AAAA AA AAAA AA AA AAAA AAAAA AAAA AA A A AAAA AAAAAAAAAA AAAAAAAAA AAAAAAAA AAAA AA AAAA AA AAAA AAAA AAAA AA AAAAAAA AAAAAA AAAAA AA AA AAAAAA AAAAAAA AAAAAAAA AAAAA AAAA AA AAAA AAAA AAAA A AAAAAAAAA AAAAAAA AAAA AAAAA AAAA A AAAA AAAA AA AAA AAAA AAAAAAAA AAAAAAAAA AAAA AA AAA AAAAAA mais de 3% a.a AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAA AAAAAAAA AAAA AAAAA AAAA AA AAAA AAAA AAAA AAAA AAAAAAAAAA AAAAAAAAA AAAAAAAA AAAAAAA AAAA A AAAAAA AAAA AAAA AA A AAAAAAAAAA A AAAA AAAA AA AAAAAAAA AAAAAAAAA AAAAAAAAAA AA AAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAA AAAAAAAA AAAA AAA AAAAA AAAAAAA AAA AAAA A AAAAA AAAAA AAAA AAAA AA AAAA AAAA AAAA AAAAA AAAA A AA AAAA AA AAAAA AAAA AAAA A AAAA A AAAA AAA AAAA AAAA AAA AAA AA AAA
Figura 5.8: Exemplo de reclassi ca o por atributo.
80
Cap tulo 6 Recupera o de Dados Geogr cos

6.1 Introdu o
Este cap tulo aborda o problema de de nir linguagens de consulta para bancos de dados geo gr cos. Inicialmente, a se o 6.2 analisa diversas alternativas e resume algumas refer ncias importantes sobre o assunto. Baseando-se no modelo de dados e nas opera es de nidas nos cap tulos 4 e 5, a se o 6.3 descreve uma linguagem de consulta e manipula o espacial, deno minada legal - Linguagem Espacial para Geoprocessamento Alg brico Cam95 . A discuss o sobre recupera o e manipula o de objetos geogr cos, especialmente lingua gens de consulta, abrange in meras refer ncias, dentre as quais ressaltamos Ooi90, RFS88, VvO92 . Este cap tulo baseia-se principalmente nos trabalhos dos autores CHF93a, HFC93, CFC94, Cam95 e de Egenhofer e Frank EF88, Ege89, Ege92, Ege94 .
6.2 Vis o Geral de Linguagens de Consulta

Esta se o apresenta uma vis o geral de linguagens de consultas para bancos de dados geogr cos, classi cando-as em: textuais, usualmente extens es de sql que acomodam relacionamentos espaciais; visuais, privilegiando a manipula o direta de elementos visualizados; e multimodais, permitindo uma combina o de linguagem textual e intera o via mouse com a tela. Os mo dos de intera o podem ser interativo navegacional, quando o usu rio explora as possibilidades existentes, navegando de uma consulta a outra, ou baseado em consulta resultado, quando o usu rio solicita uma resposta a uma consulta espec ca.
6.2.1 Linguagens Textuais

A maior parte das linguagem de consulta textuais para bancos de dados geogr cos baseia-se em extens es da linguagem sql. Paradoxalmente, a principal vantagem e fraqueza deste en foque origina-se no fato de sql ser baseada no modelo relacional. Se, por um lado, este fato 81
82
CAP TULO 6. RECUPERA O DE DADOS GEOGR FICOS
facilita a otimiza o de consultas, por outro lado, a abordagem relacional n o completamente apropriada para a modelagem de dados em aplica es de Geoprocessamento. As principais conclus es do esfor o em torno de sql s o FM91 : a inclus o de operadores espaciais em sql n o apresenta maiores problemas, desde que a sem ntica destes operadores seja de nida apropriadamente; a inclus o do controle de apresenta o e apontamento em sql poss vel, mas aconselha-se projetar uma linguagem separada para lidar com estas quest es, em lugar de acomod -las em cl usulas adicionais na estrutura
select-from-where t pica de sql. Exemplos desse enfoque s o Gut88, Ege89, Goh89, Ooi90, Wan94 . Em mais detalhe, a linguagem gql de Goh89 combina facilidades de sql com parametros gr cos de gks, sendo limitada manipula o de dados em formato vetorial. A linguagem geoql de Ooi90 estende o sql com nove operadores espaciais intersects, adjacent, joins, ends-at, contains, situated-at, within, closest e furthest, o que restringe o tipo de consulta que pode ser realizada. Ege94 prop e uma extens o a sql que, al m da parte espacial, prov sintaxe para de ni o da apresenta o do resultado da consulta. Wan94 , por sua vez, estende sql com operadores espaciais que embutem no es nebulosas perto, longe, quente, frio, previamente compiladas pelo usu rio em predicados num ricos. As propostas de Gut88, SH91 est o dentre as poucas que n o usam extens o de sql, sendo ambas de dif cil manipula o por um usu rio nal. A primeira prev , al m dos operadores e predicados relacionais, predicados geom tricos, transformadores geom tricos e operadores que retornam objetos geom tricos ou escalares para opera es m tricas. Os tipos geom tricos ma nipulados correspondem a dados em formato vetorial. A linguagem de SH91 est centrada em combinar opera es de an lise estat stica reclassi ca o, vizinhan a e outras com opera es espaciais relacionamentos geom tricos e topol gicos.
6.2.2 Linguagens Visuais

Linguagens visuais permitem a constru o de uma consulta atrav s da combina o de s mbolos, cones e texto visando facilitar o trabalho do usu rio. Esta abordagem, por m, di culta a formula o de uma sem ntica precisa para as consultas BM92 . Exemplos desse tipo de enfoque s o DC91, VMS+93 . A refer ncia DC91 apresenta duas linguagens gr cas: uma para manipula o de aplica es de redes, denominada grog, e outra para aplica es tem ticas, denominada cigales, visando permitir a combina o de aspectos de campos e objetos. grog permite a especi ca o de consultas que manipulam arestas e n s em grafos. Neste caso, a consulta formulada por um grafo orientado, onde os n s correspondem a entidades e as arestas a operadores e relacio namentos. J cigales manipula linhas e regi es. As consultas s o tamb m grafos, com outra sem ntica. O principal problema resultante da combina o dos dois enfoques reside exatamente no fato de que os grafos n o s o compar veis e no fato de que sua combina o exige interven o do usu rio para disambiguar consultas.
6.2. VIS O GERAL DE LINGUAGENS DE CONSULTA
83
A linguagem introduzida por VMS+93 permite ao usu rio combinar predicados textuais, criados a partir de tabelas de forma similar a qbe, a predicados visuais, combinando s mbolos e cones dispon veis em um menu do sistema. O maior problema , de novo, determinar a sem ntica da consulta.
6.2.3 Ambientes Multimodais

Ambientes multimodais combinam manipula o direta a consultas visuais e textuais, de forma a tirar proveito dos aspectos positivos de cada uma. O principal obst culo est em conseguir coordenar conceitos distintos de intera o, al m da sem ntica pouco clara da linguagem visual. Exemplos deste tipo de ambiente s o descritos em EF88, AKK94 . O trabalho de EF88 baseado em uma interface interativa, oferecendo um layout de tela com v rias reas, cada uma das quais dedicada a um tipo de fun o consultas textuais, painel de opera es, representa o gr ca e outras. Consultas s o expressas combinando palavras-chave, express es em um dialeto de sql estendido e opera es de nidas no painel atrav s de cones. J a linguagem de AKK94 baseada no conceito de mapas din micos, que combinam a no o de vis es em bancos de dados com t cnicas de visualiza o. Mapas din micos s o resultados de consultas textuais que podem posteriormente ser manipulados diretamente pelo usu rio. A intera o, neste caso, alterna consultas textuais que retornam mapas e manipula o direta desses mapas, em geral usando sobreposi o. Cada mapa din mico de nido por um par vis o, visualiza o onde a vis o o resultado da consulta e a visualiza o associa uma apresenta o ao resultado da consulta.
6.2.4 Linguagens de Consulta sobre Imagens

Idealmente, deveria ser poss vel realizar consultas sobre imagens, aproveitando as t cnicas que v m sendo desenvolvidas nos ltimos anos na rea de bancos de dados de imagens, que visam permitir relacionar imagens a caracter sticas de conte do, formas e textura. Neste contexto, os sistemas tipicamente pr -processam cada imagem para extrair tais caracter sticas, que s o ent o armazenadas junto com a pr pria imagem, a m de acelerar o processamento das consultas. Os enfoques de recupera o de imagens baseada em conte do t m se concentrado em duas dire es GR95 . Na primeira, algumas caracter sticas principais da imagem s o extra das manualmente e armazenadas textualmente em um banco de dados por exemplo, dados sobre uma regi o e fen menos retratados na imagem, sendo a recupera o processada a partir de consultas sobre tais dados textuais. O segundo enfoque baseado em t cnicas de processamento de imagem, que realizam extra o de caracter sticas e determina o de objetos de interesse. O primeiro enfoque mais r pido, pois pode aproveitar t cnicas de otimiza o de consultas em bancos de dados tradicionais, mas limita o tipo de consulta a ser feito. O segundo mais ex vel, mas computacionalmente caro. Um sistema de consultas a imagens deveria, idealmente, combinar os dois tipos de tratamento.
84
6.3 A Linguagem LEGAL

Esta se o descreve uma linguagem de consulta e manipula o espacial, denominada legal Linguagem Espacial para Geoprocessamento Alg brico Cam95 . legal prov um ambiente geral para an lise geogr ca, estendendo sql com operadores es paciais e facilidades para apresenta o de geo-campos e geo-objetos. A linguagem fortemente tipada, ou seja, cada objeto pertence a uma das classes introduzidas pelo modelo ou pelo esque ma conceitual do banco de dados geogr co em quest o. legal oferece ainda constru es es pec cas para a manipula o dos resultados de uma consulta dentro de um programa, baseadas no modelo de nido pelo ODMG
Object Data Management Group Cat94, Cam95 . A lingua gem permite ainda a aplica o individualizada das opera es sobre geo-campos e geo-objetos de nidas no cap tulo 5.
6.3.1 De ni o de Esquemas Conceituais

Em legal o projetista usa o comando CREATE para especi car o esquema conceitual de um banco de dados geogr co de nindo especializa es das classes b sicas do modelo descrito no cap tulo 4. Para cada nova classe, o projetista poder criar novos atributos, rede nir os dom nios dos atributos introduzidos pelo modelo e de nir os valores dos atributos de classe. Por exemplo, o seguinte comando de ne a estrutura da classe Uso-do-Solo como uma especializa o da classe Tematico:
CREATE Uso-do-Solo nome CHAR20, ano INTEGER IS-A Tematico temas= "Floresta Primaria", "Cerrado", "Floresta Secundaria"
Intuitivamente, cada inst ncia da classe Uso-do-Solo ser um geo-campo tem tico com dois atributos convencionais pr prios: nome, uma cadeia de 20 caracteres e ano, um inteiro. J temas um atributo de classe para Tematico que, neste caso, ter como valor o conjunto
Floresta Primaria,
Cerrado,
Floresta Secundaria, que corresponde ao contrado m nio do mapeamento de cada geo-campo em Uso-do-Solo. De forma semelhante, o projetista pode de nir uma classe de geo-objetos chamada Hospital, com tr s atributos pr prios, atrav s do comando:
CREATE Hospital nome num-leitos CHAR30, INTEGER,
6.3. A LINGUAGEM LEGAL

receita-SUS FLOAT IS-A GeoObjeto
85
Note que o tipo do atributo de localiza o de superclasses correspondentes.
Hospital
Uso-do-Solo
herdado das
6.3.2 Cria o de Geo-Objetos e Geo-Campos

Atrav s do comando INSERT, o usu rio cria novos objetos no banco de dados, sejam eles geo-campos, geo-objetos ou representa es destes objetos. Por exemplo, uma inst ncia de Hospital pode ser criada atrav s do comando INSERT:
INSERT nome = "Hospital Municipal SJC", num-leitos = 300, receita-SUS = 50.000,00 IN Hospital
e uma inst ncia de Uso-do-Solo atrav s de:

INSERT nome = "acao antropica 1990", ano = 1990 IN Uso-do-Solo
O comando INSERT oferece ainda a possibilidade de criar ao mesmo tempo um geo-campo e a sua representa o. Por exemplo, o seguinte comando cria uma inst ncia de Uso-do-Solo representada por uma matriz:
INSERT nome = "acao antropica 1990", ano = "1990" IN Uso-do-Solo REPRESENTED BY nome = "Acao Antropica 90 - Rio-Novo", resolucao-X = 100, resolucao-Y = 100, escala = 1:250.000 IN Matricial
O novo geo-campo ser uma inst ncia da classe Uso-do-Solo, com nome
acao antropica 1990 e ano igual a
1990. Este geo-campo ter uma representa o matricial, onde os valores dos atributos pr -de nidos s o um nome
Acao Antropica 90 - Rio-Novo, uma resolu o em X e Y de 100m, uma escala de 1:250.000 e uma regi o a de ni o de regi es feita atrav s de um comando especial, n o discutido neste texto ver Cam95 .
86
6.3.3 Consultas
Uma consulta em legal possui dois componentes: uma express o de busca expressa em sql estendido e uma resposta consulta, que pode ser objeto de manipula o posterior. O usu rio pode formular consultas envolvendo classes tanto de geo-objetos quanto de geo-campos. No caso de geo-campos, dada a sua natureza, os operadores dispon veis em legal permi tem apenas recupera o baseada em atributos convencionais. Para geo-objetos, legal oferece fun es e relacionamentos espaciais, computadas sobre suas localiza es. Por exemplo, a consulta Q1
Selecione os nomes de todos os munic pios mineiros a menos de 50 km da cidade de Belo Horizonte formulada em legal atrav s do comando:
SELECT m.nome FROM m Municipio, c Cidade 50 WHERE c.nome = "Belo Horizonte" and distancem,c
As classes Municipio e Cidade s o especializa es de GeoObjeto e cont m como inst ncias geo-objetos representando os munic pios e cidades mineiros. Sup e-se que os atributos nome e localizacao tenham sido de nidos para ambas as classes. A quali ca o da consulta im plicitamente indica que a fun o espacial distance deve operar sobre tais localiza es, j que esta fun o possui como argumentos apenas as vari veis m e c varrendo respectivamente as inst ncias de Municipio e Cidade. Para geo-objetos, legal oferece ainda a possibilidade das fun es e relacionamentos es paciais serem computadas sobre localiza es dadas por uma representa o particular destes geo-objetos ver se o 4.2.3, que passam a ter preced ncia sobre localiza es de nidas nos pr prios geo-objetos. Esta op o sinalizada pela cl usula REPRESENTED BY. Por exemplo, a consulta Q1 pode ainda ser formulada em legal como:
SELECT m.nome FROM m Municipio, c Cidade 50 WHERE c.nome = "Belo Horizonte" and distancem,c REPRESENTED BY SELECT p FROM p Mapa WHERE p.nome = "Minas Gerais"
As inst ncias de Mapa s o mapas dos estados brasileiros, com seus munic pios e cidades, e tamb m possuem o atributo nome. A constru o REPRESENTED BY indica que as localiza es dos geo-objetos em Municipio e Cidade dever o ser obtidas da representa o de nome Minas Gerais, recuperada pela consulta aninhada sobre Mapa. Esta constru o afeta portanto a sem ntica da fun o espacial distance.
87
A cl usula REPRESENTED BY pode ainda ser associada a cada classe de objetos individual mente, como no exemplo abaixo:
SELECT m.nome FROM m Municipio REPRESENTED BY SELECT p FROM c Cidade REPRESENTED BY SELECT n FROM WHERE c.nome = "Belo Horizonte" and distancep,c 50 n Mapa-Cidade WHERE n.nome = "Minas Gerais" p Mapa-Municipio WHERE p.nome = "Minas Gerais"
As classes Mapa-Municipio e Mapa-Cidade s o duas especializa es de RepComplexa. Suas inst ncias s o mapas dos estados brasileiros com seus munic pios e cidades, respectivamente. Por m, observamos que nada impede que consultas em legal envolvam tamb m geo-campos e suas representa es. Outros exemplos podem ser encontrados em Cam95 .
6.3.4 Manipula o de Objetos e Cole es

Conforme mencionado na introdu o desta se o, legal baseia-se no modelo de nido pelo ODMG. Este modelo permite a de ni o de cole es, que s o conjuntos ordenados de objetos de um mesmo tipo. Permite ainda manipular os objetos de uma cole o atrav s da de ni o de um iterador, ao qual podem ser aplicados os operadores next, first, last, more?, reset e delete. O operador next posiciona o iterador sobre o pr ximo elemento da cole o. Ap s next ter sido aplicado ao ltimo elemento da cole o, o valor do iterador ser nil. A chamada inicial a next retorna o primeiro elemento da cole o, se o par metro iteration-order do iterador for forward tomado como default, ou o ltimo elemento, se iteration-order for backward. Os outros operadores s o de nidos de forma semelhante. Para ilustrar estes construtores, considere novamente a consulta Q1, formulada agora como um programa que cria a cole o dos pares m; d tais que m um geo-objeto em Municipio a menos de 50 km da cidade da cidade de Belo Horizonte e d a dist ncia do geo-objeto a Belo Horizonte:
definicao da colecao e do iterador COLLECTION md Municipio, FLOAT; ITERATOR i OVER md;
construcao da colecao
88

md := SELECT m, distancem, c FROM m Municipio, c Cidade 50; WHERE c.nome = "Belo Horizonte" and distancem,c interacao com o usuario i := nextmd; WHILE i BEGIN IF "usuario nao aceitou o objeto i" THEN deletei; i := nextmd; END nil DO
O comando COLLECTION de ne uma vari vel, md, que recebe como valores uma cole o de pares ordenados, onde o primeiro elemento um objeto de nido da mesma forma que as inst ncias de Municipio e o segundo, um real representado em ponto utuante. O comando ITERATOR de ne um iterador i sobre md cujo par metro iteration-order , por default, forward. O comando SELECT cria md como uma cole o de pares, onde o primeiro componente origina-se de Municipio e o segundo um ponto utuante resultado da fun o distancia. Por m, o comando WHILE varre o conjunto, elemento a elemento. legal permite tamb m de nir vari veis de programa para conter a resposta de consultas que retornam apenas um objeto. Por exemplo, o seguinte programa coloca na vari vel tl o geo-objeto correspondendo cidade de Belo Horizonte:
VARIABLE tl Cidade; tl := SELECT c FROM Cidade c WHERE c.nome = "Belo Horizonte";
O comando VARIABLE indica que a vari vel de programa tl ter como valor um objeto de nido da mesma forma que as inst ncias de Cidade. A de ni o de vari veis de programa torna mais confort vel a aplica o de operadores a geo-campos e a geo-objetos individuais. Conclu mos esta se o exempli cando a utiliza o em legal dos operadores do cap tu lo 5. Considere o banco de dados geogr co AGRICULTURA contendo as seguintes classes de geo-campos de nidos sobre a mesma regi o:
CREATE Chuva nome CHAR20 IS-A Numerico; CREATE Topografia nome CHAR20 IS-A Numerico; CREATE Solo nome CHAR20

IS-A Tematico temas= "Le","Aq",... ; CREATE Aptidao nome CHAR20 IS-A Tematico temas= "Boa","Media","Baixa" ;
89
O programa abaixo ilustra simpli cadamente o uso do operador BOOLEAN para determinar a aptid o agr cola da regi o abrangida pelo banco AGRICULTURA:
VARIABLE campo-chuva VARIABLE campo-topo VARIABLE campo-solos Chuva; Topografia; Solo;
VARIABLE campo-aptidao Aptidao; campo-chuva campo-topo campo-solos := SELECT c FROM c Chuva WHERE c.nome = "Chuva92"; := SELECT t FROM t Topografia WHERE t.nome = "Topo92"; := SELECT s FROM s Solo WHERE s.nome = "Solos92"; campo-aptidao:= BOOLEAN "Boa" : campo-solo.classe = "Le" campo-chuva campo-topo campo-chuva campo-topo "Baixa" : OTHERWISE nome.campo-aptidao := "Aptidao 92"; INSERT campo-aptidao IN Aptidao = 1000 = 1500; = 600 = 1000; E E E
"Media" : campo-solo.classe = "Aq" E
O operador BOOLEAN, apesar do nome, cria um novo geo-campo a partir de outros. Ele exige que seja especi cado um conjunto de condi es a serem satisfeitas para cada tema do geo-campo de sa da, conforme o exemplo acima, onde um geo-campo de aptid o de solos calculado, a partir dos valores de chuvas, topogra a e tipo de solo.
90
Cap tulo 7 Apresenta o de Dados Geogr cos

7.1 Introdu o
A apresenta o de dados geogr cos um aspecto fundamental da interface de um sig. O cap tulo 6 discutiu a intera o de um usu rio com um sig do ponto de vista de facilidades de consulta. Este cap tulo complementa tal discuss o, tratando dos aspectos de apresenta o do resultado de uma consulta. A se o 7.2 aborda a quest o da visualiza o de dados geogr cos, destacando a apresenta o de mapas, e exempli ca como tais problemas s o tratados na lin guagem legal, proposta no cap tulo 6; a se o 7.3 d uma vis o geral do projeto de interfaces para sig. Estudos de apresenta o de dados geogr cos se concentram em aspectos 2D, com pou cas refer ncias a dados em 3D RK91 . Muitos dos trabalhos est o relacionados a linguagens Ege89, Ege94 , enquanto que apenas recentemente surgiu o interesse em arquiteturas de in terface Voi91, Voi94, OM95 e em aspectos cognitivos da apresenta o Mon91, Kuh91, LS92, Kuh93, Gou93, Woo93 . Atualmente, aspectos relacionados apresenta o v m tamb m sendo tratados no contexto de visualiza o cient ca Jai93 .
7.2 Visualiza o de Dados Geogr cos

7.2.1 Considera es Gerais
A interface de um sig deve oferecer pelo menos as seguintes fun es Ege89 . Primeiro, deve oferecer facilidades para visualiza o de campos e objetos geogr cos nos espa os 2D e 3D, incluindo comandos para controlar padr es de preenchimento. A interface deve ajudar o usu rio a formular consultas utilizando a informa o gr ca presente na tela. Deve, ainda, prover formas de combinar o resultados de v rias consultas e de construir legendas que ajudem o usu rio a examinar o conte do apresentado. Interfaces devem tamb m permitir especi car a constru o de uma apresenta o. Em sigs, 91
92
CAP TULO 7. APRESENTA O DE DADOS GEOGR FICOS
isto signi ca considerar n o apenas o que foi especi cado na consulta, mas tamb m informa o adicional que inclua geo-campos e geo-objetos de interesse na regi o recuperada pela consulta, a partir do contexto da aplica o e do per l do usu rio. O sistema de interface deve, assim, dispor de uma grande gama de facilidades para de nir apresenta es e, inclusive, auxiliar o projetista a de nir regras que permitam especi car a apresenta o adequada. O volume dos dados a apresentar e a extens o geogr ca por eles coberta muitas vezes impedem a apresenta o direta do resultado de uma consulta por inteiro. Duas t cnicas podem ser utilizadas para ampliar o espa o de apresenta o Koi95 : amplia o f sica ou redu o da informa o. No primeiro caso, a tela do terminal aumentada usando dispositivos como telas virtuais ou projetores de v deo. No segundo caso, o mais encontrado em sig, s o oferecidas fun es de interface gr ca scrolling, panning, ou fun es do pr prio sig tais como possi bilidade de mudan a de escala ou fun es de an lise estat stica. O espa o de apresenta o pode tamb m ser expandido pelo uso do conceito de hipertexto, em que as ncoras conectam dados semanticamente relacionados, ligando tanto textos descritivos quanto mapas. Em alguns casos, as ncoras ligam n o apenas dados est ticos, mas permitem ativar fun es que calculam correla es espaciais entre dados geo-referenciados BK95 . Ainda, o resultado de uma consulta pode compreender diversos espa os geogra camente distintos. Como visto no cap tulo 6, existem v rias formas de se realizar consultas em um sig. O sistema de visualiza o deve se preocupar n o apenas em mostrar resultados, mas tamb m em oferecer ao usu rio facilidades para manipular os elementos visualizados de forma a construir no vas consultas. Assim, uma interface para sig deve considerar ao menos 3 n veis de visualiza o LG93 : visualiza o de metadados; visualiza o dos componentes usados para construir consultas tanto resultados de con sultas anteriores quanto operadores e fun es que podem ser aplicados a tais resultados; visualiza o do resultado propriamente dito, com resolu es m ltiplas. A visualiza o de metadados visa facilitar a constru o de consultas e permitir estabelecer correla es entre conjuntos de dados em um n vel mais abstrato por exemplo, permitindo relacionar classes de geo-objetos e de geo-campos. Novas propostas de visualiza o destes relacionamentos envolvem grafos em duas ou tr s dimens es ea93, BFG93 . Nos sigs atuais, os metadados s o em geral limitados ao esquema do banco de dados geogr co e s o via de regra apresentados de forma tabular. A visualiza o com resolu es m ltiplas pode requerer apresenta o de informa o contex tual que varie conforme a resolu o. Considere, por exemplo, a seguinte consulta:
Onde est localizada a unicamp?. Como visto nos cap tulos anteriores, o processamento desta consulta corresponde a encontrar a geo-regi o onde est localizado o geo-objeto unicamp. A gura 7.2.1 mostra tr s dentre v rias apresenta es poss veis. A primeira indica que a unicamp est no Estado de S o Paulo; a segunda usa a cidade de Campinas como refer ncia
7.2. VISUALIZA O DE DADOS GEOGR FICOS
93
dentro do Estado; a terceira utiliza um mapa esquematizado da cidade. Estas apresenta es diferem pela escala, formas, legendas, cones e pela informa o contextual fornecida. Na terceira apresenta o, por exemplo, s o inclu das vias de acesso e o aeroporto de Viracopos, embora estes dados n o houvessem sido solicitados.
Figura 7.1: Apresenta es de uma mesma consulta em resolu es diferentes A visualiza o de dados georeferenciados complicada pelas quest es de representa o e o tratamento de relacionamentos entre os dados. Em aplica es tradicionais, representa es m ltiplas inexistem e os relacionamentos entre os dados s o estabelecidos durante a modelagem de dados. No caso de sistemas georeferenciados, uma determinada representa o pode ser apresentada de diversas formas a m de atender aos requisitos do usu rio quer por exig ncias formais do dom nio, quer por necessidades informais ligadas a aspectos cognitivos ou culturais. Al m disto, a maioria dos relacionamentos espaciais calculada a partir do contexto e da representa o adotados. Como visto no cap tulo 4, o resultado de uma consulta depende da representa o sobre o qual calculada, que por sua vez determina como e quais relacionamentos espaciais podem ser calculados. A complexidade do problema pode ser exempli cada a partir da gura 7.2.1, retirada de Arn93 , que retrata duas formas de apresentar concentra es populacionais em uma regi o urbana, cada uma das quais permitindo ao usu rio deduzir relacionamentos espaciais particu lares para uma mesma representa o subjacente. A parte superior de cada gura mostra a distribui o do n mero de habitantes por quarteir o na zona coberta pela linha AB; a parte inferior mostra a distribui o da densidade populacional. No primeiro caso, a apresenta o feita sob forma de mapa tem tico, classi cando as regi es por valor de densidade; no segundo caso, a apresenta o utiliza isolinhas.
94
Figura 7.2: Apresenta es distintas de uma mesma representa o
7.2.2 Produ o Cartogr ca

A apresenta o de mapas uma fun o importante em um sig. De fato, muitas aplica es t m por objetivo produzir cartas eletr nicas Goo93, BP94 . A produ o cartogr ca digital adapta os procedimentos manuais de gera o de mapas em papel produ o de mapas por computador. A automatiza o destes procedimentos manuais n o simples. Como ressaltado por Oli95a , estudos recentes de produ o cartogr ca digital mostram que cores e s mbolos utilizados nas cartas em papel n o s o diretamente transport veis para o meio digital. Esta automatiza o efetuada atrav s de fun es de an lise e estat stica espacial, envolvendo t cnicas de computa o gr ca, processamento de imagens e, para casos mais so sticados, morfologia matem tica Ber93, FR94 . Os algoritmos de apresenta o precisam levar em conta tamb m fatores como a resolu o do dispositivo de sa da e as distor es provocadas por opera es como rota o ou transla o. Estas observa es s o resumidas pela tabela 7.1 e que compara as facilidades de apresenta o cartogr ca usando sigs s facilidades da cartogra a tradicional: Como analisado por Monmonier Mon91 , mapas s o constru dos a partir de tr s elementos b sicos escala, proje o e s mbolos que s o fontes de distor o. A apresenta o deve levar em considera o tais distor es para tentar reduzir o erro na produ o de um mapa. De fato, as regras de produ o cartogr ca variam com os objetivos da aplica o. Cartas terrestres, por exemplo, t m caracter sticas distintas de cartas n uticas. Estas ltimas, por sua vez, diferem na apresenta o do mesmo conjunto de fen menos: cartas para opera es com minas, por exemplo, exigem detalhamento do fundo do mar e do relevo da plataforma continental, enquanto que cartas para opera es anf bias requerem detalhamento das praias, com gradiente da inclina o e natureza do litoral Oli95a .

Cartogra a tradicional Cartas limitadas a aspectos gr cos Imagem est tica Documento nico Carta destinada a um p blico grande Carta destinada a comunicar um conhecimento Cartogra a usando sig Cartas com recursos multimeios
95
Imagem din mica M ltiplos documentos interligados Carta destinada a necessidades individuais Carta utilizada para descobrir novas informa es, usando mecanismos de visualiza o e explora o Carta usada para leitura Carta usada para comunica o interativa Carta produzida por cart grafo Carta produzida por usu rio, n o necessariamente cart grafo Tabela 7.1: Compara o entre cartogra a tradicional e cartogra a usando sig Ber93 identi ca quatro categorias principais de opera es primitivas para produ o car togr ca: reclassi ca o de categorias, sobreposi o overlay de dois ou mais mapas, c lculo de vizinhan a e medidas de dist ncia e conectividade. Estas opera es correspondem a grosso modo s opera es de mesmo nome sobre geo-campos e geo-objetos do se o 5.3, onde cada ope ra o descrita naquele cap tulo seria a seguir complementada por uma fun o de visualiza o do resultado. Opera es de reclassi ca o reorganizam os dados de um mapa de forma a criar um novo mapa, onde cada faixa de valores classe visualizada variando, na apresenta o, atributos de cor, textura e outros. A determina o dos valores destes atributos de visualiza o fun o n o apenas das faixas estabelecidas pela consulta, mas tamb m de sua posi o, contig idade e geometria. Em outras palavras, n o se trata apenas de atribuir diferentes cores s distintas faixas, mas de faz -lo de forma a permitir ao usu rio distinguir as diferen as entre elas. Opera es de sobreposi o envolvem v rios mapas e criam novas regi es que resultam da combina o, para cada posi o geogr ca, dos valores dos mapas sobrepostos naquela posi o, que s o distinguidos por modi ca es de cor e textura. Os limites das regi es podem ser indica dos explicitamente atrav s de linhas poligonais ou deduzidos por diferen a de cor. Processo semelhante de apresenta o ocorre em opera es de vizinhan a. Estas geram mapas que indi cam zonas de in u ncia de algum tipo de fen meno, indicadas atrav s de varia o de cores ou uso de pol gonos. Opera es de dist ncia e conectividade geram mapas que em geral apresentam tra ado de rotas. A indica o de rotas de emerg ncia ou o planejamento de vias de escoamento de produtos s o exemplos deste tipo de situa o, em que as rotas resultantes da consulta s o apresentadas em destaque por exemplo, usando cor sobre um pano de fundo que a malha vi ria da regi o.
96
A linguagem cartogr ca utiliza 7 vari veis visuais BP94 : forma, tamanho, cor, valor, textura, gr o e orienta o. Forma, tamanho e cor s o os fatores cuja variabilidade melhor permite ao usu rio entender o resultado de uma consulta. Para informa es qualitativas sobre objetos pontuais ou lineares, a apresenta o deve ser feita variando a forma, a orienta o ou a cor; se as informa es s o sobre objetos poligonais, varia-se a cor e o gr o. Se, por outro lado, a informa o quantitativa, varia-se o tamanho se o objeto pontual ou linear, enquanto que para objetos poligonais varia-se o tamanho, o valor, a cor ou o gr o. H uma in nidade de formas dispon veis na cartogra a eletr nica, tanto geom tricas quanto simb licas. A vari vel forma s permite ao usu rio determinar informa o qualitativa, precisan do estar associada a outras vari veis cor, tamanho, textura para permitir derivar informa o quantitativa. Em uma carta n utica, por exemplo, o estilo e espessura de uma linha permitem determinar o tipo de fen meno apresentado: batimetria, regi o de visibilidade de um farol, con torno de ilhas Oli95a . Formas podem estar associadas a pontos cones, linhas ou pol gonos. Neste ltimo caso, o termo forma substitu do por textura. A varia o do tamanho dos componentes de uma carta permite avaliar suas grandezas relativas e absolutas. Na pr tica, esta varia o limitada pelas dimens es f sicas observ veis pelo olho humano por exemplo, o menor c rculo percept vel tem um di metro de 0.2 mm BP94 e pelo conjunto de dados apresentados por exemplo, havendo um grande conjunto de fen menos a serem apresentados, o uso do tamanho para avaliar a ordem de grandeza relativa de um fen meno pode inviabilizar a apresenta o de outros fen menos na regi o. Se um conjunto de cidades apresentado por meio de pontos forma em um mapa, a varia o do tamanho destes pontos permite ao usu rio visualizar sua import ncia relativa em termos de popula o. Dentre as sete vari veis visuais, a cor a que melhor permite separar os fen menos de natureza diferente. Todas as cartas de invent rio pedol gicas, clim ticas e outras se baseiam na cor como meio de transmitir informa o qualitativa. A varia o de tom e contrastes de cores possibilita ao usu rio determinar diferen as relativas entre os valores de um fen meno. Por exemplo, em cartas n uticas, diferen as de tons de azul indicam a varia o na profundidade; em mapas de temperatura, cores mais pr ximas do vermelho denotam temperaturas mais quentes. A apresenta o exige tamb m que haja um contraste su ciente entre cores de regi es cont guas, para permitir determinar seus limites. Um valor pode ser apresentado de forma textual ou gr ca combinando forma, cor e tama nho. Neste ltimo caso, a informa o obtida relativa ao contexto da carta. Tramas diferentes por exemplo, hachuras de larguras distintas s o usadas para passar ao usu rio a no o de grada o de valores. Legendas alfanum ricas ajudam a mostrar as diferen as relativas entre os dados, conforme o tipo, tamanho e outras caracter sticas do fonte tipogr co. Al m de permitir compara o entre as dimens es de fen menos a orienta o e inclina o do fonte de uma legenda tornam poss vel visualizar a geometria de um objeto. Os problemas de coloca o autom tica de legendas e de texto em cartas digitais s o descritos em DF92 .
97
Como a apresenta o em escala 1:1 em geral invi vel, qualquer apresenta o cartogr ca corresponde a uma redu o da realidade, efetuada a partir das chamadas opera es de genera liza o. Recordando, o processo de generaliza o consiste em extrair e resumir as informa es desejadas de forma a destacar em uma carta os pontos de interesse, em fun o dos objetivos, tema, escala e particularidades da regi o retratada. A generaliza o cartogr ca erroneamen te considerada como implement vel de forma autom tica a partir de opera es matem ticas de mudan a de escala. Muito pelo contr rio, a automa o completa de procedimentos de generali za o raramente bem sucedida, pois estes exigem envolvimento do usu rio quanto a decis es de apresenta o. A gura 7.2.2 mostra exemplos de opera es de elimina o de detalhes como parte dos procedimentos de generaliza o: a parte a indica a generaliza o de uma edi ca o, enquanto a parte b mostra a generaliza o de um curso d' gua. Em nenhum dos dois casos h redu o de escala, mas no entanto o usu rio respons vel pela produ o decidiu eliminar tais detalhes por exemplo, por raz es de clareza.
(A)
(B)
Figura 7.3: Exemplos de generaliza o A generaliza o se aplica em dois contextos: no processamento num rico dos dados de nindo valores derivados e agregando dados e na apresenta o relacionando visualmente as caracter sticas relevantes. As principais opera es envolvidas s o BP94 : sele o, esquema tiza o e harmoniza o. A sele o consiste em escolher os elementos que compor o a carta, que ser o transformados em um
pano de fundo gr co para permitir visualiza o do contex to por exemplo, topogra a, limites administrativos e outros. A esquematiza o corresponde a simpli car e eliminar detalhes da apresenta o, como por exemplo na gura 7.2.2. Segun do BP94 , a esquematiza o pode ser estrutural correspondendo a uma simpli ca o gr ca usando algoritmos prede nidos ou conceitual ligada sem ntica da carta. A primeira pode ser automatizada usando opera es como interpola o e elimina o de valores, enquanto que a segunda exige interven o humana. A harmoniza o consiste no conjunto de etapas iterativas que combinam sele o e esquematiza o para produzir o resultado nal.
98
7.2.3 Apresenta o de Dados em LEGAL

O cap tulo 6 descreveu de uma forma geral linguagens de consulta para sigs, terminando com o exemplo da linguagem legal, que satisfaz v rios dos requisitos enunciados. Esta linguagem foi descrita em alto n vel, do ponto de vista de especi ca o de esquemas e formula o de consultas. Um outro componente de legal se refere visualiza o dos dados de uma consulta. legal permite de nir as vari veis visuais cor, valor, textura, forma e tamanho, cinco das sete vari veis poss veis. Neste contexto, pode-se considerar a formula o de uma consulta legal como composta de duas partes: especi ca o do resultado desejado e especi ca o de sua apresenta o. A linguagem de apresenta o de legal permite de nir mecanismos para controle da visualiza o dos dados, a partir da cl usula defina visual, cujos par metros variam de acordo com a classe de geo-campos ou geo-objetos apresentada. Os par metros incluem fatores como cor, estilo e padr o de preenchimento. Diferentes formas e s mbolos podem igualmente ser associados aos geo-objetos selecionados em uma consulta. Al m disso, resultados de consultas distintas podem ser combinados em uma nica apresenta o utilizando, na de ni o da apresenta o, o par metro overlay Cam95 . A de ni o dos atributos de uma apresenta o pode ser feita de duas formas complemen tares. Uma delas consiste em de nir caracter sticas default de apresenta o para todos os objetos de uma geo-classe, tais como padr o, cor, textura e s mbolo para todos os objetos de uma geo-classe usando a cl usula defina visual. Neste caso, a cl usula show permite visua lizar os objetos dessas classes de acordo com o especi cado. Alternativamente, o usu rio pode modi car interativamente algumas destas caracter sticas da visualiza o. Suponha por exemplo que a apresenta o dos geo-objetos da classe Municipio do cap tulo 6 tenha sido de nida por
DEFINA VISUAL PARA CLASSE Municipio COR azul PADRAO hachura HACHURA 30 TEXTO AUTOMATICO FIM
Dada a consulta j vista no cap tulo 6,

Selecione os nomes de todos os munic pios a menos de 50km da cidade de Belo Horizonte, o resultado da consulta ser apresentado usando estes par metros pol gonos preenchidos por hachuras em azul, inclinadas a 30 graus, com o nome de cada pol gono nome do munic pio colocado automaticamente. Alternativamente, o resultado pode ser armazenado em alguma classe tempor ria atrav s de atribui o:
7.3. PROJETO DE INTERFACES

mun_minas:= SELECT m.nome FROM m Municipio, c Cidade 50 WHERE c.nome = "Belo Horizonte" and distancem,c
99
e a apresenta o ser solicitada posteriormente, usando a cl usula show:

SHOW mun_minas AS SHADING WHERE SHADING_COLOUR = amarelo
Neste caso, os munic pios que satisfazem a restri o da consulta dada ser o mostrados como pol gonos par metro shading, com hachuras inclinadas a 30 graus, por m na cor amarela. Os outros objetos da classe Municipio, no entanto, ser o visualizados na cor azul default.
7.3 Projeto de Interfaces

A primeira parte do cap tulo discutiu problemas de apresenta o. Estes problemas est o, natu ralmente, intimamente ligados a quest es de projeto da interface. H ainda poucos trabalhos voltados ao projeto de interfaces para sigs, apesar da import ncia da interface na aceita o de um produto. Isto se deve basicamente a dois fatores: problemas intr nsecos natureza dos dados geogr cos e problemas relativos ao projeto de interface em sigs. Por um lado, as aplica es geogr cas apresentam desa os que n o s o respondidos adequadamente pelas propostas de interfaces existentes como, por exemplo, a visualiza o cartogr ca e a apresenta o de representa es m ltiplas de um mesmo objeto; por outro lado, a pr pria rea de projeto e desenvolvimento de interfaces envolve in meros problemas em aberto, sobre os quais ainda n o existe consenso. Os principais resultados na rea de interfaces para sigs come aram a aparecer na d cada de 90, quando problemas nos n veis inferiores da arquitetura de um sig manipula o e arma zenamento de dados, vide cap tulo 8 passaram a ser melhor equacionados. Nesses estudos, a interface considerada como uma camada que entre o usu rio e o sig subjacente. Um tutorial sobre trabalhos na rea Oli95b identi cou tr s tipos de enfoque para projeto de interfaces em sig: arquitetura, linguagem e fatores humanos, mostrados na gura 7.3.1. O enfoque relativo a arquitetura se ocupa em de nir a interface funcionalmente, como um conjunto de blocos que se comunicam entre si e com o sig subjacente. Cada bloco respons vel por um conjunto de tarefas por exemplo, opera es de gerenciamento de janelas ou de apresenta o de dados. O enfoque em linguagens se preocupa em de nir e implementar uma linguagem utilizada pelo usu rio para de ni o e manipula o dos dados. A interface possui, neste caso, mecanismos que
100
USUARIO
Pacote Grafico
Modulo de Dialogo com Usuario Gerente de Interacao Gerente de Apresentacao
Modulo de Modelo de Dados Gerente Conceitual Gerente de Representacao
Driver Externo SIG Gerente de Esquemas Gerente de Dados Gerente de Operacoes
Figura 7.4: Exemplo de arquitetura de uma interface aberta para SIG
101
traduzem comandos do usu rio na linguagem proposta na gura, Le em comandos para o sig subjacente Li. A linguagem legal abordada no cap tulo 6 um exemplo de Le, enquanto que alguns detalhes de Li ser o abordados no contexto de processamento de otimiza o de consultas vide cap tulo 10. O enfoque em fatores humanos estuda o modelo mental do usu rio, para, a partir deste, especi car o modelo de interface apropriado, buscando minimizar o esfor o do usu rio em de nir e manipular dados georeferenciados. A seguir, cada um destes enfoques discutido em mais detalhes.
7.3.1 Arquitetura
Este enfoque se preocupa principalmente com dois itens: especi ca o dos blocos que comp em a arquitetura da interface, suas fun es, suas res ponsabilidades e suas interfaces; de ni o de mapeamentos para otimizar a comunica o entre a interface e o sig subja cente traduzindo o modelo da interface para o modelo do sig e vice-versa. A arquitetura da interface deve ser considerada sob dois pontos de vista: sua comunica o com o resto do sistema no caso, o sig e a intera o entre os m dulos que comp em a inter face propriamente dita. Neste ltimo ponto de vista, o sistema de interface pode ser baseado em arquiteturas diretamente implement veis ou arquiteturas de
toolbox vide por exemplo, Voi91, Voi94 . Cada conjunto de fun es agrupado em um m dulo: visualiza o, manipula o de mapas, intera o com o banco de dados e outros. Nosso modelo de dados, descrito no cap tulo 4, serve de base arquitetura de interface de OM95 , mostrada na gura 7.3. Esta arquitetura prev tr s n veis de blocos funcionais: di logo com o usu rio, modelo de dados e mapeamento. O primeiro n vel respons vel pela visualiza o e intera o com o usu rio. O n vel intermedi rio permite ao usu rio utilizar as no es multin vel do modelo, considerando geo-classes e comportando m ltiplas representa es. O n vel de mapeamento respons vel pela comunica o entre a interface e o sig subjacente, correspondendo linguagem Li. O cap tulo 8 discute as camadas subjacentes interface. Esta ltima corresponde no ca p tulo aos chamados sv Subsistema de Visualiza o e sm Subsistema de Manipula o; o sv trata da apresenta o dos dados, enquanto o sm trata das fun es para de ni o e ma nipula o destes objetos ou seja, a linguagem Le. A comunica o entre esta camada mais externa e o restante do sig segue tr s tipos de loso a b sicos: uni cada, difusa ou focalizada LG93, AYA+92 . Modelos uni cados s o baseados em uma API Applications Programming Interface que esconde do projetista de interfaces os detalhes das estruturas f sicas dos dados. Modelos difusos aceitam distintas APIs, cada uma das quais baseada em estruturas de dados diferentes. Modelos focalizados eliminam a exist ncia da API, obrigando o projetista de inter faces a manusear diretamente as estruturas de dados, sendo a interface parte integrante do sig. Neste caso, a linguagem de comunica o Le altamente dependente do sig.
102
Os modelos uni cado e difuso s o considerados abertos, ou seja, o usu rio entende a interface como um subsistema parte. Nestes casos, a interface
enxerga o sig como um m dulo independente com o qual se comunica atrav s de protocolos de comunica o e convers o de dados. O modelo uni cado pouco extens vel, pois est dirigido a um conjunto b sico de estruturas providas pela API. O modelo difuso mais ex vel, mas apresenta di culdades de programa o, pois cada API precisa ser programada em separado. O modelo focalizado facilita a otimiza o de estruturas, mas obriga o programador a conhecer detalhes de estruturas f sicas.
USUARIO
Le
INTERFACE
Li
SIG
Modelo do Usuario
Modelo de Representacao
Modelo SIG (Conceitual)
Fatores Humanos
Linguagens
Arquitetura
Figura 7.5: Enfoques no projeto de interface
7.3.2 Linguagens
Como visto no cap tulo 6, linguagens de consulta para sigs podem ser textuais, visuais ou multimodais. Em geral, n o h preocupa o com aspectos de visualiza o no projeto destas linguagens, que apenas especi cam quais resultados devem ser apresentados, sem descrever a sintaxe da apresenta o. Exce es s o Ege94, Cam95 , que especi cam, como parte da linguagem, os comandos de apresenta o. Em geral, a linguagem de apresenta o tratada parte, quer dentro do c digo de desen volvimento da aplica o, quer atrav s da cria o no banco de dados de entidades espec cas que de nam os detalhes da visualiza o. Em ambos os casos, n o se trata na verdade de uma linguagem propriamente dita, mas de informa es passadas ao sig atrav s de programas ou menus.
103
7.3.3 Modelo do Usu rio

O estudo dos aspectos envolvendo cogni o espacial formam a terceira dimens o do projeto de interfaces para sigs. Estes aspectos dependem do per l do usu rio e necessidades das apli ca es, resultando em diferentes modelos mentais do usu rio Tve93 . O objetivo da pesquisa nesta rea entender como o ser humano percebe o espa o e, a partir desta percep o, desen volver um modelo que deve guiar as opera es da interface. S o igualmente sugeridas formas de prover ao usu rio diferentes met foras de intera o, adaptadas a seu modelo cognitivo. As di culdades come am na modelagem do conhecimento espacial, passam pelo armazenamento de tal conhecimento e v o at a visualiza o. Esta deve variar conforme as caracter sticas cul turais do usu rio e levar em considera o inclusive seu posicionamento em rela o aos cen rios visualizados observador externo versus participante. A constru o de um modelo mental deve considerar tr s fatores Kuh91, LS92, Kuh93, Gou93, Woo93 : a informa o desejada pelo usu rio, a informa o por ele previamente conhecida e a capacidade do usu rio em inferir novos fatos a partir dos resultados apresentados, associando-os ao conhecimento pr vio. Modelos mentais s o usados como base para de nir ordens de execu o de comandos e regras de apresenta o, validando diferentes tipos de inter faces. Os estudos realizados levam em considera o tanto aspectos cognitivos qualitativos quanto f sicos mensur veis. Exemplos de estudos quantitativos s o a cronometragem das a es de um ser humano no manuseio de mapas de papel, ou o rastreamento dos movimentos do olho humano ao examinar um mapa HCS93 . Tais estudos direcionam a especi ca o do posicionamento dos elementos apresentados em uma tela. Vale ressaltar que muitos dos aspectos cognitivos explorados s o comuns a trabalhos em outras reas vide, por exemplo, Pet95 . Sob este ponto de vista, uma grande quantidade de estudos se ocupa do uso de cores e de posicionamento relativo dos objetos de uma apresenta o. Por exemplo, se duas cores s o adjacentes em uma apresenta o, a intensidade de uma pode modi car a percep o que o usu rio tem da outra devido ao est mulo da retina, o que o far associar import ncias relativas aos dados apresentados. Cores
quentes s o mais percept veis do que cores
frias, o que geralmente faz com que apresenta es relacionem tons de vermelho e amarelo a valores positivos em mapas BP94 . Os padr es de percep o de mapas e memoriza o de seus componentes tamb m ajudam a compor o modelo mental HCS93 . Certas pessoas classi cam dados mentalmente sob forma de hierarquias, enquanto que outras criam grafos mentais que lhes permitem deduzir dist n cias e correla es espaciais. A interface, portanto, deve priorizar uma ou outra maneira de apresenta o, conforme o usu rio. Isto envolve, inclusive, discuss es sobre modos de navega o Nye93 , percep o do espa o e formas de apresenta o de relacionamentos espaciais em 2D e 3D Her94 . Ressaltamos nalmente algumas observa es relativas ao problema de apresenta o. Em primeiro lugar, o uso de interfaces gr cas n o garante a clareza ou qualidade dos resultados, pois os usu rios
enxergam o resultado de uma consulta n o apenas vendo o que mostrado, mas tamb m em fun o de alguma nota o gr ca impl cita transmitida, por exemplo, por
104
no es de adjac ncia, cor e outras, particulares ao per l cognitivo do usu rio. Em segundo lugar, esta nota o gr ca impl cita derivada da experi ncia do usu rio com o dom nio da aplica o e seu conhecimento pessoal da regi o geogr ca estudada ou seja, a familiaridade do usu rio com o problema deveria in uenciar a estrat gia de apresenta o. Finalmente, especialistas em um dom nio t m necessidades de apresenta o distintas daquelas de novatos. Todos estes fatores, no limite, levam conclus o que um sig ideal deveria ter uma interface diferente para cada usu rio, o que seria bastante complexo. A recomenda o mais pr xima de tal solu o a cria o de um banco de regras que descrevam o per l do usu rio, que seja consultado para direcionar a apresenta o Gou93 .
PARTE III
105
Cap tulo 8 Arquiteturas para SIG

8.1 Introdu o
Este cap tulo discute arquiteturas alternativas para sig, balizando-se pelo paradigma que requer o desenvolvimento de tecnologia para gerenciamento de grandes bancos de dados georeferencia dos. A se o 8.2 descreve sucintamente uma arquitetura em camadas para um sig, seguindo os conceitos introduzidos no cap tulo 4 e separando claramente as fun es de armazenamento, ma nipula o e visualiza o. A se o 8.3 especi ca ainda diferentes estrat gias de implementa o, compat veis com a arquitetura em camadas apresentada, que permitem classi car, de maneira coerente, os sig dispon veis comercialmente ou propostos como prot tipos. Finalmente, a se o 8.4 estende a discuss o para arquiteturas distribu das para sig. Quest es gen ricas sobre arquitetura de sig s o tratadas em PMP93, CHF93a, Cam93, Cam94a . Este cap tulo baseia-se principalmente em Toc95, Cam95 , onde o leitor encontrar discuss es bastante detalhadas sobre arquiteturas para sig. Experi ncias com sistemas de ger ncia de bancos de dados geogr cos s o reportadas em HC91, vOV91, Bat92 para o caso de sistemas relacionais estendidos, em DRS93b, GR93, MMS93, SV92 para sistemas orientados a objetos e em SRD+91, SA93, LL93, Web90 para o caso do uso de t cnicas de intelig ncia arti cial. Exemplos de projetos objetivando a constru o de prot tipos de sig incluem Sequoia 2000 SFGM93 , Goose AA93 , Amusing FT93 e GeO2 DRS93a , os dois primeiros ligados ao problema de mudan a global.
8.2 Uma Arquitetura em Camadas

Uma estrat gia comumente empregada para descrever sistemas computacionais consiste em divi d -los em camadas funcionalmente cada vez mais complexas e, ortogonalmente, em subsistemas especializados em determinada tarefa ou em determinado tipo de dados. Esta se o segue esta estrat gia descrevendo sucintamente uma arquitetura em camadas para um sig que claramente separa as fun es de armazenamento, manipula o e visualiza o. 107
108
CAP TULO 8. ARQUITETURAS PARA SIG
A arquitetura re ete as classes de objetos e os n veis de abstra o introduzidos no cap tulo 4. A gura 8.1 indica as camadas e subsistemas propostos para organizar um sig.
SV SMM SAM
SV visualiza o SMM manipula o matricial SAM armazenamento matricial SAF armazenamento f sico
SM SMV SAV SAF SMC SAC
SM manipula o SMV manipula o vetorial SAV armazenamento vetorial
SMC manipula o convencional SAC armazenamento convencional
Figura 8.1: Arquitetura gen rica em camadas para um sig.
No n vel superior, n o especi cado pela arquitetura, encontram-se as aplica es de geopro cessamento e m dulos de interface com o usu rio, discutidos no cap tulo 7. A primeira camada distingue as quest es de visualiza o dos problemas de manipula o e corresponde ao n vel conceitual do modelo. O Subsistema de Visualiza o sv oferece fun es b sicas para visualiza o de objetos tradicionais e georeferenciados, enquanto que o Subsistema de Manipula o sm oferece fun es para de ni o e manipula o destes objetos. A segunda camada corresponde ao n vel de representa o do modelo. Ela oferece separada mente servi os de manipula o de alto n vel para atributos convencionais, representa es ma triciais e representa es vetoriais, atrav s do Subsistema de Manipula o Convencional smc Subsistema de Manipula o Matricial smm e do Subsistema de Manipula o Vetorial smv, respectivamente. A terceira camada engloba os subsistemas que oferecem servi os de armazenamento e ma nipula o elementar para atributos convencionais, representa es matriciais e representa es vetoriais. Esta camada composta do Subsistema de Armazenamento Convencional sac Sub sistema de Armazenamento Matricial sam e do Subsistema de Armazenamento Vetorial sav. Estes subsistemas fazem uso do servi o de armazenamento de p ginas f sicas disponibilizado pelo Subsistema de Armazenamento F sico saf, que comp e a quarta camada.
8.3. ESTRAT GIAS DE IMPLEMENTA O
109
8.3 Estrat gias de Implementa o

Esta se o apresenta diferentes estrat gias de implementa o para a arquitetura em camadas, baseadas em sistemas de ger ncia de bancos de dados com grau crescente de funcionalidade. As estrat gias de implementa o permitem classi car, de maneira coerente, v rios sigs dispon veis comercialmente ou propostos como prot tipos. A tabela 8.1 apresenta uma compara o das vantagens e desvantagens de cada uma das estrat gias de implementa o discutidas nesta se o. Vale notar que a compara o apresentada esquem tica e esconde nuances. Por exemplo, as vantagens completas da ltima estrat gia discutida s ocorrem quando o sgbd utilizado completamente extens vel.
Estrat gia Dual Vantagens SGBD de mercado Independ ncia do SGBD Campos Longos Controle de integridade Problemas Controle de integridade Otimiza o de consultas Depend ncia do SGBD Otimiza o de consultas Controle de integridade Depend ncia do SGBD Otimiza o de consultas Falta de padroniza o aceita e m todos de indexa o para ling. de consulta
Extens vel
Tabela 8.1: Compara o entre as estrat gias de implementa o
Estrat gia Dual

Em linhas gerais, um sig implementado segundo a estrat gia dual utiliza um sgbd relacional para armazenar em tabelas a componente convencional de todos os objetos, e arquivos normais para a componente espacial dos objetos. Em termos da arquitetura em camadas proposta, esta estrat gia signi ca implementar o smc e o sac inteiramente sobre um sgbd relacional e implementar o smm, sam, smv e sav sobre o sistema de arquivos do sistema operacional, para a componente espacial das representa es, e sobre o sgbd, para a componente convencional das representa es. Contudo, a maior parte das solu es dispon veis comercialmente para Geoprocessamento que seguem esta estrat gia leva a dualidade at as camadas superiores. Exemplos de sistemas comerciais seguindo esta estrat gia s o o ARC INFO Mor92 , o MGE Int90 e o spring vide cap tulo 11, onde apenas este ltimo de fato mascara completamente a dualidade para o usu rio. De certa forma, o sistema GRASS U.S92 , de dom nio p blico, tamb m segue esta estrat gia, embora n o utilize um sgbd relacional. A principal vantagem da estrat gia dual est em utilizar sgbds relacionais de mercado. Por outro lado, como as componentes espaciais est o fora do controle do sgbd, a estrat gia di culta o equacionamento das quest es de otimiza o de consultas, ger ncia de transa es e controle de integridade e de concorr ncia. Estes problemas s podem ser resolvidos atrav s de
110
implementa es so sticadas do smm, smv e do pr prio sm para que operem coordenadamente com o sgbd convencional. A estrat gia dual tamb m exige a constru o do sam e do sav a partir apenas das facilidades oferecidas pelo sistemas de arquivos do sistema operacional, que em geral s o muito mais pobres do que aquelas oferecidas por um sgbd. A execu o de uma consulta em um ambiente dual tipicamente segue um plano bem r gido: a componente convencional da consulta processada pelo sgbd relacional, em separado das restri es espaciais, que s o deixadas a cargo do smm e do smv; os resultados parciais s o posteriormente combinados pelo sm para gerar o resultado nal da consulta. Esta rigidez na gera o do plano de execu o, embora conveniente para a implementa o do sig, geralmente leva a planos sub- timos. Como um segundo exemplo, poss vel que uma representa o permane a registrada no banco de dados convencional, embora o arquivo onde estava armazenada a sua componente espacial tenha sido removido, quer inadvertidamente, quer por interrup o indevida do proces samento. Para resolver completamente este problema de controle da integridade, necess rio implementar as camadas inferiores da arquitetura gen rica de forma inacess vel ao sistema ope racional por exemplo, em UNIX, os dados seriam colocados numa
raw partitition parti o da qual o UNIX n o conhece a estrutura interna, deixando para o saf a tarefa de guardar todas informa es sobre blocos e trilhas de disco onde est o armazenadas as representa es.
Estrat gia baseada em Campos Longos

Esta estrat gia baseia-se no uso de sgbds relacionais com suporte para campos longos, nos quais s o armazenadas as componentes espaciais dos objetos. Em outras palavras, em termos da arquitetura em camadas, tanto os subsistemas para manipula o e armazenamento dos atributos convencionais - smc e sac - quanto os subsistemas para armazenamento matricial e vetorial - sam e sav - passam a ser implementados atrav s do sgbd relacional, pelo menos em parte. Por m, os subsistemas para manipula o matricial e vetorial - smm e smv - continuam fora do sgbd. O SYSTEM 9 vEU89 um exemplo de um sistema comercial implementado segundo esta estrat gia. Em mais detalhe, do ponto de vista conceitual, um campo longo apenas uma cadeia bin ria, onde se pode armazenar qualquer tipo de dado, como dados gr cos, num ricos ou pict ricos. Fisicamente, o sgbd permite que um campo longo possua tamanho consider vel em alguns casos, da ordem de gigabytes. As fun es oferecidas por um sgbd para tratamento de campos longos s o tipicamente limitadas ao acesso a fragmentos do conte do do campo, especi cando a posi o de in cio e o tamanho do fragmento. Em alguns casos, engloba tamb m mecanismos de integridade f sica tipicamente shadowing. A principal vantagem desta estrat gia est em armazenar todos os objetos de um banco de dados geogr cos atrav s de um nico sgbd, evitando os problemas de ger ncia de transa es e de controle de integridade e de concorr ncia, mais complicados de resolver na estrat gia dual. Por m, como o sgbd trata um campo longo como uma cadeia bin ria, n o conhece a sem ntica do seu conte do e, portanto, n o possui mecanismos satisfat rios para seu
8.3. ESTRAT GIAS DE IMPLEMENTA O
111
tratamento. Assim, a implementa o do sig ainda deve incluir m todos de acesso espacial e um otimizador de consultas que prepare planos de execu o que fa am uso destes m todos. Al m disto, embora o padr o da linguagem sql, principal interface oferecida pelos sgbd relacionais, de na fun es b sicas para tratamento de campos longos, h pequenas varia es nas facilidades de fato disponibilizadas. Como conseq ncia, uma implementa o seguindo esta estrat gia pode car dependente do sgbd escolhido.
Estrat gia baseada em Mecanismos de Extens o

Esta estrat gia depende da ado o de um sgbd extens vel que disponha de mecanismos que permitam implementar o tratamento das componentes espaciais atrav s de extens es ao seu ambiente. Exemplos de sgbd extens veis s o os assim chamados sistemas p s-relacionais, como o POSTGRES Uni93 e o STARBURST HC91 , e os sistemas orientados a objetos, como o O2 BDK92 e o ObjectStore. No n vel da linguagem de de ni o e manipula o de dados, ou seja da sua interface com o usu rio, um sgbd extens vel tipicamente permite a de ni o de novos tipos de objetos dentre os quais, aqueles introduzidos no modelo apresentados no cap tulo 4. Note que a especi ca o de um novo tipo inclui a de ni o dos atributos dos objetos e dos m todos que atuam sobre eles. Portanto, esta facilidade vai muito al m de campos longos, pois permite capturar a sem ntica dos objetos. Para facilitar a implementa o de um sig, um sgbd deve estar aberto tamb m a extens es nos n veis mais internos. Ele deve permitir a de ni o de novos m todos de armazenamento e acesso, a adi o de novas regras ao otimizador de consultas para fazer bom uso dos novos m to dos e at a modi ca o da pol tica de ger ncia de transa es para adaptar a sua funcionalidade s necessidades das aplica es de Geoprocessamento. Em ltima inst ncia, deve ser poss vel implementar o smm, sam, smv e o sav como extens es do sgbd. Naturalmente, esta estrat gia apresenta di culdades t cnicas, embora menores do que os casos anteriores, mas aumenta muito a funcionalidade e possivelmente o desempenho do sig resultante. Na pr tica, os sigs comercialmente dispon veis baseados em estrat gias extens veis dos quais o mais importante o SMALLWORLD GIS desenvolveram seus pr prios sgbd, por n o disporem de alternativas aceit veis no mercado poca Bat92 . Quatro projetos de pesquisa merecem men o no contexto desta estrat gia: os sistemas GEO++ , Sequoia 2000, GeO2 e Paradise. Os sistemas GEO++ vOV91, VvO91 e Sequoia 2000 Sto93 foram desenvolvidos sobre o sistema POSTGRES. Este sistema uma extens o ampla da tecnologia relacional e disp e de algumas ferramentas para manuseio de dados gr cos, incluindo suporte para rvores-R, estrutura de indexa o espacial com bom de sempenho e tipos de dados espaciais - ponto, segmento de linha, linhas poligonais e ret ngulo envolvente "box". O sistema GEO++ foi escrito em C++ e estende os tipos de dados geo m tricos do POSTGRES, al m de rotinas de acesso aos dados. Sequoia 2000 um projeto de longo prazo com o prop sito de dar suporte a estudos de mudan as globais e envolve aspectos de armazenamento, redes de comunica o de dados de alto desempenho e visualiza o de dados
112
georeferenciados Gar93 . O GeO2 baseia-se no sistema O2, um sgbd orientado a objetos dispon vel comercialmente DRS93b . O GeO2 utiliza os mecanismos de cria o de novos tipos do O2 para implementar um modelo de dados adequado s aplica es de Geoprocessamento, limitado por m s repre senta es vetoriais. Foi desenvolvido pelo IGN
Institut Geographique National da Fran a para dar apoio Cartogra a Digital francesa, em v rias escalas e para v rios temas. O projeto Paradise Parallel Data Information System da Universidade de Wisconsin DDY93, ea94 tem como objetivo aplicar as tecnologias de orienta o a objetos e bancos de dados paralelos ao desenvolvimento de um sig capaz de gerenciar grandes bases de dados geo gr cas. Como gerenciador persistente de objetos, Paradise utiliza o sistema Shore M. 94 , tamb m desenvolvido pelo grupo da Universidade de Wisconsin.
8.4 Arquiteturas Distribu das

8.4.1 Arquiteturas Cliente-Multiservidor
Na arquitetura para sistemas de ger ncia de bancos de dados distribu dos sgbdd, abrevia damente, o armazenamento dos dados nos v rios processadores guiado por um crit rio de distribui o, que pode ou n o incluir replica o de fragmentos dos dados. O ciclo de execu o de uma consulta ou atualiza o passa a incluir, ent o, execu o de opera es locais, transfer ncias de dados e composi o de resultados parciais. J as arquiteturas cliente-servidor mais recentes para bancos de dados preocupam-se em separar a funcionalidade do sgbd entre um servidor e um ou mais clientes. O servidor oferece servi os de armazenamento e recupera o, que podem ser no n vel de arquivos como o NFS do sistema UNIX, de p ginas f sicas ou de objetos no caso de alguns sistemas orientados a objetos. Cada cliente implementa as camadas superiores do sistema at o n vel da aplica o. Esta discuss o pode ser uni cada com a quest o de sgbdd considerando-se um conjunto de servidores, em lugar de um nico, gerando uma arquitetura cliente-multiservidor. Reportando-se arquitetura em camadas descrita na se o 8.2, obt m-se diferentes arquite turas cliente-multiservidor variando-se a camada em que se introduz o crit rio de distribui o dos dados e o corte entre cliente e servidor Toc95 . As arquiteturas resultantes distinguem-se entre si pelo grau de abstra o dos dados fragmentados e pelas opera es realizadas no cliente e nos servidores. A camada onde aplicado o corte passa a ser respons vel por mascarar para a camada superior a distribui o do armazenamento e manipula o dos dados, controlando a localiza o dos fragmentos dos dados, bem como o processamento distribu do das opera es oferecidas naquela camada. Considere inicialmente que a distribui o se d na primeira camada, ou seja, no n vel do SV e SM ver gura 8.1. Neste caso, pode-se de nir diversos crit rios de distribui o para objetos tradicionais e georeferenciados de forma semelhante aos usados em bancos de dados convencionais. O corte da arquitetura nesta camada resulta em um banco de dados distribu do
8.4. ARQUITETURAS DISTRIBU DAS
113
fracamente acoplado, onde cada servidor conhece a sem ntica dos dados e implementa opera es de alto n vel, tornando os servidores independentes entre si. A distribui o no n vel da segunda camada facilita a de ni o de crit rios de distribui o para a componente espacial de forma completamente independente dos crit rios para a compo nente convencional dos objetos. Contudo, cada um dos servidores ainda conhece a sem ntica das componentes e pode operar sobre elas de forma independente. Uma forma de distribui o baseada na fragmenta o das componentes espaciais oferece maior exibilidade para paraleli zar opera es espaciais, j que permite armazenar fragmentos de componentes espaciais em servidores distintos. Os dois ltimos pontos de corte poss veis s o no n vel das camadas de armazenamento. Cortando no pen ltimo n vel, apenas opera es b sicas sobre representa es vetoriais no sav, sobre representa es matriciais no sam ou sobre atributos convencionais no sac s o pa ralelizadas. Os servidores que armazenam os fragmentos destes objetos s o completamente dependentes dos processos que implementam as camadas superiores. J o corte no n vel do saf gera uma arquitetura cliente-multiservidor com distribui o em n vel de p ginas f sicas, onde os servidores desconhecem completamente a sem ntica dos objetos.
8.4.2 Arquiteturas Orientadas-a-Servi os

Em uma arquitetura cliente-servidor tradicional, conforme discutido na se o anterior, cada cliente recebe comandos do usu rio e executa aplica es, que requisitam dados a um ou mais servidores. J em uma arquitetura orientada-a-servi os, a hierarquia cliente-servidor tradicio nal quebrada em tr s componentes: clientes, servidores e uma malha de interoperabilidade request broker, conforme ilustrado na gura 8.2. Os sistemas EOSDIS EMM94 e METVIEW RND+95 s o exemplos desta arquitetura no caso de sig. O cora o desta arquitetura a malha de interoperabilidade, respons vel pela comunica o entre os clientes e os servidores. Esta malha realiza v rios tipos de opera es: an ncio dos servi os dispon veis para os clientes; adequa o do pedido dos usu rios aos servi os dispon veis. Em muitos casos, uma solicita o do usu rio pode envolver v rios servi os dispon veis no sis tema; tradu o e transfer ncia de par metros e dados entre m quinas, processos e espa os de endere amento distintos. Al m disto, em uma arquitetura orientada-a-servi os, os servidores s o tipicamente especia lizados para tarefas bem de nidas. Isto permite que cada servidor tenha apenas a informa o necess ria para sua opera o, sem sobrecarga desnecess ria. Os princ pios gen ricos enumerados acima para arquiteturas orientadas-a-servi os podem ser aplicados arquitetura em camadas descrita na se o 8.2, gerando diferentes arquiteturas orientadas-a-servi os para sig. Contudo, os crit rios para divis o dos servi os entre os clientes e servidores ser o aqui considerados mais r gidos, seguindo as limita es listadas abaixo: os pontos de corte coincidem sempre com as interfaces entre as camadas, facilitando a de ni o da malha de interoperabilidade;
114

o crit rio de distribui o do banco de dados entre os servidores ser apenas por tipo de objeto, n o se considerando a possibilidade de fragmentar objetos. Cliente SV SM Cliente SV SM
Malha de Interoperabilidade SMM SAM SAF Servidor Matricial SMV SAV SAF Servidor Vetorial SMC SAC SAF Servidor Convencional
Figura 8.2: Arquitetura orientada-a-servi os para sig. O resto desta se o discute alternativas dentro destas limita es. A primeira alternativa consiste em implementar os servidores de armazenamento de forma separada e por conseguinte dividir o saf em tr s. Cada servidor passa a ser especializado portanto no armazenamento de um tipo de objeto - matricial, vetorial ou convencional. A implementa o das camadas superiores ca a cargo dos clientes. Esta alternativa bastante conveniente quando o volume de dados substancial. No caso extremo, cada servidor pode ser substitu do por um conjunto de servidores, formando um cluster, ou ligados por uma rede local ou mesmo por uma rede de longo alcance. Os servidores especializados n o conhecem a organiza o l gica do banco de dados geo gr co e s o respons veis apenas por servi os elementares de armazenamento persistente e recupera o e pelos servi os locais de ger ncia de transa es, controle de concorr ncia e contro le de integridade. A malha de interoperabilidade trabalha neste caso em um n vel de servi o bastante elementar. O servi o de otimiza o de consultas, e os servi os globais de ger ncia de transa es, controle de concorr ncia e controle de integridade permanecem sob a responsabili dade das camadas superiores, implementadas replicadamente em cada cliente. Em particular, quando uma consulta submetida a partir de um cliente, a implementa o local do sm dever estabelecer um plano timo de execu o e coordenar a sua execu o. Cada plano consistir na execu o de subconsultas sobre representa es matriciais pelo smm, sobre representa es vetoriais pelo smv e sobre atributos convencionais pelo smc, que eventualmente chamam os servidores de armazenamento apropriados atrav s da malha de interoperabilidade.
8.4. ARQUITETURAS DISTRIBU DAS
115
Evoluindo para uma camada superior, a segunda alternativa seria implementar em servi dores separados os pares de subsistemas de manipula o armazenamento para cada tipo de objeto. O subsistema respons vel pela visualiza o de representa es, em princ pio, permane ceria sob responsabilidade do cliente, embora do ponto de vista l gico nada impe a a cria o de um servidor especializado em visualiza es. Os servidores especializados neste caso ofere cem servi os so sticados, incluindo recupera o de dados atrav s de consultas de alto n vel. As subconsultas geradas pelo plano de execu o de uma consulta seriam ent o diretamente submetidas ao servidores especializados. Em resumo, as arquiteturas orientadas-a-servi os para sig discutidas nesta se o baseiam-se em servidores especializados por tipo de objeto, sugerindo implementa es pr ximas do es quema tradicional de sistemas de ger ncia de bancos de dados distribu dos heterog neos com acoplamento fraco entre os n s. As alternativas apresentadas diferem essencialmente pelo n vel dos servi os oferecidos pelos servidores. Este enfoque justi ca-se pelas enormes diferen as de comportamento e volume de dados entre os diversos tipos de representa es, geo-objetos e geo-campos manipulados pelas aplica es de Geoprocessamento. Por m, observamos que as decis es mais importantes sobre a implementa o do processo que ger ncia a malha de interoperabilidade s o o modelo de objetos a ser utilizado e o protocolo de comunica o com os demais processos. Alternativas poss veis incluem Cam95 : utiliza o de um padr o de mercado, onde as op es incluem SOM Cam94b e OLE Bro94 ; implementa o de uma
casca adicional; ado o de protocolo dedicado, de r pida implementa o, semelhante ao dispon vel para o sistema METVIEW RND+95 . Um dos problemas com os padr es emergentes na rea a incerteza relativa quanto ao seu futuro, o que aumenta em muito o risco de qualquer op o. Adicionalmente, embora especi ca es como CORBA Obj94 de nam um padr o de interoperabilidade em sistemas distribu dos, algumas de suas implementa es como o SOM operam em um nico espa o de endere amento Cam94b . O aspecto talvez mais importante o v cio de origem. Padr es como SOM e OLE t m como objetivo maior o suporte a documentos compostos, t picos de aplica es de automa o de escrit rio, necessitando adapta es para o manuseio de dados geogr cos. O padr o OGIS, discutido na se o 4.3, prop e-se exatamente a adaptar um padr o de interoperabilidade tipo CORBA para aplica es geogr cas.
116
Cap tulo 9 Armazenamento de Dados Geogr cos

9.1 Introdu o
Este cap tulo discute as quest es de armazenamento e indexa o de dados geogr cos, a partir da arquitetura e conceitos apresentados no cap tulo 8. H uma consider vel quantidade de trabalhos publicados sobre bancos de dados geogr cos abordando m todos de indexa o espacial Sam89, GB90, HS92b, Cox91 , Kri91, HS92b, Rot91, SFGM93, KBS93, MCD94 , sem que haja um consenso sobre qual o melhor GB90 . Um estudo comparativo sobre o desempenho de diferentes tipos de rvores-R pode ser encontrado, por exemplo, em Cox91 .
9.2 Estrat gia Elementar de Armazenamento

De acordo com a discuss o da se o 8.3, as implementa es mais simples da arquitetura em camadas seguem a estrat gia dual ou a estrat gia baseada em campos longos. Resumidamente, estas estrat gias: separam a componente convencional da componente espacial dos objetos; armazenam a componente convencional atrav s de um sgbd; armazenam a componente espacial em arquivos convencionais, ou em campos longos, se o sgbd oferecer esta facilidade. As virtudes e problemas destas estrat gias j foram comentadas na se o 8.3. Recordando alguns pontos, estas estrat gias permitem construir, de forma simples e imediata, um sig sobre um sgbd usufruindo dos servi os por este oferecidos. Por m, por n o levar em conta a natu reza da componente espacial dos objetos, elas oferecem poucas oportunidades para otimizar o processamento das opera es espaciais. O resto desta se o discute algumas formas elementares de otimiza o, abstraindo at onde for poss vel a forma exata de implementa o. 117
118
CAP TULO 9. ARMAZENAMENTO DE DADOS GEOGR FICOS
A seq ncia t pica de processamento neste contexto consiste em selecionar um conjunto de objetos atrav s de uma consulta convencional, trazer da mem ria secund ria para a mem ria principal as suas componentes espaciais, ou apenas parte delas, e executar opera es espaciais sobre estas componentes. H assim tr s oportunidades para otimiza o. A primeira oportunidade consiste em facili tar a sele o dos objetos, armazenando no sgbd, sob forma de atributos convencionais, valores pr -computados a partir das suas componentes espaciais. Por exemplo, para um objeto cuja componente espacial seja um pol gono, armazena-se a rea, a descri o do per metro, e uma aproxima o do pol gono, tal como o seu ret ngulo envolvente m nimo. O usu rio, ou automa ticamente o sistema, tem neste caso a oportunidade de selecionar objetos pelas caracter sticas do seu pol gono, utilizando estes novos atributos, juntamente com os convencionais. Para um objeto cuja componente espacial seja uma imagem, computa-se v rios descritores, como por exemplo o n vel m dio de cinza e uma medida de textura da imagem, ou mesmo cria-se um pequeno cone re-amostrando-se drasticamente a imagem. H , por exemplo, sistemas que ofere cem uma interface para o usu rio selecionar um conjunto de imagens atrav s de seus descritores e re nar a escolha folheando os cones das imagens selecionadas ver tamb m a se o 6.2.4. A segunda oportunidade de otimiza o ocorre no n vel de armazenamento f sico. De fato, se a componente espacial de um objeto ocupar mais de uma p gina f sica, o subsistema de armazenamento dever armazenar todas estas p ginas contiguamente em mem ria secund ria para minimizar o tempo de leitura das p ginas. Al m disto, uma vez solicitada a recupera o da componente espacial, o subsistema de armazenamento dever reconstruir o valor do atributo em um bloco cont guo de mem ria principal e pass -lo para a camada superior, ou implementar um esquema mais so sticado de pagina o que d a ilus o para as camadas superiores de que o valor da componente reside completamente em mem ria principal. Note que esta forma de otimiza o completamente independente do tipo da componente espacial e da opera o que o usu rio deseja realizar. A terceira oportunidade de otimiza o, por outro lado, depende completamente do tipo da componente espacial e consiste em escolher uma estrat gia de armazenamento que otimize as opera es tipicamente executadas sobre esta componente. Neste caso, os pol gonos dever o ter seus v rtices armazenados em uma lista ordenada por valor crescente da coordenada usada na varredura. Esta estrat gia torna-se interessante principalmente quando o subsistema armazena esta lista em v rias p ginas f sicas e as transfere uma a uma para mem ria principal. Assim, se o espa o for varrido apenas uma vez, cada p gina ser transferida tamb m apenas uma vez da mem ria secund ria para a mem ria principal exceto se o n mero de regi es envolvidas for t o grande que n o seja poss vel manter em mem ria principal pelo menos uma p gina para cada regi o. O restante deste cap tulo descreve m todos especiais de armazenamento e indexa o que levam em considera o o tipo da componente espacial para acelerar opera es t picas sobre ela.
9.3. ARMAZENAMENTO DE REPRESENTA ES MATRICIAIS
119
9.3 Armazenamento de Representa es Matriciais
Recordando, uma representa o matricial nada mais do que uma matriz, possivelmente de grande dimens o. O m todo de armazenamento para matrizes mais simples consiste em arma zenar, nas p ginas f sicas em mem ria secund ria, uma linha ap s a outra ou uma coluna ap s a outra. Este m todo adequado para processar opera es que exigem visitar os elementos da matriz linha a linha, ou sem nenhuma ordem preferencial como, por exemplo, no c lculo de um histograma. Ele n o apropriado, no entanto, quando a opera o exige visitar elementos em uma ordem que n o seja aquela usada no armazenamento, ou visitar um elemento e seus vizinhos nas duas dimens es, ou mesmo recuperar os elementos da matriz cobertos por uma janela de nida por um intervalo de ndices em cada dimens o. poss vel minimizar este problema atrav s de um m todo de armazenamento que divi da cada linha ou coluna em segmentos de comprimento xo, subm ltiplo do tamanho da linha, e que permita transferir tais segmentos da mem ria secund ria para a mem ria princi pal e vice-versa. Este m todo seria complementado com um mecanismo que permitisse trazer concomitantemente para mem ria principal v rios segmentos de linha. Note que, no caso de armazenamento linha a linha, opera es percorrendo a matriz coluna a coluna ainda seriam processadas ine cientemente. Um terceiro m todo de armazenamento para matrizes consiste em dividir cada matriz em pequenos blocos, digamos de dimens o 256 256, armazenados seq encialmente em mem ria secund ria segundo alguma ordem, digamos na dire o das linhas. Este m todo, complemen tado por mecanismo de bu er pool, permite otimizar o processamento de opera es que n o trabalham linha a linha ou coluna a coluna. Em todos estes m todos, dado um elemento ou uma janela de elementos, poss vel identi car os segmentos ou blocos envolvidos e computar diretamente as p ginas f sicas em mem ria secund ria que os cont m. Este mapeamento simples quebrado se cada linha, segmento ou bloco sofrer compacta o sem perda antes de ser armazenado. A inclus o de compacta o diretamente no m todo de armazenamento bastante interessante no caso da representa o de imagens de sensoriamento remoto e de mapas tem ticos, onde a redund ncia bastante alta. Por m, cada linha, segmento ou bloco, depois de compactado, passa a ter comprimento vari vel, n o havendo mais um mapeamento simples entre cada entrada na matriz e sua posi o em uma p gina em mem ria secund ria. Para contornar este novo problema, a estrutura de armazenamento da matriz deve ser acompanhada de um diret rio auxiliar indicando em que posi o de que p gina f sica come a cada linha segmento ou bloco compactado e qual o seu comprimento depois de compactado. Este diret rio ser tipicamente pequeno, podendo residir em mem ria principal ap s a matriz ter sido aberta para processamento.
120
9.4 Armazenamento e Indexa o de Representa es Veto riais

Nesta se o trataremos sucessivamente do armazenamento e indexa o espacial de conjuntos de pontos, ret ngulos, linhas e regi es de nidos em R2. Em seguida, discutiremos o armazena mento de representa es vetoriais mais complexas. No que se segue, pressupomos o uso de um sistema de coordenadas planas, o que nos permite mencionar o eixo dos X e o eixo dos Y .
9.4.1 Pontos
Nesta se o descreveremos dois m todos de armazenamento e indexa o espacial a conjuntos de pontos, os arquivos em grade grid les NHS84 e as rvores KD kd-trees BER85 . Uma grade particiona a regi o de interesse em c lulas atrav s de retas paralelas aos eixos e espa adas irregularmente, conforme ilustrado na gura 9.1. Um arquivo em grade consiste de duas escalas, uma para cada eixo, e um diret rio. A escala associada ao eixo X uma lista contendo as abcissas em que as retas paralelas ao eixo Y cruzam o eixo X e similarmente para a outra escala. O diret rio uma matriz bidimensional, com as mesmas dimens es da grade, tal que cada elemento do diret rio corresponde a uma c lula e aponta para a p gina f sica ou bucket que cont m todas as coordenadas dos pontos localizados na c lula. V rios elementos podem apontar para a mesma p gina f sica. As escalas e o pr prio diret rio, se forem estruturas de dados pequenas, poder o residir em mem ria principal; caso contr rio dever o ser por sua vez paginados.
buckets
y3
y2
y1
escalas x1 x2 x3 x4
Figura 9.1: Estrutura de um arquivo em grade. Suponha, por exemplo, que as escalas e o diret rio residam em mem ria principal e que se deseje recuperar todos os pontos contidos em uma dada regi o. Neste caso, utiliza-se inicial mente as escalas para computar que c lulas cobrem a regi o; em seguida, atrav s do diret rio, obt m-se os endere os das p ginas f sicas associadas s c lulas; nalmente, l -se as p ginas
9.4. ARMAZENAMENTO E INDEXA O DE REPRESENTA ES VETORIAIS
121
f sicas contendo pontos e seleciona-se aqueles que de fato est o contidos na regi o dada. A refer ncia NHS84 descreve em detalhe as opera es sobre arquivos em grade. Uma rvore kd tamb m particiona o espa o em c lulas, mas de uma forma diferente dos arquivos em grade, conforme ilustrado na gura 9.2. A rvore kd uma rvore de busca bin ria, residindo em mem ria principal, tal que os n s interiores em cada n vel cont m valores referentes a um nico eixo, X ou Y , alternadamente, e as folhas apontam para p ginas f sicas. V rias folhas podem apontar para a mesma p gina f sica. Assim, o valor armazenado na raiz divide o espa o em dois subespa os atrav s de uma reta perpendicular ao eixo dos X , digamos; o valor armazenado no lho esquerda ou direita por sua vez divide o subespa o esquerda ou direita em dois subespa os atrav s de uma reta perpendicular ao eixo dos Y ; e assim por diante, alternando as dimens es. O processo de subdivis o p ra quando a c lula cont m um conjunto de pontos que possa ser armazenado em uma nica p gina f sica. C
r r
C
r
A D
r
Figura 9.2: Particionamento do espa o determinado por uma rvore kd Tanto os arquivos em grade quanto as rvores kd podem ser generalizados para espa os de dimens o superior a 2 de fato o pr prio nome desta segunda estrutura sugere um espa o k-dimensional. H um n mero substancial de variantes de rvores kd reportadas na literatura, como as rvores KDB Rob81 , que generalizam as rvores B, as rvores LSD AHW89 para local split decision, que permitem escolher a cada n vel qual dimens o ser dividida. Outros m todos de armazenamento e indexa o de conjuntos de pontos s o, por exemplo, EXCELL Tam82 , buddy hash trees SK90 , BANG Files Fre87 e as hB-trees hole brick trees LS89 .
9.4.2 Ret ngulos

Nesta se o abordaremos tr s enfoques para o armazenamento e indexa o espacial de con juntos de ret ngulos: transforma o de ret ngulos em pontos; decomposi o do espa o com superposi o; e retalhamento de ret ngulos. Maior nfase ser dada ao segundo enfoque. O primeiro enfoque consiste em transformar um ret ngulo de duas dimens es em uma qu drupla um ponto de 4 dimens es e utilizar um m todo de armazenamento e indexa o espacial de qu druplas, como arquivos em grade e rvores kd quadri-dimensionais. De fato, um ret ngulo est perfeitamente de nido por qu druplas indicando a abcissa e ordenada dos dois pontos extremos de uma diagonal, ou a base, altura e o seu ponto central. Este enfoque,
122
embora elegante e simples, apresenta problemas de desempenho s rios, discutidos em detalhe em PST93 . O segundo enfoque abandona a id ia de decompor o espa o em regi es que n o se superp em e utiliza a no o de ret ngulo envolvente. O ret ngulo envolvente m nimo r.e.m. de um conjunto de objetos no R2 o menor ret ngulo com lados paralelos aos eixos X e Y que cont m todos os objetos no conjunto.
D A M N
F E L C
G H
K J B I
DEFG
, , ,, ,
ABC
H I J K
@@ @@ @
LMN
Figura 9.3: Exemplo de uma rvore R . O melhor exemplo deste enfoque s o as rvores R Gut84 , ilustradas na gura 9.3. Dados dois inteiros m 1 e n 1, uma rvore R de ordem m; n uma rvore de busca balanceada tal que: todas as folhas est o no mesmo n vel;
123
cada folha N cont m entre dn=2e e n ret ngulos. O r.e.m. de N o r.e.m. do conjunto de todos os ret ngulos armazenados em N . cada n interior cont m entre dm=2e e m lhos, exceto a raiz, que cont m entre 2 e m lhos. cada n interior N cont m uma entrada para cada lho M , consistindo de um ponteiro para M e o r.e.m. de M . O r.e.m. de um n interior N o r.e.m. do conjunto de todos os r.e.m. associados a entradas de N . Todos os ramos de uma rvore R possuem o mesmo comprimento, ou seja, todas as folhas est o no mesmo n vel, como numa rvore de busca balanceada. Esta propriedade mantida atrav s de estrat gias especiais de inser o e remo o, semelhantes s de rvores B. Resumi damente, a inser o de uma nova entrada em um n N que j possua o n mero m ximo de entradas provoca a sua divis o, cando N com metade ou metade mais uma das entradas, e criando-se um novo n N 0 com a outra metade; uma entrada referente ao novo n N 0 inserida recursivamente no pai de N . A remo o segue o processo inverso, podendo dois n s serem combinados, recursivamente. O processo de busca guiado pelos ret ngulos armazenados nos n s. Por exemplo, voltando gura 9.3, para se determinar quais ret ngulos cont m o ponto P , procede-se da seguinte forma. Observa-se inicialmente que os ret ngulos A e B , armazenados na raiz, cont m P ; estes ret ngulos correspondem ao primeiro e ao segundo lho da raiz. Em seguida, repete-se o processo descendo-se por estes n s. Assim, descendo-se pelo primeiro lho da raiz, observa-se que o ret ngulo G cont m P e acrescenta-se este ret ngulo resposta. Descendo-se pelo segundo lho da raiz, observa-se que nenhum ret ngulo a armazenado cont m P . Cada ret ngulo do conjunto original est armazenado em apenas uma folha da rvore R. Por m, para cada n vel da rvore, os ret ngulos contidos nos n s daquele n vel podem se superpor. Na gura, por exemplo, os ret ngulo A e B contidos na raiz se superp em. Isto signi ca que uma busca pode ser obrigada a descer por mais de um ramo da rvore. De fato, os ret ngulos armazenados em uma rvore R n o induzem uma parti o do espa o pois poss vel ocorrer tanto superposi o de ret ngulos quanto haver regi es do espa o n o cobertas por nenhum ret ngulo. Al m disto, a decomposi o do espa o din mica, podendo ser modi cada a cada inser o ou remo o de um ret ngulo. Assim, para otimizar o processo de pesquisa, torna-se importante minimizar a superposi o dos ret ngulos armazenados nos n s interiores. Das v rias estrat gias encontradas na literatura, a proposta em BKSS90 , gerando as chamadas rvores R , aparece como a mais e ciente. Por m, o terceiro enfoque mant m a id ia de decompor o espa o em regi es que n o se superp em. Por m, cada ret ngulo ao ser inserido retalhado em um conjunto m nimo de ret ngulos tal que: os ret ngulos n o se superp em; a uni o dos ret ngulos reconstr i o ret ngulo original; cada ret ngulo intercepta exatamente uma das regi es em que se decomp e o espa o. Este enfoque permite adaptar, usando ret ngulos, qualquer m todo desenvolvido para arma
124
zenar e acessar pontos. Ele permite ainda utilizar uma s estrutura de dados para armazenar, ao mesmo tempo, pontos e ret ngulos. Por outro lado, resulta na replica o de objetos na estrutura, pois a inser o de um nico ret ngulo acarreta a inser o de uma entrada para cada regi o que intercepta. Isto complica os processos de inser o e remo o, al m de implicar em mais espa o de armazenamento. As rvores R+ SRF87 s o uma variante de rvores R em que, ao se inserir uma nova entrada, se o seu ret ngulo intercepta os ret ngulos de dois ou mais n s, o ret ngulo recortado como anteriormente descrito e cada um dos novos ret ngulos inserido nos n s apropriados, como ilustrado na gura 9.4.
D A M N
F E P L C
G H
K J B I
DEFG
ABCP ! aaa ! , @ ! ! ! ,, @@ aaaa ! ! aaa !!! , @ ! a , @ I JK LMN GH
Figura 9.4: Exemplo de uma rvore R+ A inser o e a remo o de entradas um processo bem mais complexo nas rvores R+ do que nas rvores R. Os ret ngulos inseridos tendem a se dividir para evitar superposi o, aumentando o tamanho da rvore. De fato, ao contr rio das rvores R, a inser o de uma nova entrada nesta
125
estrutura pode desencadear recursivamente uma multiplicidade de inser es. Compara es de desempenho entre rvores R+ e rvores R podem ser encontradas em CFR87 .
9.4.3 Linhas Poligonais

O armazenamento e indexa o espacial de conjuntos de linhas pode ser abordado adaptando-se os m todos utilizados para pontos e ret ngulos. Dentro da estrat gia de decompor o espa o em regi es que n o se superp em, cada linha quebrada em um conjunto m nimo de novas linhas tal que: as novas linhas n o se superp em; a uni o das novas linhas resulta na linha original; cada nova linha intercepta exatamente uma das regi es em que se decomp e o espa o. Este enfoque permite adaptar para linhas qualquer m todo desenvolvido para armazenar e acessar pontos. Pode gerar, por m, para cada linha, m ltiplas entradas na estrutura de dados adotada, com as mesmas conseq ncias para os pro cessos de inser o e remo o, e desperd cio de espa o de armazenamento, j observados para ret ngulos. Dado um conjunto de linhas, um segundo enfoque consiste em aproximar cada linha pelo seu ret ngulo envolvente m nimo e utilizar um dos m todos discutidos anteriormente para armazenar e acessar os ret ngulos assim gerados. Por exemplo, adotando-se rvores R, cada folha passa a conter como entradas um apontador para uma linha e seu ret ngulo envolvente m nimo. Este enfoque n o apropriado, por m, para o caso de linhas muito longas ou, em geral, quando o ret ngulo envolvente m nimo n o resulta em uma boa aproxima o para as linhas. Este ltimo problema resolvido utilizando-se as rvores V e VR, descritas no resto desta se o. Dados dois inteiros m 1 e n 1, uma rvore V de ordem m; n para armazenar uma linha L constru da da seguinte forma. A linha L quebrada em fragmentos consecutivos, de tamanho entre n=2 e n, que s o aproximados pelo seu ret ngulo envolvente m nimo. Esta exibilidade no n mero de pontos por fragmento permite remover e adicionar pontos posterior mente, mantendo as caracter sticas da estrutura resultante. Durante o processo de quebrar a linha em fragmentos, o ltimo ponto de cada fragmento torna-se o primeiro do pr ximo fragmento de tal forma que os ret ngulos envolventes cobrem a linha completamente. Uma rvore R de ordem m; n ent o constru da a partir dos ret ngulos envolventes m nimos dos fragmentos e considerando que suas folhas armazenam os pr prios fragmentos. A estrutura de dados resultante ser ent o a rvore V de ordem m; n para L. Um conjunto de linhas armazenado da seguinte forma. Cada linha armazenada em uma rvore V separada e aproximada pelo seu ret ngulo envolvente m nimo; o conjunto destes ret ngulos ent o armazenado em uma rvore R, cujas folhas apontam para as ra zes das rvores V. A estrutura resultante, composta desta rvore R e das v rias rvores V, forma ent o uma rvore VR. Ao fragmentar as linhas, este m todo resolve o problema de armazenar conjuntos de linhas muito longas, facilitando o acesso a partes das linhas, bem como mudan as para escalas menores
126
por exemplo, de 1:250,000 para 1:1,000,000. Uma an lise mais detalhada do m todo pode ser encontrada em MCD94 .
9.4.4 Pol gonos

O armazenamento e indexa o de pol gonos pode ser tratado, de forma simplista, como um caso particular do tratamento de linhas. Esta ltima parte do cap tulo aprofunda a discuss o abordando m todos de armazenamento e indexa o de pol gonos que se baseiam no uso de aproxima es para a geometria dos pol gonos e na decomposi o dos pol gonos em pol gonos simples. O uso de aproxima es evita testes geom tricos complexos, enquanto que as t cnicas de decomposi o simpli cam e aceleram tais testes. Para que uma aproxima o da geometria de um pol gono seja til ao processamento de con sultas, ela deve ser conservativa, ou seja, deve conter completamente o pol gono. O ret ngulo envolvente m nimo r.e.m. de um pol gono, por exemplo, oferece uma aproxima o bastante simples e c moda. De fato, dado um conjunto de pol gonos, podemos criar os r.e.m.s dos pol gonos e utilizar quaisquer dos m todos de armazenamento e indexa o de ret ngulos descritos anteriormente para tratar o conjunto de pol gonos. Assim, qualquer consulta espacial Q ao conjunto de pol gonos inicialmente transformada em uma consulta espacial Q0 ao conjunto de r.e.m.s de tal forma que o resultado de Q0 identi que todos os pol gonos que possivelmente satisfazem Q; estes pol gonos devem ent o sofrer um p s-processamento para separar aqueles que realmente satisfazem Q. Decompor um pol gono signi ca divid -lo em v rias componentes simples - tri ngulos, tra p zios, e outros - de tal forma que, durante o processamento de uma consulta espacial, apenas um pequeno n mero destas componentes precise ser examinado. Assim, cada pol gono sofre inicialmente uma decomposi o em elementos geom tricos mais simples, que s o ent o armaze nados atrav s de um m todo apropriado. Note que as rvores V discutidas na se o anterior de fato aplicam s linhas esta id ia de decomposi o. Para completar esta se o, descreveremos o m todo de decomposi o por grades que combina diretamente as id ias de aproxima o e decomposi o. Considere o espa o dividido hierarqui camente em c lulas regulares. As c lulas geradas a cada n vel podem ser colocadas em z-ordem Ore86 atrav s do processo de intercala o de bits, proposto originalmente por Morton Mor66 . Na gura 9.5, o diagrama esquerda indica a z-ordem imposta aos 4 quadrantes no primeiro n vel da divis o hier rquica do espa o. O diagrama direita ilustra o n vel seguinte: em cada quadrante, as c lulas s o conectadas em z-ordem e depois os grupos de c lulas de cada um dos quatro quadrantes s o novamente conectados em z-ordem. Cada c lula em cada n vel da hierarquia possui um endere o dado por uma cadeia de bits cujo comprimento corresponde ao n vel ao qual a c lula pertence. Por exemplo, o endere o `1110' da c lula hachurada direita da gura foi obtido intercalando-se os bits da sua abcissa `11' com os bits da sua ordenada `10'. A z-ordem das c lulas tende a manter pr ximas c lulas que s o tamb m pr ximas espacialmente. Cada pol gono aproximado pelo menor conjunto de c lulas, de qualquer n vel, que cobre completamente o pol gono, at um certo n vel de subdivis o de nido pela precis o desejada,
127
11 1 01 11 10
01 0 00 10 00
00
01
10
11
Figura 9.5: Exemplo de z-ordem conforme ilustrado na gura 9.6. Os endere os das c lulas assim obtidas formam o conjunto de z-elementos associado ao pol gono Ore86 . Um conjunto de pol gonos ent o representado por um conjunto de conjuntos de z-elementos, armazenados em um ndice convencional, como por exemplo uma rvore B. Este ndice convencional pode ent o ser utilizado para otimizar v rias opera es espaciais sobre o conjunto original de pol gonos Ore89 .
10010
100110
1000
Figura 9.6: Exemplo da decomposi o de um pol gono em c lulas.
9.4.5 Representa es Vetoriais Complexas

Todos os m todos de armazenamento e indexa o discutidos at o momento cobrem apenas os objetos vetoriais mais elementares - pontos, ret ngulos, linhas e pol gonos. Esta se o discute como compor tais m todos para armazenar representa es vetoriais complexas, utilizando como exemplo mapas tem ticos. Maiores detalhes podem ser encontrados em BHKS93, Med95 . Recorde que a geometria de uma representa o por sub-divis o planar de nida por um
128
conjunto de pol gonos que particionam o espa o de interesse, ou seja, que n o se sobrep em e que cobrem completamente o espa o de interesse. Por simplicidade, introduz-se uma regi o exterior ct cia que circunda completamente o espa o de interesse. Este conjunto de pol gonos pode ser completamente de nido por um conjunto de pontos, chamados de v rtices, e por um conjunto de linhas, chamadas de arestas, tais que: cada linha come a e termina em um v rtice que pode ser o mesmo, no caso de linhas fechadas; duas linhas s se tocam nos v rtices; cada linha possui uma regi o esquerda e uma regi o direita, uma das quais podendo ser a regi o exterior. As opera es t picas sobre uma representa o por sub-divis o planar exigem que se deter mine, dado um ponto arbitr rio, a que regi o ele pertence e, dada uma linha arbitr ria, que arestas ela cruza e em que pontos. Estas opera es e outras podem ser otimizadas escolhen do-se m todos de indexa o apropriados para os pol gonos, v rtices e arestas que comp em o mapa tem tico. Para otimizar ainda mais o processamento, as entradas nas v rias estruturas podem ser modi cadas para inclu rem refer ncias cruzadas entre si. Por exemplo, uma entrada correspondente a um v rtice apontaria tamb m para as entradas na estrutura armazenando arestas correspondentes s arestas que come am ou terminam no v rtice. Esta descri o sucinta n o torna clara, por m, a quest o do armazenamento em si das representa es exatas dos objetos espaciais. Na se o 10.3.2, discute-se que o esquema de armazenamento em mem ria secund ria de ve equacionar tanto o problema de espa o de armazenamento dos objetos espaciais quanto o problema de contig idade f sica. No caso de representa es por sub-divis o planar estes dois problemas podem ser resolvidos, por exemplo, armazenando os v rtices e arestas, com toda informa o complementar, em p ginas f sicas separadamente dos ndices. Cada p gina f sica conteria ent o tanto v rtices quanto arestas. Para garantir contig idade f sica, pode-se inde xar o pool de p ginas f sicas atrav s de uma outra rvore R, aproximando cada p gina pelo ret ngulo envolvente m nimo de todos os objetos nela armazenados, e determinando em que p gina um objeto ir residir atrav s de uma pesquisa na rvore. Se o crit rio de divis o dos n s da rvore R for cuidadosamente de nido, objetos geogra camente pr ximos ser o direcionados para p ginas pr ximas quando da sua inser o. A refer ncia Med95 cont m um tratamento detalhado do armazenamento de representa es por sub-divis o planar que se preocupa com estes problemas.
Cap tulo 10 Processamento de Transa es e Consultas

10.1 Introdu o
Este cap tulo aborda dois aspectos da implementa o de um sig: ger ncia de transa es e otimiza o de consultas. Este dois assuntos foram escolhidos por necessitarem de solu es distintas daquelas empregadas em sistemas convencionais. De fato, sistemas convencionais tratam apenas de transa es que t m curta dura o, quando usu rios trabalham isoladamente. No caso de aplica es de Geoprocessamento, a intera o com o banco de dados comumente mais longa exigindo uma revis o dos mecanismos de controle de transa es, principalmente a cria o de mecanismos para versionamento, atualiza o cooperativa e bloqueio parcial de objetos. H bem poucas refer ncias sobre ger ncia de transa es para o caso espec co de aplica es de Geoprocessamento BK91 . Por m, o padr o de transa es para estas aplica es semelhante s chamadas transa es longas e aninhadas, t picas de ambientes de desenvolvimento de software VM90, PS90 , ambientes de projeto de VLSI BK85, CK86 e hipertexto SCR93 , entre outros. A se o 10.2 baseia-se em parte nas refer ncias DGM95, SCR93 . Os problemas de otimiza o de consultas a bancos de dados geogr cos possuem alguma semelhan a com aqueles estudados no contexto de bancos de dados cient cos Gra93 ou ban cos de dados orientados a objetos Cou92, JBG93 . Pol ticas espec cas para otimiza o de consultas a bancos de dados geogr cos podem ser encontradas em AS91, Ooi90 , que tra tam separadamente a componente espacial da parte convencional das consultas. A refer ncia Kri91 discute o efeito de v rias t cnicas de ltragem sobre o processamento de consultas. J a refer ncia HS92b trata de consultas sobre segmentos de linhas e a refer ncia Rot91 aborda m todos de jun o espacial. SFGM93, Cif95 prop em benchmarks para consultas espaciais e KBS93 analisa a in u ncia do efeito da forma do pol gono envolvente na ltragem. As refe r ncias FK93, KF92, BKS93, BKSS94, HS94, WH92 tratam do uso de estruturas distribu das em ambientes paralelos para otimiza o de consultas. 129
130
CAP TULO 10. PROCESSAMENTO DE TRANSA ES E CONSULTAS
10.2 Ger ncia de Transa es

10.2.1 Transa es em SIG
Em aplica es convencionais de banco de dados, um usu rio modi ca os dados atrav s de uma seq ncia de opera es elementares que devem ser executadas como um todo. As opera es s o tipicamente curtas e envolvem um volume pequeno de dados. Por exemplo, uma transfer ncia de fundos implementada atrav s de duas atualiza es, em contas banc rias distintas, que devem ser ambas executadas ou ambas canceladas, para evitar erros. Esta situa o con gura o que se chama de uma transa o, ou seja, uma seq ncia de opera es que o sistema de ger ncia de banco de dados deve processar at o m, ou garantir que o banco de dados n o re ete nenhuma delas, desfazendo aquelas que tenham sido total ou parcialmente executadas. Al m disto, o sistema deve processar as opera es sem interfer ncia de outras transa es e garantir que, se as opera es come am em um estado consistente do banco de dados, elas terminam em um estado tamb m consistente. Mecanismos para garantir estas propriedades foram amplamente investigados no contexto de aplica es convencionais. Os usu rios de aplica es de Geoprocessamento tamb m executam transa es desta natu reza, principalmente ao modi car os atributos convencionais de objetos. Por m, eles podem apresentar um padr o de comportamento muito diferente, mais pr ximo do encontrado em ambientes de desenvolvimento de software, projeto de circuitos VLSI e cria o de documentos hiperm dia, entre outros. Nestes ambientes, uma equipe de usu rios trabalha cooperativamente para produzir uma nova con gura o dos objetos. Cada usu rio cria uma parte de um todo em v rias etapas, possivelmente trabalhando sobre uma situa o j existente, que n o pode ser congelada. Al m disto, a equipe pode criar con gura es alternativas dos objetos, ou seja, modi ca es que n o necessariamente ser o efetivadas. O conjunto de modi ca es criado pela equipe de usu rios con gura uma transa o longa e aninhada. Neste contexto, o termo sess o de trabalho freq entemente utilizado como sin nimo de transa o. A transa o longa pois normalmente o trabalho da equipe se desenvolve por muito tempo, possivelmente semanas. Ela cooperativa porque envolve modi ca es criadas por usu rios distintos, de forma coordenada. Finalmente, a transa o pode conter cole es com pletas de modi ca es organizadas em subtransa es aninhadas. Informalmente, uma transa o T cont m uma subtransa o aninhada T 0 quando um parte das opera es de T agrupada e tratada como uma transa o T 0 de tal forma que as opera es em T 0 possam ser desfeitas ou refeitas pelo sistema como um todo, ou tornadas condicionalmente vis veis a outros usu rios. Por exemplo, considere um banco de dados geogr co contendo dados sobre topogra a, vegeta o, reas de preserva o ambiental e rede vi ria de uma regi o. Suponha que uma equipe de dois engenheiros esteja desenvolvendo o tra ado de um novo oleoduto, cada um trabalhando em trechos diferentes e cont guos do oleoduto. Este projeto envolve ent o trabalho cooperativo, de longa dura o, sobre os objetos no banco, con gurado como uma nica transa o longa, contendo duas subtransa es aninhadas, uma para cada membro da equipe. Este exemplo ser elaborado de forma um pouco diferente na se o 10.2.3.
10.2. GER NCIA DE TRANSA ES
131
10.2.2 Mecanismos para Implementa o de Transa es

Esta se o discute alguns mecanismos gen ricos propostos para implementa o de transa es com as caracter sticas descritas na se o anterior, incluindo tratamento de vers es. Estes me canismos s o implementados no Subsistema de Manipula o, discutido na se o 8.2, e ativados atrav s de opera es espec cas pertencentes interface deste subsistema. A descri o segue DGM95, SCR93 . Esta se o opcional, podendo o leitor passar diretamente para a se o 10.2.3. Paralelamente aos mecanismos so sticados para manipula o de dados, descritos abaixo, o usu rio poder ainda manipular diretamente tais dados, para cobrir casos simples como, por exemplo, atualiza o do valor de um atributo convencional. Em geral, um ambiente para trabalho cooperativo deve permitir tanto compartilhamento de conjuntos de dados entre usu rios quanto a de ni o de conjuntos privativos a um grupo de usu rios. Para tanto, supomos que os dados est o organizados em uma hierarquia de bancos de dados e que cada dado s pertence a um destes bancos. Se B 0 lho de B na hierarquia, dizemos que B 0 um banco subordinado a B . Note que a hierarquia possui um n mero arbitr rio de n veis. Cada banco est associado a um grupo de usu rios com permiss o para realizar um certo conjunto de opera es sobre os dados no banco ou em bancos subordinados a ele. Esta hierarquia de bancos re ete o fato de transa es conterem outras transa es aninhadas. Assim, um grupo de usu rios 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 transa es aninhadas conduzidas por subgrupos de usu rios. Ortogonalmente a estes conceitos, consideramos que um dado pode estar em um de tr s es tados: pronto, em trabalho ou obsoleto respectivamente, committed, uncommitted ou obsolete. Um dado d pode ainda estar associado a um conjunto de outros dados, tratados como suas vers es, e organizados sob forma de uma rvore, onde d a raiz. Esta rvore mantida de tal forma que, se uma vers o est pronta, todos os seus ancestrais na rvore tamb m est o prontos; e, se uma vers o obsoleta, todos os seus descendentes tamb m s o obsoletos. Os dados s o manipulados atrav s do elenco de opera es descritas a seguir. A opera o update permite atualizar um dado em trabalho, sem alterar o seu estado. A opera o commit transforma em pronto um dado em trabalho. A opera o delete remove um dado d de um banco B . Se d for um dado em trabalho, ele efetivamente destru do; se d for um dado pronto, ele tornado obsoleto. O usu rio tamb m pode remover um banco B , provocando a remo o 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 tr s opera es para cria o de dados: create cria um dado d0 completamente novo em um banco B 0; create-version cria uma nova vers o d0 de um dado d pronto ou em trabalho no mesmo banco de dados B 0 que cont m d; check-out cria um novo dado d0 em B 0 como uma vers o de um dado pronto d existente em B , onde B 0 um banco subordinado a B . O usu rio
132
tamb m poder utilizar esta opera o para criar em bloco vers es de um conjunto de dados. Note que o usu rio n o pode mover d de B para B 0, mas apenas usar a opera o check-out para criar uma vers o d0 de d em B 0. Em todos estes tr s casos, d0 considerado um dado em trabalho ap s a sua cria o. A opera o check-in permite mover um dado pronto d0 de um banco B 0 para o banco B a que B 0 se subordina. O usu rio tamb m poder utilizar esta opera o para mover em bloco um conjunto de dados de um banco para outro. H duas variantes desta opera o. A primeira delas, check-in de adi o, de fato move d0 de B 0 para B , exceto se d0 for uma vers o de um dado d existente em B e d0 n o tiver sido modi cado, caso em que d0 descartado, evitando assim a cria o de uma r plica de d em B . A segunda, check-in por substitui o, move d0 de B 0 para B , se d0 for um novo dado, ou move d0 de B 0 para B e remove o dado d existente em B atrav s da opera o delete, se d0 for uma vers o de d e d0 tiver sido modi cado. Esta ltima opera o corresponde portanto tradicional opera o de atualiza o. Estas opera es mant m as rvores de vers es consistentes atrav s de a es colaterais. As sim, a opera o commit aplicada a um dado se propaga recursivamente para todos os seus ancestrais na rvore, transformando-os tamb m de dados em trabalho para prontos. A opera o 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 tamb m por uma opera o de check-in por substitui o ao chamar implicitamente uma opera o delete. Note que as rvores de vers es cruzam a hierarquia de bancos de dados. Portanto, quando um usu rio executa uma opera o 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 usu rio dever possuir permiss o para executar commit tamb m sobre dados nestes outros bancos. Por m, a opera o delete n o causa problemas. Por de ni o, se o usu rio possui permiss o para aplicar a opera o de delete sobre dados de B , ele tamb m possui permiss o para aplicar delete a dados em bancos subordinados a B , recursivamente. A mesma observa o se aplica opera o de check-in por substitui o. Assim, como efeito colateral de uma opera o sobre um dado d, um usu rio poder interferir com bancos de dados de outros usu rios que cont m vers es de d. Para minimizar este problema, podemos lan ar m o de mecanismos de controle de acesso, permitindo o bloqueio de dados em tr s modos: compartilhado, exclusivo e vers o-exclusivo. Quando um usu rio ou grupo de usu rios bloqueia um dado em modo compartilhado, ele indica uma potencial inten o de substitu -lo por outra vers o; em modo exclusivo, ele pro be outros usu rios de substitu -lo por outra vers o; em modo vers o-exclusivo, ele pro be outros usu rios de criar vers es do dado. Este recurso se integra s opera es descritas anteriormente da seguinte forma. Em uma opera o de check-out que cria um novo dado d0 em B 0 como uma vers o de um dado d em B , d bloqueado em modo compartilhado para o usu rio que executa a opera o. Ao executar um check-in por substitui o sobre d0, se d0 tiver sido modi cado, o bloqueio de d escalonado para o modo exclusivo e os outros usu rios que possu am bloqueios compartilhados sobre d t m seus bloqueios descartados. Isto os impede de retornar vers es de d, for ando-os a refazer o
10.2. GER NCIA DE TRANSA ES
133
check-out, agora sobre d0 dado que substituiu d. Esta discuss o simpli cada pois n o explora em detalhe as refer ncias cruzadas entre dados, quer seja porque um dado uma componente de outro, quer seja porque h um relacio namento expl cito entre ambos. A refer ncia DGM95 descreve como este problema resolvido no contexto do sistema sagre abordado no cap tulo 12. No entanto, ela tampouco considera a cria o de vers es ou o bloqueio de partes de um conjunto de dados. Esta extens o particu larmente importante pois geo-objetos ou geo-campos freq entemente cobrem reas geogr cas maiores do que a regi o de interesse do usu rio. A se o seguinte apresenta um exemplo de mo di ca o de um banco de dados geogr co que utiliza extens es das opera es acima descritas cobrindo este ponto.
10.2.3 Exemplo
Considere um banco de dados geogr co B contendo, para o Estado do Rio de Janeiro, um geo-campo T capturando a sua topogra a, uma cole o de geo-objetos, chamada de reas-de-prote o, cujos elementos descrevem as reas de prote o, representadas em uma representa o por subdivis o planar P , e duas cole es de geo-objetos, rede-vi ria e oleodutos, com a descri o das estradas e oleodutos, cujas localiza es encontram-se em uma representa o complexa V . Suponha agora que uma equipe tenha sido designada para elaborar uma proposta para um oleoduto do terminal da Petrobr s no Munic pio de Angra dos Reis para o Porto de Sepetiba, sem cruzar reas de prote o ambiental e aproveitando ao m ximo os cortes j feitos para as estradas. O trabalho da equipe con gura uma transa o longa e cooperativa, constru da interativamente da seguinte forma. Inicialmente a equipe de ne uma janela R cobrindo toda a regi o de trabalho. Em seguida, de ne o banco de dados privado B 0 e cria, atrav s da opera o check-out, vers es TR e VR dos objetos T e V apenas para a regi o R e uma vers o OL de oleodutos. Suponha que a equipe tenha permiss o apenas para consultar as cole es reas-de-prote o e rede-vi ria e a representa o P . Em seguida, a equipe de ne o oleoduto, inserindo um novo geo-objeto O em OL, e alterando VR para incluir a representa o de O. A equipe tamb m modi ca o geo-campo TR para indicar os novos cortes necess rios passagem do oleoduto mas n o modi ca P , por restri es de projeto. Ao t rmino, a equipe introduz o resultado do projeto no banco original B atrav s da opera o de check-in por substitui o, estendida para tratar de vers es que se referem a apenas uma parte da rea geogr ca coberta pelos objetos. Em paralelo, uma segunda equipe poder estar trabalhando no tra ado de uma nova estrada no Munic pio de Angra dos Reis, com restri es semelhantes s anteriores: a estrada n o poder cruzar reas de prote o ambiental e dever aproveitar ao m ximo os cortes j feitos para oleodutos.
134
Novamente, a equipe de ne uma janela S cobrindo sua regi o de trabalho e de ne o banco de dados privado E , criando atrav s da opera o check-out vers es TS e VS dos objetos T e V apenas para a regi o S e uma vers o RV de rede-vi ria. De forma semelhante, esta equipe de ne a estrada, inserindo um novo geo-objeto E na cole o RV , e alterando VS para incluir a representa o de E , e o geo-campo TS para indicar novos cortes necess rios passagem da nova estrada. Ao t rmino, a equipe tentar introduzir o resultado deste segundo projeto no banco original B atrav s da opera o de check-in por substitui o. Duas situa es poder o ocorrer. Se as regi es R e S forem disjuntas, ent o o trabalho de uma equipe n o afeta diretamente o da outra e a altera o do banco B ocorrer normalmente. Por m, a implementa o da opera o de check-in por substitui o dever ser su cientemente so sticada para alterar V e T apenas para a regi o S de tal forma que n o destrua as modi ca es efetuadas nestes campos pela equipe que criou o oleoduto. J se as regi es R e S n o forem disjuntas, o trabalho de uma equipe potencialmente afeta o da outra. guisa de ilustra o, fa amos uma an lise mais detalhada desta situa o. A primeira equipe altera V acrescentando a representa o de O e a segunda acrescentando a representa o de E . Portanto, se o sistema versionar as componentes de V , e n o V como um todo, ser simples implementar a opera o de check-in por substitui o de tal forma que o trabalho de uma equipe n o inter ra 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 necess rio analisar a representa o utilizada para T . Por exemplo, se a representa o for por isolinhas, ser necess rio versionar as isolinhas em si; assim uma equipe n o interferir com a outra se alterarem isolinhas distintas. Naturalmente, toda esta discuss o sobre a opera o de check-in por substitui o afetada pelos mecanismos de controle de acesso, que tamb m dever o ser revistos para acomodar os re namentos baseados no uso de regi es ou de componentes.
10.3 Processamento de Consultas

10.3.1 Tipos de Consultas
A e c cia das estrat gias de otimiza o de consultas e dos m todos de armazenamento e inde xa o das componentes espaciais dos dados geogr cos depende fundamentalmente do tipo e freq ncia das consultas e opera es em geral submetidas a bancos de dados geogr co. Em bora estes fatores dependam da aplica o em quest o, esta se o sugere uma classi ca o das consultas e opera es bastante til para o estudo do problema, seguindo BHKS93 . Podemos separar de um lado as opera es de atualiza o - inser o, remo o e modi ca o - submetidas ao banco de dados geogr co, e de outro lado as consultas espaciais em si. Dentre os tipos de consultas espaciais, destacamos quatro:
10.3. PROCESSAMENTO DE CONSULTAS
135
sele o convencional : dado um conjunto de dados D e de nida uma restri o sobre sele o pontual : dado um ponto P e um conjunto de dados D, determine todos os dados
em D que cont m P .
atributos convencionais dos dados em D, determine todos os dados em D que satisfazem .
sele o por regi o : dada uma regi o R e um conjunto de dados D, determine todos os dados
em D que interceptam ou est o contidos em R. Um subtipo simples e importante a chamada sele o por janela em que a regi o um ret ngulo com os lados paralelos aos eixos. espacial entre pares de dados por exemplo
estar contido em, determine todos os pares de dados d; d0 2 D D0 tais que d e d0 satisfazem .
jun o espacial : dados dois conjuntos de dados, D e D0 , e de nido um relacionamento

A sele o convencional foi inclu da na lista por uma quest o de completude, j que n o envolve a componente espacial. Note que o resultado de consultas de quaisquer um destes tipos retorna um conjunto de dados, ou um conjunto de pares de objetos, retirados do banco de dados geogr co. Existe no entanto uma variante importante da jun o espacial que n o retorna simplesmente pares de objetos:
superposi o de representa es : dados dois conjuntos de dados D e D0 e um crit rio de superposi o , determine todos os pares de dados d; d0 2 D D0 tais que d e d0 se
superp em e crie um novo dado para cada par conforme o crit rio de superposi o . O resultado da opera o consiste nestes novos dados.
10.3.2 Estrat gia para Processamento de Consultas

Conforme a discuss o do cap tulo 8, dada uma consulta sobre um banco de dados geogr co, o Subsistema de Manipula o sm cont m um otimizador de consultas que produz um plano de execu o para a consulta consistindo de comandos que ser o executados pelos Subsistemas de Manipula o Convencional smc, Vetorial smv e Matricial smm. O otimizador cont m um componente capaz de gerar planos alternativos para execu o de consultas e uma fun o de custo associando um custo estimado a cada plano. O gerador de planos incorpora ainda heur sticas que limitam o espa o de busca, evitando uma explos o combinatorial de planos alternativos. Tipicamente, a parte do plano respons vel pelo processamento da componente espacial da consulta cont m tr s fases Ore89, Kri91 : Fase 1: Filtragem Um banco de dados geogr co normalmente cont m estruturas de dados auxiliares, cha madas de ndices espaciais ou estruturas de indexa o espacial que facilitam a localiza o dos
136
dados cuja componente espacial satisfaz quali ca o de uma consulta. Reservamos o termo m todo de indexa o espacial para designar uma fam lia de estruturas de indexa o espacial. De fato, diversos m todos de indexa o espacial foram discutidos no cap tulo 9. O desempenho deste passo depende da distribui o espacial dos dados e da forma como a estrutura decomp e o espa o, sendo que em geral baixo o fator de seletividade CHF93b . Dada a complexidade da componente espacial e da sem ntica dos pr prios operadores espa ciais, em geral os ndices trabalham apenas com aproxima es das componentes espaciais por exemplo, o ret ngulo m nimo envolvente. Assim, o uso de ndices para resolver a parte espacial de uma consulta apenas ltra, dos conjuntos de dados armazenados no banco de dados, aqueles que certamente n o satisfazem quali ca o da consulta, sendo necess rio um segundo passo. Fase 2: Re namento Uma vez identi cados os dados que se candidatam a satisfazer a quali ca o da consulta, as geometrias exatas das componentes espaciais dos dados s o trazidas para mem ria principal. sobre estas geometrias que s o ent o executados os operadores espaciais especi cados na quali ca o. As estruturas de armazenamento e indexa o devem preferencialmente permitir que seja trazida para mem ria principal apenas a parte das componentes espaciais necess ria execu o dos operadores. O desempenho deste passo depende da quantidade de dados recuperados, da sua complexi dade e do custo dos operadores a aplicar, que em geral elevado. Fase 3: P s-Processamento Depois de identi cados os dados que satisfazem quali ca o da consulta, usualmente necess rio pass -los para as camadas superiores da arquitetura onde sofrer o processamento posterior ou ser o visualizados. Assim, o sistema deve oferecer um mecanismo e ciente para passar a geometria das componentes espaciais dos dados, na sua totalidade ou em parte, para as camadas superiores. Cabe ao Subsistema de Armazenamento F sico saf implementar os m todos de armaze namento, que governam a utiliza o das p ginas f sicas em mem ria secund ria, onde residem tanto as componentes espaciais dos dados quanto os pr prios ndices espaciais. Os Subsistemas de Armazenamento Matricial sam e de Armazenamento Vetorial sav implementam m todos de indexa o espacial e m todos de armazenamento espec cos para as componentes espacias. Estes subsistemas, em conjunto, devem equacionar dois problemas:
espa o de armazenamento: a representa o interna de uma componente espacial pode ne
cessitar um espa o substancial, ocupando mais de uma p gina f sica; contiguidade f sica: as p ginas f sicas de uma mesma componente espacial ou de componen tes cont guas no espa o devem ser vizinhas em mem ria secund ria, diminuindo o custo de acesso. Uma estrat gia para resolver estes problemas consiste em armazenar a geometria exata das
137
componentes espaciais dos dados fora dos ndices, digamos, em um pool comum de p ginas f sicas. Esta forma de armazenamento leva a ndices mais compactos e n o imp e limita es ao tamanho das componentes, resolvendo assim o problema de espa o de armazenamento. Por m, para endere ar o problema de contig idade f sica, necess rio de nir uma estrat gia de ger ncia para o pool de p gina f sicas de tal forma que componentes vizinhas no espa o geogr co tenham as suas geometrias armazenadas em p ginas pr ximas e, idealmente, que permita armazenar nas mesmas p ginas diferentes tipos de geometrias.
10.3.3 Exemplos de Otimiza o de Consultas

Esta se o aborda, por meio de exemplos, o problema de otimiza o de consultas espaciais, luz dos coment rios feitos na se o 10.3.2.
Exemplo de Sele o por Regi o

Considere um banco de dados geogr co sobre cidades brasileiras consistindo de apenas um conjunto de geo-objetos cidades. Para cada cidade do mundo real, h um objeto em ci dades, cujos atributos convencionais correspondem aos dados convencionais da cidade e cuja localiza o dada por um par ordenado indicando a latitude e longitude da cidade; ou seja, a localiza o destes geo-objetos representada por um ponto em coordenadas geogr cas. No que se segue, suporemos que estas coordenadas est o armazenadas junto com o pr prio geo-objeto, embora todas as opera es sobre elas sejam implementadas pelo smv e qualquer ndice espacial sobre cidades seja de responsabilidade do sav. Considere agora a consulta Q, formulada informalmente como:
Q. Selecione o nome e popula o de todas as cidades a menos de 50km da cidade de Belo

Horizonte e com mais de 50 mil habitantes.
Em legal, esta consulta seria de nida atrav s do comando:

SELECT d.nome, d.populacao FROM d Cidade, c Cidade 50 50.000 WHERE c.nome = "Belo Horizonte" and distanced,c and d.populacao
Esta consulta exempli ca uma sele o por regi o, de nida por um c rculo de raio 50km e centro na localiza o geogr ca da cidade de Belo Horizonte. H essencialmente tr s planos de execu o mais plaus veis para esta consulta entre outros poss veis, discutidos a seguir. Considere inicialmente o plano de execu o P1:
P11. Determine a posi o b de Belo Horizonte;
138
P12. Determine o conjunto C 0 de todas as cidades a 50km de b; P13. Determine o subconjunto C de C 0 de cidades com mais de 50 mil habitantes.
As subconsultas P11 e P13 n o envolvem nenhum operador espacial e, portanto, s o subcon sultas convencionais de Q para este plano. J a subconsulta P12 envolve o operador de dist ncia e a nica subconsulta espacial de Q em P1. O processamento de P1 inicia-se ent o com a execu o, pelo smc, da subconsulta conven cional P11, que retorna a localiza o 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, invis vel aos usu rios, que facilite identi car todos os objetos de cidades cuja localiza o esteja a uma certa dist ncia de um dado ponto. Suponha ainda que o ndice espacial seja impreciso para este caso, no sentido de tamb m retornar objetos que n o est o dist ncia especi cada do ponto. Esta imprecis o t pica de m todos de indexa o espacial, conforme ilustrado na se o 9.4.1, e contrasta com os m todos de indexa o tradicionais, que s o tipicamente precisos. O processamento da subconsulta P12, de responsabilidade do smv, segue em tr s passos:
P121. Atrav s de id-cidades, determine que objetos em cidades podem estar a menos de 50km de b, criando o conjunto I ; P122. Leia da mem ria secund ria para a mem ria principal a representa o interna dos objetos indicados por I , criando o conjunto C 00; P123. Determine que elementos de C 00 est o de fato a menos de 50km de b, criando o conjunto C 0.
Para utilizar o ndice id-cidades, no passo P121, e para ler a representa o interna dos ob jetos, no passo P122, o smv invoca o sav. Os elementos de I s o apontadores para a localiza o em mem ria secund ria da representa o interna de objetos em cidades. Al m disto, como supomos que o ndice n o exato, I poder apontar para objetos a mais de 50km de b. J os elementos de C 0 e C 00 s o representa es internas de objetos em cidades, armazenadas em mem ria principal. Assim, o passo P121 corresponde fase de ltragem e P122 e P123, fase de leitura e re namento. O processamento da subconsulta P13 agora simples, bastando extrair de cada elemento de 0 C os valores dos atributos de interesse e eliminando aqueles que n o possuem mais de 50 mil habitantes, criando assim o conjunto C , que a resposta da consulta Q. Os elementos de C ser o pares de valores, correspondendo ao nome e popula o de uma cidade. O processamento de P121, P122, P123 e P3 poder ser concatenado pipelined, ou seja, cada elemento identi cado em P121 imediatamente processado por P122 e ltrado por P123, eventualmente gerando um par em C , ao ser tratado em P13. Isto evita a cria o expl cita dos resultados intermedi rios I , C 0 e C 00, levando a uma razo vel economia no processamento global da consulta. O segundo plano, P2, inverte a ordem de execu o das restri es da consulta Q:

P21. Determine a posi o b de Belo Horizonte; P22. Determine o conjunto C 0 de todas as cidades com mais de 50 mil habitantes; P23. Determine o subconjunto C de C 0 de cidades a 50km de b.
139
Os elementos de C 0 ser o triplas em mem ria principal indicando o nome, popula o e locali za o de objetos em cidades com mais de 50 mil habitantes. O processamento da subconsulta convencional P22 pelo smc ser particularmente e ciente se partirmos do pressuposto que o ban co de dados inclui um ndice convencional sobre cidades, que chamaremos de id-pop, invis vel aos usu rios, que permita identi car todos os objetos de cidades cuja popula o esteja em uma faixa de valores. Tal ndice ser provavelmente preciso, no sentido de retornar exatamente o subconjunto de cidades cuja popula o est na faixa de valores dada. Por m, note que o conjunto C 0 corresponder a todas as cidades brasileiras com mais de 50 mil habitantes. Neste caso, a execu o de P22 d -se da seguinte forma:
P221. Atrav s de id-pop, determine que objetos em cidades possuem popula o com mais de 50 mil habitantes, criando o conjunto J ; P222. Leia da mem ria secund ria para a mem ria principal a representa o interna dos objetos indicados por J , selecionando seu nome, popula o e localiza o e criando o conjunto C 0.
O processamento da subconsulta P23, de responsabilidade do smv, ent o simpli cado, bastando selecionar do conjunto C 0 suposto j em mem ria principal aqueles elementos que est o 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 cria o de J e C 0. O terceiro plano, P3, constr i dois conjuntos independentemente para, em seguida, computar a sua interse o:
P31. P32. P33. P34.
Determine a posi o b de Belo Horizonte; Determine o conjunto C 0 de todas as cidades com mais de 50 mil habitantes; Determine o conjunto C 00 de cidades a 50km de b; Determine a interse o C de C 0 e C 00.
A execu o detalhada deste plano uma combina o da discutida para os dois planos anteriores. At este ponto, descrevemos apenas o detalhamento de tr s planos plaus veis para execu o da consulta. A estimativa do custo de cada plano depende essencialmente de estimar o n mero de objetos identi cados 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 id-cidades for razoavelmente e ciente, ou seja, n o retornar muitas cidades que n o est o a menos de 50km de Belo Horizonte, e se o n mero de cidades brasileiras com mais de 50 mil habitantes for muito grande. Em outras palavras, se a constru o da resposta intermedi ria registrada no conjunto I for mais barata do que a registrada no conjunto J .
140
Exemplo de Jun o Espacial

Suponha agora que o banco de dados geogr co cont m tamb m um conjunto de geo-objetos aeroportos tal que, para cada aeroporto brasileiro, h um objeto em aeroportos cujos atributos convencionais correspondem aos dados convencionais do aeroporto e cuja localiza o dada novamente pela latitude e longitude do aeroporto. Suponha ainda que o banco inclua um ndice espacial sobre aeroportos chamado id-aeroportos, que permita identi car todos os aeroportos cuja localiza o esteja a uma certa dist ncia de um dado ponto. Considere a seguinte consulta
Selecione todas as cidades que s o sede de munic pios e que s o atendidas por aeroportos pavimentados. Esta consulta exempli ca uma jun o 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 ent o:
Q. Selecione o nome de cada cidade e o nome de cada aeroporto tais que a cidade sede de
munic pio, o aeroporto pavimentado e a cidade dista menos de 50km do aeroporto.
Novamente h v rios planos de execu o poss veis para esta consulta, sendo os principais discutidos a seguir. Todos os planos, sob certo aspecto, reduzem o processamento da jun o espacial ao processamento de v rias sele es por regi o. Considere o plano P1 inicialmente:
P11. Determine o conjunto R contendo o nome n e localiza o l de cada aeroporto pavimentado; P12. Inicialize o conjunto C como vazio; P13. Para cada elemento n; l 2 R, fa a: P131. Determine o conjunto dos nomes c de cidades que s o sede de munic pio e que est o a menos de 50km de l, acrescentando o par c; n a C .
O processamento de P1 inicia-se com a execu o, pelo smc, da subconsulta convencional P11, que retorna o nome e a localiza o de todos os aeroportos pavimentados. Para cada um destes, executa-se uma sele o por regi o para determinar as sedes dos munic pios que est o a menos de 50km do aeroporto. O processamento destas sele es segue ent o de acordo com uma das estrat gias discutidas no exemplo anterior. O segundo plano, P2, sim trico a este, recuperando primeiro o conjunto de todas as cidades que s o sede de munic pio para depois determinar quais aeroportos pavimentados est o 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 determina o de qual dos dois planos mais vantajoso depende de qual conjunto for menos numeroso: os aeroportos pavimentados ou as cidades que s o sede de munic pio. O terceiro plano, P3, constr i dois conjuntos independentemente para, em seguida, computar a sua interse o:
141
P31. Determine o conjunto R contendo o nome n e localiza o l de cada aeroporto pavimentado; P32. Determine o conjunto S contendo o nome c e localiza o s de cada sede de munic pio; P33. Determine o conjunto C tal que c; l 2 C sse n; l 2 R e c; s 2 S e a dist ncia de l a s menor do que 50km.
O passo P33 esconde uma itera o 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 condi o imposta. O plano P3 nada mais seria ent o do que uma reformula o do plano P1 . poss vel, 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 m todo de varredura do espa o para computar este passo. Intuitivamente, este m todo consiste em varrer o espa o em uma dada dire o 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

localiza es;
P332. Para cada elemento de menor longitude ainda n o processado, fa a: P3321. Suponha que este elemento seja um par n; l 2 R se for um par c; s 2 S , o
processamento inteiramente semelhante; P3322. Determine todos os pares c; s 2 S tais que a dist ncia 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, discuss o que est fora do escopo deste texto.
Exemplo de Superposi o de Representa es

Considere agora que o banco de dados geogr co cont m dois geo-campos tem ticos, solos e vegeta o, indicando os tipos de solo e de vegeta o do Estado de S o Paulo. Suponha que os geo-campos possuam representa es por subdivis o planar. Suponha ainda, por simplicidade, que as duas representa es utilizem a mesma escala e proje o de tal forma que seja poss vel operar sobre elas sem convers o. Considere agora a consulta Q, formulada como:
Q. Crie um geo-campo tem tico com o remanescente de mata atl ntica em latossolo roxo na regi o B
142
onde B uma janela um ret ngulo de nido por um par ie; sd, no mesmo sistema de coordenadas cartogr cas das representa es, indicando o canto inferior esquerdo e superior direito do ret ngulo. Esta consulta difere das anteriores por criar um campo tem tico a partir de dois outros armazenados no banco de dados, tendo uma restri o dada por um ret ngulo. Discutiremos a execu o de apenas um plano, P1, para esta consulta:
P11. Utilizando solos, crie o campo tem tico solos-b indicando os tipos de solo em B ; P12. Utilizando vegeta o, crie o campo tem tico vegeta o-b indicando os tipos de vege ta o em B ; P13. Crie o campo tem tico veget-rem, resposta da consulta, aplicando uma variante da
opera o de superposi o de campos a solos-b e vegeta o-b;
Como ambos os campos possuem representa o vetorial, a execu o de P1 de inteira responsabilidade do smv, com aux lio do sav. Ao contr rio dos exemplos anteriores em que a otimiza o do plano dependia da exist ncia de ndices espaciais, o processamento ser facilitado aqui se supusermos a exist ncia de estruturas de armazenamento e cientes para as representa es que facilitem recuperar as parcelas das representa es que cobrem o ret ngulo B . Suponha ent o que o sav armazene as representa es envolvidas em estruturas que permitam trazer para mem ria principal apenas as p ginas que cont m os dados de vegeta o ou solos na regi o B ou, pelo menos, em uma regi o B 0 que cubra B e seja signi cativamente menor do que a regi o abrangida pelas representa es. Neste segundo caso, os dados devem sofrer um processo de ltragem no sav antes de passar para o smv. Em uma implementa o mais simples, o sav recuperar as p ginas apropriadas, ltrando-as se necess rio, e materializar as representa es vetoriais dos campos solos-b e vegeta o-b. Sobre estes campos intermedi rios, o smv aplicar ent o a opera o de superposi o de repre senta es apropriada para criar o campo tem tico veget-rem, resposta da consulta. J em uma implementa o mais so sticada, o sav tratar os campos solos-b e vegeta o-b como vis es n o materializadas dos campos originais. Mais explicitamente, quando o smv executar a opera o de superposi o de representa es, o sav recuperar , para mem ria principal, as p ginas contendo os dados de vegeta o ou solos medida que se tornem necess rias para a opera o, sendo de fato criada apenas a representa o do campo tem tico veget-rem.
PARTE IV
143
Cap tulo 11 O Sistema SPRING

11.1 Introdu o
Este cap tulo descreve as caracter sticas principais do spring "Sistema para Processamento de Informa es Georeferenciadas", desenvolvido no inpe, com nfase na vers o 2.0 do sistema. A vers o 1.0 do spring, lan ada em 1993, concretizava o esfor o, levado a cabo no inpe, para desenvolvimento de uma nova gera o de sistemas de Processamento de Imagens e Geopro cessamento. A motiva o b sica para esta iniciativa foi integrar as tecnologias de Sensoriamento Remoto e Sistemas de Informa o Geogr ca, utilizar um modelo de dados orientado a obje tos e fornecer ao usu rio um ambiente interativo para visualizar, manipular e editar dados geogr cos CSFP93 . A vers o 2.0 do spring foi concebida para ser um sig de segunda gera o, trabalhando em um ambiente cliente-servidor e funcionando acoplado a sgbds. Os objetivos desta vers o foram: dar suporte a um banco de dados geogr cos de grande porte, sem estar limitado pelo recorte de proje es cartogr cas; aprimorar a integra o de dados geogr cos, com a introdu o do conceito de modelagem de geo-campos e geo-objetos; obter escalabilidade, sendo o sistema capaz de operar com funcionalidade plena em microcomputadores pessoais e em esta es de trabalho; e prover uma interface que combine aplica es comandadas por menus e uma linguagem de consulta e manipula o espacial. O spring oferece interfaces de janela nos padr es Motif, Windows e SVT
Spring Virtual Toolkit, sendo este ltimo um padr o propriet rio implementado como uma classe virtual que permite a de ni o de elementos de interface. Al m desses, est dispon vel tamb m um m dulo gerador de interfaces, que faz uso do aplicativo X-Designer. Al m do spring, o inpe tamb m disponibiliza uma biblioteca de classes de uso geral, comum para diversas plataformas de mercado, e um ambiente para desenvolvimento e teste de novas tecnologias em sig. A biblioteca de classes, chamada springlib, possui c digo na linguagem C++ multiplataforma, implementando os objetos do modelo conceitual e de representa o como classes C++. A m de garantir seu uso em diversas plataformas, h aplicativos 145
146
CAP TULO 11. O SISTEMA SPRING
Banco de dados geo-refereciados
part-of
part-of
Plano Informao
part-of
No-espacial
Geo-objeto
Geo-campo
Cadastral
is-a
Temtico
is-a is-a
Numrico Rede
is-mapped-in
is-a
Dado Sensor Remoto
Figura 11.1: N vel conceitual do modelo de dados independentes do sistema de janelas adotado e classes que permitem a independ ncia do sgbd adotado. Do ponto de vista do sgbd empregado, o spring v2.0 oferece uma interface seguindo o padr o sql, al m de interfaces com o CodeBase e com o Postgres. O acesso ao banco de dados encapsulado em uma classe espec ca.
11.2 O Modelo de Dados do SPRING

11.2.1 N vel Conceitual
O modelo de dados do spring v2.0 baseia-se em uma vers o preliminar do modelo descrito no cap tulo 4. A Figura 11.1 resume as classes b sicas, a n vel conceitual, do modelo. As classes GeoCampo, Tem tico, Num rico, DadoSensorRemoto, GeoObjeto e ObjetoN oEspacial s o equivalentes s classes hom nimas introduzidas no cap tulo 4. A classe Cadastral foi introduzida para permitir a associa o de representa es m ltiplas de um geo-objeto e armazenar as rela es de topologia entre os geo-objetos representados num mesmo mapa. As inst ncias desta classe de nem um mapeamento de geo-objetos para uma determinada regi o geogr ca e proje o cartogr ca. A classe PlanoInforma o generaliza as classes GeoCampo e Cadastral. Para ilustrar o caso em que mapas cadastrais representam a localiza o de geo-objetos, con sidere o exemplo de um mapa de lotes de uma cidade com duas classes: Lotes, especializa o de GeoObjeto, e MapaLotes, especializa o de Cadastral. No caso dos lotes, a informa
11.2. O MODELO DE DADOS DO SPRING

geoid num_cad IPTU R$ 154 195689 1500 Serimbura, 60 350 Figura 11.2: Exemplo de Atributos para Lotes rea endere o
147
geoid n mero regi o escala ano 345 273 Jardim Esplanada 2000 1986 Figura 11.3: Exemplo de Atributos para MapaLotes
o associada seria o n mero do cadastro na Prefeitura, endere o, rea constru da e valor do IPTU, conforme a gura 11.2. Para os elementos da classe MapaLotes, os atributos t picos seriam as caracter sticas do mapa n mero do mapa, regi o da cidade, escala do mapa, data do levantamento como ilustrado na gura 11.3. Por m, para estabelecer a liga o entre os geo-objetos e suas representa es no exemplo, entre lotes e suas localiza es num mapa de lotes preciso associar os pol gonos ou arcos do mapa cadastral aos geo-objetos descritos anteriormente, como mostra a gura 11.4. Recorde que o modelo de dados contempla ainda a classe ObjetoN oEspacial, que en globa qualquer tipo de informa o que n o seja georeferenciada, e que se queira agregar a um sig. O exemplo, na gura 11.5 mostra o uso deste conceito em uma aplica o de cadastro rural. Neste caso, tem-se os geo-objetos da classe Fazendas que est o localizados num mapa e se deseja estabelecer a liga o entre estes geo-objetos e a informa o alfanum rica constante em um cadastro de propriedades j existente. Estas informa es de cadastro s o consideradas objetos n o espaciais.
Mapa Lotes Lotes geoid 22 22 dono endereco cadas IPTU 250186
Guimaraes C Bevilacqua 768
345
geoid num mapa 345 878
label Esplanada
ano 1986
escala 2000
Figura 11.4: Associa o de geo-objeto a mapa cadastral
148
fazendas geoid 22 area 1500 cadastro INCRA 019331
cadastro INCRA 019331
ITR 12000
dono Olacyr
cadastro
Figura 11.5: Liga o entre geo-objeto e objeto n o espacial
11.2.2 N vel de Representa o

No n vel de representa o, o spring possui duas grandes classes, Representa oVetorial e Representa oMatricial. O spring permite que tanto as representa es matriciais quanto as vetoriais estejam associadas a um mesmo plano de informa o. O sistema distingue as seguintes especializa es da classe Representa oVetorial:
Subdivis oPlanar: conjunto de arcos, n s e pol gonos formando um recobrimento
completo utilizado para mapas tem ticos no formato vetorial; GrafoOrientado: conjunto de arcos e n s conectados sob forma de grafo orientado; Isolinhas: conjunto de linhas, que n o se cruzam, associadas a uma cota utilizado para modelos num ricos de terreno; Amostras3D: conjunto de pontos esparsos, armazenando coordenadas 3D utilizado em modelos num ricos de terreno; GradeTriangular: representa o vetorial formada por tri ngulos, cujos n s possuem coordenadas 3D. As especializa es da classe Representa oMatricial s o:
GradeRegular2D: uma matriz onde cada elemento est associado a um valor real; ImagemTonsCinza: imagem representada atrav s de uma matriz cujos valores corres
pondem quantiza o de uma grandeza num rica. Esta representa o utilizada tanto para dados de sensores remotos como para apresenta es pict ricas de modelos num ricos de terreno; ImagemTem tica: representa o matricial de um geo-campo da classe Tem tico, da da por uma matriz onde cada elemento o ndice em uma tabela que cont m a descri o dos temas do mapa.
11.3. INTERFACE INTERATIVA E LINGUAGEM DE CONSULTA

N vel de Representa o Matriz tem tica Representa o planar pol gonos Geo-campo Grade regular 2D num rico Grade triangular Amostras 3D Lote urbano Geo-objeto em um mapa de lotes Mapa de lotes Cadastral Representa o vetorial arco-n -pol gono Rede el trica Rede Grafo orientado arcos orientados + n s Tabela 11.1: Rela o entre n veis conceitual e de representa o Dado Geogr co Mapa de aptid o agr cola Mapa altim trico N vel Conceitual Geo-campo Tem tico
149
A tabela 11.1 mostra como um mesmo dado geogr co pode ter diferentes representa es.
11.3 Interface Interativa e Linguagem de Consulta

O spring v2.0 oferece uma interface de usu rio dirigida por menus, especialmente til de ni o de esquemas conceituais. O processo de de nir o esquema conceitual de um banco de dados geogr co no ambiente spring consiste em estender a hierarquia de classes, de nida pelo modelo de dados, criando classes derivadas das classes b sicas. Na terminologia adotada no spring, uma especializa o de uma geo-classe chamada de categoria, podendo ser esta uma classe b sica ou n o. Ao de nir uma categoria, o usu rio estar criando uma classe derivada das classes b sicas, herdando as suas propriedades. Como exemplo, considere a seguinte de ni o do esquema conceitual de um banco de dados geogr cos para cadastro rural, ilustrada na gura 11.6. A categoria Fazendas uma espe cializa o da classe GeoObjeto. A categoria MapaPropriedades uma especializa o da classe Cadastral, que inclui uma representa o geom trica para os geo-objetos da classe Fa zendas. A categoria MapaSolos uma especializa o da classe Tem tico, cujas inst ncias armazenam os tipos de solos para as reas de estudo. As categorias Altimetria e Decli vidade s o especializa es da classe Num rico, cujas inst ncias guardam a topogra a e a declividade da rea de estudo, respectivamente. A categoria DadosTM uma especializa o da classe DadoSensorRemoto, cujas inst ncias cont m imagens do sat lite Landsat sobre a regi o de estudo. O spring v2.0 inclui uma implementa o parcial da linguagem legal, j discutida na se o
150
Campo is-a Mapa Temtico

Mapa solos
Mapa Objetos is-a Imagem Mapa Sens. Rem Cadastral

Imagem TM Mapa Fazendas
Geo-Objeto is-a
Fazendas
MNT is-a
is-located-in
Altimetria
Declividade
Figura 11.6: Exemplo de de ni o de esquema conceitual no spring 6.3. Recordando, legal baseia-se em uma lgebra geogr ca, que permite expressar opera es espec cas para cada tipo de dado, bem como explicitar opera es que transformam um tipo de dado em outro. Para indicar como LEGAL dever operar em sua implementa o plena, considere o exemplo de um estudo para selecionar uma rea para dep sito de lixo na cidade de S o Jos dos Campos, baseando-se na localiza o dos postos de sa de e em mapas de solos e de declividade. As condi es ideais de localiza o de um dep sito de lixo s ao: estar a mais de 5 km de postos de sa de, em solo n o-perme vel e com declividade menor que 5 . As reas com valor aceit vel s o marcadas
adequadas para um dep sito de lixo. A opera o requer uma consulta espacial
selecione todos os postos de sa de localizados na regi o da Vila Paiva, uma transforma o entre geo-objetos e geo-campo
calcule um mapa de dist ncias a partir dos postos de sa de, uma f rmula num rica
determine a declividade e uma an lise booleana. A gura 11.7 apresenta os comandos em legal que implementam o exemplo descrito.
11.4 Funcionalidade
A funcionalidade completa do spring v2.0 n o ser aqui descrita em detalhes, sendo abordadas apenas algumas opera es e facilidades oferecidas pelo sistema, ressaltando aquelas incorpora das nesta nova vers o. Para uma descri o mais detalhada sobre as fun es citadas, o leitor deve se referir ao manual do sistema.
Fun es sobre Imagens. O spring oferece um amplo leque de opera es sobre imagens, in
cluindo opera es de contraste, ltragem, classi ca o, registro, segmenta o, opera es aritm ticas, transforma o IHS-RGB, opera es estat sticas, entre outras. A classi ca o de imagens por regi es oferece fun es de classi ca o n o supervisionada BEF93 , su
11.4. FUNCIONALIDADE
Definicao dos Dados Tematico solo SOLO, adeq ADEQUACAO, dist DISTANCIA; Cadastral Numerico Tabela Colecao mapa_SJC MAPA_CIDADE; topoTOPOGRAFIA, decl DECLIVIDADE; tab_dist FATIAMENTO; postos PSAUDE;
151
Recuperacao dos Dados topo= SELECT * FROM TOPOGRAFIA WHERE Nome solo= SELECT * FROM SOLO WHERE Nome = ``Top92''; = ``Solo92'';
mapa_SJC= SELECT * FROM MAPA_CIDADE WHERE Nome = ``SJCampos''; Postos de Saude no Bairro postos = SELECT posto FROM posto IN PSAUDE ON MAP mapa_SJC, bairro IN BAIRRO ON MAP mapa_SJC, WHERE posto INSIDE bairro.nome = ``Vila Paiva''; Calculo do Mapa de Distancias mapa_dist= NOVO Nome = ``Dist'', Representacao = Matricial, ResX = 100, ResY= 100, Escala = 25000; tab_dist:= NOVO TIPO = FATIAMENTO, ``mais de 5 km'' : $ $ 5km, ``perto'': DEFAULT; mapa_dist= FATIA DISTANCIA postos, tab_fatia; Calculo do mapa de declividade decl= NOVO Nome=``Declividade'', Representacao = Matricial, ResX = 100, ResY= 100; decl := DECLIVIDADE mapa_topo; Calculo do Mapa de Adequacao adeq= NOVO Nome = ``DepositoLixo'', Representacao = Matricial, ResX = 100, ResY= 100, Escala mapa_adeq: = 25000; = Atribua ``adequado'': solo.tema = ``Le'' E dist.tema=``mais de 5 km" E mapa_decl $ $ 0.05; ``inadequado'': Outros ;
Figura 11.7: Exemplo de implementa o em LEGAL
152

pervisionada e por redes neurais BML94 . Possui opera es para restaura o de imagens TM e SPOT. Na vers o 2.0, est o sendo incorporadas diversas fun es para processamen to d e imagens de radar, inclusive: corre o de padr o de antena, corre o geom trica
slant range ground range e c lculo de par metros estat sticos.
Fun es sobre Dados Tem ticos e Cadastrais. As fun es sobre dados tem ticos e cadas
trais incluem opera es de tabula o cruzada, lineamentos, mapas de dist ncia, edi o com topologia autom tica ajuste e poligonaliza o, opera es booleanas lgebra, mo saico e mascaramento, transforma o vetor-varredura e varredura-vetor, entre outras. dade, fatiamento, gera o de imagem, per l, c lculo de volume, visualiza o 3D, ponde ra o lgebra, mosaico e mascaramento, gera o de grade regular e triangular, gera o de isolinhas, entre outras. Ressaltamos a opera o de triangula o com restri es, onde as linhas de restri o representam linhas ao longo das quais ocorrem quebras de continui dade na superf cie modelada. Um modelo de terreno deve incorporar estas linhas se uma representa o el necess ria. Assim, para o modelo que utiliza grades triangulares, as linhas de restri o devem ser incorporadas e a superf cie a ser ajustada a cada retalho triangular deve tamb m considerar a quebra de continuidade. dimento aloca o.
Fun es sobre Modelos Num ricos de Terreno. Oferece opera es de c lculo de declivi
Fun es sobre Redes. A vers o 2.0 oferecer opera es de caminho timo e centros de aten Acoplamento a Banco de Dados. O spring permite o acoplamento a um sgbd relacional
mono-usu rio e tamb m a sgbds comerciais com suporte arquitetura cliente-servidor. Oferece interface compat vel com DBaseIV e com sql. As opera es de consulta ao ban co de dados incluem sele o de objetos baseada em atributos ou em restri es topol gicas adjac ncia, cruzamento, pertin ncia, sobreposi o e m tricas dist ncia. combina uma interface interativa com o acesso a uma biblioteca de s mbolos cartogr cos.
Gera o Interativa de Cartas. o spring disp e de um m dulo para gera o de cartas, que Interface com outros sig. A m de garantir a comunica o com sig mais utilizados no mer
cado, o sistema importa dados nos formatos SGI, MAXICAD, ASCII, ARC INFO e DXF. A vers o 2.0 exporta dados nos formatos SGI, ASCII, ARC INFO e DXF.
Al m da funcionalidade delineada acima, cabe ressaltar que o spring v2.0 permite a execu o de forma n o interativa de certas opera es, tais como importa o com remapeamento de imagens, segmenta o, classi ca o e modelagens.
Cap tulo 12 O Projeto SAGRE

12.1 Introdu o
O sagre Sistema Automatizado de Ger ncia de Rede Externa Mag94 um conjunto integra do de software para automatizar os diversos processos relacionados ao cadastro, planejamento, projeto, implanta o, opera o, manuten o, expans o e ger ncia da Rede Externa das Empre sas Operadoras do Sistema TELEBR S. A Rede Externa a rede que est do lado de fora das Esta es Telef nicas. Ela composta da rede de canaliza o rede formada por conjunto de dutos enterrados conectados a caixas subterr neas, da rede a rea rede dos cabos suspensos e da rede subterr nea rede dos cabos que passam pela rede de canaliza o. O sagre um t pico sistema de am fm constru do sobre um sig. O sig utilizado para representar espacialmente a rede de canaliza o e a rede a rea sobre um mapeamento urbano. A rede subterr nea representada em esquem ticos ou detalhes layouts. Aplica es deste tipo podem trazer uma s rie de benef cios para as empresas que os utilizam. O sagre permitir alcan ar, dentre outros benef cios, a redu o do tempo de implanta o das redes telef nicas, a melhor utiliza o da rede instalada e a melhoria da qualidade dos servi os. O sagre est sendo especi cado e desenvolvido de forma cooperativa por Empresas Operadoras do Sistema TELEBR S e pelo Centro de Pesquisa e Desenvolvimento da TELE BR S cpqd-telebras.
12.2 Funcionalidade
O in cio do sagre foi motivado pela necessidade de otimizar os processos de administra o das plantas cadastrais do sistema de telecomunica es atualmente, cerca de 300.000 plantas no total. Este objetivo motivou a cria o de um grupo de trabalho multidisciplinar, com a participa o de especialistas na rea de Rede Externa planejamento, projeto, implanta o e opera o e de Computa o provenientes da TELESP, TELERJ, TELEMIG, TELEPAR, 153
154
CAP TULO 12. O PROJETO SAGRE
TELEBAHIA, TELEBRAS LIA e TELEAMAZON para a elabora o do documento preliminar da especi ca o do sagre. Requisitos do sagre exigiram uma plataforma computacional que implementa uma arqui tetura cliente-servidor. No lado servidor s o utilizadas esta es de trabalho RISC de alto desempenho e resolu o gr ca e sistema operacional UNIX. Os clientes podem ser esta es UNIX ou micro-computadores com sistema operacional MS Windows. O ambiente computa cional completado com impressoras laser e plotters. Os dados s o processados atrav s de um sig comercial. Este sig difere da maioria dos sistemas geogr cos comerciais por utilizar um sgbd relacional comercial para gerenciar n o s os dados convencionais mas tamb m os dados espaciais. O sagre est sendo desenvolvido a partir de uma loso a de sistemas abertos, com faci lidade de portabilidade linguagem de programa o C e linguagem de manipula o de banco de dados sql, ado o de metodologia estruturada e padr o de interface homem-m quina OSF Motif. As fun es a serem atendidas pelo sagre envolvem o cadastramento da rede e mapeamento urbano correspondente inser o, no sistema, dos dados e seu georeferenciamento, planeja mento, estudos de mercado e demanda, projeto de engenharia e implanta o e gerenciamento da opera o e manuten o da rede. Suas principais fun es est o concentradas em Cadastro conjunto de procedimentos para cadastramento e atualiza o da rede existente e mapeamento urbano GEOG94 . Convers o metodologia e ferramentas para convers o dos dados e mapas do papel para o banco de dados do sagre MGS+94 . Administra o ambiente de controle de reas em projeto ou em implanta o, controle de usu rios, con gura o de ndices de or amenta o, e ger ncia do uxo de trabalho. Esta fun o permite o trabalho cooperativo entre operadores e projetistas. Projeto e Planejamento fun es relativas elabora o do planejamento para moderniza o e expans o da Rede Externa PTO95 . Estas atividades incluem o planejamento de novos centro de os, cortes de rea, entroncamentos e atendimento de grandes clientes, de ni o da rea de tarifa b sica, projetos das redes de canaliza o, alimenta o, distri bui o e entroncamentos, com previs o de materiais e custo de m o-de-obra envolvidos nos projetos. Opera o aloca o, reserva, libera o e dedica o de facilidades para servi os de clientes. Al m de reduzir o trabalho manual de veri ca o da qualidade dos dados, dando mais op es para a atividade de planejamento, o sagre permitir a uni ca o e integra o dos cadastros e gerenciamento automatizado dos recursos existentes, com conseq ente economia de custos e utiliza o racional da rede. Experi ncias em outros pa ses mostram que a automatiza o dos processos de gerenciamento de Rede Externa reduziram os custos das opera es de cadastro
12.3. COMPONENTES E ARQUITETURA
155
em 90, 20 na elabora o de projetos e 40 nas fun es de planejamento, o que resultaria numa redu o de custos na m dia em torno de 50.
12.3 Componentes e Arquitetura

12.3.1 Principais Componentes
Geralmente, a rede externa dividida em rede a rea, rede de canaliza o e rede subterr nea. Da esta o telef nicas, partem as conex es pares de os dentro das canaliza es diretamente para concentra es de usu rios e. g. pr dios ou para um centro de distribui o arm rio. Do centro de distribui o, os pares s o levados por cabos suspensos s vezes enterrados at os usu rios. O sistema est organizado em diversos m dulos. O m dulo de cadastro, j instalado na maio ria da operadoras, fornece ferramentas para manuten o, recupera o, gera o de relat rios, mapas e convers o de dados de mapas em papel para o meio digital. No m dulo de projeto do ambiente do sagre, o usu rio projetista trabalha nas etapas de cria o, modi ca o e acompanhamento de um projeto. Para iniciar um novo projeto, o usu rio precisa de nir a regi o alvo, que est armazenada no banco de dados relacional do sagre. Esta escolha de regi o pode ser feita interativamente, atrav s da sele o de partes de mapas mostrados na tela. Quando a regi o selecionada, seus dados s o copiados para um banco de dados de trabalho a chamada atividade de
check-in, que ser utilizado pelo projetista para desenvolver alternativas de projeto. No cadastro, os elementos copiados s o marcados como bloqueados com compartilhamento. Ao m da atividade de projeto, o conte do do banco de dados de trabalho ser retornado
check-out para o banco de dados do sagre, ocorrendo ent o veri ca o da consist ncia. Este processo controlado por um sistema de vers es, descrito ao m deste cap tulo. Outras fun es permitem realizar c lculos de engenharia e de custo de material e m o-de-obra. Atualmente, esta parte realizada manualmente, sendo respons vel por uma grande parcela dos custos de um projeto. Os c lculos de engenharia envolvem opera es como atenua o do sinal el trico, de ni o da localiza o de aterramentos, testes de v lvulas. O c lculo de custos consome atualmente cerca de 40 do tempo de um projeto e a sua automatiza o pelo sagre dever reduzir consideravelmente este custo. Outra fun o corresponde s opera es de an lise de redes, que permite calcular e prever fatores como ocupa o dos dutos e cabos. Os valores m ximo e m nimo de ocupa o e as caracter sticas de uma rea demanda, localiza o permitem de nir a expans o da rede. Este tipo de atividade pode envolver todas os elementos de uma rede em uma regi o, ou apenas um elemento espec co. As facilidades de manipula o dos dados incluem edi o de atributos convencionais, espaciais e gr cos. A atividade de projeto envolve tanto os elementos da rede quanto os esquem ticos e
layouts de circuitos. Cada esquem tico associado a uma localiza o geogr ca ou a
156
outro esquem tico mais complexo. Um dos problemas atualmente sendo tratado a gera o autom tica de esquem ticos a partir de opera es do usu rio.
12.3.2 Arquitetura do SAGRE

A arquitetura do sagre pode ser considerada como composta de tr s camadas funcionais, que executam tarefas bem de nidas e funcionalmente independentes: Interface Homem-M quina IHM, Aplica o APL, que permite a transforma o dos dados e Encapsulamento da Base de Dados EBD, conforme ilustra a gura 12.1.
INTERFACE HOMEM-MAQUINA
APLICACAO
ENCAPSULAMENTO
ADMINISTRACAO
SGBD & SIG
BD
Figura 12.1: Arquitetura do sagre . A camada IHM respons vel pela implementa o de todos os processos de comunica o com o usu rio, incumbindo-se de padronizar a interface. Seus servi os s o implementados atrav s de primitivas de abertura fechamento de telas de atributos, mudan a de caracter sticas dos atributos de uma tela, entrada de informa es, con rma o e escolha de op es. A interface baseada em um conjunto de telas mapas b sicos, de ni o de atributos, esquem ticos e mensagens. As telas de mapas b sicos cont m os detalhes da rede externa, mostrando seus elementos tanto gra camente quanto textualmente. O usu rio pode realizar v rias opera es para visualiza o, como
zoom,
pan e outras. A camada APL implementa todas as opera es de edi o inser o, altera o e remo o e consulta sobre os objetos do banco de dados, centralizando as tarefas da aplica o propriamente dita. Esta camada ativada quando o usu rio seleciona um objeto atrav s da interface e escolhe uma opera o a ser executada. Ela respons vel pelos procedimentos operacionais do sistema,
12.4. ELEMENTOS ARMAZENADOS E MODELO DE DADOS
157
tais como garantir a consist ncia dos dados a partir das regras de engenharia e de gerenciamento. A camada orientada a objetos. Cada objeto manipulado um elemento da rede, associado a um s mbolo para sua representa o gr ca. O m dulo EBD re ne todas as rotinas de acesso ao banco de dados, sendo respons vel pela padroniza o de acesso, abstra o em rela o s tabelas f sicas do sistema e seguran a na intera o dos m dulos de IHM e APL com a base de dados, o que se d atrav s da invoca o de primitivas funcionais pr -de nidas. Esta camada respons vel pelo banco de dados permanente e pelos bancos de dados de trabalho para projeto de alternativas, com o controle de vers es. Mais importante, esta camada tem uma fun o b sica de prover uma abstra o orientados a objetos sobre o sistema relacional utilizado. Dessa forma, a camada APL trabalha com objetos encapsulados, deixando para a camada EBD a tarefa de mapear estes objetos e, s vezes, seus componentes nas tabelas do esquema relacional. A comunica o entre as camadas gerenciada pelo m dulo de administra o, que controla todos os projetos em andamento para cada rea geogr ca coberta pelo banco de dados. Os mecanismos de controle de vers o DGM95 s o implementados aqui. O primeiro m dulo a ser automatizado foi o de manuten o do cadastro de rede externa, denominado sagreCad, cujo objetivo a atualiza o de dados, desde o n vel macro rede at o n vel de esquem ticos, atrav s de fun es de edi o de objetos, edi o de esquem ticos e associa o de imagens raster.
12.4 Elementos Armazenados e Modelo de Dados

Um conceito fundamental na modelagem de sistemas para aplica es de concession rias de servi os p blicos o mub Mapa Urbano B sico. Este modela os elementos que formam a base do planejamento urbano. Em princ pio, todas aplica es relativas a servi os utilit rios telefonia, eletricidade e outros usam o mub como base, por m os elementos utilizados variam conforme a aplica o. Exemplos de elementos que fazem parte do mub s o divisas de lote, linhas centrais, im veis numera o predial, obras de arte e edi ca es de destaque. No caso do sagre, os elementos do mub incluem: Arruamento Quadra, Meio Fio, Logra douro, Loteamento Testada de Lote, Indica o de Lote, Numera o, Aspectos Geogr cos Hidrogra a, Acidentes Geogr cos, Obras P blicas Rodovia, Ferrovia, Edi ca es de Destaque. Os elementos do mub s o armazenados no banco de dados camada EBD fazendo parte do cadastro armazenado. Do ponto de vista do nosso modelo, descrito no cap tulo 4, estes elementos constituem geo-objetos. No mub do sagre, um logradouro representado por um ou v rios segmentos de linha central, conceito fundamental para permitir desenvolver as fun es relativas ao georeferencia mento. A linha central , na verdade, um conjunto de segmentos de reta que passam ao longo do eixo dos logradouros e s o delimitadas por pontos de interse o cruzamento de ruas ou esquinas com outros logradouros.
158
Nos pontos de interse o, os segmentos de linha central coincidem nas extremidades forman do uma rede de conectividade f sica. Al m dos elementos do mub o banco de dados armazena v rios outros componentes, relativos aos dados da rede externa. Exemplos s o dados da rede a rea bloqueio, caixas terminais, lances de cabo, subida de lateral, caixas prediais, emendas, arm rios, aterramento, da canali za o subterr nea lance de duto, duto lateral, cano interno, amarra o das caixas e da rede subterr nea caixa subterr nea, lance de cabo subterr neo, subida de lateral. Estes dados so frem o chamado processo de convers o para serem armazenados no banco de dados, de acordo com um padr o patenteado pelo cpqd-telebras, discutido ao m deste cap tulo. No banco de dados do sagre existe um conjunto de estruturas topol gicas de redes, que s o fundamentais representa o da rede externa, permitindo a modelagem das v rias redes existentes. Estas estruturas garantem que se possa considerar a geometria e topologia das redes que fazem parte da rede externa por exemplo, rede de cabos e rede de canaliza o. No processo de inser o, os dados da rede externa s o georeferenciados usando como base tais estruturas e posicionados em rela o aos dados do mub previamente armazenados. Por exemplo, na inser o de um lance de cabo, os postes que fazem parte do percurso do lance devem ser registrados no banco de dados e relacionados ao lance. Este relacionamento se faz atrav s das coordenadas de identi ca o, que indicam os elementos relacionados atrav s de uma coordenada pr xima ao elemento, dentro de uma toler ncia. As caixas subterr neas s o posicionadas sobre o mub e com lances de duto interligando-as. Para cada caixa subterr nea deve-se associar um sub-mapa, denominado Esquem tico de Cabos e Emendas, que descreve sob a forma de diagramas as liga es dos lances de cabos subterr neos, emendas e demais equipamentos que est o localizados na caixa subterr nea. Os dados armazenados s o extra dos das plantas da rede utilizadas nas empresas operadoras. Estas plantas s o visualizadas no sagre atrav s de elementos gr cos que est o dispostos em diferentes n veis. Cada elemento representa gra camente um item de rede externa poste, cabo e pode possuir dados alfanum ricos associados tipo, capacidade, comprimento que est o contidos em rela es do banco de dados. As informa es est o organizadas por objetos que representam os elementos reais existentes no mub e na Rede Externa. Al m dos dados alfanum ricos, cada elemento possui uma representa o gr ca que o caracteriza. Um exemplo de uma tela com objetos de mub e rede mostrado na gura 12.2.
12.5 Caracter sticas da Manipula o de Dados

O projeto e desenvolvimento do sagre segue uma metodologia orientada a objetos. Assim sendo, cada elemento do cadastro da rede externa est associado a um conjunto de opera es que variam segundo suas caracter sticas particulares, visando a manuten o do cadastro. Cada uma dessas opera es habilitada e desabilitada automaticamente em fun o da situa o con textual do momento. Essas opera es podem ser agrupadas em tr s classes funcionais b sicas: Inser o, Modi ca o e Remo o, que atuam tanto sobre dados espaciais quanto textuais e de
12.5. CARACTER STICAS DA MANIPULA O DE DADOS
159
Figura 12.2: Exemplo de tela base do sagre . apresenta o. Por exemplo, durante a inser o, o usu rio tem a possibilidade de desenhar um objeto gr co indicando gra camente o ponto inicial, os pontos em que o mesmo muda de dire o e o ltimo ponto, ou inserir um s mbolo pr -de nido que o represente, indicando o ponto onde deve ser inserido e sua orienta o. Entretanto, antes de represent -lo gra camente, pode ser necess rio indicar os pontos de interesse da rede ou mub e ou outros objetos aos quais est associado. Em seguida, o ambiente auxilia o usu rio na de ni o dos atributos do objeto. Um objeto pode ser apresentado associado a diversos fatores de simbologia: cor, legendas e s mbolos especiais. A associa o de um objeto s legendas pode ser autom tica ou manual. Neste ltimo caso, o usu rio indica a posi o localiza o e orienta o onde a legenda deve aparecer e digita o texto desejado. Al m do gerenciamento dos elementos da rede externa, o sistema auxilia o gerenciamento automatizado dos componentes de esquem ticos, que podem ser editados e manipulados dire tamente atrav s da camada IHM. O usu rio pode, inclusive, associar uma imagem raster a
160
qualquer objeto ou a qualquer ponto da regi o geogr ca que est sendo manipulada. A imagem associada a duas coordenadas da regi o que est sendo manipulada, sendo dimensionada conforme o tamanho da rea determinada pelas coordenadas fornecidas. Com estas facilidades, o usu rio pode cadastrar informa es que n o s o pr prias da rede externa, mas que in uenciam o seu tra ado, como o caso da rede de esgotos e da rede de energia el trica. Em geral, as concession rias de servi os p blicos possuem sistemas de opera o desenvolvi dos em computadores de grande porte sem o aux lio de um sig. O uso de sig nestas aplica es traz uma s rie de benef cios, em especial na localiza o espacial dos consumidores e dos equi pamentos que podem serv -los. No ambiente da opera o da rede, as transa es s o curtas mas freq entes. Normalmente estas transa es s o originadas no sistema de atendimento ao cliente das operadoras. Por exemplo, uma transa o comum o provimento de um servi o num determinado endere o. Neste caso fornecido o endere o do cliente e o servi o desejado. De posse do endere o, uma pesquisa convencional realizada para encontrar a inst ncia. Uma vez encontrado o endere o, sua localiza o geogr ca dada pelo sig. Neste ponto feita uma busca espacial para encontrar os elementos de rede que podem se conectar ao endere o do cliente a uma certa dist ncia deste. Conhecidos os elementos de rede candidatos, percorre-se a rede avaliando-se condi es de forma a determinar a solu o tima para atender o cliente. Esta transa o tamb m poderia ser disparada por um engenheiro a partir de um micro-computador remoto. Com estes requisitos, o sagre teve que utilizar geradores de interfaces capazes de gerar c digo para v rias plataformas, especialmente PC MS Windows e Risc UNIX. No ambiente de projeto e planejamento a situa o diferente. Neste caso a intera o ho mem-m quina longa e complexa. Durante um projeto, elementos s o inseridos com atributos parcialmente conhecidos. medida em que o projeto vai progredindo, os atributos deixados incompletos v o sendo preenchidos at que se tenha um projeto conclu do. Foi necess rio criar mecanismos de veri ca es de pend ncias. Tamb m, num ambiente deste tipo necess rio fornecer meios de retroceder no projeto. O uso de vers es foi fundamental no provimento desta funcionalidade.
12.6 Interface
A interface do sagre OCM95 din mica, ou seja, os componentes de uma tela s o de nidos em tempo de execu o, medida em que o usu rio interage com o banco de dados. Ela deve ser considerada sob dois aspectos: o modelo da interface propriamente dito arquitetura da interface e a especi ca o de uma biblioteca de m dulos que permitem criar e combinar os elementos de uma apresenta o funcionalidades dispon veis. Ambos o modelo e a biblioteca de classes seguem o paradigma de orienta o a objetos. A especi ca o do modelo seguiu o modelo din mico da metodologia omt. A interface foi constru da visando a reutiliza o de esfor os, em termos de projeto e de
12.6. INTERFACE
161
implementa o. O modelo de interface orientado a objetos, sendo utilizado para de nir uma biblioteca de elementos que permitem manipular representa es gr cas. O sistema de interface permite reutiliza o na constru o de interfaces din micas, isto , cujos componentes s o determinados em tempo de execu o. A capacidade de constru o din mica dos elementos da interface possibilita a personaliza o da interface, o que aumenta a exibilidade do sistema e conseq entemente o grau de satisfa o do usu rio. Pode-se programar, para cada elemento gr co, os atributos alfanum ricos que devem apa recer no mapa, bem como a forma que os mesmos devem ser exibidos. Al m disso, o pr prio s mbolo do elemento pode ser alterado automaticamente em fun o da altera o dos seus atri butos. Os componentes de di logo n o precisam ser de nidos estaticamente durante o processo de compila o da interface; ao contr rio, eles podem ser inseridos e removidos dinamicamente. O modelo de interface adota a linguagem de de ni o de interface orientada a objetos cor ba idl de nida na arquitetura de gerenciamento de objetos proposta pelo Object Management Group omg Obj94 , garantindo o suporte sem ntico necess rio, que disp e inclusive de me canismos para descri o de m todos e passagem de mensagens, e assegurando a padroniza o entre os diversos projetos de interface, no que se refere ao di logo com a aplica o. A principal motiva o para a constru o do modelo de interface foi promover a reutiliza o n o s de c digo, mas tamb m de projetos de interface. O modelo formado por um conjunto de classes inter-relacionadas, onde cada classe descreve um componente t pico de um sistema de interface visual . Uma interface visual suporta e permite a coexist ncia de qualquer um dos estilos b sicos de intera o linguagens, menus, telas formatadas e manipula o direta. Esta classe de interfaces , portanto, mais abrangente que a das interfaces gr cas, as quais utilizam primordialmente conceitos de manipula o direta. O principal elemento do modelo a classe Janela. Qualquer interface visual baseia sua intera o com o usu rio em algum tipo de janela, que pode ser ou n o gr ca, e que cont m os elementos de di logo usados na intera o. Uma janela formada por um conjunto de pain is, onde cada painel agrega, por sua vez, elementos de interface relacionados de acordo com as id ias do projetista da interface. Esta caracter stica de de ni o recursiva de um painel de controle facilita a reutiliza o de componentes na interface. A janela que cont m os componentes de intera o pain is de controle, pode estar asso ciada a outras janelas. Existem diferentes tipos de relacionamentos entre janelas, como por exemplo a rela o de hierarquia entre janela b sica e janelas secund rias, em um ambiente de janelas m ltiplas, ou como a rela o de ordem de chamada de janelas, em um sistema de telas formatadas. O classe Janela tamb m relacionada classe Interface da Aplica o, que representa a vis o que os componentes de interface possuem da aplica o subjacente. A classe Interface da Aplica o pode ser considerada como um elemento de liga o nico que associa os componentes da interface com o usu rio aos componentes da aplica o propriamente dita. este conceito de vis o que possibilita a utiliza o do modelo para constru o de interfaces din micas.
162
O objetivo deste relacionamento prover independ ncia de di logo s interfaces baseadas na biblioteca, garantindo que decis es de projeto que afetam apenas o di logo homem-computador sejam isoladas daquelas que afetam apenas o software computacional e a estrutura da aplica o. Esta abordagem simpli ca as modi ca es tanto da interface quanto da aplica o, pelo isolamento existente entre os dois componentes do sistema. Outras classes da interface s o Campo Textual, rea de Desenho, Bot o, Lista e Menu. A metodologia utilizada para o desenvolvimento da biblioteca da interface foi a Object-Oriented Modeling and Design omt Rum91 , que mostrou-se bastante e ciente tanto nas fases ini ciais quanto na implementa o do projeto. Ela possibilitou manter a vis o orientada a objetos, mesmo utilizando uma linguagem convencional no caso, a linguagem C. A biblioteca exten s vel, ou seja, novos componentes podem ser acrescentados ou modi cados via mecanismo de heran a, para reutiliza o. Este processo de reutiliza o exige que sejam oferecidas facilidades para pesquisa, recupera o e atualiza o de componentes da biblioteca. Um dos componentes da camada de interface com o usu rio o m dulo denominado Gerente de Atributos gat, que implementa o acesso aos atributos alfanum ricos dos componentes da rede externa. Durante uma sess o de trabalho no sagre, o usu rio visualiza representa es gr cas da rede externa, ou seja, mapas. A sele o de um elemento da rede externa ativa o m dulo gat que permite a manipula o dos atributos do elemento selecionado. A gura 12.3 mostra uma inst ncia do gat para o objeto Poste. O sagre permite que o usu rio visualize de v rias formas e com diferentes n veis de de talhes, as informa es do banco de dados geogr co subjacente. Esta visualiza o pode ser textual, gr ca ou uma combina o de ambas. A apresenta o abrange diversas escalas, haven do possibilidade de opera es de zoom e panning para navegar em uma regi o. H dois tipos de opera es b sicas: manipula o de informa es gr cas e manipula o de atributos. As informa es gr cas s o manipuladas atrav s de uma tela denominada Mapa Base e uma tela espec ca para a manipula o de esquem ticos. A edi o gr ca possibilita a sele o e a edi o de objetos gr cos, georeferenciados atrav s de coordenadas UTM Universe Transverse Mercator, em escala de nida pelo usu rio. Durante a manipula o dos objetos no sagreCad, uma s rie de mensagens s o enviadas ao usu rio visando orient -lo durante a execu o das opera es, bem como inform -lo de poss veis erros ocorridos. Os elementos do cadastro de rede externa s o, em geral, referenciados ao mub e, para a visualiza o, s o desenhados sobre a
imagem do mub. Al m disso, alguns elementos podem ser associados a outros desenhos ou diagramas, que n o s o desenhados sobre o mub, e que podem ser armazenados em formato raster ou vetorial. Deve-se observar que em algumas situa es, o mesmo elemento do banco de dados pode ser representado gra camente em mais de um esquem tico. Um lance de cabo, por exemplo, pode ter uma emenda inicial em uma determinada caixa subterr nea, passar direto por uma ou mais caixas e terminar o seu percurso em uma emenda localizada em outra caixa.
12.6. INTERFACE
163
Figura 12.3: Interface de atributos do sagre .
164
A simbologia pode ser considerada como uma consulta din mica que, ao mostrar o lance de cabo segmento de linha, mostra tamb m com s mbolos e letras alguns dos atributos e relacionamentos do mesmo. A visualiza o de elementos, por raz es est ticas e regras de apresenta o, nem sempre segue os relacionamentos armazenados. Por exemplo, o banco de dados informa quais lances de cabo est o apoiados em que postes. Na apresenta o, o segmento de linha que representa o lance de cabo n o toca os s mbolos que representam os postes.
12.7 Mecanismos Internos

12.7.1 Convers o dos Dados para Entrada no Sistema
A constru o de bancos de dados para o sagre envolve um processo de convers o de dados, cr tico para o sistema em implanta o, pois o desempenho do sistema depender da qualidade dos dados MGS+94 . A convers o realizada por empresas especializadas, tendo em vista sua complexidade. Normalmente, as empresas de convers o trabalham com ferramental pr prio e fornecem os dados convertidos nos formatos propriet rios dos sig utilizados. Estes formatos s o de nidos num n vel muito primitivo, tornando o processo de aceita o complicado e oneroso. Para reduzir os custos, melhorar a qualidade, reduzir o tempo de convers o, e facilitar todo o processo de aceita o dos dados, a TELEBR S optou por de nir um formato pr prio para a convers o. Este formato, orientado aos elementos de mapeamento urbano e rede externa, de nido numa linguagem de alto n vel nos termos utilizados pelos t cnicos e engenheiros das empresas operadoras. Com isto, as empresas de convers o n o precisam se especializar nos formatos propriet rios dos sig. Outra vantagem que este formato abre o mercado para empresas nacionais. Existe uma especi ca o t cnica detalhada em 600 p ginas onde est o descritas todas as regras da convers o. Para cada elemento a ser convertido, s o descritas as formas de como devem ser representados ap s a convers o Descri o de Elemento Gr co ou DEG, como se apresentam nas plantas Descri o de Elemento de Planta ou DEP e a forma como os dados, produto da convers o, devem ser armazenados Descri o de Formato de Convers o ou DFC. O formato de convers o precisa considerar elementos gr cos e textuais que dependem de cada tipo de elemento a ser convertido. Al m disso, a convers o precisa levar em conta dados como data de instala o, afastamento de elementos em rela o a pontos de refer ncia, coordenadas de posicionamento que pode chegar a constituir uma lista de coordenadas, dependendo do tipo de elemento.
12.7. MECANISMOS INTERNOS
165
12.7.2 Controle de Vers es

Nos casos de aplica es ambientais, usu rios tipicamente trabalham com transa es longas, em que in meros cen rios s o gerados a partir de opera es de an lise, testando diferentes situa es, levando a um diagn stico nal. Em ambientes de projeto como o sagre, a situa o outra: ao mesmo tempo, projetistas trabalham com transa es longas e aninhadas enquanto que operadores manipulam os dados em regime on-line com transa es curtas. A solu o encontrada foi a implementa o de um sistema de vers es DGM95 . A solu o permite a conviv ncia controlada de atualiza es de curta dura o garantidas em princ pio pelo mecanismo de controle de concorr ncia do sgbd relacional do sagre e atualiza es de longa dura o. Estas ltimas envolvem inclusive mudan as condicionais, isto , que podem ser efetivadas ou revogadas. Al m disso, a representa o gr ca de um elemento condicional projetado pode ser diferente da sua representa o na rede existente. Geralmente, vers es s o utilizadas para resolver problemas num ambiente de projeto onde v rios usu rios trabalham cooperativamente para produzir um projeto, gerando alternativas. No sagre, o ambiente alvo bem similar por m com um agravante. Projetos de redes de telecomunica es geralmente atuam sobre uma rea geogr ca onde j existe alguma rede im plantada rede j em opera o. Assim, os projetistas trabalham sobre uma situa o existente que n o pode ser congelada, uma vez que as redes implantadas s o atualizadas on-line. Estas altera es podem ser provocadas por acidentes por exemplo, um temporal pode dani car a rede a rea ou por press o da demanda por servi os. Os projetistas, embora num ambiente de transa es longas, gostariam de trabalhar com os dados na vers o mais recente mesmo que isto venha a invalidar algumas tarefas j realizadas. Por exemplo, ao lan ar um novo lance de cabo a reo os postes sobre os quais o cabo se apoiar podem ter sido substitu dos ou at mesmo retirados. Outra caracter stica importante que a maioria das altera es projetadas para a rede s o inerentemente condicionais, isto , nada garante que as mesmas ser o efetivadas implanta das. As atualiza es s o condicionais por dependerem de dados existentes que foram alterados durante o ciclo do projeto. Quanto maior o grau de concorr ncia entre os projetistas numa determinada rea geogr ca, maior a probabilidade de haver con itos de depend ncias entre dados projetados e existentes. A ger ncia de vers es baseada no esquema de check-in check-out proposta inicialmente em CK86 . O projetista antes de qualquer a o extrai para um banco de dados de trabalho os dados existentes na rea geogr ca de interesse opera o de check-out. Todas as opera es de projeto s o executadas neste banco de dados de trabalho, sendo os dados criados todos condicionais. A sele o de elementos para as opera es de transfer ncia de dados feita atrav s de coordenadas geogr cas. Quando as altera es estiverem conclu das e prontas para a instala o, os dados alterados s o retornados ao banco de dados central atrav s da opera o de check-in. Se houver projetos que se sobreponham em uma mesma rea geogr ca, isto acarreta a
166
exist ncia de m ltiplos bancos de dados para a rea: o central permanente e os de trabalho. Somente os dados do primeiro check-in ser o aceitos, invalidando as modi ca es ocorridas nestes dados nos outros bancos de dados de trabalho. Esta invalida o ocorre apenas para os elementos atualizados e n o para toda a rea de interse o de projetos. Havendo invalida o, cada banco de dados que teve seus dados invalidados deve reextra -los, atualizando-os conforme o banco de dados central. A exist ncia de dados condicionais e permanentes requer um tratamento diferenciado no armazenamento destes dados no banco de dados central. A maneira encontrada foi garantir uma ordena o parcial das vers es de um dado conjunto de elementos. A vers o zero armazena os dados permanentes enquanto que as outras vers es de projeto representam os dados condi cionais. No banco de dados, todos os registros que comp em uma mesma vers o de elemento est o associados a um mesmo n mero de vers o. A atualiza o do banco de dados para o estado permanente baseada no conceito de depend ncias de vers es, que fun o da ordem relativa de cria o de vers es no tempo. Maiores detalhes est o em DGM95 . A implementa o dos mecanismos de vers o requereu uma s rie de servi os n o dispon veis em sgbd relacionais comerciais. Primeiro, a atividade de check-in check-out exigiu a imple menta o de protocolos de bloqueio especiais. O sig utilizado no sagre oferece uma camada de servi os sobre o sgbd relacional que inclui alguns recursos adicionais que simpli caram a implementa o do mecanismo de vers es. Por exemplo, o servidor de identi cadores deste sig foi utilizado para garantir a unicidade de identi ca o dos dados e a ordena o parcial dos identi cadores de vers o, facilitando a identi ca o dos registros com depend ncias de ver s es. O esquema de exporta o importa o de dados foi realizado atrav s de um formato de transfer ncia provido pelo sig.
Cap tulo 13 Centros de Dados Geogr cos

13.1 Introdu o
Este cap tulo discute solu es emergentes que tratam do gerenciamento de dados geogr cos em grande volume, de forma a permitir seu uso cooperativo por ag ncias governamentais ou privadas. Solu es para este problema envolvem o desenvolvimento de cooperativas e centros de dados geogr cos. A se o 13.2 introduz conceitos e de ni es. A se o 13.3 discute as fun es de um centro de dados hipot tico e a se o 13.4 descreve sucintamente alguns projetos correlatos.
13.2 Cooperativa de Dados e Centro de Dados

V rias ag ncias, governamentais ou n o, atuam na aquisi o, armazenamento, processamento e distribui o de diversos tipos de dados geogr cos para os mais variados ns, tais como previs es agr colas, an lises ambientais e planejamento urbano. Para realizar suas tarefas, uma ag ncia, pode utilizar dados de outras ag ncias, al m dos dados coletados e produzidos internamente. Assim, o trabalho entre ag ncias pode ser visto como um trabalho cooperativo. Contudo, esta coopera o , por muitas vezes, prejudicada pela grande dispers o geogr ca existente entre as ag ncias, e agravada pela aus ncia de uma padroniza o para os dados. O acesso a dados ambientais sofre com o fato de cada ag ncia arquivar seus dados em forma particular, de acordo com as suas necessidades por exemplo, de acordo com o sig utilizado, complicando a coordena o e combina o destes m ltiplos conjuntos de dados. Esses dados gerados s o subutilizados ou at mesmo recriados a cada nova aplica o. Por exemplo, nos EUA, mais de 20 ag ncias federais gastam anualmente por volta de 5 bilh es de d lares em pesquisa cient ca sobre o meio ambiente. Estes problemas de coopera o prejudicam as tomadas de decis es e impedem a utiliza o efetiva de dados j dispon veis. Nesse contexto, uma cooperativa de dados um conjunto de ag ncias interligadas atrav s de um sistema de informa o global de dados vide gura 13.1, que, por sua vez, formado por 167
168
CAP TULO 13. CENTROS DE DADOS GEOGR FICOS
centros de dados interligados atrav s de um sistema de comunica o de dados. O sistema de comunica o pode ser uma rede privada, interligando as ag ncias de uma cooperativa, ou uma rede p blica, permitindo a comunica o com outras ag ncias externas, sendo possivelmente composto pelas duas redes.
Fornecedor Administrao do Centro de Dados Centro de Dados Sistema de Comunicao Fornecedor Centro de Dados Centro de Dados Usurio
Usurio
Administrao do Centro de Dados
Administrao do Centro de Dados
Figura 13.1: Cooperativa de dados
Um centro de dados uma facilidade que permite coleta, armazenamento, processamento, acesso e distribui o de dados ou programas atrav s do sistema de comunica o. Um Sistema de Ger ncia de Centro de Dados sgcd respons vel pela ger ncia dos dados em centro de dados, mas n o obrigatoriamente por sua propriedade. Uma ag ncia pode exercer diversos pap is dentro da cooperativa, quer administrando um ou mais centros de dados, quer fornecendo dados e produtos para tais centros, ou mesmo atuando como simples usu rio do sistema de informa o global. O resultado deste tipo de coopera o til n o apenas para as ag ncias envolvidas, como tamb m para usu rios externos, aos quais os dados podem ser tornados dispon veis, segundo diferentes pol ticas de acesso. Um sgcd dever , em particular, fornecer mecanismos para garantir a seguran a dos dados, prote o do patrim nio individual de cada ag ncia, acesso controlado de acordo com a tarifa o ou comprometimento da ag ncia tanto participante como n o participante da cooperativa, sendo de responsabilidade dos administradores de cada um dos centros de dados componentes zelar pela manuten o das regras estabelecidas de comum acordo entre os participantes da cooperativa.
13.3. FUN ES DE UM CENTRO DE DADOS
169
13.3 Fun es de um Centro de Dados

Nesta se o, discutimos caracter sticas gerais de centro de dados, sintetizadas a partir da des cri o de diversos centros de dados. Na se o 13.4 apresentamos alguns projetos de centros de dados. Em alto n vel, um sistema gerenciador de centro de dados deve ser capaz de lidar com quatro entidades: dados, produtos, usu rios e fornecedores. Dados, usu rios e metadados j s o comu mente tratados por sgbds, sendo o tratamento feito de forma an loga por sgcds. Um produto a informa o gerada a partir do processamento de dados armazenados, podendo consistir em dados ou programas. Este processamento pode ser t o simples quanto o encapsulamento de um dado para um formato pr -determinado ou t o so sticado quanto a gera o de um mapa a partir de temas selecionados pelo usu rio e incorporando procedimentos n o autom ticos. poss vel especi car restri es ao acesso de usu rios a dados, produtos e e fun es do sgcd, de forma semelhante ao acesso a dados em sgbds. A manuten o do cadastro de fornecedores importante para a ger ncia de atualiza o e o controle de qualidade do conte do do banco de dados no centro de dados. Usualmente, um sgcd uma aplica o sobre um sgbd ou sig, em fun o da variedade de fun es de processamento que se deseja disponibilizar. Assim, a discuss o sobre arquiteturas para sigs, apresentada no cap tulo 8, pertinente para centros de dados. Centros de dados caracterizam-se por armazenarem dados pouco vol teis, existentes a longo termo e, portanto, sua arquitetura deve ser capaz de acomodar evolu es tecnol gicas. As principais fun es de um centro de dados, descritas a seguir, envolvem aquisi o, geren ciamento e disponibiliza o de dados, de forma a permitir integra o entre diferentes centros.
Aquisi o de Dados
O processo de aquisi o inclui a coleta e pr -processamento dos dados, a sua convers o para um formato de troca, controle de qualidade e inser o no banco de dados de um centro de dados. A execu o das etapas de aquisi o depende do tipo dos dados e da aplica o por exemplo, imagens de sat lite e dados pluviom tricos s o adquiridos de forma distinta. Neste processo, a integra o ou migra o de sistemas de bancos de dados de produ o legados deve ser prevista SSB95 . Um formato de troca visa garantir a interoperabilidade entre sistemas. Ele deve ser autocon tido, ou seja, deve encapsular todas as informa es relevantes para a compreens o do dado. O dado de troca pode ser um objeto, incluindo inclusive m todos para sua manipula o. Elkington EMM94 argumenta que uma cooperativa n o deve ditar um formato de troca nico e r gido, dado que ag ncias podem ter prefer ncias particulares sobre formatos distintos. Um sgcd deve disponibilizar algumas rotinas de convers o de formatos entre os padr es internacionais mais utilizados e os formatos de troca adotados na cooperativa. O pr -processamento envolve convers o de formato e corre o de dados para garantir sua
170
qualidade. No controle de qualidade, os dados devem ser veri cados de acordo com os meta dados associados. Os resultados desta veri ca o devem ser enviados para o fornecedor. Por exemplo, uma imagem de sat lite coletada pode ser inicialmente corrigida radio e geometri camente, atrav s de rotinas de processamento de imagens. Ela tamb m deve passar por um processo de georeferenciamento e ser convertida para um padr o de troca. Informa es relevan tes s o ent o extra das para futura indexa o como discutido no cap tulo 9. interessante por m observar que, em muitos casos, h interesse em se armazenar histori camente dados brutos, j que pode haver uma variedade de algoritmos de pr -processamento, e nem sempre estes permitem a recupera o do dado original a partir do pr -processado. Na inser o de dados, o sistema deve prever a gera o autom tica de amostras para campos longos, a m de facilitar o folheamento dos dados por parte do usu rio. Por exemplo, no caso das imagens de sat lite, amostras podem ser obtidas atrav s de subamostragem dos pixels.
Armazenamento e Arquivamento de Dados

A fun o de armazenamento e arquivamento de dados oferece servi os para as demais fun es. O objetivo desta fun o gerenciar o armazenamento de dados, de acordo com pol ticas de arquivamento estabelecidas. H basicamente tr s n veis de dados armazenados: os metadados, o cat logo de dados e os dados propriamente ditos. Os metadados descrevem os dados armazenados. O cat logo mant m informa es condensadas sobre inst ncias de dados, incluindo amostras de valores longos. Os dados propriamente ditos s o freq entemente volumosos, numerosos e hist ricos. Atualmente, grande parte dos sistemas em opera o armazena o cat logo e os metadados em um sgbd. J os dados cam em um sistema de arquivos, com ger ncia de hierarquia de mem ria, com uma arquitetura semelhante dual no que diz respeito a armazenamento. Como o cat logo por sua vez tamb m tende a car com muitas entradas muitas entidades, dados hist ricos, alguns sgbds t m conex o direta com tais sistemas de ger ncia de mem ria, segundo a pol tica de arquivamento estabelecida. Os dados devem ser armazenados utilizando um formato neutro, padr o, a m de minimizar os esfor os de convers o de formato. Este formato de armazenamento visa a e ci ncia na recupera o da informa o e no uso de mem ria. Eventualmente, o formato de troca e o formato de armazenamento podem ser os mesmos.
Disponibiliza o de Dados e Programas

O objetivo da fun o de disponibiliza o de dados e programas tornar os bancos de dados dispon veis para consulta tanto para os usu rios de uma cooperativa quanto para eventuais usu rios externos. Consultas envolvendo mais de um centro de dados geram subconsultas a serem formuladas aos centros adequados, sendo suas respostas a seguir integradas em um resultado nal.
13.3. FUN ES DE UM CENTRO DE DADOS
171
As consultas podem envolver tanto dados quanto metadados SSKS95 , inclusive tornando dispon veis programas de uso gen rico, tais como programas para visualiza o e anima o. A diversidade potencial de dados e usu rios requer aten o especial quanto a estrat gias de busca e acesso. A consulta, feita via rede, pode ser navegacional ou associativa, atrav s de uma interface hiperm dia NS91 . Consultas espaciais devem ser permitidas, como por exemplo as descritas no cap tulo 6. O aspecto de seguran a de acesso importante. Assim, a disponibiliza o de dados e fun es deve ser customizada de acordo com o usu rio. Ap s uma sess o de consultas, um usu rio gera uma lista de dados e programas selecionados, a partir da qual poss vel a solicita o de produtos, conforme discutido a seguir.
Distribui o de Produtos
Esta fun o abrange o gerenciamento da solicita o e distribui o de produtos para usu rios, sendo a distribui o escalonada conforme prioridades de atendimento. Os usu rios podem emitir ordens de pedidos de produtos a partir da lista de dados e programas selecionados, acrescen tando poss veis informa es necess rias para a gera o do produto por exemplo, especi ca o da m dia de distribui o e do formato de troca. Os produtos podem ser classi cados para facilitar este gerenciamento, considerando por exemplo informa es sobre responsabilidades, tempo de m dio de produ o e outros. A conta biliza o de dados sobre sess es de usu rios ajuda a prever solicita es de produtos, os quais podem ser gerados e armazenados em antecipa o demanda. Esta contabiliza o tamb m til para outros ns, como por exemplo tarifa o, otimiza o de ndices de acesso, revis o de pol ticas de arquivamento, ou de ni o de per s de usu rios. Um problema na fun o de distribui o a exist ncia de c pias il citas. Alguns sistemas CDD+ 95 sugerem o uso de
marcas d' gua
watermarking identi cando a proced ncia ou os usu rios requisitantes nos produtos sendo distribu dos, seja eletr nica ou sicamente, a m de inibir a difus o de tais c pias.
Integra o com Outros Centros de Dados

Esta fun o respons vel pela integra o de dados e processamentos entre os centros de dados de uma cooperativa. Ela visa permitir combinar diferentes centros de dados apesar de diferen as em seu vocabul rio, completude e representa es. A ado o de um nico padr o de metadados facilita esta tarefa, tendo sido esta uma estrat gia adotada pelo FGDC
Federal Geospatial Data Committee - Content Standard for Digital Geospatial Metadata veja se o 4.3. Caso isto n o seja poss vel, o sistema deve ajudar o usu rio a lidar com as diferen as e eventuais incompatibilidades do sistema EMM94 . A integra o de processamentos tem por objetivo a comunica o entre processamentos pela rede de comunica o, possivelmente se baseando em uma especi ca o tipo OGIS Car94 ou CORBA Obj94 conforme discutido na se o 8.4.
172
A integra o de dados e o processamento de transa es s o reas de pesquisa ativas em bancos de dados m ltiplos
multidatabases SL90, LMR90 . Em um ambiente de informa es globais, no entanto, estas quest es assumem novas dimens es, conforme discutimos na pr xima se o.
Outras Fun es
Outras fun es incluem a ger ncia de usu rios, produtos e fornecedores, a ger ncia de aquisi o e distribui o de dados, o processamento de dados propriamente dito e fun es administrativas em geral. A ger ncia de usu rios, produtos e fornecedores controla os cadastros respectivos, agrupan do-os em fun o de seu relacionamento com a cooperativa, de acordo com n veis diferenciados de acesso. A fun o de processamento de dados basicamente respons vel pela gera o de produtos, realizando, por exemplo, encapsulamento de dados, convers es de formato, classi ca o de imagens, gera o de mapas. A ger ncia de aquisi o e distribui o de dados respons vel por gerenciar a freq ncia com que o banco de dados deve ser atualizado Por exemplo, um centro de dados que disponibilize imagens do sat lite Landsat deve garantir a atualiza o peri dica das imagens. Al m disso, usu rios poder o fazer assinaturas de produtos dos quais necessitem com certa periodicidade. Finalmente, a fun o de administra o respons vel pelas tarefas usuais de administra o de dados tais como
back-up e recupera o de dados. Alguns outros servi os, tais como admi nistrar um f rum aberto de discuss es via rede, tamb m s o interessantes para a cooperativa.
13.4 Exemplos
Nesta se o apresentamos brevemente algumas das iniciativas que envolvem cooperativas e centros de dados geogr cos STMS94 . A iniciativa DLT
Digital Library Technology, nos EUA, tem por objetivo o desenvolvi mento de novas tecnologias para facilitar o acesso p blico aos dados da NASA via redes de computadores, em especial ferramentas, aplica es e hardware que enderecem a quest o de es calabilidade. A ADL
Alexandria Digital Library FAB+95 um dos projetos patrocinados por esta iniciativa, sendo desenvolvida na Universidade da Calif rnia em Santa B rbara. A ADL um projeto de um cons rcio de diversos grupos, incluindo setores privados, tendo o objetivo de desenvolver uma biblioteca digital composta de v rios n s distribu dos sobre a rede p blica Internet. Seu foco inicial em dados geogr cos. J existe um primeiro prot tipo, que armazena mapas digitalizados, fotogra as a reas e imagens de sat lite. Nas pr ximas fases, o projeto pretende tratar tamb m de classes espaciais gen ricas e textos. O EOSDIS
Earth Observation System Data and Information System EMM94, EW94
13.4. EXEMPLOS
173
um dos componentes da Miss o do Planeta Terra, projeto de pesquisa multi- e interdisciplinar da NASA. Seu objetivo permitir acesso f cil e con vel aos dados do EOS
Earth Observation System, em sua maioria obtidos a partir de sat lites em rbita baixa da Terra. O EOSDIS baseia-se em uma cooperativa de dados com inicialmente oito centros de dados espalhados pelo territ rio americano, respons veis pela produ o, arquivamento e distribui o de produtos, e diversos centros de processamento, para desenvolver e manter programas, validar dados e programas, gerar produtos e outras atividades. Os dados ser o coletados durante 15 anos a partir de 20 instrumentos diferentes colocados a bordo de seis sat lites especiais que ser o postos em rbita entre os anos de 1998 e 2002. O volume de dados previsto de 1Tbyte por dia, que dever ser formatado, calibrado e armazenado para acesso pelos diferentes grupos de pesquisa. Estima-se, atualmente, que cerca de 10000 grupos de pesquisa diferentes dever o utilizar tais dados, al m das eventuais consultas que poder o ser feitas atrav s de redes como a Internet. Duas redes de comunica o s o previstas, uma dedicada, corporativa, e outra externa, p blica. O ERC
Environment Resource Center tem o objetivo de oferecer facilidades para identi car, acessar e integrar dados ambientais existentes. um projeto entre a ind stria privada e diversos n veis do governo americano, como a NASA e o Estado do Texas. Mais especi camen te, o ERC dever oferecer um sig integrado, com acesso f cil a dados brutos ou interpretados via interfaces gr cas, capacidade de compartilhar dados entre usu rios e aplica es de forma transparente, permitindo integra o simples e barata de novos dados e novas aplica es. O ERC prev ferramentas para visualiza o, anima o e manipula o interativa de dados, interface de comunica o padr o sobre WAN e f cil acesso de usu rios a dados atrav s de interfaces via
e-mail e redes como a Internet. A primeira fase deste projeto foi iniciada em abril de 1994 com a constru o de um prot tipo, atualmente operacional. No Brasil, o projeto ProTeM-CC geotec tem intera o com o Projeto CODEX. O objetivo do CODEX prover um conjunto de servi os com metodologias bem de nidas e componentes para especi ca o, desenvolvimento, instala o e opera o de um centro de dados para aplica es ambientais CGFH95 .
174
Refer ncias Bibliogr cas

AA93 G. Alonso and A. El Abbadi. GOOSE: Geographic Object Oriented Support Envi ronment. In Proc. ACM ISCA Workshop on Advances in Geographic Information Systems, pages 3843, 1993. ABC+91 J. Antenucci, K. Brown, P. Croswell, M. Kevany, and H. Archer. Geographic Infor mation Systems - a Guide to the Technology. Van Nostrand Reinhold, 1991. AHW89 H.-W. Six A. Henrich and P. Widmayer. The LSD-Tree: Spatial Access to Multi dimensional Point- and Non-Point-Objects. In Proc 15th VLDB Conference, pages 4553, 1989. AKK94 ANS75 ANS94 Arn93 Aro89 AS91 AS93 M. Arikawa, H. Kawakita, and Y. Kambayasshi. Dynamic Maps as Composite Views of Varied Geographic Database Servers. In Proc. International Conf. on Applications of Databases, 1994. ANSI. American National Standards Institute Study Group on Database Manage ment Systems. Technical report, ANSI, 1975. ANSI. SQL - Multimidia Spatial, 1994. Draft. E. Arnberger. Thematische Kartographie. Westermann Schulbuchverlag, Braunsch weig, 1993. S. Arono . Geographic Information Systems. WDL Publications, Canada, 1989. W. Aref and H. Samet. Optimization Strategies for Spatial Query Processing. In Proc. 17th VLDB Conference, pages 8190, 1991. E. Assad and E. Sano. Sistema de Informa es Geogr cas: Aplica es na Agricul tura. Edi o Embrapa CPAC, 1993.
AYA+92 D. Abel, S. Yap, R. Ackland, M. Cameron, D. Smith, and G. Walker. Environmen tal Decision Support System Project: an Exploration of Alternative Architectures for Geographical Information Systems. International Journal of Geographical In formation Systems, pages 193204, 1992. Bar92 N. Barry. How OLE works. BYTE, 1711, 1992. 175
176 Bat92 BDK92 BDN93
REFER NCIAS BIBLIOGR FICAS

P. Batty. Exploiting relational database technology in a GIS. Computers and Geosciences: An international journal, 184:453462, 1992. F. Bancilhon, C. Delobel, and P. Kanellakis, editors. Building an Object-Oriented System the Story of O2. Morgan Kaufmann, 1992. C. Broiato, C. Domingues, and M. N ia. A Experi ncia da Implanta o de um Sistema de Informa es Geogr cas na Prefeitura Municipal de Santo Andr . In IV Confer ncia Latinoamericana sobre Sistemas de Informa o Geogr ca, pages 365382, 1993. C. Beeri. Formal Models for Object-oriented Databases. In Proc. 1st International Conference on Deductive and Object-oriented Databases, pages 370395, 1989. L. Bins, G. Erthal, and L. Fonseca. Um M todo para Classi ca o N o-Supervisionada de Regi es. In Proc. VI Simp sio Brasileiro de Computa o Gr ca e Processamento de Imagens, 1993. D. Beckley, M. Evens, and V. Raman. Multikey Retrieval from K-d trees and Quad-trees. In Proc. of the ACM SIGMOD Conference, pages 291301, maio 1985. J. Berry. Cartographic Modeling: the Analytical Capabilities of GIS. In M. Good child, B. Parks, and L. Steyaert, editors, Environmental Modelling with GIS, pages 5874. Oxford University Press, 1993. J. Boyle, J. Fothergill, and P. Gray. Design of a 3D User Interface to a Database. In J. Lee and G. Grinstein, editors, Proc. IEEE Visualization Workshop, pages 273185, 1993. Springer Verlag Lecture Notes in Computer Science 871.
Bee89 BEF93 BER85 Ber93 BFG93
BHKS93 T. Brinkho , H. Horn, H. Kriegel, and R. Schneider. A Storage and Access Archi tecture for E cient Query Processing in Spatial Database Systems. In Proc. 3rd International. Symposium on Large Spatial Databases, pages 357376, 1993. BK85 BK91 BK95 BKS93 D. Batory and W. Kim. Modeling Concepts for VLSI CAD Objects. ACM Tran sactions on Database Systems, 103:322346, 1985. N. Barghouti and G. Kaiser. Concurrency Control in Advanced Database Applica tions. ACM Computing Surveys, 233:319344, 1991. M. Bieber and C. Kacmar. Designing Hypertext Support for Computational Ap plications. Communications of the ACM, 388:99107, 1995. T. Brinkho , H. Kriegel, and B. Seeger. E cient Processing of Spatial Joins Using R-Trees. In Proc. of the ACM SIGMOD Conference, junho 1993.
BKSS90 N. Beckmann, H. Kriegel, R. Schneider, and B. Seeger. The R-tree: An E cient and Robust Access Method for Points and Rectangles. In Proc. of the ACM SIGMOD Conference, pages 322331, 1990.
177
BKSS94 T. Brinkho , H-P. Kriegel, R. Schneider, and B. Seeger. Multi-Step Processing of Spatial Joins. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 197208, 1994. BM92 BML94 Bot95 BP94 Bro94 Bul94 Bur86 Bur92 Bur93 BX94a BX94b Cam93 P Boursier and M Mainguenaud. Spatial Query Languages: Extended SQL vs Visual Languages vs Hypermaps. In Proc 5th International Symposium on Spatial Data Handling, pages 249259, 1992. Volume 1. V. Barbosa, R. Machado, and F. Liporace. A Neural System for Deforestation Monitoring on Landsat Images of the Amazon Region. International Journal of Approximate Reasoning, pages 321359, 1994. M. A. Botelho. Incorpora o de Facilidades Espa o Temporais em um Banco de Dados Orientado a Objetos. Master's thesis, UNICAMP, dezembro 1995. M. Beguin and D. Pumain. La Representation des Donn es Geographiques. Statis tique et Cartographie. Armand Colin, 1994. K. Brockschmidt. OLE Integration Technologies. Dr. Dobb's Special Report on Interoperable Objects Revolution, pages 4249, 1994. G. Bull. Ecosystem Modelling with GIS. 183:345349, 1994.
Environmental Management,
P. Burrough. Principles of Geographical Information Systems for Land Resources Assessment. Clarendon Press, 1986. P. Burrough. Development of Intelligent Geographical Information Systems. Inter national Journal of Geographical Information Systems, 61:112, 1992. P. Burrough. Soil Information Systems. In D. J. Maguire, M. F. Goodchild, and D. W. Rhind, editors, Geographical Information Systems - volume II, pages 153169. John Wiley and Sons, 1993. M. Batty and Y. Xie. Modelling inside GIS: Part 2. Selecting and Calibrating Urban Models Using Arc-Info. International Journal of Geographical Information Systems, 84:451470, 1994. M. Batty and Y. Xie. Modelling inside GIS: Part I. Model Structures, Explorato ry Spatial Data Analysis and Aggregation. International Journal of Geographical Information Systems, 83:291308, 1994. G. Camara. Anatomia de Sistemas de Geoprocessamento: Vis o Atual e Perspec tivas de Evolu o. In Anais do II Simp sio Brasileiro de Geoprocessamento, pages 157183, 1993.
Cam94a G. Camara. An lise de Arquiteturas para Bancos de Dados Geogr cos Orientados a Objetos . Technical report, INPE, 1994.
178
Cam94b F. Campagnoni. IBM's System Object Model. Dr. Dobb's Special Report on Inte roperable Objects Revolution, pages 2428, 1994. Cam95 Car94 Cas93 Cat94 G. Camara. Modelos, Linguagens e Arquiteturas para Bancos de Dados Geogr cos. PhD thesis, INPE, dezembro 1995. C. Cargill. Standard View - ACM Perspectives on Standardization. Communica tions of the ACM, 23, 1994. S. Cassettari. Introduction to Integrated Geo-Information Management. Chapman & Hall, 1993. R.G. Catell. The Object Database Standard. Morgan Kau mann, San Francisco, 1994.
CDD+ 95 D. Choy, R. Dievendor , C. Dwork, J. Lotspiech, R. Morris, L. Anderson, A. Bell, S. Boyer, T. Gri n, B. Hoenig, J. McCrossin, A. Miller, N. Pass, F. Pestoni, and D. Picciano. The Almaden Distributed Digital Library System. In ADL'95 - A Forum on Reserach and Technology Advances in Digital Libraries, 1995. CdFvO93 E. Clementini, P. di Felice, and P. van Oosterom. A Small Set of Formal Topological Relationships Suitable for End-User Interaction. In Proc. 3nd Symposium Spatial Database Systems, pages 277295, 1993. CFC94 CFR87 G. Camara, U. Freitas, and J. Cordeiro. Towards an Algebra of Geographical Fields. In VII Simp sio Brasileiro de Computa o Gr ca e Processamento de Imagens, 1994. T. Sellis C. Faloutsos and N. Rossopoulos. Analysis of Object-Oriented Spatial Access Methods. In Proc. of the ACM SIGMOD Conference, pages 426439, 1987.
CFS+94 G. Camara, U. Freitas, R. Souza, J. Paiva, M. Casanova, and A. Hemerly. A General Data Model for Integrating Remote Sensing and GIS Data. In Proc. ISPRS Symposium on Mapping and Geographical Information Systems, 1994. CGFH95 S. Cruz, L. Gon alves, S. Fuks, and A. Hemerly. Proposta de uma Cooperativa de Banco de Dados sobre Recursos Naturais na EMBRAPA. In AgroSoft'95 Semin rio Internacional de Informatiza o da Agropecu ria, 1995. CHF93a M. Casanova, A. Hemerly, and A. Furtado. Cooperative Environments for Geo graphic Databases: a Prescriptive Analysis. In Anais, 8 Simposio Brasileiro de Bancos de Dados, pages 266279, 1993. CHF93b M. Casanova, A. Hemerly, and A. Furtado. Um Gerenciador para Atributos Espa ciais de Objetos Geogr cos. In Anais da IV Conferencia Latino-americana sobre SIG, pages 223235, 1993.

CHK93 Chr90 Chr93 Cif95 CK86 Cou92
179
D. Clark, D. Hastings, and J. Kineman. Global databases and their implications for GIS. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume II, pages 217231. John Wiley and Sons, 1993. N. Chrisman. De ciencies of Sheets and Tiles: Building Sheetless Databases. In ternational Journal of Geographical Information Systems, 42:157168, 1990. N. Chrisman. The Error Component in Spatial Data. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume I, pages 165174. John Wiley and Sons, 1993. R. Ciferri. Um Benchmark Voltado a An lise de Desempenho de Sistemas de Infor ma es Geogr cas. Master's thesis, UNICAMP, junho 1995. H. Chou and W. Kim. A Unifying Framework for Version Control in a CAD Environment. In Proc. 12th VLDB Conference, pages 336344, 1986. H. Couclelis. People Manipulate Objects but Cultivate Fields: Beyond the Ras ter-Vector Debate in GIS. In Proc International Conference on GIS - From Space to Territory: Theories and Methods of Spatial Reasoning, pages 6577. Springer Verlag Lecture Notes in Computer Science 639, 1992. D. Cowen. GIS versus CAD versus DBMS: what are the Di erences? In Introducto ry Readings in Geographical Information Systems, pages 5261. Taylor and Francis, 1990. F. Cox. An lise de M todos de Acesso a Dados Espaciais Aplicados a Sistemas Gerenciadores de Banco de Dados. Master's thesis, UNICAMP, dezembro 1991. E. Clementini, J. Sharma, and M. Egenhofer. Modelling Topological Spatial Re lations: Strategies for Query Processing. Computer and Graphics, 186:815822, 1994. G. Camara, R. C. M. Souza, and U. Freitas. SPRING: Object-oriented Geopro cessing. In XV International Congress of Photogrammetry and Remote Sensing, 1992.
Cow90 Cox91 CSE94 CSF92
CSFP93 G. Camara, R.C.M. Souza, U. Freitas, and J. Paiva. SPRING: Concep o, Evo lu o, Perspectivas. In Proc. VII Simposio Brasileiro de Sensoriamento Remoto, 1993. Dal93 P.F. Dale. Land Information Systems. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume II, pages 8599. John Wiley and Sons, 1993. Dan90 K. Dangermond. A Classi cation of Software Components Commonly Used in Geo graphic Information Systems. In Introductory Readings in Geographical Information Systems, pages 3151. Taylor and Francis, 1990.
180 DC91 DDY93 DF92 DGM95

M. Maingenaud D. Calcinelli. The Management of the Ambiguities in a Graphical Query Language for GIS. In Proc. 2nd Symposium Spatial Database Systems, pages 99118. Spring Verlag Lecture Notes in Computer Science 525, 1991. J. Patel D. DeWitt and J. Yu. Paradise - A Parallel Geographic Information System. In Proc. ACM Workshop on Advances in Geographic Information Systems, pages XY, 1993. J. Doerschler and H. Freeman. A Rule-based System for Dense Map Name Place ment. Communications of the ACM, 351:6879, 1992. E. Dias, S. Granado, and G. Magalh es. Uso de Vers es na Garantia de Consist ncia em Ambientes Mistos de Projeto e Opera o. In Anais, X Simp sio Brasileiro de Bancos de Dados, pages 321334, 1995.
DRS93a B. David, L. Raynal, and G. Schorter. GeO2: Object Oriented Contribution for a Geographic DBMS? In Proc. 4th International Conference Database and Expert Systems Applications, pages 377383, 1993. DRS93b B. David, L. Raynal, and G. Schorter. GeO2: Why Objects in a Geographical DBMS? In Proc 3rd International Symposium Large Spatial Databases, 1993. DS93 ea92 ea93 ea94 EF88 EF91 Ege89 F.W. Davis and D.S. Simonett. GIS and Remote Sensing. In D. Maguire, M. Good child, and D. Rhind, editors, Geographical Information Systems - volume I, pages 191213. John Wiley and Sons, 1993. M. Goodchild et al. Integrating GIS and Spatial Data Analysis: Problems and Pos sibilities. International Journal of Geographical Information Systems, 65:407424, 1992. A. Mendelzon et al. Declarative Database Visualization: Recent Papers from the Hy+ GraphLog Project . Technical Report CSRI-285, University of Toronto, junho 1993. D. DeWitt et alii. Client-Server Paradise. In Proc. 20th VLDB Conference, pages 558569, 1994. M. Egenhofer and A. Frank. Designing Object-oriented Query Languages for GIS: Human Interface Aspects. In Proc 3rd International Symposium on Spatial Data Handling, pages 7998, 1988. M. Egenhofer and R. Franzosa. Point-Set Topological Spatial Relations. Interna tional Journal of Geographical Information Systems, 52:161174, 1991. M. Egenhofer. Spatial Query Languages. PhD thesis, University of Maine, maio 1989.

Ege92 Ege94 Ege95 EH90
181
M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 62:7186, 1992. M. Egenhofer. Spatial SQL: A Query and Presentation Language. IEEE Transac tions on Knowledge and Data Engineering, 61:8695, 1994. M. Egenhofer. Object-oriented GISs: The Principles. Technical report, NCGIA, fevereiro 1995.
M. Egenhofer and J. Herring. A Mathematical Framework for the De nition of Topological Relationships. In Proc. 4th International Symposium on Spatial Data Handling, pages 803813, 1990. EMM94 M. Elkington, R. Meyer, and G. McConaughy. De ning the Architectural Deve lopment of EOSDIS to Facilitate Extension to a Wider Data Information System. Technical Report 194-00131, Hughes Applied Information Systems, 1994. EW94 A. Endal and S. Wharton. ECS Science Requirements Summary - White Paper. Technical Report FB9402V2, Hughes Applied Information Systems, Inc., mar o 1994. FAB+95 J. Frew, M. Aurand, B. Butten eld, L. Carver, P. Chang, R. Ellis, C. Fisher, M. Gardner, M. Goodchild, G. Hajic, M. Larsgaard, K. Park, M.Probert, T. Smith, and Q. Zheng. The Alexandria Rapid Prototype: Building a Digital Library for Spatial Information. In ADL'95 - A Forum on Reserach and Technology Advances in Digital Libraries, 1995. FCF92 A. Frank, I. Campari, and U. Formentini, editors. Theories and Methods of Spa tio-Temporal Reasoning in Geographic Space. Lecture Notes in Computer Science 639. Springer Verlag, 1992. Fed93 K. Fedra. GIS and Environmental Modelling. In M. Goodchild, B. Parks, and L. Steyaert, editors, Environmental Modelling with GIS, pages 3547. Oxford Uni versity Press, 1993. Feu93 M. Feutchwanger. Towards a Geographic Semantic Database Model. PhD thesis, Simon Fraser University, 1993. FG90 A. Frank and M. Goodchild. Two Perspectives on Geographical Data Modelling. Technical Report 90-11, National Center for Geographic Information and Analysis, 1990. FG94 C. Felgueiras and M. Goodchild. An Incremental Constrained Delaunay Triangula tion. Technical report, NCGIA, 1994. Fil93 A. Queiroz Filho. Ortofoto Digital para Atualiza o Cartogr ca em SIG. In IV Confer ncia Latinoamericana sobre Sistemas de Informa o Geogr ca, pages 4756, 1993.
182 FK93 FM91 FR93 FR94 Fre75 Fre87 FT93 Gar93 GB90

C. Faloutsos and I. Kamel. High Performance R-trees. IEEE Data Engineering Bulletin, pages 2833, 1993. A. Frank and D. Mark. Language Issues for GIS. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume I, pages 147161. John Wiley and Sons, 1991. R. Fernandez and M. Rusinkiewicz. A Conceptual Design of a Soil Database for a GIS. International Journal of Geographical Information Systems, 76:525540, 1993. S. Fotherington and P. Rogerson, editors. Spatial Analysis and GIS. Taylor and Francis, 1994. J. Freeman. The Modelling of Spatial Relations. Computer Graphics and Image Processing, 4:156171, 1975. M. Freeston. The BANG File: A New Kind of Grid File. In Proc. of the ACM SIGMOD Conference, pages 260269, 1987. P. Franciosa and M. Talamo. ESPRIT Project EP6881 - AMUSING. IEEE Data Engineering Bulletin, pages 4650, 1993. K. Gardels. The Sequoia Model of Geographic Information. In Proc. of the GIS '93 Symposium, 1993. O. Gunther and A. Buchman. Research Issues in Spatial Databases. ACM Sigmod Record, 194:6168, 1990.
GEOG94 J. Gon alves, M. Erhardt, F. Obata, and S. Granado. Automa o de Cadastros de Rede Externa. In Proc. I Encontro de Qualidade de Redes de Telecomunica es e de Equipamento Terminais, 1994. Goh89 Goo87 Goo91 Goo92 P-C. Goh. A Graphic Query Language for Cartographic and Land Information Systems. International Journal of Geographical Information Systems, 33:245256, 1989. M. Goodchild. A Spatial Analytical Perspective on Geographical Information Sys tems. International Journal of Geographical Information Systems, 14:327334, 1987. M. Goodchild. Spatial Analysis with GIS: Problems and Prospects. In Proc GIS LIS 91, volume 1, pages 4048, 1991. M. Goodchild. Geographical Data Modelling. Computers and Geosciences, 184:401408, 1992.

Goo93 Gou93 GPS93 GR93 GR95 Gra93 Gut84 Gut88 Gut94 GV93 HC91 HCS93
183
M. Goodchild. A Perspective on the State of Environmental Smulation. In M. Go odchild, B. Parks, and L. Steyaert, editors, Environmental Modelling with GIS, pages 815. Oxford University Press, 1993. M. Gould. Human Factors in Geographic Information Systems, chapter Two Views of the User Interface, pages 101110. Belhaven Press, 1993. M. Goodchild, B. Parks, and L. Steyaert, editors. Environmental Modelling with GIS. Oxford University Press, 1993. O. Gunther and W-F Riekert. The Design of GODOT: an Object-oriented Geo graphic Information System. IEEE Data Engineering Bulletin, pages 49, 1993. V. Gudivada and V. Raghavan. Content-based Image Retrieval Systems. IEEE Computer, 289:1822, 1995. G. Graefe. Query Evaluation Techniques for Large Databases. ACM Computing Surveys, 252:73170, 1993. A. Guttman. R-Trees: A Dynamic Index Structure for Spatial Searching. In Proc. of the ACM SIGMOD Conference, pages 4756, junho 1984. R. Guting. Geo-relational Algebra: a Model and Query Language for Geometric Database Systems. In Proc. 1st EDBT Conference, pages 506527, 1988. R. Guting. An Introduction to Spatial Database Systems. VLDB Journal, 34, 1994. J. Gomes and L. Velho. Modelagem em Computa o Gr ca. In VI Simp sio Brasileiro de Computa o Gr ca e Processamento de Imagens, 1993. L. Haas and W. Cody. Exploiting Extensible DBMS in Integrated Geographic Information Systems. In Proc. 2nd Symposium Spatial Database Systems, pages 423449. Springer Verlag Lecture Notes in Computer Science 525, 1991. S. Hirtle, T. Crippa, and M. Spring. The Cognitive Structure of Space: an Analysis of Temporal Sequences. In Proc. European Conference Spatial Information Theory - COSIT, pages 177189. Springer Verlag Lecture Notes in Computer Science 716, 1993. J. Herring. TIGRIS: A Data Model for an Object-oriented Geographic Information System. Computers and Geosciences: An international journal, 184:443451, 1992. D. Hernandez. Qualitative Representation of Spatial Knowledge, volume 804 of Lecture Notes in Arti cial Intelligence. Springer Verlag, 1994. A. Hemerly, A. Furtado, and M. Casanova. Towards Cooperativeness in Geographic Databases. In Proc 4th International DEXA Conf., pages 373376, 1993.
Her92 Her94 HFC93
184 HS92a HS92b HS94 Int90 Jai93 JBG93 JEM93 KBS93 KF92

W. Hall and D. Simmons. An Open Model for Hypermedia and Its Application to Geographical Information Systems. Computer Graphics Forum, 23, 1992. E. Hoel and H. Samet. A Qualitative Comparison Study of Data Structures for Large Line Segment Databases. In Proc. of the ACM SIGMOD Conference, pages 205214, 1992. E. Hoel and H. Samet. Performance of Data-Parallel Spatial Operations. In Proc 20th VLDB Conference, 1994. Intergraph. MGE - The Modular GIS Environment, 1990. R. Jain. NSF Workshop on Visual Information Management Systems. ACM Sigmod Record, 223:5776, 1993. W. McKenna J. Blakeley and G. Graefe. Experiences Building the Open OODB Optimizer. In Proc. of the ACM SIGMOD Conference, pages 287296, maio 1993. JEM. Environmental Assessment and the Application of Expert Systems: an Over view. Journal of Environmental Management, 39:2738, 1993. H. Kriegel, T. Brinkho , and R. Schneider. E cient Query Processing in Geo graphic Database Systems. IEEE Data Engineering Bulletin, pages 1015, 1993. I. Kamel and C. Faloutsos. Parallel R-Trees. ACM Sigmod Record, 212, 1992.
KHFM93 H. Kriegel, S. Heep, A. Fahldiek, and N. Mysliwitz. Query Processing of Geometric Objects with Free Form Boundaries in Spatial Databases. In Proc 4th International DEXA Conf., pages 349360, 1993. Kli94 Koi95 Kri91 KT92 Kuh91 A. Kliskey. A Comparative Analysis of Approaches to Wilderness Perception Map ping. Journal of Environmental Management, 41:199236, 1994. H. Koike. Fractal Views a Fractal-based Method for Controlling Information Display. ACM Trans. on Information Systems, 133:305323, 1995. H. Kriegel. Query Processing in Spatial Database Systems. In Proc. 2nd Sympo sium Spatial Database Systems, pages 172191. Springer Verlag Lecture Notes in Computer Science 525, 1991. Z. Kemp and R. Thearle. Modelling Relationships in Spatial Databases. In Proc 5th International Symposium on Spatial Data Handling, pages 313322, 1992. Volume 1. W. Kuhn. Are Displays Maps or Views? In Auto-Carto, volume 10, pages 588598, 1991.

Kuh93 Lan93a Lan93b LG93 LHM94 LL93 LMR90 LS89 LS92
185
W. Kuhn. Metaphors Create Theories for Users. In Proc. European Conference in Spatial Information Theory, pages 366376. Springer Verlag Lecture Notes in Computer Science 716, 1993. G. Langran. Issues of Implementing a Spatiotemporal System. International Jour nal of Geographical Information Systems, 74:305314, 1993. G. Langran. Time in Geographic Information Systems. Taylor & Francis, 1993. J. Lee and G. Grinstein, editors. Database Issues for Data Visualization - Proc. IEEE Visualization Workshop . Springer Verlag, 1993. Lecture Notes in Computer Science 871. P. Longley, G. Higgs, and D. Martin. The Predictive use of GIS to Model Pro perty Valuations. International Journal of Geographical Information Systems, 82:217236, 1994. Y. Leung and K. Leung. An Intelligent Expert System Shell for Knowledge-based Geographical Information Systems: 1 - the tools. International Journal of Geo graphical Information Systems, 71:189200, 1993. W. Litwin, L. Mark, and N. Roussopoulos. Interoperability of Multiple Autonomous Databases. ACM Computing Surveys, 223:297293, 1990. D. Lomet and B. Salzberg. A Robust Multi-Attribute Search Structure. In Proc. 5th International Conf. on Data Engineering, pages 296304, 1989. M. Lindholm and T. Sarjakoski. User Models and Information Theory in the Design of a Query Interface for GIS. In Proc International Conference on GIS - From Space to Territory: Theories and Methods of Spatial Reasoning, pages 328347. Springer Verlag Lecture Notes in Computer Science 639, 1992. M. Carey and D. Dewitt and M. Franklin and N. Hall and M. MacAuli e and J. Naughton and D. Schuh and M. Solomon and C. Tan and O. Tsatalos and S. White and M. Zwilling. Shoring up Persistent Objects. In Proc. of the ACM SIGMOD Conference, pages 383394, 1994. G. Magalh es. The Development of Open Systems for Engineering Applica tions. In Proc International Automated Mapping Facility Management Conference AM FM International, 1994. R. Mahoney. GIS and Utilities. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume II, pages 101114. John Wiley and Sons, 1993. M. Mediano, M. Casanova, and M. Dreux. V-Trees: A Storage Method for Spatial Data. In Proc 20th VLDB Conference, pages 321330, 1994.
M. 94
Mag94 Mah93 MCD94
186
MCS+94 C. Medeiros, G. Camara, R. Souza, U. Freitas, M. Casanova, and A. Hemerly. A Model to Manipulate Objects and Cultivate Fields. In Proc. ACM Workshop on Advances in Geographic Information Systems, pages 3037, 1994. MD91 Med95 D. Maguire and E. Dangermond. The Functionality of GIS. In D. Maguire, M. Go odchild, and D. Rhind, editors, Geographical Information Systems - volume I, pages 319335. John Wiley and Sons, 1991. M. Mediano. M todos de Acesso a Mapas com Agrupamento. Technical report, Depto. de Informatica, Puc-Rio, 1995.
MEdF94 E. Clementini M. Egenhofer and P. di Felice. Topological Relationships between Regions with Holes. International Journal of Geographical Information Systems, 82:129142, 1994. MGR93a D. Maguire, M. Goodchild, and D. Rhind, editors. Geographical Information Sys tems - volume I. John Wiley and Sons, 2 edition, 1993. MGR93b D. Maguire, M. Goodchild, and D. Rhind, editors. Geographical Information Sys tems - volume II - Applications. John Wiley and Sons, 2 edition, 1993. MGS+94 G. Magalhaes, A. Giglioni, C. Santos, D. Teijero, and E. Argondizio. Especi ca o T cnica de Convers o de Dados Proposta da Telebras Projeto SAGRE. In Anais GIS-Brasil, pages 4352, 1994. MJ93 MMS93 Mon91 Mor66 Mor92 Mou93 Mue86 MV89 C. Medeiros and G. Jomier. Managing Alternatives and Data Evolution in GIS. In Proc. ACM ISCA Workshop on Advances in Geographic Information Systems, pages 3437, 1993. P. Milne, S. Milton, and J. Smith. Geographical Object-oriented Databases: a Case Study. International Journal of Geographical Information Systems, 7:3956, 1993. M. Monmonier. How to Lie with Maps. University of Chicago Press, 1991. G. Morton. A Computer Oriented Geodetic Data Base and a New Technique in File Sequencing. Technical report, IBM Canada, 1966. S. Morehouse. The ARC INFO geographic information system. Computers and Geosciences: An international journal, 184:435443, 1992. H. Mounsey. Multisource, Multinational Environmental GIS: lessons learnt from CORINE. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume II, pages 185200. John Wiley and Sons, 1993. P. Muehercke. Map Use. JP Publications, 1986. N. Mascarenhas and F. Velasco. Processamento Digital de Imagens. Editorial Kapelusz S.A., 1989.

MW92 NCG89 NHS84 NS91 NTE92 Nye93 Obj94 OCM95 Oli95a Oli95b OM95 Ooi90 Ore86 Ore89
187
J. Morrison and K. Wortman. Cartography and Geographic Information Systems - Special Issue: Implementing the Spatial Data Transfer Standard. American Con gress on Surveying and Mapping, 195, 1992. NCGIA. The Research Plan of the National Center for Geographic Information and Analysis. International Journal of Geographical Information Systems, 32:117136, 1989. J. Nievergelt, H. Hinterberger, and K. Sevcik. The Grid File: An Adaptable, Sym metric Multikey File Structure. ACM Transactions on Database Systems, 9:3871, 1984. J. Noll and W. Scacchi. Integrating Diverse Information Repositories: A Distribu ted Hypertext Approach. IEEE Computer, 1512:3845, 1991. R. Newell, D. Theriault, and M. Easter eldy. Temporal GIS - Modeling the Evo lution of Spatial Data in Time. Computers and Geosciences: An international journal, 184:427434, 1992. T. Nyerges. Understanding the Scope of GIS: its Relationship to Environmental Modeling. In M. Goodchild, B. Parks, and L. Steyaert, editors, Environmental Modelling with GIS, pages 815. Oxford University Press, 1993. Object Management Group, Framingham, Massachussets. The Common Object Request Broker: Architecture and Speci cation, 1.2 edition, 1994. J. Oliveira, C. Cunha, and G. Magalhaes. Modelo de Objetos para Constru o de Interfaces Visuais Din micas. In Anais, IX Simp sio Brasileiro de Engenharia de Software, pages 143158, 1995. C. Oliveira. Cartas N uticas Eletr nicas: Opera es e Estruturas de Dados. Mas ter's thesis, DCC-UNICAMP, dezembro 1995. J. Oliveira. User Interface Issues in Geographic Information Systems. Technical Report 18-95, DCC - UNICAMP, dezembro 1995. J. Oliveira and C. Medeiros. A Direct Manipulation User Interface for Querying Geographic Databases. In Proc. 2nd International ADB Conference, 1995. B. Ooi. E cient Query Processing in Geographic Information Systems. Springer Verlag Lecture Notes in Computer Science, 1990. J. Orenstein. Spatial Query Processing in an Object-Oriented Database System. In Proc. of the ACM SIGMOD Conference, pages 326336, 1986. J. Orenstein. Redundancy in Spatial Databases. In Proc. of the ACM SIGMOD Conference, pages 294305, 1989.
188 Par94 Pet95 Peu93 Peu94 PM90 PMP93

E. Paredes. Sistema de Informa o Geogr ca Princ pios e Aplica es Geopro cessamento. Editora rica, 1994. M. Petre. Why Looking Isnt Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 386:3344, 1995. D. Peuquet. What, Where and When - a Conceptual Basis for Design of Spatiotem poral GIS Databases. In Proc. ACM ISCA Workshop on Advances in Geographic Information Systems, pages 117122, 1993. D. Peuquet. It's about time: A Conceptual Framework for the Representation of Temporal Dynamics in Geographic Information Systems. In Annals of the Associa tion of American Geographers, 1994. D. Peuquet and D. Marble, editors. Introductory Readings in Geographic Informa tion Systems. Taylor and Francis, 1990. N. Pissinou, K. Makki, and E. Park. Towards the Design and Development of a New Architecture for Geographic Information Systems. In Proc. 2nd International Conference on Information and Knowledge Management- CIKM, pages 565573, 1993. C. Pietrobom and A. Staa. Controle de Consist ncia em um Ambiente de Desenvol vimento de Software Distribu do com Objetos Imut veis. In Anais do IV Simp sio Brasileiro de Engenharia de Software, 1990. B. Pagel, H. Six, and H. Toben. The Transformation Technique for Spatial Objects Revisited. In Proc. 3rd International Symposium on Large Spatial Databases, pages 7388, 1993. A. Prezzoto, D. Teijero, and F. Obata. Telecommunications Outside Plant De sign Automation. In Proc. II International Congress on Information Engineering ICIE'95, pages 1415, 1995. M. Ramirez. Sistemas Gerenciadores de Banco de Dados para Geoprocessamento. Master's thesis, COPPE-UFRJ, abril 1994. N. Roussoupolos, C. Faloutsos, and T. Sellis. An E cient Pictorial Database Sys tem for PSQL. IEEE Transactions on Software Engineering, SE-145:639650, 1988. D. Rhind. Counting the People: the Role of GIS. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume II, pages 127137. John Wiley and Sons, 1993. P. Rigaux. Interfaces Graphiques pour Bases de Donnees Spatiales: Application a la Representation Multiple. PhD thesis, CEDRIC - Conservatoire National des Arts et Metiers, 1995.
PS90 PST93 PTO95 Ram94 RFS88 Rhi93 Rig95

RK91 RM92
189
J. Raper and B. Kelk. Three Dimensional GIS. In D. J. Maguire, M. F. Goodchild, and D. W. Rhind, editors, Geographical Information Systems - volume I, pages 299317. John Wiley and Sons, 1991. J. Raper and D. Maguire. Design Models and Functionality in GIS. Computers and Geosciences, 184:387400, 1992.
RND+95 B. Raoult, B. Norris, J. Daabeck, R. Souza, and G. Camara. Distributed Architec tures for Environmental Visualization Systems. In Anais, VII Simp sio Brasileiro de Computa o Gr ca e Processamento de Imagens, pages 249256, 1995. Rob81 Roc95 Rot91 RSM78 Rum91 SA93 SAI Sam89 SCR93 SDT J. Robinson. The KDB-Tree: A Search Structure for Large Multidimensional Dy namic Indexes. In Proc. of the ACM SIGMOD Conference, pages 1018, 1981. J. Rocha. Gerenciamento de Opera es Agr colas em Sistema de Informa es Geo-referenciadas. Cadernos de Inform tica Georeferenciada, 11, 1995. D. Rotem. Spatial Join Indices. In Proc. IEEE Data Engineering Conference, pages 500509, 1991. A. Robinson, R. Sale, and J. Morrison. Elements of Cartography. John Wiley & Sons, 1978. J. Rumbaugh. Object-Oriented Modeling and Design. Prentice-Hall, 1991. R. Subramanian and N. Adam. The Design and Implementation of an Expert Object-Oriented Geographic Information System. In Proc. 2nd International Con ference on Information and Knowledge Management- CIKM, pages 537546, 1993. SAIF. http: www.wimsey.com infosafe saif saifHome.html. H. Samet. The Design and Analysis of Spatial Data Structures. Addison-Wesley, 1989. L. Soares, M. Casanova, and N. Rodriguez. Um Modelo Conceitual Hiperm dia com N s de Composi o e Controle de Vers es. In Anais VII Simp sio Brasileiro de Engenharia de Software, pages 365381, 1993. SDTS. ftp: sdts.er.usgs.gov.
SFGM93 M. Stonebraker, J. Frew, K. Gardels, and J. Meredith. The Sequoia 2000 Bench mark. In Proc. of the ACM SIGMOD Conference, pages 211, 1993. SH91 P. Svensson and Z. Huang. Geo-Sal: A Query Language for Spatial Data Analysis . In Proc. 2nd Symposium Spatial Database Systems, pages 119140. Springer Verlag Lecture Notes in Computer Science 525, 1991.
190 SK90 SL90 SMJ94

B. Seeger and H-P. Kriegel. The Buddy-Tree: an E cient and Robust Accest Method for Spatial Database Systems. In Proc. 16th VLDB Conference, pages 590601, 1990. A. Sheth and J. Larson. Federated Database Systems for Managing Distri buted, Heterogeneous, and Autonomous Databases. ACM Computing Surveys, 223:183236, 1990. E. Strand, R. Mehta, and R. Jairam. Applications Thrive on Open Systems Stan dards. Standard View - ACM Perspectives on Standardization, 23:148154, 1994.
SMSE87 T. Smith, S. Menon, J. Star, and J. Estes. Requirements and Principles for the Implementatio and Construction of Large-scale Geographic Information Systems. International Journal of Geographical Information Systems, 11:1331, 1987. Sno92 SPR93 SQ93 R. Snodgrass. Temporal Databases. In Proc International Conference on GIS From Space to Territory: Theories and Methods of Spatial Reasoning, pages 2263. Springer Verlag Lecture Notes in Computer Science 639, 1992. SPRING - Manual do Usu rio. Vers o Preliminar, fevereiro 1993. R. Silva and J. Quintanilha. SIG na Gest o Municipal. In IV Confer ncia Latinoa mericana sobre Sistemas de Informa o Geogr ca, pages 353364, 1993.
SRD+91 A. Skidmore, P. Ryan, W. Dawes, D. Short, and E. O'Loughlin. Use of an Expert System to Map Forest Soils from a Geographical Information System. International Journal of Geographical Information Systems, 54:431446, 1991. SRF87 SS94 SSB95 SSKS95 T. Sellis, N. Roussopoulos, and C. Faloutsos. The R+ -Tree: A Dynamic Index for Multi-Dimensional Objects. In Proc. 13th VLDB Conference, pages 507518, 1987. R. Snodgrass and M. Soo. Bibliography on Spatiotemporal Databases. International Journal of Geographical Information Systems, 81:95103, 1994. L. Shklar, K. Shah, and C. Basu. Putting Legacy Data on the Web: A Repository De nition Language. In Third International WWW Conference, 1995. L. Shklar, A. Sheth, V. Kashyap, and K. Shah. InfoHarness: Use of Automatically Generated Metadata for Search and Retrieval of Heterogeneous Information. In Proc. CAiSE'95. Springer Verlag Lecture Notes in Computer Science 932, 1995.
STMS94 L. Shklar, S. Thatte, H. Marcus, and A. Sheth. The InfoHarness Information Integration Platform. In Second International WWW Conference, 1994. Sto93 M. Stonebraker. The SEQUOIA 2000 Project. IEEE Data Engineering Bulletin, pages 2428, 1993.

Sur94 SV92 Tam82 Thi93 TMC92 Toc95 Tom90 Tom94 Tos94 Tsa93 Tve93 Uni93 U.S92 vEU89 VM90
191
Surveys and Resource Mapping Branch - Ministry of Environment, Lands and Parks, British Columbia - Canad . Spatial Archive and Interchange Format: For mal De nition, 3.1 edition, 1994. Reference Series. M. Scholl and A. Voisard. Geographic Applications an Experience with O2. In F. Bancilhon, C. Delobel, and P. Kanellakis, editors, Building an Object-oriented System the Story of O2. Morgan Kaufmann, 1992. M. Tamminen. The Extendible Cell Method for Closest Point Problems. BIT, 22:2741, 1982. J. Thieman. The International Directory Network and Connected Data Information System for Research in the Earth and Space Sciences. In Proc. of the ACM SIGMOD Conference, pages 475478, 1993. A. Teixeira, E. Moretti, and A. Cristofoletti. Introdu o aos Sistemas de Informa o Geogr ca. Edi o de Autor, 1992. C. Tocantins. Armazenamento e Manipula o de Mapas Vetoriais em uma Arqui tetura Paralela. Master's thesis, PUC-RJ, agosto 1995. D. Tomlin. Geographic Information Systems and Cartographic Modeling. Prentice Hall, New York, 1990. H. Tom. The Geographic Systems GIS Standards Infrastructure. StandardView, 23, 1994. N. Tosta. Standards to Support the National Spatial Data Infrastructure. Stan dardView - ACM Perspectives on Standardization, 23:143147, 1994. V. Tsai. Delaunay Triangulations in TIN Creation: an Overview and a Li near time Algorithm. International Journal of Geographical Information Systems, 76:501524, 1993. B. Tversky. Cognitive Maps, Cognitive Collages, and Spatial Mental Models. In European Conference Spatial Information Theory - COSIT, pages 1424. Springer Verlag Lecture Notes in Computer Science 716, 1993. University of California. Postgres 4.1 Reference Manual, 1993. U.S. Army Construction Engineering Research Laboratory. GRASS 4.0 Program mer's Manual, 1992. J. van Eck and M. U er. A Presentation of System 9. Photogrammetry and Land Information Systems, pages 139178, mar o 1989. E. Victorelli and G. Magalh es. MVC: Um Modelo para Controle de Vers es e Con gura es. In Anais V Simp sio Brasileiro de Engenharia de Software, 1990.
192
VMS+93 K. Vadaparty, R. Molmen, H. Salem, P. Whiting, and S. Naqvi. Towards a Ful ly Sheetless GIS with Incremental Querying. In Proc. ACM ISCA Workshop on Advances in Geographic Information Systems, pages 9499, 1993. Voi91 Voi94 vOV91 VvO91 VvO92 Wan94 Web90 WH92 Whi93 A. Voisard. Towards a Toolbox for Geographic User Interfaces. In Proc. Second Symposium on Spatial Database Systems, pages 7597. Springer Verlag Lecture Notes in Computer Science 525, 1991. A. Voisard. Designing and Integrating User Interfaces of Geographic Database Ap plications. In Proc. ACM Workshop on Advanced Visual Interfaces, pages 133142, 1994. P. von Oosterom and T. Vijlbrief. Building a GIS on Top of the Open DBMS POSTGRES. In Proc European GIS Conference, 1991. T. Vijlbrief and P. von Oosterom. The GEO++ System: an Extensible GIS. In Proc European GIS Conference, 1991. T. Vijilbrief and P. van Oosterom. The GEO++ System: an Extensible GIS. In Proc. 5th International Symposium on Spatial Data Handling, pages 4050, 1992. F. Wang. Towards a Natural Language User Interface: an Approach of fuzzy Query. International Journal of Geographical Information Systems, 82:143162, 1994. C. Webster. Rule-based Spatial Search. International Journal of Geographical Information Systems, 43:241260, 1990. T. Waugh and S. Hopkins. An Algorithm for Polygon Overlay Using Cooperative Processing. International Journal of Geographical Information Systems, 66, 1992. M. White. Car Navigation Systems. In D. Maguire, M. Goodchild, and D. Rhind, editors, Geographical Information Systems - volume II, pages 115125. John Wiley and Sons, 1993.
WHM90 M. Worboys, H. Hearnshaw, and D. Maguire. Object-oriented Data Modelling for Spatial Databases. International Journal of Geographical Information Systems, 44:369384, 1990. Wol83 Woo93 Wor94a Wor94b P. Wolf. Elements of Photogrammetry. McGraw Hill Book Co., 1983. M. Wood. Human Factors in Geographic Information Systems, chapter Interfacing with Maps, pages 111123. Belhaven Press, 1993. M. Worboys. Object Oriented Approaches to Georeferenced Information. Interna tional Journal of Geographical Information Systems, 84:385400, 1994. L. Worral. Justifying Investment in GIS: a Local Government Perspective. Inter national Journal of Geographical Information Systems, 68:545566, 1994.

WSS90 ZFS89 ZM92
193
C. Woodcock, C. Shaw, and B. Shaw. Comments on Selecting a Geographic In formation System for Environmental Management. Environmental Management, 143:307315, 1990. E. Zube, S. Freedman, and D. Simcox. Landscape Change: Perceptions and Physi cal Measures. Environmental Management, 135:639644, 1989. F. Zhan and D. Mark. Object-Oriented Spatial Knowledge Representation and Processing: Formalization of Core Classes and their Relationships. In Proc 5th International Symposium on Spatial Data Handling, pages 662671, 1992. Volume 2.

Anatomia SIG

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Anatomia SIG

Enviado por

Direitos autorais:

Formatos disponíveis

Anatomia de Sistemas de Informa o Geogr ca

Divis o de Processamento de Imagens INPE

Departamento de Sistemas de Opera o CPqD TELEBR S

Instituto de Computa o UNICAMP

2 Sistemas de Informa o Geogr ca

3 Caracteriza o de Dados Geogr cos

5 Opera es sobre Dados Geogr cos

6 Recupera o de Dados Geogr cos

7 Apresenta o de Dados Geogr cos

91 91 91 94 98 99 101 102 103

9 Armazenamento de Dados Geogr cos

10 Processamento de Transa es e Consultas

13 Centros de Dados Geogr cos

Cap tulo 1 Conceitos B sicos

1.2 Conceitos de Cartogra a

CAP TULO 1. CONCEITOS B SICOS

1.2.2 Sistemas de Coordenadas

1.2. CONCEITOS DE CARTOGRAFIA

1.2.3 Proje es Cartogr cas

CAP TULO 1. CONCEITOS B SICOS

Classi ca o das Proje es

1.2. CONCEITOS DE CARTOGRAFIA

CAP TULO 1. CONCEITOS B SICOS

Figura 1.1: Proje o estereogr ca polar

Figura 1.2: Proje o c nica de Lambert

1.2. CONCEITOS DE CARTOGRAFIA

Figura 1.3: Proje o de Mercator

Figura 1.4: Proje o plana

CAP TULO 1. CONCEITOS B SICOS

Figura 1.5: Proje o c nica

Figura 1.6: Proje o cil ndrica

1.2. CONCEITOS DE CARTOGRAFIA

Proje o Albers Bipolar

Tabela 1.1: An lise comparativa das proje es

CAP TULO 1. CONCEITOS B SICOS

Figura 1.7: Cartas 1:1.000.000 - UTM

1.2.4 Mapas e Cartas

1.3. CONCEITOS DE SENSORIAMENTO REMOTO

 topogr cas: confeccionadas mediante levantamento topogr co regular, ou compila

1.3 Conceitos de Sensoriamento Remoto

CAP TULO 1. CONCEITOS B SICOS

1.3.1 Princ pios F sicos

1.3. CONCEITOS DE SENSORIAMENTO REMOTO

1.3.2 Sensores a Bordo de Sat lites

Principais sat lites no Brasil

CAP TULO 1. CONCEITOS B SICOS

1.3. CONCEITOS DE SENSORIAMENTO REMOTO

CAP TULO 1. CONCEITOS B SICOS

1.3.3 C maras Fotogr cas Aero-Transportadas

Cap tulo 2 Sistemas de Informa o Geogr ca

CAP TULO 2. SISTEMAS DE INFORMA O GEOGR FICA

2.2 Conceitos B sicos

2.2. CONCEITOS B SICOS

de qualidade. Com o advento do GPS 

CAP TULO 2. SISTEMAS DE INFORMA O GEOGR FICA

Entrada e Integr. Dados

Banco de Dados Geogrficos

Figura 2.1: Arquitetura de Sistemas de Informa o Geogr ca

2.2.2 Processo de Implanta o

2.2. CONCEITOS B SICOS

2.2.3 Breve Hist rico

CAP TULO 2. SISTEMAS DE INFORMA O GEOGR FICA

CAP TULO 2. SISTEMAS DE INFORMA O GEOGR FICA

2.3.2 Aplica es S cio-Econ micas

topogr cas: confeccionadas mediante levantamento topogr co regular, ou compila

de qualidade. Com o advento do GPS

n vel de implementa o f sico ou interno: de ne padr es, formas de armazenamento e

rialmente, no sentido da se o 5.2.2 que n o se superp em e que cobrem completamente R.

Graph. Um objeto desta classe consiste em um conjunto de conex es entre objetos da