interoperabilidade em geoprocessamento - marte3:80

MINISTÉRIO DA CIÊNCIA E TECNOLOGIA
INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS
INPE-7266-TDI/708
INTEROPERABILIDADE EM GEOPROCESSAMENTO:
CONVERSÃO ENTRE MODELOS CONCEITUAIS DE SISTEMAS
DE INFORMAÇÃO GEOGRÁFICA E COMPARAÇÃO COM O
PADRÃO OPEN GIS
Rogério Thomé
Dissertação de Mestrado em Computação Aplicada, orientada pelo Dr. Gilberto Câmara
Neto, aprovada em 29 de setembro de 1998.
INPE
São José dos Campos
1999
681.3 : 621.376.5
THOMÉ, R.
Interoperabilidade em geoprocessamento: conversão
entre modelos conceituais de sistemas de informação geográfica e comparação com o padrão OPEN GIS / R. Thomé. – São José dos Campos: INPE, 1998.
196p. - (INPE-7266-TDI/708).
1.Sistemas de informação geográfica (SIG). 2.Interoperabilidade. 3.Geoprocessamento. 4.Sistemas de informação geográfica abertos (OPEN GIS). 5.ArcInfo. 6.Modular
GIS environment (MGE). 7.Sistema de processamento de
informações georreferenciadas (SPRING). 8.Representação
do conhecimento. 9. Modelos. I.Título.
Aprovado pela Banca Examinadora
em cumprimento a requisito exigido
para a obtenção do Título de Mestre
em Computação Aplicada.
Candidato: Rogério Thomé
São José dos Campos, 29 de setembro de 1998.
“ A vida na Terra teria surgido há 3,5 bilhões de anos. Se esse período for
comparado a um único ano, o primeiro réptil só teria aparecido na metade de
dezembro. Isso dá uma idéia do tempo que a vida, que surgiu no mar,
demorou para diversificar-se e evoluir. O problema agora é o homem
industrializado: mesmo tendo chegado apenas nos últimos 2 segundos desse
ano imaginário, ele ameaça a impressionante arquitetura da natureza.”
Caminhos da Terra, p. 64, dezembro de 1996.
À minha esposa e companheira
Adriana,
Ao meu filho, luz e vida
Ruan,
Aos meus pais
Carmen e Oswaldo.
AGRADECIMENTOS
Agradeço a Deus por me ter concedido a oportunidade desta vida, por me ter
dado este corpo perfeito e saudável para que pudesse desenvolver-me e
contribuir de alguma forma para a nossa humanidade.
Agradeço a minha esposa Adriana pela força, paciência e dedicação.
Aos meus pais Oswaldo e Carmen pelo incentivo e compreensão.
A Erli e ao Cursino pelo auxílio e paciência incessantes.
Ao meu orientador Dr. Gilberto Câmara, pela confiança e por todo o
conhecimento transferido.
A todas as pessoas do DPI/INPE que contribuíram para a realização deste
trabalho.
Ao Dr. Tatuo pela colaboração neste trabalho.
As empresas Imagem e Intersat, pela oportunidade de transformar muitos
conceitos em realidade prática.
A empresa Geoambiente por nos proporcionar um ambiente fértil para
contribuir ainda mais na área de geoprocessamento.
RESUMO
O objetivo deste trabalho é analisar o problema da interoperabilidade em
Geoprocessamento, tomando por base a tecnologia atual de Sistemas de
Informação Geográfica (SIG). A partir de uma análise dos modelos conceituais
de diferentes SIGs, e da especificação do padrão OPEN GIS, o trabalho
apresenta uma conversão entre estes modelos conceituais e uma análise dos
problemas de sua tradução para os conceitos OPEN GIS. Para materializar as
idéias apresentadas, desenvolveu-se o protótipo de uma ferramenta de
tradução entre estes modelos conceituais.
INTEROPERABILITY IN GEOGRAPHIC INFORMATION SYSTEMS:
CONVERSION AMONG GEOGRAPHIC INFORMATION SYSTEMS
CONCEPTUAL MODELS AND A COMPARISON WITH THE OPEN GIS
STANDARD
ABSTRACT
This work discusses the problem of interoperability in Geographic Information
Systems (GIS), trying to identify the potential pratical barriers which limit the
complete interchange of geographical information. The semantic models of
three differents GIS are described and compared with each other and with the
OPEN GIS concepts. These comparisons allow an assessment of the problems
and limitations of the semantic translation on the GIS domain. To illustrate the
ideas established, a prototype for GIS semantic model conversion has been
developed.
SUMÁRIO
LISTA DE FIGURAS
LISTA DE TABELAS
Pág.
CAPÍTULO 1 - INTRODUÇÃO ......................................................................... 25
1.1 - Motivação ................................................................................................. 26
1.2 - Objetivo do Trabalho ................................................................................ 27
1.3 - Breve Revisão da Literatura ..................................................................... 28
1.4 - Metodologia de Trabalho.......................................................................... 31
1.5 - Contribuição do trabalho .......................................................................... 32
1.6 - Estrutura da dissertação........................................................................... 33
CAPÍTULO 2 - GEOPROCESSAMENTO ........................................................ 35
2.1 - Histórico ................................................................................................... 35
2.2 - Sistemas de Informação Geográfica - SIG............................................... 39
2.2.1 - Definição ............................................................................................... 39
2.2.2 - Arquitetura de SIG................................................................................. 40
2.2.3 - Modelagem de Dados Geográficos ....................................................... 43
2.2.4 - Banco de Dados Geográfico ................................................................. 46
2.2.4.1 - Arquitetura dual ................................................................................. 46
2.2.4.2 - Arquitetura Baseada em Campos Longos.......................................... 48
2.2.4.3 - Arquitetura Baseada em Mecanismos de Extensão........................... 49
2.2.5 - Topologia em SIG ................................................................................. 50
2.2.5.1 - Estrutura de Dados Arco-Nó .............................................................. 52
2.2.5.2 - Conectividade..................................................................................... 53
2.2.5.3 - Definição de Área............................................................................... 55
2.2.5.4 - Contiguidade ...................................................................................... 56
CAPÍTULO 3 - MODELAGEM ORIENTADA POR OBJETOS......................... 57
3.1 - Introdução a Modelagem de Dados ......................................................... 57
3.2 - Abstração de Dados ................................................................................. 60
3.3 - Técnica de Modelagem de Objetos.......................................................... 60
3.3.1 - Objeto, Atributo e Operações ................................................................ 61
3.3.2 - Classes.................................................................................................. 62
3.3.3 - Associações, Ligação e Multiplicidade .................................................. 63
3.3.4 - Atributo de Ligação ............................................................................... 64
3.3.5 - Agregação ............................................................................................. 65
3.3.6 - Generalização, Especialização e Herança ............................................ 66
3.3.7 - Polimorfismo.......................................................................................... 68
3.4 - Persistência de Objetos em Ambientes Relacionais ............................... 69
3.4.1 - Mapeamento de Classes....................................................................... 69
3.4.2 - Mapeamento de Associações Muitos para Muitos ............................... 70
3.4.3 - Mapeamento de Associações Um para Muitos ..................................... 71
3.4.4 - Mapeamento de Associações Um para Um .......................................... 74
3.4.5 - Mapeamento de Generalizações........................................................... 75
CAPÍTULO 4 - MODELAGEM DE DADOS EM SISTEMAS DE INFORMAÇÃO
GEOGRÁFICA ......................................................................... 81
4.1 - MGE ......................................................................................................... 81
4.1.1 - Conceitos e Fundamentos .................................................................... 81
4.1.2 - Arquitetura do Sistema .......................................................................... 81
4.1.3 - Projeto ................................................................................................... 83
4.1.3.1 - Esquema ............................................................................................ 84
4.1.3.2 - Categorias e Classes de Feições....................................................... 84
4.1.3.3 - Representação da Informação Gráfica .............................................. 84
4.1.3.4 - Representação da Informação Não-Gráfica....................................... 86
4.1.4 - Modelagem de Dados MGE .................................................................. 87
4.1.5 - Topologia no MGE ............................................................................... 90
4.2 - ARC/INFO ................................................................................................ 93
4.2.1 - Conceitos e Fundamentos .................................................................... 93
4.2.2 - Modelo de Dados Vetorial ..................................................................... 94
4.2.2.1 - Topologia no Arc/Info ......................................................................... 95
4.2.2.2 - Regiões .............................................................................................. 96
4.2.2.3 - Rotas .................................................................................................. 97
4.2.2.4 - Representação das Informações Descritivas ..................................... 97
4.2.3 - Coverage............................................................................................. 100
4.2.4 - Outras Representações....................................................................... 100
4.3 - SPRING.................................................................................................. 101
4.3.1 - Apresentação ...................................................................................... 101
4.3.2 - Arquitetura do Sistema ........................................................................ 103
4.3.3 - Modelo Conceitual do SPRING ........................................................... 105
4.3.4 - Topologia no SPRING ......................................................................... 110
4.4 - O Padrão OPEN GIS.............................................................................. 110
4.4.1 - Conceito .............................................................................................. 110
4.4.2 - O Conceito de Comunidade de Informação Geo-espacial .................. 112
4.4.3 - Feição e conceitos associados............................................................ 113
4.4.3.1 - Noção Geral de Informação Geo-espacial ....................................... 114
4.4.3.2 - Especificação Abstrata de Feições .................................................. 117
4.4.3.3 - Tipos de Feições .............................................................................. 117
4.4.3.4 - Atributos de Feições......................................................................... 117
4.4.3.5 - Identidade das Feições .................................................................... 118
4.4.3.6 - Persistência de Feições ................................................................... 118
4.4.3.7 - Instância de Feições ........................................................................ 118
4.4.3.8 - Coleção de Feições.......................................................................... 118
4.4.4 - Feição com Geometria ........................................................................ 119
4.4.4.1 - Geometria......................................................................................... 120
4.4.5 - Coverage............................................................................................. 121
4.4.5.1 - Propriedades .................................................................................... 122
4.5 - Comparação entre os SIGs e o padrão OGIS........................................ 124
4.5.1 - MGE e OGIS ....................................................................................... 124
4.5.1.1 - Feição com Geometria ..................................................................... 124
4.5.1.2 - Coverage.......................................................................................... 125
4.5.2 - Arc/Info e OGIS ................................................................................... 125
4.5.2.1 - Feição com geometria ...................................................................... 125
4.5.2.2 - Coverage.......................................................................................... 125
4.5.3 - SPRING e OGIS.................................................................................. 126
4.5.3.1 - Feição com geometria ...................................................................... 126
4.5.3.2 - Coverage.......................................................................................... 127
4.5.3.3 - Uma breve conclusão....................................................................... 127
CAPÍTULO 5 - INTEROPERABILIDADE SEMÂNTICA ENTRE SIGS .......... 129
5.1 - Introdução .............................................................................................. 129
5.2 - Metodologia de Desenvolvimento do GeoTMS ..................................... 130
5.3 - Especificação Informal do Sistema ........................................................ 131
5.3.1 - Propósito do GeoTMS ......................................................................... 131
5.3.2 - Modelo Descritivo do GeoTMS............................................................ 131
5.3.3 - Diagrama de Contexto do Sistema...................................................... 131
5.3.4 - Resumo dos Requisitos do Sistema.................................................... 132
5.4 - Especificação Formal do Sistema .......................................................... 134
5.4.1 - Visão Funcional ................................................................................... 134
5.4.2 - Visão Estática...................................................................................... 137
5.4.2.1 - Objetos Gráficos............................................................................... 137
5.4.2.2 - Regras Conceituais .......................................................................... 138
5.4.2.2.1 - O Padrão OGIS ............................................................................. 138
5.4.2.2.2 - MGE .............................................................................................. 139
5.4.2.2.3 - ARC/INFO ..................................................................................... 139
5.4.2.2.4 - SPRING......................................................................................... 141
5.4.2.3 - Tabelas de Conversão ..................................................................... 142
5.4.2.3.1 - Considerações Iniciais................................................................... 143
5.4.2.3.2 - MGE para OGIS ............................................................................ 144
5.4.2.3.3 - ARC/INFO para OGIS ................................................................... 147
5.4.2.3.4 - SPRING para OGIS....................................................................... 149
5.4.2.3.5 - MGE para SPRING e vice e versa ................................................ 152
5.4.2.3.6 - MGE para ARC/INFO e vice e versa ............................................. 153
5.4.2.3.7 - ARC/INFO para SPRING e vice e versa ....................................... 154
5.4.2.4 - Modelo.............................................................................................. 159
5.4.2 - Visão de Dinâmica .............................................................................. 159
5.5 - Projeto do GeoTMS................................................................................ 160
5.5.1 - Diagrama de Estrutura do Módulos..................................................... 161
5.5.2 - Modelo Relacional ............................................................................... 161
5.5.2.1 - Objetos Gráficos............................................................................... 161
5.5.2.2 - Regras Conceituais .......................................................................... 163
5.5.2.3 - Tabela de Conversão ....................................................................... 163
5.5.2.3 - Modelos............................................................................................ 164
5.6 - Implementação....................................................................................... 165
CAPÍTULO 6 - CONCLUSÃO ........................................................................ 173
6.1 - Diferenças Conceituais entre os SIGs do mercado................................ 174
6.2 - Alcance e Limitações do padrão OPEN GIS .......................................... 175
6.3 - Interoperabilidade na Prática.................................................................. 177
6.4 - Estudos Futuros ..................................................................................... 178
REFERÊNCIAS BIBLIOGRÁFICAS............................................................... 181
APÊNDICE A - QUESTIONÁRIO DADO AO USUÁRIO E AO
DESENVOLVEDOR .............................................................. 187
APÊNDICE B - TABULAÇÃO DAS RESPOSTAS: QUESTIONÁRIO
DADO AO USUÁRIO E AO DESENVOLVEDOR.................. 189
LISTA DE FIGURAS
Pág.
1.1 - Utilização de um Esquema Conceitual Global para Facilitar Comunicação
a
de Informações entre Modelos de Dados Específicos ............................. 31
2.1 - Exemplo de Geoprocessamento .............................................................. 38
2.2 - Módulo de Entrada de Dados de um SIG................................................. 41
2.3 - Módulo de Armazenagem de Dados e Gerenciamento
de Banco de Dados Geográficos.............................................................. 42
2.4 - Questões a Serem Respondidas por um SIG .......................................... 42
2.5 - Módulo de Saída de um SIG .................................................................... 43
2.6 - Representação de Fenômenos Geográficos............................................ 44
2.7 - Arquitetura Dual para Banco de Dados Geográficos ............................... 47
2.8 - Ilustração da Representação Computacional da Estrutura de Arco-Nó ... 53
2.9 - IIustração do Conceito de Conectividade de Topologia Arco-Nó ............. 54
2.10 - Ilustração da Representação Computacional da Estrutura PolígonoArco ........................................................................................................ 55
2.11 - Ilustração da Topologia Direita-Esquerda .............................................. 56
3.1 - As Três Visões de um Sistema ................................................................ 59
3.2 - Notação Gráfica TMO .............................................................................. 63
3.3 - Exemplos de Associação e Multiplicidade................................................ 64
3.4 - Exemplos de Atributo de Ligação............................................................. 65
3.5 - Conceito de Agregação Aplicado a um Exemplo de Projeto de Casa...... 65
3.6 - Exemplo de Especialização e Herança .................................................... 66
3.7 - Exemplo de Herança Múltipla: a Classe “Veículo Anfíbio” Possui Duas s
s
SuperClasses .......................................................................................... 68
3.8 - Novo Modelo Ajustado para Evitar a Herança Múltipla ............................ 68
3.9 - Mapeamento de Classes em Tabelas ...................................................... 70
3.10 - Mapeamento de Associações “Muitos para Muitos” para Tabelas......... 71
3.11 - Mapeamento de Associações “Um para Muitos” do Caso 1 .................. 72
3.12 - Mapeamento de Associações “Muitos para Muitos” do Caso 2 ............. 73
3.13 - Primeira Alternativa para Mapear Associações “Um para um” em
p
p p
Tabelas - Caso 1 .................................................................................... 75
3.14 - Segunda Alternativa para Mapear Associações “Um para Um” em p p
p
Tabelas - Caso 2 ................................................................................... 76
3.15 - Exemplo de Generalização-Especialização: Ponto, Nó e Vértice .......... 77
3.16 - Mapeamento de Generalização Especialização em Tabelas de a a a
aa
Generalização e em Tabelas de Especialização - Caso 1 ..................... 77
3.17 - Mapeamento de Generalização-Especialização em Tabelas de n
n
nn
Generalização e em Tabelas de Especialização - Caso 2 ..................... 78
3.18 - Mapeamento de Generalização-Especialização em Tabelas de a a
a
a
a
Generalização ........................................................................................ 79
4.1 - Arquitetura do Sistema MGE.................................................................... 83
4.2 - A Representação de Fenômenos Geográficos no MGE: Classe de Feição
a
e Categoria .............................................................................................. 85
4.3 - Organização Hierárquica de Dados Geográficos no MGE ....................... 87
4.4 - Exemplo de Organização de Dados no MGE........................................... 89
4.5 - Modelo de Dados Implementados no MGE para Arquivo de Mapas........ 90
4.6 - Ilustração do Conceito de Índice Geográfico............................................ 91
4.7 - Modelo de Dados do MGE que Reflete o Conceito de Arquivo de Índice a
a
Geográfico ................................................................................................ 92
4.8 - Exemplo de Análise Espacial no MGE ..................................................... 93
4.9 - Ilustração da Representação Computacional de Dados Vetoriais no a a
a
ARC/INFO ............................................................................................... 95
4.10 - Ilustração do Conceito de Região .......................................................... 96
4.11 - ILustração do Conceito de Rota ............................................................. 97
4.12 - Ilustração da Representação das Informações Descritivas.................... 99
4.13 - Exemplo de uma Coverage: Propriedade ............................................ 102
4.14 - Modelo Orientado por Objetos do SPRING.......................................... 106
4.15 - Os Nove Níveis de Abstração Definidos pelo OGIS............................. 115
4.16 - Feição OGIS e seus Subtipos .............................................................. 116
4.17 - Uma Forma de Representação de Feições Geográficas ..................... 120
4.18 - Subtipos de Coverage .......................................................................... 123
4.19 - Modelo Semântico que se Aproxima da Especialização OPEN GIS.... 124
5.1 - Diagrama de Contexto do Sistema......................................................... 133
5.2 - Visão Funcional: Diagrama de Fluxo de Dados do Sistema GeoTMS ... 135
5.3 - Visão Estática: Modelagem dos Objetos Gráficos ................................. 137
5.4 - Visão Estática: Modelagem dos Tipos de Regras Conceituais .............. 138
5.5 - Visão Estática: Modelagem das Regras Conceituais OGIS ................... 139
5.6 - Visão Estática: Modelagem das Regras Conceituais MGE.................... 140
5.7 - Visão Estática: Modelagem das Regras Conceituais ARC/INFO ........... 141
5.8 - Visão Estática: Modelagem das Regras Conceituais SPRING .............. 142
5.9 - Visão Estática: Classe Modelos Onde São Armazenadas as Ocorrências
d
de Modelos Conceituais Desenvolvidos pelo Usuário do Sistema ......... 159
5.10 - Visão Dinâmica: Diagrama de Transição de Estados .......................... 160
5.11 - Diagrama de Estrutura dos Módulos .................................................... 162
5.12 - Ambiente Padrão do GeoTMS ............................................................. 166
5.13 - Menu Arquivo e Suas Opções.............................................................. 166
5.14 - Menu “Exibir” e Suas Opções............................................................... 167
5.15 - Tipo de Relacionamentos Disponíveis pelo GeoTMS .......................... 167
5.16 - Menu “Consistência”, Opção para Verificar Consistência do Modelo s s
s
Conceitual do Usuário.......................................................................... 167
5.17 - Opção Para a Tradução do Modelo Conceitual do Usuário ................. 168
5.18 - Interface de Seleção de SIG ................................................................ 168
5.19 - Classes de Dados do MGE Disponibilizadas ao Usuário do Sistema para
s
Elaborar o Modelo Conceitual.............................................................. 169
5.20 - Classes de dados do ARC/INFO disponibilizadas ao usuário do sistema
d
para elaborar o modelo conceitual ...................................................... 169
5.21 - Classes de dados do SPRING disponibilizadas ao usuário do sistema a
a
para elaborar o modelo conceitual ...................................................... 170
5.22 - Exemplo de modelo conceitual elaborado pelo usuário no SIG MGE.. 171
5.23 - Exemplo de tradução do modelo conceitual do MGE para o OGIS ..... 171
5.24 - Exemplo de tradução do modelo conceitual do MGE para o SIG s
s
s
ARC/INFO............................................................................................ 172
5.25 - Exemplo de tradução do modelo conceitual do MGE para o SIG
a
SPRING............................................................................................... 172
A.1 - Questionário dado ao usuário ................................................................ 187
A.2 - Questionário dado ao desenvolvedor .................................................... 188
B.1- Esboço do Modelo Conceitual Apresentado aos Desenvolvedores para a
a
Validação e Ajustes ............................................................................... 195
B.2- Esboço do Modelo de Dados Que Foi Apresentado aos Desenvolvedores
a
Para Validação e Ajustes ....................................................................... 196
LISTA DE TABELAS
Pág.
4.1 - Quadro Comparativo Entre os Três SIGs e os Conceitos Feição Com
d
Geometria e Coverage do OGIS ............................................................ 128
5.1 - Resumo dos Requisitos a Serem Atendidos pelo GeoTMS ................... 133
5.2 - Tabela de Conversão ............................................................................. 143
5.3 - Tabela de Conversão de MGE para OGIS............................................. 145
5.4 - Tabela de Conversão de ARC/INFO para OGIS .................................... 147
5.5 - Tabela de Conversão do SPRING para OGIS ....................................... 149
5.6 - Tabela de Conversão do MGE para SPRING e Vice-Versa................... 152
5.7 - Tabela de Conversão do MGE para o ARC/INFO e Vice-Versa ............ 153
5.8 - Tabela de tradução de ARC/INFO para SPRING e Vice-Versa ............. 155
5.9 - Objetos Gráficos..................................................................................... 162
5.10 - Regras Conceituais .............................................................................. 163
5.11 - Tabela de Conversão ........................................................................... 164
5.12 - Modelos................................................................................................ 164
B.1 - Formação dos Usuários Entrevistados .................................................. 189
B.2 - Tempo de Contato com Sistemas Informatizados ................................. 189
B.3 - Tempo de Contato com o SPRING....................................................... 189
B.4 - Aplicação do Sistema ............................................................................ 190
B.5 - Solução de Problemas ........................................................................... 190
B.6 - Ponto Frágil no Sistema......................................................................... 190
B.7 - Eficiência do Sistema............................................................................. 190
B.8 - Pontos Fortes no Sistema...................................................................... 191
B.9 - Outros Sistemas Conhecidos pelos Entrevistados ................................ 191
B.10 - Formação dos Entrevistados ............................................................... 191
B.11 - Responsabilidade dos Entrevistados ................................................... 192
B.12 - Utilização de Metodologia de Engenharia de Software........................ 192
B.13 - Geração de Disponibilidade de Modelos ............................................. 192
B.14 - Validação de Modelo Existente............................................................ 193
B.15 - Conhecimento da Estrutura de Base de Dados................................... 193
B.16 - Validação da Estrutura de Base de Dados Existente .......................... 193
B.17 - Eficácia do Sistema em Relação ao Tempo de Resposta ................... 193
B.18 - Eficiência do Sistema em Relação ao Tempo de Resposta ................ 194
B.19 - Destaque dos Pontos que Merecem Maior Atenção............................ 194
CAPÍTULO 1
INTRODUÇÃO
A atuação do homem no meio ambiente, ao longo da história, fornece provas
de suas ações em nome do progresso. Esta evolução tem seu lado positivo,
pois abre novos horizontes, novas possibilidades e descobertas, e o lado
negativo, pois pode causar desequilíbrios econômicos, ecológicos e sociais.
Desta forma, o próprio homem, fazendo uso do seu principal atributo, a
inteligência, vem criando mecanismos para controlar, sanar e prevenir tais
desequilíbrios. Neste sentido emerge uma área de estudos e aplicações,
denominada “Geoprocessamento”.
Geoprocessamento, pelo significado do próprio nome (Geo = Terra, Processar
= Executar, Realizar, Mudar), processa informações sobre a superfície terrestre
através de ferramentas computacionais ou não. Estes processos auxiliam o
homem na monitoração, administração e planejamento do espaço geográfico
em que vive. Os sistemas computacionais com estes propósitos são
conhecidos como Sistemas de Informação Geográfica (SIG).
Pelas razões apontadas acima nos sentimos conscientes e motivados a
contribuir nesta área, com este trabalho de dissertação de mestrado. A
elaboração de tal trabalho é resultado de nossa formação associada à
experiência adquirida no Instituto Nacional de Pesquisas Espaciais (INPE) em
cursos, pesquisas, trabalhos e conversas com pessoas de conhecimento de
áreas
como
engenharia
de
software,
processamento
sensoriamento remoto e geoprocessamento entre outros.
25
de
imagens,
1.1 - Motivação
Na prática atual a concepção e a implementação de projetos na área de
Geoprocessamento segue regras conceituais vinculadas à ferramenta
computacional selecionada. Entendemos por regras conceituais a semântica
do funcionamento de cada SIG, e a maneira como os dados devem estar
organizados, levando em consideração o tipo de cada dado, para o adequado
tratamento pelo SIG adotado.
Tendo em vista a diversidade dos modelos conceituais dos SIGs, muitas
organizações, por deter apenas o conhecimento de um sistema, acabam por
utilizar, para efeitos de modelagem, a terminologia específica deste sistema.
Este tipo de prática é comum no mercado e acaba por impor barreiras de
comunicação entre os diferentes produtores de informação georeferenciada.
Esta situação é fonte de muitos problemas, incluindo:
• a conversão de dados entre organizações que utilizam SIGs distintos
torna - se extremamente trabalhosa e
• organizações receptoras de tecnologias ficam condicionadas ao uso de
um único sistema e à adoção de uma terminologia que pode desrespeitar
seus próprios aspectos culturais e técnicos.
Neste cenário, é cada vez maior o interesse por soluções que permitam o
acesso amplo a diferentes bancos de dados geográficos. Entre as soluções
possíveis, a proposta do consórcio OPEN GIS merece especial destaque. O
OPEN GIS (ou OGIS) é um padrão de interoperabilidade entre SIGs, baseado
em conceitos de orientação por objetos, que estabelece mecanismos
padronizados para acesso a informações geográficas.
26
No entanto, a implantação do modelo OGIS não poderá ser imediata. Como
existem enormes bases de dados geográficas armazenadas em formatos
proprietários, prevê-se um processo de migração paulatino pelas diferentes
instituições que detêm repositórios de dados geográficos.
Neste sentido, consideramos importante estabelecer uma correspondência
entre os conceitos utilizados na modelagem de dados de diferentes sistemas e
o padrão OGIS. Como se verá no decorrer deste trabalho, há uma grande
diferença entre as terminologias adotadas por estes sistemas, o que dificulta
sobremaneira a difusão da informação geográfica.
1.2 - Objetivo do Trabalho
O estudo realizado analisará três dos principais SIGs disponíveis no Brasil
(ARC/INFO-ESRI, MGE-INTERGRAPH e SPRING-INPE), discutindo em
detalhe o modelo conceitual de cada um, e procurando estabelecer uma
correspondência entre estes conceitos e o padrão OGIS. Como se verá, a
tradução entre os diferentes sistemas, e destes para o padrão OGIS não é
direta, e possui algumas ambigüidades e indefinições que este trabalho
procura abordar.
Em função da análise realizada, será desenvolvida uma ferramenta
computacional (GeoTMS), como protótipo, que pretende auxiliar na tradução
entre os modelos semânticos de diferentes sistemas e na migração de bancos
de dados existentes para o padrão OGIS. Além de sua relevância para o
problema geral da interoperabilidade, esta ferramenta terá grande valor prático.
27
1.3 - Breve Revisão da Literatura
Este trabalho insere-se na área científica de geoprocessamento. Por tratar-se
de uma área relativamente recente e em consolidação, o contexto é dinâmico,
logo sujeito a discussões e questionamentos entre as diversas visões. A
padronização deste universo é um processo em desenvolvimento. Os trabalhos
semelhantes na literatura abrangem características teóricas e práticas
separadamente, constituindo relatos de experiências específicas. A seguir,
tem-se uma descrição de trabalhos considerados relevantes para o propósito
desta dissertação, constituindo uma base preliminar de estudos para situar
este trabalho.
A interoperabilidade constitui a capacidade de compartilhar e trocar
informações e processos entre ambientes computacionais heterogêneos,
autônomos e distribuídos (Yuan, 1998). No entanto, a exequibilidade deste
conceito na área de geoprocessamento
é complexa pois existem
incompatibilidades de representação, de estrutura e de semântica, que
impedem esta prática.
Segundo Yuan (1998), existem três aspectos a serem abordados que são
necessários para a interoperabilidade: sintático, semântico e software. O
aspecto sintático esforça-se por padronizar a codificação e a interpretação da
informação geográfica oriunda de diferentes formatos. Isto permite que um
sistema compreenda o significado de dados provenientes de outros sistemas.
Trata-se dos padrões de transferência de dados tais como SDTS, DXF, MIF,
SAIF, etc..
Apesar do aspecto sintático caminhar no sentido de facilitar a transformação
de dados de diferentes sistemas, ocorrem limitações, provenientes do aspecto
semântico, que barram este desenvolvimento. A representação conceitual da
informação geográfica que cada sistema possui é denominada de aspecto
28
semântico. Estas limitações decorrem da considerável distância existente entre
as comunidades de diferentes culturas e história, que acabam por
conceitualizar e interpretar distintamente a realidade geográfica.
No aspecto de software ou operacional, espera-se uma inclinação das
organizações produtoras de software no sentido de atender aos requisitos de
interoperacionalidade.
Hoje
existe
uma
proposta,
em
construção,
de
especificação destes requisitos, que é o OPEN GIS. Esta proposta exige que
os softwares migrem seus ambientes para este padrão.
Atualmente
não
existem
sistemas
que
atendam
por
completo
as
especificações do OPEN GIS. O que ocorre comumente são funcionalidades
de importação e exportação de formatos intercambiáveis que exploram o
aspecto sintático. Podemos citar o software GeoMedia como um exemplo de
produto que caminha no sentido da interoperação completa. Para mais
detalhes sobre este software pode-se consultar Intergraph (1998).
Yuan (1998) sugere a construção de um modelo conceitual genérico para SIG,
que seria usado para definir elementos responsáveis pelo compartilhamento da
informação espacial entre os SIGs específicos existentes. Os aspectos
sintáticos
e
software
serão
consideradas
em
fases
futuras
pois
a
compatibilidade semântica é fundamental para interoperabilidade.
Segundo Garhegan (1998), o significado semântico dos dados espacias não é
o mesmo nos modelos dos diferentes SIGs existentes. Como decorrência
disto, a transformação de dados espaciais de um sistema para outro pode
acarretar inconsistências lógicas caso seja enfocada somente a sua geometria.
Gahegan (1998) propõe uma notação para descrever as diferenças semânticas
entre os diversos SIGs e auxiliar o processo de interoprabilidade.
Além da diferença semântica intrínseca ao modelo do sistema, existem outras
desenvolvidas pelo próprio usuário do sistema na interpretação de um
fenômeno geográfico para fins de modelagem. Para ilustrar, podemos citar o
29
exemplo de usuários que podem modelar “solos” utilizando um mesmo SIG, de
maneiras diferentes. Estas diferenças são decorrentes do atendimento de
propósitos diferentes. No entanto na ocorrência da migração de dados entre os
sistemas deve-se ter cuidado com estas barreiras semânticas.
Voisard (1998) propõe a construção de um GIS genérico e aberto, em
atendimento aos requisitos de interoperabilidade. Esta construção baseia-se
na decomposição do mundo real em quatro níveis de abstração: aplicação,
serviços abstratos, serviços concretos e sistemas. No nível de aplicação serão
atendidos os requisitos do usuário final. No nível de serviços abstratos serão
abordados aspectos de alto nível do sistema e estabelecimento de uma
plataforma lógica de integração de dados. Já o nível de serviços concretos terá
a responsabilidade de especificar a distribuição dos dados e operações. Por
fim o nível de sistema se compromete por executar serviços de sistemas
específicos.
Gooldchild et al (1998) afirma que o compartilhamento de dados, o treinamento
de usuário e o compartilhamento de procedimentos de utilização são aspectos
complexos de serem praticados entre diferentes sistemas. Isto é reflexo da
independência existente durante a construção dos sistemas de informações
geográficas, ocorrendo pouco intercâmbio de teoria e terminologia. Segundo o
autor, o termo “interoperabilidade” sugere
um mundo ideal no qual esses
problemas irão desaparecer ou, pelo menos, diminuir significativamente,
resultado de uma mudança fundamental nos projetos, abordagens e filosofia.
1.4 - Metodologia de Trabalho
Uma abordagem para solucionar o problema da interoperabilidade é o
estabelecimento de um modelo conceitual que possa servir de referência para
30
a tradução sistemas distintos (Yuan, 1998). Os conceitos semânticos de cada
sistema a ser analisado seriam traduzidos para o modelo conceitual geral, o
que tornaria mais fácil sua expressão em um outro sistema, como ilustrado
pela Figura 1.1.
SISTEMA A
SISTEMA B
ESQUEMA
CONCEITUAL
GLOBAL
ESQUEMA
CONCEITUAL
GLOBAL
SOFTWARE
ESPECÍFICO
MODELO DE DADOS A1
MODELO DE DADOS A2
MODELO DE DADOS A3
SOFTWARE
ESPECÍFICO
MODELO DE DADOS B1
MODELO DE DADOS B2
MODELO DE DADOS B3
Fig. 1.1 - Utilização de um esquema conceitual global para facilitar
comunicação de informações entre modelos de dados específicos.
FONTE : adaptada de Yuan (1998).
O desenvolvimento metodológico deste trabalho segue esta proposta. Com
base para um modelo conceitual de caráter geral, adotamos a abordagem mais
aceita pela comunidade, que estabelece a distinção da informação geográfica
em campos (variáveis contínuas) e objetos (elementos discretos), como
proposto em Goodchild (1992), Worboys (1995) e Câmara (1995). Este modelo
está descrito em maior detalhe no Capítulo 2 do trabalho e está sendo
adotado, com alguns ajustes, pelo consórcio OPENGIS.
31
1.5 - Contribuição do trabalho
Este trabalho contribui para a área de geoprocessamento sob as perspectivas
teóricas e práticas. Na perspectiva teórica podemos citar:
1) A investigação e o esclarecimento de conceitos provenientes da
especificação padrão OPENGIS, referência para a modelagem de SIGs
abertos e interoperáveis.
2) A realização de um estudo de aderência e tradução de três SIGs de
mercado (ARC/INFO, MGE e SPRING) para o padrão OGIS, sob a visão
semântica.
3) A tradução semântica entre os SIGs anteriormente citados.
4) Análise e justificativas das compatibilidades e incompatibilidades
semânticas decorrentes do processo de tradução realizados nos dois itens
anteriores. O grau de automação e interferência do usuário nas traduções
é determinado por estas análises.
Na perspectiva prática podemos citar as seguintes contribuições:
• fornecimento de uma noção do grau de aplicabilidade prática da idéia de
interoperabilidade semântica e
• desenvolvimento de uma ferramenta computacional, como protótipo, para
auxiliar a interoperabilidade semântica entre os SIGs citados e entre estes
e o padrão OGIS.
As traduções semâticas apresentadas neste trabalho são um reflexo de um
estudo e posterior análise das terminologias que definem a semântica dos
32
SIGs citados e do padrão OGIS. Dado a grande distância existente entre estas
terminologias, colocamos esta tradução como uma opção, não excluindo a
existência de outras possíveis traduções.
1.6 - Estrutura da Dissertação
Esta dissertação divide-se em sete capítulos. No primeiro Capítulo é realizado
uma introdução ao trabalho.
No segundo Capítulo será apresentado um histórico sobre geoprocessamento.
Serão levantadas definições e características de Sistemas de Informações
Geográficas - SIGs. As diferentes arquiteturas de banco de dados geográficos
para a construção de SIGs também serão abordadas.
No terceiro Capítulo será apresentada a técnica de modelagem de objetos
(TMO) e algumas diretrizes para mapear o modelo de objetos em um ambiente
relacional. Este capítulo fornece um alicerce conceitual que será utilizado para
o adequado entendimento sobre os conceitos apresentados nos SIGs
estudados no Capítulo 4, e o desenvolvimento prático apresentado no Capítulo
5.
O Capítulo 4 será composto pela investigação de três SIGs de mercado: MGE,
ARC/INFO e SPRING. Os conceitos e modelos semânticos de cada sistema
serão apresentados. Uma investigação sobre o padrão OPENGIS também será
abrangida por este capítulo. Por fim, um estudo e análise de aderência entre
os sistemas e o padrão OPENGIS será mostrado.
No quinto Capítulo serão desenvolvidas as atividade de especificação informal,
formal e projeto para a construção da ferramenta GeoTMS (Tradutor de
Modelos Semânticos de Geoinformação). Neste Capítulo serão apresentadas e
33
justificadas as traduções entre os modelos conceituais dos SIGs e o padrão
OPENGIS e entre os SIGs.
A conclusão é assunto para o sexto e último Capítulo. A contribuição do
trabalho de forma específica assim como as perspectivas futuras de utilização
e evolução do trabalho serão apresentadas.
34
CAPÍTULO 2
GEOPROCESSAMENTO
Este capítulo tem por objetivo descrever o nosso entendimento sobre a área de
geoprocessamento levando em consideração os aspectos históricos que
resultaram na tecnologia dos dias atuais, e a descrição da ferramenta
computacional utilizada para se fazer geoprocessamento: o Sistema de
Informação Geográfica (SIG). No escopo desta descrição serão abordados os
componentes internos do SIG, as diferentes arquiteturas para armazenamento
de dados geográficos, e a apresentação da forma que um importante conceito
é implementado pelos SIGs: a topologia.
É reservado um espaço para a
apresentação de modelagem de dados geográficos e a sua forma de
implementação em um SIG.
2.1 - Histórico
O instinto de sobrevivência determina no homem, dentre outra coisas, o
desenvolvimento natural do senso de localização. Conhecer o seu espaço e
saber se locomover sobre ele é um requisito para sua proteção e evolução.
Neste sentido, surgiu o seu primeiro instrumento de auxílio: o mapa.
Segundo a definição de Aurélio (1977) o mapa visa representar uma
determinada área geográfica, em superfície plana e em escala menor. Os
primeiros mapas, segundo Robinson (1953) surgiram há cerca de 5.000 anos.
Sem projeção ou escala, foram utilizados como esboço por milênios. Porém,
na Grécia antiga (160-120 A.C.) é que foram lançados os primeiros
fundamentos da ciência cartográfica (Bakker, 1965). Mais tarde, o comércio e a
navegação
impulsionaram
o
seu
desenvolvimento
necessidade de se guiar em oceanos.
35
devido
à
natural
No século XVII, a academia de ciências de Paris influencia a cartografia
francesa. O desenvolvimento das ciências, em particular, matemática,
geodesia e astronomia, possibilitaram à cartografia uma maior solidez
científica. A criação de mapas passou a ter refino matemático. Surgiu a
cartografia como uma disciplina científica.
Desta forma a Terra passou a ser estudada como ciência, no sentido de se
definir a melhor forma geométrica para sua representação. Atualmente,
“geóide” é a forma adotada para este fim. A representação da Terra em
diferentes
superfícies
geométricas
determinam
as
diversas
projeções
existentes. Assim, dependendo do propósito de utilização, um mapa pode ser
gerado considerando características como escala, preservação de direção, de
área, de distância entre outras.
Com o advento da tecnologia digital os mapas, antes analógicos, passaram a
ser produzidos em forma digital. Os sistemas computacionais responsáveis
inicialmente por este processo são chamados de Computer Aidded Design
(CAD). Estes sistemas apenas reproduzem, na forma digital, o desenho
original. Neste sentido, um CAD constitui-se de um conjunto de ferramentas
para entrada de dados gráficos, edição e geração de desenhos através de
dispositivos de saída. Manipulações avançadas como, por exemplo, mudanças
de projeções, associação com banco de dados estão fora do escopo destes
tipos de sistemas.
Os sistemas computacionais evoluíram, cada qual especializando-se em áreas
determinadas.
A
tradução
do
conhecimento
humano
em
sistemas
informatizados constitui uma realidade. Como conseqüência desta evolução
surgiram os Sistemas de Informação Geográfica ou simplesmente SIGs.
A representação de uma realidade geográfica ou fenômeno geográfico,
inicialmente realizada através de mapas, tornou-se mais poderosa com esta
36
tecnologia. As manipulações, armazenamento, geração de novos mapas, são
processos automatizados pelos SIGs. Operações como mudanças de
projeções, associações e manipulações com banco de dados, análise espacial
em áreas geográficas de estudo, geração de novos mapas como uma
decorrência de simulações são alguns exemplos de facilidades oferecidos por
um SIG.
Visando mostrar o avanço nesta área, apresentaremos um exemplo de
geoprocessamento, especificamente de análise espacial, mostrando que
problemas graves que afetam o homem podem ser solucionados pelo uso
desta tecnologia.
Em 1854 a cidade de Londres vivia uma grave epidemia de cólera. Famílias
inteiras foram mortas e suas residências lacradas. Desconhecia-se a forma de
disseminação e contágio da doença.
No entanto, um médico, de nome Jonh Snow, realizou o seguinte
procedimento: sobre o mapa das ruas e residências da cidade, marcou com “x”
os poços de água e com “ponto” as residências onde haviam ocorridos mortes
como decorrência da doença. Com estas duas classes de informações
espacializadas no mapa, o doutor John, realizando o que hoje é denominado
de análise espacial, verificou que havia muitos “pontos” (casos de cólera)
próximo a um “x” (poço) da “Broad Street”. Portanto, decidiu lacrar o referido
poço. Como conseqüência, constatou-se a diminuição dos casos de cólera e
evidenciou-se a associação do cólera com a água. A Figura 2.1 reflete o
raciocínio da época.
37
Fig. 2.1 - Exemplo de Geoprocessamento: mapa de Londres com casos de
cólera (pontos) poços de água (cruzes).
Fonte: Tufte (1983)
Este exemplo ilustra a ação de fazer geoprocessamento, neste caso particular,
sem uso de uma ferramenta computacional. Outra análise derivada deste
exemplo está no poder de se ter dados espacializados como suporte à tomada
de decisão. Caso estes dados fossem apresentados em forma de simples
listagens das localizações de poços e casos de cólera, certamente o grau de
dificuldade para tomar uma decisão seria maior.
38
2.2 - Sistema de Informação Geográfica - SIG
2.2.1 - Definição
O termo Sistema de Informação Geográfica (SIG) é aplicado para sistemas
que realizam o tratamento computacional de dados geográficos. Devido à sua
ampla gama de aplicações, que inclui temas como agricultura, florestas,
cartografia, cadastro urbano e redes de concessionária (água, energia e
telefonia), há pelo menos três formas de se utilizar um SIG:
• como ferramenta para produção de mapas;
• como suporte para análise espacial de fenômenos e
• como um banco de dados geográficos, com funções de armazenamento
e recuperação de informação espacial (Câmara, 1995).
Pela abrangência expressa na definição acima, concluímos que estes tipos de
sistema lidam com informações multi-disciplinares, onde a heterogeneidade e
complexidade dos diversos temas é comum. Desta forma, os SIGs tem uma
característica básica de integração de informações, tornando-se uma
ferramenta que procura agregar dados artificialmente separados pelo homem,
de forma a manipulá-los e apresentá-los de outras maneiras, proporcionando
uma nova visão ao usuário.
Notamos uma outra característica, a de suporte à decisão. Pela possibilidade
de apresentar as informações existentes de uma outra maneira, através de
manipulações e análise, provê ao usuário um suporte à tomada de decisão
para melhor planejar o espaço em estudo, por exemplo.
Por se tratar de uma área recente, existem muitas definições sobre SIG. Cada
pesquisador expressa uma visão própria, que tendem a um mesmo ponto:
39
• integrar, em um banco de dados único, informações espaciais
provenientes de diferentes áreas e
• oferecer mecanismos para combinar as várias informações, através de
algoritmos de manipulação e análise; e para consultar, recuperar, visualizar
e plotar1 o conteúdo da base de dados geográficos.
2.2.2 - Arquitetura de SIG
Intencionamos com este item realizar uma “radiografia” de um SIG, explicando
as características dos principais módulos que o compõem. Basicamente um
SIG divide-se nos seguintes módulos (Burrough, 1986):
a) interface com o usuário;
b) entrada de dados e verificação;
c) armazenagem de dados e gerenciamento do banco de dados
geográfico;
d) funções para a manipulação e análise dos dados e
e) saída de dados: visualização e plotagem1.
Como já mencionado, por se tratar de um sistema que lida com uma ampla
variedade de informações, o módulo de entrada de dados deve ser de tal
robustez de modo a não restringir o formato do dado a ser tratado. Um SIG
________________________
1
Termo acolhido pelo meio técnico, significando o processo de impressão por
uma máquina chamada “Plotter”
40
deve tratar dados provenientes de sensores, de mapas analógicos, de arquivos
digitais, e por meio de interação direta. A Figura 2.2 ilustra este módulo:
Mapas Analógicos
Digitalização
Observações
Sensores
Arquivos Digitais
Interação Direta
Varredura Ótica
Meio Magnético
Entrada de Dados
Fig. 2.2 - Módulo de entrada de dados de um SIG.
O módulo de armazenagem de dados e gerenciamento do banco de dados
geográfico é considerado o coração do SIG. Após passar por
ajustes, os
dados são armazenados de modo a preservar a topologia, a localização
geográfica de acordo com a projeção geométrica adotada, e atributos
descritivos dos objetos geográficos. À frente trataremos a questão de banco de
dados geográfico com mais detalhes, por agora esclarecemos que este banco
é gerenciado por um programa denominado sistema gerenciador de banco de
dados (SGBD).
Sobre este banco de dados serão executadas consultas específicas,
recuperação de dados, atualizações de dados transformados, e suporte aos
mecanismos de análise de informações espaciais, característica principal de
um SIG. A Figura 2.3 ilustra este módulo.
O módulo sobre funções e manipulações dos dados é o componente que
distingue o SIG da cartografia automatizada. É um módulo provedor de
mecanismos de questionamento aos dados armazenados, de forma a analisálos, manipulá-los, e apresentá-los de uma maneira diferente da original.
Podemos indicar algumas perguntas comuns que podem ser respondidas por
um SIG na Figura 2.4.
41
Entrada de Dados
Análise Espacial
Recuperação de Dados
Sistema Gerenciador de Banco de Dados
BANCO DE DADOS GEOGRÁFICOS
Topologia + Localização + Atributos
Fig. 2.3 - Módulo de armazenagem de dados e gerenciamento de banco de
dados geográficos.
• Onde está localizada a cidade A ?
• Qual é a população da cidade B ?
• Houve um crescimento urbano nesta região nos últimos 2 anos ?
• Quais são os hospitais localizados a um raio de 5 km da minha casa ?
• Qual o melhor caminho para ir do ponto A ao ponto B desta cidade
passando por C ?
• O que acontece na região se elevarmos em 2 metros o nível da
represa?
• Qual a taxa de desmatamento na Amazônia entre 1995 e 1998 ?
Fig. 2.4 - Questões a serem respondidas por um SIG.
Quando sistemas deixam de oferecer estes tipos de mecanismos de análise,
tornam-se apenas ferramentas para transformar mapas de formato analógico
em formato digital, ou seja, uma automatização da área cartográfica.
O último módulo trata a saída de dados através da visualização de mapas,
tabelas de banco de dados, figuras, etc.. Esta saída pode ser expressa por
42
uma plotter, impressora, tela da estação de trabalho, ou por meio magnético. A
Figura 2.5 ilustra a idéia.
Visualização e Relatório
Tela de Estação de Trabalho
Figuras
Impressora
Plotter
Tabelas
Meio Magnético
Mapas
Fig. 2.5 - Módulo de saída de um SIG.
2.2.3 - Modelagem de Dados Geográficos
Para se construir um Sistema de Informação Geográfica torna-se necessário
criar um modelo que represente os fenômenos geográficos. Segundo Worboys
(1995) e Câmara (1995) tal modelo representa estes fenômenos como dois
grandes tipos de dados: objeto geográfico e campos. A Figura 2.6 ilustra a
idéia.
Na recente proposta de padronização de modelo de dados geográficos OGC
(1998A), estes conceitos podem ser aproximados por “Feature with Geometry”
e “Coverage” respectivamente. Uma investigação detalhada sobre este
assunto será apresentada no capítulo 5 deste trabalho.
Os objetos geográficos são individualizáveis e possuem identificação com
elementos do mundo real. São compostos de duas partes. Uma parte define a
representação geométrica do objeto geográfico (ponto, linha, polígono), que é
apresentada graficamente na tela do computador e a outra que define sua
descrição alfanumérica, como por exemplo seu nome, tamanho, área,
perímetro, etc.
43
FENÔMENOS
GEOGRÁFICOS
Representados por
OBJETOS
GEOGRÁFICOS
CAMPOS
Fig. 2.6 - Representação de Fenômenos Geográficos.
Por exemplo, uma determinada reserva indígena é um objeto geográfico, cuja
representação geométrica é definida por um polígono, e sua descrição
alfanumérica é dada pela localização geográfica de referência (12o00’ Latitude
Sul, 53o30’ Longitude Oeste), pelo nome da reserva (Xingu), pela área (4300
hectares), pelo número de índios em 1995 (1568 índios) e tantos outros
elementos descritivos quanto necessários. Vale ressaltar a unicidade deste
objeto reserva indígena do Xingu.
Campos são variações espaciais contínuas que representam grandezas
distribuídas espacialmente no mundo real. Cada localização no espaço está
associada a um conjunto de valores da variável espacial representada.
Como exemplo de “campos” podemos tomar um mapa temático de tipos de
solo. Solo é a variável espacial a ser representada e o conjunto valores
associado a esta variável pode ser latossolo roxo, litossolo, cambisolo, etc..
Cada valor associado também é denominado por “tema”. Numa representação
vetorial as ocorrências do tema latossolo roxo são representadas por inúmeros
polígonos que, em conjunto com outros temas, preenchem por completo o
espaço para o qual se pretende mapear o solo.
44
O outro exemplo são os dados provenientes de sensores remotos. Estes
dados são materializados em imagens digitais onde cada pixel (menor unidade
de uma imagem) reflete a resposta do solo medida por um sensor numa faixa
do espectro eletromagnético. Desta forma, torna-se possível, por algoritmos de
classificação, determinar faixas de variações de valores de cada pixel
conforme a variável espacial de interesse, e extrair informações da imagem.
A representação vetorial armazena os dados espaciais através de elementos
geométricos
como
pontos,
linhas,
região
e
nós.
A
implementação
computacional destes elementos exige técnicas e algoritmos de indexação em
árvores como B-Tree, R-Tree, V-Tree (Câmara, 1995).
O formato matricial2 representa fenômenos geográficos através de uma grade
de células. Cada célula da grade é referenciada por uma linha e coluna, e
contém um dado que representa o valor do fenômeno que está sendo
mapeado. Por
tratarem
de
grandes
volumes de dados, estes formatos
exigem técnicas que permitam otimizar o seu armazenamento. Vários
algoritmos são propostos para compactar dados matricial, para maiores
detalhes ver Burrough (1986).
As descrições dos dados não espaciais, ou também denominados de atributos,
relacionados aos objetos geográficos são armazenadas em um banco de
dados relacional.
________________________
2
Proveniente do inglês “raster”, também denominado varredura.
45
2.2.4 - Banco de Dados Geográfico
O banco de dados geográfico é o componente do SIG responsável por
armazenar
os objetos geográficos e campos pertinentes a uma aplicação.
Existem três arquiteturas básicas para se implementar um banco de dados
geográfico (Câmara, 1995):
• arquitetura dual;
• arquitetura baseada em campos longos e
• arquitetura baseada em mecanismos de extensão.
Descreveremos cada uma delas a seguir:
2.2.4.1- Arquitetura Dual
A arquitetura dual refere-se a uma estratégia de implementação onde utiliza-se
um sistema gerenciador de banco de dados relacional (SGBDR) para
armazenar os atributos descritivos dos objetos geográficos, e arquivos
convencionais para guardar as representações geométricas destes objetos.
Um identificador comum liga os componentes geométrico e descritivo do objeto
geográfico. Para recuperar um objeto, os dois subsistemas devem ser
pesquisados e a resposta é uma composição de resultados (Câmara, 1995).
Como exemplos de SIGs que utilizam este tipo de arquitetura podemos citar
MGE, Arc Info e Spring. A Figura 2.7 mostra um diagrama que ilustra desta
definição.
Existem alguns problemas relacionados a esta abordagem. O primeiro está
associado ao controle da integridade em uma estratégia dual. Como um objeto
geográfico possui componentes nos dois subsistemas, se ocorrer uma
exclusão de um dos componentes, por motivo que não seja adequado, o outro
46
componente não será atualizado (excluído), e ocorrerá a inconsistência do
objeto e consequentemente do banco de dados geográfico.
SIG
Entrada de Dados
Análise Espacial
Saída de Dados
BANCO DE DADOS
GEOGRÁFICOS
Id nome área classe
ccclasse
classe descr
desdescrprop
Arquivos
SGBDR
Fig. 2.7 - Arquitetura dual para banco de dados geográfico.
Com relação a consultas, também existe a dualidade, no sentido de ocorrer
nos dois subsistemas separadamente. A parte da representação geométrica do
objeto geográfico é consultada de forma independente pelo seu subsistema,
assim como a parte descritiva do mesmo objeto é consultado pelo SGBDR.
Após ambas as operações, os resultados são tratados e unidos
por uma
camada de nível superior de implementação e o resultado é apresentado. Um
trabalho interessante utilizando esta é arquitetura foi desenvolvida por Thomé
et al (1996).
47
2.2.4.2 - Arquitetura Baseada em Campos Longos
A arquitetura baseada em campos longos difere da anterior por armazenar a
representação geométrica dos objetos geográficos no campo longo do
SGBDR. Um campo longo consiste de uma cadeia binária de grande
capacidade de armazenamento, onde pode-se depositar informação gráfica,
numérica ou pictórica. Nesta abordagem, tanto a parte descritiva quanto a
parte da representação geométrica do objeto geográfico estarão contidas no
mesmo subsistema.
Ao armazenar todas as partes do objeto geográfico em um único SGBDR,
evita-se problemas de controle de integridade, controle de concorrência em um
ambiente multi-usuário e gerência de transações típicos de um ambiente dual
(Câmara, 1995). Entretanto, esta abordagem deve prover uma camada de
implementação para interpretar a massa de dados armazenada no campo
longo, capturando a semântica da representação geométrica do objeto
geográfico.
Como exemplo desta arquitetura podemos citar o Spatial Database Engine
(SDE) desenvolvido pela Environmental System Research Institute (Esri).
Trata-se de um sistema gerenciador de banco de dados geográfico (espacial)
que capacita SGBD Relacionais a armazenar dados espaciais e dados não
espaciais. A construção deste sistema levou em consideração o processo de
padronização em elaboração pelo consórcio OpenGIS. O SDE é compatível
com os produtos da ESRI como ArcInfo, ArcView, ArcExplorer, etc.. (Esri,
1998).
Outro exemplo é o Spatial Data Option (SDO) da Oracle que é capaz de
armazenar e gerenciar dados geográficos como pontos, linhas e polígonos no
banco de dados relacional. Esta implementação busca seguir o padrão que
vem sendo estabelecido pelo consórcio OpenGIS. Empresas líderes no
48
segmento de SIG tais como Advanced Visual Systems, Bentley, ESRI,
Formida,
Intergraph,
MapInfo,
MCI's
SHL
Vision
Solutions,
Sedona
GeoServices Inc., SmallWorld and TIMC Ltda, buscam incluir esta opção como
forma de armazenamento e gerenciamento de dados geográficos. (Oracle,
1998)
2.2.4.3 - Arquitetura Baseada em Mecanismos de Extensão
Uma
terceira
estratégia
de
implementação
baseia-se
em
sistemas
gerenciadores de banco de dados extensíveis (SGBD Extensíveis). Por esta
abordagem, os sistemas forneceriam mecanismos para definir um objeto
geográfico como sendo a extensão do seu próprio ambiente. Tanto a parte
descritiva quanto a geométrica, além das funções próprias de manipulação
destas partes, seriam definidos dentro do SGBD Extensível, compondo um
objeto geográfico. Por estes mecanismos captura-se a semântica do objeto
(Câmara, 1995).
Nesta estratégia enquadram-se os sistemas gerenciadores de banco de dados
orientados por objetos (SGBDOO). Essa nova geração de SGBDs está sendo
pesquisada no sentido de possibilitar a integração com SIGs. Existem questões
a serem avaliadas nesses SGBDs como por exemplo, o seu desempenho ao
lidar com grandes volumes de dados, flexibilidade para a definição de novos
métodos de acesso e armazenamento, e outros, quando tratamos de
aplicações em geoprocessamento. Embora existam questões técnicas,
conforme citadas anteriormente, este tipo de abordagem aumenta muito a
funcionalidade e possivelmente o desempenho final da aplicação (Milne, 1993).
Um exemplo da implementação desta arquitetura é o GODOT (FAW, 1998).
Trata-se de um protótipo de SIG implementado em C++ que utiliza o SGBDOO
ObjectStore em plataforma UNIX. Para este desenvolvimento argumenta-se
que para tratar estruturas complexas como dados espaciais e não espaciais os
49
sistemas gerenciadores de banco de dados padrão apresentam certas
limitações e necessitam de uma solução especial. Já os SGDOO emergentes
no mercado nos últimos anos superam estas limitações.
GOTHIC ADE (LASER, 1998) é outro exemplo de SIG no sentido de ser um
ambiente de desenvolvimento de aplicações orientado por objetos para
construir sistemas de informação que processam dados geográficos. O
SBDOO tem a função de armazenar e gerenciar os dados espaciais e não
espaciais. Gothic ADE está disponível para plataforma UNIX nos seguintes
tipos de hardwares Hewlett-Packard, Digital, Sun e IBM workstations.
Outro SIG desta categoria é o GEO2. Baseado no SGBDOO O2 (02, 1998),
este sistema implementa um objeto geográfico como um objeto derivado de
uma classe sob o paradigma orientado por objetos encapsulando a parte
espacial e não espacial (FLEXIMAGE, 1998). Está disponível em plataforma
UNIX e futuramente em Windows NT.
2.2.5 - Topologia em SIG
As definições apresentadas a seguir refletem uma visão de topologia aplicada
nos Sistemas de Informação Geográfica. Portanto estas definições não
possuem o rigor presente em uma visão matemática. Trata-se de buscar expor
a forma como os SIGs estão implementando o conceito de topologia.
Pontos,
linhas
e
polígonos
são
representações
vetoriais
utilizadas
normalmente para representar fenômenos geográficos ou feições geográficas
em mapas. Relacionamentos espaciais entre estes fenômenos geográficos,
como por exemplo proximidade e vizinhança, são obtidos através da análise e
observação dos mapas pelo intérprete.
50
Entretando, uma vez que as feições do mapa foram digitalizadas e estão
representados por pontos, linhas e polígonos no computador, esta relação
espacial deverá ser definida explicitamente para que se possa proceder as
operações de análise espacial dos dados.
Em mapas digitais, uma forma de descrever os relacionamentos espaciais é
através da topologia. A topologia é definida como a parte da matemática que
estuda as propriedades geométricas que não variam mediante uma
deformação. Formas e coordenadas dos objetos são menos importantes que
os elementos do modelo topológico como conectividade, contiguidade,
definição de área, etc.
Em síntese, a topologia define o relacionamento espacial das feições
geográficas. A criação e o armazenamento dos relacionamentos topológicos
tem diversas vantagens. Os dados espaciais são armazenados eficientemente
de tal forma que um grande volume de dados pode ser processado
rapidamente.
A topologia facilita o processamento de funções analíticas como a modelagem
do fluxo através das linhas conectadas de uma rede, combinação de polígonos
adjacentes com características similares, identificação de feições adjacentes e
sobreposição de feições geográficas.
A estrutura arco-nó, detalhada no próximo item, suporta os três mais
importantes conceitos topológicos. São eles:
1) Conectividade: Os arcos são conectados entre si pelos nós.
2) Definição de Área: Os arcos conectados em torno de uma área definem
um polígono.
3) Contiguidade: Os arcos têm direção e lados direito e esquerdo.
51
Cada um destes conceitos será abordado em detalhes após a apresentação da
estrutura arco-nó.
Ressalta-se que este estudo se refere a representação vetorial da topologia em
SIG. Existem ainda a representação matricial que não fará parte deste estudo.
2.2.5.1 - Estrutura de Dados Arco-Nó
A
estrutura
arco-nó
armazenamento
de
é
arcos
uma
de
representação
polígonos.
Por
computacional
esta
para
estrutura,
o
arcos
compartilhados por polígonos vizinhos são armazenados uma única vez,
evitando redundância e incrementando eficiência.
A estrutura arco-nó armazena e referencia dados de tal forma que cada dois
nós, contendo ou não vértices entre eles, formam arcos e os arcos formam
polígonos. Um nó é definido por no mínimo dois pontos finais de arcos. Um
arco é um segmento de linha entre dois nós. Um arco é composto por dois nós
e uma série de pontos ordenados que definem sua forma. Estes pontos são
chamados de vértices. Tanto os nós quanto os vértices são representados por
coordenadas x,y.
Vale a observação de um caso particular em que um arco é forma por um
único nó pelo qual este arco tem seu início neste nó e retorna ao mesmo nó
formando uma “ilha” ou “anel” com uma série de vértice neste caminho.
Na Figura 2.8, os nós são criados onde as linhas se intersectam. Os arcos são
criados entre os nós. Os vértices dão a forma aos arcos. Os polígonos A e B
são construídos a partir dos arcos.
52
d
c
1
f
b
20
e
A
a
2
g
l
B
10
3
i
j
Identificador
do Arco
1
2
3
Nó
Inicio
10
20
10
h
Vétices
Nó
Final
20
10
20
a, b, c, d, e
l
j, i, h, g, f
Polígono
A
B
Lista de
Arcos
1,2
2,3
Fig. 2.8 - Ilustração da representação computacional da estrutura Arco-Nó.
FONTE : adaptada de ESRI (1994).
2.2.5.2 - Conectividade
A conectividade é um componente da topologia que auxilia, por exemplo, a
identificar uma rota para um aeroporto ou verificar o fluxo de um córrego para
um rio ou seguir um caminho da estação de tratamento de água para uma
casa.
Porém para que estes exemplos sejam viáveis por completo, é
necessário,
além
da
conectividade,
outros
elementos
associados
a
representação vetorial como a impedência (sentido de fluxo) e a vazão
(quantidade de elementos que fluem no trecho por unidade de tempo).
Dependendo do propósito da aplicação este elementos associados podem ser
alterados ao acrescidos de novos.
A conectividade é possível pela implementação da estrutura arco-nó. O arco,
definido por dois nós, tem em seu nó início a indicação de onde o arco começa
53
e em seu nó final a indicação de onde o arco termina. Denomina-se a isto
topologia arco-nó.
A topologia arco-nó é suportada através de uma lista de arco-nós. Esta lista
identifica os nós início e nós final de cada arco. Através de uma pesquisa nesta
lista é possível selecionar os nós comuns entre os arcos. Isto é relevante para
a determinação de caminhos possíveis de serem percorridos.
No exemplo da Figura 2.9 abaixo, é possível computacionalmente traçar um
caminho entre os arcos 3 e 5, pois eles compartilham o nó 23. Já um caminho
entre os arcos 3 e 7 é inviável porque não há compartilhamento de nós.
Ressalta-se que neste exemplo não se tem a restrição de impedância portanto
qualquer sentido é valido.
Topologia Arco-Nó
20
21
1
Lista Arco-Nó
22
2
Arco
1
2
3
4
5
6
7
3
5
23
7
27
25
4
6
24
26
Nó Inicio
20
21
21
23
23
25
25
Nó Final
21
22
23
24
25
26
27
Fig. 2.9 - Ilustração do conceito de conectividade e topologia arco-nó.
FONTE : adaptada de ESRI (1994).
54
2.2.5.3 - Definição de Área
Muitas das feições geográficas representam área claramente distintas sobre a
superfície da terra, tal como lagos, propriedades de terras, e setores
censitários. Uma área no modelo vetorial é representado por um ou mais
perímetros que definem um polígono. O caso da ilha dentro de um lago é um
exemplo que reflete a idéia do polígono com dois perímetros. Um perímetro é
externo e o outro é o perímetro da ilha. Novamente a topologia é utilizada para
a devida representação computacional.
A estrutura arco-nó representa os polígonos como uma lista de arcos
ordenados. Isto é denominado de topologia polígono-arco. Na Figura 2.10 o
polígono D é formado pelos arcos 2, 6, 9 e 4 .
Cada arco pertence a dois polígonos. Assim, um polígono é uma lista de arcos
que define seu perímetro e as coordenadas dos arcos são armazenados uma
única vez, reduzindo o volume de dados e evitando redundância de perímetros
de polígonos adjacentes.
F
2
1
E
TOPOLOGIA POLÍGONO-ARCO
D
6
Polígono
A
B
C
D
E
8
9
7
C
5
B
10
A
4
Lista de Arcos
5, 10, 4, 3
10, 9, 8
7
2, 6, 9, 4
5, 8, 6, 1
3
Fig. 2.10 - Ilustração da representação computacional da estrutura polígonoarco.
FONTE : adaptada de ESRI (1994).
55
2.2.5.4 - Contiguidade
Contiguidade é um conceito topológico que permite ao modelo de dados
vetorial determinar adjacências. No SIG, denomina-se adjacência a duas
feições geográficas que compartilham um arco.
Conforme definido anteriormente um arco utiliza-se o conceito de nó inicio e nó
final, isto indica a direção do arco, e como decorrência é determinado o
polígono do lado direito e esquerdo deste arco. A topologia direita-esquerda
refere-se a determinação dos polígonos do lado esquerdo e direito de um arco.
Na ilustração da Figura 2.11, o arco 9 tem o polígono D ao lado esquerdo e o
polígono B ao lado direito. Logo o polígono D e B são adjacentes.
F
TOPOLOGIA DIREITA-ESQUERDA
2
1
E
Arco
D
6
1
2
3
4
5
6
7
8
9
10
8
9
7
C
5
B
10
A
4
3
Polígono
Esquerdo
F
F
F
D
A
E
B
E
D
A
Polígono
Direito
E
D
A
A
E
D
C
B
B
B
Fig. 2.11 - Ilustração da topologia direita-esquerda.
FONTE : adaptada de ESRI (1994).
56
CAPÍTULO 3
MODELAGEM ORIENTADA POR OBJETOS
O objetivo deste capítulo é apresentar alguns conceitos associados ao
desenvolvimento de sistemas de software, baseados no trabalho de
Rumbaugh (1994), e a técnica de modelagem de objetos TMO. Estes
conceitos servirão de alicerce para a construção dos demais capítulos.
3.1 - Introdução a Modelagem de Dados
A modelagem de dados é parte integrante de uma metodologia de
desenvolvimento de software. Uma metodologia é um processo organizado de
produção
de
software,
que
utiliza
técnicas
predefinidas
e
notações
convencionais. As etapas que compõem este processo correspondem ao ciclo
de vida do software. Tradicionalmente, a formulação inicial do problema, a
análise, o projeto, a implementação, os testes e a operação (manutenção e
aperfeiçoamento) compõem estas etapas do ciclo de vida.
A modelagem de dados é uma das etapas mais importantes do projeto de um
SIG, pois a escolha de uma modelo que melhor se ajuste à realidade que
pretende expressar é fator crítico para o sucesso ou fracasso do projeto
(Worboys, 1995). São apresentados a seguir as definições de autores como
base de discussão:
“Modelo de dados é uma coleção de ferramentas conceituais para descrição
dos dados, relacionamento entre os dados, semântica e restrições dos dados”
(Korth e Silberschatz, 1989).
“Um modelo é uma abstração de alguma coisa, cujo propósito é permitir que se
conheça essa coisa antes de se construí-la” (Rumbaugh, 94).
57
Sinteticamente, modelar os dados é uma maneira de expressar uma realidade
através de um formalismo que requer abstração
por parte do modelador.
Existem diversas técnicas para modelagem de dados, cada uma com
ferramentas de abstração diferenciadas determinando a classe de problemas
mais adequada ao seu uso.
Um modelo completo de um sistema é composto por sub-modelos que
expressam visões diferentes da mesma realidade. Essas visões estão divididas
em três (Rumbaugh, 1994):
1) Visão de objetos: descreve estaticamente os objetos que compõem o
sistema e seus relacionamentos através de diagramas de objetos.
2) Visão dinâmica: descreve os aspectos do sistema que se modificam
com o passar do tempo, especificando o controle do sistema. Os
diagramas de estado são usados como ferramenta de descrição.
3) Visão funcional: descreve as transformações dos valores dos dados de
um sistema. Os diagramas de fluxo de dados são usados como ferramenta
de trabalho.
Cada visão descreve um aspecto do sistema, mas contém referências às
outras visões. A visão de objetos descreve as estruturas de dados sobre as
quais atuam as visões dinâmicas e funcional. As operações da visão de
objetos correspondem a eventos nas visões dinâmicas, e a funções na visão
funcional.
A visão funcional descreve as funções chamadas pelas operações da visão de
objetos e pelas ações na visão dinâmica.
Por se tratar de abstração, é natural que exista alguma ambigüidade quando
alguma informação é representada por uma visão, pois a meta é simplificar a
58
descrição sem sobrecarregar uma visão com construções complexas, de modo
a se tornarem um auxílio e não um peso no desenvolvimento do sistema.
Funcional
Dinâmica
Objetos
Fig. 3.1 - As três visões de um sistema.
Esses inter-relacionamentos entre visões é inevitável, compondo um fator
delicado na modelagem. Segundo (Rumbaugh, 1994) essas visões são partes
ortogonais, que se inter-relacionam, na modelagem de um sistema. A fig. 3.1
ilustra as visões.
As metodologias estruturadas abordam as três perspectivas. Por ter como
princípio
a
decomposição
funcional
para
modelar
sistemas,
essas
metodologias dão mais ênfase à visão funcional; em um segundo grau de
importância, vem a visão dinâmica e por fim a de objetos. A visão de objetos,
para as metodologias estruturadas, restringe-se apenas aos dados. As
metodologias orientadas por objetos, da mesma forma que as estruturadas,
abordam as três perspectivas, com ênfases diferentes. A visão de objetos é a
mais enfatizada, depois a visão dinâmica e a funcional (Rumbaugh, 1994).
A realidade geográfica modelada pelos SIGs é complexa e heterogênea. Com
o estudo e análise destas técnicas de modelagem este trabalho buscará criar
um embasamento conceitual para melhor compreender os modelos atuais
destes SIGs.
59
3.2 - Abstração de Dados
Abstração é uma capacidade de visão de alto nível que nos permite examinar
problemas de forma a selecionar grupos comuns, encontrar generalidades,
para melhor compreender o problema e construir modelos. A abstração deve
estar associada a um propósito. Desta forma, pode-se ter várias abstrações de
um mesmo problema para propósitos diferentes. A construção de modelos pela
abstração possui o caráter de simplificação da realidade a ser modelada, por
isso não deve procurar a verdade absoluta, mas sim a adequação ao propósito
(Rumbaugh, 1994).
Para auxiliar na construção destes modelos através da abstração foram
desenvolvidas algumas técnicas e notações gráficas. Uma delas é a Técnica
de Modelagem de Objetos - TMO que será apresentada a seguir.
3.3 - Técnica de Modelagem de Objetos
A TMO aborda as três visões definidas anteriormente. A partir do uso da
abstração, constrói-se três modelos: de objetos , dinâmico e funcional, além da
relação entre os modelos. Neste trabalho, será tratado aspectos ligados a
banco de dados, logo será enfatizado a modelagem das estruturas estáticas e
seus relacionamentos: o modelo de objetos.
Precedendo a notação TMO, será mostrado alguns conceitos básicos de
modelagem de objetos como : objeto, atributo, operações e classes.
60
3.3.1 - Objeto, Atributo e Operações
Define-se um objeto como
um conceito, uma abstração, algo com limites
nítidos e significado em relação à realidade estudada (Rumbaugh, 1994). Os
objetos facilitam a compreensão do mundo real e oferecem uma base real para
a implementação em um sistema de software. Eles possuem identidade e são
distinguíveis.
Os exemplos a seguir ilustram a idéia de objeto: o homem Mohandas K.
Gandhi, o rio Amazonas, a cidade de São José dos Campos, a empresa
Human Tecnologies Ltda., etc..
Objetos possuem características próprias que descrevem o seu estado em um
determinado momento, e a isso denomina-se atributos ou propriedades de um
objeto.
A exemplo a seguir ilustra o conceito de atributo: “A cidade de São José dos
Campos possui uma população de 450.000 habitantes.” Neste caso
“população” é um atributo que descreve o objeto “São José dos Campos” em
um determinado momento.
Os objetos são responsáveis por atuar sobre os seus atributos e também sobre
outros objetos, para isto desempenham diversas “operações”. Essas
operações descrevem o comportamento do objeto. Os métodos são a
implementação dessas operações.
A seguir são mostrados dois exemplos de operação: “A cidade de São José
dos Campos incrementou sua população de 50.000 novos habitantes.” Neste
caso, a operação de “incrementar” será implementada por um método do
objeto “São José dos Campos” que adicionará “50.000” no atributo
“população”. No segundo exemplo: “A população do Brasil é de 140.000.000
61
de habitantes.”, o objeto “Brasil” poderáa se relacionar com todos os objetos
que representam os estados brasileiros (objeto São Paulo, objeto Amazonas,
etc.) para acumular os respectivos valores dos atributos “população” ou poderá
se relacionar as cidades brasileiras e acumular seus valores. Da mesma forma,
esses objetos representantes dos estados brasileiros se relacionam com cada
objeto representante da cidade de seu estado (objeto São José dos Campos,
objeto Ribeirão Preto, etc.) para acumular suas populações.
3.3.2 - Classes
Uma classe de objetos descreve um grupo de objetos com propriedades
semelhantes
(atributos),
o
mesmo
comportamento
(operações)
e
conseqüentemente a mesma semântica (Rumbaugh, 1994). No exemplo
anterior, já tocamos nesta definição, quando expressamos
“objetos que
representam...” ou seja, objetos de uma mesma classe, por exemplo: “estados
brasileiros” e “cidades”.
Os objetos de uma classe compartilham um objetivo semântico comum, além
dos requisitos de atributos e comportamento. Dessa maneira, embora um
celeiro e um cavalo tenham ambos um preço e uma idade, provavelmente
pertencem a classes diferentes. Se o celeiro e o cavalo fossem vistos apenas
como bens contábeis, provavelmente pertenceriam a mesma classe. Se o
desenvolvedor levar em consideração que um celeiro deve ser pintado, e um
cavalo, alimentado, eles seriam modelados como classes distintas. A
interpretação da semântica depende do propósito de cada aplicação, sendo
uma questão de critério.
Cada metodologia de modelagem utiliza uma notação gráfica própria. Esta
discussão utiliza a notação de Rumbaugh (1994). A Figura 3.2 indica esta
notação para o diagrama de objetos.
62
Cidade
Cidade
Nome : String
População : Integer
Centroid : Integer
Incrementar_População
Classe
(Cidade)
Nome=São José dos Campos
População=450.000
Centroid=156
Objetos da
Classe
Cidade
Atributos
Operações
(Cidade)
Nome=São Paulo
População=2.200.000
Centrid=248
Fig. 3.2 - Notação Gráfica TMO.
Para completar a apresentação da modelagem orientada por objetos, torna-se
necessário outros conceitos chaves da TMO que serão discutidos a seguir.
3.3.3 - Associação, Ligação e Multiplicidade
A associação descreve um conjunto de ligação com estrutura e semântica
comuns. Exemplo: “Uma cidade pertence a um estado”. Assim como as
classes, as associações podem possuir atributos provenientes da semântica de
cada ligação.
Ligação é a conexão física ou conceitual entre instâncias de objetos. Exemplo:
“A cidade de Ribeirão Preto pertence ao estado de São Paulo”. Uma ligação é
uma instância de uma associação.
A multiplicidade especifica quantas instâncias de uma classe relacionam-se a
uma única instância de uma classe associada, restringindo a quantidade de
objetos relacionados. A multiplicidade pode ser expressa, de maneira geral, por
“um” ou “muitos”. No entanto, é possível utilizar intervalos bem definidos. A
simbologia adotada representa por uma “bola cheia” na extremidade do
relacionamento a multiplicidade “muitos” significando zero ou mais, e para
63
“bola vazia” a multiplicidade zero ou um. Na Figura 3.3 são ilustradas o
emprego dessas notações.
“um” para “um ou zero”
Microcomputador
Utilizado por
Usuário
“um” para “muitos ou zero”
Usufruído por
Hotel
Usuário
“muitos ou zero” para “muitos ou zero”
Cursar
Disciplina
Aluno
intervalos definidos
Cruza
Linha
+2
Ponto
Fig. 3.3 - Exemplos de associação e multiplicidade.
3.3.4 - Atributo de Ligação
Assim como um atributo é uma propriedade dos objetos de uma classe, um
atributo de ligação é uma propriedade das ligações de uma associação. Na fig.
3.4, “avaliação” é um exemplo de propriedade de associação que é do tipo
“muitos ou zero” para “muitos ou zero”. Desta forma, dado um determinado
aluno, este deverá ter muitas avaliações dependendo de cada disciplina que
cursar. No modo inverso, dado uma disciplina, esta avaliará os diversos alunos
que a cursam.
64
Cursar
Disciplina
Aluno
Avaliação
Fig. 3.4 - Exemplos de atributo de ligação.
3.3.5 - Agregação
A agregação é um tipo de associação forte onde um objeto agregado é
contituído de componentes. A agregação é representada pelo relacionamento
“parte-todo” ou “uma-parte-de” no qual os objetos que representam os
componentes de alguma coisa são associados a um objeto que representa a
estrutura inteira. Em termos semânticos, o objeto agregado é um objeto
estendido tratado como uma unidade em muitas operações, embora
fisicamente ele seja composto por objetos menores.
Uma agregação é representada graficamente pelo símbolo de losango. O
exemplo da fig. 3.5 ilustra a idéia exposta.
Projeto de Casa
Estrutural
Hidráulico
Elétrico
Exterior
Arquitetura
Interior
Paisagismo
Fig. 3.5 - Conceito de agregação aplicado a um exemplo de projeto de casa.
65
3.3.6 - Generalização, Especialização e Herança
Esses termos referem-se a aspectos da mesma idéia e são freqüentemente
usados de forma intercambiável. Utilizamos generalização para nos referirmos
ao relacionamento entre classes, enquanto a herança refere-se ao mecanismo
de compartilhamento de atributos e operações utilizando o relacionamento de
generalização. Generalização e especialização são dois diferentes pontos de
vista do mesmo relacionamento, vistos a partir da superclasse ou das
subclasses. Generalização deriva do fato de que a superclasse generaliza as
subclasses. Especialização refere-se ao fato de que as subclasses refinam ou
especializam a superclasse. A Figura 3.6 ilustra esses conceitos.
Estado
Id_Estado: String
Nome: String
Nro_Cidade: Integer
Area: Float
Calcula_População():Integer
Estar/Possui
Cidade
Nome : String
População : Integer
Centroid : Integer
Incrementar (Valor):Integer
Tipo da Cidade
Capital
Verba_Estadual: Float
Meta_Educação: String
Meta_Saude: String
Agregação onde “Estados”
são compostos por muitas
“Cidades”.
“Um estado possui muitas
cidade e uma cidade está
em um estado.”
Especialização da classe
“Cidade” em subclasses
“Capital” e “Município”.
As subclasses herdam os
atributos e operação da
superclasse “Cidade”.
Municípios
%_Verba_Estadual: Foat
Prioridades: String
Fig. 3.6 - Exemplo de Especialização e Herança.
66
A herança múltipla é um conceito que consideramos relevante para o trabalho,
uma vez que aumenta a capacidade de especificação das classes. A herança
múltipla permite que uma classe possua mais de uma superclasse e herde as
características de todos os seus ancestrais. Isto possibilita a mesclagem de
informações de duas ou mais classes. A desvantagem desta prática está na
perda de simplicidade conceitual e de implementação. A Figura 3.7 expressa a
idéia.
Por esta possibilidade de modelagem, uma característica proveniente da
mesma classe ancestral encontrada em mais de um caminho é herdada
apenas uma vez. Os conflitos de definições paralelas criam ambigüidades que
precisam ser resolvidas seja pelas implementações ou por ajustes no modelo,
que impeçam a herança múltipla.
No exemplo da Figura 3.7 uma possível solução para se evitar a herança
múltipla, na modelagem, é “elevar” a classe “Veículo Anfíbio” para o mesmo
nível de “Veículo Terrestre” e “Veículo Aquático”, tornando-se uma outra
especialização de “Veículo”. Desta forma o novo modelo seria como
apresentado pela Figura 3.8.
Em razão deste ajuste deve-se adicionar explicitamente à classe “Veículo
Anfíbio”, em forma de novos atributos, as características que antes eram
herdadas de ambos os ancestrais e que também eram motivo de conflitos.
Outras soluções são possíveis no nível de implementação, no sentido de fazer
uso de mecanismos oferecidos pela linguagem escolhida. Esta abordagem não
será detalhada neste trabalho por entendermos tratar-se de um nível mais
baixo de detalhes, fora do nível conceitual o qual pretendemos seguir. Uma
boa explicação sobre este assunto encontra-se em (Rumbaugh, 1994).
67
Veículo
Veículo Terrestre
Carro
Veículo Aquático
Veículo Anfíbio
Barco
Fig. 3.7 - Exemplo de herança múltipla: a classe “Veículo Anfíbio” possui duas
superclasses.
Veículo
Veículo Terrestre
Carro
Veículo Aquático
Veículo Anfíbio
Barco
Fig. 3.8 - Novo modelo ajustado para evitar a herança múltipla.
3.3.7 - Polimorfismo
Um outro conceito utilizado na abordagem orientada por objetos denomina-se
polimorfismo. Trata-se da possibilidade que uma mesma operação possui de
atuar de modos diferentes em classes diferentes. Isto é possível quando uma
operação esteja declarada em classes diferentes, porém com o mesmo nome,
executando processamentos diferentes para atender os requisitos semânticos
de sua classe. Por exemplo, uma operação de “mover” para classe “Janela”
executa um processo diferente do que a operação “mover” para classe “Peça-
68
de-Xadrez”. Enquanto uma operação modifica a posição de uma janela a outra
movimenta uma peça de xadrez.
3.4 - Persistência de Objetos em Ambientes Relacionais
Este tópico visa completar os tópicos antecessores sobre a TMO apresentando
algumas técnica de mapeamento das classes de dados e suas associações
em tabelas em um banco de dados relacional. Denominamos a isto
persistência de dados em ambientes relacionais.
A discussão a seguir é baseada no texto de Rumbaugh (1994).
3.4.1 - Mapeamento de Classes
De uma maneira geral cada classe persistente dá origem a uma tabela, onde
cada atributo da classe corresponde à uma coluna, e os valores dos atributos
para cada objeto na classe correspondem a uma linha.
No entanto, deve-se, neste mapeamento, ter o cuidado de criar a coluna de
identificação, ou seja a chave primária de cada linha ou registro armazenado.
Em um programa C++, quando ocorre a criação de um novo objeto, é gerado
automaticamente
o identificador deste objeto. Já em um banco de dados
relacional cabe ao desenvolvedor a responsabilidade desta criação. Quando
ocorre o mapeamento, recomenda-se armazenar no banco de dados relacional
o identificador do objeto como chave primária, ou qualquer outro atributo do
objeto que possa identificá-lo de forma única.
A Figura 3.9
a seguir mostra um exemplo de conversão de uma classe
persistente em uma tabela. Nesse exemplo a classe “Municipio” possui os
atributos “Nome” e ”Populacao_98”. Quando ela é convertida para a tabela
“Municipio”, acrescenta-se a coluna “Id-Municipio”, pois a classe não possui um
69
atributo ou um conjunto de atributos que possa ser considerado “chave”. Essa
estratégia é compatível com as linguagens baseadas em objetos, onde os
objetos têm identidades independentes das suas propriedades.
Municipio
Nome
População98
TABELA MUNICIPIO
Id- Municipio
Nome
População98
123
São José dos Campos
450.000
100
São Paulo
12.000.000
131
São José do Rio Preto
480.000
171
Guarujá
204.000
...
...
...
Fig. 3.9 Mapeamento de Classes em Tabelas.
3.4.2 Mapeamento de Associações Muitos para Muitos
Cada associação “muitos para muitos” entre objetos persistentes deve ser
mapeada em uma nova tabela. As chaves das tabelas das classes associadas
transformam-se em atributos dessa nova tabela. Um exemplo do mapeamento
de associação muitos para muitos é dado na fig. 3.10.
Neste exemplo foi utilizado a propriedade “Nro_Lei” da classe “Leis” para ser a
chave primária ou identificador único da tabela gerada pelo mapeamento desta
classe no banco de dados relacional.
70
Municipios
Leis
Nome
Area_km2
Pop98
Nro_Lei
Data
Ambito
TABELA MUNICIPIOS
TABELA LEIS
Id
Nome
Area_km2
Pop98
Nro_Lei
Data
Ambito
121
São Carlos-SP
1.800
320.000
122.444.78
10/09/97
Estadual
233
Londrina-PR
2.360
120.000
145.883.33
03/02/98
Federal
321
Santa Maria-RS
1.640
480.000
111.211.44
08/12/97
Federal
600
Cuiaba-MS
2.660
430.000
223.444.76
10/04/98
Estadual
...
...
...
...
...
...
...
TABELA MUNICIPIOS_LEIS
Id
Nro_Lei
121
122.444.78
121
145.883.33
233
223.444.76
233
145.883.33
233
111.211.44
...
...
Fig. 3.10 Mapeamento de Associações “muitos para muitos” para Tabelas.
3.4.3 - Mapeamento de Associações Um para Muitos
Existem duas maneiras de se mapear associações “um para muitos” entre
objetos persistentes para o modelo relacional. São elas :
• Caso 1. No primeiro caso transpõe-se a chave primária da tabela
correspondente à classe do lado “Muitos”, para a tabela correspondente à
71
classe do lado “1”. (Por “transpor” deve-se entender criar uma coluna com
a chave da tabela correspondente à uma determinada classe, em outra
tabela). Um exemplo é dado na Figura 3.11 a seguir.
Quadras
Lotes
Id_Quadra
Area
Perimetro
Id_Lote
Area
Proprietario
TABELA QUADRAS
TABELA LOTES
Id_Quadra
Area_m2
Perimetro
Id_Lote
Area
Proprietário
Id_Quadra
A-10
4.580
383
10-01
1.200
Antonio C. M.
A-10
B-08
5.200
652
10-05
1.800
Paulo M.
A-10
C-22
4.220
322
08-03
900
Luiza E.
B-08
...
...
...
08-07
800
Luis I. L. S.
B-08
22-01
2.200
Fernando H. C.
C_22
...
...
...
...
Fig. 3.11 Mapeamento de associações “um para muitos” do caso 1.
• Caso 2. No segundo caso cria-se uma tabela correspondente à
associação, transpondo para ela as chaves das duas classes. Um exemplo
é dado na Figura 3.12 a seguir (foram usadas as classes “Quadras” e
“Lotes” do exemplo anterior).
72
TABELA QUADRAS
TABELA LOTES
Id_Quadra
Area_m2
Perimetro
Id_Lote
Area
Proprietário
A-10
4.580
383
10-01
1.200
Antonio C. M.
B-08
5.200
652
10-05
1.800
Paulo M.
C-22
4.220
322
08-03
900
Luiza E.
...
...
...
08-07
800
Luis I. L. S.
22-01
2.200
Fernando H. C.
...
...
...
TABELA QUADRAS_LOTES
Id_Quadra
Id_Lote
A-10
10-01
A-10
10-05
B-08
08-03
B-08
08-07
C_22
22-01
...
...
Fig. 3.12 - Mapeamento de associações “muitos para um” do caso 2.
Porém quando deve-se usar o Caso 1, e quando deve-se usar o Caso 2 ? A
seguir são apresentadas algumas vantagens e desvantagens de cada
abordagem. Elas devem ser analisadas de acordo com os requisitos
estabelecidos pelo sistema que está sendo desenvolvido (Setzer,1986).
A Figura 3.12 tem uma tabela a menos. Isso significa menor espaço ocupado
pelos arquivos resultantes e, muito mais importante, maior eficiência (rapidez)
no processamento de operações que envolvam a associação. As transações
são também expressas de maneira mais simples. Portanto, se eficência for um
requisito do sistema que está sendo desenvolvido, deve-se optar por essa
abordagem.
73
A Figura 3.12 apresenta uma solução com maior independência de dados : a
tabela “Lotes” contém exclusivamente seus dados próprios, ao contrário da
Figura 3.11 em que recebe a chave de “Quadras”.
Uma vantagem da Figura 3.12 é que uma mudança estrutural do tipo da
associação, passando de “muitos para um” para “muitos para muitos”, não
requer nenhuma alteração estrutural nas tabelas, ao contrário da Figura 3.12.
3.4.4 - Mapeamento de Associações Um para Um
Para se fazer o mapeamento das associações “um para um” entre objetos
persistentes deve-se criar uma tabela para cada classe, e transpor a chave de
uma tabela para a outra. O sentido da transposição depende das formas de
acesso para ganho de eficiência.
Os exemplos da Figura 3.13 e da Figura 3.14 a seguir mostram as duas
maneiras de se mapear as associações um para um em tabelas. O exemplo da
Fig. 3.13 é melhor pois como todas as ocorrências de Imposto Predial e
Territorial Urbano (IPTU) possui um “lote” associado, logo a transposição da
chave de “lotes” para a tabela de “IPTU” não existirá ocorrência de valores
vazios. Já o contrário, como mostrado pela Figura 3.14, nem todas as
ocorrência de “lotes” possuem um “IPTU” associado. Os “lotes” da “prefeitura”
são isentos de “IPTU”. Neste último caso, na transposição da chave de “IPTU”
para “lotes”, existirá valores vazios nesta chave transposta para as ocorrências
de “lotes” pertencentes a “prefeitura” por exemplo. São eles :
• Caso 1. Transpõe-se a chave de “Lotes” para “IPTU”, como mostra a
Figura 3.13 a seguir.
74
IPTU
Lotes
Nro_IPTU
Valor
Vencimento
Situação
Id_Lote
Area
Proprietario
TABELA LOTES
TABELA IPTU
Id_Lote
Area
Proprietário
Nro_IPTU
Valor
Vencimento
Situacao
Id_Lote
10-01
1.200
Antonio C. M.
0345/96
1.200,00
12/03/98
NOT_OK
10-01
10-05
1.800
Paulo M.
0337/97
1.800,00
12/03/98
NOT_OK
10-05
08-03
900
Luiza E.
0224/95
900,00
12/03/98
OK
08-03
08-07
800
Luis I. L. S.
0112/97
800,00
12/03/98
OK
08-07
22-01
2.200
Fernando
0332/92
2.200,00
12/03/98
OK
22-01
...
...
...
...
...
H.
C.
22-02
3.000
Prefeitura
25-01
1.450
Prefeitura
...
...
...
Fig. 3.13 Primeira alternativa para mapear associações “um para um” em
tabelas - caso 1.
• Caso 2. Transpõe-se a chave de “IPTU” para “LOTES”, como mostra a
Figura 3.14 a seguir.
3.4.5 - Mapeamento de Generalizações
Existem três abordagens principais para o mapeamento de generalizações de
classes persistentes em tabelas. Serão dados exemplos das três abordagens
tomando-se como base a Figura 3.15. São elas :
75
TABELA LOTES
Id_Lote
Area
TABELA IPTU
Proprietário
Nro_IPTU
Nro_IPTU
Valor
Venciment
Situacao
o
10-01
1.200
Antonio C. M.
0345/96
0345/96
1.200,00
12/03/98
NOT_OK
10-05
1.800
Paulo M.
0337/97
0337/97
1.800,00
12/03/98
NOT_OK
08-03
900
Luiza E.
0224/95
0224/95
900,00
12/03/98
OK
08-07
800
Luis I. L. S.
0112/97
0112/97
800,00
12/03/98
OK
22-01
2.200
Fernando
0332/92
0332/92
2.200,00
12/03/98
OK
...
...
...
...
H.
C.
22-02
3.000
Prefeitura
Null
25-01
1.450
Prefeitura
Null
...
...
...
...
Fig. 3.14 - Segunda Alternativa para Mapear associações “um para um” em
Tabelas - Caso 2.
• Caso 1. A classe de generalização e as classes de especialização são
mapeadas cada uma para uma tabela. A chave da tabela da classe de
generalização é reproduzida nas tabelas das classes de especialização.
Um exemplo é dado na Figura 3.16.
Nesse exemplo, a identidade de um objeto através de uma generalização é
preservada com a utilização de um ID compartilhado. Desse modo, uma
dada ocorrência de “nó” terá uma linha na tabela “Pontos”, e outra linha na
tabela “Nos”, e em ambas as ocorrências permanecerá o mesmo valor
para “Id_Ponto”.
A coluna “Tipo” é acrescentada à tabela “Pontos” para que se possa saber
que tabela pesquisar, se a tabela de “nos” ou se a tabela de “vertices”.
A navegação nas tabelas do exemplo anterior poderia ser feita da seguinte
forma :
76
Ponto
Coordenada_X
Coordenada_Y
Nó
Vértice
Nro_de_Arcos
Posição
Fig. 3.15 - Exemplo de generalização-especialização: ponto, nó e vértice.
TABELA PONTOS
Id_Ponto
Coordenada_X
Coordenada_Y
TIPO
0001
3445
23322
NO
0002
7772
27765
NO
0003
8290
20900
VERTICE
0004
0023
00090
VERTCE
...
...
...
...
TABELA NOS
TABELA VERTICES
Id_Ponto
Nro_de_arcos
Id_ponto
Posicao
0001
4
0003
2
0002
5
0004
1
...
...
...
...
Fig. 3.16 - Mapeamento de generalização-especialização em tabelas de
generalização e em tabelas de especialização - Caso 1.
77
1) Dado o identificador de um ponto, descobre-se a linha da tabela
“Pontos” correspondente a ele.
2) Recupera-se o tipo do ponto para essa linha da tabela.
3) Vai-se para a tabela da classe de especialização indicada pelo tipo do
ponto e encontra-se a linha com o mesmo identificador da linha da tabela
“pontos”.
• Caso 2. Cada classe de especialização é mapeada para uma tabela. A
classe de generalização é eliminada, e seus atributos são reproduzidos em
cada tabela de especialização. Um exemplo é dado na Figura 3.17 a
seguir.
TABELA NOS
Id_Ponto
Coordenada_X
Coordenada_Y
Nro_de_arcos
0001
3445
23322
4
0002
7772
27765
5
...
...
...
...
TABELA VERTICES
Id_ponto
Coordenada_X
Coordenada_Y
Posicao
0003
8290
20900
2
0004
0023
00090
1
...
...
...
...
Fig. 3.17 - Mapeamento de generalização-especialização em tabelas de
especialização - Caso 2.
• Caso 3.
A classe de generalização é mapeada para uma tabela
juntamente com os atributos das classes de especialização. Um exemplo é
dado na Figura 3.18.
78
TABELA PONTOS
Id_Ponto
Coordenada_X
Coordenada_Y
Nro_Arco
Posicao
0001
3445
23322
4
Null
0002
7772
27765
5
Null
0003
8290
20900
Null
2
0004
0023
00090
Null
1
...
...
...
...
...
Fig. 3.18 - Mapeamento de generalização-especialização em tabela de
generalização.
Porém em que situação deve-se usar cada caso ? Abaixo seguem algumas
vantagens e desvantagens de cada abordagem. Elas devem ser analisadas de
acordo com os requisitos estabelecidos pelo sistema que está sendo
desenvolvido (Rumbaugh,1994) :
1) A Figura 3.16 apresenta a abordagem padrão, que é a mais correta e
estensiva logicamente. Contudo ela envolve muitas tabelas, e a navegação
das classes de generalização para as classes de especialização pode ser
lenta.
2) A Figura 3.17 apresenta uma abordagem que pode ser utilizada se as
classes de especialização possuírem muitos atributos, se a classe de
generalização tiver poucos atributos, e se a aplicação souber qual classe
deve ser pesquisada.
3) A Figura 3.18 apresenta a abordagem menos satisfatória, porém ela
pode ser útil se existirem somente duas ou três classes de generalização
com poucos atributos.
79
4) As abordagens das Figura 3.17 e Figura 3.18 são abordagens
alternativas motivadas pelo desejo de eliminar a navegação da classe de
generalização
para
as
classes
de
especialização,
melhorando
o
desempenho de consultas; contudo, esta melhora de desempenho incorre
em outros problemas, tal como armazenamento de valores nulos.
80
CAPÍTULO 4
MODELAGEM DE DADOS EM SISTEMAS DE INFORMAÇÃO GEOGRÁFICA
Este Capítulo possui três objetivos fundamentais. O primeiro visa realizar uma
investigação sobre a forma como o conhecimento geográfico foi modelado e
implementado em três SIGs de mercado: MGE, Arc/Info e SPRING. O segundo
objetivo visa descrever os conceitos que envolvem o OPENGIS, mais
especificamente feição e coverage. O terceiro busca realizar uma comparação
entre os três SIGs apresentados, tendo como referência os conceitos do
OPENGIS.
4.1 - MGE
4.1.1 - Conceitos e Fundamentos
O MGE, “Modular GIS Environment”, é um sistema gerenciador de dados
geográficos que possibilita capturar, armazenar, recuperar, analisar e
apresentar dados espaciais (Intergraph,1994).
O banco de dados geográfico construído por este sistema implementa uma
arquitetura dual onde os mapas (informações gráficas) e tabelas (informações
não gráficas) são armazenados em ambientes diferentes.
4.1.2 - Arquitetura do Sistema
Este sistema possui como característica fundamental a modularidade. São
diversos pacotes que se agregam visando atender um propósito específico de
trabalho. Existem três módulos primários sem os quais não se consegue
desenvolver qualquer trabalho. São eles:
81
1) MGE Basic Nucleus (MGNUC): trata-se do ambiente que permite o MGE
compilar e integrar todas os outros módulos e aplicações. Este módulo
oferece funções básicas para o gerenciamento de projetos, ferramentas
para consulta de dados, apresentação de dados geográficos, e se utiliza
de sistemas de coordenadas de projeção.
2) MGE Basic Administrator (MGAD): componente que oferece ferramentas
de gerenciamento de banco de dados para preparar o acesso aos dados
de um projeto em um ambiente multi-usuário ou mono-usuário. O MGAD
oferece uma configuração essencial e rotinas de gerenciamento para
funcionalidades disponíveis no MGE Basic Mapper (MGMAP). O MGAD é
necessário para um ambiente de rede local, quando um banco de dados
relacional é configurado como parte do sistema MGE para tratar dados não
espaciais ou alfanuméricos.
3) MGE Base Mapper (MGMAP): Contém funcionalidades que permitem
capturar, generalizar, ajustar, manipular e validar dados do projeto em um
ambiente interativo ou automático e funções para transformar descrições
de localização em posição geográfica (espacialização).
Além destes módulos primários, existem também os módulos básicos que são
a plataforma sobre o qual são executados módulos primários. São eles:
1) MicroStation: componente que oferece um completo ferramental gráfico
para desenhar vetores geométricos que representam dados espaciais. Por
exemplo, uma estrada pode ser uma série de linhas.
2) Relational Interface System (RIS): trata-se do software responsável pela
comunicação com o banco de dados relacional. Este módulo torna o banco
de dados relacional transparente ao usuário e permite que a interfaces do
MGE composta por menus acesse o banco de dados utilizado.
82
3) Relational Data Base (RDB): trata-se do SGBD utilizado para armazenar
informações descritiva dos atributos que usualmente estão associadas aos
dados gráficos provenientes do MicroStation. Por exemplo, pode-se
armazenar o nome e o tipo do pavimento como atributos em um banco de
dados relacional que descreve uma estrada. O MGE suporta muitos SGBD
relacionais. São eles: INFORMIX, INGRES, ORACLE, SYBASE e DB2.
A Figura 4.1 abaixo ilustra a arquitetura do sistema MGE.
MGE Base Mapper e outros Aplicativos
MGE Basic Administrator
(MGAD)
MGE Basic Nucleus
Relational Interface System (RIS)
Sistema Banco de Dados Relacional
Microstation
Fig. 4.1 - Arquitetura do Sistema MGE.
FONTE : adaptada de Intergraph (1994).
4.1.3 - Projeto
Um projeto no MGE combina todas as fontes de informações geográficas. Um
projeto está associado a uma área de estudo e é uma coleção de informações
geográficas (mapas e tabelas) relacionadas.
No projeto, as informações são estruturadas conforme sua origem. As feições
geográfica são agrupados em categorias, os elementos alfanuméricos são
armazenados em tabelas em um sistema gerenciador de banco de dados
relacional. Para isto deve existir um esquema que reflete esta estruturação no
banco de dados. A seguir são apresentados esses conceitos mais
detalhadamente.
83
4.1.3.1 - Esquema
Cada projeto MGE pode ter seu próprio esquema (uma coleção de tabelas e
privilégios de acesso do projeto ao banco de dados) ou vários projetos podem
compartilhar um esquema. Caso se esteja trabalhando sobre um ambiente
multiusuário, torna-se possível usar esquemas residentes em sistemas
remotos.
4.1.3.2 - Categorias e Classes de Feições
Em um projeto MGE os fenômenos geográficos são representados por
categoria, classes de feições e feição geográfica. Cada feição geográfica,
representada por um ponto, uma linha ou um polígono, é materializada em um
mapa ou arquivo .DGN e deverá pertencer a uma classe de feição. As classes
de feições são agregadas em categorias. A Figura 4.2 ilustra esta lógica.
4.1.3.3 - Representação da Informação Gráfica
As informações gráficas no MGE são armazenadas em arquivos de projeto no
MicroStation (.DGN), também usuamente denominados como mapas digitais.
Um elemento geográfico é representado sobre o mapa como uma feição
geográfica. Os tipos de feições representadas no MGE são ponto, linha,
fronteira de área3 e identificador de area4:
___________________________
3
4
Traduzido do inglês ‘area boundary’.
Traduzido do inglês ‘area centroid’.
84
Categoria
Agrupadas em
Classe de Feições
Fig. 4.2 - A representação de fenômenos geográficos no MGE: classe de
feição e categoria.
• Ponto: Um ponto representa a localização de um elemento geográfico,
tal como um poste ou hidrante, que é tão pequeno que não pode ser
representado como uma linha ou área. Um ponto pode ser representado
sobre o mapa como um ponto MicroStation (linha de tamanho zero), nó
texto, texto, ou elemento de célula.
• Linha: Trata-se de um conjunto de pontos conectados. Ruas, rios são
tipicamente feições lineares.
• Fronteira de Área: Trata-se de um conjunto de linhas fechadas sobre
uma região geográfica, como a fronteira de uma lago ou a fronteira de uma
cidade. As fronteiras são compartilhadas por áreas adjacentes, sendo que
o elemento gráfico não necessita ser duplicado.
• Identificador de Área: Este tipo de feição contém informações sobre os
atributos de uma área, e devem ser localizados em algum lugar no interior
da fronteira da área.
No MGE deve-se criar tabelas com atributos para conter essas
informações e ligá-las às feições. Um identificador de área
85
pode ser
apresentado sobre o mapa como um ponto, nó texto, texto ou elemento
célula.
• Indefinido: Este tipo de feição pode ser tudo que o usuário do sistema
determinar. Uma grade é um exemplo de uma feição indefinida.
4.1.3.4 - Representação da Informação Não Gráfica
As informações não espaciais no MGE ou atributos descritivos, conforme
definido em no tópico 2.2.4.1 Arquitetura Dual, são armazenadas em tabelas
em um SGBD relacional. Por exemplo, em um mapa de edificações é possível
associar, a todas as ocorrências, dados alfanuméricos tais como: endereço,
número de andares, nome da construtora, data de finalização da construção,
etc.
O MGE permite aos usuários executar esta associação pela criação dos
atributos na tabela, pelo cadastro dos dados, e pela ligação com as classes de
feições.
A associação dos valores de um ou mais atributos ligados a uma classe de
feição é chamado de definição de atributos. O MGE deixa o usuário definir o
atributo automaticamente para as feições quando elas são digitalizadas
(digitalização inteligente) ou, posteriormente, identificando-as uma a uma e
cadastrando-as.
86
4.1.4 - Modelagem de Dados no MGE
Identificou-se, até este ponto, alguns conceitos gerais que refletem como o
MGE interpreta os dados geográficos e os trata computacionalmente. Este item
abordará com um grau maior de detalhe as estruturas internas de
armazenamento e a manipulação dos dados geográficos.
De uma forma geral todos os dados deverão estar organizados em um projeto.
O projeto constitui-se da seguinte hierarquia: projeto, índices, categorias (nível
de índice), classe de feições (nível de feições) e atributos. A Figura 4.3 ilustra
esta hierarquia.
Projeto
Índices
Categoria
Classe de Feições
Fig. 4.3 - Organização Hierárquica de Dados Geográficos no MGE.
Um projeto é organizado por índices, que são denominados como arquivos de
índices geográficos. Esses índices são arquivos (.dgn) que contêm formas
geométricas que envolvem as classes de feições materializadas sobre o mapa.
Um índice pode ser composto por até 63 categorias. Cada categoria
componente pertence a um único nível do índice.
87
Uma categoria contém qualquer número de classes de feições ou temas
relacionados, que por sua vez agregam as feições geográficas materializadas
em mapas. Um mapa é simplesmente um arquivo de projeto (.dgn) que contém
feições geográficas. Cada feição geográfica é classificada em uma classe de
feição. Uma classe de feição pode ou não ter associada uma tabela de
atributos definida pelo usuário, no qual contém informação não gráfica sobre
cada feição geográfica.
Para exemplificar alguns destes conceitos vejamos o exemplo de modelagem
e estruturação no MGE da Figura 4.4. É mostrado um exemplo de um projeto
onde que modelou-se uma realidade natural e uma realidade artificial que
ocorreu como decorrência da intervenção do homem. (Intergraph, 1994)
adaptado.
Um projeto necessita de um conjunto de dados que incluem arquivos de
mapas, arquivo de índices geográficos, banco de dados com as tabelas
predefinidas, arquivos de suporte e arquivos padrão.
Os arquivos de mapas são arquivos no formato ‘dgn’ que contêm as feições
digitalizadas. Cada feição é um elemento do MicroStation com pelo menos um
atributo de ligação para a tabela de feição e opcionalmente, uma ligação com
uma tabela de atributos definida pelo usuário. Um mapa também contém um
sistema de coordenada MGE. A Figura 4.5 modela esta lógica.
O limite espacial de um mapa é denominado índice geográfico. Um nível em
um arquivo índices geográficos contém os limites espaciais dos mapas que
compõem uma categoria. Podem existir tantos níveis quantos forem o número
de categorias existentes. O nível e o nome do arquivo de índice para uma
categoria são armazenados na tabela de categoria na banco de dados. A
Figura 4.6 ilustra a idéia.
88
PROJETO XXX
Índice - natural.idx
Índice - artificial.idx
Categoria - Hidrografia
Categoria - Vias
Nível do Índice 1
Nível da
Feição
1
2
3
4
5
Nível do Índice 1
Feições
Nível da
Feição
Mapas
Área Inundável
Texto
Lago
Margem Dupla
Margem Simples
hidro.dgn
1
2
3
4
5
Feições
Rodovia
Texto Rodo
Ruas
Texto Rua
Margem Simples
Categoria - Físico
1
2
3
4
5
6
Feições
ruas.dgn
texto.dgn
Nível do Índice 2
Nível da
Feição
Mapas
Uso da Terra
Identificador Uso
Solo
Identificador Solo
Vegetação
Identificador Veg.
rodo.dgn
Categoria - Estruturas
Nível do Índice 2
Nível da
Feição
Mapas
uso.dgn
2
4
5
solo.dgn
Feições
Mapas
Id Ponte
Construção
Id Construção
veg.dgn
ponte.dgn
constr.dgn
texto.dgn
Categoria - Propriedades
Nível do Índice 3
Nível da
Feição
22
23
5
6
Feições
Quadra
Id Quadra
Lote
Id Lote
Mapas
Quadra.dgn
Lote.dgn
Fig. 4.4 - Exemplo de organização dos dados no MGE.
FONTE : adaptada de Integraph (1994).
O objetivo do arquivo de índices geográficos é, como o próprio termo “índice”
sugere, servir de uma primeira aproximação para definir a área geográfica de
interesse. Após ser realizada esta aproximação, através de ferramentas de
“zoom” por exemplo,
sobre os arquivos de índices geográficos que
armazenam somente os limites espaciais envolventes do conjuntos de feições
geográficas, carrega-se, em detalhes, todas as feições geográficas. Um
segundo objetivo é a organização que se impõe ao projeto no sentido de
referenciar categorias com determinadas semelhanças em um mesmo arquivo
de índice geográfico.
89
Arquivos de Mapas
CLASSE DE
FEIÇÕES
Mslink
fcode
fname
tablename
category
ftype
flevel
fstyle
fweight
fcolor
digcmd
displaypriority
outros...
ROTULOS
rotulo
contentstmt
x
y
CATEGORIA
Mslink
cname
indexname
indexlevel
indextype
TABELA DO USUARIO
Mslink
MapId
Outras Atributos...
Fig. 4.5 - Modelo de Dados implementado no MGE para arquivo de mapas.
A utilização deste mecanismo é tanto conveniente e importante quanto for a
dimensão e volume de dados gráficos do projeto. A Figura 4.7 reflete o modelo
de dados implementado para suportar isto.
4.1.5 - Topologia no MGE
Os arquivos de projeto originais, no fomato “dgn” provenientes do Microstation,
não possuem topologia para análise espacial. Por isto é preciso fazer uso de
diversos processos do MGE para construir a “inteligência topológica” ou
arquivos topológicos.
90
O limite espacial de cada
mapa, em destaque, é o
índice geográfico do referido
mapa.
QUADRA.DGN
LOGRADOUROS.DGN
CATEGORIA: VIAS
Todos os limites espaciais de uma categoria
estão localizados em um nível do arquivo
índices geográficos.
ÍNDICE NÍVEL 1: TRANSPORTE
ÍNDICE NÍVEL 2: INFRA-ESTRUTURA
ÍNDICE NÍVEL 3: VIAS
URBANO.IDX é um exemplo de arquivo de
índices geográficos. Possue três níveis:
Índice Nível 1 : Transporte
Índice Nível 2 : Infra-estrutura
Índice Nível 3 : Vias
Análises em nível macro, sobre o arquivo de
índices geográfico, como determinação de
área de estudo, são bem mais eficientes do
que se trabalhar com o mapa detalhado
(todas as feições geográficas).
Fig. 4.6 - Ilustração do conceito de índices geográficos.
91
CATEGORIA
Mslink
cname
indexname
indexlevel
indextype
Arquivos de Índices
Geográficos
MAPAS
Mslink
mapname
fname
tablename
Arquivos de Mapas
Fig. 4.7 - Modelo de dados do MGE que reflete o conceito de arquivo de índice
geográfico.
A definição de topologia empregada pelo MGE pode ser vista conforme já
descrita no tópico 2.2.5 Topologia em SIG.
Existem duas formas para se criar estes arquivos. Na primeira todos os
arquivos no formato “dgn”, deverão passar, um a um, pelos processos de
criação da topologia. Na segunda, somente as feições geográficas contidas na
área delimitada5 pelo usuário deverão passar pelo referido processo.
O aplicativo do MGE responsável pela análise espacial vetorial é o “MGE
analyst” (MGA) Intergraph (1997). Através dele cria-se um arquivo com a
topologia dos diversos mapas temáticos. Os mapas são então “cruzados”,
utilizando-se ferramentas do referido aplicativo, resultando informações
derivadas, como mostra o exemplo na Figura 4.8.
_____________________________
5
Proveniente do inglês fence.
92
1
2
C2
C
+
=
C1
R2
R
R1
1 - bairro 1
2 - bairro 2
C - Área Comercial
R - Residêncial
Fig. 4.8 - Exemplo de análise espacial no MGE.
4.2 - ARC/INFO
O
Arc/Info
suporta
computacionalmente
as
três
modelos
feições
de
geográficas.
dados
Feições
para
representar
geográficas
são
entidades do mundo real que podem ocorrer naturalmente como rios e
vegetação, ou podem ser construções como ruas, infra-estrutura subterrânea e
prédios, ou podem ser subdivisões da terra como municípios, propriedades e
divisões políticas. Os modelos suportados são: modelo de dados vetorial,
modelo de dados matricial, e o modelo de dados de rede irregular triangular
(TIN).
4.2.1 - Conceitos e Fundamentos
O Arc/Info implementa um modelo de dados híbrido chamado geo-relacional
que representa feições geográficas. Uma feição geográfica é representada no
SIG por dois tipos de informação: localização e descrição.
A principal estrutura para representar o modelo de dados vetorial do Arc/Info é
a Coverage (ESRI, 1994). Esta estrutura suporta o modelo geo-relacional
vetorial. Antes de avançarmos neste conceito, torna-se necessário explicitar
alguns fundamentos típicos do modelo de dados vetorial.
93
O dado de localização (espacial) é armazenado usando uma estrutura de
dados vetorial ou matricial como definido no tópico 2.2.3. O dado descritivo de
cada feição geográfica é armazenado em um conjunto de tabelas. Os dados
espaciais e descritivos são ligados de tal forma que ambos os conjuntos de
informação estão disponíveis ao usuário (ESRI, 1994).
4.2.2 - Modelo de Dados Vetorial
O modelo de dados vetorial representa as feições geográficas assim como o
mapa. Os pontos representam feições geográficas tão pequenas que não
podem ser mostradas como linhas ou áreas, por exemplo poços, telefones
púbicos e postes. As linhas representam feições geográficas que não podem
ser apresentadas como áreas, por exemplo ruas, rios e contornos de elevação.
As áreas representam feições geográficas homogêneas tal como estados,
municípios, propriedades e tipos de solos. Um sistema de coordenadas
cartesiana x,y referencia as localizações do mundo real.
No modelo de dados vetorial cada localização é armazenada com coordenada
x,y. Pontos são armazenados como uma única coordenada. Linhas ou arcos
são armazenadas como uma série ordenada de coordenadas x,y. Áreas ou
polígonos são armazenadas como uma série de coordenadas de x,y que define
um ou mais segmento de linha ou arco que se fecham para formar uma área
ou polígono.
À cada uma das feições representadas está associada um identificador único.
Portanto a lista de coordenadas de cada feição está associada com o
identificador da feição. A Figura 4.9 ilustra a definição.
94
Pontos
1
3
2
4
5
Identificador do
Ponto
1
2
3
4
5
Coordenadas
X,Y
1,5
0,3
4,4
2,1
1,1
Identificador da
Linha ou Arco
1
2
Coordenadas
X,Y
1,5 2,4 4,5
1,1 2,2 3,1 5,5
Identificador do
Polígono
1
2
Coordenadas
X,Y
1,5 3,5 4,4 3,3 1,4 1,5
1,2 2,1 3,2 5,1 3,1 1,1 1,2
Linha ou Arco
1
2
Polígonos
1
2
Fig. 4.9 - Ilustração da representação computacional de dados vetoriais no
Arc/Info.
FONTE : adaptada de ESRI (1994).
4.2.2.1 - Topologia no Arc/Info
O conceito de topologia implementado no Arc/Info é baseado na estrutura ArcNó, descrita no tópico 2.2.5.1, e implementa os três conceitos: Conectividade,
Definição de Área e Contiguidade, já apresentados no capítulo 2.
95
4.2.2.2 - Regiões
As regiões suportam a modelagem de relacionamentos complexos entre
feições
geográficas
representadas
como
polígonos.
Uma
região
é
representada por um conjunto de polígonos. Por exemplo, uma região de
floresta e uma outra região de floresta destruída pelo fogo são representadas
por polígonos que indicam as áreas de florestas antes do incêndio e as áreas
destruídas após o incêndio. Neste caso, pode ocorrer sobreposição dos
polígonos que compõem as duas regiões modeladas. Outro caso é o das ilhas
que formam um arquipélago. Por exemplo, o país Japão é uma região
representada por vários polígonos.
Assim como ponto, linha e polígono, à cada região é dado um identificador
único e o cálculo da área e perímetro são mantidos.
Construir regiões com polígonos é similar a construir polígonos com arcos.
Assim como o polígono é uma lista de arcos, uma região é um lista de
polígonos. Porém existe uma distinção importante: a ordem dos polígonos não
é relevante. A Figura 4.10 ilustra o conceito de região.
C
4
3
B
5
Região
2
D
1
A
B
C
D
7
6
Lista de
Polígonos
6, 7
4, 5
2, 3, 4
1, 2
A
Fig. 4.10 - Ilustração do conceito de região.
FONTE : adaptada de ESRI (1994).
96
4.2.2.3 - Rotas
As rotas definem caminhos ao longo de um conjunto de feições lineares
existentes. As rotas baseiam-se em arcos. Como exemplos de utilização podese citar, para o caso de rota de um ponto a outro, o caminho de casa para a
escola ou, no caso de um circuito que começa e termina em um mesmo ponto,
uma rota de ônibus.
CASA
4
1
Ônibus
6
2
13
8
3
5
7
7
8
12
6
ESCOLA
14
11
15
10
4
5
1
ROTA
Casa - Escola
Rota de Ônibus
9
16
2
17
3
Lista de Arcos
1, 3, 6, 8
7, 8, 11, 4, 17, 3, 2, 1, 14, 13
Fig. 4.11 - Ilustração do conceito de rota.
FONTE : adaptada de ESRI (1994).
O modelo de dados vetorial implementado pelo Arc/Info está alicerçado no
conceito de topologia. O armazenamento organizado, e a leitura indexada do
dados fornecem ao sistema a possibilidade de realizar manipulações espaciais
à qualquer momento.
4.2.2.4 - Representação das Informações Descritivas
Até agora apresentamos as formas de representação das feições geográficas
baseadas no conceito de topologia. No entanto, é necessário apresentar a
forma de representação das informações descritivas associadas às feições
geográficas. O mecanismo de ligação entre as duas representações também é
abordado.
97
Os atributos descritivos associados às feições geográficas são armazenados
da mesma forma que as coordenadas. O arquivo com os dados descritivos é
denominado de tabela de atributos. Cada linha desta tabela é chamada de
contêm as informações descritivas de uma única feição. As colunas ou campos
definidas na tabela são as mesmas para cada linha.
A ligação entre as feições geográficas e a tabela de atributos é garantida pelo
modelo geo-relacional implementado pelo Arc/Info. Na prática um identificador
único materializa a ligação entre as coordenadas das feições geográficas e os
atributos descritivos, mantendo uma correspondência um para um, entre o
registro espacial e o registro de atributos.
Uma vez que esta conexão é estabelecida, pode-se apresentar as informações
descritivas sobre o mapa e armazenar novas informações descritivas. A Figura
4.12 ilustra a representação.
No exemplo da Figura 4.12, a coluna denominada “polígono” armazena o
identificador único que estabelece a ligação entre os dados espaciais e os
dados descritivos. Neste caso, o polígono com identificador “A” tem seus
atributos espaciais descritos na tabela “Topologia Polígono-Arco” e os atributos
descritivos ou não espaciais descritos pela “Tabela de Atributos de Polígonos”.
Nesta tabela pode-se criar tantos atributos quantos forem necessários para
descrever devidamente o dado espacial, ou fazer uso de outras tabelas que
possuam um atributo em comum com a “Tabela de Atributos de Polígonos”
como é o caso da “Tabela de Propriedade”. Neste último caso faz-se uso de
funções típicas de um ambiente relacional tais como “Join” entre tabelas, para
se acessar todos os atributos.
98
TOPOLOGIA POLIGONO-ARCO
7
1
Polígono
A
B
C
D
A
D
9
8
2
6
11
10
C
B
TABELA DE ATRIBUTOS DE POLÍGONO
3
5
Lista de Arcos
1, 9
3, 10
5, 11
7, 8
4
Polígono
Área
A
B
C
D
86,03
79,12
78,45
72,13
Outros
Atributos
...
...
...
...
Código
Quadra
550-002
550-022
550-021
550-001
TABELA DE PROPRIETARIOS
Código
Quadra
550-001
550-002
550-002
550-002
550-003
Código
Proprietário
223-76
224-82
225-97
226-97
227-89
Proprietário
Paulo M.
Fernando H. C.
Antônio C. M.
Luís I. L. S.
José S.
Outros
Atributos
...
...
...
...
...
Fig. 4.12 - Ilustração da representação das informações descritivas.
FONTE : adaptada de ESRI (1994).
O Arc/Info gerencia três tipos de tabelas de atributos. O primeiro tipo consiste
das tabelas de atributo das feições geográficas, que abrange as tabelas de
topologia para polígono, arco, nó, ponto, rota, região, na Figura 4.12 é indicada
como TOPOLOGIA POLÍGONO-ARCO. O segundo tipo consiste dos arquivos
de dados INFO, que são similares às tabelas provenientes dos SGBD
relacionais de mercado, na Figura 4.12 é indicada como TABELA DE
ATRIBUTOS DE POLÍGONO. E o terceiro tipo consiste das tabelas de
atributos externas cuja fonte são os próprios SGBDR tais como ORACLE,
INGRES, INFORMIX, SYBASE, indicada também na Figura 4.12 como
TABELA DE PROPRIETARIOS.
99
4.2.3 - Coverage6
Para a organização dos dados no Arc/Info, visando representar a realidade
geográfica, é utilizado o conceito de coverage. Coverage é uma estrutura para
o armazenamento de dados vetoriais. Ela representa um único conjunto de
objetos geográficos tal como, ruas, propriedades, tipos de solos ou padrões de
florestas. Uma coverage suporta o modelo geo-relacional onde contempla
tanto dados espaciais quanto os atributos para as feições geográficas.
Uma coverage contém um conjunto de feições, onde cada uma é representada
por uma classe de feição como arco, nó, ponto, anotações ou polígono. A
combinação das classes de feições presentes em uma coverage depende do
fenômeno geográfico a ser representado. A Figura 4.14 ilustra esta idéia.
Conforme o modelo geo-relacional, uma feição geográfica em uma coverage é
identificada por um único número. O dado espacial e o atributo são ligados por
este número.
4.2.4 - Outras Representações
Além do modelo de dados vetorial, tendo a coverage como o principal método
de representação no Arc/Info, existem o modelo de dados matricial e o modelo
de rede irregular triangular.
__________________________________
6
Palavra proveniente do inglês cujo significado direto é cobertura. Aplicada à
área de geoprocessamento pode-se traduzir como sendo área de estudo
coberta. Pela ampla utilização achamos prudente manter o termo em inglês
neste trabalho.
100
O modelo de dados matricial representa as feições geográficas como uma
fotografia materializada por uma grade regular de pontos. Cada ponto desta
grade é denominado “célula” ou “pixel”. As células possuem valores que
podem representar três interpretações: uma classificação, como o tipo de
vegetação por exemplo; uma medida da quantidade de luz refletida pela Terra
proveniente de uma imagem de satélite; e finalmente uma medida de
elevação.
Portanto o método utilizado para representar o modelo de dados vetorial é a
grade regular ou “grid”. Para maiores detalhes ver Esri (1994).
O modelo de rede irregular triangular ou “TIN”7 é uma outra estrutura utilizada
para representar superfícies contínuas, assim como a grade regular. O TIN
representa a superfície por uma série de pontos ligados de forma triangular.
Cada três pontos, que geram um triângulo, podem ocorrer em qualquer
localização geográfica, daí decorre a irregularidade, diferença básica da grade
regular. Além disto os relacionamentos topológicos entre os triângulos são
criados e armazenados por este modelo. Para maiores detalhes ver Esri
(1994).
4.3 - SPRING
4.3.1 - Apresentação
O SPRING, Sistema para Processamento de Informações Georeferenciadas,
desenvolvido pelo INPE (Instituto Nacional de Pesquisas Espaciais) para
ambientes UNIX e Windows (em desenvolvimento) possui as seguintes
características (INPE.DPI, 1998a):
____________________________________
7
Proveniente de abreviatura em inglês “Triangulated Irregular Network”
101
Coverage: PROPRIEDADE.
2
1
NÓ
2
3
3
PONTO
4
1
4
ARCO
ANOTAÇÃO
lago
POLÍGONO
5
6
6
Número da
Propriedade
1
2
3
4
5
6
5
Polígonos #
1
2
3
4
5
6
Lista de Arcos
6, 7, 8
7, 1, 10, 9
8, 9, 11, 13, 15, 5, 16
2, 12, 11, 10
3, 14, 13, 12
4, 15, 14
Área_Km2
Area_Produtiva_Km2
Proprietário
1242,20
1532,32
2730,55
1129,34
1601,77
1923,87
1023,55
890,11
2599,88
1129,34
745,22
432,12
Edson A.
Francisco R.
Mário C.
Franco M.
José R.
Almino A.
Fig. 4.13 - Exemplo de uma coverage: Propriedade.
• opera como um banco de dados geográfico sem fronteiras e suporta
grande volume de dados (sem limitações de escala, projeção e fuso),
mantendo a identidade dos objetos geográficos ao longo de todo banco;
• administra tanto dados vetoriais como dados matriciais, e realiza a
integração de dados de sensoriamento remoto;
• provê um ambiente de trabalho amigável e poderoso, através da
combinação de menus e janelas com uma linguagem espacial facilmente
102
programável pelo usuário: Linguagem Espacial para Geoprocessamento
Algébrico (LEGAL);
• consegue escalonabilidade completa, isto é, é capaz de operar com toda
sua funcionalidade em ambientes que variem desde micro-computadores a
estações de trabalho RISC de alto desempenho.
O desenvolvimento de uma nova geração de sistemas de processamento de
imagens e geoprocessamento no INPE iniciou-se em 1991, e teve seu primeiro
resultado concreto em 1993, com o lançamento da versão 1.0 do SPRING. A
evolução do sistema SPRING durante estes anos levou ao lançamento em
1996 da versão 2.0.
Seguindo uma estratégia de utilizar sistemas competitivos e no estado da arte,
o INPE está migrando o sistema para o ambiente de microcomputadores (MSWindows), gerando assim o SPRING For Windows. Este produto mostra-se
altamente promissor, uma vez que incorpora todas as funcionalidades e
vantagens do SPRING/UNIX em um ambiente simples e de larga utilização no
mercado.
4.3.2 - Arquitetura do Sistema
O sistema SPRING é composto por três módulos IMPIMA, SPRING e
SCARTA. Segue suas definições (INPE.DPI, 1998b):
• IMPIMA : executa leitura de imagens digitais de satélite, gravadas pelo
INPE, através dos dispositivos Compact Disc - Read Only Memory (CDROM), Computer Compatible Tapes (CCT), "streamer" (60 ou 150
megabytes) e Digital Audio Tape - 4 ou 8mm (DAT) adquiridas a partir dos
sensores TM/LANDSAT-5, HRV/SPOT e AVHRR/NOAA. Converte as
103
imagens dos formatos BSQ, Fast Format, BIL e 1B para o formato GRIB
(Gridded Binary).
• SPRING : é o módulo principal de entrada, manipulação e transformação
de dados geográficos, executando as funções relacionadas à criação,
manipulação e consulta ao banco de dados, funções de entrada de dados,
processamento digital de imagens, modelagem numérica de terreno e
análise geográfica de dados. As funções da janela principal, na barra de
menus, estão divididas em: Arquivo, Editar, Exibir, Imagem, Temático,
Numérico Cadastral, Rede, Objetos e Utilitários. Para cada opção há um
menu (janela de diálogo) associado às operações específicas.
• SCARTA : edita uma carta e gera arquivo para impressão a partir de
resultados
gerados
no
módulo
principal
SPRING,
permitindo
a
apresentação sob a forma de um documento cartográfico. Permite editar
textos, símbolos, legendas, linhas, quadros e grades em coordenadas
planas ou geográficas. Permite exibir mapas em várias escalas, no formato
varredura ou vector, através do recurso "O que você vê é o que você tem"
(What You See Is What You Get, Wysiwyg).
O banco de dados geográfico construído pelo SPRING implementa uma
arquitetura dual onde as representações dos dados espaciais e as informações
descritivas (dados não espaciais) são armazenados em ambientes diferentes.
As representações gráficas se utilizam de arquivos convencionais do tipo
binário onde são armazenados as coordenadas x, y que definem a geometria
de um objeto geográfico ou campo do SPRING. Este armazenamento é
realizado segundo algorítmo R-tree para prover uma indexação dos dados.
Os atributos descritivos destes objetos ou campos são armazenados em
tabelas em um banco de dados relacional.
104
Um identificador único é responsável pela ligação dos dois componentes.
Com a evolução do SPRING, sistemas gerenciadores de banco de dados
relacionais
foram
adotados,
para
implementar
uma
estratégia
para
portabilidade de software. Hoje a visão estática, é implementada em SGBDR
de mercado tais como CODEBASE e ORACLE.
A visão funcional e dinâmica representada pelos métodos das classes
modeladas no SPRING e as ligações e associações entre seus objetos foram
implementadas pela linguagem de programação C++.
4.3.3 Modelo Conceitual do SPRING
A realidade geográfica é representada no SPRING por uma modelo conceitual
baseado no paradigma orientado por objetos. A persistência dos dados é
realizada em um ambiente dual conforme exposto anteriormente.
Na busca de um melhor detalhamento e compreensão do modelo de conceitual
implementado pelo SPRING, além da documentação disponível na Internet,
foram construídos e aplicados dois tipos de questionários. Um questionário foi
dirigido aos desenvolvedores, e o outro foi aplicado aos usuários do sistema. A
íntegra dos questionários está no Apêndice A.
Como resultado desta pesquisa,
apresentadas
no
Apêndice
B,
além da tabulação das respostas
a
discussão,
principalmente
com
os
desenvolvedores do sistema ajudou-nos a compreender a semântica do
modelo orientado por objetos apresentado na Figura 4.14, representada pela
técnica TMO.
105
O Banco de Dados Geográfico é definido no SPRING por um nome e um
caminho (path) que devem ser fornecidos pelo usuário. O sistema criará no
caminho indicado um diretório, que corresponde fisicamente ao seu banco.
Tudo que for criado e definido para este banco será armazenado debaixo
deste diretório. Após criar um Banco de Dados é necessário ativá-lo para que
se possa prosseguir. Somente um Banco de Dados pode estar ativo de cada
vez (INPE.DPI, 1998e)
BANCO DE DADOS
GEOGRAFICOS
PROJETO
PROJEÇÃO
DATUM
CAMPO
TEMATICO
CATEGORIA
PLANO DE INFORMACAO
MNT
MAPA DE OBJETOS
IMAGEM
REDE
CADASTRAL
REPRESENTACAO
VETORIAL
PONTOS LINHAS
POLIGONO
OBJETOS
VISUAL
MATRIZ
GRADE REGULAR
GRADE TRIANGULAR
Fig. 4.14 - Modelo Orientado por Objetos do SPRING.
As Categorias e Classes Temáticas devem ser definidas a priori, para que
cada tipo de dado a ser tratado pelo SPRING seja associado a uma categoria.
Cada categoria pertence a um modelo de dados (Temático, Numérico,
Imagem, Cadastral, Redes e Objeto). O usuário não precisa definir todas as
106
categorias de imediato, mesmo porque, muitas vezes não se sabe tudo que
será necessário para chegar no seu objetivo. A qualquer momento pode-se
acrescentar ou definir novas categorias. Apenas nas categorias do modelo
Temático é necessário definir classes. Classes temáticas definem o modo
(visual) como pontos, linhas e áreas serão apresentadas no monitor (cor,
hachura, preenchimento, etc).
Um projeto define a área fisica de trabalho. Para criar um projeto deve-se
fornecer um nome, projeção e retângulo envolvente. Ao se fazer isso, um
subdiretório, embaixo do diretório correspondente ao banco, será criado, e
todos os dados referentes à uma dada região serão armazenados nele. A
condição para criar um projeto é apenas ter um banco ativo, não sendo
necessário definir as categorias. Pode-se ter quantos projetos se desejar, mas
somente um pode estar ativo de cada vez.
Os planos de informações (PIs) são armazenados dentro de um projeto. Os
PIs representam mapas de solos, mapas de estradas, imagens, etc., que
estejam na mesma área geográfica de estudo definido pelo retângulo
envolvente. Um PI é criado fornecendo-se um nome, a categoria à qual ele
pertencerá (previamente definida), a escala (quando PI Temático, Numérico ou
Cadastral) e a resolução (quando PI Numérico ou Imagem), desde de que
tenha um Banco de Dados e um Projeto ativos. Pode-se ter quantos PIs se
desejar da mesma categoria ou não, mas apenas um estará ativo.
Um dado no SPRING pode estar representado no formato matricial e/ou
vetorial, dependendo do modelo (categoria) ao qual ele pertence. Para editar
pontos, linhas e áreas no formato vetorial, pode-se utilizar uma mesa
digitalizadora, para transferir os dados do mapa para computador, ou importar
arquivos de outros softwares ou formatos. Para dados matriciais pode-se
utilizar leitura de imagens gravadas em formatos específicos, interpolar grades
107
(matrizes) numéricas ou mesmo converter dados da representação vetorial
para matricial.
Uma vez que tem-se os dados (PIs) editados, pode-se obter outros dados
através de análises, cruzamentos, etc., por meio de funções específicas do
software ou de uma linguagem de programação para mapas.
No SPRING as feições geográficas do mundo real são modeladas por dois
grandes tipos de dados: geo-objetos e geo-campos. A seguir é mostrada, com
maior detalhe, os tipos de dados suportados pelo SPRING provenientes dos
tipos de plano de informação (INPE.DPI, 1998c):
1) Os tipos de dados cadastrais, sub-tipo de geo-objetos, descrevem a
localização de elementos de sistemas de informação de cadastro urbano
ou rural, e utilizam a topologia arco-nó-polígono para armazenamento. Um
item específico sobre a estrutura topológica implementado pelo SPRING
será apresentado à frente.
2) Os dados do tipo rede, sub-tipo de geo-objetos utilizam a topologia arconó, e armazenam a localização e a simbologia associadas a estruturas
linearmente conectadas. Informações adicionais neste tipo de mapas
incluem direções de fluxo e segmentação dinâmica.
3) Os dados do tipo mapa temático, sub-tipo de geo-campos, representam
uma dada região geográfica R, associando a cada ponto do espaço um
tema de um mapa (p.ex. um mapa de solos é caracterizado pelo conjunto
{latosolo roxo, litosolo, cambisolo, ...})
4) Os tipos de dados numéricos, sub-tipo de geo-campos, de associam
para cada ponto do espaço, de uma região geográfica, um valor real (p. ex.
um mapa de campo magnético, um modelo numérico de terreno);
108
5) O tipo de dados denominado de Imagem de satélite, sub-tipo de geocampo, é obtida através de discretização da resposta recebida por um
sensor (passivo ou ativo) para todos os pontos de uma dada região
geográfica.
Seja qual for o tipo de dado ele possui uma representação gráfica que pode
ser vetorial ou matricial, excluindo o caso dos objetos não espaciais. É
evidente que para cada plano de informação especializado, ou tipo de dados
tratado, existe uma representação mais utilizada. No entanto o sistema oferece
mecanismos de conversão entre os dois tipos de representações possíveis.
Na representação vetorial, a parte gráfica do objeto espacial ou campo, é
implementada usando uma das três geometrias básicas: pontos, linhas e
polígonos.
Já
na
representação
matricial,
a
realidade
geográfica
é
implementada por dois métodos: grade regular ou grade triangular irregular.
Para finalizar a descrição da semântica do modelo orientado por objetos do
SPRING, existe o conceito de “visual” que é associado à categoria e à
representação gráfica dos objetos e campos. O visual define as propriedades
tais como cor, espessura de linha, estilo da linha, etc. que pode ser prédefinida para as categorias, podendo ser especifico para uma dada
representação gráfica de um determinado objeto. Desta forma, todo o plano de
informação de uma dada categoria “herda” estas propriedades de visual da
categoria. Além disto, o sistema permite ao usuário modificar o visual
específico de cada representação gráfica alterando o visual herdado pela
referida categoria.
109
4.3.4 - Topologia no SPRING
O conceito de topologia implementado no SPRING é baseado na estrutura
Arco-Nó, descrita no item 2.3.1 Estrutura de dados arco-nó, e implementa os
três conceitos topológicos importantes: Conectividade, Definição de Área e
Contiguidade, já apresentados pelo itens 2.3.2, 2.3.3, 2.3.4 respectivamente.
4.4 O - Padrão OPEN GIS
O desenvolvimento do assunto deste tópico tem como objetivo, além de
apresentar e elucidar
alguns resultados alcançados por esta organização,
servir de marco de referência para uma comparação entre os três SIGs
apresentados anteriormente.
4.4.1 - Conceito
O Consórcio OPEN GIS - OGC é uma organização sem fins lucrativos
dedicada a tornar os sistemas de geoprocessamento abertos (OGC, 1998D). O
OGC almeja a integração completa de dados geográficos e recursos de
geoprocessamento através do uso de sistemas de informação geográficas
interoperáveis.
O comitê técnico do consórcio está em processo de estabelecer uma
especificação que define uma arquitetura de software abrangente para
sistemas abertos de geoprocessamento. Os sistemas construídos baseados
nesta especificação serão capaz de praticar a interoperação entre aplicações
em uma rede local, e serão capaz, também, de navegar sobre um ambiente
heterogêneo e distribuído, como a Internet, e de acessar dados geográficos
heterogêneos e recursos de geoprocessamento.
110
Para a criação dessa especificação, o consórcio OPEN GIS utiliza-se de um
processo de consenso entre seus membros. Tal consenso é traduzido para
uma especificação abstrata e uma especificação de implementação para cada
um dos componentes de software relacionados aos Sistemas de Informação
Geográfica.
Através dos grupos de trabalho formados pelos membros do consórcio, o
modelo essencial (isto é, a descrição formal do mundo real) e a especificação
do modelo (isto é, a descrição de como o sistema representará o mundo real),
são desenvolvidos. O modelo essencial e a especificação do modelo, juntas,
são denominadas de “especificação abstrata”.
Quando a especificação abstrata está suficientemente madura, os membros do
OGC constróem os requisitos para uma proposta de especificação de
implementação. As respostas desta proposta fornecem uma especificação de
implementação para uma plataforma neutra, incluindo uma linguagem de
definição de interface.
Quando todos os membros do OGC chegam a um consenso, a proposta de
especificação de implementação passa a ser parte da base de especificações
da OGC. Então, para cada software indicado pelos membros será verificada a
conformidade com as especificações de implementação. Caso atenda às
especificações, o software passará a ter o certificado OGC.
111
4.4.2 - O Conceito de Comunidade de Informação Geo-espacial
Uma comunidade de informação geo-espacial (CIG) é uma coleção de
sistemas ou indivíduos que compartilham informações espaciais, definições,
interesses e tecnologia.
Os indivíduos que não pertencem à mesma comunidade de informação e
querem compartilhar informações são impedidos de fazê-lo por três motivos:
• ignorância da existência da informação fora de sua comunidade;
• modelagem do fenômeno sem interesse mútuo e
• modelagem do mesmo fenômeno em duas representações distintas, em
dois CIG diferentes, fazendo com que uma representação não reconheça a
outra e vice-versa.
A especificação OGC visa superar estas limitações. O OGC capacita os CIG a
articular seus domínios de interesse, ao fornecer duas novas tecnologias que
objetivam:
• anunciar sua existência e suas informações para que estes outros CIGs
possam descobrí-lo e acessá-lo, sempre que exista o interesse de
compartilhar informações, e
• preservar a semântica quando ocorre a transferência de dados de um
CIG para outro.
A aplicação e o amadurecimento da tecnologia OGIS deverão resultar no
crescimento do tamanho e formalismo do CIG, além de incrementar a
disponibilidade de informações pelo referido CIG. Esta tendência pode ser
acompanhada com uma redução gradual do número de CIGs distintos, à
medida que estes apliquem o padrão OGIS.
112
Para formalizar um projeto do mundo real em um CIG, serão brevemente
apresentados os diversos níveis de abstração para modelar os fatos do mundo
real como coleções de feições no OPEN GIS. Existem duas tecnologias
fundamentais para modelar fatos do mundo real: feições com geometria
(features) e coverage. Os conceitos relativos a estes dois termos serão
introduzido em tópicos mais à frente.
Nove níveis de abstração são identificados, com oito interfaces entre elas. Os
níveis de abstração, seus nomes, as linguagem utilizadas, suas interfaces e os
métodos que suportam a navegação através da interface são todos
apresentados na Figura 4.15.
Os nove níveis podem ser vistos em OGIS (1998B) com detalhe. Os cinco
primeiro níveis de abstração, do nível do “mundo real” para o nível do “visão do
mundo”, objetivam gerar
a abstração dos fatos do mundo real e não são
diretamente implementados em
um software. Os quatro últimos níveis, do
nível “pontos do OGIS” até o nível “coleções de feições do mundo OGIS”,
visam gerar modelos matemáticos e simbólicos do mundo e são diretamente
implementáveis no software. Assim, o modelo essencial gerado ao final dos
quatro últimos níveis dá uma especificação abstrata para as suas
implementações. O nível final é a abstração da realidade especificada em uma
linguagem de coleções de feições OGIS.
4.4.3 - Feição e Conceitos Associados
Feição é definida na documentação do OGIS como sendo uma representação
abstrata do mundo real, ou seja, o átomo da representação geográfica.
113
Este conceito geral é especificado e adotado pelo OGIS somente dentro do
contexto da Comunidade de Informação Geoespacial e será apresentado a
seguir.
A feição OGIS é compreendida pela comunidade como sendo uma classe
abstrata sobre a qual se derivam duas sub-classes principais responsáveis
pela sua representação. São elas: feição com geometria e coverage. A Figura
4.16 ilustra a idéia.
4.4.3.1 - Noção Geral de Informação Geo-espacial
Informação geo-espacial é qualquer coisa que pode ser aprendida olhando em
um mapa, não em qualquer mapa, mas em mapas novos, criativos, e com
anotações. Um mapa pode ser interpretado como uma metáfora do mundo
real. Uma imagem de satélite é aceita por esta comunidade como um tipo de
mapa, bem como as coleções estruturadas de exemplos de fenômenos da
Terra (OGIS 1998A).
A informação geo-espacial digital é a informação geo-espacial codificada na
forma digital. A codificação é feita por recursos computacionais aplicados para
automatizar processos da informação geo-espacial tais como: armazenamento,
transmissão, análises e assim por diante.
O modelo OGIS, não trata, por agora, o caso de mapas que representam a
variação temporal de fenômenos geográficos.
A unidade básica da informação geo-espacial é chamada de feição. Feições
podem ser definidas recursivamente como variações delas próprias. Por
exemplo, dependendo da aplicação ou interesse da informação, qualquer item
a seguir pode ser uma feição:
114
Mundo
Dimensional;
Interface com
a comunidade
Linguagem
Métrica
Interface da
métrica local
Projeto do
Mundo (Visão
do Mundo);
Interface
Referencia
Espacial
Pontos OGIS
Comunidade de
Informação
Interface de
estruturas
geométricas
Coordenadas
Geométricas
Mundo
Geoespacial;
Mundo
geométrico
OGIS;
Linguagem
SIG
WFTs* OGIS
Mundo
Conceitual;
Interface de
Estruturas de
Feição
Feições do
mundo OGIS;
Interface
Disciplinada
para SIG
Feições
OGIS
Linguagem
Natural
Inteface de
projeto
estruturado
Interface
Epistêmica
Mundo Real;
Linguagem
Essencial
Coleção de
feições do
mundo OGIS;
Coleção de
feições OGIS
Fig. 4.15 - Os nove níveis de abstração definidos pelo OGIS.
FONTE : adaptada de OGC (1998A).
(*) “Well-Known-Types”, ou seja, tipos bem conhecidos.
115
FEIÇÃO OGIS
COVERAGE
FEIÇÃO
COM GEOMETRIA
Fig. 4.16- Feição OGIS e seus subtipos.
FONTE : adaptada de OGC (1998B).
• um segmento de uma rodovia entre duas intercessões consecutivas;
• uma rodovia constituída de muitos segmentos;
• uma imagem de satélite georeferenciada;
• um pixel de uma imagem de satélite georeferenciada;
• uma rede de drenagem e
• uma rede triangular irregular.
Existem diferentes maneiras para criar a representação digital da informação
geo-espacial. Esta riqueza de alternativas tem se tornado mais um problema
do que um benefício. A variedade de estruturas de dados e formatos do SIGs
torna a área confusa e aparentemente caótica, e atualmente tem criado
obstáculos para os usuários.
A especificação abstrata que está sendo criada pelo OGIS tem o objetivo de
colocar ordem neste caos.
116
4.4.3.2 - Especificação Abstrata de Feições
4.4.3.3 - Tipos de Feições
Até o presente momento o consenso existente sobre a definição de feição
geográfica é apresentada, resumidamente, no parágrafo a seguir.
Uma feição pode ser composta por outras feições. Uma feição pode ser
derivada de um tipo principal de feição. Uma feição deve ser instancializada de
um tipo, quando solicitada por um cliente OPEN GIS e enviada a ele em um
formato “bem conhecido".
O termo "bem conhecido" neste contexto significa: definido usando significados
compreendidos pelos clientes OPEGIS. Isto pode ser definido explicitamente
em uma especificação de implementação, mas provavelmente alguns
significados são disponíveis pela tecnologia de distribuição que será utilizada
(ex.: SQL, CORBA IDL.) (OGIS 1998A).
4.4.3.4 - Atributos de Feições
A uma feição são associados atributos. Cada atributo é distinto por um nome e
um valor dentro do domínio de valores do atributo. Nomes e domínios de
atributos associados são definidos pelo tipo do atributo.
Um subconjunto de atributos de uma feição pode ser geométrico (isto é, do tipo
geométrico). Este subconjunto pode representar a extensão espacial de uma
feição, ou pode ser vazio para feições de outros tipos.
117
4.4.3.5 - Identidade das Feições
Uma feição tem um identificador único dentro de um domínio e independe do
valor de qualquer ou de todos os seus atributos associados.
4.4.3.6 - Persistência de Feições
Uma feição é geralmente persistente. Um consenso sobre o conceito de
persistência está ainda em amadurecimento no OPENGIS. Esta é uma área
onde é necessário trabalhos futuros.
4.4.3.7 - Instância de Feições
Uma feição pode ser referenciada como uma instância de feição.
4.4.3.8 - Coleção de Feições
Os membros do consórcio OGIS ainda não chegaram a um consenso em
muitos assuntos sobre as coleções de feições. A seguir apresenta-se estes
assuntos em discussão relacionado ao tema coleção de feição.
• uma feição pode ser uma composição de outras feições;
• uma área pode ser uma feição composta de feições contidas nela e
• uma feição pode ser “dividida” por limites de áreas, e pode ser
reagrupada como uma única feição quando solicitada por uma interface ou
por um serviço.
No entanto o mundo real, em alguns casos, é visto como uma coleção de
feições que necessitam ser modeladas. Este mundo real inclui:
• projetos com limites bem definidos e feições que atendam certos critérios;
118
• produtos provenientes de agências governamentais, tais como SDTS e
arquivos similares;
• bancos de dado de SIG e
• persistência e não persistência de coleções do feições presentes em um
espaço de trabalho de um SIG.
Apesar destas dúvidas, a especificação do consórcio OPEN GIS expõe as
seguinte características sobre coleção de feições em consenso.
• uma coleção de feições é uma instância de feição que agrupa outras
feições;
• uma coleção de feições é também uma feição é por isso possui um tipo,
identificador, um conjunto de atributos associados e podem participar de
certos processos, e
• a utilização de coleção de feições inclui a representação lógica ou física
de feições; feições complexas ou compostas; o resultado de uma consulta;
uma coleção de feição criada para determinado propósito.
4.4.4 - Feição com Geometria
Feição com geometria é uma forma de representação dos fenômenos
geográficos que ocorrem na Terra. Estes fenômenos geográficos, também
denominados de feições geográficas, estão posicionados no mundo real em
um sistema de coordenadas da Terra. A representação destes fenômenos no
sistema de informação geográfica (SIG) se dará pelo “mapeamento” do seu
posicionamento no sistema de coordenadas adotado pelo SIG. A Figura 4.17
ilustra a idéia.
119
Fig. 4.17 - Uma forma de representação de feições geográficas.
FONTE : adaptada de OGC (1998C).
As feições geográficas são compostas por informações que as posicionam em
coordenadas relativas da Terra, ou relativas a algum outro sistema. A técnica
mais comum para representar o posicionamento e a forma de uma feição
geográfica é a geometria (OGC, 1998C).
Portanto, estas feições geográficas são vistas como um ponto, um polígono ou
alguma outra representação geométrica. Os SIGs fornecem tecnologia para a
representação destas geometrias no seu sistema de coordenadas.
4.4.4.1 - Geometria
Geometria é a combinação de coordenadas geométricas e um sistema de
referência. A coordenadas geométricas consistem de quatro itens:
1) Uma sequência de coordenadas (pontos), todas provenientes de um
mesmo sistema de referência.
2) Uma coleção de geometrias, todas provenientes de um mesmo sistema
de referência.
120
3) Um algoritmo de interpretação que usa estas geometrias e coordenadas
para construir uma entidade geométrica que define uma geometria no
tempo e no espaço. Uma entidade geométrica pode ser composta de
outras entidades geométricas, e uma entidade geométrica pode ser
compartilhada, como componente, por outras entidades.
4) Um sistema de referência espaço-temporal para dar à geometria uma
melhor interpretação do mundo real.
A
representação
geométrica
da
feição
geográfica
segue
critérios
e
especificações para garantir a sua manipulação por operadores topológicos
tais como: interior, adjacência, intersecção, união, subtração, disjunção, dentro
de, contido em, sobreposição, etc.. Para uma especificação em detalhes
destes critérios e operadores topológicos consultar (OGIS, 1998C).
4.4.5 - Coverage
As coverages em SIG, incluindo o caso de imagem de satélite, são metáforas
de duas ou mais dimensões de fenômenos de uma área da superfície da
Terra. Constituem a segunda forma de representação de feições geográficas.
Fundamentalmente, coverages fornecem uma visão n-dimensional, onde n é
usualmente 2 e ocasionalmente 3 ou maior, de um espaço de feições
geográficas. Esta visão deverá ser geo-espacialmente registrada com a Terra.
É útil utilizar a seguinte analogia: o domínio espacial de uma coverage é
como uma “view port” sobre
a tela de um vídeo, e existe uma função
(FUNÇÃO_C) que associa as cores de uma “viewport” aos fenômeno reais
que ela busca representar.
As coverages tem a capacidade de modelar e tornar visível os relacionamentos
espaciais entre fenômenos da Terra e a sua distribuição espacial.
121
4.4.5.1 - Propriedades
Uma coverage possui uma propriedade denominada de “Função_Coverage”
cujo valor é uma FUNCAO_C. A FUNCAO_C é uma função que tem um
domínio espacial e seu intervalo de valores é um conjunto de tuplas
homogêneas. Este intervalo pode ser simplificado para ser uma coleção de
vetores homogêneos (que são coordenadas numéricas).
Um domínio espacial pode ser qualquer geometria ou uma coleção de
geometrias. Usualmente , a geometria é acompanhada por uma referência em
um sistema espacial, e seus pontos estão associados às localizações.
Normalmente um domínio espacial inclui retângulos fechados, conjuntos de
pontos, grades, triângulos, e outras coleções de geometrias.
Uma coverage pode ter mais que uma propriedade FUNCAO_C como valor.
O intervalo de valores de uma FUNCAO_C é um conjunto de valores
usualmente representados como uma coleção de vetores.
FUNCAO_C: (Geometria no domínio espacial) -> (v1, v2, v3, ..., vn)
Por exemplo, uma FUNCAO_C pode associar a cada ponto valores de
temperatura, pressão, umidade, e velocidade do vento de noite. Neste caso,
todo ponto é mapeado para um vetor de 4 dimensões.
Uma coverage é projetada para representar uma única feição ou um conjunto
de feições. Por exemplo, uma coverage pode ter um domínio espacial que
contenha um único município ou um único país. Em um outro caso uma
coverage pode ser tratada para modelar uma única feição (país), ou como uma
coleção de feições (coleção de municípios).
A Figura 4.18 ilustra os diversos subtipos de coverage prevista no OGIS.
122
Para um maior detalhamento sobre os tipos de coverage apresentados e suas
propriedades ver OGIS (1998B).
Como decorrência deste estudo sobre a especificação OPEN GIS, concluímos
preliminarmente, que ainda existem muitos pontos a serem amadurecido e
consolidados e que qualquer interpretação desta especificação pode ser
considerada uma “aproximação”. Neste sentido elaboramos e propomos um
modelo semântico orientado por objetos que, segundo nosso entendimento,
mais se aproxima ao estágio atual da especificação OPEN GIS. A Figura 4.19
apresenta este modelo.
COVERAGE
IMAGEM
COVERAGE
GRADE
COVERAGE
SUPERFÍCIE
COVERAGE
PONTO
DISCRETO
COVERAGE
SUPERFÍCIE
POLIEDRAL
COVERAGE
LINHA
COVERAGE
AREA E
VIZINHANÇA
COVERAGE
TIN
COVERAGE
SEGMENTO
DE LINHA
COVERAGE
GEOMETRICA
OUTRAS
COVERAGE
Fig. 4.18 - Subtipos de Coverage.
FONTE : adaptada de OGC (1998B).
123
COLEÇÃO DE FEIÇÕES
TIPO DE FEIÇÃO GEOGRÁFICA
COVERAGE
1
FEIÇÃO COM GEOMETRIA
C_FUNCTION
ATRIBUTOS
IMAGEM
PONTO
LINHA
POLÍGONO
COVERAGE
GRADE
OUTRA GEOMETRIA
PRIMITIVA
COVERAGE
SUPERFÍCIE
COVERAGE
PONTO
DISCRETO
COVERAGE
SUPERFÍCIE
POLIEDRAL
COVERAGE
LINHA
COVERAGE
ÁREA E
VIZINHANÇA
COVERAGE
TIN
COVERAGE
SEGMENTO
DE LINHA
COVERAGE
OUTRAS
COVERAGE
GEOMETRIA
Fig. 4.19 - Modelo semântico que se aproxima da especificação OPEN GIS.
4.5 - Comparação entre os SIGs e o padrão OGIS
Este item tem a pretensão de realizar uma comparação entre os três SIGs
apresentados, tomando como referência dois conceitos do OGIS: feição com
geometria e coverage. Trata-se de um desenvolvimento onde será buscado
mostrar até onde cada um destes sistemas aderem a esses dois conceitos.
4.5.1 - MGE e OGIS
4.5.1.1- Feição com Geometria
O conceito de feição geográfica é apresentada pelo MGE como sendo a
representação dos fenômenos geográficos do mundo real e possui
informações descritivas no banco de dados. A representação geométrica de
cada feição é materializada em um mapa. Cada feição com geometria possui
um identificador e é classificada em uma classe de feição que compõe uma
categoria. A definição de que feição com geometria pode ser composta por
outras feições com geometria pode ser contemplada por este item através do
124
mecanismo existente entre categoria de feições que podem ser compostas por
classes de feições.
4.5.1.2 - Coverage
O MGE não captura a visão semântica do modelo OGIS que considera as
diferentes especialização do conceito coverage. Alguns subtipos de coverage
no MGE são tratados de forma independente por módulos específicos como é
o caso de grade irregular triangular e grade regular. Neste caso a aderência ao
modelo OGIS é parcial.
4.5.2 - Arc/Info e OGIS
4.5.2.1 - Feição com Geometria
O modelo de dados vetorial é responsável por representar as feições
geográficas através do modelo geo-relacional onde a parte gráfica é
especializada pelas geometrias ponto, linhas e polígonos, e a parte descritiva é
representada por tabelas de atributos no SGBD relacional. Apesar da parte
gráfica possuir uma representação geométrica, ela somente pode ser
materializada no sistema através de uma estrutura denominada coverage. Não
é possível conceber feição com representação geométrica sem a existência de
coverage. Portanto concluímos que o Arc/Iinfo adere parcialmente ao conceito
de feição com geometria.
4.5.2.2 - Coverage
Coverage, no Arc/Info, é definido como o método primário para representar o
modelo de dados vetorial, assim como “GRID” é o método para representar o
modelo de dados matricial, e o “TIN” é o método para representar o modelo de
dados de rede irregular triangular. Devido à existência de um sub-tipo de
125
coverage denominado coverage geométrica, deduzimos que este sub-tipo é o
mais próximo correspondente à estrutura coverage do ARC/INFO.
Já o modelo de dados matricial e o modelo de dados de rede irregular
triangular são contemplados no OGIS como sub-tipos de coverage: coverage
grade e coverage TIN respectivamente. No Arc/Info estes modelos possuem
representações específicas, no caso: “GRID” e “TIN”. Portanto para este item a
aderência é parcial.
4.5.3 - SPRING e OGIS
4.5.3.1 - Feição com Geometria
No SPRING, as feições geográficas do mundo real são modeladas por dois
grandes tipos de dados: geo-objetos e geo-campos. Os geo-objetos
representam feições geográficas com identidades únicas e possuem uma
descrição no banco de dados. Além disto eles são representados por uma ou
mais geometrias no sistema, como é o caso de uma representação de um
mesmo geo-objeto em duas escala diferentes: em uma ela pode ser um ponto
em outra pode ser um polígono.
Portanto a definição de geo-objetos adere à definição de feição com geometria
do OGIS. Ressalve-se porém, que a da feição com geometria que pode ser
composta por outras feições com geometria, conceito este não encontrado no
referido sistema
126
4.5.3.2 - Coverage
A definição de geo-campos implementada pelo SPRING representa a
distribuição espacial das feições geográficas no mundo real. Dentro deste
contexto, o geo-campo e suas especialidades contemplam a definição de
coverage do OGIS.
A Tabela 4.1 mostra um resumo das comparações realizadas anteriormente
tendo como referência o conceito OGIS para feição com geometria e coverage.
4.5.3.3 - Uma Breve Conclusão
Sob o ponto de vista semântico nenhum dos sistemas apresentados adere por
completo ao padrão OGIS. Pode-se citar, para exemplificar esta afirmação, os
seguintes fatos:
1) No MGE, a noção de especialização de tipos de feições, representada
por categoria e classes de feições, não é contemplada pelo OGIS de forma
explícita e direta.
2) No Arc/Info existe a noção de coverage e não contempla a idéia de
feição com geometria como entidade independente da coverage. A noção
de coverage no Arc/Info pode ser mapeado parcialmente para o conceito
de coverage geométrica no OGIS.
3) A separação explícita entre feição geográfica e sua geometria, presente
no SPRING, não é disponível diretamente no OGIS.
Como a especificação do padrão OGIS é um processo em evolução, isto é,
não se esgotou até o momento destas análises, é possível que em versão mais
avançadas no futuro, tais fatos poderão ser contemplados de forma explícita.
127
TABELA 4.1 - QUADRO COMPARATIVO ENTRE OS TRÊS SIGS E OS
CONCEITOS FEIÇÃO COM GEOMETRIA E COVERAGE DO OGIS
SIGs
aderência
Feição c/ Geometria
Coverage
LIMITADA(*)
PARCIAL
As feições com
geometria somente
se materializam com
a existência das
Coverages.
Não há o conceito
uma feição com
geometria que pode
ser composta por
outras feições com
geometria
O modelo de dados vetorial
adere ao sub-tipo Coverage
Geométrica, o modelo de
dados de Grade Regular
adere ao sub-tipo de Grade
Coverage, e o modelo de
dados de grade irregulat
triangular adere ao sub-tipo
TIN coverage.
PARCIAL
LIMITADA
Não há o conceito
uma feição com
geometria que pode
ser composta por
outras feições com
geometria.
O modelo de dados matricial
e de grade triangular
irregular possui método de
representação específico.
Existem os módulos
específicos para a
representação de feições
geográfica distribuídas
espacialmente.
PARCIAL
PARCIAL
Geo-objetos e suas
especialidades.
Não tem o conceito
uma feição com
geometria que pode
ser composta por
outras feições com
geometria
Geo-Campos e suas
especialidades.
Porém não suporta a noção
de vetor de valores para
cada ponto.
Arc/Info
detalhe
aderência
MGE
detalhe
Aderência
SPRING
detalhe
(*) As classes de avaliação adotadas são: TOTAL, PARCIAL e LIMITADA
128
CAPÍTULO 5
INTEROPERABILIDADE SEMÂNTICA ENTRE SIGs
5.1 - Introdução
Nos capítulos anteriores discutimos a fundamentação teórica dos Sistemas de
Informação Geográfica (SIGs), apresentamos os modelos conceituais de
diferentes sistemas, e procuramos relacionar estes sistemas no contexto do
padrão OPEN GIS.
Neste capítulo, abordaremos o problema da interoperabilidade semântica entre
sistemas, e apresentaremos o desenvolvimento de uma ferramenta prática
para apoiar a modelagem de projetos na área de geoprocessamento e
subsidiar a conversão de conceitual deste modelo entre sistemas diferentes.
Trata-se do Tradutor de Modelos Semânticos de Geoinfomação - GeoTMS, um
protótipo8 de sistema que provê ao usuário recursos gráficos para auxiliar a
construção de modelos conceituais compatíveis com as regras conceituais de
um determinado SIG. Estas regras conceituais estão embutidas no sistema,
que certifica se elas estão sendo cumpridas pelo usuário.
Outra funcionalidade importante do GeoTMS é a capacidade de, a qualquer
momento, converter o modelo conceitual de um determinado SIG para o
padrão OPEN GIS, e para qualquer outro SIG de preferência do usuário.
___________________________
8
A prototipação de software deve ser desenvolvida rapidamente, de forma que
o cliente possa avaliar o protótipo e recomendar mudanças” (Pressman, 1995).
Para maiores detalhes pode-se consultar este autor.
129
A princípio, o GeoTMS implementará as regras conceituais dos três SIGs
estudados no capítulo anterior (MGE, ARC/INFO e SPRING), e a especificação
padrão do OPEN GIS.
5.2 - Metodologia de Desenvolvimento do GeoTMS
O processo de construção da ferramenta computacional GeoTMS envolve as
seguintes fases e técnicas de engenharia de software :
A primeira fase é denominada “Especificação Informal do Sistema” onde são
apresentados o propósito do sistema, uma descrição informal do sistema, um
diagrama de contexto e por fim, um resumo dos requisitos essenciais. Esta
fase tem por objetivo, além da identificação e explicitação desses requisitos do
sistema, a definição do escopo de trabalho.
Na segunda fase é elaborada a “Especificação Formal do Sistema”. Nesta
especificação é utilizada a metodologia de Rumbaugh (1994) apresentada no
capítulo 3. Esta metodologia fundamenta-se na elaboração de modelos de três
visões do mundo real para construção do sistema. São elas : visão funcional,
dinâmica e estática (ou de objetos).
Para a visão funcional é utilizado o diagrama de fluxo de dados (DFD) baseado
na notação de Yourdon (1990). Já para a visão dinâmica é elaborado o
diagrama de transição de estados (DTE) segundo a notação de de Rumbaugh
(1994). Para a visão estática ou de
objetos, é utilizada a técnica de
modelagem de objetos (TMO) de Rumbaugh (1994).
A terceira fase é o projeto do sistema, que envolve o detalhamento dos
modelos desenvolvidos na descrição formal, visando a implementação.
A quarta fase é a implementação do sistema. Como linguagem de
programação será utilizado o Visual Basic (versão 4.0), e como ambiente de
130
persistência de dados será utilizando o banco de dados relacional Access
(versão 97).
5.3 - Especificação Informal do Sistema
5.3.1 - Propósito do GeoTMS
O propósito do GeoTMS é oferecer um instrumento computacional de auxílio
na
elaboração
de
modelos
conceituais
para
projetos
na
área
de
geoprocessamento com independência do SIG adotado, disponibilizando
ferramentas de consistência do modelo, conversão do modelo entre SIGs e
conversão para o padrão OPEN GIS.
5.3.2 - Modelo Descritivo do GeoTMS
O sistema é baseado em um ambiente gráfico e amigável. O usuário do
sistema
pode
escolher
o
SIG
que
melhor
conhece
para
modelar
conceitualmente o seu problema.
O sistema fornece, em forma de objetos gráficos, as diversas classes de dados
comuns ao SIG adotado, assim como os tipos de relacionamentos que
poderão existir entre estas classes de dados.
Os objetos gráficos possuem propriedades que devem ser preenchidas pelo
usuário de forma a torná-las mais representativas da classe de dados
modelada.
Desta forma, através de movimentos simples com o “mouse” o usuário
seleciona os objetos gráficos que representam as classes de dados do SIG
selecionado, e monta um diagrama conceitual.
131
É disponibilizada ao usuário uma ferramenta de verificação de consistência
que é capaz de indicar os pontos do diagrama discordantes com as regras
conceituais do SIG adotado.
O sistema é capaz, a qualquer momento, de converter o modelo conceitual
construído em um determinado SIG para um outro SIG, e para o modelo
padrão OGIS.
5.3.3 - Diagrama de Contexto do Sistema
O diagrama de contexto é uma visão de alto nível do sistema, na qual procurase identificar as entidades externas e as principais funcionalidades que o
sistema deverá atender através de “perguntas” que estas entidades externas
queiram ver respondidas pelo sistema. A Figura 5.1 mostra o diagrama.
5.3.4 - Resumo dos Requisitos do Sistema
Esta seção descreve um resumo dos requisitos que o sistema deverá atender.
Este resumo é decorrente da análise do modelo descritivo do sistema e do
diagrama de contexto. A tabela 5.1 mostra este resumo.
132
USUÁRIO
USUÁRIO
Quero modelar meu
projeto em MGE
Quero modelar meu
USUÁRIO projeto em ARC/INFO
Com fica meu projeto em
MGE no ARC/INFO e SPRING ?
Com fica meu projeto em
USUÁRIO
ARC/INFO no MGE e SPRING ?
GeoTMS
Quero modelar meu
projeto em SPRING
Com fica meu projeto em
SPRING no MGE e ARC/INFO ?
USUÁRIO
USUÁRIO
Como fica meu projeto no
Padrão OPEN GIS ?
Meu projeto está rigidamente dentro
das regras conceituais do SIG
que estou modelando?
USUÁRIO
USUÁRIO
Fig. 5.1 - Diagrama de contexto do sistema.
TABELA. 5.1 - RESUMO DOS REQUISITOS A SEREM ATENDIDOS PELO
GEOTMS
ITEM
A
B
C
D
E
F
G
H
REQUISITO
Encapsular as regras conceituas do SIG MGE.
Encapsular as regras conceituas do SIG ARC/INFO.
Encapsular as regras conceituas do SIG SPRING.
Encapsular as regras conceituas do padrão OPENGIS.
Prover um ambiente gráfico para modelagem conceitual em qualquer
um dos SIGs adotados.
Fornecer um mecanismo de conversão dos modelos conceituais para
o modelo padrão OPENGIS.
Fornecer um mecanismo de conversão entre os modelos conceituais
dos SIGs.
Prover um mecanismo de verificação de consistência com as regras
conceituais do sistema adotado.
133
5.4 - Especificação Formal do Sistema
A descrição formal envolve a elaboração dos modelos das três visões do
mundo real: visão funcional, dinâmica e estática. Segue a especificação de
cada uma delas.
5.4.1 - Visão Funcional
A visão funcional é especificação formal do sistema sob o enfoque funcional.
Nela são definidos sete processos essenciais responsáveis pela transformação
dos dados, que por sua vez estão representados em quatro depósitos de
dados. A entidade externa, denominada “usuário”, é responsável por estimular
o sistema a atender suas necessidades.
Segue uma breve explicação de cada processo representado pelo diagrama da
Figura 5.2. Acompanhando esta explicação está sendo referenciado o item de
requisito a que o processo está atendendo. Desta forma, poderemos garantir
que todos os requisitos estabelecidos na primeira fase sejam cumpridos.
• Selecionar SIG. Trata-se da possibilidade que o sistema oferece ao
usuário em selecionar um dos três SIGs (MGE, ARC/INFO, SPRING) para
construção do seu modelo conceitual.
• Apresentar um ambiente de trabalho em determinado SIG. Para o SIG
escolhido no processo anterior, o sistema monta um ambiente gráfico de
trabalho adequado para a construção do modelo conceitual do SIG
selecionado. Atende ao requisito E.
134
OBJETOS GRÁFICO
USUÁRIO
SOLICITA
OBJETOS
GRÁFICOS PARA
MODELAGEM
USUÁRIO
SOLICITA AMBIENTE
TRABALHO EM
DETERMINADO
SIG
1
SELECIONAR
SIG
SIG
SELECIONADO
2
APRESENTAR
UM AMBIENTE DE
TRABALHO EM
DETERMINADO
SIG
3
MONTAR
MODELO
CONCEITUAL
SIG
SELECIONADO,
AMBIENTE
PRONTO
REGRAS CONCEITUAIS
PROBLEMAS
REALÇADOS
PARA AJUSTE
5
APONTAR
INCONSISTÊNCIAS
PROBLEMAS
ENCONTRADOS
MODELO
PRONTO PARA
CHECAGEM
4
CHECAR
CONSISTÊNCIA
DO MODELO
CONCEITUAL
MODELOS
6
TRADUZIR
PARA O
MODELO OGIS
MODELO
CONCEITUAL
SEM
PROBLEMAS
TABELA DE TRADUÇÃO
7
TRADUZIR
PARA QUALQUER
SIG
Fig. 5.2 - Visão Funcional: Diagrama de Fluxo de Dados do Sistema GeoTMS.
• Montar Modelo Conceitual. São disponibilizados para o usuário dois
grupos de elementos gráficos de trabalho para a montagem do modelo
conceitual: Caixas de classes abstratas de dados e tipos de ligações entre
estas classes. Com estes elementos, e o auxílio de uma “ajuda on line” o
usuário, através de “cliques do mouse”, vai construindo o diagrama que
representa o modelo conceitual. Caixas de classes e ligações apresentam
propriedades padrão, e devem ser convenientemente preenchidas pelo
usuário para que haja uma melhor adequação à classe de dados ou ao tipo
de ligação modelada. Atende ao requisito E.
• Verificar Consistência do Modelo Conceitual. À qualquer momento o
usuário tem a possibilidade de checar a consistência do modelo conceitual
135
construído por ele com a regra conceitual do SIG selecionado. Este
processo é uma funcionalidade do próprio sistema. Atende ao requisito H.
• Apontar as Inconsistências. Caso ocorram como resultado do processo
anterior, problemas de inconsistência, o sistema as aponta graficamente.
Cabe ao usuário corrigir estas inconsistências e passar pelo processo 4
novamente. Atende ao requisito H.
• Converter para o Modelo OGIS. Esta opção é disponibilizada ao usuário
somente após o processo de verificação de consistência obter sucesso.
Através deste processo, o modelo construído em determinado SIG é
traduzido para o padrão OGIS e apresentado graficamente. Este processo
se apoia na definição das tabelas de conversão que serão apresentadas
no tópico de visão estática do sistema. Atende ao requisito F.
• Converter para qualquer SIG. Como no processo anterior, esta opção é
disponibilizada ao usuário somente após o processo de Verificação de
consistência obter sucesso. Através deste processo, o modelo conceitual
elaborado pelo usuário em um determinado SIG, é traduzido para um outro
SIG que ele mesmo selecionou. Por exemplo, caso o usuário construa o
modelo conceitual em MGE, ele poderá ver uma tradução deste modelo
em ARC/INFO ou SPRING. Este processo se apoiará na definição das
tabelas de conversão que serão apresentadas no tópico de visão estática
do sistema. Atende ao requisito G.
Os demais requisitos A, B, C e D serão atendidos diretamente pela
especificação da visão estática no item de regras conceituais no próximo
tópico.
136
5.4.2 - Visão Estática
A visão estática busca modelar as estruturas estáticas contidas nos depósitos
de dados apresentados na visão funcional. Neste caso, esses armazenadores
são: Objetos Gráficos, Regras Conceituais, Tabelas de Conversão e Modelos.
A seguir o modelo de cada uma delas é apresentado.
5.4.2.1 - Objetos Gráficos
Os objetos gráficos representam uma classe abstrata de tipos de dados que
são especializados nas regras conceituais. O objetivo dos objetos gráficos é
disponibilizar ao usuário, em forma de ferramentas gráficas, todas as classes
de dados dos diversos níveis semânticos que definem o modelo conceitual
padrão de cada SIG. Isto é possível pela especialização das regras conceituais
para cada SIG, conforme será apresentado no próximo item. A fig. 5.3 ilustra a
classe abstrata “Objetos Gráficos”.
OBJETOS GRÁFICOS
REGRAS CONCEITUAIS
Fig. 5.3 - Visão Estática: Modelagem dos Objetos Gráficos.
137
5.4.2.2 - Regras Conceituais
As regras conceituais representam a semântica de cada SIG. Através da
especialização do super-tipo abstrato Regra Conceitual, tem-se toda a
definição semântica de cada SIG estudado no capítulo anterior, além do
padrão OGIS. A Figura 5.4 ilustra a especialização das regras conceituais.
REGRAS CONCEITUAIS
OGIS
MGE
ARC/INFO
SPRING
Fig. 5.4 - Visão Estática: Modelagem dos Tipos de Regras Conceituais.
A seguir serão apresentados, como especializações dos tipos de regras
conceituais, o modelo conceitual padrão de cada SIG e do OGIS.
5.4.2.2.1 - O padrão OGIS
A definição conceitual do modelo OGIS é decorrente dos estudos realizados no
capítulo anterior. A Figura 5.5 mostra o modelo padrão identificado até o
momento na documentação de especificação do consórcio OPEN GIS.
138
REGRAS CONCEITUAIS
OGIS
COLEÇÃO DE FEIÇÕES
TIPO DE FEIÇÃO GEOGRÁFICA
COVERAGE
1
FEIÇÃO COM GEOMETRIA
C_FUNCTION
ATRIBUTOS
IMAGEM
PONTO
LINHA
POLÍGONO
COVERAGE
GRADE
OUTRA GEOMETRIA
PRIMITIVA
COVERAGE
SUPERFÍCIE
COVERAGE
PONTO
DISCRETO
COVERAGE
SUPERFÍCIE
POLIEDRAL
COVERAGE
LINHA
COVERAGE
ÁREA E
VIZINHANÇA
COVERAGE
TIN
COVERAGE
SEGMENTO
DE LINHA
COVERAGE
OUTRAS
COVERAGE
GEOMETRIA
Fig. 5.5 - Visão Estática: Modelagem das Regras Conceituais OGIS.
Este item atende o requisito D da especificação informal do sistema.
5.4.2.2.2 - MGE
O modelo conceitual padrão que define o SIG MGE é apresentado pela Figura
5.6. Este modelo é resultado de investigação realizada no Capítulo 4 tópico
4.1, onde encontra-se uma descrição da semântica modelada.
Este item atende o requisito A da especificação informal.
5.4.2.2.3 - ARC/INFO
As regras conceituais expostas pela Figura 5.7 definem o modelo padrão do
SIG ARC/INFO. Isto é resultado de um processo de investigação realizado no
Capítulo 4 tópico 4.2, onde poderá ser encontrada uma explicação detalhada
da semântica modelada.
139
Este item atende o requisito B da especificação informal do sistema.
REGRAS CONCEITUAIS
MGE
GRADE
REGULAR
PROJETO
GRADE
IRREGULAR
TRIANGULAR
IMAGENS
INDICE
CATEGORIA
CLASSES DE
FEIÇÕES
ELEMENTO
GRÁFICO
PONTO
LINHA
FRONTEIRA
DE ÁREA
TABELA DO
USUÁRIO
IDENTIFICADOR
DE ÁREA
INDEFINIDO
FORMA
COMPLEXA
Fig. 5.6 - Visão Estática: Modelagem das Regras Conceituais MGE.
140
REGRAS CONCEITUAIS
ARC/INFO
MODELO DE DADOS
VETORIAL
MODELO DE DADOS
DE GRADE IRREGULAR
TRIANGULAR
COVERAGE
TIN
MODELO DE DADOS
DE GRADE REGULAR
GRID
PONTO
LINHA
LATTICE
IMAGEM
POLÍGONO
TABELA DE
VALORES
TABELA DE
ATRIBUTOS
TABELA DE
ATRIBUTOS
TABELA DE
ATRIBUTOS
Fig. 5.7 - Visão Estática: Modelagem das Regras Conceituais ARC/INFO.
5.4.2.2.4 - SPRING
Assim como para os outros SIG, o modelo padrão do SPRING foi resultado de
investigação detalhada consolidada no Capítulo 4 tópico 4.3. A Figura 5.8
mostra a semântica modelada para este sistema.
Este item atende o requisito C da especificação informal do sistema.
141
REGRAS
CONCEITUAIS
SPRING
BANCO DE
DADOS GEOGRÁFICOS
1
PROJETO
é instanciado por
CATEGORIA
MAPA DE
OBJETOS
CAMPOS
TEMÁTICO
NUMÉRICO
PLANO DE
INFORMAÇÃO
IMAGENS
CADASTRAL
é representado por
REDE
OBJETO
NÃO ESPACIAL
TABELA DE
ATRIBUTOS
Fig. 5.8 - Visão Estática: Modelagem das Regras Conceituais SPRING.
5.4.2.3 - Tabelas de Conversão
As tabelas de conversão definem como será traduzido o modelo conceitual
criado pelo usuário, para o padrão OGIS, ou para qualquer outro SIG. A seguir
são apresentados as seguintes tabelas de conversão:
• MGE para OGIS;
• ARC/INFO para OGIS;
• SPRING para OGIS;
142
• MGE para SPRING e vice-versa;
• MGE para ARC/INFO e vice-versa e
• ARC/INFO para SPRING e vice-versa.
A tabela de conversão é composta por quatro colunas. A primeira coluna
representa o item de tradução. Na segunda coluna estão representadas as
classes de dados do sistema origem a ser traduzido. A terceira coluna
representa as classes correspondentes do sistema destino. Já na quarta
coluna é representada a referência ao modelo conceitual global que define se
a classe traduzida é “campo” ou “objeto”. Está referência é realizada sempre
que possível. A Tabela 5.2 ilustra a idéia.
TABELA 5.2 - TABELA DE CONVERSÃO
ITEM
SISTEMA ORIGEM
SISTEMA DESTINO
GLOBAL
1
2
...
CLASSE A
CLASSE B
...
CLASSE 3
CLASSE 1
...
Campo
Objeto
...
Para as traduções onde serão representadas o caminho de retorno, ou seja, a
tradução inversa, deixa de ter sentido as denominações “sistema origem” e
“sistema destino”, pois em uma coluna
estarão representadas as classes
correspondentes do outro sistema, e vice-versa.
Após a apresentação da tabela de conversão serão expostas as justificativas
para a tradução de cada item da tabela.
5.4.2.3.1 - Considerações Iniciais
Com relação à tradução para o modelo OGIS seguem algumas considerações.
Este modelo procura representar, organizar e simplificar a realidade geográfica
através de classes abstratas de dados. Já os modelos conceituais dos SIGs
143
representam esta mesma realidade com um nível maior de detalhes,
decorrentes da maneira específica com que estes sistemas de mercado
enxergam as particularidades do mundo real. Isto implica em uma natural
convergência de classes de dados dos SIGs, para uma mesma classe de
dados destino no modelo OGIS.
Em outros casos não existe uma correspondência direta entre classes
específicas dos SIGs e classes do OGIS, uma vez que o OGIS não tem o
compromisso de representar particularidades dos SIGs, e procura generalizar
conceitos que todos os sistemas deveriam seguir.
5.4.2.3.2 - MGE para OGIS
A Tabela 5.3 mostra a tabela de conversão do MGE para o modelo padrão
OGIS. A seguir serão apresentadas justificativas e considerações sobre esta
tradução :
• Justificativa do item 1: A tradução entre CATEGORIA e COLEÇÃO DE
FEIÇÕES foi proposta uma vez que, em ambas as classes, busca-se
representar um agrupamento de feições geográficas. Vale lembrar que a
definição de COLEÇÃO DE FEIÇÃO é assunto em discussão pelo
consórcio OPEN GIS (para maiores detalhes recomendamos (OGC,
1998A)). Portanto, tomamos como verdade COLEÇÃO DE FEIÇÕES como
agrupamento de feição geográfica para representar um fenômeno
geográfico. Porém, essas feições geográficas não necessariamente
possuem a mesma geometria e atributos descritivos. Por exemplo,
vejamos o caso de “hidrografia”. Trata-se de uma CATEGORIA ou
COLEÇÃO DE FEIÇÕES que agrupam classes de feições tais como “rio
permanente” (geometria linha), “terreno sujeito a inundação” (geometria
polígono), “ilhas” (geometria polígono), etc..
144
TABELA 5.3 - TABELA DE CONVERSÃO DE MGE PARA OGIS
ITEM
1
2
3
4
5
6
7
8
9
10
11
12
MGE
OGIS
CATEGORIA
CLASSE DE FEIÇÕES
PONTO
IDENTIFICADOR DE ÁREA
LINHA
FRONTEIRA DE ÁREA
FORMA COMPLEXA
GRADE REGULAR
GRADE TRIANGULAR
IMAGENS
ELEMENTO GRÁFICO
TABELA DO USUÁRIO
PROJETO
INDICE
GLOBAL
COLEÇÃO DE FEIÇÕES
TIPO DE FEIÇÃO GEOGRÁFICA
PONTO
CAMPOS / OBJETOS
CAMPOS / OBJETOS
CAMPOS / OBJETOS
LINHA
POLÍGONO
CAMPOS / OBJETOS
CAMPOS / OBJETOS
COVERAGE GRADE
COVERAGE TIN
COVERAGE IMAGEM
GEOMETRIA
ATRIBUTOS / C_FUNCTION
EM DEFINIÇÃO
EM DEFINIÇÃO
CAMPOS
CAMPOS
CAMPOS
CAMPOS / OBJETOS
CAMPOS / OBJETOS
-
• Justificativa do item 2: A correspondência entre CLASSE DE FEIÇÃO e
TIPO
DE
FEIÇÃO
correspondência
GEOGRÁFICA
existente
entre
é
suas
em
parte
classes
justificada
superiores,
e
pela
pela
semelhança de definição. Neste caso, as classes, em ambos os modelos,
são semelhantes na representação geométrica e nos atributos descritivos.
Pelo exemplo utilizado na justificativa anterior, a CLASSE DE FEIÇÃO ou
TIPO DE FEIÇÃO GEOGRÁFICA ‘rio permanente’ representa todas as
ocorrências de rio permanente cuja geometria é linha, e os atributos
descritivos podem ser nome e extensão.
A tradução justificada pelos itens 1 e 2 é válida para a parte do modelo
OGIS que representa os fenômenos geográficos através de geometria. Os
fenômenos cuja representação utiliza a terminologia COVERAGE no OGIS,
são representados pelo MGE através de pacotes específicos que serão
abordados na justificativas dos itens 6, 7 e 8.
• Justificativa dos itens 3, 4 e 5: A justificativa para a tradução destes
itens baseia-se na semelhança de geometria. Para as classes do Item 3, a
representação geométrica é ponto. Já as do item 4, como o próprio nome
das classes sugere, a representação geométrica é linha. No item 5, a
representação geométrica é polígono.
145
• Justificativa do item 6, 7 e 8: Essas traduções tratam a representação
de fenômenos geográficos distribuídos espacialmente, como sugere a
definição de Campos exposta no capítulo 2 tópico 2.2.3. O MGE possui
produtos específicos para tratar estas classes de dados. GRADE
REGULAR, GRADE IRREGULAR TRIANGULAR e IMAGENS são tratados
no MGE de forma independente, e possuem correspondência semântica
no modelo OGIS com COVERAGE GRADE, COVERAGE TIN e
COVERAGE IMAGEM respectivamente. Isto é justificado pela semelhança
de definição na representação de fenômenos geográficos.
• Justificativa do item 9: O elemento gráfico define a forma geométrica
da feição geográfica no MGE. Isto é idêntico ao conceito de geometria do
OGIS.
• Justificativa do item 10: A TABELA DO USUÁRIO define os atributos
alfanumérico que descrevem uma feição geográfica. Esta tabela, no MGE,
poderá estar associada tanto a feição do tipo objeto, quanto a campo.
Portanto sua tradução para o OGIS poderá ser para ATRIBUTOS ou para
C_FUNCTION.
• Justificativa dos itens 11 e 12: Estes conceitos presentes no MGE
encontram-se em processo de definição no OGIS sendo, portanto,
imprudente realizar qualquer tipo de conclusão.
146
5.4.2.3.3 - ARC/INFO para OGIS
A Tabela 5.4 mostra a conversão do ARC/INFO para o modelo OGIS.
TABELA 5.4 - TABELA DE CONVERSÃO DE ARC/INFO PARA OGIS
ITEM
ARC/INFO
1
COVERAGE
2
3
4
5
6
7
TABELA DE ATRIBUTOS
PONTO
LINHA
POLÍGONO
TIN
GRID
LATTICE
IMAGEM
TABELA DE VALORES
8
9
OGIS
GLOBAL
COLEÇÃO DE FEIÇÕES
GEOGRÁFICAS
ATRIBUTOS
PONTO
LINHA
POLÍGONO
COVERAGE TIN
COVERAGE GRADE
CAMPOS / OBJETOS
CAMPOS / OBJETOS
CAMPOS / OBJETOS
CAMPOS / OBJETOS
CAMPOS / OBJETOS
CAMPOS
CAMPOS
CAMPOS
CAMPOS
CAMPOS
COVERAGE IMAGEM
C_FUNCTION
A seguir serão apresentadas justificativas e considerações sobre esta
tradução:
• Justificativa do item 1: A classe COVERAGE do ARC/INFO materializa
um conjunto de feições geográficas de uma mesma geometria dentre as
possíveis: pontos, linhas ou polígonos. Portanto, como a classe OGIS
COLEÇÃO
DE
FEIÇÕES
GEOGRÁFICAS
é
definida
como
uma
composição de feições geográficas de um ou mais tipos de feição
geográfica, decidimos optar por esta correspondência com a seguinte
restrição: neste caso a COLEÇÃO DE FEIÇÕES OGIS deve ser composta
por feições de um mesmo tipo.
• Justificativa do item 2: Tanto a classe TABELA DE ATRIBUTOS do
ARC/INFO, quanto a classe ATRIBUTOS do OGIS, são responsáveis por
representar os atributos das feições geográficas. Porém, no OGIS esses
atributos incluem a parte alfanumérica e a geometria, e portanto, para a
devida correspondência faremos a seguinte restrição: para esta tradução
somente a parte alfanumérica é valida.
147
• Justificativa do item 3, 4 e 5: As classes PONTO, LINHA e POLÍGONO
do ARC/INFO têm tradução direta para as classes PONTO, LINHA
e
POLÍGONO respectivamente, no modelo OGIS. Isto é justificado como
decorrência da semelhança geométrica entre as classes.
• Justificativa do item 6: A classe de dados TIN, sub-classe de MODELO
DE DADOS DE GRADE IRREGULAR TRIANGULAR, é traduzida para o
modelo OGIS como a classe COVERAGE TIN. Isto é justificado pela
semelhança de definição entre estas classes.
• Justificativa do item 7: As classes GRID, LATICCE, e TABELA DE
VALORES são traduzidas para a classe COVERAGE GRADE em OGIS.
Isto é justificado pela semelhança de definição existente entre estas
classes.
• Justificativa do item 8: A classe IMAGENS do ARC/INFO é traduzida
para a COVERAGE IMAGENS, pois elas tratam o mesmo tipo de dados:
IMAGENS.
• Justificativa do item 9: A classe TABELA DE VALORES armazena os
valores que estão associados a cada célula de um GRID, ou seja define a
representação de uma feição distribuída espacialmente. Esta atribuição da
TABELA DE VALORES é semelhante a da C_FUNCTION do OGIS,
portanto justifica-se a correspondência.
5.4.2.3.4 - SPRING para OGIS
A Tabela 5.5 mostra a tabela de conversão do SPRING para o modelo OGIS.
A seguir serão apresentadas justificativas e considerações sobre esta
tradução:
148
TABELA 5.5 - TABELA DE CONVERSÃO DO SPRING PARA OGIS
ITEM
SPRING
1
2
3
4
PLANO DE INFORMAÇÃO
CATEGORIA
CAMPO
OBJETOS com
representação no MAPA DE
OBJETOS
TEMÁTICO
NUMÉRICO
5
6
7
8
9
10
11
12
13
OGIS
GLOBAL
COLEÇÃO DE FEIÇÕES
TIPO DE FEIÇÃO GEOGRÁFICA
COVERAGE
FEIÇÃO C/ GEOMETRIA
CAMPOS / OBJETOS
CAMPOS / OBJETOS
CAMPOS
OBJETOS
COVERAGE GEOMÉTRICA
COVERAGE GRADE
COVERAGE TIN
COVERAGE IMAGEM
FEIÇÃO C/ GEOMETRIA
FEIÇÃO C/ GEOMETRIA
ATRIBUTOS
EM DEFINIÇÃO
IMAGEM
CADASTRAL
REDE
TABELA DE ATRIBUTOS
BANCO DE DADOS
GEOGRÁFICO
PROJETO
NÃO ESPACIAL
CAMPOS
CAMPOS
CAMPOS
OBJETOS
OBJETOS
OBJETOS
-
EM DEFINIÇÃO
EM DEFINIÇÃO
• Justificativa do item 1:
-
Na classe PLANO DE INFORMAÇÃO são
representadas uma ou mais feições geográficas. A noção de coleção de
feições
no
SPRING
é
um
agrupamento
de
feições
geográficas
materializadas em um PLANO DE INFORMÇÃO. Esta definição se
aproxima da definição de classe COLEÇÃO DE FEIÇÕES no OGIS,
conforme exposta na justificativa do item 1 do tópico 5.4.2.3.2. Portanto, a
correspondência entre PLANO DE INFORMAÇÃO e COLECÃO DE
FEIÇÕES é justificada pela proximidade de definição.
• Justificativa do item 2: A classe CATEGORIA no SPRING define uma
das classes de feições geográficas a serem tratadas. Dentro destas
possíveis classes encontram-se: Temático, Objetos, Imagem, Numérico,
Não espacial, Cadastral e Rede. Nesta tradução do SPRING para o OGIS,
aproximaremos
a
correspondência
de
CATEGORIA
para
FEIÇÃO
GEOGRÁFICA no sentido de representar classes de feição geográfica que
podem ser divididas nas classes abrangidas pelo SPRING.
• Justificativa do item 3: A classe CAMPO do SPRING é definida para
representar fenômenos geográficos distribuídos espacialmente em uma
área geográfica. Esta definição coincide com a definição da classe
149
COVERAGE do modelo OGIS. Além disto, elas permitem a especialização
em sub-tipos
para representar de forma mais fiel particularidades de
fenômenos geográficos. Como exemplo destes sub-tipos podemos citar as
classes traduzidas nos itens 5, 6 e 7 deste tópico.
• Justificativa do item 4: A classe de OBJETOS com representação no
MAPA DE OBJETOS é responsável pela representação de fenômenos
geográficos discretos tais como lotes, fazendas, rede de esgoto, etc.. A
representação de cada instância destas classes inclui a parte geométrica e
os atributos alfanuméricos. Esta definição está bem próxima da definição
de FEIÇÃO COM GEOMETRIA do OGIS, onde os fenômenos discretos
são representados por feições que possuem como atributos a parte
geométrica e a parte alfanumérica. Portanto, esta correspondência é
justificada.
• Justificativa do item 5: A classe TEMÁTICA do SPRING é uma
especialização da classe CAMPO. Esta classe TEMÁTICA busca
representar fenômenos distribuídos espacialmente através de polígonos
representativos da grandeza geográfica que se deseja mapear. Cada
grandeza é representada por um sub-tema, como por exemplo vegetação
secundária, mata ciliar, etc. A sub-classe de COVERAGE que possui a
mesma proximidade com esta definição é a COVERAGE GEOMETRICA.
Da mesma forma que a TEMATICA, esta classe busca representar
grandezas distribuídas espacialmente, neste caso através da geometria.
• Justificativa do Item 6: A classe NUMÉRICO no SPRING é definida
para representar fenômenos distribuídos espacialmente através de um
conjunto de pontos regularmente espaçados ou não, onde para cada ponto
existe um valor que representa a grandeza geográfica que se deseja
mapear. As classes do OGIS que possuem uma definição próxima diste
são é COVERAGE GRADE e COVERAGE TIN.
150
• Justificativa do Item 7: Esta tradução é clara pela terminologia utilizada
nos dois sistemas. Esta terminologia reflete para os dois casos um
conteúdo semelhante para representação de imagens georeferenciadas.
• Justificativa dos itens 8 e 9:
A classe CADASTRAL e REDE são
especializações de uma instância da classe OBJETOS com representação
no MAPA DE OBJETOS. Trata-se de feições que representam elementos
geográficos do mundo real, individualizados e possuem uma geometria
associada. Esta definição é semelhante ao conceito de FEIÇÃO C/
GEOMETRIA do OGIS.
• Justificativa do item 10: A classe TABELA DE ATRIBUTOS define a
descrição alfanumérica que está associada aos OBJETOS que poderão ou
não possuir uma representação geométrica no MAPA DE OBJETOS. Isto é
semelhante a atribuição da classe ATRIBUTOS que está associada a
FEIÇÃO C/ GEOMETRIA. Daí a correspondência entre as classes.
• Justificativa dos itens 11 à 13: Estes itens não se encontram de forma
explícita na documentação do OGIS, o que nós leva a concluir que estão
em processo de definição.
5.4.2.3.5 - MGE para SPRING e vice-versa
A tradução semântica entre os sistemas MGE e SPRING é mostrada pela
Tabela 5.6. Em seguida são apresentadas as justificativas para esta tradução :
151
TABELA 5.6 - TABELA DE CONVERSÃO DO MGE PARA O SPRING E VICEVERSA
ITEM
MGE
1
2
PROJETO
CLASSES DE FEIÇÕES
3
4
TABELA DO USUÁRIO
GRADE REGULAR
GRADE IRREGULAR
TRIANGULAR
IMAGENS
5
SPRING
GLOBAL
PROJETO
TEMÁTICO / OBJETOS com
representação no MAPA DE OBJETOS
TABELA DE ATRIBUTOS
NUMÉRICO
CAMPOS/OBJETOS
OBJETOS
CAMPOS
IMAGENS
CAMPOS
• Justificativa do item 1: A tradução do item 1 é justificada pela
proximidade de definição existente as duas classes. Em ambos os casos
busca-se definir o sistema de coordenadas a ser utilizado, e identificar a
área geográfica de trabalho. No SPRING, além disto, existe a definição do
retângulo envolvente desta área geográfica de trabalho, o que no MGE não
é necessário.
• Justificativa do item 2: A classe CLASSE DE FEIÇÕES no MGE pode
ser mapeada para duas classes no SPRING: TEMATICO e OBJETOS com
representação no MAPA DE OBJETOS. Esta duplicidade de mapeamento
é acontece porque no MGE não existe distinção para se representar
fenômenos
geográficos
distribuídos
espacialmente,
e
fenômenos
geográficos discretos. Neste caso, a classe CLASSE DE FEIÇÃO é
utilizada para representar estes dois tipos de fenômenos.
• Justificativa do item 3: Esta tradução é justificada porque as classes
dos dois sistemas representam a mesma semântica: tabelas descritivas
criadas pelo usuário associadas às feições geográficas.
• Justificativa do item 4 e 5: Estas traduções são justificadas pela
proximidade de definição entre as classes correspondentes.
152
5.4.2.3.6 - MGE para ARC/INFO e vice-versa
A tradução semântica entre os sistemas MGE e ARC/INFO é mostrada pela
Tabela 5.7. Em seguida são apresentadas as justificativas para esta tradução :
TABELA 5.7 - TABELA DE CONVERSÃO DO MGE PARA O ARC/INFO E
VICE-VERSA
ITEM
MGE
1
CATEGORIA
2
3
4
CLASSE DE FEIÇÕES
TABELA DO USUÁRIO
PONTO
IDENTIFICADOR DE ÁREA
LINHA
FRONTERIA DE ÁREA
FORMA COMPLEXA
GRADE REGULAR
5
6
7
8
9
GRADE IRREGULAR
TRIANGULAR
IMAGENS
ARC/INFO
<CONJUNTO DE
COVERAGE>
COVERAGE
TABELA DE ATRIBUTOS
PONTO
GLOBAL
CAMPOS/OBJETOS
CAMPOS/OBJETOS
OBJETOS
OBJETOS
LINHA
POLÍGONO
OBJETOS
OBJETOS
GRID
LATTICE
TIN
CAMPOS
IMAGEM
CAMPOS
CAMPOS
• Justificativa do item 1: A classe CATEGORIA do MGE representa a
generalização de CLASSE DE FEIÇÕES que possuem semelhanças. A
classe correspondente no ARC/INFO que melhor corresponderia a esta
definição do MGE seria <CONJUNTO DE COVERAGE>. Porém, esta
classe <CONJUNTO DE COVERAGE> não existe de forma explícita no
modelo conceitual do ARC/INFO. Existe esta noção quando o usuário cria
uma estrutura de diretório para organizar e agrupar as coverages mais
semelhantes. Esta organização é mais explícita no sistema ARC/VIEW
porque pode-se criar uma “view” composta por um conjunto de coverage.
Neste sistema, cada coverage é denominada de “tema” da “view”. Por isto,
optamos por representar o correspondente da classe CATEGORIA do
MGE por <CONJUNTO DE COVERAGE>.
• Justificativa do item 2: A classe CLASSE DE FEIÇÕES do MGE
representa classes de feições geográficas semelhantes. Esta noção é
153
compartilhada pela classe COVERAGE, porém, o aspecto de “semelhança”
é mais forte no ARC/INFO. Isto justifica-se porque necessariamente as
feições pertencentes numa mesma coverage devem ter geometrias
semelhantes: ponto, linha ou polígono. No MGE as feições geográficas
pertencentes à uma mesma CLASSE DE FEIÇÕES não necessitam ter a
mesma geometria.
• Justificativa do item 3: Esta tradução é justificada porque em ambos os
sistemas estas classes representam os atributos alfanuméricos definidos
pelo usuário.
• Justificativa dos itens 4, 5 e 6: Estas traduções são justificadas pela
semelhança de geometria existente entre as classes correspondentes.
• Justificativa do item 7, 8 e 9: Estas traduções são justificadas pela
proximidade de definição entre as classes correspondentes.
5.2.2.3.7 - ARC/INFO para SPRING e vice-versa
A Tabela 5.8 mostra a tradução entre o modelo conceitual do ARC/INFO e o
SPRING. . Em seguida são apresentadas as justificativas para esta tradução :
• Justificativa Item 1: A classe COVERAGE do ARC/INFO possui a
responsabilidade
de
representar
fenômenos
geográficos.
Esta
representação é geométrica e pode ser especializada em três tipos:
polígono, linha ou ponto. Os fenômenos geográficos são categorizados em
duas classes: Objeto Geográfico e Campos, conforme exposto no capítulo
2 tópico 2.2.3 deste trabalho.
154
TABELA 5.8 - TABELA DE TRADUÇÃO DE ARC/INFO PARA SPRING E
VICE-VERSA
ITEM
1
2
3
4
ARC/INFO
SPRING
COVERAGE
TABELA DE ATRIBUTOS
TIN
GRID
LATTICE
IMAGEM
GLOBAL
PLANO DE INFORMAÇÃO / OBJETO /
CADASTRAL
PLANO DE INFORMAÇÃO / OBJETO /
REDE
PLANO DE INFORMAÇÃO / TEMÁTICO
TABELA DE ATRIBUTOS
NUMERICO
OBJETOS
IMAGEM
CAMPOS
OBJETOS
CAMPOS
OBJETOS
CAMPOS
Porém, a classe COVERAGE possui limitações para representar dados do
tipo Campos. Unicamente dados temáticos do tipo vetorial são suportados.
Isto ocorre porque, para outros tipos de dados Campos, existem métodos
específicos de representação diferentes da COVERAGE.
A classe PLANO DE INFORMAÇÃO é uma estrutura computacional onde
são representados os fenômenos geográficos modelados no SPRING.
Uma instância da classe PLANO DE INFORMAÇÃO pertence a uma
categoria disponível no sistema. A categoria que define a classe de dados
a ser apresentada é manipulada no PLANO DE INFORMAÇÃO.
As
categorias
CATEGORIA
possíveis
em
decorrem
MAPAS
DE
da
especialização
OBJETOS
e
da
classe
CAMPOS.
Essas
especializações são semelhantes às duas classes de fenômenos
geográficos descritos anteriormente: Objetos Geográficos e Campos. As
classes de Objetos Geográficos disponíveis pelo sistema são OBJETOS
representados como CADASTRAL, REDE e NÃO ESPACIAL (sem
representação geométrica). As classes de Campos disponíveis no sistema
são: TEMÁTICO, NUMÉRICO e IMAGENS.
155
Portanto, a classe COVERAGE do ARC/INFO possui como correspondente
no SPRING o PLANO DE INFORMAÇÃO pertencente às categorias
OBJETO/CADASTRAL, OBJETO/REDE e TEMÁTICO/SUB-TEMAS.
Esta tradução identificou apenas estas classes correspondentes devido às
limitações existentes na classe COVERAGE. Nesta operação de tradução
necessita-se a orientação do usuário para definir a classe de dados correta
para correspondência de acordo com a utilização dos dados. O caminho
de retorno é verdadeiro e direto.
• Justificativa Item 2: Os atributos alfanuméricos associados à classe
COVERAGE no ARC/INFO são representados pela classe TABELA DE
ATRIBUTOS. No SPRING, esses atributos são representados pela classe
TABELA DE ATRIBUTOS associada à classe OBJETOS. Em ambos os
casos a TABELA DE ATRIBUTOS é formada por atributos alfanuméricos
definidos pelo usuário para descrever fenômenos geográficos do tipo
objetos geográficos. Neste escopo, a tradução entre as duas classes
TABELA DE ATRIBUTOS nos dois sistemas é verdadeira
nos dois
sentidos.
• Justificativa Item 3: Os fenômenos geográficos do tipo campos podem
ser representados no ARC/INFO, além da classe COVERAGE para dados
temáticos, pelas classes TIN, GRID ou LATTICE. No SPRING esta
representação pode ser dada pela classe NUMÉRICO. Portanto, a
correspondência das classes TIN, GRID e LATTICE é a classe
NUMÉRICA. No caminho de retorno torna-se necessário a interação com o
usuário para indicar ao sistema a tradução correta da classe NUMÉRICO
para as três classes possíveis no ARC/INFO, considerando-se a finalidade
de utilização do dado.
156
• Justificativa Item 4: A classe IMAGEM do ARC/INFO e a classe
IMAGEM do SPRING tratam do mesmo tipo de dados: imagens no formato
“raster”. Este tipo de classe de dados nos dois sistemas reflete uma
especialização da classe campo. Portanto, a tradução é direta entre as
duas classes nos dois sentidos
Existem classes de dados tanto do modelo de ARC/INFO, quanto do modelo o
SPRING que não sofreram tradução. As justificativas de cada ocorrência serão
apresentadas a seguir.
No modelo do SPRING, as classes que não sofreram tradução são: BANCO
DE DADOS GEOGRÁFICO, PROJETO e NÃO ESPACIAL.
A classe BANCO DE DADOS GEOGRAFICO representa o repositório das
informações espaciais e não espaciais geradas ao longo de um projeto.
Explicitamente não existe uma classe responsável por isto no ARC/INFO. De
uma forma mais prática, o que mais se aproxima deste conceito no ARC/INFO
é a estrutura de diretórios que o usuário do sistema deve montar para
armazenar cada COVERAGE gerada. Porém, isto não é evidente no modelo
conceitual do ARC/INFO.
A classe PROJETO do SPRING define a área geográfica de estudo sobre o
BANCO DE DADOS GEOGRÁFICO. Pode existir mais de um projeto
associado ao mesmo banco. No entanto, não existe de forma explícita uma
classe PROJETO no modelo conceitual do ARC/INFO que desempenhe esta
mesma função. Porém, com o produto de visualização e consulta de dados
geográficos, o ArcView, é possível se criar vários projetos associados às
mesmas COVERAGEs armazenadas na estrutura de diretório criada pelo
usuário.
157
A classe NÃO ESPACIAL representa dados alfanuméricos, introduzidos pelo
usuário no sistema, que não estão ligados diretamente a uma representação
geométrica. Semelhante conceito não foi identificado no ARC/INFO. De forma
indireta, a classe TABELA DE ATRIBUTOS pode ter esse tipo de
responsabilidade.
No modelo do ARC/INFO as classes que não sofreram tradução são: MODELO
DE DADOS VETORIAL, MODELO DE DADOS DE GRADE IRREGULAR,
MODELO DE DADOS REGULAR, PONTO, LINHA, POLÍGONO, TABELA DE
VALORES.
As classes MODELO DE DADOS VETORIAL, MODELO DE DADOS DE
GRADE IRREGULAR, MODELO DE DADOS REGULAR são classes
generalizadas que abrangem as classes de dados que possuem uma tradução
direta. No entanto, para estas classes não foram identificadas, de forma direta,
uma tradução para o SPRING.
As classes PONTO, LINHA e POLÍGONO são tipos de representações
geométricas que um COVERAGE pode assumir no ARC/INFO. Este tipo de
representação geométrica existe no SPRING, no entanto, ela está associada
intimamente à classe de dados especificada na CATEGORIA. Por não existir
uma correspondência direta no modelo, não é possível realizar a tradução para
estas classes.
A classe TABELA DE VALORES define os valores que estão associados a
cada elemento que compõe a classe GRID. Semelhante conceito não existe no
SPRING.
158
5.4.2.4 - Modelo
O modelo representa um repositório de dados onde é armazenada cada
ocorrência de um novo modelo conceitual desenvolvido pelo usuário do
GeoTMS, em qualquer um dos SIGs selecionados. Esta classe de dados é
representada pela Figura 5.9.
MODELOS
Fig. 5.9 - Visão Estática: Classe modelos onde são armazenadas as
ocorrências de modelos conceituais desenvolvidos pelo usuário
do sistema.
5.4.2 - Visão de Dinâmica
A visão dinâmica busca representar as mudanças de estado do sistema que
ocorrem com o passar do tempo. A Figura 5.10 apresenta o diagrama de
transição de estado e eventos que reflete a visão dinâmica.
Este diagrama apresenta 12 transições de estado provocadas por 21 eventos
diferentes. Estes eventos são ações provocadas pelo ususário do sistema, ou
pelo próprio sistema, ocasionando a modificação do estado. Estas ações
devem ser englobadas pelos processos do diagrama de fluxo de dados.
159
5.5 - Projeto do GeoTMS
Neste caso, a fase de projeto será composta pelo diagrama de estrutura dos
módulos e pela construção das tabelas que compõem o modelo relacional.
1 - Executar Sistema
MONTANDO AMBIENTE DE
TRABALHO PADRÃO
2 - Selecionar
MGE como
Ambiente de Trabalho
4 - Selecionar
SPRING como
Ambiente de Trabalho
3 - Selecionar
ARC / INFO como
Ambiente de Trabalho
MONTANDO AMBIENTE DE
TRABALHO NO ARC/INFO
MONTANDO AMBIENTE DE
TRABALHO NO MGE
MONTANDO AMBIENTE DE
TRABALHO NO SPRING
6 - Montar
Modelo Conceitual
em ARC/INFO
5 - Montar
Modelo Conceitual
em MGE
7 - Montar
Modelo Conceitual
em SPRING
MONTANDO
MODELO CONCEITUAL
8 - Checar a Consistência
do Modelo Conceitual
11 - Ajustar Modelo
Conceitual
CHECANDO
CONSISTÊNCIA
10 - Dar resposta ao
usuário
9 - Dar resposta ao
usuário
APONTANDO
OS PROBLEMAS
OCORRIDOS
EVIANDO MENSAGEM DE
SUCESSO NA
CHECAGEM DE CONSISTÊNCIA
12 - Traduzir para
o Modelo OGIS
15 - Traduzir para
o Modelo SPRING
13 - Traduzir para
o Modelo MGE
TRADUZINDO O MODELO
PARA OGIS
14 - Traduzir para
o Modelo ARC/INFO
TRADUZINDO O MODELO
PARA MGE
TRADUZINDO O MODELO
PARA ARC/INFO
TRADUZINDO O MODELO
PARA SPRING
16 - Traduzir para o
Modelo ARC/INFO
17- Traduzir para o Modelo SPRING
18 - Traduzir para o
Modelo ARC/INFO
19 - Traduzir para o Modelo MGE
20 - Traduzir para o Modelo MGE
21 - Traduzir para o Modelo SPRING
Fig. 5.10 - Visão Dinâmica: Diagrama de Transição de Estados.
160
O diagrama de estrutura dos módulos é derivado do diagrama de fluxo de
dados apresentado na visão funcional. Já a especificação do modelo relacional
é derivada dos modelos de objetos apresentados na visão estática do sistema.
5.5.1 - Diagrama de Estrutura do Módulos
Como já mencionado, este diagrama é derivado do diagrama de fluxo de
dados - DFD . A Figura 5.11 apresenta o diagrama de estrutura dos módulos
ressaltando, através de setas, os fluxos de controle e de dados entre os
módulos.
5.5.2 - Modelo Relacional
Conforme já mencionado, o modelo relacional é derivado da visão estática do
sistema. A visão estática foi construída segundo a técnica de modelagem de
objetos TMO, portanto será utilizada a técnica de mapeamento de objetos para
ambientes relacionais como exposto no tópico 3.4 Persistência de Objetos em
Ambientes Relacionais, para a construção do banco de dados.
5.5.2.1 - Objetos Gráficos
A classe objetos gráficos armazena os 4 tipos de objetos gráficos atualmente
disponíveis neste sistema: OGIS, MGE, ARC/INFO e SPRING. Esta classe é
diretamente mapeada para uma tabela no modelo relacional, como mostrado
na Tabela 5.9.
161
TABELA 5.9 - OBJETOS GRÁFICOS
CAMPO
ID_SIG
TIPO
caracter
TAMANHO
1
SIG
caracter
10
DESCRIÇÃO
Identificador do SIG que terá sua classes
representadas por objetos gráficos
Denominação do Sistema de Informação
Geográfica
TRADUZIR MODELOS
SEMÂNTICOS
STATUS
MODELO
MODELO
MODELO
MODELO
CONVERTIDO
MODELO
CONVERTIDO
CONVERTER
MODELOS
CONSTRUIR
MODELOS
APRESENTAR
TRADUÇÃO
MODELO
CONVERTIDO
MODELO
CONVERTIDO
SIG
MODELO
STATUS
MODELO
SIG
TRADUZIR
PARA
OGIS
MODELO
CONVERTIDO
TRADUZIR
PARA
ARC / INFO
MODELO
TRADUZIR
PARA
MGE
MODELO
SIG
VERIFICAR
CONSISTÊNCIA
APRESENTAR
INTERFACE
STATUS
SIG
APRESENTAR
INTERFACE
SELECIONAR
SIG
SIG
STATUS
MODELO
APRESENTAR
AMBIENTE
DO SIG
CHECAR
PROPRIEDADES
STATUS
CHECAR
CLASSES
MODELO
APONTAR
INCONSISTÊNCIAS
ENVIAR
MENSAGEM
MODELO
INCONSISTENTE
MONTAR
MODELO
CONCEITUAL
MODELO
SIG
MODELO
INCONSISTENTE
DISPONIBILIZAR
FERRAMENTAS
Fig. 5.11 - Diagrama de estrutura dos módulos.
162
TRADUZIR
PARA
SPRING
5.5.2.2 - Regras Conceituais
As regras conceituais refletem a semântica de cada SIG estudado e do modelo
OGIS.
Cada classe do modelo conceitual dos SIGs e OGIS representados através da
TMO é mapeado para o modelo relacional por uma única tabela. Isto é
possível pela aplicação do conceito de auto-relacionamento, e pela utilização
de chaves estrangeiras para indicar qual SIG está associado à uma
determinada classe.
Na coluna descrição da tabela gerada, tabela 5.10, tem-se maiores detalhes
sobre a utilização destes conceitos.
TABELA 5.10 - REGRAS CONCEITUAIS
CAMPO
ID_CLASSE
ID_SIG
TIPO
caracter
caracter
TAMANHO
5
1
CLASSE
CLASSE_SUP
caracter
caracter
50
5
TIPO_RELACION
inteiro
DESCRIÇÃO
Identificador da ocorrência de uma classe.
Chave estrangeira: Indica qual é o SIG
associado a ocorrência de uma classe.
Nome da classe.
Trata-se do campo que materializa o autorelacionamento. Este campo armazena o
identificador da classe superior à classe
ocorrida.
Armazena o tipo de relacionamento existente
entre a classe superior e a classe ocorrida.
Os tipo são:
0 - Especialização;
1 - Agregação;
2 - Associação.
5.5.2.3 - Tabela de Conversão
Trata-se da classe onde são armazenadas as traduções entre as classes dos
diversos sistemas estudados. Os valores desta tabela foram discutidos no
tópico 5.4.2.3. Esta parte da visão estática é mapeada para uma única tabela
no modelo relacional. A Tabela 5.11 mostra isto.
163
5.5.2.3 - Modelos
Trata-se da parte da visão estática onde são armazenadas as classes
construídas pelo usuário. Independentemente do SIG selecionado, a classe
modelo, além de armazenar as classes criadas pelo usuário, armazena os
relacionamentos entre elas.
TABELA 5.11- TABELA DE CONVERSÃO
CAMPO
ID_SIG1
TIPO
caracter
TAMANHO
1
ID_CLASSE1
ID_SIG2
caracter
caracter
5
1
ID_CLASSE2
caracter
5
DESCRIÇÃO
Chave estrangeira: Indica qual é o SIG
associado a classe 1 que será traduzida para
a classe 2.
Identificador da classe a ser traduzida
Chave estrangeira: Indica qual é o SIG
associado a classe correspondente a classe
1 traduzida.
Identificador da classe correspondente a
classe 1 traduzida.
Esta classe é mapeada para uma única tabela no modelo relacional, conforme
mostrado na Tabela 5.12.
TABELA 5.12- MODELOS
CAMPO
ID_CLASS_USU
TIPO
inteiro
TAMANHO
ID_SIG
caracter
1
ID_CLASSE
caracter
5
CLASSE_USU
ID_SUP_USU
caracter
inteiro
50
TIPO_RELACIONA
COMENTARIO
inteiro
caracter
50
164
DESCRIÇÃO
Chave Primária: Identificador de uma classe
criada pelo usuário
Chave Estrangeira: Identificador do SIG
pertencente a classe criada pelo usuário.
Chave Estrangeira: Identificador da classe
do SIG a qual a classe do usuário derivou.
Nome da classe criada pelo usuário.
Identificador da classe superior criada pelo
usuário. Implementa o auto-relacioanmento
Armazena o tipo de relacionamento
existente entre a classe superior e a classe
ocorrida. Os tipo são:
0 - Especialização;
1 - Agregação;
2 - Associação.
Armazena algum comentário sobre a classe
5.6 - Implementação
Para ilustrar esta fase será apresentada a interface do sistema. As principais
telas, seguidas de uma breve descrição serão mostradas a seguir. Também
serão apresentados um exemplo de modelo conceitual construído pelo usuário,
um exemplo da sua conversão para o padrão OGIS, e
exemplos de sua
conversão para outros SIGs.
A Figura 5.12 ilustra o ambiente padrão do GeoTMS. Esta interface é
apresentada ao usuário após a inicialização do sistema.
Já a Figura 5.13 mostra o menu “arquivo”, onde são permitidas ao usuário as
opções de criar um “novo” modelo conceitual, “abrir” um modelo conceitual já
existente em determinado SIG, “salvar” um modelo, e “sair” do sistema.
A Figura 5.14 apresenta o menu “exibir” e as suas opções. A opção “Objetos
Gráficos” mostra uma janela onde são disponíveis as classes de dados do SIG
selecionado pelo usuário. Estas janelas são mostradas pelas Figuras 5.19,
5.20 e 5.21. É através destas janelas que o usuário seleciona a classe de
dados que deseja instancializar e insere-a no seu modelo.
O usuário
seleciona o SIG no qual deseja construir o seu modelo no momento que
aciona a opção “novo”, no menu “arquivo”. A partir daí, uma janela é
apresentada, conforme exposta pela Figura 5.18, com uma lista dos SIGs
disponíveis para construção do modelo.
A opção “Relacionamentos” disponível no menu “Exibir”, apresenta ao usuário
os tipos de relacionamentos que poderão existir entre as classes que
representam o modelo de cada um dos três SIGs. Cabe ao usuário selecionar
um tipo de relacionamento e “clicar” em duas classes de seu modelo para
materializar o relacionamento entre eles. A Figura 5.15 ilustra esta
funcionalidade.
165
Outra importante funcionalidade implementada é a verificação da consistência
do modelo conceitual que está sendo construído pelo usuário do sistema, com
as regras semânticas do SIG selecionado.
Isto é permitido pelo Menu
“Consistência” opção “verificar”, exposta na Figura 5.16.
Fig. 5.12 - Ambiente padrão do GeoTMS.
Fig. 5.13 - Menu arquivo e suas opções.
166
Fig. 5.14 - Menu “Exibir” e suas opções.
Fig. 5.15 - Tipo de relacionamentos disponíveis pelo GeoTMS.
Fig. 5.16 - Menu “Consistência”, opção para verificar consistência do modelo
conceitual do usuário.
As opções para tradução do modelo conceitual elaborado pelo usuário para
outros SIGs, e para o padrão OGIS, são permitidos pelo menu “Tradução”,
conforme exposto na Figura 5.17.
167
Fig. 5.17 - Opção para a tradução do modelo conceitual do usuário.
Fig. 5.18 - Interface de seleção de SIG.
168
Fig. 5.19 - Classes de dados do MGE disponibilizadas ao usuário do sistema
para elaborar o modelo conceitual.
Fig. 5.20 - Classes de dados do ARC/INFO disponibilizadas ao usuário do
sistema para elaborar o modelo conceitual.
169
Fig. 5.21 - Classes de dados do SPRING disponibilizadas ao usuário do
sistema para elaborar o modelo conceitual.
A Figura 5.22 ilustra um exemplo de uma modelo conceitual elaborado pelo
usuário do sistema no SIG MGE. Após realizada a verificação de consistência
com sucesso, o modelo está disponível para tradução.
A seguir é apresentada a Figura 5.23 onde é mostrado o resultado da tradução
do modelo conceitual elaborado no MGE para o padrão OGIS. Já a Figura
5.24 apresenta o modelo MGE e a sua tradução para o modelo ARC/INFO.
Para finalizar este exemplo a Figura 5.25 apresenta a tradução deste modelo
MGE para o SPRING.
170
Fig. 5.22 - Exemplo de modelo conceitual elaborado pelo usuário no SIG MGE.
Fig. 5.23 - Exemplo de tradução do modelo conceitual do MGE para o OGIS.
171
Fig. 5.24 - Exemplo de tradução do modelo conceitual do MGE para o SIG
ARC/INFO.
Fig. 5.25 - Exemplo de tradução do modelo conceitual do MGE para o SIG
SPRING.
172
CAPÍTULO 6
CONCLUSÃO
Esta dissertação reflete um trabalho de investigação sobre o problema de
interoperabilidade em Geoprocessamento sob um ponto de vista prático e real.
As funcionalidades de transferência de dados entre SIGs, e as propostas de
especificações de padronização de dados geográficos, foram os primeiros
passos rumo à interoperabilidade. No entanto, estes mecanismos de
transferência de dados entre formatos distintos esbarram nas regras
conceituais que devem ser obedecidas para a absorção destes dados
geográficos pelos SIGs.
Tais regras conceituais refletem a maneira como os dados geográficos devem
ser dispostos no SIG para a sua manipulação. Portanto, é vital o conhecimento
destas regras conceituais para realizar, de forma plena, a interoperabilidade.
Desenvolvemos um estudo investigativo sobre três SIGs utilizados no Brasil:
MGE, ARC/INFO e SPRING e uma análise comparativa entre os modelos
conceituais destes sistemas e o padrão OPEN GIS. O objetivo do estudo da
especificação OPEN GIS foi ter um referencial para comparar os SIGs. O grau
de aderência destes SIGs ao padrão OPEN GIS nos permitiu ter uma
indicação
da
distância
entre
estes
SIGs
e
as
funcionalidades
de
interoperabilidade prometidas pelo OPEN GIS.
A especificação do OPENGIS encontra-se ainda em fase de desenvolvimento,
com muitos assuntos ainda não concluídos. Apesar disto, este trabalho buscou
investigar e interpretar esta especificação de maneira a trazer de uma forma
mais clara e objetiva os conceitos abordados.
173
Este trabalho realizou ainda um proposta de tradução entre as regras
conceituais de cada SIG para o padrão OPEN GIS, e também um proposta de
tradução entre os SIGs. Para isto desenvolveu-se tabelas de conversão entre
as classes de dados que compõem os diferentes modelos conceituais de cada
SIG.
Esta proposta de tradução foi materializada por um protótipo de sistema
denominado de Tradutor de Modelos Semânticos de Geo-Informação GeoTMS. Este sistema se propõe a ser uma ferramenta no auxílio à
interoperabilidade para efetivar a transferência de dados de um sistema para o
outro, respeitando as regras semânticas de cada SIG.
As conclusões obtidas com esta experiência podem ser listadas a seguir pelo
tópicos 6.1, 6.2 e 6.3.
6.1 - Diferenças Conceituais entre os SIGs do mercado
O estudo mostrou uma grande distância semântica entre os sistemas
considerados. Deste modo, a proposta de tradução entre os modelos
semânticos de cada SIG, implementada na ferramenta GeoTMS não
necessariamente é a única possível. Nem todas as classes de dados de um
sistema possuem um correspondente direto no outro sistema, e pode-se
concluir que qualquer proposta de tradução será necessariamente incompleta.
Podemos citar alguns exemplos:
1) O MGE implementa a idéia de especialização de feições geográficas,
com os conceitos de categoria e classe de feições, não disponíveis
explicitamente no ARC/INFO e no SPRING. A indexação de bancos de
dados geográficos (através do conceito de INDICE) não possui
correspondência exata no ARCINFO e SPRING;
174
2) O SPRING estabelece uma separação entre a feição geográfica e sua
representação (através dos conceitos de objeto e cadastral), e permite
diferentes representações associadas a um mesmo campo (coverage).
Estas duas características estão ausentes no MGE e no ARC/INFO.
3) O ARC/INFO permite a associação de uma representação matricial de
um campo (GRID) com uma TABELA DE VALORES, o que não tem
correspondência exata em MGE e SPRING.
6.2 - Alcance e Limitações do padrão OPEN GIS
Da comparação do padrão OPENGIS com os diferentes SIGs e com as
propostas téoricas de modelagem da literatura, é possível estabelecer que a
especificação OPENGIS está centrada em dois conceitos fundamentais para
representar fenômenos geográficos: feição com geometria e coverage. A
especificação do conceito de feição com geometria se aproxima da noção
teórica de geo-objetos, assim como a especificação do conceito de coverage
se aproxima da definição de geo-campo. De uma forma geral, por abordar as
duas perspectivas de modelagem geográfica, a especificação OPEN GIS deve
ser vista como um avanço conceitual em relação aos principais SIGs do
mercado internacional.
No entanto, tal como está especificada hoje, e em função dos diferentes
compromissos que uma solução de consenso inevitavelmente tem de adotar, a
proposta OPEN GIS apresenta ainda algumas limitações e indefinições:
1) Apesar da proposta técnica estar baseada no visão de “campos” e
“objetos”, também há uma tendência em acomodar alguns conceitos dos
modelos semânticos do MGE e do ARC/INFO. Os conceitos de “feição com
geometria” e “coverage” propostos facilitam a aderência do modelo MGE
ao primeiro e do ARC/INFO ao segundo.
175
2) O problema da separação entre feição geográfica e sua representação
(essencial para questões como modelagem temporal) não foi tratado
adequadamente, pois a noção de “feição simples” refere-se a uma única
representação espacial. O SPRING trata este problema de forma mais
adequada, ao diferenciar entre geo-objeto e mapa cadastral. A noção de
“feição complexa”, que seria uma possível maneira de resolver o problema,
não está descrita de forma completa na atual especificação e pode gerar
complicações desnecessárias.
3) No OPEN GIS, uma coverage pode ser especializada em diferentes
representações (grade, vetor, pontos), o que configura uma proposta
desnecessariamente restritiva, pois cada coverage teria uma e somente
uma representação. Seria muito mais útil substituir a noção de
especialização de uma coverage em diferentes representações pela idéia
da coverage como uma agregação de representações geométricas, como
faz o SPRING. Neste caso, uma mesma coverage (um MNT, por exemplo)
poderia possuir simultâneamente várias representações geométricas
(como grade regular, malha triangular, isolinhas e amostras esparsas).
4) A idéia de hierarquia entre feições (uma classe de feições podendo ser
especializada em outras), disponível no MGE, é extremamente útil na
modelagem de problemas reais. Mais uma vez, a especificação OPENGIS
não é explícita a forma de realizar esta hierarquia, pois as noções de
“feição complexa” e “conjunto de feições” não estão completamente
especificadas.
Nestes casos, o padrão OPENGIS pode ser visto como tendo menor poder
expressivo que sistemas já disponíveis e a tradução de modelos conceituais de
sistemas como o SPRING e o MGE para o padrão OPENGIS será feita com
perda de semântica.
176
6.3 - Interoperabilidade na Prática
Não obstante suas limitações, a especificação OPEN GIS representa um
avanço significativo na questão da interoperabilidade. Como vimos ao longo
deste trabalho, há ainda muitas indefinições e dúvidas que terão de ser
resolvidas, antes do OPENGIS ser estabelecido de fato.
As soluções adotadas pelo OPENGIS (ao acomodar as definições mais aceitas
na teoria de Geoprocessamento à realidade dos sistemas) podem ter um efeito
contraproducente. Ao permitir dubiedades e inconsistências no mapeamento
de bancos de dados existentes para o padrão OPEN GIS, o consórcio pode ter
criado um substancial problema para a futura migração dos bancos de dados
geográficos existentes para o padrão.
Tome-se o caso da migração de um grande centro de dados no formato
ARC/INFO para o padrão OPENGIS. Como as “coverages” ARC/INFO podem
ser
entendidas
tanto
como
“feições
com
geometria”
ou
“coverages
geométricas” no OPENGIS, o resultado da tradução admite uma dubiedade.
Assim, um usuário externo dos dados deste banco de dados pode ter
surpresas ao tentar fazer acesso aos dados, porque o entendimento do padrão
OPENGIS deste usuário pode não ser o mesmo do estabelecido pelo
administrador do centro de dados.
177
6.4 - Estudos Futuros
Como complemento deste trabalho e em continuidade ao problema de
interoperabilidade em Geoprocessamento, acreditamos relevante abordar:
• uma extensão do estudo realizado para outros SIGs de mercado, como
MapInfo, IDRISI, Vision e Smallworld;
• um aumento de funcionalidade da ferramenta GeoTMS para modelar
sistemas como os citados acima, e para incluir relacionamentos entre
entidades do banco de dados geográfico;
• uma ligação do sistema GeoTMS com ferramentas de tradução sintática
de dados geográficos (conversores de formatos);
• a proposição de um modelo conceitual para dados geográficos que possa
unificar os conceitos dos diferentes sistemas, sem as restrições presentes
no OPEN GIS, e
• a análise do problema de interoperabilidade de procedimentos de análise
espacial, usualmente expressos em linguagens de comandos (GRID no
ARC/INFO,
AVENUE
no
ARC/VIEW,
LEGAL
no
SPRING),
e
a
implementação de um tradutor semântico entre estas linguagens.
Espera-se no futuro, com a absorção da padronização das especificações
propostas pelo consórcio OPEN GIS, que o mundo do geoprocessamento seja
totalmente aberto e acessível por qualquer ferramenta que obedeça estas
especificações, em qualquer lugar do planeta. Este futuro infelizmente não está
muito próximo, uma vez que a adequação dos sistema atuais a esta
especificação não é instantânea, e a migração dos dados geográficos
existentes nos diversos formatos pode ser bastante lenta.
178
Um fato é certo: o intercâmbio entre as diversas comunidades que utilizam
informação geográfica é extremamente necessário nos dias de hoje, e muito já
esta sendo feito para transformar esta necessidade em uma solução
operacional.
179
180
REFERÊNCIAS BIBLIOGRÁFICAS
Bakker, M. P. R. Cartografia: noções básicas. Rio de Janeiro: Ministério da
Marinha - Diretoria de Hidrografia e Navegação, 1965. 242p.
Burrough, P.A. Principles of geographical information systems for land
resources assessment. New York: Oxford University Press,1986. 194p.
Câmara, G. Modelos, linguagens e arquitetura para banco de dados
geográficos. São José dos Campos. Tese (Doutorado em Computação
Aplicada) - Instituto Nacional de Pesquisas Espaciais - INPE, 1995.
Environmental Systems Research Institute (ESRI). Arc/Info data management
concepts, data models, database design, and storage. Redlands: 1994.
389p.
Environmental Systems Research Institute (ESRI). ESRI's spatial database
engine: a seamless GIS solution. [online].
<http://www.esri.com/base/common/userconf/proc96/TO100/PAP094/P94A
.HTM>. March 1998.
Fleximage Groupe Aeroespatiale. O2Géo: Le SGBD géographique objet.
[online]. <http://www.fleximage.fr/produits/o2geo/indexf.htm>. March 1998.
Gahegan M. Accounting for the semantic differences between various
geographic information systems . [online].
<http://bbq.ncgia.ucsb.edu/conf/interop97/program/papers/gahegan.html>.
July 1998.
181
Gooldchild F. M. , Egenhofer M. J., Fegeas R. Interoperating GISs : report of
a specialist meeting held under the auspices of varenius project, painel on
computacional implementations of geographic concepts. [online]
<ncgia.ucsb.edu/conf/interop97/report.html> July 1998.
Gooldchild F. M. Geographical data modeling. Elsevier: Computers &
Geosciences, 1992, 408.
Intergraph Corp. MGE basic nucleos (MGNUC) user’s guide for the
windows NT operating system. Huntsville: 1994. 378p.
Intergraph Corp. MGE analyst (MGA) user’s guide. Hunstiville: 1997. 182p.
Intergraph Corp. GeoMedia pro first product designed specifically for
A
enterprise collection and maintenance of GIS Data . [online]. CC
<http://www.intergraph.com/venezuela/noticias/221.htm> July 1998.
Korth, H. F., Silberschatz, A. Sistemas de banco de dados. São Paulo:
McGraw-Hill, 1989. 582p.
Laser - Scan Geographic Information System. Gothic development
environment. [online]. <http://www.lsl.co.uk/products/gothic.htm>. March
1998.
Mapa. In: Buarque de Holanda Ferreira, A: minidicionário. Rio de Janeiro:
Nova Fronteira, 1977. 306p.
Milne, P.; Milton, S.; Smith, J.L. Geographical Object-Oriented Data Bases: a
Case Study. International Journal of Geographic Information Systems.
v. 7, n. 1, p. 39-55, January - February 1993.
182
O2 Technology. The O2 system, the database solution for C++, java and
smalltalk developers. [online]. <http://www.o2tech.com/>. March 1998.
Open GIS Consortium (OGC). Topic 5: The OpenGIS feature. [online]
<http://www.opengis.org/techno/specs.htm>. March 1998A.
Open GIS Consortium (OGC). Topic 6: The coverage type and its subtypes.
[online] <http://www.opengis.org/techno/specs.htm>. March 1998B.
Open GIS Consortium (OGC) Topic 1: Feature geometry. [online]
<http://www.opengis.org/techno/specs.htm>. March 1998C.
Open GIS Consortium (OGC) What is OpenGIS?. [online]
<http://www.opengis.org/opengis.htm#opengis>. March 1998D.
Oracle Corporation. New version of spatial data option catapults oracle
universal server into new mapping and network applications leading
industry partners commit to develop oracle-powered spatial. [online]
<http://www.oracle.com.ar:1000/corpnews/cn_0227.htm>. March 1998.
Pressman, R. S. Engenharia de software. São Paulo: Mc Graw-Hill, 1995.
CK 1056p.
Research Institute for Applied Knowledge Processing at the University
of Ulm
(FAW). Research project GODOT. [online]. <http://www.faw.uniulm.de:9876/umweltbe/protxt/GODOT.html>. March 1998.
Robinson, A. H. Elements of cartography. Santa Barbara: John Wiley &
Sons, 1963. 343 p.
183
Rumbaugh, J; Blaha, M; Premerlani, W; Eddy, F; Lorensen, W. Modelagem e
projeto baseados em objetos. Rio de Janeiro: Editora Campus, 1994.
652p.
Setzer, V. W. Projeto lógico e projeto físico de banco de dados. Belo
Horizonte: UFMG, 1986. 289p.
Instituto Nacional de Pesquisas Espaciais - Departamento de Processamento
de imagens (INPE.DPI). Introdução ao SPRING 2.0. [online].
<http://www.dpi.inpe.br/spring/usuario/intro.htm#historico>. abr. 1998a.
Instituto Nacional de Pesquisas Espaciais - Departamento de Processamento
de imagens (INPE.DPI). Introdução ao SPRING. [online].
<http://www.dpi.inpe.br/spring/teoria/introdu1/teoria1.htm#geopro>. abr.
1998b.
Instituto Nacional de Pesquisas Espaciais - Departamento de Processamento
de imagens (INPE.DPI). As classes básicas do modelo conceitual.
[online].
< http://www.dpi.inpe.br/spring/usuario/esquema2.htm#conc_campo >. abr.
1998c.
Instituto Nacional de Pesquisas Espaciais - Departamento de Processamento
de imagens (INPE.DPI). Manipulação de Dados Vetoriais no SPRING.
[online].
< http://www.dpi.inpe.br/spring/usuario/edicao_v.htm>. abr. 1998d.
Instituto Nacional de Pesquisas Espaciais - Departamento de Processamento
de imagens (INPE.DPI). Partindo do Início. [online].
< http://www.dpi.inpe.br/spring/usuario/passo1.htm>. maio. 1998e.
184
Thomé, R. ; Yamaguchi, F. ; Motta, M. Uma Proposta de Interface
Operacional entre SIG e SGBDR para Dados Convencionais. [CDROM]. In: Simpósio Brasileiro de Sensoriamento Remoto, Salvador,
8.,1996. Anais. São Paulo: Image Multimídia, 1996. Seção de
Comunicações Técnico Científicas.
Tufte, E. Visual Display of Quantitative Information. New York: Graphics
Press,1992. 232p.
Voisard, A. Geographic information extraction: querying or quarrying?
[online]. <http://www/inf.fu-berlin.de/~voisard/interop97.av.html>. July 1998.
Worboys, M.F.; Hearnshaw, H.M.; Maguire, D.J. Object-oriented data
modelling for spatial data bases. International Journal of Geographical
Information Systems, v. 4, n. 4, p. 369-383, October - December 1990.
Worboys, M.F. GIS : a computer perspective. Keele: Taylor&Francis, 1995.
376p.
Yourdon, E. Análise estruturada moderna. Rio de Janeiro: Editora Campus,
1990. 836p.
Yuan M. Development of a global conceptual schema for interoperable
geographic information. [online].
<http://bbq.ncgia.ucsb.edu/conf/interop97/program/papers/yuan/yuan.html>
. July. 1998.
185
186
APÊNDICE A
QUESTIONÁRIO DADO AO USUÁRIO E AO DESENVOLVEDOR
O questionário dado ao usuário tem por objetivo a aquisição maior
conhecimento sobre o sistema SPRING, sob a perspectiva do usuário. Ele é
ilustrado na Figura A.1:
QUESTIONÁRIO DADO AO USUÁRIO:
1) Qual a sua formação acadêmica ?
2) Qual o tempo de contato com sistemas informatizados ?
3) Qual o tempo de contato com o sistema SPRING ?
4) Em qual área aplica o sistema ?
5) O sistema soluciona os seus problemas ?
[ ] Sim, totalmente.
[ ] Sim, parcialmente.
6) Considera algum ponto frágil no sistema ?
7) Com relação ao tempo de resposta, considera o sistema eficiente ?
8) Quais os pontos que considera mais forte no sistema ?
9) Conhece outros sistemas na mesma área? Quais?
Fig. A.1 - Questionário dado ao usuário.
O questionário dado ao desenvolvedor tem por objetivo a aquisição maior
conhecimento sobre o sistema SPRING, sob a perspectiva do desenvolvedor.
Ele é ilustrado na Figura A.2.
187
QUESTIONÁRIO DADO AO DESENVOLVEDOR:
1) Qual a sua formação acadêmica ?
2) Qual a sua responsabilidade dentro do projeto do sistema ?
3) Foi utilizada alguma metodologia de Engenharia de Software ? Qual ?
[ ] Metodologia de Desenvolvimento Orientada por Objetos.
[ ] Fases: Análise, Projeto, Implementação/Teste e Manutenção.
[ ] Técnica de Modelagem de Objetos - TMO de Rumbaugh.
[ ] Modelagem Orientada por Objetos de Coad/Yourdon.
[ ] Outras:..................................................................................
[ ] Metodologia de Desenvolvimento Clássica
[ ] Fases: Análise, Projeto, Implementação/Teste e Manutenção.
[ ] Diagramas de fluxo de dados.
[ ] Diagrama entidade relacionamento.
[ ] Modelo relacional.
[ ] Diagrama de estados.
[ ] Outras:......................................................................................
4) Existe algum modelo gerado por você ou sua equipe ? Se sim é possível fornecer ?
5) É possível validar o esboço do modelo conceitual do sistema em anexo ?
6) Conhece a estrutura da base de dados no qual o sistema se apoia ?
[ ] Muito Bem
[ ] Bem
[ ] Moderado [ ] Desconhece
7) É possível validar estas estruturas de base de dados em anexo?
8) Considera o sistema eficaz, no sentido de atender os objetivos que se propõe?
9) Considera o sistema eficiente com relação ao tempo de resposta ?
10) Gostaria de destacar algum ponto do sistema que mereceria maior atenção ?
Fig. A.2 - Questionário dado ao desenvolvedor.
188
APÊNDICE B
TABULAÇÃO DAS RESPOSTAS : QUESTIONÁRIO DADO AO USUÁRIO E
AO DESENVOLVEDOR
A seguir é apresentada a tabulação das respostas obtidas no questionário
dado ao usuário*.
1) Qual a sua formação acadêmica?
TABELA B.1 - FORMAÇÃO DOS USUÁRIOS ENTREVISTADOS
GEOLOGIA
OCEANOGRAFIA
33.3%
BIOLOGIA
33.3%
OUTRAS
33.4%
0%
2) Qual o tempo de contato com sistemas informatizados ?
TABELA B.2 - TEMPO DE CONTATO COM SISTEMAS INFORMATIZADOS
até 2 anos
de 2 à 5 anos de 5 à 10 anos
de 10 à 15 anos Acima de
15 anos
0%
0%
66.6 %
33.4 %
0%
3) Qual o tempo de contato com o sistema SPRING ?
TABELA B.3 - TEMPO DE CONTATO COM O SPRING
até 1 anos
0%
de 1 à 3 anos
de 3 à 5 anos
33.4 %
Acima de 5 anos
66.6 %
____________________________
(*) O questionário foi aplicado em um universo de 6 usuários
189
0%
4) Em qual área aplica o sistema ?
TABELA B.4 - APLICAÇÃO DO SISTEMA
Meio Ambiente
Geologia
80%
Oceanografia
20 %
Outros
0%
0%
5) O sistema soluciona os seus problemas ?
TABELA B.5 - SOLUÇÃO DE PROBLEMAS
Sim, totalmente
Sim, parcialmente
0%
100 %
6) Considera algum ponto frágil no sistema ?
TABELA B.6 - PONTO FRÁGIL NO SISTEMA
Entrada
Edição
Análise
Saída
de dados
de dados
de dados
de dados
20%
30%
0%
30%
Documentação
20%
7) Com relação ao tempo de resposta considera o sistema eficiente ?
TABELA B.7 - EFICIÊNCIA DO SISTEMA
Proporcional ao tamanho da
Proporcional ao número de
área de trabalho
pessoas utilizando na rede
70%
30%
190
Outras
0%
8) Quais os pontos que considera mais forte no sistema ?
TABELA B.8 - PONTOS FORTES NO SISTEMA
Ambiente Integrado
Suporte técnico
Agilidade em relação ao SGI
50%
30%
20%
9) Conhece outros sistemas na mesma área? Quais?
TABELA B.9 - OUTROS SISTEMAS CONHECIDOS PELOS
ENTREVISTADOS
SGI/SITIM
IDRISI
ERDAS
ARC/INFO
ENVI
PCI
MGE
25%
25%
12.5%
12.5%
12.5%
12.5%
0%
A seguir é apresentada a tabulação das respostas obtidas no questionário
dado ao desenvolvedor*.
1) Qual a sua formação acadêmica?
TABELA. B.10 - FORMAÇÃO DOS ENTREVISTADOS
Engenheiro Eletrônico
Engenheiro
Bacharel em
(com mestrado em computação
Mecânico
Computação
30%
0%
Outros
aplicada)
70%
____________________________
(*) O questionário foi aplicado em um universo de 3 desenvolvedores
191
0%
2) Qual a sua responsabilidade dentro do projeto do sistema ?
TABELA B.11 - RESPONSABILIDADE DOS ENTREVISTADOS
Desenvolvimento de aplicação
Desenvolvimento de Arquitetura
em processamento de imagens
banco de dados
geral
33.3%
33.3%
33.4%
Outros
0%
3) Foi utilizada alguma metodologia de Engenharia de Software ? Qual ?
TABELA B.12 - UTILIZAÇÃO DE METODOLOGIA DE ENGENHARIA DE
SOFTWARE
Sim, em parte. A
Não como
Não. Houve muita
Utilização de
Utilização
concepção foi
ferramenta
informalidade. Sem
técnicas clássicas
do
orientada por
de trabalho
documentação de
como fluxo de
diagrama
objetos segundo a
especificação. Muita
dados e diagrama
entidade -
TMO.
documentação no
de estados como
relaciona-
código
rascunho
mento
17%
17%
17%
32%
17%
4) Existe algum modelo gerado por você ou sua equipe ? Se sim é possíve
fornecer ?
TABELA B.13 - GERAÇÃO E DISPONIBILIDADE DE MODELOS
SIM
NÃO
100%
0%
192
5) É possível validar o esboço do modelo conceitual do sistema em anexo ?
TABELA B.14 - VALIDAÇÃO DE MODELO EXISTENTE
SIM
NÃO
100%
0%
6) Conhece a estrutura da base de dados no qual o sistema se apoia ?
TABELA B.15 - CONHECIMENTO DA ESTRUTURA DE BASE DE DADOS
Muito Bem
Bem
Moderado
Desconhece
65%
0%
35%
0%
7) É possível validar estas estruturas de base de dados em anexo?
TABELA B.16 - VALIDAÇÃO DA ESTRUTURA DE BASE DE DADOS
EXISTENTE
SIM
NÃO
100%
0%
8) Considera o sistema eficaz, no sentido e atender os objetivos que se
propõe?
TABELA 17 - EFICÁCIA DO SISTEMA EM RELAÇÃO AO PROPÓSITO
Sim, quanto a ser um
Sim, quanto a ser um
ambiente integrado
ambiente monousuário
70%
30%
193
Outros
0%
9) Considera o sistema eficiente com relação ao tempo de resposta ?
TABELA B.18 - EFICIÊNCIA DO SISTEMA EM RELAÇÃO AO TEMPO DE
RESPOSTA
Sim, em parte. Para
Sim, em parte.
Sim, em
processamento de
Dependendo do volume
geral.
imagens, é proporcional
de dados a apresentação
ao tamanho da imagem.
na tela pode demorar.
30%
30%
10)
40%
Outros
0%
Gostaria de destacar algum ponto do sistema que mereceria maior
atenção?
TABELA B.19 - DESTAQUE DOS PONTOS QUE MERECEM MAIOR
ATENÇÃO
Maior rigor no
Ambiente
Maior disciplina na utilização
Controle de
Multiusuário
de uma metodologia de
versões
(controle de acesso
desenvolvimento de software
Outras
ao banco de dados)
20%
50%
30%
0%
Na Figura B.1 a seguir é mostrado o esboço do modelo conceitual do sistema
apresentado aos desenvolvedores para validação e ajustes.
A partir deste esboço chegou-se a um modelo mais fiel a realidade do sistema
que foi apresentado pelo Figura. 5.15
SPRING, no Capítulo 5.
194
- Modelo Orientado por Objetos do
BANCO DE DADOS
GEOGRAFICOS
PROJETO
CATEGORIA
SPROJECTION
DATUM
PLANO DE INFORMACAO
CAMPO
TEMATICO
MNT
OBJETOS
IMAGEM
REDE
CADASTRAL
REPRESENTACAO
VETORIAL
VISUAL
MATRIZ
Fig. B.1 - Esboço do modelo conceitual do sistema apresentado aos
desenvolvedores para validação e ajustes.
Na Figura B.2 a seguir é mostrado o esboço do modelo de dados, utilizando
um
diagrama
entidade
relacionamento,
para
representar
as
tabelas
implementadas no sistema SPRING. Este modelo foi apresentado aos
desenvolvedores para validação e ajustes.
195
1
PROJETO
1
1
n
n
n
PROJEÇÃO
n
1
1
n
1
INFOLAYER
n
n
DATUM
n
PROJECTIONS
1
n
1
1
1
CATEGORIA
n
VVISUAL
1
1
REPRESS
n
n
1
1
CATEGORIA
VVISUAL
1
INFOLAYER
1
n
1
n
GEOOBJETO
1
n
1
n
n
GEOANCHOR
Fig. B.2 - Esboço do modelo de dados que foi apresentado aos
desenvolvedores para validação e ajustes.
A partir da apresentação deste modelo e discussão sobre o mesmo, foi
possível
adquirir
um
maior
conhecimento
armazenamento de dados do SPRING.
196
sobre
as
estruturas
de