geovisual – um ambiente de consultas visuais para bancos

UNIVERSIDADE F EDERAL DE PERNAMBUCO
C ENTRO DE I NFORMÁTICA
P ÓS-G RADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
GEOV ISUAL – UM A MBIENTE DE
CONSULTAS V ISUAIS PARA BANCOS
DE
D ADOS GEOGRÁFICOS
Tese de Doutorado
Valéria Gonçalves Soares
Prof. Dra. Ana Carolina Salgado
(Orientadora)
Recife
Agosto de 2002
I
II
D EDICATÓRIA
Dedico este trabalho aos meus
queridos filhos, Caroline e Victor,
e a meu esposo, Glêdson, pelo
amor, compreensão e pelas vidas
compartilhadas.
III
A GRADECIMENTOS
A Deus, acima de tudo, pelo dom da vida.
À Prof. Ana Carolina, pela orientação criteriosa, infalível e, acima de tudo, amiga.
À Prof. Valéria Times, pela posição firme e fundamental ao bom andamento deste
trabalho.
Ao Prof. Gilberto Câmara, pela disponibilidade em compartilhar toda a sua riqueza
de informações e experiência.
Aos Profs. Fernando Fonseca, Juliano Oliveira e Carlos Ferraz, cujos comentários e
excelentes sugestões serviram para enriquecer este trabalho.
Ao Sílvio Cortez, cuja inteligência e dedicação foram imprescindíveis ao
desenvolvimento do protótipo final. Meu sincero muito obrigado.
Aos meus familiares e amigos, enfim, a todos aqueles que estiveram ao meu lado,
torcendo e apoiando este projeto, em especial aos meus pais, pela base e educação
recebidos, e à minha querida tia Nicinha, pelo carinho.
Às amigas: Thienne, por seu carinho, amizade e atenção; Soninha, pelo seu ombro
sempre firme em apoiar; e Maria, companheira constante dessa longa caminhada.
Ao meu marido, Glêdson, pela sua firmeza, compreensão e apoio, principalmente nos
últimos momentos dessa jornada. Devo a você essa conquista.
À Empresa de Pesquisa Agropecuária do Rio Grande do Norte, pelo suporte
financeiro e apoio à execução deste doutorado.
Ao CNPq, pelo suporte financeiro.
IV
RESUMO
Existem algumas dificuldades no projeto de linguagens de consultas para
Sistemas de Informações Geográficas, mais especificamente para Bancos
de Dados Geográficos - BDG, que são inerentes a estes tipos de dados.
Apesar de existirem, na literatura, algumas propostas de sistemas de
consultas visuais para SIG, o Sistema GeoVisual - Ambiente de Consultas
Visuais para Bancos de Dados Geográficos, se propõe a integrar duas
áreas de pesquisa - o paradigma de consultas visuais e padrões de
metadados espaciais - que têm sido pouco utilizadas em conjunto.
Inicialmente foi definida uma Arquitetura para o Sistema GeoVisual,
composta por módulos com funcionalidades específicas. Devido aos
dados geográficos serem inerentemente visuais, ou seja, serem
naturalmente associados a alguma representação gráfica, foi definida
uma Linguagem de Consulta Visual Geográfica, a GeoVisualQL. Esta
linguagem utiliza, em sua concepção, o modelo de dados do consórcio
Open GIS como também a sua especificação SQL. A GeoVisualQL foi
formalmente definida utilizando-se uma gramática apropriada para
linguagens visuais. O uso desta linguagem, por meio de uma interface
apropriada, permite ao usuário submeter uma consulta utilizando apenas
símbolos visuais, e obter o resultado da mesma, também de forma visual.
O Sistema GeoVisual, através de um processo de tradução, que utiliza
informações de metadados, converte a sentença de consulta visual para
uma sentença de consulta textual em SQL, e realiza a busca efetiva ao
banco de dados geográfico de forma transparente ao usuário. Foi
desenvolvido um protótipo do Sistema GeoVisual, utilizando o SGBD
Oracle, com dados de coordenadas geográficas de uma aplicação de
Hidrologia do estado do Rio Grande do Norte, Brasil.
Palavras-Chaves: Bancos de Dados Geográficos, Linguagem de Consulta
Visual, Metadados, Interface.
V
ABSTRACT
There are some difficulties in the design of Query Languages for
Geographic Information Systems, more specifically for Geographic
Databases, that are inherent to this kind of data. Although there are, in
the literature, some proposals for Visual Query Systems for GIS, the
GeoVisual System – An Environment for Visual Queries on Geographic
Databases, integrates two research areas (visual queries paradigm and
spatial metadata standards) that have been rarely used together.
Initially, we defined the GeoVisual System Architecture that consists of
modules with specific functionalities.
Since geographic data are
inherently visual, i.e, naturally associated with graphic representations,
we have defined a Visual Query Language for Geographic Data, namely
the GeoVisualQL. This language uses both the geodata model and the
SQL specification of the Open GIS Consortium. GeovisualQL was
formally defined using an appropriate grammar for visual languages.
The use of this language, by means of an adequate interface, allows
users to submit a query using only visual symbols, and to get results on
visual form too. The GeoVisual System, through a translation process
that uses metadata information, converts the visual query to a textual
SQL, and searches the geographic database in a way that is transparent
to the user. We have developed a GeoVisual Prototype System, using
the Oracle DBMS, with data from geographic coordinates of a
hydrology application of the State of Rio Grande do Norte,Braz il.
Keywords: Geographic Databases, Visual Query Languages, Metadata,
Interface.
VI
SUMÁRIO
ÍNDICE DE F IGURAS ...................................................................................................
XIV
ÍNDICE DE TABELAS ................................................................................................ XVIII
1 INTRODUÇÃO............................................................................................................
1
1.1 M OTIVAÇÃO ...............................................................................................
1
1.2 O BJETIVOS .................................................................................................. 2
1.3 ESTRUTURA DA TESE ................................................................................
4
2 MODELOS DE D ADOS EM SISTEMAS DE INFORMAÇÃO G EOGRÁFICA ......................
6
2.1 INTRODUÇÃO ............................................................................................
6
2.2 CARACTERIZAÇÃO DOS DADOS .................................................................
10
2.3 LINGUAGENS DE C ONSULTAS PARA BANCOS DE D ADOS GEOGRÁFICOS ...
12
2.3.1 LINGUAGENS TEXTUAIS ............................................................
12
2.3.2 LINGUAGENS V ISUAIS .................................................................
13
2.3.3 LINGUAGENS H ÍBRIDAS .............................................................
14
2.4 TIPOS DE REPRESENTAÇÃO .....................................................................
14
2.5 M ODELOS CONCEITUAIS E M ODELOS DE DADOS G EOGRÁFICOS ...........
16
2.6 O CONSÓRCIO OPEN GIS .......................................................................
19
2.6.1 ESPECIFICAÇÃO ABSTRATA OPEN GIS ....................................
21
2.6.2 HIERARQUIA DO MODELO OPEN GIS .....................................
25
2.6.3 CONSIDERAÇÕES FINAIS DA ESPECIFICAÇÃO O PEN GIS ................ 28
VII
2.7 PADRÕES DE M ETADADOS ESPACIAIS ......................................................... 29
2.7.1 O PADRÃO FGDC ......................................................................... 31
2.7.2 OUTRAS P ROPOSTAS .................................................................... 33
2.7.3 M ODELO A BSTRATO DE M ETADADOS OGC ................................
34
2.7.4 PERSPECTIVAS F UTURAS ............................................................... 36
2.8 CONCLUSÃO ...............................................................................................
36
3 LINGUAGENS DE C ONSULTAS ESPACIAIS E SISTEMAS DE C ONSULTAS VISUAIS ........
38
3.1 INTRODUÇÃO ............................................................................................
38
3.2 RELAÇÕES ENTRE O BJETOS ESPACIAIS ....................................................
39
3.2.1 RELAÇÕES TOPOLÓGICAS ENTRE O BJETOS ESPACIAIS .............
39
3.2.1.1 M ODELO DAS 9-INTERSEÇÕES ...................................
40
3.2.2 RELAÇÕES DIRECIONAIS ENTRE O BJETOS ESPACIAIS ..............
44
3.2.3 RELAÇÕES TEMPORA IS ENTRE OBJETOS ESPACIAIS ..................
47
3.3 PROPOSTAS DE EXTENSÃO DO PADRÃO SQL ...........................................
49
3.3.1 SPATIAL SQL ...............................................................................
50
3.3.2 ESPECIFICAÇÃO SQL DO MODELO OPEN GIS .............................. 51
3.3.4.1 M ÉTODOS BÁSICOS DA CLASSE G EOMETRIA ................
53
3.3.4.2 M ÉTODOS PARA TESTES DE RELAÇÕES ESPACIAIS
ENTRE OBJETOS GEOMÉTRICOS ................................
53
3.3.4.3 M ÉTODOS DE A NÁLISE ESPACIAL ................................
54
3.3.4.4 F UNÇÕES SQL ............................................................
54
3.3.4.5 EXEMPLOS DE C ONSULTAS .........................................
56
3.3.3 OUTRAS P ROPOSTAS ...................................................................
56
3.3.4 QUESTÕES DE APRESENTAÇÃO DOS RESULTADOS DAS C ONSULTAS 57
VIII
3.4 LINGUAGENS DE C ONSULTAS V ISUAIS ......................................................
58
3.4.1 SISTEMAS DE C ONSULTAS VISUAIS ..............................................
59
3.4.1.1 E STRATÉGIAS PARA ENTENDIMENTO DA
REALIDADE DE INTERESSE ...........................................
61
3.4.1.2 ESTRATÉGIAS PARA F ORMULAÇÃO DE CONSULTAS ........
62
3.4.1.3 ESTRATÉGIAS DE TESTE DA CONSULTA .........................
64
3.4.2 REPRESENTAÇÕES V ISUAIS ........................................................... 65
3.4.2.1 REPRESENTAÇÕES V ISUAIS DA C ONSULTA ...................... 65
3.4.2.2 REPRESENTAÇÕES V ISUAIS DOS RESULTADOS DAS
C ONSULTAS ..................................................................
66
3.5 FORMALISMOS V ISUAIS E GRAMÁTICAS ....................................................... 67
3.5.1 FORMALISMOS DE ESPECIFICAÇÃO G RAMATICAL .......................... 68
3.5.2 ESPECIFICAÇÃO DE SINTAXE DE LINGUAGENS VISUAIS ............... 69
3.5.3 ESPECIFICAÇÃO DE F IGURAS B ASEADAS EM GRAMÁTICAS ............ 71
3.5.4 P ICTURE LAYOUT GRAMMARS – PLG ..........................................
71
3.6 USO DE LINGUAGENS DE CONSULTAS V ISUAIS EM SIG ............................
76
3.7 CONCLUSÃO .............................................................................................
77
4 SISTEMAS DE C ONSULTAS V ISUAIS PARA SIG .........................................................
78
4.1 INTRODUÇÃO ...........................................................................................
78
4.2 UMA LINGUAGEM DE CONSULTA V ISUAL PARA SIG: CIGALES ................
79
4.2.1 CARACTERIZANDO CIGALES .................................................
79
4.2.2 A LINGUAGEM DE C ONSULTA .....................................................
80
4.2.3 INTERFACE GRÁFICA DO CIGALES ...........................................
81
4.2.3.1 EXEMPLO DE UMA C ONSULTA UTILIZANDO A INTERFACE ......
84
4.2.4 D ETALHES DE IMPLEMENTAÇÃO .............................................
85
IX
4.2.5 A VALIANDO CIGALES ..................................................................
85
4.3 LVIS ........................................................................................................
85
4.3.1 CARACTERIZANDO LVIS ...........................................................
85
4.3.2 A LINGUAGEM DE C ONSULTA LVIS .........................................
86
4.3.3 A INTERFACE G RÁFICA LVIS .................................................
87
4.3.4 A VALIANDO LVIS ........................................................................ 88
4.4 VISCO .......................................................................................................
89
4.4.1 CARACTERIZANDO VISCO ..........................................................
89
4.4.2 A LINGUAGEM DE C ONSULTA ...................................................... 89
4.4.3 A INTERFACE G RÁFICA DO VISCO .............................................
91
4.4.4 A VALIANDO VISCO .....................................................................
94
4.5 SKETCH!....................................................................................................... 94
4.5.1 CARACTERIZANDO SKETCH! ......................................................... 95
4.5.2 A LINGUAGEM DE C ONSULTA ....................................................... 95
4.5.3 A INTERFACE SKETCH! ................................................................. 97
4.5.4 A VALIANDO SKETCH ! ..................................................................... 99
4.6. SPATIAL-QUERY -B Y -SKETCH ...................................................................... 100
4.6.1 C ARACTERIZANDO O SPATIAL-Q UERY-B Y -SKETCH ....................... 100
4.6.2 A LINGUAGEM DE C ONSULTA ....................................................... 101
4.6.3 A INTERFACE SPATIAL-Q UERY -BY -SKETCH ................................. 104
4.6.4 A VALIANDO SPATIAL-QUERY -B Y-SKETCH .................................. 105
4.7 OUTRAS P ROPOSTAS ................................................................................... 105
4.8 ANÁLISE C OMPARATIVA DAS PROPOSTAS DE INTERFACES DE CONSULTAS
V ISUAIS PARA SIG .......................................................................................
107
4.9 CONCLUSÃO ...............................................................................................
109
X
5 C ONSULTAS V ISUAIS EM BDG BASEADAS EM METADADOS ESPACIAIS .....................
110
5.1 INTRODUÇÃO ...........................................................................................
110
5.2 SISTEMA G EOV ISUAL ................................................................................
111
5.2.1 A RQUITETURA DO SISTEMA G EOV ISUAL ....................................
111
5.2.1.1 M ÓDULO DO SGBD ......................................................
111
5.2.1.2 M ÓDULO DO MODELO DE METADADOS ......................
112
5.2.1.3 M ÓDULO GERENCIADOR DE C ONSULTAS ...................
113
5.2.1.4 M ÓDULO DA INTERFACE G RÁFICA .............................
114
5.3 ESCOPO DO TRABALHO .........................................................................
114
5.4 REPRESENTAÇÕES V ISUAIS DO SISTEMA GEOVISUAL ..............................
115
5.4.1 UTILIZANDO OS PADRÕES DE METADADOS ..............................
117
5.4.2 EXEMPLO DE USO DO PADRÃO FGDC E DO M ODELO OGC EM
UMA A PLICAÇÃO DE HIDROLOGIA ................................................ 117
5.5 D EFININDO A LINGUAGEM DE CONSULTA V ISUAL - G EOV ISUALQL .......... 118
5.5.1 ESPECIFICAÇÃO DA G EOV ISUALQL ............................................... 120
5.5.1.1 O PERAÇÕES SOBRE F EIÇÕES G EOGRÁFICAS .................... 122
5.5.1.2 G EOMETRIAS DOS OBJETOS PICTÓRICOS ......................... 124
5.5.1.2 RELACIONAMENTOS D EFINIDOS PELO M ODELO 9 IM
ENTRE AS G EOMETRIAS:
PONTO, L INHA E P OLÍGONO ... 124
5.5.2 RELACIONAMENTOS ESPACIAIS DA LINGUAGEM G EOV ISUALQL ... 128
5.5.2.1 RELACIONAMENTOS ESPACIAIS VISUAIS DE TOPOLOGIA
B ASEADOS NA SQL DO OGC ........................................... 129
5.5.2.2 A CRESCENTANDO NOVOS OPERADORES DE TOPOLOGIA 138
5.5.2.3 RELACIONAMENTOS ESPACIAIS VISUAIS DE C ONJUNTOS
B ASEADOS NA SQL DO OGC ........................................... 141
XI
5.5.3 GRAMÁTICA DA LINGUAGEM G EOV ISUALQL ................................ 155
5.6 ESPECIFICAÇÃO DO USO DOS M ETADADOS ................................................
156
5.7 G ERAÇÃO DA SENTENÇA SQL ..................................................................... 157
5.7.1
GERAÇÃO DE SENTENÇAS SQL UTILIZANDO OS OPERADORES
TOPOLÓGICOS D EFINIDOS PELA LINGUAGEM BASE ..................... 157
5.7.2 GERAÇÃO DE SENTENÇAS SQL UTILIZANDO AS EXTENSÕES DOS
O PERADORES TOPOLÓGICOS .......................................................
5.7.3
158
GERAÇÃO DE SENTENÇAS SQL UTILIZANDO O PERADORES DE
CONJUNTOS .............................................................................
159
5.8
P ROCESSO DE TRADUÇÃO DA C ONSULTA VISUAL ................................. 160
5.9
A NÁLISE C OMPARATIVA DOS SISTEMAS DE CONSULTAS V ISUAIS PARA SIG
E O SISTEMA GEOVISUAL .....................................................................
5.10 CONCLUSÃO .........................................................................................
163
165
6 IMPLEMENTAÇÃO DO SISTEMA G EOV ISUAL .............................................................. 166
6.1 INTRODUÇÃO .............................................................................................. 166
6.2 OBJETOS P ICTÓRICOS DA APLICAÇÃO DE RECURSOS H ÍDRICOS .................. 168
6.3 INTERFACE GEOVISUAL ............................................................................. 168
6.3.1 D ETALHES DE IMPLEMENTAÇÃO .................................................
170
6.3.2 A DAPTAÇÃO AO ORACLE 9 I ........................................................... 171
6.3.2.1 TIPO G EOMETRIA DO ORACLE E SEUS MÉTODOS ..........
171
6.4 M ODELAGEM DA A PLICAÇÃO ...................................................................... 173
6.4.1 UTILIZANDO OS METADADOS ......................................................
175
6.4.2 EXEMPLOS DE SENTENÇAS SQL G ERADAS .................................
177
6.5 CONSIDERAÇÕES SOBRE GML.................................................................
178
6.6 EXEMPLO DE UTILIZAÇÃO DA GEOVISUALQL ...........................................
178
XII
6.6.1 SENTENÇA SQL EQUIVALENTE ..................................................
180
6.6.2 RESULTADO DA C ONSULTA .........................................................
180
6.7 ANÁLISE C RÍTICA DO PROTÓTIPO G EOV ISUAL .........................................
181
6.8 CONCLUSÃO ..............................................................................................
182
7 C ONTRIBUIÇÕES E TRABALHOS FUTUROS ...............................................................
183
7.1 INTRODUÇÃO .............................................................................................. 183
7.2 CONTRIBUIÇÃO DO TRABALHO .................................................................. 184
7.3 TRABALHOS FUTUROS ...............................................................................
184
7.4 CONCLUSÃO ............................................................................................
185
A EXEMPLO DE DESCRIÇÃO DOS M ETADADOS DE H IDROLOGIA PELO PADRÃO DE
FGDC..................................................................................................................
186
B DEFINIÇÃO DA GRAMÁTICA DE G EOV ISUALQL ....................................................... 192
C TRADUÇÃO DA LINGUAGEM G EOV ISUALQL PARA SQL ..........................................
197
D DESCRIÇÃO DO ESQUEMA DE BANCO DE DADOS DA A PLICAÇÃO DE HIDROLOGIA NO
SGBD O RACLE 9 I ..........................................................................................
203
E DESCRIÇÃO DAS F EIÇÕES G EOGRÁFICAS DE HIDROLOGIA EM XML .................
206
REFERÊNCIAS B IBLIOGRÁFICAS ................................................................................... 217
XIII
Í NDICE DE FIGURAS
F IGURA 2.1 – REFERÊNCIAS G EOGRÁFICAS .................................................................. 7
F IGURA 2.2 – C OMPONENTES DE SOFTWARE DE UM SIG ............................................ 9
F IGURA 2.3 – C OMPONENTES DE UM BANCO DE DADOS GEOGRÁFICO ....................... 9
F IGURA 2.4 – REPRESENTAÇÃO MATRICIAL E V ETORIAL ............................................ 15
F IGURA 2.5 - TECNOLOGIA O PEN GIS ......................................................................
21
F IGURA 2.6 – H IERARQUIA DE C LASSES G EOMÉTRICAS .............................................
26
F IGURA 2.7 - ELEMENTOS DE DADOS DO PADRÃO FGDC ........................................
32
F IGURA 3.1 - D IFERENTES CRUZAMENTOS ENTRE LINHA E P OLÍGONO...................
40
F IGURA 3.2 - A MATRIZ 3X3 DAS 9-INTERSEÇÕES .....................................................
41
F IGURA 3.3 - REPRESENTAÇÃO GEOMÉTRICA DAS 19 INTERSEÇÕES P OSSÍVEIS ENTRE
UMA LINHA E UMA REGIÃO ATRAVÉS DO MÉTODO DA MATRIZ DAS
9-INTERSEÇÕES ..................................................................................
43
F IGURA 3.4 – C ONCORDÂNCIA EM QUE A RODOVIA CRUZA O PARQUE ..................
44
F IGURA 3.5 – PARTIÇÕES AO REDOR DE UM O BJETO DE REFERÊNCIA A .................
46
F IGURA 3.6 – (A ) EXISTÊNCIA DE UM OBJETO A; (B ) N ÃO-EXISTÊNCIA DE UM O BJETO,
SEM HISTÓRIA ; ( C) N ÂO-EXISTÊNCIA DE UM OBJETO A, COM H ISTÓRIA.....
48
F IGURA 3.7 – TRANSIÇÃO ENTRE D OIS ESTADOS DE IDENTIDADE DE UM OBJETO ...... 49
F IGURA 3.8 - UM SISTEMA DE P ROGRAMAÇÃO VISUAL COM ANALISADOR ESPACIAL. 70
XIV
F IGURA 3.9 - UMA F IGURA SIMPLES ............................................................................ 72
F IGURA 3.10 - RESTRIÇÕES DE UMA LINGUAGEM D EFINIDAS PELO USUÁRIO ............. 74
F IGURA 3.11 – UMA LINGUAGEM USANDO ATRIBUTOS A DICIONAIS ............................. 75
F IGURA 4.1 – INTERFACE GRÁFICA DO C IGALES ......................................................... 82
F IGURA 4.2 – D ESCRIÇÃO DE UM BALÃO E UMA ÂNCORA EM LVIS ............................. 86
F IGURA 4.3 – INTERFACE DA LINGUAGEM LVIS ........................................................... 87
F IGURA 4.4 – TRADUÇÃO DA LINGUAGEM LVIS PARA A LINGUAGEM SIG DESTINO ... 88
F IGURA 4.5 - V ISUALIZADOR DE MAPA ........................................................................ 92
F IGURA 4.6 – EDITOR GRÁFICO DE C ONSULTAS ........................................................... 93
F IGURA 4.7 - EXEMPLO DE UM DESENHO ESPACIAL ................................................... 94
F IGURA 4.8 – EXEMPLO DE CONSULTA NA INTERFACE DO SKETCH! .......................... 98
F IGURA 4.9 – ESQUEMA DE PROCESSAMENTO DE UMA C ONSULTA EM SPATIAL-Q UERY BY - SKECTH ................................................................................................
103
F IGURA 4.10 - SPATIAL-Q UERY -BY -SKETCH ................................................................. 104
F IGURA 5.1 – ARQUITETURA DO SISTEMA GEOVISUAL ……………………………….. 112
F IGURA 5.2 - G ERENCIADOR DE C ONSULTAS ............................................................. 113
F IGURA 5.3 - H IERARQUIA DE C LASSES G EOMÉTRICAS ............................................... 116
F IGURA 5.4 – SÍMBOLOS V ISUAIS BÁSICOS DA LINGUAGEM G EOV ISUALQL ................ 116
F IGURA 5.5 – D ESCRIÇÃO DE M ETADADOS DA FEIÇÃO G EOGRÁFICA B ACIA
HIDROGRÁFICA ....................................................................................... 118
F IGURA 5.6 – LINGUAGEM DE C ONSULTA VISUAL G EOGRÁFICA – G EOV ISUALQL ...... 120
F IGURA 5.7 – EXEMPLO DE OPERAÇÃO DE SELEÇÃO ESPACIAL .................................. 123
F IGURA 5.8 – RELACIONAMENTOS P OSSÍVEIS ENTRE D OIS P ONTOS .........................
125
F IGURA 5.9 – RELACIONAMENTOS P OSSÍVEIS ENTRE UM PONTO E UMA LINHA .....
125
F IGURA 5.10 – RELACIONAMENTOS P OSSÍVEIS ENTRE UM P ONTO E UMA REGIÃO ...
126
XV
F IGURA 5.11 – RELACIONAMENTOS P OSSÍVEIS ENTRE D UAS LINHAS .....................
126
F IGURA 5.12 – RELACIONAMENTOS P OSSÍVEIS ENTRE UMA LINHA E UMA REGIÃO ...
127
F IGURA 5.13 – RELACIONAMENTOS P OSSÍVEIS ENTRE D UAS REGIÕES .....................
127
F IGURA 5.14 – REPRESENTAÇÃO VISUAL DOS O PERADORES A DICIONAIS DA
G EOV ISUALQL...................................................................................... 128
F IGURA 5.15 – REPRESENTAÇÃO DE CONSULTAS V ISUAIS VÁLIDAS USANDO
O OPERADOR EQUALS.........................................................................
130
F IGURA 5.16 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS COM O OPERADOR
DISJOINT ........................................................................................... 131
F IGURA 5.17 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS USANDO O O PERADOR
TOUCHES ........................................................................................... 132
F IGURA 5.18 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS USANDO O O PERADOR
WITHIN .............................................................................................
133
F IGURA 5.19 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS USANDO O O PERADOR
OVERLAPS .......................................................................................
134
F IGURA 5.20 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS ENVOLVENDO
O OPERADOR CROSSES
...................................................................... 135
F IGURA 5.21 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS QUE USAM O
O OPERADOR ESPACIAL INTERSECTS.............................................
136
F IGURA 5.22 – REPRESENTAÇÃO DE CONSULTAS VÁLIDAS QUE UTILIZAM O
O PERADOR CONTAINS ..................................................................
137
F IGURA 5.23 – C ONSULTA VISUAL VÁLIDA QUE UTILIZA O O PERADOR CROTHIN ....
139
F IGURA 5.24 – C ONSULTA VISUAL VÁLIDA QUE UTILIZA O O PERADOR CROCHES ....
140
F IGURA 5.25 – C ONSULTA VISUAL VÁLIDA QUE UTILIZA O O PERADOR CROSSOUT...
140
F IGURA 5.26 – C ONSULTA VISUAL VÁLIDA QUE UTILIZA O O PERADOR CROSSECTS .... 141
XVI
F IGURA 5.27 - REPRESENTAÇÃO DE CONSULTAS V ISUAIS QUE UTILIZAM O
O PERADOR INTERSECTION ..........................................................
145
F IGURA 5.28 – REPRESENTAÇÃO DE CONSULTAS V ISUAIS QUE UTILIZAM O
O PERADOR DIFFERENCE .........................................................
151
F IGURA 5.29 – REPRESENTAÇÃO DE CONSULTAS V ISUAIS QUE UTILIZAM
O OPERADOR UNION .......................................................................
154
F IGURA 5.30 - P OSSÍVEL C ONSULTA VISUAL V ÁLIDA EQUIVALENTE À DEFINIÇÃO DE
USO DO OPERADOR NOT PELA GRAMÁTICA DA GEOVISUALQL
........
156
F IGURA 5.31 – Á RVORES SINTÁTICAS LOGIC-C LAUSES EM G EOVISUALQL ...............
160
F IGURA 5.32 – Á RVORES SINTÀTICAS DAS QUERY _CLAUSES EM G EOV ISUALQL ......
161
F IGURA 5.33 – Á RVORES SINTÁTICAS DE SET_QUERY_CLAUSES EM G EOV ISUALQL .. 161
F IGURA 5.34 – TIPOS DE G EOMETRIAS ACEITOS NAS C LÁUSULAS DE C ONSULTA
G EOV ISUALQL.....................................................................................
161
F IGURA 5.35 – EXEMPLO DE UMA C ONSULTA V ISUAL VÁLIDA ...................................
162
F IGURA 5.36 – Á RVORE SINTÁTICA EQUIVALENTE DA C ONSULTA REPRESENTADA NA
F IGURA 5.34 ........................................................................................
162
F IGURA 5.37 – EXEMPLO DE UMA C ONSULTA VÁLIDA COM O OPERADOR CROTHIN .. 163
F IGURA 6.1 - INTERFACE G EOV ISUAL – JANELA P RINCIPAL ........................................ 169
F IGURA 6.2 – JANELA DA APLICAÇÃO ........................................................................... 170
F IGURA 6.3 – JANELA DE A PRESENTAÇÃO ................................................................... 170
F IGURA 6.4 – RELACIONAMENTOS TOPOLÓGICOS DO O RACLE SPATIAL 9I ................
171
F IGURA 6.5 – EXEMPLO DE UMA CONSULTA V ISUAL VÁLIDA ....................................
179
F IGURA 6.6 – RESULTADO DA C ONSULTA VISUAL .....................................................
181
XVII
Í NDICE DE TABELAS
TABELA 4.1 – A NÁLISE C OMPARATIVA DE SISTEMAS DE C ONSULTAS V ISUAIS PARA SIG.109
TABELA 5.1 – C ARACTERIZANDO O G EOV ISUAL .......................................................... 164
TABELA 5.2 – A NÁLISE C OMPARATIVA DE GEOVISUAL COM D EMAIS TRABALHOS ....... 164
TABELA 6.1 – O BJETOS P ICTÓRICOS DE RECURSOS HÍDRICOS .................................... 167
TABELA 6.2 – TABELA DE BACIAS H IDROGRÁFICAS ..................................................... 174
TABELA 6.3 – TABELA DE MUNICÍPIOS ........................................................................ 174
TABELA 6.4 – TABELA DE AÇUDES ..............................................................................
174
XVIII
Capítulo 1 - Introdução
________________________________________________________________________________________________
CAPÍTULO 1
INTRODUÇÃO
“O espinho é da essência da rosa, como o
sofrimento é da essência da vida”.
(Dom Helder Câmara)
1.1 MOTIVAÇÃO
A área de Sistemas de Informação Geográfica (SIG) é objeto ainda de muitas pesquisas e
esforços no desenvolvimento de novas tecnologias para melhorar seu uso efetivo,
principalmente no que diz respeito ao projeto de linguagens de consultas [Oli97, OM96,
OGM97, OPM97, Mey92a, CCH+96, DeM97, WH98].
Existem algumas dificuldades adicionais no projeto de linguagens de consultas para
SIG, mais especificamente para Bancos de Dados Geográficos - BDG, que são inerentes a
estes tipos de dados. Por exemplo, a apresentação dos resultados das consultas se torna mais
complexa, pois pode envolver a transformação de informações alfanuméricas em estruturas
gráficas apropriadas para a produção de resultados cartográficos.
Um aspecto importante a ser considerado no projeto de BDG é a necessidade de uma
linguagem de consulta visual que permita que os usuários possam pensar graficamente
enquanto formulam suas consultas. A maioria dos SIG atuais é capaz de gerar representações
____________________________________________________________________________________
1
Capítulo 1 - Introdução
________________________________________________________________________________________________
gráficas para obtenção dos resultados das consultas, mas apenas poucos deles suportam
consultas visuais [Me y92a].
É muito difícil para um usuário típico de SIG formular consultas utilizando operadores
espaciais complexos e suas entidades relacionadas de forma textual.
As sentenças de
consultas em linguagens baseadas em SQL, por exemplo, têm como característica o número
excessivo de cláusulas, geralmente confusas, para simular operações geográficas eficientes.
Com o uso de Linguagens de Consultas Visuais (LCV) essa dificuldade pode ser reduzida.
Este tipo de linguagem de consulta trabalha com elementos pictóricos que objetivam facilitar
a formulação das consultas. Este paradigma é abordado no Capítulo 3 dessa tese.
A aquisição, o processamento e o compartilhamento de dados geográficos em SIG
apresentam-se como problemas críticos de uso do mesmo. Isto se deve principalmente ao fato
dos SIG serem em geral sistemas monolíticos, fechados, de uso restrito, que impedem o
compartilhamento dos seus dados com outros SIG [Per00]. Com o objetivo de adquirir,
processar, armazenar e distribuir informações geográficas de modo a alcançar uma grande
variedade de usuários, diversos padrões de metadados espaciais vêm sendo desenvolvidos.
Estes padrões se propõem a unificar a descrição dos dados geográficos para facilitar o
compartilhamento dos mesmos por diversas aplicações. Metadados espaciais são, na verdade,
informações sobre os dados espaciais e os padrões se propõem a formatar a maneira de
descrevê-los [FGD99, SDT99, ISO99, ESM98]. Estes padrões estão descritos em [Soa01].
Considerando as vantagens de linguagens de consultas vi suais em bancos de dados
geográficos, e visto que os padrões de metadados se propõem a facilitar a interação entre SIG
e o compartilhamento dos dados entre os mesmos, este trabalho se propõe a unir essas duas
tecnologias com um objetivo principal: facilitar a busca de informações em bancos de dados
geográficos através de uma linguagem de consulta visual, independente de aplicação, baseada
no padrão Open GIS [OGC99a].
1.2 OBJETIVOS
Este trabalho utiliza Padrões de Metadados Espaciais [MSD99, FGD99] e uma Linguagem de
Consulta Espacial para a definição de uma Linguagem de Consulta Visual - GeoVisualQL,
para resolver alguns problemas típicos da interface com o usuário, como também melhorar a
visualização e a integração dos dados.
____________________________________________________________________________________
2
Capítulo 1 - Introdução
________________________________________________________________________________________________
Alguns símbolos visuais básicos são definidos e utilizados na interface do sistema.
Símbolos específicos de entidades geográficas, dependentes das aplicações, também são
permitidos e aceitos na linguagem. A Linguagem Geográfica de Consultas Visuais,
GeoVisualQL (Geographic Visual Query Language) é definida baseada em símbolos visuais e
operadores espaciais. Esta linguagem é sintaticamente definida para suportar as principais
estruturas de uma Linguagem de Consulta Espacial baseada em uma extensão do padrão
SQL, que será apresentada no decorrer desta tese.
A Linguagem de Consulta Visual permitirá que os usuários não necessitem se preocupar
com os detalhes das estruturas internas do Banco de Dados Geográfico nem com as
Linguagens de Consultas Espaciais. A arquitetura do sistema proposto permite não apenas
consultas visuais pela manipulação direta de símbolos visuais básicos da linguagem em sua
interface, mas também que os usuários utilizem símbolos visuais específicos de determinadas
aplicações de modo a ser possível conhecer as informações disponíveis das mesmas.
Desta forma, através do uso da linguagem de consulta visual GeoVisualQL na interface,
o usuário poderá consultar um banco de dados geográfico, sem necessitar se preocupar com a
sintaxe da linguagem específica para o mesmo. A gramática desta linguagem visual está
formalmente definida, bem como os seus operadores e a sua forma de tradução para a
linguagem SQL que foi tomada como base.
Apesar de existirem, na literatura, algumas propostas de sistemas de consultas visuais
para SIG [CM91, Mey92a, BE00], estas duas áreas de pesquisa – o paradigma de consultas
visuais e os padrões de metadados espaciais - têm sido pouco utilizadas em conjunto. As
propostas existentes não utilizam o padrão Open GIS [OGC99a] como base de seu modelo
de dados, nem a especificação SQL deste mesmo consórcio. Além disso, o fato de utilizarmos
padrões de metadados para a descrição dos dados, também de forma visual, torna o Sistema
GeoVisual inovador e adaptável a novas aplicações.
Alguns problemas que o Sistema GeoVisual se propõe a resolver são:
1. Dificuldade de elaboração de sentenças de consultas espaciais nas Linguagens de
Consultas, baseadas em SQL, existentes para este tipo de dados. Geralmente essas
linguagens são compostas de construções sintáticas muito complexas que, muitas
vezes, confundem os usuários [Ege92, Mey92a, WH98].
____________________________________________________________________________________
3
Capítulo 1 - Introdução
________________________________________________________________________________________________
Uma linguagem de consulta visual está disponível na interface contendo os símbolos
visuais representativos básicos das geometrias ponto, linha e polígono, além de
operadores espaciais da linguagem. Como informações geográficas são inerentemente
visuais, ou seja, podem ser facilmente associadas a uma representação gráfica que se
aproxima do formato geométrico das entidades geográficas modeladas, o uso de uma
linguagem de consulta visual, neste tipo de banco de dados, se torna bastante
intuitivo. A construção das sentenças SQL para a efetiva consulta ao banco de dados
geográfico faz parte de um dos objetivos deste trabalho e é realizada de forma
transparente aos usuários.
2. Os BDG, em geral, não dispõem de informações descritivas sobre o seu conteúdo em
suas interfaces, nem de mecanismos que as disponibilizem.
Informações de metadados espaciais estão disponíveis visualmente na interface,
tomando como base o Padrão de Metadados Espaciais FGDC [FGD99], onde as
feições geográficas são associadas aos símbolos visuais que são definidos pelo
projetista de cada aplicação.
1.3 ESTRUTURA DA TESE
A estrutura desta tese apresenta o estado da arte de algumas tecnologias envolvidas e mostra
as metodologias utilizadas na definição do Sistema de Consultas Visuais para Bancos de
Dados Geográficos, GeoVisual, estando organizada como segue:
No Capítulo 2 – Modelos de Dados em Sistemas de Informação Geográfica, os
conceitos básicos de SIG são apresentados, como também alguns modelos de dados
geográficos e padrões de metadados existentes na literatura.
No Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais,
algumas linguagens de consultas espaciais propostas na literatura são descritas e algumas
características dos Sistemas de Consultas Visuais são apresentadas.
No Capítulo 4 – Sistemas de Consultas Visuais para SIG, são abordados alguns
trabalhos existentes na literatura que juntam as tecnologias de sistemas de Consultas Visuais e
SIG.
No Capítulo 5 - Consultas Visuais em BDG baseadas em Metadados Espaciais, o
____________________________________________________________________________________
4
Capítulo 1 - Introdução
________________________________________________________________________________________________
sistema GeoVisual é apresentado, com a sua arquitetura e suas funcionalidades, como
também a linguagem de consulta visual.
No Capítulo 6 – Implementação do Sistema GeoVisual, é apresentado o protótipo do
Sistema GeoVisual, suas definições e características de projeto, e uma aplicação do uso do
mesmo em um estudo de caso de Recursos Hídricos.
No Capítulo 7 – Contribuições e Trabalhos Futuros, são apresentadas as conclusões
do trabalho desenvolvido.
____________________________________________________________________________________
5
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
CAPÍTULO 2
MODELOS DE DADOS EM
SISTEMAS DE I NFORMAÇÃO GEOGRÁFICA
“Se não houver frutos, valeu a beleza das flores, Se
não houver flores, valeu a sombra das folhas, Se não
houver folhas, valeu a intenção da semente”.
Henfil
2.1 I NTRODUÇÃO
Sistemas de Informação Geográfica - SIG - são usados para armazenar, analisar e manipular
dados geográficos. São sistemas automatizados que comportam diferentes tipos de dados e
aplicações, em várias áreas de conhecimento. São utilizados para otimização de tráfego,
controles cadastrais, gerenciamento de serviços de utilidade pública, levantamento
demográfico,
sistema
de
cartografia
digital,
administração
de
recursos
naturais,
monitoramento costeiro, controle de epidemias, planejamento urbano, entre outras
aplicações.
O termo “dado espacial” denota qualquer tipo de dado que descreva fenômenos aos
quais esteja associada alguma dimensão espacial como, por exemplo, estruturas moleculares
de um composto químico. Quando esta dimensão espacial é a superfície terrestre, tem-se um
tipo especial de dados espaciais: os dados geo-referenciados ou dados geográficos.
______________________________________________________________________________________
6
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Dados geográficos representam objetos ou fenômenos cuja localização geográfica é uma
característica essencial à informação e indispensável à sua análise.
Uma definição básica de SIG considera-os como conjuntos poderosos de ferramentas
para coletar, armazenar, recuperar, transformar e disponibilizar dados espaciais do mundo
real para um conjunto particular de interesses. SIG armazenam informações sobre o mundo
real como um conjunto de camadas que podem ser utilizadas juntas pela Geografia
[HGW99], como ilustrado na Figura 2.1. Informações geográficas podem conter tanto uma
referência geográfica explícita, tal como latitude e longitude, como também uma referência
implícita, tal como um endereço, código postal, identificador de floresta, nome de uma
estrada, etc. Um processo de geo-codificação [HGW99] é usado para criar referências
geográficas explícitas a partir de referências implícitas.
Clientes
Edifícios
Ruas
Mundo Real
Figura 2.1 – Referências Geográficas [HGW99]
Além desta definição que considera SIG dentro de uma visão de ferramenta, existem
outras definições que classificam SIG baseados no enfoque de banco de dados ou de
organização [BM98]. Uma definição baseada no enfoque de banco de dados trata SIG como
um banco de dados no qual a maioria de seus dados está indexada espacialmente, e para o
qual especifica-se um conjunto de procedimentos de modo a responder consultas a respeito
das entidades espaciais envolvidas. Numa definição pelo enfoque de organização, considera-
______________________________________________________________________________________
7
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
se SIG como um conjunto automatizado de funções que provêem aos profissionais
capacidades avançadas de armazenar, recuperar, manipular e disponibilizar dados
geograficamente localizados.
As definições de SIG [Cam95] refletem, cada uma à sua maneira, a multiplicidade de
usos e visões possíveis a partir desta tecnologia e apontam para uma perspectiva
interdisciplinar de sua utilização. A partir de diferentes conceitos, identificam-se duas
importantes características dos SIG. A primeira delas é que os mesmos possibilitam a
integração, numa mesma base de dados, de informações geográficas de diversas fontes. A
segunda delas é que SIG oferecem mecanismos para recuperar, manipular, e visualizar estes
tipos de dados, através de algoritmos específicos de manipulação e análise.
Sistemas de Informação Geográfica possuem três componentes principais: hardware,
conjunto de softwares aplicativos e um contexto organizacional apropriado incluindo pessoal
capacitado. O hardware de um SIG é composto do computador com sua capacidade de
armazenamento para os dados e programas; uma mesa digitalizadora ou um scanner, usados
para converter mapas e documentos na forma a serem usados pelos programas aplicativos; e
um plotter ou impressora ou algum tipo de dispositivo de saída usado para apresentar o
resultado do processamento dos dados.
O Software de SIG pode ser dividido em 5 componentes funcionais [BM98]:
•
Entrada de Dados e Verificação;
•
Armazenamento de Dados e Gerenciamento de Banco de Dados;
•
Saída de Dados e Apresentação;
•
Transformação dos Dados;
•
Interface com o usuário.
______________________________________________________________________________________
8
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Entrada
Entrada
de
de
Dados
Dados
Interface
Interface
com
comoo
Usuário
Usuário
Banco
Banco de
de
Dados
Dados
Geográfico
Geográfico
Apresentação
Apresentação
ee
Relatórios
Relatórios
Transformação
Transformação
Figura 2.2 – Componentes de software de SIG [BM98]
A entrada de dados [BM98] (Figura 2.2) diz respeito a aspectos da captura dos dados
espaciais de mapas existentes, campos de observação, e sensores e à conversão deles em uma
forma digital. O armazenamento dos dados e o gerenciamento do banco de dados (Figura
2.3) se referem à localização dos dados, às ligações entre os mesmos (topologia), e como os
atributos dos elementos geográficos estão estruturados e organizados.
Banco de Dados
Banco de Dados Geográfico
Localização
Topologia
Atributos
Sistema de Gerenciamento
Figura 2.3 – Componentes de um Banco de Dados Geográfico [BM98]
A saída de dados e a apresentação se referem à maneira pela qual os dados são
disponibilizados e como os resultados das análises são informados aos usuários. Os dados
podem ser apresentados através de mapas, tabelas ou figuras.
______________________________________________________________________________________
9
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
A transformação dos dados envolve duas classes de operações básicas: (a)
transformações necessárias para remover os erros dos dados, atualizar estes dados ou adaptálos a outros conjuntos de dados; (b) conjunto vasto de métodos de análise que podem ser
aplicados aos dados de modo a alcançar as respostas das consultas realizadas ao SIG. Muitas
destas transformações, tais como mudança de escala, novas projeções com os dados,
recuperação lógica dos dados e cálculo de áreas e perímetros são, de tal forma, intrínsecas aos
SIG, que se pode encontrá-las na maioria deles.
Este capítulo tem como objetivo apresentar as característ icas básicas dos SIG, bem
como informações sobre os dados manipulados pelos mesmos, noções básicas sobre os
modelos de dados utilizados, além de diferenciar os tipos de linguagens de consultas
existentes para dados espaciais.
2.2
Caracterização dos Dados
Os dados geográficos representam fenômenos do mundo real em termos de sua posição com
respeito a um dado sistema de coordenadas; seus atributos não espaciais, tais como cor,
custo, pH; e as inter-relações entre estes fenômenos que descrevem como os mesmos estão
ligados. Um exemplo de inter-relação conhecida é a topologia que descreve o espaço e as suas
propriedades espaciais, tais como conectividade [BM98].
Os dados geográficos são caracterizados por apresentarem quatro componentes
fundamentais: característica não-espacial; característica espacial; característica temporal e
característica gráfica.
A sua característica não-espacial representa os atributos textuais do fenômeno
correspondente, ou seja, informações que caracterizam o dado, como nome e atributos
específicos do mesmo. Em relação à característica espacial, temos a localização espacial
propriamente dita do fenômeno, ou seja, seu geo-referenciamento. As características
temporais dos dados geográficos são informações bastante importantes, principalmente pelo
fato dos mesmos serem variantes com o tempo, enquanto que as características gráficas são as
representações pictóricas dos dados, armazenadas também no banco de dados.
Dados geográficos, ou geo-dados, que descrevem fenômenos direta ou indiretamente
associados a uma localização relativa à superfície terrestre, têm sido coletados em forma
digital há mais de 30 anos. O alcance total desta coleção aumenta rapidamente com avanços
em tecnologia, tais como sistemas de imagens de satélite de alta resolução e sistemas de
______________________________________________________________________________________
10
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
posicionamento global, como também o crescente número de pessoas e organizações que
coletam ou utilizam estes dados.
Durante
muitos
anos
diferentes
métodos
para
aquisição,
armazenamento,
processamento, análise e visualização de geo-dados têm sido desenvolvidos mais ou menos
independentes uns dos outros. Refere-se a geo-dados como sendo todos os tipos de dados
geográficos digitais, tais como:
•
Mapas digitais
•
Dados de imagens de satélite
•
Dados espaciais e temporais
Define-se geoprocessamento como sendo qualquer tipo de sistema de computação que
utilize geo-dados, incluindo: Sistemas de Informação Geográfica – SIG, Sistemas de Controle
Aéreo, Processamento de Imagens, Armazenamento de Geodados em Bancos de Dados de
todos os tipos, Métodos de Navegação, Meteorologia, Sismologia, CAD, Gerenciamento de
Transportes, Cartografia Digital, Comércio Geográfico, Simulação de Vôos entre outros.
Como uma definição mais ampla, segundo Güting [Gut94], um banco de dados é
espacial se o mesmo gerencia dados que estão relacionados com algum espaço. Como
exemplo de espaço, temos o espaço geográfico (superfície terrestre), o universo, um projeto
de VLSI, ou uma estrutura molecular. Como característica deste tipo de sistema de banco de
dados e da tecnologia necessária para o mesmo, cita-se a capacidade de gerenciar grandes
conjuntos de objetos geométricos simples. Quando o espaço utilizado é a superfície terrestre
temos, como exemplo de aplicação, os Sistemas de Informação Geográfica (SIG).
Uma das principais características de SIG [CCF+96, Cam+ 00] é sua capacidade de
manipular dados espaciais e não-espaciais, ou descritivos, de forma integrada provendo uma
forma consistente para análise e consulta. É possível, desta forma, ter acesso às informações
descritivas de uma entidade geográfica a partir de sua localização geográfica, e vice -versa.
Entidade Geográfica é qualquer fenômeno ou objeto do mundo real que possua atributos
associados à sua localização sobre a superfície da Terra, num certo instante ou intervalo de
tempo.
______________________________________________________________________________________
11
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
2.3
LINGUAGENS DE CONSULTA PARA BANCOS DE DADOS GEOGRÁFICOS
As linguagens de consultas existentes para Bancos de Dados Geográficos classificam-se em
textuais, visuais e multimodais ou híbridas. As linguagens textuais são usualmente extensões
de SQL que acomodam relacionamentos espaciais em suas estruturas. As linguagens visuais
por outro lado permitem a manipulação direta dos elementos visualizados na elaboração da
sentença de consulta desejada. As linguagens multimodais ou híbridas permitem uma
combinação de linguagem textual com manipulação de elementos gráficos pelo usuário.
2.3.1 Linguagens Textuais
Por serem baseadas na linguagem SQL, essas linguagens apresentam como vantagem principal
a larga utilização da mesma por usuários de bancos de dados, além de que o padrão SQL
facilita a otimização de consultas. Por outro lado, apresentam uma limitação em relação à
modelagem de dados em aplicações de geoprocessamento.
Devido à falta de relações no conjunto de operações fundamentais que suportam
apropriadamente a maior parte de operações geométricas e pictoriais, características dos SIG,
as operações relacionais por si só são insuficientes para resolver muitas consultas típicas.
Inúmeras extensões especializadas de SQL têm sido propostas para manipular objetos
complexos, temporais e dados espaciais [Ege94, FC92, MSO87, RFS88, PF88, Sam88].
Existem algumas diferenças nas extensões SQL que suportam dados espaciais:
1. A forma de extensão em que são cobertas as propriedades espaciais;
2. O grau de formalidade em que são definidas as semânticas das extensões;
3. A sua implementação sintática;
4. O grau de concordância com a estrutura padrão SQL.
Extensões SQL que tentam cumprir com o padrão SQL têm que conviver com um
conjunto de restrições conceituais que se referem ao esquema padrão. É muito difícil estender
uma linguagem padrão SQL de modo que a mesma suporte dados geográficos e os manipule
corretamente [Ege92]. Dois tipos de deficiências são encontrados:
1. A falta de poder expressivo para formular certos tipos de consultas espaciais;
2. A falta de conceitos espaciais no padrão SQL.
______________________________________________________________________________________
12
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
A deficiência da linguagem SQL em relação à expressividade na manipulação de dados
geográficos diz respeito a: poder da linguagem, identidade de objetos, consulta a metadados e
consulta de conhecimentos [Ege92].
Extensões SQL para dados espaciais apresentam operações sobre objetos geográficos
que incluem operações de seleção espacial e junção espacial. As operações sobre objetos
geográficos referem-se a [Cam95]:
1. Restrições sobre atributos: computados em função dos atributos dos objetos
geográficos.
2. Restrições espaciais: derivados a partir dos relacionamentos espaciais dos objetos
geográficos.
3. Propriedades de objetos: os resultados correspondem a predicados de um objeto
ou de um conjunto de objetos.
Algumas linguagens textuais para banco de dados geográficos seguem a filosofia QBE –
Query-By-Example [Zlo76], outras seguem a filosofia de QUEL [HSW75]. Uma descrição de
várias dessas linguagens pode ser vista em [Nas95]. Neste trabalho serão descritas algumas
linguagens baseadas em SQL no Capítulo 3.
2.3.2 Linguagens Visuais
As linguagens de consultas visuais permitem a construção de uma consulta através de
combinações de símbolos e texto, visando facilitar o trabalho do usuário. Muitas vezes,
porém, esta abordagem dificulta a formulação de uma semântica precisa para as consultas.
Recentemente, o crescimento do número de usuários de BD, tanto experientes como
novatos, tem levado ao desenvolvimento de um número de interfaces baseadas em diferentes
princípios, cujo principal propósito é facilitar a interação homem-máquina [Cat+97]. Uma
das tecnologias existentes é a utilização de linguagens de manipulação direta caracterizada
tanto pela visibilidade dos objetos de interesse, como pela substituição da sintaxe da
linguagem de comandos pela manipulação direta desses objetos.
A manipulação direta com técnicas visuais apresenta algumas vantagens [Cat+97], tais
como:
•
Representação dos objetos de forma visual pelo computador;
______________________________________________________________________________________
13
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
•
Redução da dependência da linguagem nativa do usuário;
•
Facilidade no entendimento da funcionalidade básica da interação;
•
Alto grau de eficiência devido à possibilidade de definição de novas
funções e características;
•
Redução significativa do grau de erro.
Encontram-se na literatura alguns exemplos de utilização deste tipo de linguagem em
SIG [CM94, Fra82, Mey92a, Mey92b]. No Capítulo 4, serão vistas algumas destas propostas
com mais detalhes.
2.3.3 Linguagens Híbridas
Em um ambiente multimodal, ou híbrido, tem-se a combinação de consultas visuais e
textuais, de forma a tirar proveito dos aspectos positivos de cada uma. Um tipo de
metodologia para implementar estas linguagens é a utilização de mapas dinâmicos, onde se
tem a combinação de noção de visões de bancos de dados com técnicas de visualização
[CCH +96]. Cada mapa dinâmico é definido por um par (visão, visualização), onde a visão é o
resultado da consulta e a visualização associa uma apresentação ao resultado da consulta.
2.4 Tipos de Representação
Os SIG trabalham com dois tipos diferentes de representação gráfica, a representação
“matricial” e a representação “vetorial” [HGW99]. O tipo de representação mais simples e
mais freqüentemente usado é constituído por entidades espaciais básicas, especificadas por
atributos e localização geográfica, que é a representação vetorial. Nesta representação,
informações sobre pontos, linhas e polígonos são codificadas e armazenadas como uma
coleção de coordenadas x, y. A representação vetorial é extremamente útil para descrever
características discretas, mas menos utilizadas para descrever características continuamente
variantes, tal como tipos de solos.
Pontos, linhas e polígonos complexos podem ser usados para capturar as estruturas externas
de uma entidade, e estas definições podem ser funcionais ou descritivas. Por exemplo, uma
cidade pode ser representada tanto por um ponto, em um mapa com nível de descrição por
continentes, ou como um polígono, em um mapa com nível de descrição por regiões. Em um
nível ainda mais detalhado, uma cidade pode incluir ruas, casas, parques, cada um com
diferentes funcionalidades e respondendo diferentemente às operações de consulta.
______________________________________________________________________________________
14
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
A representação matricial é utilizada para descrever características ou fenômenos que
variam continuamente com o tempo. Uma representação matricial consiste de uma coleção de
células de uma malha regular, como um mapa digitalizado ou uma figura. Também chamado
de tesselações, a representação matricial consiste de superfícies contínuas que podem ser
representadas por conjuntos de unidades básicas, tais com o células quadradas, triangulares ou
hexagonais, ou ainda polígonos irregulares. Superfícies geométricas 2D podem ser divididas
em células quadradas, conhecidas como pixels, cujo tamanho é determinado pela resolução
que é requerida para representar a variação de um atributo para um dado propósito. O
equivalente dos pixels em 3D é chamado de voxels e são as unidades básicas numa variação
espacial de um espaço 3D. Tanto a representação matricial como a vetorial (Figura 2.4)
possuem vantagens e desvantagens no armazenamento de dados geográficos. SIG modernos
devem ser capazes de manipular ambos os modelos de representação.
Figura 2.4 – Representação Matricial e Vetorial [GIS02]
Devido ao gerenciamento de grandes volumes de dados, existe uma necessidade dos
SIG trabalharem de forma integrada com sistemas gerenciadores de bancos de dados (SGBD)
geográficos. Assim, as aplicações desenvolvidas a partir de SIG apresentam uma
complexidade semelhante ou maior àquela apresentada por aplicações que são desenvolvidas
com base em SGBD [Lis00] convencionais.
______________________________________________________________________________________
15
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Tem sido um grande desafio para os desenvolvedores projetar Sistemas de Informação
Geográfica que atendam às diversas necessidades das diferentes aplicações para os mesmos.
Muitas vezes verifica-se o desenvolvimento de SIG de forma não metodológica, tendo como
resultado diversos tipos de problemas de projeto. Entre os problemas citados, destacam-se: a
grande variedade de métodos de aquisição de dados, a falta de uma codificação adequada dos
elementos sendo modelados, a ocorrência de coberturas esporádicas de dados, a necessidade
de dados temporais e a incompatibilidade entre conjuntos de dados [Lis00].
2.5 Modelos Conceituais e Modelos de Dados Geográficos
Quando se manipula informações geográficas através de um vasto domínio, torna-se
necessário formalizar os modelos usados para descrever este domínio e garantir que os dados
sejam interpretados sem ambigüidade e comunicados efetivamente. Fenômenos do mundo
real não são armazenados no computador diretamente, mas somente suas representações
baseadas nestes modelos formais.
A partir de idéias conceituais de fenômenos geográficos é possível formalizar a
representação do espaço e de propriedades espaciais. Podem-se adotar diferentes maneiras de
descrever o que está acontecendo na superfície terrestre: (a) percebendo o espaço como
sendo ocupado por entidades que são descritas por seus atributos e propriedades e cuja
posição pode ser mapeada usando um sistema de coordenadas, ou (b) imaginando que a
variação contínua de um atributo de interesse, ou campo, através do espaço, seja de acordo
com alguma função matemática. Será apresentado, a seguir, algumas características destes
modelos de representações espaciais.
Genericamente falando, pode-se dizer que os modelos de representações espaciais são
formalizações equivalentes do modelo conceitual usado [BM98]. Eles formalizam como o
espaço é dividido em partes para análise e comunicação e assumem que, unicamente
identificados, os atributos possam ser medidos ou especificados e que as coordenadas
geográficas possam ser registradas.
Uma característica bastante importante dos dados geográficos é que os mesmos não
podem ser considerados sozinhos no espaço porque a sua análise e interpretação dependem
basicamente de sua localização neste espaço de acordo com outros dados, ou seja, a sua
referência espacial é extremamente importante. Esta característica é refletida intensamente na
elaboração de consultas a estes dados. De uma forma geral, consultas a dados geográficos,
______________________________________________________________________________________
16
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
geralmente manipulados por SIG, envolvem tanto o estado de um fenômeno, como a sua
distribuição espacial e temporal [CCH+96].
Um modelo de dados conceitual é um conjunto de ferramentas computacionais
utilizado para estruturar dados em um sistema computacional. Aspecto fundamental no
projeto de SIG, o modelo descreve como a realidade geográfica vai ser representada no
computador. A modelagem de dados tem um papel crítico [Cam95] no desenvolvimento de
sistemas ao determinar a capacidade de uso e a rapidez de aprendizado do mesmo.
Um modelo busca sistematizar o entendimento que é desenvolvido a respeito de objetos
e fenômenos que serão representados em um sistema computacional [BD00]. No entanto, os
objetos e fenômenos do mundo real são complexos demais para permitir uma representação
completa, considerando os recursos computacionais à disposição dos SGBD atuais. Ao longo
dos anos foram criados diversos modelos de dados que podem ser classificados em modelo de
dados conceitual, modelo de dados lógico e modelo de dados físico. Os modelos de dados
conceituais são os mais adequados para capturar a semântica dos dados e, conseqüentemente,
modelar e especificar as suas propriedades. Como exemplos mais utilizados de modelos
conceituais temos o modelo entidade-relacionamento [Che76], e os modelos de objetos das
metodologias OMT [Rum91] e UML [BRJ00].
Quando se modelam dados espaciais, ou dados geográficos, sente-se necessidade de
representar basicamente duas visões dos dados: os objetos no espaço e o espaço propriamente
dito [Gut99]. Como exemplos de objetos pode-se citar uma cidade com nome, população e
área, como também um rio possuindo um nome e uma rota. Como exemplos de espaço a ser
modelado tem-se: mapas temáticos, estados e meso-regiões. Numa modelagem geo-espacial
considera-se então os objetos simples e as coleções de objetos que se encontram
espacialmente relacionados. Abstrações básicas para se modelar objetos simples são [Gut99]:
•
Ponto - representa uma entidade geográfica cuja localização geográfica é
importante, mas a sua extensão não é um dado relevante.
•
Linha – modela movimento ou conexão através do espaço.
•
Região – abstração de um objeto geográfico com a sua área.
Exemplos de abstrações básicas para se modelar coleções de objetos espacialmente
relacionados entre si são [Gut99]:
______________________________________________________________________________________
17
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
•
Mapas cadastrais e temáticos – como exemplo de modelagem do uso da terra,
distritos, proprietários, etc.
•
Rede espacialmente conectada – como exemplo cita-se: ruas, estradas, rios,
telefonia, etc.
Tendo sido exposta a grande complexidade dos dados geográficos, entende-se porque
ainda existem tantos estudos na definição de um modelo conceitual que atenda a todas as
necessidades e aplicações. Foram analisados alguns modelos conceituais para dados
geográficos encontrados na literatura [BD00, Pim95, Pir97, OGC98a, CF94], e a seguir,
apresenta-se algumas características de alguns deles.
O modelo MGeo+ [Tim94, Pim95, Pas96]
é um modelo conceitual orientado a
objetos para aplicações geográficas. Consiste de uma hierarquia de classes que foi
desenvolvida a partir da representação gráfica do modelo de objetos OMT e é capaz de
representar um grande conjunto de requisitos normalmente presentes em aplicações
geográficas. Características básicas do Modelo MGeo+: representação das camadas
temáticas; definição de um grande número de operações espaciais; elevado nível de
abstração; integração de ambas as representações gráficas: matricial e vetorial; dados
geográficos com características descritivas, geométricas e gráficas. Um projeto de esquema de
banco de dados geográfico, utilizando o modelo MGeo+, consiste em definir novas classes e
inseri-las como subclasses das classes pré-definidas na hierarquia. São projetados também,
diagramas de instâncias dessas classes, com detalhamento complementar da modelagem dos
objetos não-espaciais.
O Modelo GMOD [Pir97, Oli97] tem como características principais: ser
independente de qualquer modelo de dados utilizado pelos SIG comerciais, permitindo um
nível mais alto de abstração; ser extensível, permitindo ao usuário derivar classes a partir de
classes pré-definidas; permitir a especificação de processos e de aplicações; permitir
representar relacionamentos temporais; permitir a especificação de regras que retratam a
dinâmica do mundo real. O GMOD é um modelo orientado a objetos e utiliza como base a
proposta de Câmara [Cam95]. O GMOD contém basicamente três grupos de classes que são
utilizadas para a modelagem estática, dinâmica e funcional. O modelo de objetos abstrai a
estrutura de dados das entidades geográfica s sendo modeladas; o modelo dinâmico abstrai o
______________________________________________________________________________________
18
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
comportamento temporal do sistema e o modelo de processos abstrai como os valores são
computados.
O modelo GEO-OMT [BD00] apresenta-se como uma extensão do modelo OMT,
agrupando de forma unificada as primitivas geográficas propostas por outros autores além de
introduzir outras, como por exemplo, a representação de múltiplas visões das entidades
geográficas. Por múltiplas visões entende-se a capacidade de um SIG de representar um
mesmo fenômeno geográfico através de múltiplas representações. Características básicas do
modelo Geo-OMT: segue o paradigma de orientação a objetos; representa e diferencia
diversos tipos de dados geográficos utilizando uma representação simbólica dos mesmos,
facilitando a percepção da natureza do dado; fornece uma visão integrada do espaço
modelado; caracteriza as classes em contínuas e discretas; é de fácil visualização e
entendimento. O modelo Geo-OMT é baseado em três conceitos principais: classes,
relacionamentos e restrições de integridade. Mais informações sobre este modelo podem ser
obtidas em [BD00, Bor97].
Existem diversos outros modelos conceituais de dados propostos na literatura
especificamente para aplicações de SIG como, por exemplo, Modul-R [Bed99], GeoOOA
[KPS97], Geo-ER [HT97], MADS [PSZ+98] e GISER [SCG+97]. A maioria deles é baseada
nos formalismos Entidade-Relacionamento e da Orientação a Objetos. No entanto, antes de
adotar qualquer um deles, convém observar os níveis de abstração dos dados geográficos, os
requisitos de um modelo de dados geográficos e finalmente, se o que se pretende modelar
poderá ser claramente representado no modelo escolhido [LIH+02, Lis97].
Alguns destes modelos são apresentados em [Soa01]. Apresenta-se com mais detalhes, a
seguir, o modelo de dados do padrão OpenGIS [OGC96, OGC98a, OGC99a] que foi
utilizado neste trabalho devido a completude de sua especificação.
2.6 O CONSÓRCIO OPEN GIS
O Consórcio Open GIS – Open Geodata Interoperability Specification [OGC96, OGC98a,
OGC99a] é uma organização sem fins lucrativos dedicada a sistemas de geoprocessamento
abertos. Este consórcio utiliza um processo em consenso com seus membros com o objetivo
de alcançar especificações abstratas e de implementação para componentes de software
relacionados a Sistemas de Informação Geográfica e Geoprocessamento.
______________________________________________________________________________________
19
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
OpenGIS é uma especificação de um ambiente de software para acesso distribuído aos
dados geográficos ou geodados e recursos de geoprocessamento. Através destas atividades, os
membros deste consórcio desenvolvem modelos essenciais e modelos de especificação. O
Modelo Essencial juntamente com o Modelo de Especificação são chamados de Especificação
Abstrata. O ambiente OGIS inclui três partes:
•
Open Geodata Model: apresenta um significado comum para a
representação digital da Terra e dos seus fenômenos, de forma matemática
e conceitual.
•
OGIS Services Model: apresenta um modelo comum de especificação para
implementação de serviços de acesso a geodados, gerenciamento,
manipulação, representação e compartilhamento entre comunidades de
informação.
•
Information Communities Model: um ambiente para uso do modelo de
geodados e serviços OGIS para resolver problemas técnicos da não
interoperabilidade de dados.
O OGIS tem como proposta permitir que um usuário em um PC padrão executando
uma aplicação de mapeamento de baixo-custo possa, de conformidade com o OGIS,
consultar um servidor remoto de dados na Internet, provavelmente através de uma técnica de
seleção gráfica simples dentro da aplicação. Por sua vez, o servidor de dados remoto irá
armazenar os geodados em um SGBD relacional comercial e de propósito geral, configurado
com uma interface OGIS. Algumas informações podem se perder na transferência, mas o
servidor poderá cooperar e informar ao usuário sobre esta informação perdida.
O Consórcio OGIS [OGC99a, Bog99] provê uma plataforma para desenvolvedores de
software que permite que seus usuários acessem e processem dados geográficos de uma
variedade de fontes ao longo de interfaces computacionais genéricas com uma tecnologia de
informação aberta (Figura 2.5). Especifica, ainda, a tecnologia que irá habilitar um
desenvolvedor de aplicação a usar qualquer geodado e qualquer função de geoprocessamento
ou processo disponível na rede com um ambiente simples de fluxo de trabalho. Geodados
incluem qualquer representação digital de características da Terra, sejam elas naturais ou
feitas pelo homem ou fenômenos da Terra definidos por sistemas de coordenadas espaciais
ou temporais.
______________________________________________________________________________________
20
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Figura 2.5 – Tecnologia Open GIS
O Modelo Open GIS [OGC96, OGC98a, OGC99a] é um modelo operacional, e não
um padrão de dados. Os elementos ou características do modelo de geodados são definidos
em termos de interfaces e não estruturas. Do ponto de vista de interoperabilidade geográfica,
significa que implementações individuais podem ser desenvolvidas baseadas em diferenças
profundamente fundamentais de organizações de dados, mas estas diferenças são
transparentes ao usuário.
2.6.1 ESPECIFICAÇÃO ABSTRATA OPEN GIS
O modelo abstrato OGIS identifica as classes e sub-classes mais interessantes e seus
relacionamentos e especifica, de forma abstrata, as interfaces que devem ser implementadas
no sistema. O modelo OGIS trabalha com informações geo-espaciais que utiliza feições com
geometria, camadas ou informações de imagens.
a) Geometria de Feição (Feature Geometry):
Considera-se uma feição como sendo o átomo da informação geográfica. É uma
representação abstrata dos fenômenos do mundo real e está associada a uma localização
______________________________________________________________________________________
21
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
relativa à Terra. Feições são abstrações codificadas digitalmente de objetos e fenômenos do
mundo real que têm uma representação geométrica e espaço-temporal, além de outros
atributos associados a elas. Feições são criadas, administradas, acessadas, alteradas entre si e
manipuladas pelos serviços Open GIS. Exemplos de feições podem ser: um segmento de reta
entre interseções consecutivas, uma imagem de satélite geo-referenciada, uma sobreposição
de temperatura ou um mapa climático.
Uma coleção de feição pode conter uma ou mais feições simples. Feições são
compostas por três elementos básicos:
•
Geometria: com um sistema de referência espacial e/ou temporal, incluindo
uma sentença de uma resolução e a exatidão do modelo geométrico. Feição
com extensões espaciais no projeto são desenhadas usando formas geométricas
primitivas simples. Estas formas primitivas são instâncias do conjunto Well
Known Types (WKTs) do módulo OpenGIS Geometry, tais como polígonos,
cadeias de linhas, poliedros e outras formas OpenGIS. Todas as geometrias
devem poder ser representadas por um sistema de coordenadas geométricas.
•
Propriedades Semânticas: Consiste na definição da entidade ou do fenômeno.
Ao contrário da geometria, a semântica pode variar de um grupo para outro da
mesma forma que uma visão conceitual.
•
Metadados: São informações que podem ser necessárias para posicionar a
feição no contexto da aplicação ou da comunidade de usuários. Padrões e
requisitos de metadados são freqüentemente definidos através de empresas
profissionais e são usados para traçar uma linha e prover uma medida de
qualidade garantida ao usuário.
A feição geográfica contém as informações da sua posição em relação às
coordenadas da Terra ou em relação à outra feição. A técnica mais comum de se obter a
forma e a localização de uma feição é através de sua geometria. Instâncias geométricas
simples estão associadas a um número de pontos de coordenadas que são mapeadas em
pontos do mundo real através do uso de um sistema de referência espaço-temporal
constante para uma geometria particular. Geometrias complexas podem ser derivadas do
uso de geometrias simples, ou seja, a classe geometria do modelo pode representar vários
tipos de geometria.
______________________________________________________________________________________
22
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
A aparência de uma feição é estabelecida pela sua geometria, semântica e seus
metadados. Contudo, não existe nenhum requisito rigoroso que obrigue a existência de
um valor para cada um deles, mas, devido ao seu uso em aplicações geográficas, a maioria
dos objetos apresenta uma localização.
As instâncias de uma feição são identificadas dentro do sistema operacional por uma
identidade de objeto. Esta identidade, OID, é única para cada objeto em todos os
conjuntos de dados. As feições podem ser definidas por recursividade, ou seja, feições
podem conter muitas sub-feições, que por sua vez, podem conter também outras subfeições.
b) Camadas e feições
Elementos geográficos dividem-se em duas grandes categorias: entidades e fenômenos.
•
Entidades são reconhecíveis, ou seja, são objetos discretos que possuem limites
relativamente bem-definidos ou extensão espacial. São exemplos de entidades:
caminhões, prédios, rios.
•
Fenômenos variam através do espaço e não possuem extensão específica. Exemplos de
fenômenos são: temperatura, composição do solo e topografia. Um valor ou uma
descrição de um fenômeno só faz sentido se houver uma correlação com um ponto no
espaço, e possivelmente uma variável temporal.
Estas duas categorias não são obrigatoriamente mutuamente exclusivas. De fato,
muitos componentes da Terra apresentam características por uma parte de entidade, por
outra, de fenômeno, tornando sua classificação subjetiva e aberta às interpretações. Na
especificação Open GIS, tanto as feições como as camadas podem ser usadas para mapear
diferentes entidades ou fenômenos do mundo real.
•
Feição é a representação de uma entidade do mundo real, ou uma abstração do
mundo real. Possui um domínio espacial, temporal ou espaço-temporal como
atributo. Qualquer coisa que possa ser localizada no tempo e no espaço pode ser
exemplo de uma feição. Um mapa cadastral de uma cidade que mostra as suas ruas,
por exemplo, é na verdade, uma coleção de feições, cada uma das quais sendo uma
feição do tipo rua. Uma feição, desta forma, normalmente representa entidades.
______________________________________________________________________________________
23
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
•
Camada é uma associação de pontos com um domínio espaço/temporal de um valor,
ou seja, em uma camada, cada ponto tem um valor simples ou complexo particular.
Na especificação Open GIS, uma camada é, então, simplesmente uma função que
retorna um valor a cada ponto geométrico. Campos escalares, modelos da Terra,
distribuição populacional e mapas dos solos podem ser manipu lados como camadas.
Desta forma, vê-se que camadas estão normalmente relacionadas com fenômenos.
Uma cidade definida como uma feição, por exemplo, não apresenta um valor para
cada ponto. Se a mesma cidade for definida como uma camada, para cada ponto ela vai
fornecer um valor, tal como o índice de elevação da qualidade do ar, índices pluviométricos,
de umidade do ar, etc.
O Open GIS define um modelo para descrever as semânticas das propriedades de uma
feição. Estas propriedades podem ser arbitrariamente complexas dependendo de como forem
representadas sobre os tipos do modelo. Por exemplo, o atributo de tipo de solo pode ser
simplesmente um nome tal como arenoso ou pode conter um largo conjunto de parâmetros
como pH, densidade, etc.
É necessário prover descrições do modelo de atributos escolhido para uma feição. O
componente semântico de uma feição inclui o seu esquema. Todos os tipos deste modelo
terão estruturas de representação bem conhecidas que podem ser usadas para construir
instâncias para estes tipos.
O Modelo Open GIS necessita também acomodar descrições dos metadados que são
associadas às feições. A necessidade dos metadados e seus tipos variam largamente de
aplicação para aplicação. Os metadados são subconjuntos das propriedades de uma feição.
Além das propriedades das feições, é necessário, também, prover descrições do modelo de
elementos dos metadados.
As aplicações geográficas manipulam uma grande variedade de geometrias. O Modelo
Open GIS deve prover a capacidade para manipular geometrias independentemente do
tipo/modelo de representação específico e escolhido para a aplicação. Os seguintes tipos de
geodados são descritos na especificação: ponto, superfície, curva e coleção de geometrias.
Cada objeto geométrico é associado a um Sistema de Coordenadas Espacial, que descreve as
coordenadas do espaço no qual a geometria é definida.
______________________________________________________________________________________
24
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
2.6.2 HIERARQUIA DO MODELO OPEN GIS
Geometria é a classe raiz da hierarquia do Modelo Open GIS (Figura 2.6). É uma classe
abstrata, ou seja, não instanciável. Todas as classes geométricas instanciáveis descritas nesta
especificação são definidas de tal forma que as instâncias válidas de uma classe geométrica são
topologicamente fechadas (incluem seus limites).
Geometria é a combinação de uma coordenada geométrica com um sistema de
referência. Uma coordenada geométrica é composta por quatro itens:
1. Uma seqüência de pontos de coordenadas do mesmo sistema de referência.
2. Uma coleção de outras geometrias do mesmo sistema de referência.
3. Um algoritmo de interpretação que usa estas geometrias e pontos de
coordenadas para construir entidades geométricas que indiretamente definem
a extensão da geometria no tempo e no espaço.
4. Um sistema de referência temporal que mapeia a coordenada geométrica e sua
localização, fornecendo à mesma uma interpretação do mundo real.
______________________________________________________________________________________
25
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Geometria
Ponto
1+
Sistema de Referência Espacial
Curva
Superfície
Cadeia de
Linhas
Polígono
Coleção de Geometrias
2+
MultiSuperfície
MultiCurva
MultiPonto
1+
Linha
Linha Anel
MultiPolígono
MultiLinhaString
1+
Figura 2.6 – Hierarquia de Classes Geométricas
Ponto
O exemplo mais simples de um domínio espacial é o ponto. É uma geometria que possui
dimensão zero e representa uma posição simples no sistema de coordenadas. Um ponto tem
um valor da coordenada-x e outro valor da coordenada-y. O limite de um ponto é o conjunto
vazio.
Multiponto
É uma coleção geométrica de dimensão zero. Os elementos de um Multiponto estão restritos
a pontos, e os mesmos não são conectados ou ordenados. Um Multiponto é simples se não
existirem dois pontos que sejam iguais (tenham os mesmos valores de coordenadas). O limite
de um conjunto de pontos também é o conjunto vazio.
Curva
A Curva é um objeto geométrico de uma dimensão, normalmente armazenada como uma
seqüência de pontos, com o subtipo de curva especificando a forma de interpolação entre os
______________________________________________________________________________________
26
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
pontos. Uma curva simples é aquela que não passa por um mesmo ponto mais de uma vez. É
fechada se seu ponto inicial for igual ao ponto final. O limite de uma curva fechada é
definido como vazio. Uma curva simples e fechada é chamada de Linha Anel. Os limites de
uma curva aberta consistem de seus dois pontos extremos.
Cadeia de Linhas, Linha e Linha Anel.
Uma Cadeia de Linhas é uma curva com interpolação linear entre seus pontos. Cada par
consecutivo de pontos define um segmento de linha.Uma Linha é uma Cadeia de Linhas que
possui exatamente dois pontos. Uma Linha Anel é uma Cadeia de Linhas que é tanto fechada
como simples.
MultiCurva
É uma coleção de geometrias de uma dimensão cujos elementos são curvas. MultiCurva é
uma classe não-instanciável nesta especificação e define um conjunto de métodos para suas
sub-classes. Uma MultiCurva é simples se, e somente se, todos os seus elementos forem
simples. As únicas interseções possíveis são entre pontos que estejam nos limites de ambos os
elementos. A MultiCurva é fechada se todos os seus elementos forem fechados. O limite de
uma Multicurva fechada é sempre vazio.
MultiCadeiadeLinhas
É uma MultiCurva cujos elementos são Cadeias de Linhas.
Superfície
É um objeto geométrico de duas dimensões. Superfícies simples em um espaço tridimensional
são isomórficas às superfícies planas. O limite de uma superfície simples é o conjunto de
todas as curvas fechadas correspondentes aos seus limites internos e externos. A única
subclasse instanciável de superfície nesta especificação é o polígono.
Polígono
É uma superfície plana, definida por um limite exterior e zero ou mais limites interiores.
Cada limite interior define um buraco em um polígono.
Polígonos são topologicamente fechados. Os limites de um polígono consistem de um
conjunto de Linhas Anéis que compõem seus limites interior e exterior. Polígonos são
geometrias simples.
______________________________________________________________________________________
27
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
MultiSuperfície
É uma coleção de geometrias de duas dimensões cujos elementos são superfícies. Os
interiores de quaisquer dessas superfícies não podem se intersectar entre si. Multisuperfície é
não-instanciável. A subclasse instanciável de multisuperfície é multipolígono e corresponde a
uma coleção de polígonos.
Multipolígono
É uma multisuperfície cujos elementos são polígonos. Seus limites consistem de um conjunto
de curvas fechadas correspondentes aos limites de seus elementos polígonos.
2.6.3 Considerações Finais da Especifica ção Open GIS
No Open GeoData Model - OGM [OGC99a], objetos digitais representando entidades são
associados com valores de atributos o que implica que a entidade correspondente no mundo
real tem uma descrição que esta atribuição está representando.
Um sistema de referência é uma maneira de atribuir valores de localização, tempo e
outras quantidades ou qualidades descritivas. De uma maneira mais geral, um sistema de
referência pode ser pensado como uma medida de escala. Normalmente, Sistemas de
Referências Espaciais e Temporais são restritos a escalas cardinais e contínuas cujos valores
fazem parte de um espaço vetorial real.
Um Sistema de Referência Espacial é uma função que associa localizações no espaço
com as tuplas de coordenadas das geometrias em um espaço matemático, normalmente um
espaço de coordenadas vetoriais reais. Esta conversão associa valores de coordenadas e
geometrias com localizações do mundo real.
Existem muitas extensões espaciais possíveis para o Modelo de Geodados apresentado
anteriormente. Círculos, splines, cilindros, sólidos geométricos construtivos, e muitos outros
podem ser adicionados. Modelos geométricos tridimensionais também, muitas vezes, são
necessários em muitos domínios.
As diferentes geometrias apresentadas na especificação [OGC98a] podem ser
implementadas utilizando-se estruturas conhecidas, Well Known Structures – WKS. Todas as
geometrias são lineares, ou seja, toda interpolação entre dois dados pontos na geometria
WKS é linear. Algumas das estruturas usadas são: Coordenadas, Multiponto, Cadeia de
Linhas, MultiCadeiadeLinhas, Linha Anel, Polígonos e Triângulos.
______________________________________________________________________________________
28
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
A Especificação Abstrata OpenGIS [OGC990] é muito extensa e engloba informações
a respeito da Geometria de Feições [OGC01I], Sistemas de Referências Espaciais [OGC02II],
Estruturas de Localização de Geometrias [OGC99III], Feições [OGC99V], Relações entre
Feições [OGC99VIII], Coleções de Feições [OGC99X], Metadados [OGC99XI], entre
outras, e todos estes podem ser obtidos em [OGC98a, OGC99a].
Apesar das características inovadoras da especificação do OpenGIS [OGC99a,
OGC99b], a mesma apresenta algumas limitações de uso como, por exemplo, pelo fato de
tomar a linguagem SQL como base de sua linguagem de consulta. O SQL, por si só, não
prevê a existência de uma linguagem de apresentação associada às consultas realizadas e nem
permite o conceito de que o resultado das consultas possa retornar objetos e campos que
sejam manipulados posteriormente [Tom98, Lim02]. Além disso, a especificação da
linguagem não permite a definição de restrições espaciais.
2.7 P ADRÕES DE METADADOS ESPACIAIS
Muitas vezes algumas companhias trabalham sobre um mesmo tipo de dado geográfico, mas
não compartilham os mesmos entre si devido a:
•
Utilizarem plataformas para SIG diferentes e, portanto, utilizarem dados
digitais em diferentes formatos;
•
Utilizarem os mesmos SIG, mas as estruturas dos dados serem diferentes;
•
Terem obstáculos institucionais, econômicos e legais. Muitas vezes os
dados de uma empresa não podem ser legalmente acessados por outra.
Com o objetivo de promover a interoperabilidade global de dados espaciais, normas de
padronização vêm sendo desenvolvidas e utilizadas em toda a comunidade de usuários de
SIG. Os metadados realizam um importante papel nesta tarefa, pois os mesmos dão suporte à
infra-estrutura de dados espaciais permitindo aos usuários localizar, avaliar, extrair e aplicar
estes dados.
Os metadados podem ser definidos como dados sobre dados. Descrevem o conteúdo, a
qualidade, a condição e outras características relevantes do dado [HP98, Dub01]. O conceito
de metadados é familiar para a maioria das pessoas que manipulam informações geográficas.
A legenda de um mapa, por exemplo, é puramente metadado [VMR99]. A maior parte dos
arquivos geo-espaciais digitais atualmente tem algum metadado associado.
______________________________________________________________________________________
29
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Metadados de dados geográficos são necessários por uma série de propósitos e incluem
as seguintes informações [Aus00]:
•
Informações detalhadas sobre métodos de coleta de dados, técnicas de análise e
integração, aplicadas a vários componentes de dados fontes, que dêem suporte
à preparação de relatórios científicos;
•
Informações sobre a exatidão do conjunto de dados fontes, histórico do
processamento e procedimentos de arquivos que gerenciem e utilizem os dados
efetivamente;
•
Informações sobre especificações de projeto, escala e um dicionário de dados
para acompanhar a transferência de dados para outras organizações;
•
Descrições adequadas do conteúdo, qualidade e extensão geográfica do
conjunto de dados de modo que usuários em potencial de dados existentes
possam calcular sua aplicabilidade para outros propósitos;
•
Um resumo de descrições de conteúdo e qualidade assim como informações de
contato e inclusão dos sistemas de diretório.
A qualidade dos dados é requerida para uma série de propósitos, mas o grau de
detalhes necessários varia. Os elementos de metadados requeridos para descrever
adequadamente diferentes tipos de dados também variam. Por exemplo, alguns dos
elementos relevantes em uma descrição de conjuntos de dados climáticos podem não ser
relevantes em uma descrição de geociência ou de conjuntos de dados populacionais. Devido a
esta variação de requisitos de metadados, se faz necessário definir um número de elementos
comuns para muitos propósitos [Aus00], de acordo com o tipo de dados ou o nível de detalhe
a ser trabalhado.
A National Spatial Data Infrastruture – NSDI [Tos98], através de um consenso geral
entre pesquisadores, especificou uma infra-estrutura que definiu as ferramentas, a tecnologia
e as pessoas necessárias para adquirir, processar, armazenar e distribuir informações
geográficas de modo a alcançar uma grande variedade de usuários.
Alguns padrões independentes foram desenvolvidos e seu principal objetivo é auxiliar o
acesso aos dados. Estes padrões provêem uma abordagem e formatos consistentes para a
descrição das características dos dados. Provêem ainda uma maneira dos usuários saberem:
______________________________________________________________________________________
30
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
quais dados estão disponíveis; se os dados atendem às necessidades específicas; onde
encontrá-los e como acessá-los. A próxima seção descreve o padrão mais largamente
utilizado, segundo a literatura analisada [FGD99], onde pode-se encontrar diversos links de
sistemas que consideram este padrão na descrição de seus dados.
2.7.1 O P ADRÃO FGDC
O Federal Geographic Data Committee (FGDC) [FGD99] adotou um padrão de conteúdo
para metadados, o Content Standard for Digital Geospatial Metadata (CSDGM) [MSD99],
que é um padrão de metadados espaciais desenvolvido para suportar a National Spatial Data
Infrastructure [Tos98]. Este padrão provê um meca nismo consistente e formal para a
descrição das características dos dados.
O padrão CSDGM da FGDC [MSD99], especifica as informações contidas nos
metadados para um conjunto de dados geo-espaciais digitais. O propósito deste padrão é
prover um conjunto de terminologias e definições para a documentação de dados geoespaciais. Este padrão especifica informações que auxiliam os prováveis usuários a determinar
quais dados existem, as qualidades destes dados para suas aplicações, e as condições de acesso
destes dados [VMR99]. Este padrão define elementos de dados a serem usados com estes
propósitos. Aparentemente o CSDGM se apresenta bastante complexo. As principais
subdivisões deste padrão, como podem ser vistos na Figura 2.7, são [HP98]:
•
Informação de Identificação: Título do conjunto de dados, área coberta, palavraschave, propósito, resumo, restrições de acesso e de uso.
•
Informação da Qualidade do Dado: Correta localização horizontal e vertical,
completude e linearidade do conjunto de dados.
•
Informação da Organização dos Dados Espaciais: Dados tipos raster, vetor, ou
uma ligação indireta a sua localização.
•
Informação da Referência Espacial: Latitude, longitude, sistema de coordenadas
ou projeção de mapa.
•
Informação das Entidades e Atributos: Definições e atributos do conjunto de
dados.
•
Informação de Distribuição: Distribuidor, formato dos arquivos de dados, tipos
de mídia off-line, ligação para os dados on-line, taxas.
______________________________________________________________________________________
31
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
•
Informação de Referência dos Metadados: Quem criou os metadados e quando.
Metadados
1.
Informação de
Identificação
2.
Informação da
Qualidade do
Dado
3.
Informação da
Organização dos
Dados Espaciais
4.
Informação da
Referência
Espacial
5.
Informação das
Entidades e
Atributos
6.
Informação de
Distribuição
7.
Informação de
Referência aos
Metadados
Legendas
Obrigatório
Obrigatório
se Aplicável
Opcional
Caixa 3-D
Indicando
Campos de
Entrada de
Dados
Figura 2.7 – Elementos de dados do padrão FGDC
Adicionalmente apresentam-se outras seções menos usadas:
•
Informação de Citação: Diz respeito à origem dos dados, título, data de
publicação e editor.
•
Informação do Período de Tempo: Datas simple s, datas múltiplas e intervalo de
datas.
•
Informação de Contato: Pessoa de contato e/ou organização, endereço, telefone,
e-mail.
Estas seções menores não são obrigatórias e nunca são usadas sozinhas, sendo muitas
vezes inseridas em uma das seções principais, como um bloco (as mesmas não aparecem na
______________________________________________________________________________________
32
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Figura 2.7). Alguns elementos do padrão de conteúdo são denominados de elementos
compostos, porque possuem pais que são compostos ou porque eles mesmos possuem outros
sub-elementos. Verifica-se, também na mesma figura, que apesar da existência de várias
seções neste padrão, as únicas obrigatórias são as seções: Informação de Identificação e
Informação de Referência dos Metadados.
A especificação baseada em seções, como mostrada acima, descreve cada entidade
espacial no SGBD Geográfico. Uma especificação completa de cada um destes itens, incluindo
um arquivo template, pode ser encontrada em [ATM02].
Uma importante informação diz respeito a que mesmo os metadados estando em
conformidade com o CSDGM, eles não se apresentam sempre da mesma forma. Isto porque
CSDGM especifica apenas o conteúdo dos metadados, não o seu formato. Existem algumas
ferramentas como, por exemplo, o TKME [Sch00, Sch02], que auxiliam a tarefa de
especificação de metadados dentro deste formato. Este sistema lê os metadados e os põe no
formato consistente, com os elementos identificados e nomeados que possam ser lidos, desta
forma, por outras ferramentas de metadados.
2.7.2 Outras Propostas
O Comitê Técnico para Padrões SIG Globais da Organização Internacional de Padronização
ISO/TC211 [ISO99] está desenvolvendo um padrão integrado que promova a
interoperabilidade global entre SIG. A primeira versão do Padrão CSDGM foi o primeiro
“rascunho” do padrão ISO 15046-15. O principal objetivo deste padrão é estabelecer um
conjunto de informações padrões referentes a fenômenos e objetos que estejam direta ou
indiretamente associados com a sua localização relativa à Terra [ISO99]. Os elementos de
metadados neste padrão são divididos nas seguintes subseções: Informação de Identificação,
Informação de Referência Espacial, Informação da Representação Espacial, Informação de
Atributos e da Característica, Informação da Distribuição, e Informação da Referência de
Metadados. Devido à diversidade dos dados geográficos, nenhum conjunto simples de
elementos de metadados irá satisfazer todos os requisitos. É importante salientar que este
padrão não está sendo desenvolvido pela academia. Cada elemento de metadado está sendo
selecionado para atingir uma determinada necessidade e estas necessidades estão sendo
analisadas em experiências reais.
______________________________________________________________________________________
33
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
O padrão SDTS – Spatial Data Transfer Standard [SDT99], se apresenta como uma
maneira robusta de transferir dados espaciais entre sistemas de computadores diferentes
afirmando apresentar o potencial de nenhuma perda de informação. É um padrão de
transferência que abrange a filosofia de transferências de: autoconteúdo, dados espaciais,
atributos, geo-referências, relatórios de qualidade dos dados, dicionários de dados, e outros
metadados de suporte associados com a transferência. O padrão SDTS é neutro, modular,
extensível, orientado a crescimento e flexível, ou seja, possui todas as características de
padrões de sistemas abertos. Um mecanismo de transferência de dados espaciais efetivo deve
prover a codificação e o intercâmbio de todas estas características e componentes de banco de
dados espaciais entre plataformas de computação diferentes. SDTS foi designado para
atender a este objetivo sem a perda e a corrupção de dados no processo de transferência.
O ESMI [ESM98, CEN99] foi fundado pela Comissão Européia e teve como iniciativa
original estabelecer em um ambiente formal, dentro de interesses de organizações públicas e
privadas, serviços de metadados universais para informações geográficas. ESMI propõe então
uma implementação de metadados baseada em padrões existentes que permitam que serviços
de metadados sejam encontrados na Internet. Para o objetivo do padrão ESMI ser alcançado
é necessário que os provedores de metadados geográficos utilizem métodos e ferramentas de
conversão de seus serviços existentes ou que projetem novos serviços que sejam compatíveis
com o ESMI. Certos elementos de metadados ESMI necessitam ser incluídos no serviço de
metadados destes provedores. Estes elementos de metadados são os mesmos normalmente
utilizados nos padrões ISO/TC211, CEN/TC287 ou FGDC. O padrão ESMI fornece
ferramentas que auxiliam neste processo de criação, conversão e manutenção de metadados.
2.7.3 Modelo Abstrato de Metadados OGC
A habilidade de armazenar metadados para cada coleção de feições é provida pela requisição
dos relacionamentos entre uma coleção de feições e a coleção de metadados. Da mesma
forma, a habilidade de armazenar metadados para cada feição individual é provida pelo
relacionamento entre cada feição e o conjunto de metadados [OGC99XI].
Cada entidade de metadados normalmente contém atributos que armazenam valores
dos elementos metadados. Muitas sub-classes ou tipos de classes da entidade metadado
podem ser definidos, onde cada sub-classe armazena um tipo diferente da entidade metadado.
______________________________________________________________________________________
34
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Uma Coleção de Feições tem um relacionamento novo com o conjunto de metadados.
Este relacionamento é necessário e armazenado por uma propriedade obrigatória da coleção
de feições com o respectivo nome do metadado. O valor da propriedade de metadado é o ID
do conjunto de metadados associado.
Uma feição também tem um relacionamento novo com o conjunto de metadados. Este
relacionamento é opcional, e é incluído apenas quando a informação de metadado está
associada com a feição individual. Este relacionamento é armazenado por uma propriedade
obrigatória da feição, com o respectivo nome do metadado. O valor da propriedade do
metadado é nulo se todos os metadados estiverem associados à coleção de feições em que a
feição se encontra.
O Conjunto de Metadados contém, ou é relacionado com, uma coleção de entidades
de metadados. Estes relacionamentos são armazenados no conjunto de metadados utilizandose um atributo da feição que contenha uma seqüência de IDs de todas as entidades de
metadados. Cada conjunto de metadados é relacionado com uma ou mais coleções de feições
ou de feições simples, mas estes relacionamentos precisam ser armazenados pelo conjunto de
metadados.
A Entidade de Metadado normalmente contém um conjunto de atributos de feição que
armazenam os valores de um grupo lógico de elementos de metadados. Cada item de
metadado é armazenado como um nome e um par de valores de objetos atributos. A classe
entidade de metadado define apenas os atributos que são comuns a todas as subclasses. Cada
entidade de metadado é relacionada com um ou mais conjuntos de metadados, mas estes
relacionamentos não precisam ser armazenados dentro da entidade de metadados. Isto pode
ser feito seguindo as seguintes regras de comportamento [OGC99XI]:
•
Toda vez que um objeto entidade de metadado, definido e aplicável, não estiver
incluído no conjunto de metadados, este metadado deve ser interpretado como
desconhecido ou não especificado.
•
A maioria dos atributos do conjunto de metadados deve ser somente de leitura.
Certamente estes atributos serão modificados durante ou imediatamente depois da
criação do objeto, antes que novos objetos possam se relacionar com outros objetos.
______________________________________________________________________________________
35
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
•
Um conjunto de metadados é fornecido para uma feição inteira, a qual contém
múltiplos componentes. Por exemplo, uma feição freqüentemente contém uma
geometria que pode conter múltiplos pontos ou vértices. O armazenamento de um
conjunto de metadados por cada feição significa que:
o Os metadados associados a todos os componentes das feições são similares.
o O usuário não tem nenhuma maneira prática de usar os metadados, desta
forma, cada parte deve ser armazenada como uma feição separada. O
armazenamento da feição composta é formado por todas as feições
menores.
2.7.4 P ERSPECTIVAS F UTURAS
Algumas companhias já estão publicando seus dados espaciais e metadados na World Wide
Web (WWW). Estas companhias são conhecidas como Geospatial Data Clearinghouses, ou
seja, um repositório de dados geo-espaciais. Pode-se encontrar em [Mon99] bons exemplos
de descrições de dados geo-espaciais através do padrão de conteúdo FGDC. O Open GIS está
trabalhando em conjunto com o FGDC na especificação do padrão ISO/TC 211, mencionado
anteriormente, para juntos desenvolverem um padrão formal e global de metadados espaciais.
Com o crescimento da Internet e de arquiteturas de software distribuídos o
compartilhamento e a análise de recursos de informações digitais têm demandado muita
pesquisa. Contudo, como conseqüência deste fenômeno, problemas adicionais têm sido
estudados de modo a prover buscas inteligentes de informações sem sobrecarregar os usuários
com quantidades excessivas de dados.
2.8 C ONCLUSÃO
Este Capítulo teve como objetivo introduzir os conceitos principais dos Sistemas de
Informação Geográfica de modo a caracterizar a problemática a ser analisada e as diversas
tecnologias que serão utilizadas nesta tese. Foi apresentado como se caracterizam os dados
em SIG, e como os mesmos são representados graficamente. Também foram citadas as
diferentes metodologias utilizadas na definição de linguagens de consultas para este tipo de
sistema.
______________________________________________________________________________________
36
Capítulo 2 - Sistemas de Informações Geográficas, Modelos e Padrões
________________________________________________________________________________________________
Foi apresentada a proposta do Consórcio OpenGIS como uma opção a ser utilizada
neste trabalho por unir conceitos e metodologias que atendem às necessidades básicas de
definição do Sistema GeoVisual, além de ser uma proposta bem definida e abrangente.
O Padrão de Metadados Espaciais que foi selecionado para este trabalho foi o
FGDC/CSDGM [FGD99], devido à grande variedade de informações disponíveis sobre o
mesmo, onde se pode encontrar além de definições formais do padrão, também várias
referências a sistemas que já o estão utilizando.
O padrão FGDC é compatível com a proposta de utilização de metadados na
especificação OGC. O Modelo Essencial de Dados Geográficos do Open GIS [OGC98a]
[OGC99a] complementa as informações básicas necessárias à definição do Sistema GeoVisual
e oferece suporte ao desenvolvimento da Linguagem de Consulta Visual.
______________________________________________________________________________________
37
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
CAPÍTULO 3
LINGUAGENS DE CONSULTAS ESPACIAIS
E SISTEMAS DE
CONSULTAS V ISUAIS
“Diante do colar belo como um sonho, admirei, sobretudo,
o fio que unia as pedras e se imolava anônimo para
que todos fossem um”.
Dom Helder Câmara
3.1 I NTRODUÇÃO
Integrar dados espaciais e não-espaciais associados com aplica ções geográficas com o objetivo
de tornar as diferentes estruturas de dados geográficas mais compatíveis entre si, como
também tornar os mecanismos de busca mais efetivos, têm sido alguns dos objetivos de
pesquisa em SIG nos últimos anos. Algumas soluções propostas tendem a estender padrões já
largamente aceitos, incorporando características espaciais em aplicações geográficas.
Extensões espaciais ao padrão SQL, por exemplo, acrescentam operadores espaciais às novas
linguagens mantendo a filosofia relacional do SQL. As linguagens de consultas espaciais
possuem características próprias devido à natureza espacial dos dados a serem manipulados.
Como já anteriormente citado, a linguagem SQL não apresenta, em sua natureza,
operações topológicas e métricas sobre dados espaciais, tais como, intersecção de regiões, ou
operações de distância e localização sobre uma determinada região. Um usuário, por
38
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
exemplo, pode requerer informações sobre uma área onde duas ou mais regiões armazenadas
no banco de dados estão envolvidas.
Muitas extensões de SQL, que têm sido propostas na literatura, apresentam como
principal objetivo, dentre outros, incorporar informações espaciais no projeto de bancos de
dados relacionais [AG97]. Duas metodologias têm se destacado: adicionar atributos de tipos
de dados espaciais às relações, e incorporar informações espaciais nos valores de atributos
não-espaciais.
3.2 Relações entre Objetos Espaciais
Sabe-se que consultas a bancos de dados geográficos são freqüentemente baseadas em
relacionamentos entre objetos espaciais e a maioria dos bancos de dados comerciais não
suporta este tipo de consulta. Caracterizam-se, a seguir, os relacionamentos dos tipos
topológicos, direcionais e temporais entre objetos espaciais.
3.2.1 Relações Topológicas entre Objetos Espaciais
Um dos conceitos fundamentais necessários à análise de dados espaciais em bancos de dados
geográficos é o entendimento formal dos relacionamentos topológicos entre objetos espaciais
arbitrários [EH91, WF02]. Relacionamentos topológicos entre objetos se preservam mesmo
após transformações topológicas tais como translação, rotação, e mudança de escala.
Informações topológicas são propriedades puramente qualitativas e excluem qualquer
consideração de medidas quantitativas. Por exemplo, dois lotes de terra são vizinhos se
compartilharem um limite comum e o relacionamento de vizinhança é independente do
comprimento deste limite compartilhado ou do número de lados comuns. É bom lembrar que
equivalências topológicas não preservam distâncias e direções [EH91]
Pode-se dizer também que a topologia é um conjunto de técnicas que nos permite
perceber as relações espaciais inerentes ao posicionamento relativo dos objetos, independente
de suas dimensões ou coordenadas exatas. Então, relações de pertinência (contém, contido),
adjacência (vizinho, ao lado de), e conexão (conectado a, ligado a, relacionado com) são
deduzidas com base em técnicas de topologia.
Quando se fala em relacionamentos espaciais, depara-se com uma dificuldade que
existe em entrar num consenso a respeito das apresentações visuais que denotam essas
relações: dentro de, cruza, toca, vizinho a, em frente a, corta, atravessa, pertence e contém.
Apesar de todos nós termos um conhecimento bastante intuitivo sobre o significado dessas
39
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
relações, muitas vezes pessoas diferentes podem selecionar um conjunto diferente de
representações para essas relações. Como exemplo prático, tem-se a Figura 3.1 que mostra
diferentes interseções entre uma linha e um polígono [Dav01]. Qual dessas representações
melhor identifica que a linha cruza o polígono? Muitas vezes a resposta a esta pergunta é
resultado de alguma convenção ou acordo adotado.
Figura 3.1 – Diferentes cruzamentos entre linha e polígono [Dav01]
3.2.1.1 Modelo de 9-Interseções
Uma metodologia formal de entendimento dos relacionamentos topológicos binários entre
regiões (polígonos regulares), linhas e pontos foi desenvolvida e é baseada na comparação de
9 interseções entre os interiores, limites e exteriores de dois objetos [EH91, ME94]. O
critério básico de distinção entre dois relacionamentos topológicos utilizados por esta
metodologia verifica se a interseção entre estes limites, interiores e exteriores dos dois objetos
é vazia ou não, identificando desta forma, 29 (512) relacionamentos topológicos mutuamente
exclusivos e exaustivos.
Egenhofer e Herring, [EH91], definiram uma formalização para relações binárias em
um espaço bi-dimensional IR2 entre objetos geométricos, por exemplo, entre duas linhas ou
entre uma linha e uma região. Um modelo de dados espacial algébrico-topológico, utilizado
neste formalismo, considera elementos geométricos primitivos chamando-os de células, que
são definidos por suas dimensões: um objeto 0-célula é um nó (o menor objeto geométrico
possível); um objeto 1-célula é uma ligação entre dois objetos 0-célula; e um objeto 2-células
é uma área descrita pela seqüência fechada de três (ou mais) objetos de 1-célula disjuntos. As
definições a seguir são importantes [ME94]:
40
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
a) Um ponto é definido como uma única célula em um espaço IR2, que não apresenta
limites, seu interior é definido como sendo a sua única célula, e o exterior, é a
diferença entre o espaço IR2 e a sua célula.
b) Uma linha é uma seqüência de 1..n células conectadas entre dois nós independentes
que não se cruzam entre si nem formam ciclos. Nós que se posicionam exatamente
onde as células iniciam e terminam podem ser referenciados como os limites da linha.
O interior da linha é definido como a união de todos os nós interiores e de todas as
conexões entre esses nós. O exterior da linha é a diferença entre o espaço IR2 e a
união do limite e do interior da linha.
c) Uma região é definida como células homogeneamente conectadas em um espaço bidimensional, que pode ser chamado de polígono. Seu limite forma uma curva que
separa o seu exterior do seu interior.
O modelo de 9-interseções descreve as relações topológicas binárias em termos das
interseções dos interiores (I), limites (L) e exteriores (E) entre dois objetos espaciais. As nove
possíveis interseções entre cada uma das três partes dos objetos são preservadas sob
transformações topológicas e provêem um ambiente para a descrição formal de suas relações
topológicas. Isto pode ser representado através de uma matriz 3x3, como mostra a Figura
3.2.
Células da Matriz
Objeto 1
I
L
E
I
L
E
Objeto 2
Figura 3.2 – A matriz 3x3 das 9-interseções
De acordo com a representação proposta por Egenhofer [EH91, ME94] são utilizadas
algumas notações para representar o interior (I), o limite (L) e o exterior (E) dos objetos
espaciais envolvidos. O limite de um objeto A é denotado por ∂A, o interior de um objeto A é
denotado por A o e o exterior do objeto A é denotado por A- .
41
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
A relação topológica binária R entre dois objetos A e B é baseada na comparação entre
o interior de A (Ao), o limite de A (∂A), e o exterior de A (A- ) com o interior de B (Bo), o
limite de B (∂B), e o exterior de B (B- ). Cada conjunto das combinações possíveis dos valores
(0 e 1) da matriz identifica uma única relação topológica entre dois objetos. Cada elemento
linha/coluna da matriz representa uma interseção possível entre as partes dos objetos
envolvidos na relação:
•
A interseção do interior de A com o interior de B (A°∩B°)
•
A interseção do interior de A com o limite de B (A°∩∂B)
•
A interseção do interior de A com o exterior de B (A°∩B- )
•
A interseção do limite de A com o limite de B (∂A ∩ ∂B)
•
A interseção do limite de A com o interior de B (∂A ∩ B°)
•
A interseção do limite de A com o exterior de B (∂A ∩ B- )
•
A interseção dos dois exteriores (A- ∩ B- )
•
A interseção do exterior de A com o limite de B (A- ∩ ∂B)
•
A interseção do exterior de A com o interior de B (A - ∩ B°)
Cada conjunto de possíveis valores da matriz de 9-interseções descreve uma relação
topológica diferente, e relações que tenham os mesmos valores da matriz são consideradas
topologicamente equivalentes.
Para o modelo das 9-interseções, o conteúdo de cada
elemento da matriz é identificado como um modelo mais simples e geral, caracterizando cada
interseção pelo valor vazio (∅) ou não-vazio (¬∅).
Para cada uma dessas nove interseções serem vazias ou não, o modelo é capaz de
representar 512 (29) possíveis relações entre esses objetos. Mas, a maioria dessas combinações
é impossível de ser encontrada, devido a certas regras geométricas, em um plano
bidimensional.
Entre uma linha e uma região, por exemplo, distinguem-se apenas 19
possíveis relações topológicas que são mostradas na Figura 3.3. [ME94].
42
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Figura 3.3 – Representação geométrica das 19 interseções possíveis entre uma linha e uma
região através do método da matriz das 9-interseções [ME94]
Mark e Egenhofer [ME94] realizaram um estudo comparativo para as 19 possíveis
relações entre uma região e uma linha (Figura 3.3), comparando-as com um possível parque e
uma rodovia. Desse estudo comparativo, chegou-se à conclusão, através da entrevista com
três grupos de usuários de nacionalidades diferentes, que dessas 19 relações, três conjuntos
diferentes de situações topológicas reais entre uma rodovia e um parque se destacaram. O
primeiro grupo da relação mostra a situação em que “uma rodovia entra no parque”; o
segundo grupo lembra a situação em que “a rodovia cruza o parque¨, e o terceiro grupo foi
43
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
identificado por não fazer parte de nenhum dos grupos anteriores. O segundo grupo
escolhido que representou a variação do operador crosses é ilustrado a seguir na Figura 3.4.
¬Ø Ø Ø
Ø ¬Ø Ø
¬ Ø ¬Ø ¬Ø
¬ Ø ¬Ø ¬ Ø
Ø ¬Ø Ø
¬ Ø ¬Ø ¬Ø
¬ Ø ¬Ø Ø
Ø ¬Ø Ø
¬ Ø ¬Ø ¬Ø
¬ Ø ¬Ø ¬ Ø
Ø ¬Ø ¬ Ø
¬ Ø ¬Ø ¬Ø
¬ Ø ¬Ø ¬Ø
Ø Ø ¬Ø
¬ Ø ¬Ø ¬Ø
Figura 3.4 – Concordância de que a Rodovia cruza o Parque
No Capítulo 5 são definidos os relacionamentos espaciais que serão abordados na
linguagem GeoVisualQL. Cada relacionamento topológico da linguagem será definido através
deste formalismo 9-intersection (9IM) [EH91, ME94, EM95] aqui apresentado.
3.2.2 Relações Direcionais entre Objetos Espaciais
Relações Direcionais constituem uma classe especial de relacionamentos espaciais que
descrevem a ordem de objetos no espaço. A grande disponibilidade de dados espaciais de
várias fontes e de vários formatos combinados com o avanço de bancos de dados espaciais e
de sistemas de informação geográfica, criaram a necessidade de responder questões que
envolvem relações de direção e outras relações espaciais [PE97].
Ao contrário de relações topológicas entre objetos espaciais, para as quais existem um
conjunto de relações largamente utilizadas tanto na literatura de pesquisa como em produtos
comerciais, não existem definições universalmente aceitas para relações direcionais [PES00].
Na geografia, embora termos linguísticos utilizados para descrever as relações
direcionais entre pares de países sejam indiscutíveis (todo mundo concorda que a Alemanha
44
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
fica ao norte da Itália), isto não acontece sempre. Por exemplo, considere a questão:
"encontre todos os países que ficam ao norte da Itália". Será que a França entraria nesse
conjunto, ou será que a mesma está ao nordeste da Itália, e não ao norte? Estas questões são
respondidas dependendo das definições tomadas a respeito das relações de direção, que
podem variar para cada aplicação [TPS96].
Quando utiliza-se dados espaciais em SIG os usuários têm que saber a respeito dos
tipos geométricos que os representam de modo a poder aplicar os operadores apropriados.
Isto porque as semânticas e as definições das relações espaciais podem variar dependendo da
representação geométricas dos dados espaciais [GE00].
Um modelo chamado de Matriz de Relação-Direção (DRM - Direction-Relation
Matrix) [GE00] foi introduzido para capturar as direções cardinais que distingue as relações
direcionais entre pontos, linhas e polígonos. A vantagem desse modelo integrado de direções
é que o mesmo se aplica para diferentes tipos de dados espaciais.
Ao contrário de direções quantitativas, que se referem a valores numéricos em graus,
minutos e segundos, direções cardinais são relações espaciais qualitativas e são baseadas em
um pequeno conjunto de símbolos.
Uma relação cardinal, no modelo DRM, é uma tripla <A, d, B>, onde A e B são o
objeto de referência e o objeto destino, respectivamente, e d é um subconjunto não vazio de
nove símbolos (N, S, E, W, NE, SE, NW, SW, 0), que representam, respectivamente: norte,
sul, leste, oeste, nordeste, sudeste, noroeste, sudoeste, e posição central (Figura 3.5).
NWA
WA
NA
0
B NEA
EA
A
A
SWA
SA
SEA
Figura 3.5 - Partições ao redor de um objeto de referência A
45
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
As relações cardinais entre dois polígonos, por exemplo, capturam a vizinhança de
uma partição ao redor do objeto de referência e registra as interseções entre o objeto destino
e as partições ao redor do objeto, como mostra a matriz DIR abaixo.
NWA ∩ B
DirRR (A,B) =
NA ∩ B
NEA ∩ B
WA ∩ B
WA ∩ B
EA ∩ B
SW A ∩ B
SA ∩ B
SEA ∩ B
Por exemplo, dada a Figura 3.5, a matriz DIR desta representação apresenta os
seguintes valores:
DirRR (A,B) =
∅
∅
∅
¬∅
∅
∅
¬∅
¬∅
∅
Isto porque, o objeto destino B se encontra parcialmente ao norte, nordeste e a leste
do objeto de referência A, por isso os valores diferentes de vazio na matriz. Uma matrizdetalhada de relações de direções é uma matriz que reflete o quanto o objeto destino se
posiciona em relação às partições ao redor do objeto de referência [GE01]. A matriz mostra
percentagens calculadas da seguinte forma:
DirRR (A,B) =
area(NWA ∩ B) area(NA ∩ B) area(NEA ∩ B)
area(B)
area(B)
area(B)
area(W A ∩ B) area(OA ∩ B) area(EA ∩ B)
area(B)
area(B)
area(B)
area(SWA ∩ B) area(SA ∩ B) area(SEA ∩ B)
area(B)
area(B)
area(B)
Por exemplo, para a Figura 3.5, a matriz apresenta os seguintes valores:
46
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
DirRR(A,B) =
∅
∅
∅
0.05
∅
∅
0.45
0.50
∅
Através deste modelo, medidas de distâncias podem ser introduzidas entre duas
direções cardinais. Um grafo conceitual de vizinhança, para um conjunto de relações espaciais
mutuamente exclusivas, serve como base para cálculo dessas distâncias entre relações deste
conjunto. Este grafo, apresenta um vértice para cada direção cardinal e um arco para cada
par de relações cardinais que são horizontal ou verticalmente adjacentes. Mudanças contínuas
de relações cardinais seguem um caminho através deste grafo conceitual de vizinhança.
Também, através deste modelo, pode-se determinar o menor caminho entre duas posições
cardinais [GE01].
Relações direcionais em SIG têm sido pesquisadas e diversos modelos têm sido
propostos de modo a definir soluções para as questões direcionais existentes entre objetos
espaciais [PE97, PES00, GE00, GE01, TPS+ 95, TPS96]. Estas questões dizem respeito a:
técnicas de otimização de consultas durante o processamento de relações de direção;
determinação do menor caminho entre posições cardinais em relação a um objeto de
referência; cálculos de distância entre posições; similaridades cardinais; recuperação de
relações de direção em bancos de dados espaciais; entre outras aplicações. Cada um destes
modelos apresenta características
inovadoras e limitações que precisam ser levadas em
consideração na escolha de um deles para uso em uma determinada aplicação.
3.2.3 RelaçõesTemporais entre Objetos Espaciais
Fenômenos geográficos mudam constantemente através do tempo e do espaço. Uma das
maiores limitações dos Sistemas de Informação Geográfica atuais é que os mesmos capturam
apenas uma cena da realidade, pelo fato de que os mesmos trabalham com bancos de dados
que armazenam apenas o dado atual [HE00]. Aspectos temporais de SIG têm sido
investigados a partir de perspectivas de cartografia, modelos de dados e bancos de dados
espaciais, embora ainda nenhum modelo que inclua dados temporais em SIG tenha sido
largamente adotado [HE00].
47
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
As pessoas vêem o mundo através de difere ntes níveis de detalhes, cada um abtraindo
do mesmo aquilo que lhe interessa. Entidades geográficas podem ser percebidas através de
diferentes níveis de detalhes temporais e podem ser tratadas como objetos. Uma linguagem de
descrição de mudanças (Change Description Language - CDL) [HE99] é definida e é baseada
em uma classificação de alterações em objetos discretos, através de mudanças na identidade
dos objetos. Identidades de objetos provêem uma maneira de representar a individualidade e
a unicidade de um objeto, independente de seus atributos e de seus valores.
A linguagem CDL utiliza símbolos para representar os elementos básicos do modelo,
bem como as combinações destes elementos. Estes elementos, ou primitivas, são baseados nos
estados de identidade dos objetos e são fundamentadas na noção de existência. Existência,
neste caso, se refere a presença física ou ocorrência de um objeto, ou, no caso de objetos
conceituais, a certeza da percepção do objeto [HE99].
Também pode-se caracterizar a não-existência de um objeto. Diferencia-se dois
estados de não-existência de objetos: não-existência sem história e não-existência com
história (Figura 3.6). Estas definições caracterizam o caso de objetos que não existem e nunca
existiram, e o outro caso em que os objetos não mais exsitem, mas já existiram em algum
tempo passado.
A
(a)
A
(b)
(c)
Figura 3.6 - (a) Existência de um objeto A; (b) Não-existência de um objeto, sem história; (c)
Não-existência de um objeto, com história.
Mudanças temporais são modeladas de uma maneira qualitativa baseada na ordem de
eventos. A mudança entre um estado de identidade para outro é representado através de uma
seta que é chamada de transição. Os cenários entre identidades de objetos são definidos da
esquerda da seta até a direita onde o estado da esquerda é chamado de antes e, o da direita,
de depois (Figura 3.7).
48
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
A
A
Figura 3.7 - Transição entre dois estados de identidade de um objeto
Um conjunto de operações entre estados de identidade de objetos é definido através
de combinações sistemáticas de primitivas que capturam as semânticas das operações de:
criação, continuação da existência, eliminação, destruição e recriação.
Linguagens de consultas temporais para SIG focam a habilidade de responder
questões como:
•
Qual o estado de um fenômeno em um determinado tempo t?
•
Quais localizações têm sido afetadas pelo fenômeno através do período de
tempo ? t?
•
Quais fenômenos exibem a característica do tempo t?
A descrição de fenômenos espaços-temporais com respeito às mudanças abre as portas
ao entendimento da semântica associada com essas mudanças. Cenários de mudanças entre
objetos podem ser modelados e as seqüências de operações comparadas. Operações de
mudança de alto nível podem ser derivadas através de um processo de combinação
sistemática de possíveis estados de identidade de objetos antes e depois de transições.
Diferentes propostas de modelagem de relacionamentos temporais têm sido
apresentadas, mas ainda nenhuma delas foi adotada como padrão [HE00, HE99, BTAL99,
MV02].
3.3 Propostas de Extensão do padrão SQL
Dados espaciais possuem propriedades adicionais, tais como geometria e representação
gráfica, que os usuários precisam manipular em uma linguagem de consulta. Os
relacionamentos espaciais e as operações nas linguagens de consultas espaciais têm
importância reconhecida, como também a álgebra relacional possui extensões para dados
geográficos, como por exemplo a Geo-Relational Algebra [Gut88].
Foram abordadas algumas propostas de extensão do SQL para dados espaciais em
[Soa01]. A seguir abordam-se apenas as mais relevantes ao nosso trabalho.
49
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
3.3.1 S PATIAL SQL
Segundo Egenhofer [Ege94], uma linguagem de consulta espacial deve ser muito mais do que
a simples equação:
Linguagem de Consulta + Relacionamentos Espaciais = Linguagem de Consulta Espacial
No contexto de manipulação de dados espaciais, as linguagens de consulta devem ser mais do
que apenas uma solução de recuperação de dados. Uma apresentação apropriada dos dados
espaciais deve fazer parte da especificação de uma linguagem de consulta espacial.
O objetivo principal de Spatial SQL é o de prover abstrações de dados espaciais de alto
nível, em uma linguagem de consulta, incorporando conceitos próximos aos seres humanos
como o pensamento a respeito do espaço em que vivemos.
Em Spatial SQL, o domínio do cálculo relacional é estendido e o novo domínio
espacial provê um alto nível de abstração de dados espaciais na interface. Foram
desenvolvidos na Spatial SQL apenas um subconjunto da Álgebra Espacial [Gut88] e algumas
definições formais de relacionamentos espaciais.
Tem sido demonstrado que o uso de SQL puro para algumas consultas espaciais
[Ege92] tem se tornado uma tarefa árdua e sintaticamente muito complexa. O tratamento de
dados espaciais como sendo abstrações de mais alto nível do que dados do tipo inteiro e
string requer um tratamento apropriado de geometria. Embora algumas operações, tal como
o cálculo da distância Euclidiana entre dois pontos, possa ser familiar para uma grande
comunidade de usuários, assim como a sua implementação também possa ser largamente
divulgada, outras operações são claramente bem mais complexas. Usuários menos
familiarizados com certos termos matemáticos podem ter dificuldade em usar alguns critérios
geométricos.
Operadores espaciais unários acessam uma propriedade espacial de uma tupla ou de
uma relação espacial. Um operador espacial unário pode ser considerado uma função sobre
um atributo espacial. Algumas funções unárias importantes são: limite (boundary) que indica
as faces limites do objeto O n-dimensional, ou seja, tudo o que faz parte dos limites de O.
Complementando a função limite, tem-se a função interior que calcula o interior das faces,
ou seja, tudo o que não estiver nos limites do objeto O nem no seu exterior.
50
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Um outro conjunto de operadores unários trabalha com operações aritméticas e
depende da dimensão do objeto. Este conjunto de operações consiste em comprimento de um
objeto de uma dimensão, e área e volume para objetos de duas e três dimensões,
respectivamente. Outros atributos complexos podem ser derivados como uma combinação de
propriedades topológicas e aritméticas tais como o perímetro de um polígono, que pode ser
definido como o somatório dos comprimentos de seus lados.
Operadores espaciais binários calculam o valor entre duas tuplas de relações espaciais,
de forma similar às operações aritméticas de adição e multiplicação. Exemplos de operadores
binários incluídos na definição de Spatial SQL são distância e direção. Distâncias podem ser
subtraídas, adicionadas, multiplicadas por algum escalar, comparadas, e ordenadas. Direções
podem ser comparadas com o uso de alguns operadores e subtraídas de determinados
ângulos. As funções agregadas são mínimo e média e podem ser aplicadas tanto aos
operadores distância como direção.
Relacionamentos espaciais binários são relacionamentos entre dois atributos espaciais.
Comportam-se como relacionamentos binários comuns e resultam em um valor booleano.
Relacionamentos binários topológicos são baseados no conjunto de interseções de limites e
interiores dos dois objetos em questão. Exemplos de relacionamentos topológicos são:
disjunto,
encontra,
sobrepõe,
dentro_de
/contém,
cobre/é_coberto_por,
e
igual.
Relacionamentos possíveis de ordem, direção ou orientação são: esquerda/direita, norte/sul, e
acima/abaixo.
Spatial SQL [Ege94] apresenta ao usuário uma linguagem de apresentação gráfica que
provê ferramentas de manipulação da apresentação gráfica dos resultados das consultas. O
conceito central da linguagem de apresentação gráfica (Graphical Presentation Language –
GPL) está baseado na idéia de ambiente de edição, onde se manipulam as informações de
como exibir os resultados das consultas. Distinguem-se seis tipos diferentes de especificação
gráfica em GPL: (1) o modo de exibição; (2) a apresentação gráfica; (3) a escala do desenho;
(4) a janela a ser mostrada; (5) o contexto espacial, e (6) a exibição do conteúdo.
3.3.2 ESPECIFICAÇÃO SQL DO OPEN GIS
O propósito da especificação SQL do Open GIS é definir um esquema SQL padrão que
suporte o armazenamento, recuperação, consulta e atualização de coleções de feições
51
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
(features) geo-espaciais simples. Uma feição simples definida através da Especificação Abstrata
Open GIS [OGC98a, OGC99a] apresenta tanto atributos espaciais como não-espaciais.
Atributos espaciais possuem valores geométricos, onde feições simples são baseadas em
geometrias 2D com interpolação linear entre os seus vértices.
As feições geo-espaciais simples são conceitualmente armazenadas em tabelas, com
colunas apresentando valores geométricos, em um banco de dados relacional, onde cada
feição está armazenada em uma linha desta tabela. Os atributos não-espaciais são mapeados
dentro de colunas cujos tipos são definidos a partir do padrão de tipos ODBC/SQL92
[OGC99b]. Uma tabela, cujas linhas representam as feições Open GIS, pode ser referenciada
como Tabela de Feições (Feature Table).
Esta especificação descreve um conjunto padrão de tipos geométricos SQL baseados no
Modelo Geométrico Open GIS [OGC99a], juntamente com as funções SQL em conjunto com
estes tipos.
Esta extensão do SQL92 suporta consulta padrão a metadados que retornam:
1. A lista de tabelas de feições em um banco de dados;
2. A lista de colunas geométricas para qualquer tabela de feição no banco de dados;
3. O sistema de referência espacial para qualquer coluna geométrica no banco de
dados.
O modelo de objetos geométricos Open GIS foi abordado no Capítulo 2 desta tese. Os
atributos, métodos e deduções para cada classe geométrica são descritos a seguir.
A geometria é uma classe abstrata raiz da hierarquia. Todas as subclasses instanciáveis
de Geometria definidas nesta especificação estão restritas às dimensões 0, 1 ou 2. Todas as
classes geométricas são definidas de modo que instâncias válidas de uma classe geométrica
sejam topologicamente fechadas.
52
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
3.3.2.1 Métodos Básicos da Classe Geometria
A classe Geometria apresenta diversos métodos que estão descritos em [OGC99b].
Selecionamos alguns desses métodos para exemplificar como seria o funcionamento dos
mesmos.
§
Dimension( ): integer – Retorna a dimensão herdada de um dado objeto geométrico,
o que deve ser menor ou igual à dimensão da coordenada. Esta especificação é restrita
ao espaço de coordenadas de duas dimensões.
§
GeometryType( ):String – Retorna o nome do subtipo instanciável da Geometria, da
qual uma dada instância de Geometria é membro. O nome do subtipo instanciável da
Geometria é retornado como string.
§
Boundary( ):Geometry – Retorna os limites combinatórios de uma dada Geometria.
Devido ao resultado desta função ser uma figura topologicamente fechada, o
resultado dos seus limites pode ser representado usando primitivas geométricas
representativas.
§
SRID( ):Integer – Retorna a Identificação do Sistema de Referência Espacial para uma
dada Geometria.
Outros métodos da classe Geometria que podem ser vistos em [OGC99b]: Envelope():
Geometry; AsText( ):String; AsBinary( ):Binary; IsEmpty( ): Integer; IsSimple(): Integer.
3.3.2.2 Métodos para Teste de Relações Espaciais entre Objetos Geométricos
Os métodos abaixo descritos realizam testes entre dois ou mais objetos geométricos. Todos
eles são bastante úteis e estão também descritos na especificação do OGC [OGC99b]. Alguns
deles estão descritos logo a seguir:
§
Equals(another Geometry:Geometry): Integer – Retorna 1 (Verdadeiro) se uma dada
geometria for espacialmente igual a uma outra geometria passada como parâmetro.
§
Disjoint(another Geometry:Geomety): Integer - Retorna 1 (Verdadeiro) se uma dada
Geometria for espacialmente disjunta de uma outra Geometria passada como
parâmetro.
53
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
§
Intersects(another Geometry:Geometry):Integer – Retorna 1 (Verdadeiro) se uma
dada geometria intersectar espacialmente uma outra Geometria passada como
parâmetro.
Outros métodos que seguem a mesma filosofia destes anteriores, ou seja, retornam
verdadeiro ou falso: Touches( another Geometry: Geometry): Integer; Crosses( another
Geometry: Geometry): Integer; Within( another Geometry: Geometry): Integer; Contains(
another Geometry: Geometry): Integer; Overlaps( another Geometry: Geometry): Integer;
Relate( another Geometry: Geometry): Integer.
3.3.2.3 Métodos de Análise Espacial
Os métodos a seguir, também disponíveis na especificação OGC, realizam análise espacial
entre objetos geométricos. Foi feita uma seleção de alguns deles para se entender a filosofia
de funcionamento dos mesmos.
§
Distance( another Geometry:Geometry):Double – Retorna a menor distância entre
dois pontos em duas geometrias como calculado no sistema de referência espacial de
uma dada geometria.
§
Intersection(another Geometry:Geometry):Geometry – Retorna a geometria que
representa o conjunto de pontos de intersecção entre a Geometria do objeto receptor
da mensagem e uma outra geometria passada como argumento.
§
Union(another Geometry:Geometry):Geometry – Retorna a geometria que representa
o conjunto de pontos da união a Geometria do objeto receptor da mensagem e uma
outra geometria passada como argumento.
Outros
métodos
ConvexHull():Geometry;
de
análise
espacial:
Buffer(distance:Double):Geometry;
Difference(anotherGeometry:Geometry):Geometry;
SymDifference(another Geometry:Geometry):Geometry.
3.3.2.4 Funções SQL
Na especificação SQL do Open GIS, algumas funções foram definidas para atender às
necessidades da descrição do modelo de geodados. Por exemplo, cada elemento de tipo
geometria possui uma representação textual conhecida (Well Know Text) [OGC99b], que
54
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
pode ser usada tanto para a construção de novas instâncias como para conversão de instâncias
existentes da forma textual para o resultado alfanumérico. A representação textual de um
tipo geométrico instanciável deve ser implementada segundo as regras da gramática que está
definida na especificação [OGC99b].
Existem funções que são específicas para a criação de uma instância de Geometria
dada sua representação textual – WKT (Well Know Text). Denota-se SRID (Spatial Reference
System ID) a Identificação do Sistema de Referência Espacial. Algumas funções deste tipo:
§
GeoFromText(geometryTaggedText String, SRID integer):Geometry – Constrói
um valor Geometria dada sua representação textual.
§
PointFromText(pointTaggedText String, SRID integer):Point – Constrói o ponto.
§
PolyFromText(polygonTaggedText String, SRID integer): Polygon – Contrói o
polígono
Outras funções deste mesmo tipo: LineFromText, MpointFromText, MlineFromText,
GeomCollFromText, BdPolyFromText, BdMPolyFromText.
Algumas funções SQL constroem instâncias de Geometria a partir de sua representação
binária conhecida - WKB (Well Know Binary). Exemplos de funções deste tipo:
§ GeoFromWKB(WKBGeometry Binary, SRID Integer):Geometry – Constrói uma
instância de Geometria dada sua representação binária.
§ PointFromWKB(WKBPoint Binary, SRID Integer):Point – Constrói um ponto.
§ PolyFromWKB(WKBPolygon Binary, SRID Integer):Polygon – Constrói um
polígono.
Outras
funções
MLineFromWKB,
deste
mesmo
MPolyFromWKB,
tipo:
LineFromWKB,
GeomCollFromWKB,
MPointFromWKB,
BdPolyFromWKB,
BdMPolyFromWKB.
Outras funções SQL existentes geram a representação textual de uma dada Geometria.
As funções SQL associados com a classe Geometria e suas subclasse s estão relacionadas com
os métodos anteriormente descritos, sendo que os mesmos podem ser usados nas sentenças
SQL.
55
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
3.3.2.5 Exemplos de consultas
SELECT Parcel.Name, Parcel.Id FROM Parcels
WHERE Intersects (Parcels.Location,PolyFromWBK(:wbk,:srid))=1
Retorna todos os lotes que interceptam um polígono específico.
SELECT Parcel.Name, Parcel.Id FROM Parcels
WHERE Within(Parcels.Location, PolyFromWKB(:wkb, :srid)) = 1
Retorna todos os lotes completamente contidos em um polígono específico. Outras
consultas podem ser vistas no documento de especificação SQL do Open GIS [OGC99b].
3.3.3 OUTRAS PROPOSTAS
Extensões SQL para SIG, para serem eficientes, devem conter: (1) tipos de dados espaciais,
(2) operadores/predicados espaciais, (3) suporte para apresentação textual e gráfica de
resultados de consultas. Muitas extensões de SQL têm sido propostas, como pode-se ver em
[Ege94, Fra82, HS93, FC92, EF88, EF90, MPS94, ISO00], mas muitas delas ainda se
apresentam incompletas, muitas vezes por não manterem construções sintáticas e semânticas
consistentes.
Uma das vantagens das extensões SQL é que as mesmas permitem que os usuários SQL
experientes continuem aplicando, de uma maneira familiar, a linguagem de consulta para
consultar dados não-espaciais. Apenas consultas que incluam propriedades espaciais devem
usar as extensões de SQL. Espera-se que estes usuários experientes aprendam rapidamente
este novo dialeto.
Atualmente as linguagens que mais vêm se destacando na comunidade de pesquisadores
e projetistas são: o padrão SQL Multimedia Standard SQL/MM Parte 3 [ACK+98, ISO00], a
especificação SQL do OpenGIS [OGC98b, OGC99b], e a especificação Oracle Spatial [RS99,
Ora97].
A tese aqui apresentada tomará como base a especificação SQL do Open GIS
[OGC99b], para viabilizar o projeto da linguagem de consulta visual para banco de dados
geográficos, GeoVisualQL, como será visto no Capítulo 5. A escolha desta especificação SQL
para o desenvolvimento da linguagem visual se deu principalmente pela literatura disponível
a respeito da mesma [OGC98b, OGC99b].
56
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Levando-se em consideração que optamos, como mostra o Capítulo 2, pelo modelo de
dados proposto pelo consórcio Open GIS, também decidimos que o uso dessa especificação
SQL seria ideal, visto que foram projetados em conformidade um com o outro. Além disso,
algumas funcionalidades adicionais que foram propostas nesta especificação SQL se
mostraram úteis à necessidade desta proposta.
Antes de mostrar como pode ser aplicado o paradigma de consultas visuais em SIG,
será apresentado, na próxima seção, o conceito genérico de sistemas baseados neste
paradigma, definido por alguns autores [BCC+91, Cat+97, Cat91a, Cat91b, MM96a,
MM96b MM98].
3.3.4 Questões de Apresentação dos Resultados das Consultas
Nem toda linguagem espacial considera o fato de que questões de apresentação do resultado
de consultas tem uma relevância significativa no projeto de linguagens para SIG. Estas
questões merecem ser
detalhadas porque, para uma boa apresentação de resultados de
consultas, uma linguagem deve oferecer [Cam95, CCF +96]:
• Associação de descritores de apresentação gráfica e pictórica aos objetos geográficos:
definição de legendas e modos de apresentação gráfica para os dados geográficos;
• Controle dos objetos apresentados: associação de diferentes formas de apresentação
(cor, texto, legenda, escala) para diferenciar os resultados da consulta;
• Combinação dos resultados de consulta: instrumento bastante poderoso em
interfaces de consulta, ao realizar operações de união, intersecção e diferença entre
consultas subseqüentes;
• Apresentação do contexto espacial: a resposta a uma consulta espacial nem sempre
pode ser interpretada por si só. Por exemplo, a resposta à consulta "Mostre a cidade
de Recife" deve conter ainda a localização da cidade em relação ao mapa do estado
de Pernambuco;
• Informação adicional associada: apresentação de gráficos associados a atributos dos
objetos sob forma de cartogramas, barras e discos (“pizza”).
Estas questões foram introduzidas por Egenhofer [Ege94] e são fundamentais no
projeto de uma linguagem de consulta, pois, uma linguagem, cujos resultados de suas
57
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
consultas, não apresente pelo menos algumas dessas características não será bem aceita pelos
usuários, pois seus resultados não serão entendidos.
3.4 L INGUAGENS DE CONSULTAS VISUAIS
Quando se pensa em comunicação humana, pensa-se primeiro na linguagem falada e escrita.
Estes símbolos de linguagem são encontrados e processados seqüencialmente, tanto quando
são ouvidos como quando são lidos [MM98]. Nem toda comunicação humana, no entanto,
acontece de forma seqüencial. Componentes importantes da comunicação humana dizem
respeito às linguagens visuais, tais como mapas e diagramas. Nestas linguagens, os símbolos
básicos não são encontrados seqüencialmente, mas unidos por perspectivas.
Linguagens Visuais têm sido utilizadas desde a pré-história até o presente e são usadas
por praticamente todas as situações humanas. Elas cobrem todo o espectro humano de
expressão, desde a mais fina arte, como uma abstração expressionista, à mais precisa
comunicação técnica que utiliza notações rigorosamente definidas, notações matemáticas ou
mapas cadastrais de ruas. O crescimento explosivo da comunicação visual na World Wide
Web demonstra também o aumento do uso das linguagens visuais.
No entanto, aspectos teóricos das linguagens visuais não são ainda mundialmente
conhecidos e difundidos, contrastando com as linguagens de natureza seqüencial como
mencionado anteriormente, onde teorias lingüísticas e modernas as formalizam, e onde
técnicas de especificação são largamente utilizadas. A teoria e o entendimento das linguagens
visuais estão menos avançadas. Isto acontece porque muitas vezes as pesquisas a respeito de
linguagens visuais ocorrem em comunidades diferentes, muitas vezes independentes umas das
outras [MM98].
A pesquisa em linguagens visuais tem como um de seus objetivos, garantir um
entendimento melhor de como elas podem ser classificadas e de como elas podem ser mais
naturais e concisamente especificadas. Um outro ponto que também merece ser pesquisado é
o entendimento do que faz uma linguagem visual melhor do que outra, além da definição de
instruções de como projetar uma nova linguagem visual. Uma das grandes motivações de uso
das linguagens visuais é facilitar a interação homem-máquina.
58
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
3.4.1 Sistemas de Consultas Visuais
Recentemente, um grande número de interfaces baseadas em diferentes técnicas que
explorem melhor o senso humano, vêm sendo sugeridas e implementadas [Cat+97]. A larga
difusão de interfaces visuais também se deve ao baixo custo dos dispositivos gráficos atuais.
O campo de pesquisa em banco de dados é particularmente interessante no
desenvolvimento de interfaces visuais porque seus dados são freqüentemente consultados por
usuários que muitas vezes podem não estar familiarizados com as linguagens de consultas
textuais específicas a cada SGBD. Quando se trata de Banco de Dados Geográficos, tem-se
ainda uma dificuldade maior devido à não existência de um padrão de linguagem de consulta
para os mesmos, que seja bem aceito e formalizado pela comunidade de usuários e
desenvolvedores de SIG.
O que podemos encontrar na literatura atual é que existem grupos de pesquisa
[BCC+91, Cat+97, Cat91a, Cat91b] que se preocupam com o desenvolvimento e a definição
de linguagens ou sistemas de consultas visuais em geral para bancos de dados convencionais,
em alguns casos para bancos de dados temporais [SSC97, Sil99]. Poucos trabalhos unem esta
tecnologia com Banco de Dados Geográficos, especificamente [CM91, CM94, Mey92,
WH98].
Apresentamos a seguir, alguns conceitos de linguagens de consultas visuais para banco
de dados, e ao final mostramos um exemplo de um projeto deste tipo de linguagem específico
para SIG.
A área de banco de dados é uma das mais promissoras em linguagens de consultas
visuais desde que se justifique a existência de muitos usuários casuais, ou seja, que não
estejam familiarizados com a linguagem de consulta associada ao mesmo [BCC +91, Cat91a].
Sistemas de Consultas Visuais (SCV) são sistemas de consultas a bancos de dados que
utilizam uma representação visual para representar o domínio de interesse e expressar
pedidos solicitados [Cat+97]. Estes sistemas provêem não somente a capacidade de expressar
consultas em uma forma visual, como também diferentes funcionalidades para melhorar a
interação homem-máquina. O uso de ferramentas visuais pode ajudar os usuários no acesso
aos bancos de dados sem que os mesmos necessitem conhecer previamente a linguagem de
consulta específica em uso, sem a dependência da linguagem nativa dos usuários e das
limitações impostas pela área de aplicação.
59
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
As principais questões dos usuários são: entender o conteúdo do banco de dados, focar
o significado dos itens, encontrar padrões de consulta e entender os resultados das mesmas.
Estas tarefas requerem técnicas específicas a serem aplicadas ao mesmo tempo em que
envolvem atividades espaciais típicas tais como apontar , navegar, filtrar e mudar escala, por
exemplo.
Os fatores mais importantes que influenciam o uso efetivo de SCV, do ponto de vista
do usuário são:
•
Modelos adaptados para descrever os dados e as operações de consulta.
•
Representação escolhida para mostrar uma instância do modelo.
•
Estratégias de interação sugerindo como o sistema deve ser usado para
formular uma determinada consulta.
As linguagens tradicionais de consultas à banco de dados não auxiliam no
entendimento do significado dos dados nem provêem qualquer conselho para satisfazer a
necessidade do usuário, ou seja, não preenchem os requisitos de serem amigáveis e com
facilidade de uso necessária a uma boa interface.
Símbolos visuais são caracterizados pelo alto número de variáveis tais como: tamanho,
intensidade, textura, forma, orientação e cor. O principal propósito ao adotar uma
representação visual em um sistema de consultas é comunicar claramente ao usuário a
informação contida no banco de dados, concentrando características essenciais e omitindo
detalhes desnecessários.
Linguagens de Consultas em geral são avaliadas segundo os critérios de capacidade
funcional e usabilidade. O primeiro critério refere-se ao poder da linguagem e as alternativas
disponíveis para o usuário obter a representação da saída. O segundo deles é relacionado com
a formulação da consulta, isto é, o esforço do usuário para trabalhar com o sistema. Os
critérios principais que são considerados neste estudo são a representação visual adotada para
apresentar a realidade de interesse, as operações da linguagem aplicável e os resultados da
consulta. Os sistemas podem ser organizados em quatro classes diferentes, dependendo do
formalismo visual adotado, isto é, formulário, diagrama, ícones ou uma combinação destes
[Cat91a].
60
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
De modo a classificar os Sistemas de Consultas Visuais (SCV) serão analisados alguns
critérios dos mesmos [Cat91a]. O primeiro critério está relacionado com o objetivo das
pessoas que trabalham com SCV de recuperar os dados desejados, o que é geralmente
alcançado a partir de três atividades:
•
Entendimento da realidade de interesse;
•
Formulação da consulta;
•
Teste.
Um segundo critério para classificação de SCV se refere às estratégias de interação
providas pelas atividades acima, o que será discutido a seguir.
3.4.1.1 Estratégias para Entendimento da Realidade de Interesse
O entendimento da realidade de interesse relaciona-se com a representação visual utilizada, e
o quanto ela é efetiva para expressar os diversos tipos de conhecimento. Uma das principais
vantagens da mesma é a capacidade desta representação de permitir inferências perceptivas,
em substituição a comparações cognitivas árduas e computações. As estratégias de interação,
que facilitam o entendimento do usuário no domínio de banco de dados, podem ser
classificadas em três grandes grupos: top-down, navegação, e simplificação de esquema
[Cat91a].
Metodologia Top-Down
Um esquema de banco de dados pode conter milhares de conceitos, e muitas vezes se
faz necessário um mecanismo para apresentar o esquema com quantidades variáveis de
detalhes que são controlados pelo usuário. Isto pode ser alcançado com a metodologia topdown, na qual aspectos gerais da realidade são percebidos primeiro, e então, detalhes
específicos são introduzidos:
•
Zoom seletivo: Neste caso, o esquema é único, e os conceitos são
distribuídos em termos de níveis de importância. O esquema pode ser
rastreado graficamente em diferentes níveis de abstração.
•
Refinamentos interativos: Neste caso, o sistema provê para cada esquema
uma biblioteca de refinamentos top-down. Cada refinamento pode ser
obtido do anterior pelo uso de transformações sobre objetos.
61
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
•
Zoom hierárquico: O esquema, neste caso, é único, mas os objetos podem
ser examinados em diferentes níveis de detalhes.
•
Tecnologia baseada em diálogo: Consiste de uma seqüência de decisões
do usuário em relação à relevância ou não de algum atributo com respeito
a sua interpretação da consulta.
Metodologia de Navegação
A navegação é em essência uma técnica de visualização, auxiliada pelo conhecimento
adquirido sobre o banco de dados e, em princípio, pode manipular, sem distinção, tanto
esquemas como instâncias de uma maneira homogênea. Neste caso, o usuário possui um
mínimo de conhecimento a respeito do banco de dados e pode acessar o sistema sem
nenhuma meta pré-definida.
•
Navegação intencional: é executada na intenção do banco de dados, isto
é, no esquema conceitual. Esta metodologia corresponde à meta-consulta
da estrutura do esquema
•
Navegação extensional: é executada na extensão do banco de dados.
•
Navegação mista: no caso da atividade de navegação ser executada em
ambas as partes: intencional e extensional.
Simplificação de Esquema
A idéia é trazer o esquema mais perto da consulta, cuja construção é feita a partir de uma
visão do usuário que resulta em agregações e transformações de consultas do esquema
original. O usuário pode construir uma visão apropriada do esquema que pode ser isomórfica
em qualquer nível de detalhe do esquema original.
3.4.1.2 Estratégias para Formulação da Consulta
A formulação da consulta é a atividade fundamental no processo de recuperação de dados.
Existem muitas estratégias para formulação de consultas e as mesmas variam em relação à
maneira como o usuário vai “montando” a sua sentença de consulta, se por navegação de
esquema, pela utilização de sub-consultas, por casamento de padrões ou por seleção variada.
Esta fase pode ser realizada baseada em quatro tipos de estratégias, a saber:
62
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Top-Down
A fase sucessiva no processo de extrair informações do banco de dados é a expressão da
consulta top-down. Na estratégia top-down a consulta é definida primeiramente
especificando os conceitos de interesse e, conseqüentemente, restringindo o conjunto de
instâncias, expressando condições em suas propriedades.
Sobre esta estratégia, podem-se obter diferentes metodologias de consulta:
•
Navegação global seguida de inspeção local: neste caso o usuário
inicialmente navega pelo banco de dados de modo a selecionar os conceitos
envolvidos na consulta e, então, especifica as características procedimentais
da mesma.
•
Intenção seguida pela extensão: nesta metodologia o usuário primeiro
especifica os tipos de objetos envolvidos na consulta e subseqüentemente
seleciona as instâncias requeridas.
Bottom-Up
Neste tipo de estratégia, a consulta é formulada dividindo o problema em sub-problemas
elementares e, então, obtendo a consulta final como a composição de resultados parciais.
Duas diferentes metodologias são apresentadas nesta estratégia:
•
Composição de conceitos: Esta metodologia é usada em diferentes
linguagens baseadas em ícones, onde os conceitos de saída da consulta são
produzidos pela composição de conceitos de entrada e, desta forma, as
consultas são construídas com a sobreposição de ícones.
•
Uso de bibliotecas de consultas: Neste caso as consultas podem ser
compostas pelo uso de sub-consultas armazenadas em uma biblioteca do
sistema.
Inside-Outside
Esta estratégia tem como característica principal a concentração em um conceito ou em um
grupo de conceitos e a movimentação dentro do mesmo de modo a alcançar outros conceitos
de interesse. Classificamos esta estratégia de acordo com o tipo do grafo que deve ser
seguido:
63
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
•
Grafo conectado hierárquico: Neste caso o usuário foca a atenção em um
conceito e então o sistema constrói uma visão hierárquica do banco de
dados com o conceito selecionado como raiz.
•
Grafo conectado como flor: Esta modalidade de consulta é baseada na
localização de um conceito particular chamado de conceito principal que
pode ser visto como um ponto de entrada de uma ou mais sub-consultas.
Estas sub-consultas expressam as navegações possíveis a partir do conceito
principal até outros conceitos do esquema.
•
Grafo não-conectado: Nos exemplos anteriores, os conceitos de
vizinhança podem ser alcançados partindo de um conceito central e
seguindo caminhos explicitamente representados no esquema. Ao
contrário, em um grafo não-conectado, o usuário pode estar interessado
em alcançar conceitos pela construção de novos relacionamentos entre os
mesmos. A consulta, neste caso, é construída passo-a-passo: primeiro,
eliminando-se os atributos não-relevantes e depois, escrevendo-se
condições para selecionar entidades.
Mista
Esta estratégia é chamada mista porque representa um compromisso entre as estratégias topdown e bottom-up. São exemplos de estratégias mistas:
•
By-example: é uma metodologia alternativa ao procedimento de consulta
tradicional, pois o usuário pode prover um exemplo de resposta e o
sistema identifica o objetivo generalizando o exemplo do usuário.
•
Casamento de padrões: Nesta metodologia o usuário provê um padrão e o
sistema procura por todos os fragmentos, casando o banco de dados com
este padrão.
3.4.1.3 Estratégias de Teste da Consulta
O propósito do teste é verificar que a consulta corresponde à intenção do usuário [Cat91a].
Podem ser usadas duas metodologias para teste da consulta:
64
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
•
Reformulação da Consulta: Poderá ser feita em linguagem natural ou em
alguma linguagem padrão como SQL.
•
Anima ção da Consulta: Visualizar com animação a computação executada
pela consulta até a obtenção do resultado.
A tecnologia visual pode ser efetiva para a solução de problemas de consultas a bancos
de dados extensos como, por exemplo, os geográficos. O que se verifica, em geral, é que o
primeiro problema do usuário é conhecer o conteúdo do banco de dados, e isto é geralmente
alcançado pela formulação de inúmeras consultas. Observando seus resultados e
reformulando novas consultas, de forma interativa, o sistema irá finalmente satisfazer o
pedido do usuário, consumindo, no entanto, bastante tempo.
Para tentar solucionar este problema, pode-se transformar todos os dados em objetos e
apresentar exemplos de objetos de forma visual, de modo a tornar o conteúdo do banco de
dados visível ao usuário, facilitando seu entendimento e auxiliando na formulação da
consulta. Porém, uma dificuldade destes tipos de sistemas consiste em encontrar exemplos
para todos os dados armazenados no BD.
3.4.2 Representações Visuais
Muitos autores, como [BCC+91, Cat91b], concordam em afirmar que representações visuais
são efetivas para expressar diferentes tipos de conhecimento. Uma das principais vantagens
disto refere-se à capacidade de permitir inferências perceptivas, substituindo comparações
cognitivas árduas e computações.
Em [Cat +97] apresenta-se uma classificação de
representações visuais em onze categorias, passando de tabelas a mapas, ícones, figuras e
diagramas de diferentes tipos. No entanto, as representações visuais utilizadas em SCV se
restringem, normalmente, a vários tipos de tabelas, diagramas e ícones. Classificam-se os SCV
de acordo com a representação gráfica das suas consultas, como também, numa outra
classificação, levaremos em consideração a representação dos resultados das consultas.
3.4.2.1 Representações Visuais da Consulta
•
Baseada em Formulário: Um formulário é uma coleção nomeada de objetos que
possuem a mesma estrutura. Foi a primeira tentativa de deixar o espaço monodimensional do texto, explorando sua bi-dimensionalidade. Auxilia os usuários
menos experientes fazendo com que os mesmos utilizem sua tendência natural em
usar estruturas regulares e/ou organizar dados em tabelas. Em alguns SCV que
65
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
utilizam formulários em sua representação visual, apenas a parte intencional do
banco de dados é mostrada, deixando a parte extensional a ser preenchida pelo
usuário. Em outros SCV baseados em formulários, ambas as partes, intencional e
extensional, do banco de dados podem ser manipuladas pelo usuário.
•
Baseada em Diagramas: Os dados contidos em um formulário podem ser melhor
entendidos se for utilizada alguma representação gráfica que demonstre os
relacionamentos entre os dados. A palavra diagrama neste contexto é usada no
sentido de denotar qualquer representação gráfica que codifique informações,
utilizando-se posição e magnitude de objetos geométricos. Os diagramas
apresentam-se como o formalismo visual mais utilizado por SCV, podendo ser
representados também em três dimensões.
•
Baseada em Ícones: Um sistema baseado em ícones utiliza um conjunto de símbolos
que denotam entidades do mundo real e algumas funções disponíveis no sistema.
Uma consulta é expressa primeiramente pela combinação de ícones de acordo com
sintaxes espaciais pré-definidas. Sistemas baseados em ícones representam um
avanço na amigabilidade da interação homem-máquina e, em geral, neste tipo de
sistema, o esquema do banco de dados não é mostrado.
•
Representação híbrida: Uma representação híbrida utiliza uma combinação
arbitrária dos três formalismos visuais acima descritos, oferecendo ao usuário várias
alternativas para representação de banco de dados e consulta.
3.4.2.2 Representação Visual dos Resultados das Consultas
Muitas vezes os resultados de consultas se apresentam como textos estruturados sem
considerar outros formatos. Uma visualização apropriada do resultado da consulta permite
que o usuário capture melhor o relacionamento entre os dados de saída.
Classifica-se, sob a metodologia baseada em formulários, os sistemas que mostram o
resultado organizado em tabelas ou em listas. Em outros SCV, diagramas são empregados
também para visualizar o resultado das consultas. Alguns SCV, por exemplo, mostram os
resultados através de um mesmo tipo de grafo que tenha sido utilizado na formulação da
consulta, através do preenchimento de nodos com os respectivos valores apropriados.
O objetivo principal no desenvolvimento de SCV é construir interfaces nas quais os
usuários possam facilmente comunicar suas solicitações e obter respostas satisfatórias.
66
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Considerando que usuários diferentes possuem necessidades diferentes, qualquer SCV deve
prover diferentes maneiras de expressar consultas e, eventualmente, deve ter a capacidade de
se adaptar a usuários em particular. A criação de sistemas de consultas visuais poderosos e
amigáveis implica em algumas necessidades de projeto dos mesmos. Sua interface deve
permitir que qualquer usuário possa interagir com o sistema sem necessidade de nenhum
treinamento prévio. A linguagem de consulta deve ser poderosa o bastante para permitir que
todas as consultas computacionalmente corretas sejam expressas e qualquer tipo de dados seja
recuperado.
Informações implícitas devem ser deduzidas de modo que o sistema possa
prover ao usuário a resposta correta, ou declarar sua ausência de informação diante de uma
pergunta sem resposta. Infelizmente, vários problemas ainda se encontram em aberto no
desenvolvimento de sistemas deste tipo, e continuam sendo temas de pesquisas atuais
[Cat+97].
3.5 Formalismos Visuais e Gramáticas
Um dos aspectos fundamentais de pesquisa em linguagens visuais refere-se a como especificálas [BCL+95, CHY97, Cru93, MMW98]. Chama-se de linguagem visual um conjunto de
diagramas que são sentenças válidas desta linguagem, onde um diagrama é uma coleção de
símbolos de duas ou três dimensões. O significado dessas sentenças válidas depende das
relações espaciais entre estes símbolos. Por exemplo, linguagens visuais são normalmente
usadas em expressões matemáticas, plantas arquitetônicas e notações musicais.
Ao especificarem-se linguagens textuais seqüenciais é comum fazer uma distinção entre
os aspectos de sua sintaxe e de sua semântica, onde a sintaxe especifica a estrutura das
sentenças, enquanto que a semântica descreve o seu significado. A sintaxe é normalmente
especificada utilizando-se uma gramática composta de regras de tradução que especificam a
composição de componentes gramaticais, tais como sentenças ou frases nominais. Enquanto a
semântica pode ser obtida inicialmente através do uso de um dicionário que encontre o
significado das palavras na sentença, e então combinando estes significados com a estrutura
sintática da sentença [HU97].
Ao serem consideradas as linguagens visuais pode-se notar que o seu comportamento é
totalmente distinto das linguagens textuais. Por exemplo, um mapa climático ou esboços de
projetos usados em arquitetura: não é tão óbvio, nestes casos, especificar a sintaxe ou a
semântica destes mapas, ou mesmo se existe separação clara entre elas.
67
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Existem diferentes metodologias que são utilizadas na especificação de linguagens
visuais: a metodologia gramatical, a metodologia lógica e a metodologia algébrica [MM98]. A
metodologia gramatical é baseada em formalismos gramaticais usados em especificação de
linguagens textuais. A segunda metodologia utiliza lógica matemática de primeira ordem, ou
outras formas de lógica matemática. A terceira e última metodologia, utiliza a especificação
algébrica, que consiste de funções de composição que constroem figuras complexas a partir
de elementos pictóricos simples.
O texto a seguir se concentrará na metodologia gramatical visto que a especificação da
linguagem visual para BDG, base dessa tese, é baseada em uma linguagem textual, que é a
especificação SQL do Open GIS. Além disso, ao utilizar a metodologia gramatical a
especificação se torna mais próxima da linguagem textual.
3.5.1 Formalismos de Especificação Gramatical
Uma gramática é um conjunto de regras que especifica a sintaxe de uma linguagem. As
primeiras propostas de gramáticas foram simples modificações das estruturas das frases de
gramáticas usadas para linguagens baseadas em string [MM98]. Posteriormente, surgiram
propostas de gramáticas usadas para linguagens baseadas em grafos, utilizando-se multiconjuntos de atributos, e gramáticas para grafos utilizando arcos nomeados. No entanto,
todas elas sempre tiveram como característica serem muito restritivas, embora elas tenham
como compromisso manter a expressividade, e como desejo, obter um formalismo que
permita um reconhecimento eficiente de diagramas na linguagem.
Muitas dessas propostas de gramáticas para descrição de linguagens visuais podem ser
encontradas em [MMW98], tais como adaptações de gramáticas livres de contexto,
linguagens de descrição de figuras, gramáticas posicionais, grafo-gramáticas baseadas em
métodos, grafo-gramáticas programadas por atributos, gramáticas visuais além de outras que
utilizam o formalismo lógico ou algébrico como princípio.
As primeiras tentativas de especificar a sintaxe de imagens usaram gramáticas livres de
contexto ou gramáticas sensíveis ao contexto, onde os terminais eram interpretados como
objetos de duas dimensões, tais como linhas retas ou arcos. Estes objetos necessitavam ter
definidos uma cabeça (head) e um fim (tail), e estavam concatenados quando a cabeça de um
estava conectada ao final do outro. Mas esta proposta não era útil para descrever qualquer
tipo de linguagem visual, pois era muito limitada.
68
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Gramáticas posicionais são mais capazes de descrever grande parte de linguagens, mas
requerem uma tradução mais complexa das estruturas gráficas bidimensionais para um string
unidimensional de modo que parte da tarefa de reconhecimento possa ser executada por esta
tradução, ao invés da derivação apropriada.
Muitas tentativas genéricas de especificação de linguagens visuais podem ser agrupadas
como gramáticas baseadas em multiconjuntos de atributos, onde a produção de escrita de
conjuntos e multiconjuntos de símbolos possuem atributos geométricos e algumas vezes
semânticos associados aos mesmos.
Foi realizada uma análise de algumas propostas de formalização de linguagens de
consultas visuais [MM98, GC96, Haa95, WZ98], e foi decidido optar pela proposta da
Picture Layout Grammar – PLG, de Golin [Gol91, GR89a, GR89b, GR90, GM93], pois a
literatura encontrada se mostrou satisfatória, e as suas funcionalidades se aproximaram mais
das particularidades da Linguagem Visual a ser definida. Desta forma, a seguir as
características desta gramática são apresentadas.
3.5.2 Especificação de Sintaxe de Linguagens Visuais
Linguagens de programação visual, segundo Golin [GR89a], são aquelas em que os
programas consistem de figuras formadas por elementos visuais ao invés de texto. A maioria
das pesquisas em programação visual tem focado o desenvolvimento de um ambiente para
uma linguagem visual específica, geralmente usando uma interface ad-hoc, de propósito
especial para a criação de programas visuais.
Grande parte das razões para isto é a falta de modelos formais para especificação de
sintaxe para linguagens visuais e de ferramentas que utilizem estas especificações. Para
linguagens de programação textuais tradicionais, os modelos formais tais como gramáticas
livres de contexto provêem um mecanismo de especificação sintática e ferramentas para a
criação de parsers para as novas linguagens. No entanto, não existem ferramentas desse tipo
desenvolvidas para linguagens visuais.
A Picture Layout Grammar ou PLG (Gramática de descrição de figuras) [GR89a] é um
tipo de gramática que pode ser usada para especificar a sintaxe das linguagens visuais quase
da mesma forma que as gramáticas livres de contexto são usadas para definir linguagens de
programação textuais. Estas gramáticas são baseadas em um modelo de gramática que gera
conjuntos de objetos com atributos.
69
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
A Figura 3.8 mostra a arquitetura de um sistema de programação visual baseado num
parser espacial [GR89a]. Um programa consiste de uma coleção plana de objetos gráficos, tais
como formas, linhas e strings. Estes objetos gráficos formam os elementos primitivos de uma
linguagem visual. Um parser espacial utiliza a definição de gramática de linguagem visual para
analisar a figura e recuperar a estrutura interna do programa.
Analisador
Espacial
Editor
Gráfico
Projetista da
Linguagem
Programador
Visual
Árvore de
Análise
Programa
Executável
Arquivo de
Figuras
Usuário
Final
Figura 3.8 – Um Sistema de Programação Visual com Analisador Espacial [GR89a]
O termo “linguagem visual” é usado para descrever diversos tipos de linguagens:
linguagens de manipulação de informações visuais; linguagens que suportam interação visual;
e linguagens de programação com expressões visuais [GR89a].
As linguagens visuais diferem entre si quanto ao tipo de figuras que elas contêm, mas
são similares na noção intrínseca do que constitui uma figura. A um nível mais baixo, uma
figura pode ser vista como um elemento primitivo, tal como linha, polígono e texto.
Uma importante diferença entre texto e figura diz respeito à estrutura interna. O texto
é estruturado como uma árvore, enquanto que numa figura, uma sub-forma pode ser
composta de várias outras formas dentro de uma figura. Desta forma, a estrutura interna de
uma figura em uma linguagem visual é muito mais freqüentemente vista como um grafo
direcionado do que como uma árvore.
Uma linguagem visual pode ser vista como um conjunto de figuras, seguindo as
seguintes definições [GR89a]:
70
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Definição 1: Um elemento-figura é um objeto gráfico primitivo tal como linha, forma (shape),
ou texto string. Uma figura é uma coleção de elementos-figura arranjados em um plano. Uma
linguagem visual é um conjunto de figuras. A sintaxe de uma linguagem visual é especificada
pela distinção do conjunto de figuras que forma a linguagem.
A utilização de uma gramática para caracterizar um conjunto de figuras (ou strings)
serve para dois propósitos: prover uma definição finita para um conjunto infinito e fornecer
uma estrutura aos elementos do conjunto que formam a base do analisador sintático.
As PLG são baseadas em um novo modelo gramatical: a gramática de atributos
multiconjuntos, onde multiconjunto é um conjunto que pode apresentar elementos repetidos
em seu conteúdo.
3.5.3 Especificação de Figuras Baseadas em Gramáticas
Um alfabeto visual e um conjunto de operadores de composição provêem a base para
descrever figuras [Gol91]. Juntos definem um universo de possíveis figuras: o conjunto de
figuras, formado a partir de elementos primitivos do alfabeto, que são cobertos pelo grafo de
composição sobre o conjunto de operadores. Desta forma, pode-se dizer que o conjunto do
alfabeto e de operadores define a linguagem visual.
A especificação da sintaxe deve definir exatamente quais figuras pertencem à linguagem
visual, e como estas figuras são construídas pela composição de elementos pictóricos. Uma
gramática é baseada em um alfabeto, dividido em símbolos terminais e não-terminais. Os
terminais são símbolos que formam os elementos da linguagem. Para uma linguagem visual,
símbolos terminais correspondem aos elementos pictóricos.
As regras ou produções da gramática servem para relacionar partes dos elementos da
linguagem. Em uma especificação gramatical de uma linguagem visual, a aplicação de uma
produção corresponde à aplicação do operador de produção. O símbolo não-terminal do
lado esquerdo da produção se refere ao objeto-composição formado pela produção. A árvore
de derivação da figura é equivalente ao seu grafo de composição.
3.5.4 Picture Layout Grammars – PLG (Gramáticas de Descrição de Figuras)
As PLG representam uma versão resumida das gramáticas de multiconjuntos, especificamente
designada para descrever sintaxes de duas dimensões [Gol91]. Uma figura é representada
como um multiconjunto de atributos. Os elementos pictóricos primitivos formam o alfabeto
71
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
terminal da gramática, onde o multiconjunto de atributos é definido. Os atributos dos
símbolos contêm, ambos, a localização e as características dos elementos pictóricos.
Cada símbolo, terminal e não-terminal, terá quatro atributos geométricos: lx, by, rx, ty,
que representam a geometria da entidade gráfica correspondente. Os atributos geométricos
são especificados em um sistema de coordenadas onde X é a coordenada horizontal que
aumenta da esquerda para a direita, e Y é a coordenada vertical que cresce de baixo para
cima. Estes atributos podem ser interpretados da seguinte forma:
•
Se o objeto é uma forma básica, então os atributos definem a sua extensão, isto
é, um retângulo, onde (lx,by) é o seu canto esquerdo mais baixo, e (rx,ty) é o
seu canto direito mais alto.
•
Se o objeto é uma linha, então (lx,by) representa seu ponto esquerdo inicial e
(rx,ty) representa seu ponto direito final.
A interpretação de se o objeto é uma forma ou uma linha vai depender do contexto
onde o mesmo é usado. Símbolos podem ter outros atributos além dos quatro obrigatórios.
Para símbolos terminais, estes atributos expressam outras características das primitivas
gráficas. Estes símbolos terminais específicos não são fixos.
Exemplo1: Seja a figura mostrada no gráfico da Figura 3.9. O alfabeto terminal para esta
linguagem consiste de três símbolos: retângulo, caixa de texto e seta. Esta figura é representada
por um multiconjunto de atributos com cinco elementos.
Figura = {retângulo [1,1,5,5], retângulo[10,1,14,5], caixa_de_texto[2,3,5,4,”Caixa
A”], caixa_de_texto[9,3,13,4,”Caixa B”], seta[5,3,10,3]}
6
4
2
Caixa A
2
4
Caixa B
6
8
10 12 14
Figura 3.9 – Uma Figura Simples[Gol91]
A estrutura sintática do programa é um paralelo da estrutura composicional da figura.
Cada composição da figura corresponde a alguma produção na gramática. Algumas
72
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
produções, contudo, controlam meramente a estrutura sintática e não possuem composições
correspondentes. Um símbolo não-teminal corresponde a objetos agregados. Formalmente
uma gramática de descrição de figuras é definida como segue:
Definição 2: Uma gramática de descrição de figura é uma gramática de multiconjuntos de
atributos finitamente representável, e não sobreposta G = (N, ∑, s, I, D, P) onde as seguintes
proposições são verdadeiras:
1. Cada símbolo x ∈ N ∪ ∑ tem (pelo menos) os seguintes quatro atributos de parsing
diferentes, lx, by, rx, ty.
2. Se p = (R,SF,C) ∈ P, com R = A → X/Y, então, para todo α ∈ {lx,rx,by,ty}, a função
semântica SF contém uma assertiva:
A. α = x. β onde x ∈ X ∪ Y e β ∈ {lx, rx, by,ty}
As PLG são formalmente vistas como gramáticas de multiconjuntos de atributos, que
apresentam uma sintaxe levemente diferente. Isto é simplesmente uma maneira mais
conveniente de escrever gramáticas. É importante notar que a gramática que está sendo
definida é uma gramática de multiconjuntos especializada e que a notação de produções em
uma gramática deste tipo é meramente uma abreviação das produções nas gramáticas de
multiconjuntos de atributos.
Assim como as gramáticas de multiconjunto de atributos, uma produção numa
gramática de descrição de figuras consiste de três partes: uma regra de reescrita, uma função
semântica e a restrição.
Quando um ou mais instâncias de um símbolo ocorre em uma regra de reescrita, eles
são distinguidos por sub-scripts. Dentro do lado direito da regra de reescrita, qualquer
símbolo terminal pode ser marcado como remoto, por caracteres sublinhados. Símbolos
remotos em uma produção formam o multiconjunto de contexto para a produção. Os demais
símbolos formam o multiconjunto regular.
As restrições em uma produção expressam o relacionamento requerido entre os
componentes de uma composição. Cada operador de construção built-in tem uma restrição
associada especificando a sintaxe de duas dimensões desta composição. Por exemplo, a
restrição associada ao operador over diz que o final do primeiro argumento deve estar acima
73
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
do topo do segundo elemento. Estas restrições são expressas em termos dos atributos dos
símbolos. Então, por exemplo, a produção em PLG:
FIGURE → over (TOP, BOTTOM),
Apresenta a restrição seguinte:
TOP.by >= BOTTOM.ty
Este exemplo ilustra como as produções determinam a interpretação das formas. Um
componente, numa linguagem visual, pode ter seus quatro atributos geométricos
interpretados tanto como extensão, como pontos finais. Em composições de formas os
componentes de um operador são tratados como formas, e seus atributos interpretados de
acordo.
Com o objetivo de mostrar a utilização da gramática na descrição de figuras,
reproduzimos a seguir alguns exemplos que foram fornecidos em [Gol91].
Exemplo2: Considere a Figura 3.10, consistindo de dois retângulos. A linguagem pode ser
definida com a seguinte produção:
1
2
Figura 3.10 – Restrições de uma linguagem definidas pelo usuário[Gol91]
FIGURE → over (retângulo1, retângulo2)
Where
retângulo1.lx == retângulo2.lx
retângulo1.rx == retângulo2.rx
retângulo1.by == retângulo2.ty
Esta produção representa o operador over com três restrições adicionais. Estas restrições
definidas pelo usuário especifica que os dois retângulos que formam a figura devem estar
alinhados nos seus lados esquerdo e direito, bem como a borda entre os mesmos.
As funções semânticas em uma produção computam os atributos de objetos agregados
resultantes da composição. Assim como as restrições, cada operador de produção built-in tem
74
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
uma função semântica que implementa a composição associada. As funções semânticas irão
computar os valores dos quatro atributos lx, by, rx e ty que serão apropriados com os objetos
agregados. Por exemplo, a regra:
FIGURE → over (TOP, BOTTOM),
Define os atributos da extensão que engloba tanto TOP como BOTTOM, isto é, o
menor retângulo que englobe TOP e BOTTOM. A função semântica para esta produção é
equivalente a:
FIGURE → (TOP, BOTTOM),
FIGURE.lx = min(TOP.lx,BOTTOM.lx)
FIGURE.rx = max(TOP.rx,BOTTOM.rx)
FIGURE.by = BOTTOM.by
FIGURE.ty = TOP.ty
Então, o projetista da linguagem pode incluir funções semânticas adicionais em uma
produção. Durante a análise sintática, as funções semânticas built-in são avaliadas primeiro,
seguidas pelas funções semânticas definidas pelo usuário. Desta forma, funções semânticas
adicionais podem ser usadas para sobrepor os valores computados pelas funções semânticas
built-in.
Exemplo3: Considere a Figura 3.11 consistindo de quatro retângulos. As seguintes produções
definem uma linguagem de características similares:
Figura 3.11 – Uma linguagem usando atributos adicionais[Gol91]
HORIZ → left_of (retângulo1, retângulo2)
HORIZ.center = retângulo1.rx
Where
Retângulo1.rx == retângulo2.lx
FIGURE → over(HORIZ1, HORIZ2)
Where
75
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
HORIZ1.by == HORIZ2.ty
HORIZ1.center == HORIZ2.center
Onde o atributo centro é usado para alinhar o ponto de corte da parte do topo e da
parte de baixo da figura.
3.6 U SO DE LINGUAGENS DE CONSULTAS VISUAIS EM SIG
Alguns autores sugerem que uma consulta espacial deve consistir de três partes [CCF+96]:
1.
Uma descrição do conjunto de objetos a ser recuperado;
2.
Um conjunto de resultados de consultas, com estes resultados separados em
conjuntos mais detalhados, cada um a ser disposto em um formato individual;
3.
Uma descrição do resultado especificando como interpretar os dados.
Um dos componentes mais importantes de um SIG é a visualização porque ajuda os
usuários a interpretar e comunicar relacionamentos espaciais complexos [Jun96]. A
visualização, em seu contexto original, é o processo de transformar dados em imagens. O
propósito da visualização em SIG é facilitar o entendimento e a interpretação de dados e
processos espaciais.
A informação contida nos dados originais deve ser interpretada fielmente na imagem
resultante. Nenhuma informação pode ser esquecida, como também nenhuma informação
pode ser adicionada. No entanto, todas as informações devem ser expressas de tal forma que
os usuários percebam, facilmente, características e padrões dos dados.
Há dois requisitos importantes a serem considerados quando se está projetando uma
visualização: a expressividade e a efetividade [Cat91b]. A expressividade observa se a
visualização contém todas e apenas as informações necessárias do conjunto de dados. A
expressividade é muito difícil de ser alcançada em SIG pois a visualização envolve todos os
tipos de mapeamento em um alto grau de abstração dos dados originais. Por outro lado, a
efetividade está relacionada com a capacidade do sistema visual humano. Em SIG existem
muitos fatores que influenciam na efetividade de uma visualização: o objetivo da
interpretação, a mídia de saída e o usuário. Ou seja, para ser efetiva, a visualização deve
incorporar as capacidades visuais do observador e as características da mídia para alcançar o
objetivo da interpretação.
76
Capítulo 3 - Linguagens de Consultas Espaciais e Sistemas de Consultas Visuais
________________________________________________________________________________________________
Alguns SIG utilizam Linguagens de Consultas Visuais como, por exemplo, a proposta
do Cigales [CM91, MP90, CM94]. Cigales é uma linguagem de consulta visual e declarativa
para SIG, onde uma consulta é definida numa filosofia Query-By-Example [Zlo76] gráfica,
que implica numa representação gráfica da consulta. Outros sistemas também suportam
consultas visuais em SIG [Mey92, WH98]. No próximo capítulo, serão descritos alguns
destes sistemas e suas metodologias.
3.7 C ONCLUSÃO
Os relacionamentos de topologia entre objetos espaciais necessitam ser formalmente
definidos através de um formalismo apropriado para poderem ser identificadas sem
ambiguidades [EH91]. O formalismo 9IM foi apresentado e é base deste trabalho.
Algumas características essenciais de uma linguagem de consulta para dados espaciais
foram apresentadas, citando algumas características de um subconjunto das mesmas que
foram encontradas na literatura. Neste subconjunto, pôde-se averiguar a falta de um
formalismo visual de apresentação de dados espaciais que facilite a busca de informações
geográficas.
Neste contexto, foi apresentado o paradigma de consultas visuais, caracterizando esse
tipo de sistema, além dos formalismos gramaticais existentes para linguagens visuais.
No próximo capítulo, serão apresentadas algumas propostas de sistemas de consultas
visuais específicos para SIG encontrados na literatura.
77
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
CAPÍTULO 4
SISTEMAS DE CONSULTAS VISUAIS PARA SIG
“Enquanto as bombas se cruzam e os
homens se matam, as rosas enviam para
além das fronteiras e dos ódios sua universal
mensagem de amor.”
(Dom Helder Câmara)
4.1 I NTRODUÇÃO
O objetivo deste capítulo é mostrar algumas propostas encontradas na literatura que
permitem consultas visuais em Sistemas de Informação Geográfica – SIG. Grande parte destas
propostas é estritamente acadêmica, não havendo, portanto, produtos comerciais no
mercado.
Como vimos no capítulo anterior, o uso de linguagens de consultas visuais reduz a
carga cognitiva dos usuários porque:
•
Estruturas de dados não precisam mais ser memorizadas;
•
Apresentações visuais substituem convenções sintáticas de texto;
•
Formas visuais de consultas são superiores na facilidade de uso e na
visualização conceitual das linguagens de consulta em que são baseadas.
É necessário inserir, neste contexto, o conceito de metáforas, dentro do escopo de
interfaces para SIG [BAT00, BF94, Kuh95, Lak02].
O conceito de metáfora pode ser
78
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
definido como um processo cognitivo onde uma “coisa” é entendida em termos de “outra”
[BAT00]. O uso de metáforas em interfaces permite uma melhora no entendimento dos
sistemas por parte dos usuários. Além disso, quando a ferramenta é bem entendida ela
aparenta ser mais fácil de usar, e dá suporte a um trabalho mais eficiente.
A metáfora mais utilizada quando se trabalha com SIG com certeza é o mapa. Uma
metáfora é considerada boa ou ruim dependendo de seu entendimento por parte dos
usuários. Se uma metáfora não for bem entendida pelos usuários, ela não pode ser
considerada metáfora, porque foge de seu princípio natural. As metáforas utilizadas nas
interfaces dos sistemas a serem apresentados serão discutidas e avaliadas.
As propostas a serem abordados a seguir são: CIGALES [BM95, CM91, CM94, CM95,
Mai92, Mai93a, Mai93b, Mai94, MP90], Lvis [BAT00, FA00, BF94] VISCO [HW97,
HMW00, WH98], Sketch! [Mey92a, Mey92b, Mey93, Mey94], Spatial-Query-By-Sketch
[BE00, Ege96, Ege97], GeoMedia [Geo02] e Arc/Info 8 [Pot02, UGIS95].
4.2 U MA LINGUAGEM DE CONSULTA VISUAL PARA SIG: CIGALES
Uma linguagem de consulta, segundo [CM94], é dita visual toda vez que a semântica de uma
consulta puder ser expressa por um desenho. É dita ser declarativa toda vez que a consulta
especificar as propriedades que vão ser verificadas no resultado da mesma, mas não a maneira
de obtê-las.
CIGALES (Cartographical Interface Generating an Adapted Language for Extensible
Systems) é uma linguagem de consulta visual e declarativa para SIG, onde uma consulta
gráfica é definida com uma filosofia Query-By-Example [Zlo76].
Como a consulta é
representada por um desenho, o gerenciamento do processo de tradução da mesma é bastante
complexo.
4.2.1 Caracterizando CIGALES
A principal característica desta linguagem é a sua simplicidade em expressar uma consulta e
seu poder representativo. O principal objetivo do CIGALES [CM91] [CM94] [MP90] é
tornar mais amigável a interação com o usuário. Desta forma definiu-se uma linguagem
gráfica que é uma maneira mais fácil e natural de manipular dados geográficos. Utiliza -se um
modelo de dados simplificado independente da representação física. Outro grande objetivo
79
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
do CIGALES é aumentar o poder expressivo que permite gerenciar um grande número de
consultas geográficas [MP90].
Dados alfanuméricos são modelados com uma metodologia orientada a objetos. Uma
consulta alfanumérica consiste na definição de um label que pode ser definido sobre um
objeto ou sobre um operador.
4.2.2 A Linguagem de Consulta
A linguagem utiliza a filosofia Query-By-Example, onde o usuário define um exemplo do
relacionamento espacial desejado. Duas metáforas, uma linha e uma área, estão disponíveis e
são completamente independentes da implementação física do modelo de dados. O primeiro
passo para o processamento de uma consulta é a escolha de uma metáfora (uma área, por
exemplo). O segundo passo é a definição da semântica desta metáfora (uma cidade com mais
de 100.000 habitantes poderia ser um exemplo e uma floresta como uma segunda área). O
terceiro passo é a definição de um relacionamento espacial entre estas duas áreas (uma
interseção, por exemplo). Uma consulta desta forma é definida como uma combinação de
relacionamentos espaciais. A manipulação dos resultados das consultas segue a mesma
filosofia.
A semântica de uma metáfora usada em uma consulta é definida no modelo de dados, o
qual é baseado numa extensão do modelo relacional, onde a representação espacial é definida
usando-se um Tipo Abstrato de Dados. Este modelo de dados permite noções básicas de
grafos (nós, arcos e redes) e conceitos definidos dentro do paradigma de orientação a objetos
(abstração). A localizaçã o espacial de uma cidade, por exemplo, é independente da
representação física destes arcos e nós. O mecanismo de abstração é aplicado nos nós, arcos e
redes, e o formalismo permite a definição de uma rede lógica com diferentes níveis de
abstração. Neste modelo, o nó e o arco podem ser representados por uma abstração de uma
ou mais redes. Operações neste modelo são usadas para definir consultas baseadas em redes.
CIGALES foi projetado para ser um Sistema de Gerenciamento de Banco de Dados
Espacial de alto nível. As metáforas, linha e área, representam objetos do banco de dados.
Cinco operadores espaciais estão disponíveis no nível da interface com o usuário: inclusão,
interseção, adjacência, linhas retas e caminhos. Muitos outros operadores estão disponíveis
assim como união e diferença, mas muitas vezes os usuários não sabem que os mesmos
existem. Na medida que o processo de desenho avança, automaticamente estes operadores
80
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
aparecem na interface. Uma consulta é graficamente construída pela combinação de
metáforas e operadores. Esta consulta é então traduzida numa expressão formal baseada numa
linguagem funcional a ser compilada pelo SGBD.
4.2.3 Interface Gráfica do CIGALES
A interface de CIGALES permite a construção de consultas gráficas, que podem ser
traduzidas em uma expressão formal, com uma gramática pré-definida. Esta expressão é
independente da aplicação do usuário e do SGBD. Torna-se necessário, por conseqüência, a
tradução da expressão formal para a linguagem de consulta do banco de dados.
A construção de consultas é executada através de um editor especializado, que provê
facilidades para a construção de consultas através de ícones que representam todos os
operadores disponíveis. A definição de consulta em CIGALES é uma combinação de
operadores, utilizando a noção de objeto corrente. A consulta pode ser feita com um objeto e
um operador, ou dois objetos e um operador entre os dois.
A consulta é definida pelo usuário, com uma interface gráfica (Figura 4.1). O
analisador compila esta consulta gráfica em uma expressão funcional usando operadores
CIGALES, onde uma otimização lógica é executada nesta expressão para evitar redundâncias
e expressões computacionais inúteis. A expressão funcional é então traduzida em comandos
específicos de acordo com o armazenamento físico dos dados. O resultado da consulta é
então transmitido do sistema de gerenciamento de dados físicos ao módulo tradutor,
formatado em estruturas de dados e associado a expressões de consulta lógica. Informações a
respeito de restrições gráficas definidas pelo usuário também são incluídas nestas estruturas.
O resultado da consulta é então transmitido à interface, pelo analisador.
81
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Figura 4.1 – Interface Gráfica do CIGALES
Um Editor Gráfico provê facilidades para a construção de consultas, contendo duas
áreas de desenho. A primeira delas, chamada área-de-consulta, é um retângulo grande vazio
no meio do editor. A outro, a área-de-trabalho é um retângulo menor vazio, abaixo da áreade-consulta. A primeira contém uma consulta a cada passo de construção, onde objetos
correntes são selecionados pelo usuário. A segunda área é usada para definir novos objetos
que podem ser combinados, pela aplicação de um operador aos objetos correntes. Funções de
agregação podem ser aplicadas a um ou vários objetos ou operadores.
Alguns botões disponíveis na interface, tais como o botão Zone e o botão Line possuem
suas semânticas representadas por um label gráfico, que corresponde a uma metáfora
completamente independente do armazenamento físico. O modelo de dados oferece, por
exemplo, diferentes semânticas para uma zona (cidades, florestas, lagos) e outras para linha
(estradas, rodovias, rios). Cinco outros botões representam operadores espaciais. As
82
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
semânticas destes operadores são: inclusão, interseção, limites, caminho e distância
Euclidiana.
O botão With/Without Negation significa expressar ou cancelar o conceito de negação
sobre os operadores espaciais. O botão Network expressa tanto aspectos orientados-ageometria como aspectos orientados-a-rede dos operadores espaciais, quando uma
ambigüidade aparece.
O botão Begin Selection tem uma semântica de permitir a seleção dos sub-objetos
resultantes da aplicação de um operador na área-de-consulta. O botão Global permite a
seleção de um objeto completo ou de uma sub-parte de um objeto.
Do lado esquerdo superior do editor se encontra o botão Logo (“France Telecom”) que
provê algumas facilidades internas na configuração do editor.
•
O botão Cancel está do lado direito do Logo, e cancela o trabalho corrente.
•
O botão Validation está do lado direito do Cancel, e valida o trabalho corrente.
•
O botão Save está do lado direito do Validation e salva uma consulta
intermediária.
•
O botão Restore está do lado direito do Save e restaura uma consulta
intermediária.
•
O botão Help está localizado do lado direito do Save e provê facilidades de
ajuda aos usuários.
•
O botão Exit se encontra do lado direito do Help e serve para sair do editor.
Uma consulta é realizada com a combinação de diferentes operadores. Introduz-se a
noção de objeto corrente de modo a permitir estas combinações. O usuário faz a escolha de
um objeto e depois escolhe um operador (que pode ser um operador unário), ou então
escolhe um outro objeto e um operador a ser usado com os dois objetos escolhidos.
83
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
4.2.3.1 Exemplo de uma Consulta Utilizando a Interface [Mai93a]
Uma consulta típica no CIGALES poderia ser a seguinte:
“Que estradas cruzam uma cidade em sua parte não-florestal?”
Para resolver esta consulta, podemos supor que a expressão gráfica de uma interseção
entre uma cidade e uma floresta está correntemente disponível na área-de-consulta. O usuário
então necessita selecionar o botão line, para representar a estrada, o botão zone para
representar a parte da cidade que não seja florestal, e o operador interseção. Para selecionar
apenas parte da cidade, o usuário necessitará do botão global que trabalha no modo switch.
Uma consulta alfanumérica, em CIGALES, é a definição de um label, que pode ser
definido sobre um objeto ou sobre um operador. Um label definido sobre um objeto é
construído a partir de um conjunto de informações do modelo de dados sobre um objeto de
um determinado tipo.
Uma consulta em SIG requer uma visualização de seus resultados. Dois componentes
são definidos: o tipo do resultado e o modo de display.
O tipo dos resultados é baseado nos objetos básicos que definem os resultados. Duas
classes podem ser distinguidas: 1) Os resultados podem ser definidos de acordo com os
objetos básicos que definem a consulta. Esta classe é chamada de Resultado-básico-orientadoa-tipos e corresponde a uma extensão do SQL que utiliza um predicado como uma interface
para uma linguagem de consulta a bancos de dados espaciais. 2) Os resultados podem ser
definidos com o uso dos operadores espaciais envolvidos na consulta. Esta classe nomeada
Totalmente-Orientada-a-Tipos corresponde a uma extensão de SQL com predicados e
operadores.
O modo de display é baseado na estrutura do resultado. Esta noção corresponde à
filosofia de definição da consulta. Duas classes podem ser definidas: 1) Os resultados podem
ser definidos pela união de objetos compondo o resultado. Esta classe denominada União-deresultados-elementares corresponde a uma metodologia orientada a conjuntos. 2) Os
resultados podem ser definidos como uma apresentação de elemento por elemento dos
resultados elementares. Esta classe denominada Resultado-elementar-no-tempo corresponde à
metodologia de um registro por vez. Normalmente a única política no momento disponível é
o par (resultado-básico-orientado-a-tipos, união-de-resultados-elementares).
84
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
4.2.4 Detalhes de Implementação
O protótipo CIGALES [CM94] foi desenvolvido usando OSF/MOTIF (para a interface com o
usuário), Yacc (para a análise das expressões funcionais internas que modelam a consulta), e a
linguagem de programaçã o C (para o gerenciamento das consultas) em estações de trabalho
Sun.
O número de aplicativos que utilizam SIG atualmente é muito grande, além disso, é de
extrema importância o oferecimento de uma interface poderosa e amigável aos usuários. O
objetivo do CIGALES não foi só oferecer mecanismos para a realização de análise espacial,
mas oferecer um ambiente computacionalmente equipado no qual estas análises estão
disponíveis.
4.2.5 Avaliando CIGALES
A proposta do CIGALES foi desenvolvida em ambiente acadêmico, como resultado de
trabalhos de pesquisa. Foi construído um protótipo da sua implementação, o que depois deu
origem a um outro projeto, como será visto a seguir. Como não foi encontrado um protótipo
executável do mesmo, observa-se, pela literatura, que a sua interface é pouco amigável e
funcionalmente pobre, apresentando poucos operadores espaciais para os usuários. Isto
significa restringir o poder da linguagem de consulta. Não foi mencionada a utilização de
padrões de metadados em sua concepção.
4.3. LVIS
A linguagem de consulta Lvis [BAT00, FA00, BF94] foi construída baseada no conhecimento
em linguagens de consultas espaciais e visuais. Introduz um modelo conceitual espaçotemporal onde consultas visuais são combinadas com métodos de navegação de modo a
construir uma linguagem amigável. Lvis é baseada na filosofia Query-by-Example [Zlo76] e é
uma extensão da linguagem do CIGALES [CM94].
4.3.1 Caracterizando Lvis
Cada objeto espaço-temporal neste modelo é associado com o tipo deste objeto. Este tipo do
objeto representa um nome lógico do nome da tabela relacional ou da classe de objetos. O
identificador semântico permite que o usuário identifique o objeto de forma mais amigável
possível: é composto de um subconjunto de atributos mono ou multi-valorados do objeto.
85
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
As consultas podem ser classificadas como: temáticas, espaciais, temporais e espaçotemporais. Consultas temáticas não incluem nenhum critério espacial ou temporal. Consultas
espaciais (temporais) são definidas com um ou mais critérios espaciais (temporais). Consultas
espaço-temporais envolvem ao menos um critério espaço-temporal.
4.3.2. A Linguagem de Consulta Lvis
Um objeto é visualizado por um ícone, uma forma geométrica e uma cor. Esta representação
visual pode ser reforçada por elementos textuais ou outras representações metafóricas como
balões ou âncoras, como mostra a Figura 4.2.
Identificador temático
Identificador semântico
e/ou critério temático
Eixo temporal
Critério temporal
Localização da âncora
Representação visual da
âncora associada
Rótulo
Figura 4.2 – Descrição de um balão e uma âncora em Lvis [BTAL99]
O ícone modela o identificador temático de um objeto. Uma forma geométrica é
associada com cada objeto de uma consulta de modo a representar seu tipo espacial. Critérios
temporais de uma consulta são expressos utilizando-se a metáfora de balões. Um balão
contém a especificação de um critério relacionado com um dado objeto. Uma âncora é a
representação reduzida de um balão.
As consultas em Lvis são compostas de operandos e operadores (lógicos, espaciais,
temporais e espaço-temporais). Os operadores espaciais da linguagem são topológicos e
métricos. Os operadores topológicos são os mesmos suportados pela linguagem Spatial-SQL
[Ege94]: intersection, inclusion, adjacency, disjunction e equality. Estes operadores podem
ser utilizados por alguns tipos de objetos espaciais suportados pelo sistema: ponto, linha e
polígono. Alguns operadores temporais também estão disponíveis no sistema: before, equals,
86
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
meets, overlaps, during, starts e finishes. Estes operadores são úteis para se comparar dois
objetos ao longo de um determinado tempo.
4.3.3 A Interface Gráfica Lvis
A Figura 4.3 mostra a interface gráfica da linguagem Lvis. Inicialmente apenas os operadores
topológicos estão disponíveis ao usuário.
Figura 4.3 – Interface da Linguagem Lvis
O usuário inicialmente seleciona os tipos dos objetos dentro do BD e então os associa
ao operador. A consulta aparece em uma área de trabalho e então, após a validação pelo
usuário final, aparece a área de validação da consulta.
Três ícones selecionados são suficientes para expressar consultas temáticas, espaciais e
temporais entre dois tipos de objetos. Critérios temáticos são especificados na forma de um
duplo clique em um ícone de um tipo de objeto da consulta.
Uma consulta válida pode ser modificada por refinamentos sucessivos: o usuário pode
adicionar novos objetos e aplicar novos operadores na consulta inteira ou em uma sub-parte
da consulta corrente. Consultas espaço-temporais complexas podem ser formatadas seguindo
este princípio.
87
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Consultas visuais são armazenadas em uma estrutura de árvore. Elas são traduzidas de
modo a serem expressas em uma linguagem destino de SIG. A linguagem pivô é baseada em
um analisador lógico que tenta ser compatível com a linguagem padrão Spatial-SQL [Ege94]
para os operadores espaciais e com TSQL [SPZ98] para operadores temporais.
As consultas válidas são computadas e executadas em SIG. Quando o usuário seleciona
o comando execute, a consulta é então traduzida na linguagem destino dos SIG. Objetos que
satisfazem os critérios definidos são então selecionados e visualizados em um mapa, segundo
mostra a Figura 4.4.
Figura 4.4 – Tradução da Linguagem Visual Lvis para a Linguagem SIG destino [BTAL99]
4.3.4 – Avaliando Lvis
A proposta da linguagem Lvis é interessante principalmente porque se apresenta como uma
extensão do CIGALES, que teve como característica ser um precursor em consultas visuais
para SIG. Lvis tem como proposta associar uma representação visual ao esquema do banco de
dados, enriquecer o conjunto de operadores disponíveis, e considerar aspectos temporais. Um
protótipo foi desenvolvido de acordo com a arquitetura mostrada na Figura 4.4.
88
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
4.4 VISCO
VISCO [HW97, WH98] é uma linguagem de consulta espacial e visual baseada-em-desenho
(sketch-based). O protótipo VISCO integra diferentes componentes para formar um sistema
de consulta visual. A interface de VISCO é composta de três componentes básicos: o editor
gráfico de consultas que oferece um mecanismo de formulação de consultas em bancos de
dados espaciais baseadas-em-desenho; um inspetor de resultados de consulta tipo-navegador;
e uma ferramenta de inspeção-de-mapa para o banco de dados espaciais. Um outro
componente importante do sistema é um compilador e otimizador de consultas da linguagem
visual.
Segundo
Wessel e Haarlev [WH98], uma linguagem é visual quando existe uma
comunicação com o sistema em uma maneira coerente e consistente através de expressões
visuais. No caso das linguagens de consultas visuais, considera-se um ambiente integrado de
sistemas que provêem um sistema de consulta visual fácil de usar, que oferece suporte e
feedback eficientes e fortes metáforas.
4.4.1 Caracterizando VISCO
VISCO é uma linguagem de consulta espacial que foi projetada para extrair informações de
sistemas de informações espaciais em uma maneira visual. O termo sistema de informação
espacial se refere a uma extensa classe de sistemas que coletam, gerenciam e oferecem análise
e apresentação de dados espaciais. Estes objetos espaciais normalmente possuem aspectos
espaciais e não-espaciais. VISCO suporta a recuperação de conjuntos de objetos espaciais de
interesse baseada em seus atributos estruturais, topológicos, métricos e geométricos e em seus
relacionamentos entre si.
4.4.2 A Linguagem de Consulta
Os seguintes elementos de linguagens de consulta são encontrados em VISCO:
•
Objetos VISCO: é qualquer elemento da linguagem visual VISCO.
•
Objetos Geométricos: são pontos, linhas, polilinhas simples, polígonos simples e
agregações. Distinguem-se dois objetos geométricos: objeto-consulta e objetouniversal.
89
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
ü Objeto-Consulta: é um objeto geométrico VISCO que corresponde a objetos
geométricos do banco de dados espaciais. Um objeto-consulta representa um
objeto do banco de dados.
ü Objeto-Universal:
Ao
contrário
do
objeto-consulta,
que
corresponde
exatamente com um objeto do banco de dados, um objeto-universal, ou
auxiliar, representa um objeto qualquer no universo de objetos geométricos.
São inicialmente usados para expressar restrições em objetos-consulta, e
posteriormente considerados como meta-objetos.
•
Meta-Objeto: é um objeto VISCO que exibe alguma condição/restrição adicional
sobre os objetos VISCO e, portanto, permitem a construção de sentenças sobre
estes objetos e suas interpretações.
•
Cerco (Enclosure): um cerco é um meta-objeto que representa um sub-conjunto
de R2. Distingue-se cercos constante, interior, exterior e e (r). Podem ser
translúcidos ou opacos.
•
Objetos Derivados: compreendem os cercos interior, exterior, e e (r) mas
também derivam pontos centrais, pontos de interseção calculada, etc.
Associa-se a cada objeto geométrico VISCO uma semântica física navegável que tem
como objetivo guiar a interpretação do usuário em aspectos espaciais numa representação
visual. Utiliza-se em VISCO, as seguintes metáforas:
• Filmes transparentes (Transparency Films): representam agregações transformáveis
com um sistema de coordenadas local. Filmes transparentes podem ser
rotacionados, traduzidos, mudados de escala, e definidos em uma determinada
camada. Cada objeto geométrico precisa ser definido com exatamente um filme
transparente.
• Percevejos e Bolas -de-Gude (Nails and marbles): são pontos especiais. Um percevejo
em um filme representa um ponto com uma posição exata, mas uma bola-de-gude
pode rolar ao redor de um cerco e, portanto, possui uma posição vaga.
• Ligas de borracha, Antenas de telescópio, e Feixes de madeira (Rubberbands,
Teslescope antennas, Wooden beams): são linhas especiais. Uma antena de
telescópio representa uma linha reta com comprimento arbitrário. Um feixe de
90
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
madeira representa uma linha reta com um comprimento exato e conhecido. E uma
liga de borracha representa uma polilinha de linhas retas.
A construção de consultas em VISCO é um processo progressivo: a cada momento em
que um objeto é criado, várias restrições de alto nível entre o novo objeto e os objetos préexistentes são estabelecidas. A noção, neste momento, de visualização parcial do objeto se
torna crucial. Os seguintes relacionamentos topológicos entre um novo objeto e outros já
existentes são permitidos em VISCO:
• Disjunto: é estabelecido se o outro objeto estiver completamente visível.
• Intersecta: é estabelecido se o novo objeto tem ao menos um ponto de interseção
visível com o outro objeto.
• Dentro de: é estabelecido se o novo objeto estiver completamente visível dentro de
um cerco.
• Contém: é estabelecido entre um novo cerco translúcido e outro objeto que está
completamente contido no mesmo.
Podemos pensar em VISCO como um componente na camada de aplicação de um
banco de dados espacial que trabalha com um modelo de dados externo provido
especialmente para VISCO.
4.4.4 A Interface Gráfica do VISCO
A interface gráfica de VISCO é composta por dois componentes:
• Um editor gráfico direcionado à sintaxe.
• Um modelo de execução e um inspetor de resultados de consultas, incluindo um
Visualizador de Mapa como mostra a Figura 4.5.
O editor gráfico de consultas do VISCO é a parte mais importante do sistema. A
interface do editor é composta de duas janelas, denominadas “VISCO” e “VISCO Buttons”
como pode ser visualizado na Figura 4.6.
91
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Figura 4.5 – Visualizador de mapa
A janela VISCO é a área de trabalho que permite que os usuários construam
interativamente suas consultas gráficas. Consiste de quatro áreas principais: a maior delas é a
“VISCO Query” que mostra a consulta gráfica corrente; a “VISCO Infos” provê informações
de ajuda; a linha de comando para entrada de comandos textuais; e a “VISCO Control” que
mostra o histórico da execução das consultas.
O estado corrente do editor gráfico é mantido e completamente visualizado pela janela
“VISCO Buttons”. Por exemplo, selecionando-se o botão “rubberband” no painel “VISCO
Objects”, o próximo segmento de linha que for criado será um “rubberband”.
Muitas outras representações gráficas podem ser selecionadas com os botões do painel
“VISCO Options” como também uma biblioteca de ícones de operadores está disponível no
painel “VISCO Operators”.
92
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Figura 4.6 – Editor Gráfico de Consultas
A grande maioria dos comandos pode ser entrada de forma textual na linha de
comandos, selecionada no menu de operadores ou diretamente ativada por um objeto, ou
uma seqüência de chaves.
As seguintes características estão disponíveis no editor gráfico VISCO:
•
•
Manutenção em paralelo de um histórico de consultas, editável;
Facilidades que dão suporte aos processos dos usuários no entendimento e
formulação das consultas;
•
Manipulação e interação com objetos complexos;
•
Criação de objetos complexos de forma “top-down” ou “bottom-up”.
•
Manipulação e interação com objetos emergentes.
Além disso, VISCO dispõe de um processo de compilação de consultas que utiliza o
modelo de redes de petri. A consulta VISCO pode ser considerada como declarativa, ou seja,
muitos planos de execução possíveis podem ser esperados. Um otimizador determina qual o
melhor desses planos e utiliza este plano para construir um programa LISP que irá buscar
informações no banco de dados de uma maneira “depth-first”.
93
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
VISCO usa a geometria dos desenhos das consultas seriamente e permite anotações de
meta-informações que podem ser usadas para especificar as consultas topológicas mais puras.
Essas meta-informações especificam relaxamentos e restrições adicionais do tipo “don’t care”
que define a interpretação das consultas. Essas restrições dizem respeito às informações
contidas na consulta do usuário de forma não proposital, ou seja, são informações que não
devem ser consideradas. A visibilidade dos relaxamentos definidos pelo usuário e de
restrições “don’t care” são umas das maiores contribuições deste trabalho [HW97].
4.4.2 Avaliando VISCO
Suas representações visuais de elementos geográficos possuem representações estranhas e
pouco expressivas à maioria dos usuários, o que dificulta o uso dos mesmos, tais como,
“cercos”, “percevejos”, “bolas de gude” e “ligas de borracha”. A construção de consultas em
VISCO é baseada em ícones que representam os objetos geográficos e seus operadores. Tem
uma interface composta por janelas bem informativas, mas não trabalha com padrões de
metadados.
4.5 SKETCH!
Sketch! [Mey92a, Mey92b, Mey94] é uma linguagem pictórica e totalmente dedutiva para
informações espaciais baseadas em desenhos. Acessos visuais tendem a ser bastante naturais
em informações espaciais porque as mesmas podem ser facilmente mapeadas em símbolos
pictóricos. A linguagem de consulta Sketch ! tem como principal metáfora o desenho.
Desenhos de entrada são interpretados pelo sistema de consulta e traduzidos em expressões
de um cálculo lógico orientado-a-objetos. É importante observar que cada desenho tem uma
interpretação bem-definida que pode ser formalmente derivada do desenho.
Nome = “Alemanha”
Rio 1
País 2
País 1
Figura 4.7 – Exemplo de um Desenho Espacial
94
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Dois tipos básicos de dedução diferentes podem ser distinguidos na manipulação de
informações espaciais: dedução proposicional e dedução espacial. Sketch! tem sua base
formal no modelo de dados orientado-a-objetos DeLOM. Um exemplo de uma consulta em
Sketch! pode ser vista na Figura 4.7.
4.5.1 Caracterizando Sketch!
Todo objeto no modelo DeLom [Mey92a], tem uma identidade única e um número de
atributos nomeados, que tanto podem ser dados (slots) como objetos (portas ) valorados.
Exemplo:
Classe Estrada:
Slots: nome → string,
Portas:
de
rota
→ cidade,
→ linha,
para
→ cidade.
Objetos que não possuem atributos do tipo objeto-valorados são chamados objetos
simples, caso contrário, são chamados de links. Um objeto é completamente definido por sua
classe, sua identidade, os valores de seus slots e as referências de suas portas. Os links são a
única maneira de se modelar relações entre objetos, já que não existe nenhum conceito
separado para os relacionamentos.
4.5.2 Linguagem de Consulta
As consultas são formadas por conjunções de fórmulas de objetos. Uma fórmula de objeto
atômico pode ser uma aplicação predicado, uma restrição, ou uma declaração de uma
variável objeto. Para usar uma fórmula como uma consulta, os atributos de resposta devem
ser definidos. Apenas variáveis dado-valoradas podem ser usadas como atributos de resposta.
A resposta é computada apenas com as informações geométricas.
O principal objetivo desta linguagem de consulta visual foi o de definir uma estrutura
de linguagem que se aproximasse de todos os processos de comunicação usados em
discussões sobre situações espaciais. Tipicamente nestas situações desenhos exemplos são
elaborados para aproximar a explicação das informações espaciais mais relevantes.
Informações não-espaciais são oferecidas em forma textual.
Sketch! divide as consultas em condições não-espaciais e espaciais. Enquanto as
restrições não-espaciais (proposicionais) são oferecidas na forma de objetos-grafos, as
restrições espaciais são oferecidas na forma de desenhos. Existe uma janela na interface na
qual os dados analógicos (espaciais) são representados por desenhos simples, e uma outra
95
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
onde dados proposicionais podem ser manipulados em figuras baseadas em diagramas.
Observe que estes desenhos não são elaborados pelo sistema de acordo com as restrições
espaciais oferecidas pelo usuário, pelo contrário, são feitos pelos usuários e interpretados
pelo sistema. No caso análogo, o conceito de ícones tem sido considerado levando-se em
consideração o formato do ícone, sua posição no espaço e talvez outras propriedades
analógicas como intensidade ou cores. Este projeto, refere-se a este tipo de ícones como
ícones analógicos, ou ácones.
Como foi dito acima, as informações não-espaciais são expressas por grafos-consulta.
Um grafo-consulta consiste de nodos objetos e nodos links. Cada nodo é nomeado pelo nome
de uma variável do tipo objeto que é, por default, um nome de uma classe, com um número
acrescido. Os rótulos devem ser únicos dentro de um grafo simples. Grafos-consulta não
precisam estar conectados entre si.
Os desenhos, por outro lado, consistem de objetos espaciais com relacionamentos
topológicos implícitos entre os mesmos. Os objetos que estão contidos em um desenho ou
são definidos pelos usuários, ou são sub-objetos definidos por uma relação topológica entre
alguns objetos explícitos. Cada objeto explícito em um desenho deve possuir um único rótulo
e deve representar necessariamente objetos distintos. Sub-objetos não são incluídos
explicitamente, mas derivados de outros objetos e seus relacionamentos topológicos.
O algoritmo de interpretação dos desenhos segue as seguintes regras [Mey94]:
(1) Relacionamentos topológicos são testados em todos os possíveis pares de objetos e
sub-objetos no desenho.
(2) Todos os relacionamentos no conjunto P de predicados espaciais são testados.
(3) Se um predicado p(x,y) aparece e existe uma função f e F correspondente a p,
então os sub-objetos serão calculados por f(x,y) e então serão interpretados como
objetos normais.
(4) Relacionamentos topológicos são sempre testados por um objeto inteiro, ou seja,
nunca será derivado que “uma parte” de um objeto está dentro de um outro objeto.
(5) Não serão derivados relacionamentos de negação.
(6) Não serão derivados relacionamentos entre um objeto e seus sub-objetos.
(7) Sub-fórmulas deduzidas são redundantes e podem ser removidas.
96
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
4.5.3 A Interface Sketch!
A nova metáfora, o paradigma do quadro-negro (Blackboard paradigm), é considerada uma
forte candidata à representação cognitiva adequada para resolver os problemas de linguagens
de consultas espaciais. Isto porque este paradigma faz um forte uso do conceito familiar de
espaço. Sketch! é uma linguagem de consulta visual com lógica baseada neste paradigma, que
se apresentou bastante interessante no projeto de interfaces baseadas-em-canetas [Mey92a].
O problema geral de interfaces para SIG consiste em que todos os formalismos que
tentam visualizar todos os aspectos espaciais de uma consulta em uma visualização simples
não são satisfatórios porque estes formalismos não podem gerenciar relações “don’t care”, e a
representação inflexível de linguagens icônicas torna o problema ainda mais difícil.
Em princípio, existem duas possibilidades ao se construir um sistema com uma
linguagem baseada em quadro-negro. Uma delas é usar um sistema totalmente baseado-emcaneta, no entanto isso sobrecarrega o sistema na tarefa de reconhecimento integral dos
desenhos feitos-à-mão. A alternativa que foi escolhida nesta proposta foi usar um tipo de
editor direcionado à sintaxe, tornando o reconhecimento de padrões desnecessário e ao
mesmo tempo, provendo um ambiente poderoso que auxilia o usuário a sintetizar consultas
corretas.
O uso de menus sensitivos-a-contexto orienta o usuário durante uma sessão de modo
que apenas um pequeno conhecimento do sistema é necessário. A área de trabalho consiste de
dois tipos de janelas: uma janela de consulta proposicional (p-window) e uma janela de
consulta espacial (s-window), que corresponde aos dados proposicionais e analógicos
respectivamente, como mostra a Figura 4.8.
97
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Figura 4.8 – Exemplo de Consulta na Interface do Sketch! [Mey92a]
Existem quatro tipos de ácones: ponto, linha , poligonal e curva. Qual desses será usado
na visualização, vai depender da classe do objeto a ser visualizado e do tipo dos atributos
geométricos ativos do objeto.
Predicados espaciais, tais como interseção, são incluídos de uma maneira pouco
diferente de predicados proposicionais, que correspondem aos links. Eles não precisam nem
podem ser fornecidos explicitamente. No entanto, eles são extraídos automaticamente do
arranjo de ícones, ou seja, se uma interseção entre dois objetos for necessária, é suficiente
fazer estes ícones se interceptarem na janela s-window. O predicado de interseção será
derivado pelo sistema sem nenhuma interferência do usuário.
98
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Atributos dado-valorados podem ser inseridos tanto na s-window como na p-window,
onde o usuário preferir. Se eles forem feitos em ambas as janelas estas condições serão
interpretadas como condições conjuntivas. Podem existir várias p-windows ou s-windows em
uma mesma consulta, cada uma delas denotando uma fórmula de uma consulta conjuntiva.
Como exemplo de utilização do Sketch!, a representação textual final da consulta
representada na Figura 4.8, é equivalente a [Mey92a]:
query(fname=FN, products=Pr, cname=PN)
C1, C2 : country ∧ R1: river(pollution=P) ∧
F1: factory(name=FN, products=Pr) ∧ T1: town ∧
P1: person(name=PN) ∧ channel(spring=F1, sink=R1) ∧
R1 intersects intersection(C1, C2) ∧ F1 inside C1 ∧ T1location inside C2∧
50 > min_dist(R1, T1location ) ∧ P<> [] ∧
employed(employee=P1, place=F1, position=“chairman”) .
Assim como predicados espaciais, funções espaciais são visualizadas na s-window. Para
aplicar uma função espacial, os objetos-argumentos deverão ser selecionados por
apontamento e o símbolo da função deverá ser invocado a partir do menu. Em alguns
predicados e especialmente em funções de agregação, conjuntos de valores ou de objetos são
usados como argumentos.
Se as consultas se tornarem muito complexas, a visualização pode se tornar um pouco
confusa, consistindo apenas de estruturas de linhas e pontos, apesar de que normalmente,
consultas interativas não chegam a este nível de complexidade. Mas se isto acontecer, a
melhor coisa a fazer é modularizá-las pelo uso de outras visões. Desta forma, partes inteiras
do diagrama serão reduzidas a um simples ícone, o que torna os diagramas mais claros e
reduzidos.
4.5.5 Avaliando Sketch!
A princípio Sketch! tem características comuns ao CIGALES, mas existem algumas diferenças
básicas, não apenas na aparência e estrutura da linguagem, como também no paradigma
fundamental em que se baseia a linguagem. O objetivo de Sketch! é explorar conceitos de
linguagens que sejam mais bem aplicados para usuários não-experientes, que não estão
acostumados com os conceitos de linguagens, mas são bem informados a respeito da estrutura
dos dados com os quais eles estão trabalhando.
99
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
A interface de Sketch! é baseada no paradigma do quadro-negro, onde os usuários
desenham a mão-livre e o sistema deduz sua interpretação. Isto implica na implementação
árdua de algoritmos eficientes para interpretação destes desenhos.
4.6 S PATIAL-QUERY -BY-SKETCH
Esta proposta está baseada no desenho a mão-livre. Este método é diferente de outras
propostas anteriormente discutidas porque o usuário especifica livremente cada propriedade
dos objetos, particularmente seu formato, tipos, localizações, orientações, e relações espaciais
entre objetos. O uso da técnica do desenho livre permite que usuários pensem espacialmente
tornando a interação com a linguagem de consulta espacial mais natural. Isto acontece
porque freqüentemente usuários têm uma representação baseada em imagens em suas mentes
quando buscam por configurações espaciais.
Expressando as configurações espaciais em uma linguagem natural ou semiformal, o
uso de sistemas de informações espaciais se torna um sucesso, principalmente se os usuários
tiverem permissão de desenhar uma figura ou imagem que eles tenham em mente,
recuperando os dados de seus interesses.
4.6.1 Caracterizando o Spatial-Query-By-Sketch
Apresenta-se aqui uma linguagem de consulta espacial chamada Spatial-Query-By-Sketch
[BE00, Ege96] que permite que os usuários expressem consultas espaciais muito próximas da
maneira como eles pensam a respeito de muitos problemas espaciais e incorpore mecanismos
de entendimento poderosos para inferir variações geométricas no desenho. O desenho
permite um feedback gráfico imediato e, portanto, é inerentemente um processo mais natural
para formular restrições espaciais do que as linguagens textuais.
O conceito de Spatial-Query-By-Sketch fica próximo da proposta Sketch!. No entanto,
este é fundamentado em um modelo matemático sólido de relações espaciais e seus
relaxamentos.
Spatial-Query-By-Sketch utiliza um dispositivo de entrada sensível ao toque, idealmente
estes dispositivos são dotados de uma caneta digital. Simulações podem ser obtidas com um
mouse ou trackballs, mas desenhar com estes dispositivos é mais vagaroso e menos efetivo.
Uma consulta desenhada consiste de cinco passos, partindo do desenho propriamente dito até
a sua execução pelo sistema de gerenciamento de banco de dados.
100
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Passo 1: O usuário desenha com a caneta um protótipo de uma configuração
geométrica que fica mais próximo
da situação espacial que ele espera
recuperar do banco de dados geográfico.
Passo 2:
O usuário anota no desenho descrições das propriedades desejadas dos
objetos desenhados. Estas anotações podem incluir a especificação destas
classes de objetos, atributos de objetos e restrições métricas.
Passo 3: Spatial-Query-By-Sketch analisa o desenho e o traduz para uma representação
em pixels em um modelo de dados vetorial e topológico.
Passo 4: Spatial-Query-By-Sketch desenvolve o plano de processamento da consul-ta.
Se necessário, as ambigüidades são resolvidas a partir de um processo de
intervenção visual com o usuário.
Passo 5: O processador de consultas executa a consulta no banco de dados espacial e
recupera o cenário que casa com a consulta solicitada em prioridade, de
modo que os cenários que melhor casem com a consulta serão recuperados
primeiro.
Embora estes processos estejam conceitualizados como passos, eles não precisam
obrigatoriamente acontecer de uma maneira linear. Por exemplo, depois de desenhar o
primeiro objeto, o usuário pode anotar imediatamente sua geometria e sua semântica, e
depois retornar ao passo 1 para desenhar o próximo objeto. O analisador irá agir assim que o
usuário começar a desenhar e não irá esperar o desenho ser completado e completamente
anotado. Desta forma, depois de analisar uma consulta o sistema pode intervir com o usuário
e requisitar informações adicionais esclarecedoras, o que fará possivelmente com que o
usuário reedite seu desenho. De uma maneira similar, depois de examinar o resultado da
consulta no passo 5, o usuário pode desejar modificar a sua consulta e submetê-la novamente.
4.6.2 A Linguagem de Consulta
O processamento de consultas desenhadas é uma tarefa não-trivial, porque os desenhos
necessitam de interpretação de quais aspectos o usuário desenhou intencionalmente, e quais
restrições foram acidentais. Isto difere consideravelmente do processamento de outros tipos
de consultas, onde relações espaciais são fornecidas explicitamente e as semânticas dos
101
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
relacionamentos são fixas. Em Spatial-Query-By-Sketch o processador de consultas precisa
determinar o que deve seguir rigorosamente e o que pode ser relaxado.
Por exemplo, em uma linguagem de consulta baseada em SQL convencional um
usuário pode formular uma consulta que recupere todos os lagos incluídos em um Estado,
sem ter que especificar suas extensões, orientação, nem tamanho dos lagos ou do Estado. Por
outro lado, um usuário pode fazer uma tradução correta da imagem em sua mente para uma
expressão verbal. Este processo pode gerar algumas ambigüidades porque o mapeamento de
representações pictóricas em descrições verbais é altamente subjetivo.
Uma segunda fonte de imprecisão surge quando a consulta espacial é processada pelo
banco de dados espacial. Bancos de Dados Geográficos guardam a geometria dos seus dados
em um modelo de dados vetorial ou matricial. Além disso, um processador de consultas tem
que entender a semântica dos termos espaciais, de modo a saber o que deve ser recuperado
do banco de dados.
Se o SGBD tiver que recuperar apenas as configurações que provêem um casamento
exato com o desenho, métodos de casamentos de padrões de imagens e recuperação de
imagens podem ser aplicados. No entanto, para informações geográficas, pode ser necessário
relaxar algumas restrições do desenho porque o usuário pode ter desenhado algumas partes
do cenário exemplo acidentalmente, ou seja, sem intenção de fazê-lo. Para decidir quais
restrições devem ser relaxadas e quais restrições devem ser mantidas, é necessário basear o
processamento da consulta em um modelo computacional de similaridades em relações
espaciais.
A análise das relações topológicas está baseada no modelo 9-intersection [EH91], um
modelo completo para relações topológicas binárias que se aplica a objetos do tipo: área,
linha e ponto. As relações topológicas que podem ser realizadas entre duas regiões espaciais
em Spatial-Query-By-Sketch são: disjunto, encontra, sobrepõe, contém, cobre, dentro_de,
coberto_por e igual.
Em Spatial-Query-by-Sketch, segundo Blaser [BE00], dentro das relações topológicas,
as relações que são mais similares com outras são descritas em termos de grafo de vizinhança
conceitual. Por exemplo: cobre ↔ coberto_por; contém ↔ dentro_de ↔ igual.
O relaxamento de uma relação topológica corresponde à troca de suas vizinhanças
conceituais. Por exemplo, se um usuário desenha um cenário onde uma linha estava
102
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
totalmente incluída no interior de uma região, então o relaxamento irá considerar não só esta
configuração que casa exatamente com esta relação topológica, mas também as que casam
com suas vizinhanças conceituais. Altos graus de relaxamento podem alcançar recursividade,
movendo de vizinhos conceituais para os mesmos. Quanto mais uma relação topológica for
relaxada, menos semelhante a relação se torna de sua geradora.
Spatial-Query-By-Sketch analisa o desenho e extrai, a partir do modelo de dados
vetorial do mesmo, as relações topológicas, tal como foram desenhadas. Para n objetos em
um desenho existem n2 relações topológicas binárias.
O processamento da consulta
desenhada pode ser analisada na Figura 4.9.
Consulta Espacial Desenhada
Rede Semântica derivada
do desenho do usuário
Sentença da linguagem de
consulta espacial do BD
Banco de
de
Dados
Dados
Espacial
Espacial
Sistema de
Gerenciamento
do
Banco de Dados
Sistema de Processamento da Consulta
Conjuntos de Registros
Recuperados do BD
Acessos similares e classificação
baseada em comparações com a
.
configuração original
Melhores resultados e
“casamentos” classificados .
Figura 4.9 – Esquema de Processamento de uma Consulta em Spatial-Query-By-Sketch
[Bla02]
Uma parte crítica do analisador sintático das consultas e do processador de consultas é
o modelo de interpretação do desenho, particularmente as relações espaciais entre os objetos
considerados. Usuários inexperientes irão inevitavelmente fazer desenhos com uma grande
variação mesmo que eles tenham a mesma configuração em suas mentes. Da mesma forma, o
mesmo usuário poderá introduzir variações randômicas quando repetirem o mesmo modelo
103
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
de desenho. Além disso, é necessário selecionar um modelo que será robusto o bastante para
suportar estas variações.
4.6.3 – Interface Spatial-Query-By-Sketch
Spatial-Query-By-Sketch está baseado na premissa da importância topológica e do
refinamento métrico. Quando o usuário desenha coincidência, inclusão, disjunção, ou
separações de características, estas especificações são consideradas mais críticas do que
direções sobre características espaciais como distâncias relativas, áreas, e outros detalhes.
Figura 4.10 – Spatial-Query-By-Sketch [Bla02]
Um aspecto crítico da interação do sistema (Figura 4.10) é que desenhos baseados em
canetas digitais podem ser usados para dois propósitos: (1) o desenho da consulta cenário e
(2) a interação com o desenho para acomodar operações tais como seleção dos objetos
desenhados; reposicionamento e eliminação de objetos; e a troca da visão do usuário sobre o
desenho. A caneta utilizada na implementação de Spatial-Query-By-Sketch possui um botão
rocker com duas posições: forward e backward. A primeira posição troca o modo da
ferramenta selecionada atual, e a segunda, inicia um menu dependente de contexto. A caneta
introduz ainda dois estados (pressionado e não-pressionado).
A interação baseada em caneta provê um método de zooming mais direto do que as
ferramentas de zoom comumente encontradas nos SIG atuais. Com o botão rocker na posição
neutra e o estado pressionado, a caneta se move a partir do centro da área de desenho
fazendo o zoom-out gradual.
Spatial-Query-By-Sketch permite que os usuários mostrem o desenho em três diferentes
níveis de abstração: (1) o desenho original com os detalhes das linhas do usuário; (2) a visão
do objeto interpretado, que mostra como Spatial-Query-By-Sketch é traduzida de linhas em
objetos; (3) uma visão diagramática, que captura as relações espaciais entre os objetos
identificados que foram considerados no processamento da consulta.
104
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
A visão de desenho acomoda o ambiente da interface com o usuário. É o lugar em que
o desenho é inicialmente criado e editado.
A visão de objeto mostra como o sistema agregou as linhas em objetos. Esta visão
mostra o resumo interpretado e simplificado de cada objeto. Ele distingue através do uso de
cores os tipos de objetos. Esta visão permite ao usuário avaliar a interpretação dada ao seu
desenho, e modificá-lo, caso desejado.
A visão de diagrama é a visão mais abstrata do desenho, pois mostra simbolicamente os
objetos como relações espaciais binárias. Relações espaciais são geradas e computadas de
acordo com a configuração do desenho digital, enquanto que o conjunto de objetos é dado
pela consulta desenhada. Esta visão permite que um usuário examine e edite certos aspectos
de seu desenho melhor do que a visão de objeto ou a visão de desenho.
4.6.4 Avaliando Spatial-Query-By-Sketch
A proposta de Spatial-Query-By-Sketch tem como principal filosofia a construção das
consultas a mão-livre, assim como no Sketch!. No entanto, esta é fundamentada em um
modelo matemático sólido de relações espaciais e seus relaxamentos. Uma consulta
desenhada consiste de passos, partindo do desenho propriamente dito até a sua execução
pelo sistema de gerenciamento de banco de dados. Em Spatial-Query-By-Sketch o
processador de consultas precisa determinar o que deve seguir rigorosamente e o que pode
ser relaxado.
A interface com o usuário conta com equipamentos modernos, sensíveis ao toque, onde
os usuários utilizam canetas para a construção de suas consultas. Os operadores espaciais
disponíveis na interface, no entanto, são limitados.
4.7 O UTRAS PROPOSTAS
Existem algumas outras propostas, igualmente importantes, que são apresentadas a seguir de
forma resumida. O fato delas serem apresentadas desta forma deve-se ao fato de que não foi
possível, pela literatura encontrada, uma avaliação mais extensa das mesmas.
GeoMedia [Geo02] é uma ferramenta de acesso, integração e análise de dados geográficos,
com uma interface gráfica com funcionalidades para a realização de consultas dinâmicas
como, por exemplo, capacidade de agregação, junção analítica, zoneamento de buffer, análise
linear, entre outras. Acrescenta também características de apresentação de mapas, plotagem e
105
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
visualização, e suporta padrões industriais de interface como OGC e de formatos de dados.
GeoMedia permite não só a visualização de dados em múltiplos formatos, mas também a
análise dessa informação pela execução de consultas, zonas de buffer e temas sobre diversos
formatos SIG. Pode-se executar análise espacial complexa utilizando-se um conjunto de
ferramentas de análise avançadas. Isto inclui funções espaciais tais como: “inteiramente
contido em”, ou “toca”, um conjunto completo de funções aritméticas e todas as ferramentas
necessárias para se criar consultas do tipo “what if”. Podem-se criar imagens de satélite
integradas com outras informações geográficas e expandir conjuntos de dados adicionando-se
novas características. GeoMedia oferece além disso, geo-codificação o que traduz dados
tabulares em dados espaciais. GeoMedia é OLE compatível de modo que pode-se associar
imagens, spreadsheets, e outras informações com características de mapas para preparar
relatórios, anotar desenhos, e criar apresentações.
ArcInfo 8 [Pot02] é a última versão do ArcInfo [UGIS95] para SIG. Uma característica
chave do ArcInfo 8 é que ele torna SIG sofisticados mais fáceis de usar. Enquanto sua
funcionalidade é bastante completa, a sua interface se torna muito fácil pela apresentação ao
usuário do que ele quer quando ele quer. Novos aplicativos como o ArcToolbox, ArcCatalog
e o ArcMap provêem interfaces fáceis de usar tornando o trabalho com o ArcInfo mais fácil
do que antes. Um novo modelo de dados de componentes de objetos, permite, através das
características tradicionais de ponto, linha e polígono, modelar objetos tais como estações de
força e circuitos elétricos, de uma maneira mais realista. Permite, também, personalizar as
interfaces de suas ferramentas de acordo com as aplicações. ArcMap e ArcCatalog possuem
um menu de ferramentas com a opção “Customize” que permite a modificação de botões de
forma fácil, além de outras ferramentas disponíveis na interface sem necessidade de
programação. ArcInfo 8 permite modernizar aplicações de SIG e expandir o seu uso através
de ferramentas mais poderosas, um modelo de dados mais flexível e um ambiente altamente
adaptável.
Uma outra proposta de consultas visuais em dados espaciais é SVIQUEL (Spatial Visual
Query and Exploration Language) [KR98a] [KR98b]. SVIQUEL permite que os usuários
realizem consultas sobre posições espaciais relativas de dois conjuntos de objetos, capturando
tanto a parte topológica como direcional do relacionamento. SVIQUEL utiliza como
componentes: Interface de Slides Espaciais (Spatial Slider Interface S-Sliders), Figuras Ativas
para Interface de Consultas (Active Picture for Querying Interface – APIQ), o Processador de
106
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Consultas (Query Processor) e a visualização espacial dos resultados das consultas (Spatial
Visualization of Results - SVIZ). Um usuário em SVIQUEL especifica uma consulta usando
uma combinação de S-sliders com interfaces APIQ. S-sliders são filtros de consultas espaciais
dinâmicos e APIQ é um complemento natural ao modelo de consultas SVIQUEL. APIQ pode
mostrar, por exemplo, todas as posições primitivas que as casas podem ocupar com respeito a
um lago, cada posição graficamente definida por uma descrição SPRIM. SPRIM é cada
relacionamento espacial primitivo que pode ser definido entre dois objetos. SVIQUEL oferece
aos usuários: uma interface visual para especificar consultas espaciais com relacionamentos
relativamente posicionados de qualquer tipo, tal como topológicos ou direcionais; habilidade
para ajustar rapidamente consultas espaciais através da manipulação direta e para especificar
de forma incremental consultas espaciais; poder tanto para especificar consultas particulares
bem como para navegar através dos relacionamentos espaciais, sem nenhuma consulta em
mente; e habilidade para compor consultas complexas assim como uma combinação de
relacionamentos espaciais de uma maneira simples.
Uma outra proposta de linguagem de consulta visual para bancos de dados geográficos
é a PQL* [PR99] (Pictorial Query Language declarativa), que é uma extensão de PQL. PQL*
é capaz de expressar consultas em um banco de dados geográfico orientado-a-objetos,
desenhando as características que formam a consulta. Consultas complexas podem ser
expressas por operações pictóricas simples e intuitivas. Usando características simbólicas
como uma representação de classes geográficas e objetos, as consultas são compostas
colocando os objetos espaciais que estão envolvidos nos relacionamentos topológicos e
posicionais graficamente em evidência. Desta forma, as semânticas das consultas são
expressas desenhando-se figuras geométricas. Uma das características peculiares desta
proposta é que a mesma permite a realização de consultas no nível intencional, ou seja,
consultas ao esquema do banco de dados. PQL* oferece um alto poder expressivo, porque os
usuários compõem suas consultas pictoricamente, expressando desta maneira todos os
relacionamentos topológicos entre os objetos geográficos envolvidos; a sua característica nãoprocedural permite voltar a atenção do usuário ao que ele deseja, e não ao como.
4.8 Análise Comparativa das Propostas de Interfaces de Consultas Visuais para SIG
Fazendo uma análise comparativa entre os diversos sistemas de consultas visuais para SIG,
apresentamos a Tabela 4.1 que mostra as semelhanças e as particularidades de cada um.
107
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
É bom salientar que cada sistema tem sua característica em particular como, por
exemplo, o desenho a mão livre disponível em Spatial-Query-By-Sketch [BE00], que necessita
de algoritmos de interpretação de desenhos muito complexos, ou a proposta SVIQUEL
[KR98a], que utiliza Sliders de valores na interface.
Sistemas de
Consultas
Visuais para
SIG
CIGALES
[CM91]
Lvis
[BAT00]
VISCO
[WH98]
SKETCH
[Mey92a]
SPATIALQUERY-BYSKETCH
[BE00]
Características
Operadores
Disponíveis da
Linguagem
Funções de localizaInclusão, Interção, modificação de
Interface pobre, seção, Adjacência,
objetos e medida de
com poucas
Caminho, Ligação,
superfície. Versão
funcionalidades. Extensão, União e
acadêmica.
Diferença.
Interface bem
Interseção, Inclutrabalhada,
são, Adjacência,
Consultas temáticas,
disponibiliza os
Disjunção, Igualespaciais, temporais e operadores da
dade. Antes, Igual,
espaço temporais.
linguagem de
Encontra, Sobreforma visual
põe, Durante,
permitindo vários
Começa e
tipos de consulta.
Termina.
Interface baseada
Janelas de controle e
em ícones e
Disjunto,
informação e muitas menus, mas com Intersecta, Dentro,
facilidades na
representações
Contém,
elaboração das
estranhas e pouco
Conectado,
consultas.
expressivas.
Sobrepõe.
Os desenhos são
associados com
ícones e menus que
facilitam o
entendimento.
Interface
Interface pouco
amigável e
confusa.
Oferece refinamentos
métricos nas
Interface com
consultas e
tecnologia
relaxamento das
avançada e muito
relações.
amigável.
Metáfora
Icônica.
Icônica.
Icônica.
Intersecta, Dentro,
Distância_Max,
Quadro_Negro.
Distância_min,
(Desenhos e
Merge,
ícones)
Mais_perto.
Disjunto, Encontra, Sobrepõe,
Contém, Cobre,
Dentro, É-Coberto-por, Igual.
Desenho Livre.
Permite análise
Interface bastante
espacial complexa e amigável e autoGEOMEDIA execução de consultas explicativa, toda Funções espaciais e Ícones, Menus e
[Geo02]
sobre diversos
baseada em
aritméticas.
Mapas.
formatos SIG.
ícones, com
janelas de ajuda.
108
Capítulo 4 – Sistemas de Consultas Visuais para SIG
_______________________________________________________________________________________________
Produto poderoso e
composto por vários Interface bastante
aplicativos que se
amigável e
ARCINFO 8
completam na
facilmente
manipulação
adaptável às
[Pot02]
de diversos formatos
diversas
de dados geográficos. aplicações SIG.
(informação
desconhecida)
Ícones, Mapas, e
Imagens de
Satélite.
Interface pouco
Disjunto,
Os sliders de consulconvencional e
Encontra,
SVIQUEL
tas dinâmicas que
complexa con- Sobrepõe, Contém,
[KR98a]
apresentam os
tendo Sliders com Cobre, É-cobertopossíveis valores dos possíveis valores
por, Contém,
Sliders.
atributos é a principal de atributos para
Dentro, Igual,
característica deste
a construção de
Norte, Sul, Leste,
sistema.
consultas.
Oeste.
Tem como funInterface amigá- União, Diferença,
cionalidade adicional
vel com
Disjunto, Toca,
PQL
a realização de
construção de
Igualdade, DistânIcônica
consultas usando
consultas baseacia, ao-norte-de,
[PR99]
operadores OLAP.
das em ícones.
ao-sul-de.
Tabela 4.1 Análise Comparativa dos Sistemas de Consultas Visuais para SIG
4.9 C ONCLUSÃO
Neste capítulo, tivemos oportunidade de discutir alguns sistemas que utilizam o paradigma de
consultas visuais em Sistemas de Informação Geográfica (SIG). Alguns desses sistemas
utilizam ícones gráficos para a definição das consultas, como CIGALES e VISCO, outros
utilizam o desenho livre como Spatial-Query-By-Sketch. Sketch! se caracteriza por usar as
duas maneiras em conjunto para formalizar uma consulta.
Cada um desses sistemas se dispõe a resolver algum subconjunto do imenso conjunto
de problemas existentes na definição da interface ideal para SIG, usando a tecnologia de
consultas visuais. Ainda existem outros problemas que não foram atacados por estes sistemas,
tais como, a definição de uma representação visual para dados espaciais e a definição de uma
linguagem de consulta visual que utiliza padrões de metadados em sua concepção. Esses
aspectos são considerados nesta tese, e são apresentados no próximo capítulo.
109
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
CAPÍTULO 5
C ONSULTAS VISUAIS EM BDG BASEADAS EM M ETADADOS
ESPACIAIS
“Ide, pois aos vossos campos e pomares,
e lá aprendereis que o prazer da abelha é de sugar o mel da flor,
mas que o prazer da flor é de entregar o mel à abelha.
Pois, para a abelha,
uma flor é uma fonte de vida.
E para a flor
uma abelha é mensageira do amor.”
(Gibran Khalil Gibran)
5.1 I NTRODUÇÃO
Este capítulo apresenta GeoVisual – Um Ambiente para Consultas Visuais em Bancos de
Dados Geográficos. GeoVisual tem como objetivo principal facilitar o acesso a informações
em Bancos de Dados Geográficos (BDG) por meio de uma interface apropriada e de uma
linguagem de consulta visual.
Apresentamos a seguir a arquitetura do sistema proposto com seus diversos módulos e
funcionalidades. Dentro desses módulos, definimos uma representação visual para dados
geográficos e uma Linguagem de Consulta Visual Geográfica. Esta linguagem é definida
através de um formalismo apropriado como também a tradução das sentenças de consultas
visuais para a linguagem textual, baseada em SQL, está definida no Apêndice C, anexado a
este trabalho.
110
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Um protótipo deste sistema foi desenvolvido e será apresentado no próximo capítulo.
5.2 Sistema GeoVisual
“GeoVisual – Um Ambiente de Consultas Visuais para Bancos de Dados Geográficos ”,
é composto de quatro módulos que foram definidos segundo a sua funcionalidade.
Estes módulos se relacionam entre si e cada um desempenha um papel fundamental
no funcionamento do sistema. A arquitetura GeoVisual é apresentada na próxima
seção.
5.2.1 ARQUITETURA DO SISTEMA GEOVISUAL
A arquitetura do Sistema GeoVisual, Figura 5.1 [SS00, SS99], é baseada em módulos que
possuem tarefas definidas e independentes que interagem entre si: SGBD, Modelo de
Metadados, Gerenciador de Consultas e Interface Gráfica.
5.2.1.1 Módulo do SGBD
Inclui o modelo de dados do SGBD, o Banco de Dados Geográfico, ou abreviadamente BDG,
e a sua Linguagem de Consulta Espacial. O Modelo de Dados do SGBD descreve como as
informações geográficas são estruturadas internamente ao BDG. Tomaremos como base,
neste nível, o modelo de geodados definido pelo Open GIS [OGC99a] e a especificação SQL
deste mesmo consórcio [OGC99b].
111
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Interface GeoVisual
LEGENDA
Caixa de Diálogo
Ferramentas
Gráficas
Editor
Editorde
de
Consultas
Consultas
Janela
Janelade
de
Resultado
Resultado
das
dasconsultas
consultas
Interação entre
os módulos
Usuário
Interação/Dependëncia entre
componentes
Principal
contribuição
Informações
Metadados
Gerenciador de Consultas
GeoVisualQL
Tradutor de
Consultas
SGBD
Modelo de Metadados
Descrição dos Dados
Padrão de
Metadados
Espaciais
Símbolos
Visuais
Modelo
de Dados
Open GIS
BDG
SQL
Estendido
Open GIS
Figura 5.1 – Arquitetura do Sistema GeoVisual
5.2.1.2 Módulo do Modelo de Metadados
Para este módulo, assume-se que os BDG estão com as suas bases de dados descritas através
do padrão de metadados do FGDC [FGD99]. As informações referentes às feições
geográficas, armazenadas no banco de dados, deverão estar descritas por seus metadados em
arquivos independentes, os quais chamamos de “arquivos de metadados do BDG”.
Esses arquivos de metadados auxiliam o sistema na geração das sentenças SQL de
forma correta. Para cada aplicação, pode-se definir um conjunto de símbolos visuais para suas
feições geográficas, que poderão ser utilizadas na construção de consultas. Estes símbolos
112
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
visuais são representações vetoriais dos tipos ponto, linha e polígono, ou variações dos
mesmos.
5.2.1.3 Módulo Gerenciador de Consultas
Neste módulo, uma Linguagem de Consulta Visual, a GeoVisualQL (Geographic Visual
Query Language), é definida utilizando os símbolos visuais básicos das geometrias ponto,
linha e polígono como também dos operadores espaciais da linguagem. É necessária a
definição de analisadores sintático e semântico para a efetiva tradução das sentenças de
consultas visuais para sentenças de consultas textuais.
O Módulo
Gerenciador de Consultas, detalhado na Figura 5.2, mostra o processo de
tradução da sentença de consulta visual, vindo do módulo de interface, para a sentença de
consulta textual que será utilizada na consulta efetiva ao BD Geográfico.
GeoVisualQL
Tradutor da
Consulta
Objetos
Pictóricos
Analisador
Sintático
Sentença
de consulta
visual
Operadores
Espaciais
Analisador
Semântico
Sentença
de consulta
textual
Figura 5.2 – Gerenciador de Consultas
A linguagem GeoVisualQL está baseada na especificação da linguagem SQL estendida
do OGC [OGC99b], que será referenciada, daqui por diante, por linguagem base. Os
operadores espaciais de natureza topológica e os operadores espaciais de conjunto da
linguagem base foram definidos visualmente na
GeoVisualQL. Alguns operadores
topológicos, não encontrados na linguagem base, foram adicionados à linguagem visual
GeoVisualQL, como está apresentado na seção 5.5.
A análise sintática da sentença de consulta visual é feita baseada na gramática da
GeoVisualQL, onde algumas regras de tradução são usadas para gerar a sentença de consulta
textual equivalente. As regras de tradução são necessárias para garantir que a nova sentença
113
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
represente exatamente o que o usuário inicialmente pretendeu. Isto pode ser feito de acordo
com os seguintes passos:
•
Identificações de quais entidades estão envolvidas na sentença de consulta visual;
•
Construção da árvore sintática da consulta;
•
Geração da sentença textual a partir da sentença visual, segundo a especificação da
gramática GeoVisualQL e do tradutor.
A sentença textual gerada é usada para recuperar efetivamente as informações no banco de
dados geográfico, que faz parte do Módulo SGBD. O resultado da consulta é então
graficamente apresentado no Módulo da Interface Gráfica [Fer00, Cor02].
5.2.1.4 Módulo da Interface Gráfica
Este módulo é o nível mais alto da arquitetura do Sistema GeoVisual e tem como função
principal interagir com o usuário, disponibilizando, os elementos da linguagem GeoVisualQL
para a realização das consultas visuais. Através desta interface o usuário pode selecionar os
símbolos visuais componentes de uma consulta e submetê-la à execução pelo banco de dados
geográfico, sem haver necessidade de conhecimento prévio da linguagem de consulta espacial
específica de cada banco de dados.
Foi desenvolvido um protótipo da Interface GeoVisual, especificada nesta arquitetura, o qual
foi objeto de uma dissertação de mestrado [Fer00]. Algumas outras funcionalidades, não
anteriormente previstas, foram adicionadas à Interface [Cor02].
5.3 Escopo do Trabalho
Dentro da arquitetura do Sistema GeoVisual mostrada na Figura 5.1, o escopo deste trabalho
diz respeito a:
•
Especificação Formal da Linguagem de Consulta Visual – GeoVisualQL (Geographic
Visual Query Language), parte do Módulo Gerenciador de Consultas;
•
Definiçã o do Processo de Tradução da Linguagem GeoVisualQL, parte do Módulo
Gerenciador de Consultas, para a linguagem base;
•
Desenvolvimento/Atualização do protótipo do Sistema GeoVisual, com as novas
funcionalidades definidas;
114
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
Validação do Sistema, com uma aplicação de hidrologia.
Diante disto, descrevemos, a seguir, essas etapas acima mencionadas.
5.4 Representações Visuais do Sistema GeoVisual
Dentre os modelos de representação vetorial e matricial, o Sistema GeoVisual se propõe a
trabalhar apenas com o modelo de representação vetorial, o qual pode ser facilmente
representado pelas figuras geométricas de ponto, linha ou região (polígono regular).
Na definição de símbolos visuais básicos para representação de dados geográficos foi
considerado o modelo de geodados proposto pelo consórcio OpenGIS [OGC99a]. Nos
propomos a utilizar algumas geometrias das feições geográficas definidas pelo consórcio
OpenGIS [OGC99V], as quais se baseiam no modelo de representação vetorial. Uma feição
geográfica, no modelo de dados do OGC, é sempre associada a uma classe geométrica que
identifica o tipo do símbolo visual que representa a feição geográfica.
A Figura 5.3 mostra a hierarquia das classes geométricas, que representam as feições
geográficas, dentro da especificação OGC.
Sabe-se que não existe um modelo mental de visualização de entidades geográficas
único por parte dos usuários. O modelo mental é dependente da aplicação e da visão pessoal
de cada usuário. Segundo Golin [Gol91] modelos mentais são, de fato, o que os usuários têm
em suas mentes e o que os guiam no uso de sistemas e/ou aplicações. No entanto, algumas
representações visuais de tipos de feições geográficas já são utilizadas, por exemplo, em
mapas cartográficos. Símbolos visuais representativos de feições geográficas podem ser usados
para uma determinada aplicação dentro do Sistema GeoVisual.
115
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Geometria
Ponto
1+
Sistema de Referência Espacial
Curva
Superfície
Cadeia de
Linhas
Polígono
Coleção de Geometrias
2+
MultiSuperfície
MultiCurva
MultiPonto
1+
Linha
Linha Anel
MultiPolígono
MultiCadeiaLinhas
1+
Figura 5.3 – Hierarquia de Classes Geométricas [OGC99a]
No Sistema GeoVisual, para cada feição geográfica da aplicação pode-se associar um
símbolo visual que tenha uma melhor representação, ou seja, que lembre a figura geométrica
da feição geográfica real. Novos símbolos visuais podem ser acrescentados ao sistema, de
acordo com as aplicações em uso. Através da descrição de metadados, o projetista pode
indicar qual o símbolo visual que representa a feição geográfica que está sendo inserida no
banco. Desta forma, a interface poderá utilizar este símbolo visual para a realização de
futuras consultas. Como essa associação é feita será apresentado na seção 5.6.
Ponto
Linha
Polígono
Figura 5.4 – Símbolos Visuais Básicos da Linguagem GeoVisualQL
116
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
A linguagem GeoVisualQL utiliza apenas os três símbolos visuais básicos ilustrados na
Figura 5.4, dentro de todas as representações vistas na Figura 5.3. Isso se deve ao fato de que
esta linguagem trabalha apenas com geometrias simples. Ao utilizar estes símbolos visuais na
interface, o usuário deverá selecionar uma possível feição geográfica para os mesmos, dentro
da aplicação em uso. A esta feição também pode estar associado o nome de uma instância em
particular.
5.4.1 Utilizando os Padrões de Metadados
O principal objetivo de padrões de metadados espaciais, tal como FGDC [FGD99], é tornar
os dados espaciais bem estruturados e que os mesmos possam ser compartilhados entre os
diversos BDG, como se pôde ver no Capítulo 3.
A proposta de utilização de metadados na interface, denominada de GeoVisual
Interface (Geographic Visual Interface), tem como objetivo principal deixar disponível as
informações descritivas dos dados geográficos armazenados no banco de dados para poder
associar a cada entidade geográfica um símbolo visual.
A GeoVisual Interface apresentada em [Fer00] foi acrescida de uma funcionalidade que
trabalha com informações descritivas de metadados espaciais. Estas informações de
metadados realizam um importante papel na construção de consultas visuais por dois motivos
básicos: (1) O usuário, até então leigo de informações a respeito do conteúdo do banco de
dados geográficos, passa a dispor de informações a respeito das feições geográficas existentes
com seus respectivos símbolos visuais, ou seja, os objetos pictóricos∗ da aplicação em uso; (2)
O usuário, além de poder conhecer o conteúdo do banco de dados, pode utilizar estes objetos
pictóricos em consultas visuais.
5.4.2 Exemplo do Uso do Padrão FGDC e do Modelo OGC em uma Aplicação de
Hidrologia
Como dito anteriormente, a interface GeoVisual conta com informações de metadados que
servem para dar suporte aos usuários com informações a respeito das feições geográficas que
estão disponíveis no banco de dados.
∗
Objetos pictóricos fazem parte da definição da linguagem GeoVisualQL e estão definidos na seção 5.5.1
117
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
De acordo com o modelo de geodados do Open GIS [OGC99b] cada feição geográfica
armazenada no banco de dados está descrita em uma linha dentro de uma tabela de
metadados chamada GEOMETRY_COLUMNS. Para exemplificarmos a viabilidade do uso
desta proposta descrevemos as informações, que fazem parte de uma aplicação de Hidrologia
e estão contidas nesta tabela, através do padrão FGDC e o utilizamos na Interface GeoVisual.
A descrição de metadados completa está contida no Apêndice A desta tese. Estas informações
serão utilizadas posteriormente pelo tradutor de consultas. Mostramos na Figura 5.5 um
resumo da descrição de uma entidade de Bacia Hidrográfica, pelo padrão FGDC.
Entity_and_Attribute_Information:
Detailed_Description:
Entity_Type:
Entity_Type_Label: Bacia Hidrográfica
Entity_Type_Definition: Entidade Geográfica Bacias
Hidrográficas do Estado do RN
Entity_Type_Definition_Source: none
Attribute:
Attribute_Label: GEOMETRY_TYPE
Attribute_Definition: Tipo da Geometria Utilizada
Attribute_Definition_Source: INTEGER
Attribute_Domain_Values:
Enumerated_Domain:
Enumerated_Domain_Value: 5
Enumerated_Domain_Value_Definition: Números inteiros
representativos das geometrias 1=point, 3=linestring, e
5=polygon
Figura 5.5 – Descrição de Metadados da Feição Geográfica Bacia Hidrográfica
Para cada feição geográfica descrita nos metadados podemos associar o símbolo
visual correspondente que poderá ser utilizado na construção de uma consulta ao banco, ou
seja, definimos um objeto pictórico da linguagem.
5.5 D EFININDO A LINGUAGEM DE CONSULTA VISUAL – GEOVISUAL QL
A definição de uma nova linguagem de consulta envolve decisões que precisam ser tomadas,
principalmente na fase de projeto. Após analisar muitas propostas de linguagens de consulta
desenvolvidas para BDG, foi tomada a decisão de que o projeto da linguagem GeoVisualQL
deveria levar em consideração as iniciativas encontradas na literatura e descritas em [Soa01] e
ser baseada em alguma delas, criando, na verdade, uma versão visual de uma linguagem já
anteriormente existente e utilizada. Nesta fase, foi tomada a decisão de utilizar a
especificação SQL do consórcio Open GIS [OGC99b].
118
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
A linguagem GeoVisualQL é definida utilizando-se símbolos visuais que representam as
feições geográficas e os operadores da linguagem. As feições geográficas, que são manipuladas
no BDG, são representadas pelos objetos pictóricos da linguagem que serão definidos na
próxima seção.
Os operadores espaciais da linguagem também estão representados graficamente para
permitir que usuários componham suas consultas de forma completamente visual.
A formulação da consulta no sistema GeoVisual é baseada nas seguintes estratégias
definidas em [Cat+97]:
•
Por Navegação de Esquema: o sistema apresenta informações de metadados do banco
de dados geográfico no módulo da interface, de modo que os usuários possam
navegar através do mesmo, selecionando elementos para compor suas consultas.
•
Por Sub-Consultas: Os usuários podem re-submeter o resultado de suas consultas de
modo a obter informações mais detalhadas.
•
Por Seleção: as consultas podem ser formuladas pela manipulação direta dos símbolos
visuais, componentes da linguagem GeoVisualQL, e que estão disponíveis no módulo
da Interface.
A sintaxe de GeoVisualQL foi definida de acordo com a linguagem base, uma vez que
necessitamos que as construções possíveis desta linguagem tenham uma construção
equivalente de forma pictórica, ou seja, as regras sintáticas e semânticas da linguagem base
devem ser obedecidas na linguagem visual (Figura 5.6).
A decisão de optar pela especificação SQL do consórcio Open GIS, como linguagem
base, foi tomada de acordo com os seguintes fatores: (1) Como o modelo de dados que está
sendo usado é também o proposto pelo mesmo consórcio, o uso desta especificação SQL se
torna mais natural e apropriado; (2) As demais propostas de linguagens de consultas espaciais
são também, em grande parte, extensões de SQL. Muitas delas até hoje servem de base ao
desenvolvimento de novas linguagens, como a Spatial SQL [Ege94]. No entanto, a realidade
atual requer mais funcionalidades das novas linguagens, e a especificação SQL do Open GIS
tenta unir características das melhores linguagens, sendo atualmente tomada também como
referência de linguagens de consulta para BDG [ACK+98].
119
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Feições
Geográficas
Linguagem
de
Consulta
Espacial
Operadores
Espaciais
e
Lógicos
Objetos
Pictóricos
Símbolos
Visuais
Linguagem de
Consulta
Consulta
Visual
Geográfica
GeoVisualQL
Especificação Formal
Formalismo
Semântico
Formalismo
Sintático
Figura 5.6 – Linguagem de Consulta Visual Geográfica (GeoVisualQL)
A definição da linguagem de consulta visual GeoVisualQL foi feita considerando as
seguintes decisões:
•
A definição da sintaxe da linguagem visual GeoVisualQL é feita para um conjunto
de operadores permitidos na linguagem base;
•
A definição da semântica de GeoVisualQL é a mesma da linguagem base;
•
O formalismo utilizado para a definição de GeoVisualQL é a Picture Layout
Grammar – PLG [GR89a] [Gol91], que foi apresentado no Capítulo 4.
5.5.1 ESPECIFICAÇÃO DA GEO VISUALQL
Algumas considerações serão necessárias para definirmos a linguagem de consulta visual para
dados geográficos GeoVisualQL:
ü Os operadores de GeoVisualQL dividem-se em topológicos, de conjuntos e lógicos.
§
Os operadores topológicos atualmente disponíveis na linguagem são: equals,
disjoint, touches, within, contains, overlaps, intersects, crosses, croches,
crothin, crossects e crossout.
§
Os operadores de conjunto são: intersection, difference e union.
§
Os operadores lógicos são: and, or e not.
120
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
ü Símbolos visuais (sv) são as representações visuais dos objetos pictóricos e dos
operadores da linguagem.
ü O conjunto de tipos geométricos permitidos T é composto pelas representações
vetoriais simples: ponto, linha e polígono. Esses tipos geométricos também são
representados por símbolos visuais que são chamados de símbolos visuais básicos e
estão representados na Figura 5.4.
Definição 1: Seja a linguagem de consultas visuais para dados geográficos GeoVisualQL
definida como GeoVisualQL = (O,R,Σ), onde O é o conjunto de objetos
pictóricos da linguagem, R é o conjunto de operadores permitidos e Σ é o conjunto
de restrições sobre estes operadores.
Definição 2: Um objeto pictórico em GeoVisualQL é uma quádrupla op=(t,sv,fg,i) onde t ∈
T é o tipo da geometria, sv é o símbolo visual do objeto, fg é a feição geográfica
representada, e i (eventualmente vazia) é o valor da instância de fg.
Definição 3: Um operador em GeoVisualQL é uma tupla r=(to,sv) onde to representa o tipo
do operador espacial e sv é o símbolo visual do operador.
Definição 4: Um relacionamento espacial topológico em GeoVisualQL é uma tripla rt=
(r,op1,op 2), onde r ∈ R é um operador topológico, e op1 e op2 ∈ O são ambos
objetos pictóricos.
Definição 5: Um relacionamento lógico em GeoVisualQL é uma tripla rl = (r,rs1,rs2), onde
r ∈ R é um operador lógico e rs1 e rs2 são relacionamentos espaciais topológicos
ou relacionamentos lógicos. No caso do operador lógico not um dos
relacionamentos da tripla rl pode ser vazio.
Definição 6: Um relacionamento espacial de conjunto em GeoVisualQL é uma tripla rc =
(r,op1,op 2), onde r ∈ R é um operador de conjunto e op1 e op2 ∈ O são objetos
pictóricos.
Um relacionamento espacial de conjunto rc retorna, como resultado, uma
geometria. Relacionamentos espaciais topológicos rt e relacionamentos lógicos rl
retornam, como resultado, valores booleanos.
121
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Definição 7: Uma consulta visual em GeoVisualQL é representada por uma figura que
contém um agrupamento de símbolos visuais que ilustram um relacionamento
espacial topológico rt, um relacionamento lógico rl, ou um relacionamento
espacial de conjunto rc.
5.5.1.1 Operações sobre Feições Geográficas
Ao definir a linguagem GeoVisualQL é necessário levar-se em consideração que a mesma é
baseada numa linguagem textual que é uma extensão do padrão SQL. Isto implica dizer que,
as sentenças de consultas visuais serão, ao final, executadas como sentenças SQL.
As operações a serem definidas utilizam as primitivas definidas anteriormente: o
relacionamento espacial topológico , o relacionamento lógico e o relacionamento espacial de
conjunto.
Definição 8: Seleção por Atributos
Seleção por atributos
O operador de seleção por atributos σ sobre um conjunto homogêneo F de feições
geográficas, dada uma restrição ρ baseada apenas nos atributos descritivos de F, é tal que:
σρ (F) = { f ε F | ρ(f) }.
Esta é operação semelhante à seleção da álgebra relacional, como indica o exemplo:
"Recupere as cidades do Estado de Pernambuco com população entre 50.000 e 500.000
habitantes".
Para definir as operações de consulta espacial, é necessário descrever o conceito de
compatibilidade de predicado espacial.
Definição 9: Predicado Espacial Computável
Predicado espacial computável
Dados uma região geográfica R, e duas feições f1 e f2 cujas geometrias geo(f1) e geo(f2) ε R, um
predicado espacial ξ computável sobre f1 e f2 é uma restrição espacial, definível através de um
relacionamento topológico (disjoints, within, touches, overlaps, intersects, contains, crosses,
crothin, croches, crossects e crossout), ou de um relacionamento de conjunto (intersection,
difference e union), entre as representações geométricas geo(f 1) e geo(f2) destas feições.
122
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Intuitivamente, os predicados espaciais que se utilizam nessas operações envolvendo
feições geográficas são assertivas do tipo “Rio que cruza o município do Recife, na região do
Recife Antigo”.
Definição 10: Seleção Espacial
Seleção espacial
Seja uma região geográfica R, um conjunto de feições F e cujas geometrias geo(fi) ε R. Seja
ainda uma feição fr cujas geometria geo(f r) ε R. Dado um predicado espacial ξ computável, o
operador de seleção espacial ϕ : F x fr → F é tal que:
ϕ (F, fr) = {fr ε F | ξ( geo(f r), geo(fi))}.
ξ
O resultado desta operação é um subconjunto do conjunto original, composto de
todos as feições que satisfazem o predicado geométrico. Um exemplo dado em [Cam95]
(Figura 5.7), mostra o resultado de uma seleção espacial.
• Exemplo: “Selecione todas as regiões da França adjacentes à região de Midi-Pirenées
(que contém a cidade de Toulouse)”.
M
Figura 5.7 - Exemplo de operação de seleção espacial [Cam95]
Definição 11: Junção Espacial
Junção Espacial
Seja uma região geográfica R e dois conjuntos de feições F1 e F2. Dado um predicado
espacial ξ computável, a operação de junção espacial θ: F1 x F2 → F1 x F2 é tal que:
θ (F1,F2) = {(f1, f2) ε (F1, F2) | ξ (geo(f1), geo(f2) ) }.
ξ
123
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
O termo junção espacial é empregado por analogia à operação de junção em banco de
dados convencionais e denota o conjunto de operações onde ocorre a comparação entre dois
conjuntos de objetos, baseado num predicado espacial computado sobre suas representações.
Exemplos:
• “Para cada estrada de Pernambuco, ache as reservas indígenas a menos de 5 km de
uma estrada”.
• “Para as cidades do sertão potiguar, ache quais estão a menos de 10 km de algum
açude com capacidade de mais de 50.000 m3 de água”.
O resultado é uma coleção de objetos e valores, que satisfazem a restrição espacial. No
primeiro exemplo, a resposta é um conjunto de pares (reserva, estrada) no segundo um
conjunto de pares (cidade, açude).
5.5.1.2 Geometrias dos Objetos Pictóricos
De acordo com as definições acima, as primitivas gráficas, que representam os objetos
pictóricos da linguagem, pertencem aos tipos geométricos: ponto, linha e polígono. Os
símbolos visuais básicos dos mesmos foram mostrados na Figura 5.4.
5.5.1.3 Relacionamentos, definidos pelo modelo 9IM, entre as Geometrias: Ponto, Linha e
Polígono.
Dadas as particularidades de cada geometria, verifica-se que nem todos os tipos de
relacionamentos espaciais são possíveis entre dois tipos geométricos quaisquer. De acordo
com esta observação definimos, apresentando as matrizes do modelo 9IM [EH91], os
relacionamentos que serão considerados na linguagem GeoVisualQL entre possíveis
combinações de duas geometrias. Como o relacionamento intersects, é, por definição, a
negação da disjunção, então, todos os exemplos a seguir que se diferenciam do
relacionamento disjoints também podem identificar o relacionamento intersects. Nas matrizes
a seguir, observa-se que, como o ponto não possui limites, a interseção entre o limite deste
tipo geométrico e qualquer parte de outra geometria é sempre vazia. Considera-se o
relacionamento within como sendo o uso conjunto dos relacionamentos Inside e Covers
definidos no modelo 9IM. O relacionamento contains não está demonstrado pois é
equivalente ao within, apenas com a ordem de seus operandos invertida.
124
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
a) Ponto X Ponto: Dadas duas geometrias do tipo ponto, as possíveis relações espaciais
entre as mesmas, são apenas duas: Disjoints e Equals, como mostra a Figura 5.8.
A
B
AB
“Disjoints”
B° ∂B B A° ∅ ∅ ¬∅
A ∩B= ∂A ∅ ∅ ∅
A- ¬∅ ∅ ¬∅
“Equals”
B° ∂B B A° ¬∅ ∅ ∅
A ∩B=∂A ∅ ∅ ∅
A- ∅ ∅¬∅
Figura 5.8 – Relacionamentos Possíveis entre dois Pontos
b) Ponto X Linha: Dados dois elementos geométricos dos tipos ponto e linha, os
possíveis relacionamentos espaciais entre os mesmos, como mostra a Figura 5.9, são
os seguintes: Disjoints, Within e Touches.
A
A
A
B
B
¨Disjoints¨
B° ∂B B-
A° ∅ ∅ ¬∅
A ∩B= ∂A ∅ ∅ ∅
A- ¬∅¬∅¬∅
B
¨Within¨
¨Touches¨
B° ∂B B-
B° ∂B B-
A° ¬∅ ∅
∅
∅ ∅ ∅
A- ¬∅¬∅¬∅
A ∩B= ∂A
A° ∅¬∅ ∅
A ∩B= ∂A ∅ ∅ ∅
A- ¬∅¬∅¬∅
Figura 5.9 – Relacionamentos Possíveis entre um Ponto e uma Linha
c) Ponto X Região: Dados dois elementos geométricos dos tipos ponto e região, os
relacionamentos espaciais possíveis entre os mesmos, de acordo com a Figura 5.10,
são os seguintes: Disjoints, Touches e Within.
125
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
A
A
A
B
¨Disjoints¨
B
B
¨Within¨
B° ∂B B-
A° ∅ ∅¬∅
A ∩B=∂A ∅ ∅ ∅
A- ¬∅¬∅¬∅
¨Touches¨
B° ∂B BA°¬∅ ∅ ∅
A ∩B=∂A ∅ ∅ ∅
A- ¬∅¬∅¬∅
B° ∂B B-
A° ∅ ¬∅ ∅
A ∩B=∂A ∅ ∅ ∅
A- ¬∅¬∅¬∅
Figura 5.10 – Relacionamentos Possíveis entre um Ponto e uma Região.
d) Linha X Linha: Dados dois objetos geométricos do tipo linha, os relacionamentos
espaciais entre os mesmos, como mostra a Figura 5.11, são os seguintes: Equals,
Disjoints, Crosses, Touches, Overlaps e Within.
B
A
A
“Disjoints”
“Crosses”
B° ∂B BA°
A∩B= ∂A
A-
A
B
B° ∂B BA° ¬∅ ∅ ¬∅
A∩B= ∂A ∅ ∅ ¬∅
A- ¬∅ ¬∅¬∅
∅ ∅ ¬∅
∅ ∅ ¬∅
¬∅ ¬∅¬∅
B
A
B
“Touches (a)”
“Touches (b)”
B° ∂B BA° ∅ ∅ ¬∅
A∩B=∂A ∅ ¬∅ ¬∅
A- ¬∅ ¬∅¬∅
∅ ¬∅ ¬∅
∅ ∅ ¬∅
B° ∂B B-
¬∅ ¬∅¬∅
B
A
B
“Equals”
B° ∂B B-
A° ¬∅ ∅ ∅
A∩B= ∂A ∅ ¬∅ ∅
A- ∅ ∅¬∅
A
B
“Within”
B° ∂B B -
A° ¬∅ ∅ ∅
A∩B= ∂A ¬∅ ∅ ∅
A- ¬∅ ¬∅¬∅
A
“Overlaps”
B° ∂B B-
¬∅ ¬∅ ¬∅
A°
A∩B=∂A ¬∅ ∅ ¬∅
A- ¬∅ ¬∅¬∅
Figura 5.11 – Relacionamentos entre duas Linhas
126
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
e) Linha X Região: Dados dois elementos geométricos de tipos linha e região
consideram-se os seguintes relacionamentos espaciais, como mostra a Figura 5.12:
Disjoints, Crosses, Within e Touches.
A
“Disjoints”
“Within (a)”
B° ∂B B-
A°
A∩B=∂A
B
“Within (b)”
B° ∂B B-
A
A
A
B
“Touches (b)”
“Touches (a)”
B° ∂B B-
B° ∂B B-
∅ ∅ ¬∅
A° ¬∅ ∅ ∅ ¬∅ ∅ ∅
A°
∅ ∅ ¬∅ A∩B= ∂A ¬∅ ∅ ∅ ¬∅ ¬∅ ∅ A∩B= ∂A
A- ¬∅ ¬∅¬∅
A
B
A B
B
A- ¬∅ ¬∅¬∅ ¬∅ ¬∅¬∅
B° ∂B B-
∅ ∅ ¬∅
∅¬∅ ¬∅
A° ∅ ¬∅ ¬∅
A∩B= ∂A ∅ ∅ ¬∅
A- ¬∅ ¬∅¬∅
A- ¬∅ ¬∅¬∅
B
“Crosses (a)”
“Crosses (b)”
B° ∂B B -
B° ∂B B-
“Crosses (c)”
B° ∂B B-
A° ¬∅ ¬∅¬∅ A° ¬ Ø Ø Ø A° ¬ Ø ¬Ø Ø
A∩B= ∂A ∅ ∅ ¬∅ ∂A Ø ¬Ø Ø ∂A Ø ¬Ø Ø
A- ¬∅ ¬∅¬∅ A- ¬ Ø ¬Ø ¬Ø A- ¬ Ø ¬Ø ¬Ø
“Crosses (d)”
B° ∂B B-
A° ¬ Ø ¬Ø ¬ Ø
∂A Ø ¬Ø Ø
A- ¬ Ø ¬Ø ¬Ø
“Crosses (e)”
B° ∂B BA° ¬ Ø ¬Ø ¬ Ø
∂A Ø ¬Ø ¬ Ø
A- ¬ Ø ¬Ø ¬Ø
Figura 5.12 – Relacionamentos Espaciais possíveis entre uma Linha e uma Região
f) Região X Região: Dados dois objetos geométricos do tipo Região, considera-se os
seguintes relacionamentos entre os mesmos, como mostra a Figura 5.13: Disjoints,
Touches, Within/Contains, Overlaps, e Equals.
A
B
B
“Disjoints”
B
A
“Within (a)”
B° ∂B BA° ∅ ∅ ¬∅
A∩B= ∂A ∅ ∅ ¬∅
A- ¬∅ ¬∅¬∅
A
A
B
“Within (b)”
B° ∂B BB° ∂B BA° ¬∅ ∅ ∅ ¬∅ ∅ ∅
A∩B= ∂A ¬∅ ∅ ∅ ¬∅ ¬∅ ∅
A- ¬∅ ¬∅¬∅ ¬∅ ¬∅¬∅
A
B
“Touches”
(a)
B° ∂B
B-
A° ∅ ∅ ¬∅
A∩B= ∂A ∅¬∅ ¬∅
A- ¬∅ ¬∅¬∅
A
B
“Equals”
B° ∂B BA° ¬∅ ∅ ∅
A∩B=∂A ∅¬∅ ∅
A- ∅ ∅¬∅
A
B
“Touches”
(b)
“Overlaps”
B° ∂B
A° ∅ ∅ ¬∅
A∩B=∂A ∅¬∅ ¬∅
A- ¬∅ ¬∅¬∅
B° ∂B BA° ¬∅¬∅ ¬∅
A∩B= ∂A ¬∅¬∅ ¬∅
A- ¬∅ ¬∅¬∅
B-
Figura 5.13 – Relacionamentos Espaciais possíveis entre duas Regiões.
127
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
5.5.2 Relacionamentos Espaciais da Linguagem GeoVisualQL
Definiremos a seguir os relacionamentos espaciais e os operadores que serão usados em
GeoVisualQL, com as suas respectivas restrições. Como vimos na seção anterior, alguns
relacionamentos não podem ser usados por certos tipos de geometrias, devido à própria
natureza das mesmas e do relacionamento.
Alguns operadores foram adicionados à linguagem GeoVisualQL de modo a facilitar a
edição das consultas visuais. A metodologia utilizada na elaboração de consultas na nossa
linguagem é sempre a do uso de operadores espaciais agrupados aos símbolos visuais dos
objetos pictóricos. Mas, para a realização de consultas mais complexas, onde vários
operadores estão relacionados e onde exista a necessidade de utilização de operadores
lógicos, faz-se necessário o uso dos operadores adicionais como ilustrado na Figura 5.14(a).
Para agrupar elementos, utilizaremos o operador de edição adicional que representa a
ação de agrupamento Grouped como mostra a Figura 5.14(b). Este operador de agrupamento
também pode ser utilizado para associar os operadores lógicos aos símbolos visuais.
Normalmente ele é substituído, na linguagem textual, pelo uso dos parênteses.
Operador AND: ∧
Operador OR:
∨
Operador NOT: ¬
(a) Representação dos Operadores Lógicos
(b) Representação do Operador de Edição
Grouped
Figura 5.14 – Representação Visual dos operadores Adicionais da GeoVisualQL
Em cada um dos operadores a serem apresentados a seguir, mostramos sua definição
formal pelo modelo 9IM [EH91] (apresentado no Capítulo 4), seu símbolo visual e sua
definição gramatical. Em seguida, são apresentados exemplos de possíveis consultas válidas,
utilizando cada um desses operadores, em GeoVisualQL. Cada uma dessas sentenças ao ser
identificada como válida, será depois traduzida para a linguagem base. É importante lembrar
que todas as consultas em GeoVisualQL são compostas por símbolos visuais que representam
os objetos pictóricos e os operadores espaciais. A consulta só é semanticamente analisada
128
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
quando se encontra na sua forma textual traduzida, quando então é submetida ao BD
Geográfico.
Sabe-se que uma consulta, em GeoVisualQL, utiliza sempre objetos pictóricos como
operandos. Sabe-se, também, que um dos componentes do objeto pictórico, além da feição
geográfica que está sendo representada, é o tipo da geometria deste objeto.
O tipo da geometria do objeto pictórico é a informação mais importante para a
definição das consultas visuais na linguagem GeoVisualQL, pois, é com base neste tipo que se
identificam os possíveis relacionamentos entre as mesmas. Desta forma, para simplificar a
especificação das consultas em GeoVisualQL nos baseamos unicamente nas geometrias dos
objetos pictóricos. Para uma consulta ser determinada como válida, a mesma deve ser
formada por duas geometrias e um operador espacial, agrupados.
O tipo das geometrias relacionadas com os operadores depende da especificação de
sintaxe de cada operador espacial de acordo com a gramática de cada um deles. Uma consulta
visual está delimitada pelo operador grouped mais externo.
Vale lembrar que os relacionamentos Covers e CoveredBy do modelo 9IM tiveram suas
características incorporadas aos do relacionamento Inside, também do 9IM, gerando, na
definição da linguagem base, o relacionamento Within, como sugere o próprio autor do
modelo 9IM em [EH91]. O operador Crosses, da maneira como está definido a seguir,
considera apenas o caso do cruzamento entre duas linhas (Figura 5.11) e um caso de
cruzamento entre uma linha e uma região (Figura 5.12 (a)). Os demais casos do Crosses entre
uma linha e uma região são definidos, na linguagem GeoVisualQL, separadamente, com
nomes diferentes, como operadores adicionais à linguagem, como pode-se ver a seguir.
5.5.2.1 Relacionamentos Espaciais Visuais de Topologia baseados na SQL do OGC
A seguir apresenta-se os relacionamentos espaciais de topologia da linguagem GeoVisualQL,
com suas respectivas restrições.
129
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
a) Equals: Operador Igual
Formalismo 9IM
A.equals.B ⇔ (A° ∩ B° = ¬∅) ∧ ((∂A ∩ ∂B =¬∅ ) ∨
(∂A ∩ ∂B =∅ )) ∧ (A-∩ B -=¬∅) ∧ (A°∩ ∂B =
A°∩ B -= ∂A ∩ B° = ∂A ∩ B- = A- ∩ ∂B = A- ∩ B -= ∅)
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta de igualdade em GeoVisualQL está definida se existir
um agrupamento de duas geometrias, do mesmo tipo, com o operador equals, como
mostra a definição abaixo:
EQUALS-CLAUSE→ grouped(GEOMETRY1,Equals, GEOMETRY2)
Where
(GEOMETRY1.type = GEOMETRY2.type)
O analisador sintático GeoVisualQL verifica se os tipos das geometrias utilizadas são
iguais de modo a validar e submeter a consulta. As representações pictóricas de possíveis
consultas válidas para o operador equals estão ilustradas na Figura 5.15.
Figura 5.15 – Exemplos de consultas válidas usando o operador equals
130
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
b) Disjoint: Operador Disjunto
Formalismo 9IM
A.disjoints.B ⇔ ( A° ∩ B° = ∅) ∧ (A° ∩ ∂B =∅ ) ∧
(∂A ∩ B° =∅)∧ (∂A ∩ ∂B = ∅) ∧ (A- ∩ B - =¬∅) ∧ (A∩ B° =¬∅) ∧ ((A- ∩ ∂B) =¬∅) ∨ (A- ∩ ∂B) =∅)) ∧ (A°
∩ B - =¬∅) ∧ ((∂A ∩ B - =¬∅)∨ (∂A ∩ B - =∅))
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta de disjunção está definida em GeoVisualQL se existir
um agrupamento de duas geometrias de qualquer tipo, com o operador disjoint, dentro de
uma consulta visual, como define a descrição abaixo, e ilustra a Figura 5.16:
DISJOINT–CLAUSE→ grouped(GEOMETRY1,Disjoint, GEOMETRY2)
O operador DISJOINT pode ser usado comparando-se quaisquer dois tipos geométricos
conhecidos, por isso, não apresenta restrições em sua definição.
Figura 5.16 – Representação de consultas válidas com o operador disjoint
131
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
c) Touches: Operador Toca.
Formalismo 9IM
A.touches.B ⇔ (A° ∩ B° = ∅) ∧ ((∂A ∩ B° =¬∅) ∨
(A° ∩ ∂B =¬∅ ) ∨(∂A ∩ ∂B =¬∅)) ∧ (A- ∩ B-= ¬∅) ∧
(A- ∩ B°=¬∅) ∧ (A- ∩ ∂B =¬∅) ∧ ((A° ∩ B-= ¬∅) ∧
(∂A ∩ B-= ¬∅)) ∨ ((A° ∩ B-= ∅) ∧
(∂A ∩ B-= ∅))
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta toca está definida em GeoVisualQL se o operador
espacial touches for agrupado junto com duas geometrias segundo a especificação abaixo e
ilustrada na Figura 5.17:
TOUCHES -CLAUSE→ grouped(GEOMETRY1,Touches, GEOMETRY2)
Where
(GEOMETRY1.type=point and GEOMETRY2.type = line) or
(GEOMETRY1.type=point and GEOMETRY2.type=polygon) or
(GEOMETRY1.type=line and GEOMETRY2.type = line) or
(GEOMETRY1.type= line and GEOMETRY2.type = polygon) or
(GEOMETRY1.type=polygon and GEOMETRY2.type=polygon)
O operador espacial touches está definido para quaisquer dois tipos geométricos, exceto o caso
de dois pontos.
Figura 5.17 – Representação de consultas válidas usando o operador touches
132
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
d) Within: Operador Dentro de
Formalismo 9IM
A.within.B ⇔ ( A° ∩ B° = ¬∅) ∧ (A° ∩ ∂B =∅ ) ∧
(A° ∩ B - =∅) ∧ (∂A∩ B - =∅) ∧ ((∂A ∩ ∂B =∅) ∨
(∂A∩ ∂B=¬∅))∧ ((∂A∩ B°= ¬∅)∨ (∂A ∩ B°= ∅)) ∧
( A-∩ B°= ¬∅) ∧ (A- ∩ ∂B = ¬∅) ∧ (A- ∩ B - = ¬∅)
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta dentro_de em GeoVisualQL está definida se existir
um agrupamento de duas geometrias com o operador within, segundo a especificação
abaixo, como ilustrado na Figura 5.18:
WITHIN-CLAUSE→grouped(GEOMETRY1, Within, GEOMETRY2)
Where
(GEOMETRY1.type = point and GEOMETRY2.type = line) or
(GEOMETRY1.type=point and GEOMETRY2.type= polygon) or
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type= polygon) or
(GEOMETRY1.type=polygon and GEOMETRY2.type= polygon)
Pela restrição definida, operador Within só não se aplica no caso de dois pontos.
Figura 5.18 – Representação de consultas válidas usando o operador within
133
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
e) Overlaps: Operador Sobrepõe
Formalismo 9IM
A.overlaps.B ⇔ (A° ∩ B° = ¬∅) ∧ (A°∩ B -=¬∅ ) ∧
(A°∩∂B =¬∅) ∧(∂A ∩ B°=¬∅) ∧ (∂A ∩ B -=¬∅ ) ∧
((∂A ∩ ∂B =¬∅)∨ (∂A ∩ ∂B =∅)) ∧ (A -∩ B° =¬∅) ∧
(A- ∩ B -=¬∅) ∧(A- ∩ ∂B =¬∅)
Símbolo
Visual
Formalismo Gramatical
Definição: A definição de uma cláusula de consulta de sobreposição é definida se existir
um agrupamento de duas geometrias, segundo a especificação definida a seguir,
juntamente com o operador overlaps, como ilustrado na Figura 5.19:
OVERLAPS -CLAUSE→ grouped(GEOMETRY1,Overlaps,GEOMETRY2)
Where
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type=polygon and GEOMETRY2.type=polygon)
O analisador sintático de GeoVisualQL verifica se o operador overlaps está agrupado com
duas geometrias do tipo linha, ou duas geometrias do tipo região a fim de validar a
consulta.
Figura 5.19 – Representação de consultas válidas utilizando o operador overlaps
134
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
g) Crosses: Operador Cruza
Formalismo 9IM
A.crosses.B ⇔ (A° ∩ B° = ¬∅) ∧ ((A° ∩ ∂B =¬∅) ∨
(A° ∩ ∂B =∅)) ∧ (A° ∩ B - = ¬∅) ∧ (∂A ∩ B° = ∅) ∧
(∂A ∩ ∂B =∅) ∧ (∂A ∩ B-= ¬∅) ∧ (A-∩ B° = ¬∅) ∧ (A∩ ∂B =¬∅) ∧ (A-∩ B-= ¬∅)
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta visual de cruzamento em GeoVisualQL é definida se
existir um agrupamento de duas geometrias, segundo a especificação abaixo, com o
operador crosses e é ilustrada na Figura 5.20:
CROSSES-CLAUSE→grouped(GEOMETRY1,Crosses,GEOMETRY2)
Where
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type = polygon)
Neste caso, pela própria natureza do operador crosses, que diz respeito a um cruzamento,
o primeiro operador geométrico envolvido na consulta deverá ser do tipo linha, como prérequisito para a sua validação, e o segundo operando só poderá ser do tipo linha ou do tipo
região. Exemplos de possíveis consultas válidas utilizando o operador crosses estão
ilustrados na Figura 5.20.
Figura 5.20 – Representação de consultas válidas envolvendo o operador crosses.
135
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
g) Intersects: Operador Intersecta
Formalismo 9IM
A.intersects.B ⇔ (A° ∩ B°=¬∅) ∨ (A° ∩ ∂B =¬∅ ) ∨
(∂A ∩ B°=¬∅) ∨ (∂A ∩ ∂B =¬∅) ∧ (A- ∩ B -=¬∅) ∧
(A- ∩ B° =¬∅) ∧ (A-∩ ∂B =¬∅) ∧ (A°∩ B - =¬∅) ∧
(∂A∩ B - =¬∅)
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta visual de interseção em GeoVisualQL, é definida se
existir um agrupamento de duas geometrias com o operador espacial intersects,como
definido abaixo e ilustrado na Figura 5.21:
INTERSECTS-CLAUSE→ grouped (GEOMETRY1, Intersects,GEOMETRY2)
Nenhuma restrição é adicionada à relação intersects, pois como a mesma é somente a
negação da relação disjoints, ela também pode ser usada com qualquer tipo de objeto
geométrico.
Figura 5.21 – Representação de consultas válidas que usam o operador espacial intersects
136
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
g) Contains: Operador Contém
Formalismo 9IM
A.contains.B ⇔ ( A° ∩ B° = ¬∅) ∧ (∂A∩ B° =∅ ) ∧
(A - ∩ B° =∅) ∧ (A -∩ ∂B =∅) ∧ ((∂A ∩ ∂B =∅) ∨ (∂A
∩ ∂B =¬∅)) ∧ ((A° ∩ ∂B =¬∅) ∨ (A° ∩ ∂B =∅)) ∧
-
Símbolo
Visual
-
(A°∩ B = ¬∅) ∧ (∂A ∩ B = ¬∅) ∧ (A- ∩ B - = ¬∅)
Formalismo Gramatical
Definição: Uma cláusula de consulta visual que utiliza o operador contém, em
GeoVisualQL, é definida se existir um agrupamento de duas geometrias, como definido
abaixo, com o operador contains:
CONTAINS-CLAUSE→ grouped(GEOMETRY1,Contains, GEOMETRY2)
Where
(GEOMETRY1.type = point and GEOMETRY2.type = line) or
(GEOMETRY1.type=point and GEOMETRY2.type= polygon) or
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type= polygon) or
(GEOMETRY1.type = polygon and GEOMETRY2.type = polygon)
O operador contains é, funcionalmente igual ao operador within, com a ordem de seus
operandos invertida. O uso deste operador está ilustrado na Figura 5.22.
Figura 5.22 – Representação de consultas válidas que utilizam o operador contains
137
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
5.5.2.2 Acrescentando novos Operadores Espaciais de Topologia
Ao analisar o cruzamento entre uma linha e uma região foi verificado que o operador Crosses
merece ser detalhado de modo a demonstrar, na linguagem, as suas variações topológicas, de
acordo com o modelo 9IM proposto por Egenhofer [Ege91]. Segundo a avaliação feita pelos
usuários em [ME94] o cruzamento simples entre uma linha e uma região está fracamente
representado por apenas um tipo de cruzamento. Desta forma, foram identificados alguns
tipos de cruzamentos que representam estas variações da realidade, como foi apresentado no
Capítulo 4.
Estes relacionamentos não são oferecidos na linguagem base, ou seja, pela especificação
SQL do OGC [OGC99b]. Apresentam-se, então, quatro possíveis extensões de cruzamento
entre uma linha e uma região.
a) Crothin: Representa o caso em que uma linha A cruza totalmente uma região B estando
totalmente dentro da mesma. Será definido a seguir abreviadamente como CroThin.
Formalismo 9IM
A.crothin.B ⇔ ( A° ∩ B° = ¬∅) ∧ ( A° ∩ ∂ B =∅ ) ∧ (
A° ∩ B -=∅ ) ∧ (∂A ∩ B° =∅) ∧ (∂A ∩ ∂B = ¬∅) ∧(∂A
∩ B - =∅) ∧ (A- ∩ B° = ¬∅) ∧ (A- ∩ ∂B =¬∅) ∧ (A∩ B - =¬∅)
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta visual válida em GeoVisualQL que utiliza o crothin,
está definida se existir um agrupamento de duas geometrias de tipo linha e região, com o
operador crothin, como definido abaixo e ilustrado na Figura 5.23:
CROTHIN-CLAUSE→grouped(GEOMETRY1,Crothin, GEOMETRY2)
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
A função do operador crothin pode ser representada pela situação de união entre o
operador crosses e o operador within.
138
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Figura 5.23 – Consulta visual válida que utiliza o operador crothin
b) Croches: Representa a situação em que uma linha A cruza totalmente uma região B,
está totalmente dentro da mesma e o interior de A toca nos limites de B. Está definido
a seguir como CroChes.
Formalismo 9IM
A.croches.B ⇔ (A°∩ B°= ¬∅) ∧ ( A° ∩ ∂ B =¬∅ ) ∧ (
A° ∩ B - =∅ ) ∧ (∂A ∩ B° = ∅) ∧ (∂A ∩ ∂B =¬∅) ∧
(∂A ∩ B - =∅) ∧(A- ∩ B°= ¬∅) ∧ (A- ∩ ∂B =¬∅) ∧ (A∩ B - =¬∅)
Símbolo
Visual
Formalismo Gramatical
Definição: Uma cláusula de consulta visual válida em GeoVisualQL que utiliza o croches,
está definida se existir um agrupamento de duas geometrias de tipo linha e região, com o
operador croches, como definido abaixo e ilustrado na Figura 5.24
CROCHES -CLAUSE→grouped(GEOMETRY1,Croches, GEOMETRY2)
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
A função do operador croches pode ser representada pela situação de união entre o
operador crosses e o operador touches.
139
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Figura 5.24 – Consulta visual válida que utiliza operador Croches.
c) Crossout: Representa a situação em que uma linha A cruza uma região B e um dos
limites de A se encontra no exterior de B. Será referenciado como operador crossout.
Formalismo 9IM
Símbolo
Visual
A.crossout.B ⇔ (A° ∩ B°= ¬∅) ∧ ( A°∩ ∂ B =¬∅ ) ∧ (
A° ∩ B -=¬∅ ) ∧ (∂A ∩ B° = ∅) ∧ (∂A ∩ ∂B =¬∅ ) ∧
(∂A ∩ B -=¬∅ )∧ (A-∩ B°=¬∅) ∧ (A-∩ ∂B =¬∅) ∧
(A- ∩ B - =¬∅)
Formalismo Gramatical
Definição: Uma cláusula de consulta visual válida em GeoVisualQL que utiliza o crossout,
está definida se existir um agrupamento de duas geometrias de tipo linha e região, com o
operador crossout, como definido abaixo:
CROSSOUT-CLAUSE →grouped (GEOMETRY1, Crossout, GEOMETRY2)
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
Este operador se mostrou necessário para representar a situação em que uma linha tem
início dentro de uma região e termina fora da mesma. Está ilustrado na Figura 5.25.
Figura 5.25 – Consulta visual válida que utiliza o operador crossout
140
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
d) Crossects: Representa a situação em que uma linha A cruza uma região B, onde, ambos os
limites de A se encontram dentro de B, mas, parte de seu interior se encontra externo a B.
Será referenciado a seguir como Crossects.
Formalismo 9IM
Símbolo
Visual
A.crossects.B ⇔ (A°∩ B° =¬∅) ∧ ( A° ∩ ∂ B =¬∅ ) ∧
(A°∩ B -=¬∅ ) ∧ (∂A ∩ B°=∅) ∧ (∂A ∩ ∂B =¬∅ ) ∧
(∂A ∩ B -=∅ ) ∧(A- ∩ B°= ¬∅) ∧ (A- ∩ ∂B = ¬∅) ∧ (A∩ B - =¬∅)
Formalismo Gramatical
Definição: Uma cláusula de consulta visual válida em GeoVisualQL que utiliza o
crossects, está definida se existir um agrupamento de duas geometrias de tipo linha e
região, com o operador crossects, como definido abaixo:
CROSSECTS-CLAUSE→grouped (GEOMETRY1, Crossects, GEOMETRY2)
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
O uso deste operador está ilustrado na Figura 5.26.
Figura 5.26 – Consulta visual válida que utiliza o operador crossects
5.5.2.3 Relacionamentos Espaciais Visuais de Conjuntos baseados na SQL do OGC
Os operadores de conjuntos, definidos pela linguagem base, têm como característica retornar
uma geometria como resultado.
Como não são operadores de natureza topológica, não
estão descritos pelo modelo 9IM [EH91]. Na especificação OGC [OGC99b] não é
141
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
apresentada uma formalização para estes operadores. Apresenta-se então uma formalização
para estes operadores.
Sabe-se que as geometrias manipuladas pela linguagem GeoVisualQL são: ponto P,
linha L e região R. Então, considerando cada uma das possíveis combinações entre duas
geometrias em um espaço bi-dimensional IR2 , utilizam-se algumas notações adicionais. Há
casos em que o retorno do operador de conjunto entre as geometrias A e B é uma geometria
diferente de A e diferente de B. Neste caso, interessa apenas o tipo desta geometria
retornada, que pode ser representada como G(P) para uma geometria do tipo ponto, G(L)
para uma geometria do tipo linha, e G(R) para uma geometria do tipo região. Além disso, em
alguns casos, faz-se nece ssário acrescentar outra notação, G(Rh), que identifica uma
geometria do tipo região com um “buraco” (hole), como também G(mL), para uma geometria
do tipo MultiLinha, ou G(mR) para uma geometria do tipo MultiPolígono. As definições que
se seguem considera apenas regiões convexas. A seguir definem-se os operadores de
conjuntos oferecidos pela GeoVisualQL.
a) Intersection
O operador intersection retorna a geometria resultante da interseção entre duas
geometrias quaisquer. O símbolo visual que o representa na linguagem GeoVisualQL e
sua definição, para cada conjunto de combinações possíveis entre geometrias está
definido a seguir:
Símbolo
Visual
i.
A ponto e B ponto
A.intersection.B = B.intersection.A ⇒ A ∨ B ∨ ∅
Prova: Se A ∈ P e B ∈ P, então, A ∩ B = A = B.
•
Se A intersecta B implica dizer que A é igual a B, pois, como uma
geometria do tipo Ponto possui uma única célula, esta é a única
142
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
possibilidade de interseção entre duas geometrias deste mesmo tipo.
Desta forma, a geometria retornada é o ponto A ou B;
•
Se as duas geometrias do tipo ponto A e B forem disjuntas, a interseção
entre os mesmos retorna o conjunto vazio.
ii.
A ponto e B linha
A.intersection.B = B.intersection.A ⇒ A ∨ ∅
Prova: Se A ∈ P e B ∈ L, então A ∩ B = A.
•
Se A do tipo P intersecta B do tipo L, implica dizer que A está dentro de
B ou que A toca em B. Nestes dois casos, o resultado da interseção é o
próprio A;
•
Se A e B forem disjuntos, o resultado da interseção entre os dois é o
conjunto vazio.
iii.
A ponto e B região
A.intersection.B = B.intersection.A ⇒ A ∨ ∅
Prova: Se A ∈ P e B ∈ R, então A ∩ B = A.
•
Se A do tipo P, intersecta B do tipo R, o resultado desta interseção é o
próprio A, como pode ser verificado nos casos em que A está dentro de
B ou que A toca em B;
•
No caso de A e B serem disjuntos, o resultado da interseção entre os
dois é o conjunto vazio.
iv.
A linha e B linha
A.intersection.B = B.intersection.A ⇒ G(P) ∨ G(L) ∨ A ∨ B ∨ ∅
Prova: Se A ∈ L e B ∈ L, então:
•
O retorno da interseção entre duas linhas A e B pode ser um ponto
G(P), nos casos em que A e B se cruzam ou no caso em que se tocam;
•
O retorno da interseção é um segmento de linha G(L), no caso em que
A se sobrepõe a B;
143
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
O retorno da interseção pode ser a própria linha A, no caso de A estar
dentro de B, ou se B contém A.
•
E se B estiver dentro de A, ou se A contém B, este retorno é a própria
linha B;
•
O retorno da interseção pode ser a linha A ou a linha B, no caso de
serem iguais;
•
O retorno pode ser simplesmente o conjunto vazio no caso de A e B
serem disjuntos.
v.
A linha e B região
A.intersection.B = B. intersection.A ⇒ G(P) ∨ G(L) ∨ A ∨ ∅
Prova: Se A ∈ L e B ∈ R, então:
•
A interseção entre linha A e a região B retorna um ponto G(P), no
caso em que A toca em B em um ponto;
•
A intersecção entre A e B retorna um segmento de reta G(L), no caso
em que A toca em um lado de B, ou no caso em que A cruza B, ou em
que A entra/sai em/de B;
•
A interseção entre A e B pode ser a própria linha A, no caso de A estar
dentro de B;
•
A interseção entre A e B pode retornar simplesmente o conjunto vazio
no caso de A e B serem disjuntos.
vi.
A região e B região
A.intersection.B = B.intersection.A ⇒ G(P) ∨ G(L) ∨ G(R) ∨ A ∨ B ∨ ∅
Prova: Se A ∈ R e B ∈ R, então:
•
O retorno da interseção entre A e B pode ser um ponto G(P), no caso
em que as regiões de tocam em um único ponto;
•
O retorno pode ser um segmento de reta G(L), no caso em que A e B
se tocam em um lado;
144
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
O retorno da interseção entre A e B pode ser uma região G(R), se A se
sobrepõe a B;
•
O retorno da interseção entre A e B pode ser a própria região A, se A
estiver dentro de B;
•
A interseção entre A e B pode retornar a região A ou a região B no caso
de serem iguais;
•
A interseção entre A e B pode retornar simplesmente o conjunto vazio
no caso de A e B serem disjuntos.
Formalismo Gramatical
Definição: Uma consulta que utiliza o operador de interseção é definida se existir um
agrupamento de duas geometrias com o operador intersection, como definido abaixo e
ilustrado na Figura 5.27:
INTERSECTION-CLAUSE→grouped(GEOMETRY1,Intersection, GEOMETRY2)
O operador intersection é definido para quaisquer tipos de geometrias.
Figura 5.27 – Representação de consultas visuais que utilizam o operador Intersection
145
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
b) Difference
O operador difference retorna como resultado a geometria da diferença entre duas outras
geometrias. O símbolo visual que o representa na linguagem GeoVisualQL e sua
definição, para cada conjunto de combinações possíveis entre geometrias estão definidos
a seguir.
Símbolo
Visual
i.
A ponto e B ponto
A.difference.B ⇒ ∅ ∨ A
Prova: Se A ∈ P e B ∈ P, então:
•
Se A intersecta B implica dizer que A é igual a B, então, A – B = ∅ ;
•
Se A e B forem disjuntos, a diferença entre A e B retorna o próprio
ponto A.
B.difference.A ⇒ ∅ ∨ B
Prova: Se A ∈ P e B ∈ P, então:
•
Se A intersecta B implica dizer que A é igual a B, então, B – A = ∅ ;
•
Se A e B forem disjuntos, a diferença entre B e A retorna o próprio
ponto B.
ii.
A ponto e B linha
A.difference.B ⇒ A ∨ ∅
Prova: Se A ∈ P e B ∈ L, então:
•
Se A intersecta B, como no caso em que A está dentro de B, ou A toca
em B, a diferença A – B = ∅ ;
146
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
Se A e B forem disjuntos entre si, A – B = A, ou seja, retorna o
próprio ponto A.
B.difference.A ⇒ (G(L1)∧ G(L2)) ∨ G(L) ∨ B
Prova: Se A ∈ P e B ∈ L, então:
•
Se A está dentro de B, o retorno da diferença entre B e A é a linha B
menos exatamente o ponto A, gerando, por conseqüência, dois
segmentos de linha;
•
Se A toca B, então o retorno de B – A, é igual a B menos um de seus
limites, gerando um novo segmento de linha;
•
E no caso de A e B serem disjuntos entre si, B – A = B, ou seja, retorna
a própria linha B.
iii.
A ponto e B região
A.difference.B ⇒ A ∨ ∅
Prova: Se A ∈ P e B ∈ R, então:
•
Se A intersecta B, temos casos em que A está dentro de B ou em que A
toca em B, então a diferença A – B = ∅ ;
•
Se A e B forem disjuntos entre si, A – B = A, ou seja, retorna o
próprio ponto A.
B.difference.A ⇒ G(Rh) ∨ G(R) ∨ B
Prova: Se A ∈ P e B ∈ R, então:
•
Se A está dentro de B, então a diferença entre B e A é uma geometria
com menos um ponto interno, gerando na verdade, uma região com
um ¨buraco¨;
•
Se, o ponto A tocar na região B, o resultado da diferença B – A é uma
nova região;
•
Se A e B forem disjuntos entre si, B – A = B, ou seja, retorna a
própria região B.
147
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
iv.
A linha e B linha
A.difference.B ⇒ A ∨ ( G(L1) ∧ G(L2) ) ∨ G(L) ∨ ∅
Prova: Se A ∈ L e B ∈ L, então:
•
Se A e B forem disjuntos, o retorno da diferença entre as duas é a
própria linha A, ou seja, A – B = A;
•
No caso de cruzamento entre as duas linhas a diferença entre A e B é
igual a linha A menos o ponto de interseção, gerando dois segmentos
de linha (L1 e L2);
•
No caso da linha A tocar a linha B, ou se a linha A se sobrepõe à
linha B, o retorno da diferença entre A e B é um novo segmento de
linha;
•
Se as linhas A e B forem iguais, ou se A estiver dentro de B, então, A –
B = ∅;
•
Se A contém B, então a diferença entre A e B vai ser um ou dois
segmento(s) de linha(s).
B.difference.A ⇒ B ∨ ( G(L1) ∧ G(L2)) ∨ G(L) ∨ ∅
Prova: Se A ∈ L e B ∈ L, então:
•
Se as linhas A e B forem disjuntas, o retorno da diferença entre as duas
é a própria linha B, ou seja, B – A = B;
•
No caso de cruzamento entre as duas linhas, a diferença entre B e A é
igual a B menos o ponto de interseção, gerando dois segmentos de
linha;
•
No caso da linha A tocar a linha B, ou no caso em que as duas linhas
se sobrepõem o retorno da diferença entre B e A, é um novo segmento
de linha;
•
Se as duas linhas forem iguais, então B – A = ∅;
148
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
Se a linha A estiver dentro da linha B, então, a diferença entre B e A
vai ser um ou dois segmento(s) de linha(s) ;
•
Se a linha A contém a linha B, a diferença entre B e A é o conjunto
vazio.
v.
A linha e B região
A.difference.B ⇒ A ∨ ∅ ∨ ( G(L1) ∧ G(L2)) ∨ G(L)
Prova: Se A ∈ L e B ∈ R, então:
•
Se A e B forem disjuntos entre si, a diferença entre A e B é igual à linha
A;
•
Se A está dentro de B, então, A menos B, vai ser igual ao conjunto
vazio;
•
Se a linha A cruza a região B, a diferença entre A e B é igual a dois
segmentos de linha;
•
Se a linha A toca em um lado de B, a diferença entre A e B é igual a um
ou dois segmento(s) de linha(s).
•
Se A toca em um ponto de B, ou se A entra/sai da região B, então a
diferença entre A e B é igual a um novo segmento de linha.
B.difference.A ⇒ B ∨ G(Rh) ∨ (G(R1) ∧ G(R2)) ∨ G(R)
Prova: Se A ∈ L e B ∈ R, então:
•
Se A e B forem disjuntos, então, B menos A, é igual à própria região B;
•
Se A está dentro de B, então a diferença entre B e A é a região B menos
os pontos referentes à linha A, ou seja, é uma região com um
¨buraco¨;
•
Se A entra/sai em/de B, o resultado da diferença entre B e A é uma
nova região.
•
Se a linha A cruza a região B, então a diferença entre B e A, são duas
regiões;
149
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
E se A toca em B, a diferença entre B e A, nos dois casos em que a
linha A toca em apenas um ponto, ou toca em um lado de B, o
resultado é uma nova região.
vi.
A região e B região
A.difference.B ⇒ A ∨ ∅ ∨ G(R) ∨ G(Rh)
Prova: Se A ∈ R e B ∈ R, então:
•
Se A e B forem disjuntos, A – B = A;
•
Se A está dentro de B, ou A igual a B, A – B = ∅;
•
Se A contém B, então a diferença entre A e B é uma região com um
buraco;
•
Se a região A toca na região B em um lado, ou se A toca em B em um
ponto, ou se A se sobrepõe a B, o resultado da diferença entre A e B é
igual a uma nova região.
B.difference.A ⇒ B ∨ G(Rh) ∨ ∅ ∨ G(R)
Prova: Se A ∈ R e B ∈ R, então:
•
Se A e B são disjuntos entre si então B – A = B;
•
Se A está dentro de B, então a diferença entre B e A é uma região
com um ¨buraco¨;
•
Se A contém B, então a diferença entre B e A é o conjunto vazio;
•
Se A e B forem iguais, então B – A = ∅ ;
•
Se A toca em B por um lado, ou se A toca em B por um ponto, ou se
A se sobrepõe a B, então a diferença entre B e A é uma nova região.
Formalismo Gramatical
Definição: Uma consulta que utiliza o operador Difference é representada pelo
agrupamento de duas geometrias com o operador, como definido abaixo, e ilustrado na
Figura 5.28:
150
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
DIFFERENCE-CLAUSE→ grouped(GEOMETRY1,Difference, GEOMETRY2)
O retorno desta operação é a conjunto de pontos topologicamente fechados resultante da
diferença entre a primeira e a segunda geometria.
Figura 5.28 – Representação de co nsultas visuais que utilizam o operador difference
c) Union
O operador union retorna a geometria resultante da união entre as duas geometrias A e
B. O símbolo visual que o representa na linguagem GeoVisualQL e sua definição, para
cada conjunto de combinações possíveis entre geometrias estão definidos a seguir:
Símbolo
Visual
i.
A ponto e B ponto
A.union.B = B.union.A ⇒ (A ∧ B) ∨ A ∨ B
Prova: Se A ∈ P e B ∈ P, então:
151
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
Se A e B são disjuntos, a união dos dois consiste do conjunto formado
pelos dois pontos.
•
ii.
Se A e B são iguais então a união dos dois é o ponto A ou o ponto B.
A ponto e B linha
A.union.B = B.union.A ⇒ (A ∧ B) ∨ B
Prova: Se A ∈ P e B ∈ L, então:
•
Se A e B são disjuntos, a união dos mesmos consiste do conjunto
formado pelo ponto A e pela linha B;
•
Se A está dentro de B, ou se A toca B, o resultado da união dos dois é a
própria linha B.
iii.
A ponto e B região
A.union.B = B.union.A ⇒ (A ∧ B) ∨ B
Prova: Se A ∈ P e B ∈ R, então:
•
se A e B forem disjuntos, então a união dos dois será o conjunto
formado pelo ponto A e pela região B.
•
Se A está dentro de B, ou se A toca B, então o resultado da união dos
dois é a própria região B.
iv.
A linha e B linha
A.union.B = B.union.A ⇒ (A ∧ B) ∨ G(mL) ∨ A ∨ B ∨ G(L)
Prova: Se A ∈ L e B ∈ L, então:
•
Se A e B são disjuntos, a união dos dois é o conjunto formado pelas
duas linhas A e B.
•
Se A e B se cruzam, ou se tocam entre si, o resultado da união dos dois
é uma multilinha formada pela união de todos os pontos de A e B.
•
Se A e B são iguais, o resultado da união dos dois é a linha A ou a
linha B.
152
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
Se A está dentro de B o resultado da união é a linha B;
•
Se A contém B o resultado da união entre A e B é a linha A;
•
Se A e B se sobrepõem , então o resultado da união das duas é uma
nova linha.
v.
A linha e B região
A.union.B = B. union.A ⇒ (A ∧ B) ∨ B ∨ (B ∧ 2 G(L))
Prova: Se A ∈ L e B ∈ R, então:
•
Se A e B são disjuntos, então a união entre os dois é o conjunto
formado pelas duas geometrias desconectas linha e região;
•
Se A está dentro de B, o resultado da união entre A e B é a região B;
•
Se A contém B, o resultado da união é a região A;
•
Se A cruza B, o resultado da união entre os dois, é a região B junto
com os dois segmentos de linhas restantes de A.
•
Se A toca em B, em um ponto, ou em um lado, ou se A entra/sai na
região B, o resultado desta união, é o conjunto formado pelas duas
geometrias conectadas A e B.
vi.
A região e B região
A.union.B = B.union.A ⇒ (A ∧ B) ∨ A ∨ B ∨ G(R) ∨ G(mR)
Prova: Se A ∈ R e B ∈ R, então:
•
Se A e B são disjuntos, a união dos dois é formada pelo conjunto de
geometrias desconectas A e B.
•
Se A está dentro de B, o resultado da união é a região B;
•
Se A contém B, o resultado da união é a região A;
•
Se A e B são iguais, o resultado da união entre A e B, é a região A ou
a região B.
153
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
•
Se A e B se tocam em um lado, o resultado da união entre A e B é uma
nova região.
•
Se A e B se tocam por um único ponto, o resultado da união dos dois é
uma geometria do tipo multipolígono ;
•
Se A e B se sobrepõem, então o resultado da união entre os mesmos é
uma nova região.
Formalismo Gramatical
Definição: Uma consulta visual que utiliza o operador de união é identificada se existir um
agrupamento de duas geometrias com o operador union como definido abaixo e ilustrado
pela Figura 5.29:
UNION -CLAUSE → grouped (GEOMETRY1, Union, GEOMETRY2)
Este operador retorna como resultado a geometria correspondente à união das duas
geometrias envolvidas na consulta.
Figura 5.29 – Representação simbólica de possíveis consultas visuais que utilizam o
operador union
5.5.3 Gramática da linguagem GeoVisualQL
A gramática da linguagem GeoVisualQL [SS02] foi definida, no Apêndice B, utilizando-se a
Picture Layout Grammar [Gol91] que foi apresentada no Capítulo 3. Nesta definição da
154
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
gramática foram definidos os símbolos terminais e não terminais da linguagem e os formatos
das sentenças de consultas. Por exemplo, suponha que se deseja validar uma consulta que
utiliza o operador Within. Partindo do símbolo inicial da linguagem STATEMENT, segue-se
as sentenças da gramática até se alcançar a cláusula WITHIN_CLAUSE, tem-se:
STATEMENT
STATEMENT ⇒ QUERY_CLAUSE
QUERY_CLAUSE ⇒ WITHIN_CLAUSE
WITHIN-CLAUSE⇒ grouped (GEOMETRY1, Within, GEOMETRY2)
Where
(GEOMETRY1.type = point and GEOMETRY2.type = line) or
(GEOMETRY1.type = point and GEOMETRY2.type= polygon) or
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type = polygon) or
(GEOMETRY1.type= polygon and GEOMETRY2.type= polygon)
Substituindo cada símbolo terminal desta equação final por seus símbolos visuais
equivalentes obtêm-se exatamente as consultas válidas representadas na Figura 5.18.
Considere agora uma sentença de consulta mais complexa que utiliza o operador lógico Not.
Considere novamente o símbolo inicial da linguagem STATEMENT, como mostra a Figura
5.30, onde as derivações da gramática são utilizadas, a partir do símbolo inicial da linguagem,
até se alcançar a cláusula de consulta visual original.
155
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
STATEMENT
STATEMENT
⇒ QUERY_CLAUSE
QUERY_CLAUSE
⇒ LOGIC_CLAUSE
LOGIC_CLAUSE
⇒ NOT_CLAUSE
NOT_CLAUSE
Þ Not (QUERY_CLAUSE)
NOT_CLAUSE
Þ Not (LOGIC_CLAUSE)
Not (LOGIC_CLAUSE)
ÞNot (And_Clause)
Not (And_Clause)
ÞNot ((Query_clause) And (Query_clause))
Not ((Query_clause) And (Query_clause))
ÞNot ((crosses_clause) And (within_clause))
-- Crosses Clause -Þ Not ((grouped(GEOMETRY1.crosses.GEOMETRY2)
where
(GEOMETRY1.type=line and GEOMETRY2.type=line) or
(GEOMETRY1.type=line and GEOMETRY2.type=polygon))
-- and -AND
-- Within Clause -(grouped (GEOMETRY3.within.GEOMETRY4))
¬
∧
Figura 5.30 – Possível Consulta Visual equivalente à definição de uso do operador Not pela
Gramática da GeoVisualQL
No apêndice B, está descrito todo o formalismo gr amatical da linguagem GeoVisualQL.
Nele, pode-se observar como são as sentenças de consulta desta linguagem, os símbolos
terminais e não-terminais e o seu símbolo inicial. Os símbolos visuais dos operadores
espaciais mostrados na seção 5.5.2 complementam a definição de GeoVisualQL.
O processo de tradução da sentença de consulta visual para a sentença de consulta
textual na linguagem base faz parte também da especificação da linguagem GeoVisualQL e
será descrito a seguir.
5.6 ESPECIFICAÇÃO DO USO DOS METADADOS
Ao gerar a sentença SQL equivalente à consulta visual GeoVisualQL, são utilizadas as
definições formais da seção 5.5.1.1 conjuntamente com as informações de metadados.
A definição de predicado espacial computável requer que as geometrias das feições
sejam computáveis através de um operador espacial, por exemplo, os operadores crosses ou
touches.
156
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
O uso de metadados aparece como uma alternativa útil para determinar, dadas duas
feições f1 e f2 e um predicado espacial ξ, se o predicado é computável e como ele é
computável. Por exemplo, o processamento da consulta “Ache todos os lotes de Recife que
tocam o rio Capibaribe” poderia ser facilitado se se soubesse quais são as representações
geométricas associadas aos “lotes” e ao “rio Capibaribe”.
Estas informações estão disponíveis nas descrições de metadados, de forma que ao
submeter a consulta, através do analisador sintático, seja possível determinar se as feições
geográficas definidas como lote e rio possuem geometrias que podem ser associadas ao
operador touches. Caso o predicado espacial seja não computável, a consulta não é aceita.
5.7 Geração da Sentença SQL
Para ser possível a efetiva tradução da sentença de consulta visual GeoVisualQL para a
sentença de consulta textual SQL são utilizadas informações de metadados a respeito das
feições geográficas, envolvidas na consulta. Através das descrições de metadados, é possível
saber: quais as tabelas em que estão armazenadas as feições geográficas, que tipo de
geometria está associada às mesmas, além da informação do símbolo visual, ou imagem no
formato GIF que irá representar, dentro da linguagem, o objeto pictórico. Estas descrições de
metadados estão no formato XML e são lidas pelo tradutor de modo a disponibilizar, para os
usuários, os objetos pictóricos de cada aplicação, as possíveis instâncias para os mesmos,
como também tornar possível a geração da sentença SQL. Um exemplo completo destes
arquivos e como utilizá-los na tradução das consultas será apresentado no próximo capítulo.
Para cada um dos tipos de operadores disponíveis na GeoVisualQL, apresenta-se uma
breve descrição de como podem ser traduzidos para a especificação SQL do Open GIS. As
sentenças SQL geradas são dependentes do tipo do operador utilizado.
5.7.1 Geração de sentenças SQL utilizando os operadores topológicos definidos pela
linguagem base
Todos os operadores espaciais de natureza topológica, tais como: equals, disjoint, touches,
crosses, overlaps, within e contains, retornam valores lógicos em seus resultados. Devido à
natureza visual da linguagem GeoVisualQL, necessita-se, no entanto, de um retorno
essencialmente visual.
157
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Desta forma, inicialmente precisa-se identificar as feições geográficas que fazem parte
da sentença de consulta visual. Esta informação é obtida através das informações de
metadados da aplicação. Através das cláusulas SQL buscam-se, no banco de dados, as
coordenadas de cada feição, de modo a representar o resultado da consulta de forma visual.
Desta forma, uma possível sentença de consulta gerada, seguindo a especificação SQL do
OGC é a seguinte:
Select Feicao1.GetGeometry(), Feicao2.GetGeometry()
From Feicao1, Feicao2
Where OperadorTopológico ( Feicao1.GetGeometry(),
Feicao2.GetGeometry()) = 1
A função GetGeometry() retorna as coordenadas da geometria que representa a Feição
Geográfica e está descrita no Apêndice C.
5.7.2 Geração de sentenças SQL utilizando as extensões dos operadores topológicos
Os operadores topológicos derivados do formalismo 9IM [EH91] e acrescentados à
linguagem GeoVisualQL tais como: crothin, croches, crossout e crossects, são traduzidos, em
geral, para combinações de operadores que fazem parte da especificação SQL do OGC
[OGC99b]. Alguns destes podem ser simulados com o uso de dois ou mais operadores
espaciais de topologia do OGC. No entanto, existem casos em que isso ainda não é possível.
Devido à natureza visual da linguagem GeoVisualQL, necessita-se, também nestes operadores,
de um retorno visual.
Desta forma, as possíveis sentenças de consultas geradas, usando as funções da
especificação SQL do OGC, considerando que a função GetGeometry() retorna as
coordenadas da geometria que representa a Feição Geográfica, são as seguintes:
a) Crothin
Select Feicao1.GetGeometry(), Feicao2.GetGeometry()
From Feicao1, Feicao2
Where ((Crosses(Feicao1. GetGeometry(), Feicao2. GetGeometry()) = 1)
AND
((Within(Feicao1. GetGeometry(), Feicao2. GetGeometry()) = 1))
158
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
b) Croches
Select Feicao1.GetGeometry(), Feicao2.GetGeometry()
From Feicao1, Feicao2
Where ((Crosses(Feicao1. GetGeometry(), Feicao2. GetGeometry()) = 1)
AND
((Touches1. GetGeometry(), Feicao2. GetGeometry()) = 1))
No caso dos operadores Crossout e Crossects, não existe um conjunto de operadores
topológicos da especificação SQL do OGC [OGC99b] que tenham sua semântica equivalente
a estas definições e que possam ser utilizados na cláusula SQL. Desta forma, não
apresentamos a tradução para SQL destes dois operadores.
5.7.3 Geração de sentenças SQL utilizando operadores de conjuntos
Todos os operadores espaciais de conjuntos, utilizados na GeoVisualQL, retornam geometrias
como resultado. Devido à natureza visual da linguagem GeoVisualQL, utilizamos estes
retornos geométricos na interface. Desta forma, identificadas as feições geográficas que estão
sendo consultadas, as sentenças SQL geradas buscam, no banco de dados, as coordenadas de
cada feição, de modo a executar os operadores espaciais de conjuntos entre essas geometrias.
As possíveis sentenças de consultas geradas, usando as funções da especificação SQL do
OGC, considerando que a função GetGeometry() retorna as coordenadas da geometria que
representa a Feição Geográfica, são as seguintes:
a) Intersection
Select Intersection( Feicao1.GetGeometry(), Feicao2.GetGeometry())
From Feicao1, Feicao2
a) Difference
Select Difference( Feicao1.GetGeometry(), Feicao2.GetGeometry())
From Feicao1, Feicao2
a) Union
Select Union( Feicao1.GetGeometry(), Feicao2.GetGeometry())
From Feicao1, Feicao2
159
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
5.7 PROCESSO DE TRADUÇÃO DA CONSULTA VISUAL
A tradução da sentença de consulta visual para a consulta equivalente em SQL é feita
inicialmente através de uma associação dos símbolos equivalentes das duas linguagens. Os
símbolos visuais dos operadores topológicos, e de conjuntos, foram apresentados na seção
5.5.2. Também neste Capítulo, foram mostrados os símbolos visuais dos operadores lógicos,
na Figura 5.14(a) e do operador Grouped na Figura 5.14 (b).
Através da gramática da linguagem, a cada consulta visual válida em GeoVisualQL,
uma árvore sintática é gerada [Cor02] de acordo com o tipo do operador espacial utilizado,
se topológico, de conjunto ou lógico.
Então, considerando os tipos de operadores da linguagem, apresenta-se as possíveis
árvores sintáticas para cada tipo de consulta em GeoVisualQL. Consideram-se apenas árvores
binárias, onde o caminhamento na mesma é feito na forma in-order.
Uma cláusula de consulta lógica em GeoVisualQL apresenta-se com os seguintes
componentes, como mostra a Figura 5.31.
And
Or
Query
Clause
Query
Clause
Query
Clause
Query
Clause
Query
Clause
Not
Figura 5.31 – Árvores Sintáticas Logic_Clauses em GeoVisualQL
Dadas as árvores da Figura 5.31, cada Query_clause pode ter uma das seguintes
derivações, ilustradas na Figura 5.32. Uma Query_Clause, pode gerar uma outra
Logic_Clause, como está ilustrado na Figura 5.32. Neste caso, esta Logic_Clause será
substituída por uma das árvores da Figura 5.31, onde, para cada Query-Clause será utilizada
novamente as substituições da Figura 5.32 quantas vezes forem necessárias.
160
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Topologic
Operator
Logic
Clause
GEOMETRY
GEOMETRY
Figura 5.32 – Árvores Sintáticas das Query_Clauses de GeoVisualQL
Um outro tipo de consulta visual em GeoVisualQL é no caso do uso de operadores de
conjunto. Neste caso, a Figura 5.33 mostra a árvore sintática de uma cláusula de conjunto.
Set
Operator
GEOMETRY
GEOMETRY
Figura 5.33 – Árvore Sintática de um Set_Query_Clause em GeoVisualQL
Estes símbolos da linguagem GeoVisualQL foram todos definidos em sua gramática, no
Apêndice B desta tese. Para enfatizar, porém, definimos a geometria, chamada GEOMETRY,
utilizada nas cláusulas de consultas, como mostrado na Figura 5.34.
GEOMETRY
PONTO
LINHA
POLÍGONO
SET_QUERY
CLAUSE
Figura 5.34 – Tipos de Geometrias Aceitos nas C láusulas de Consulta GeoVisualQL
A partir da árvore sintática de uma consulta GeoVisualQL válida, algumas decisões são
tomadas, de acordo com o tipo de operador utilizado [Cor02].
Quando um operador topológico ou lógico é utilizado na consulta, a tradução SQL
equivalente corresponde a uma condição na cláusula WHERE do SELECT. Quando um
operador de conjunto é utilizado na consulta visual, o resultado da consulta é uma geometria
que é visualizada.
161
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Rio = ‘Capibaribe’
Cidade = ‘Recife’
Figura 5.35 – Exemplo de uma Consulta Visual válida
Considere o exemplo de consulta dado na Figura 5.35. Esta consulta ilustra o seguinte
questionamento: “O Rio Capibaribe cruza a Cidade do Recife?”. Apresenta-se a árvore
sintática desta consulta, na Figura 5.36, e como é feita a tradução da mesma. Baseado na
definição do tradutor, apresentado no Apêndice C desta tese, apresenta-se o exemplo de
tradução desta sentença de consulta visual para a sentença de consulta textual equivalente.
Crosses
Linha
Polígono
Figura 5.36 – Árvore Sintática Equivalente da Consulta Representada na Figura 5.35
Inicialmente identifica-se o operador crosses e as feições geográficas associadas às
geometrias e suas respectivas instâncias que, neste exemplo, estão identificadas. Então,
seguindo o tradutor da GeoVisualQL a seguinte sentença textual é gerada:
Select Rio.GetGeometry(), Cidade.GetGeometry() from Rio, Cidade
Where ((Rio.name =¨Capibaribe ¨) AND (Cidade.name =¨Recife¨) AND
Crosses(Rio.GetGeometry(), Cidade.GetGeometry()) = 1)”)
Isto implica dizer que a consulta em SQL vai buscar as geometrias das feições
geográficas do tipo Cidade e Rio que possuam os nomes de instâncias Recife e Capibaribe,
respectivamente, se as mesmas se cruzarem entre si. Caso contrário, a consulta retornará
vazia.
Suponha a seguinte consulta visual ilustrada pela Figura 5.37:
162
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
Parque = “Central Park”
Figura 5.37 – Exemplo de uma Consulta Válida com o operador crothin
A questão da consulta agora é a seguinte: “Retorne, se existir, um Rio que esteja
inteiramente dentro do Central Park, e o cruze de uma extremidade a outra”. De acordo com
o tradutor definido no Apêndice C, gera-se a seguinte sentença de consulta:
Select Rio.GetGeometry(), Parque.GetGeometry() from Rio, Parque
Where (Parque.name =“Central Park”) and
(Crosses(Rio.GetGeometry(), Parque.GetGeometry()) = 1 and
Within(Rio.GetGeometry(), Parque.GetGeometry()) = 1) )
Nesta consulta, serão selecionados todos os rios que cruzam o Central Park e que
estejam totalmente dentro do mesmo, assim como foi definida a consulta visual da Figura
5.37.
Para a geração de sentenças de consultas complexas, que utilizam operadores lógicos,
ilustra-se a geração da sentença SQL da Figura 5.30, seguindo as regras de tradução definidas
no Apêndice C desta tese:
Select feicao1.GetGeometry(), feicao2.GetGeometry(), feicao3.GetGeometry(),
feicao4.GetGeometry() from feicao1, feicao2, feicao3, feicao4
Where NOT ( (Crosses(feicao1.GetGeometry(), feicao2.GetGeometry()) = 1)
AND
Within(feicao3.GetGeometry(), feicao4.GetGeometry()) = 1) )
5.8 ANÁLISE COMPARATIVA DOS SISTEMAS DE CONSULTAS VISUAIS PARA SIG E O
SISTEMA GEOVISUAL
A seguir apresenta-se uma análise comparativa dos sistemas avaliados no Capítulo 4, de
acordo com as suas ca racterísticas e vantagens, como também suas limitações, e os
comparamos com o sistema GeoVisual. Primeiramente são apresenatdas as características do
Sistema GeoVisual, na Tabela 5.1, de acordo com as características avaliadas no Capítulo 4,
na Tabela 4.1.
163
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
SQL Padrão
OGC
Operadores
Métricos
Operadores
Temporais
Operadores
Lógicos
Modelo de
Dados OGC
Sistemas de
Consultas
Visuais para SIG
Interface
Representação
visual do
esquema do
Linguagem de
Consulta
Visual
Operadores
Topológicos
Conformidade
9IM
GeoVisual
Operadores
Disponíveis da
Metáfora
Linguagem
Topológicos: Equals,
Disponibiliza uma
Interface com
Disjoints, Touches,
linguagem de
ícones e
Within, Contains,
consulta visual em
informações de
Intersects, Overlaps,
Icônica.
sua interface, que
metadados que
Crosses, Crothin,
apresenta feições
facilitam o
Croches, Crossects e
geográficas de
entendimento do
Crossout. Conjunto:
forma visual e
conteúdo do BD.
Intersection,
operadores.
Difference e Union.
Lógicos.
Tabela 5.1 – Caracterizando GeoVisual
Características
Metadados
Sistema de
Consultas Visuais
para SIG
CIGALES
x
x
Ö
Ö
Ö
Lvis
x
x
Ö
Ö
Ö
Ö
Ö
VISCO
x
x
x
Ö
Ö
SKETCH
x
x
x
Ö
Ö
SPATIALx
x
x
Ö
Ö
Ö
Ö
QUERY-BYSKETCH
GEOMEDIA
x
√
x
x
x
x
x
Ö
ARCINFO 8
x
x
x
x
x
x
SVIQUEL
x
x
Ö
Ö
PQL
x
x
Ö
Ö
GeoVisual
x
x
Ö
Ö
Ö
Ö
Ö
Ö
Ö
Tabela 5.2 – Análise Comparativa de GeoVisual com demais trabalhos
Legenda:
x
x
x
x
x
x
x
x
x
Ö
Ö apresenta a característica
x não apresenta a característica
não foi possível avaliar.
A Tabela 5.2 compara a existência ou não de algumas funcionalidades entre os mesmos
sistemas. Ao analisar essa tabela pode-se observar que o Sistema GeoVisual se destaca por ter
usado padrões em diversos estágios de definição, por utilizar informações de metadados em
sua tradução, por representar o esquema do BD visualmente e por definir uma linguagem de
164
Capítulo 5 - Consultas Visuais em BGG baseadas em Metadados Espaciais
________________________________________________________________________________________________
consulta visual contendo, inclusive, operadores lógicos. Operadores métricos, direcionais e
temporais não são suportados.
5.9 CONCLUSÃO
As aplicações de BDG vêm demonstrando uma crescente necessidade de desenvolvimento de
novas opções de consultas para dados geográficos. Por ser bastante complexa e diversificada,
a natureza destes dados tem uma característica inerentemente visual devido a sua topologia e
referência espacial, além de suas dimensões. O uso de linguagens de consultas visuais em
BDG tem sido objeto de pesquisa em diferentes comunidades, e se destaca devido a sua
natureza amigável e a sua maior facilidade de uso em relação às linguagens de consultas
textuais tradicionais.
O que GeoVisual oferece como característica adicional aos outros sistemas é que: (1)
Define símbolos visuais para as geometrias das entidades geográficas e para os operadores da
linguagem de consulta, na interface; (2) Define formalmente uma linguagem de consulta
visual GeoVisualQL que é baseada no padrão Open GIS e possui operadores espaciais de
topologia, de conjuntos e operadores lógicos; (3) Faz a efetiva tradução para a linguagem
textual baseada em SQL; (4) Oferece uma visualização para os retornos booleanos dos
operadores topológicos; (5) Propõe novos operadores de topologia à linguagem que seguem a
especificação 9IM [Ege91]; (6) Propõe uma interface baseada em informações de metadados,
e portanto, extensível a novas aplicações.
No Capítulo seguinte apresenta-se um exemplo de uma aplicação utilizando o Sistema
GeoVisual.
165
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
CAPÍTULO 6
IMPLEMENTAÇÃO DO SISTEMA G EOVISUAL
“Em grande parte de vossas conversações, o
pensamento é meio assassinado. Pois, o
pensamento é uma ave do espaço que, numa
gaiola de palavras, pode abrir as asas, mas
não pode voar”.
(Gibran Khalil Gibran)
6.1 I NTRODUÇÃO
Este capítulo apresenta os detalhes de implementação do protótipo do Sistema GeoVisual
[Cor02] e as suas funcionalidades de acordo com a especificação da linguagem GeoVisualQL.
É possível, através do uso da interface deste protótipo, selecionar os símbolos visuais, agrupálos e submeter uma consulta ao sistema. Em seguida, após a validação sintática dessa consulta,
o módulo de tradução gera a sentença SQL equivalente. A partir dessa sentença SQL o banco
de dados é acessado e o resultado da mesma é apresentado de forma visual ao usuário.
Para validar o Sistema GeoVisual foi feita uma atualização na
implementação da
Interface GeoVisual [Fer00], como também uma modelagem de uma aplicação de Hidrologia,
utilizando dados reais do Estado do Rio Grande do Norte.
166
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Bacia Hidrográfica
Açude
Descrição:
Descrição:
Símbolo
visual
Área total drenada por um
rio e seus afluentes .
Símbolo
visual
Lago
Floresta
Descrição:
Símbolo
visual
Massa continental de água
superficial de extensão
considerável.
Descrição:
Símbolo
visual
Cidade
Símbolo
visual
Símbolo
visual
Símbolo
visual
Ecossistemas complexos,
nos quais as árvores são a
forma vegetal predominante
que protege o solo contra o
impacto direto do sol, dos
ventos e das precipitações.
Rio Permanente
Descrição:
Centro populacional
permanente, altamente
organizado, com funções
urbanas e políticas próprias.
Lugar onde a água é
acumulada, em geral,
formado pela construção de
barragens nos rios.
Descrição:
Símbolo
visual
Curso de água permanente
ou outro líquido cuja vazão
contribui para aumentar o
volume de outro corpo
d'água.
Rio Intermitente
Estrada de Ferro
Descrição:
Descrição:
Curso de água temporário ou
outro líquido cuja vazão
contribui para aumentar o
volume de outro corpo d'água.
Símbolo
visual
Via de transporte
Ferroviário.
Rodovia
Município
Descrição:
Descrição:
Via de transporte
Rodoviário.
Símbolo
visual
Extensão territorial em que
se exerce a jurisdição de
uma vereação.
Tabela 6.1 – Objetos Pictóricos de Recursos Hídricos
167
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
6.2 Objetos Pictóricos da Aplicação de Recursos Hídricos
A aplicação exemplo é denominada Hidrologia e contém as seguintes feições
geográficas, cada uma delas com a sua representação visual equivalente.
Um conjunto de dados-exemplo de Hidrologia é formado por uma descrição de Bacias
Hidrográficas do Estado do Rio Grande do Norte. Cada Bacia é representada por uma região
bem limitada, contendo um rio e seus afluentes. A extensão de uma Bacia pode incluir mais
de um município. Cada açude pertence a uma única Bacia Hidrográfica e é formado pela
barragem de um dos rios que compõem a Bacia. Uma Bacia pode ou não possuir açudes.
Qualquer ponto geográfico do Estado pertence obrigatoriamente a alguma Bacia
Hidrográfica. Em outras palavras, as bacias hidrográficas cobrem toda a extensão do Estado.
Dentro de uma Bacia encontram-se, além dos rios e açudes, os municípios com suas cidades,
lagos, florestas, estradas de ferro e rodovias. Alguns objetos pictóricos, com seus respectivos
símbolos visuais que representam as feições geográficas, foram definidos para esta aplicação e
podem ser usados na construção de consultas como ilustrados na Tabela 6.1.
Os objetos pictóricos de uma aplicação de Recursos Hídricos representados na Tabela
6.1 estão disponíveis na interface para a efetiva elaboração das consultas ao banco de dados
geográfico da aplicação.
6.3 Interface GeoVisual
A interface GeoVisual apresenta uma área para os símbolos visuais básicos da linguagem
(ponto, linha e polígono) e uma área para os símbolos visuais dos operadores espaciais, sejam
de topologia, de conjuntos ou lógicos, e o operador de agrupamento, como mostra a Figura
6.1. A área de consultas está localizada na área central da Janela Principal e nela o usuário
seleciona os símbolos visuais e os agrupa, segundo a definição de cada operador da
linguagem. Uma área adicional é dependente da aplicação em uso e apresenta os objetos
pictóricos específicos para a mesma, como ilustrado na Figura 6.2.
168
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Símbolos
Visuais dos
Operadores
Lógicos
Símbolos
Visuais
Básicos
Área de Consultas
Símbolos
Visuais dos
Operadores
da
Linguagem
Figura 6.1 - Interface GeoVisual - Janela Principal
A Figura 6.2 ilustra os objetos pictóricos que representam as feições geográficas da
aplicação de Hidrologia que foram implementados neste protótipo. Uma área adicional é
definida, como ilustrado na Figura 6.3, onde o usuário tem a disponibilidade de verificar a
sentença SQL gerada, e uma outra onde pode analisar, graficamente, o resultado da consulta.
169
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Figura 6.2 - Janela da Aplicação
Figura 6.3 - Janela de Apresentação
6.3.1 Detalhes de Implementação
A Interface GeoVisual [Cor02] atual, foi desenvolvida em Java no ambiente JBuilder 6
Enterprise Edition, da Borland Products, sendo, desta forma, portável e facilmente adaptável
ao ambiente Web.
Foi feita uma implementação do Banco de Dados Geográfico utilizando o pacote
Oracle Spatial da versão 9i do SGBD Oracle [Ora02]. Para realizarmos a comunicação da
interface com o banco de dados, utilizou-se a API JDBC própria do Oracle 9i, de modo que
as consultas realizadas pudessem ser geradas e executadas com sucesso.
Um conjunto de dados reais de Recursos Hídricos foi selecionado para a efetiva
implementação do banco de dados. Estes dados incluíram coordenadas geográficas, e
informações não espaciais de bacias hidrográficas, açudes e municípios. Foram realizados
vários tipos de consultas neste banco de dados, e algumas delas foram implementadas de
forma visual, na Interface.
170
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
6.3.2 Adaptação ao Oracle 9i
Para a implementação do banco de dados geográfico, utilizamos o pacote Oracle Spatial do
Oracle 9i Database [Ora02] e adaptamos a geração das consultas SQL para a especificação da
linguagem do Oracle.
Para implementação do tipo Geometria, o Oracle Spatial apresenta um esquema, o
MDSYS, que define o armazenamento, a sintaxe e a semântica dos tipos geométricos a que dá
suporte, como também os mecanismos de indexação espacial e funções espaciais.
Os tipos geométricos permitidos no Oracle Spatial 9i são compatíveis com a
especificação do Open GIS [OGC99a]. Os relacionamentos topológicos oferecidos pela
implementação Oracle são mostrados na Figura 6.4.
Figura 6.4 - Relacionamentos Topológicos do Oracle Spatial 9i [Ora02]
Alguns relacionamentos que foram definidos para a linguagem GeoVisualQL não são
oferecidos por esta versão do Oracle, como por exemplo, o relacionamento Crosses e suas
variações. O relacionamento Within, do GeoVisualQL, pode ser substituído pelo uso do
INSIDE e do COVEREDBY, ilustrados na Figura 6.4.
6.3.2.1 Tipo Geometria do Oracle e seus Métodos
O Oracle Spatial 9i define um tipo geometria, dentro do esquema MDSYS, chamado de
SDO_GEOMETRY, como:
171
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
CREATE TYPE sdo_geometry AS OBJECT (
SDO_GTYPE NUMBER,
SDO_SRID NUMBER,
SDO_POINT SDO_POINT_TYPE,
SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY,
SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY);
onde, SDO_GTYPE define o tipo da geometria,
SDO_SRID define o Sistema de Referencia Espacial,
SDO_POINT é utilizado em casos especiais quando os dois
próximos campos são vazios. Armazena as
coordenadas do ponto.
SDO_ELEM_INFO define a forma de leitura dos pontos
armazenados em SDO_ORDINATE_ARRAY.
SDO_ORDINATES armazena as coordenadas da geometria.
e os tipos auxiliares:
CREATE TYPE
X
Y
Z
CREATE TYPE
CREATE TYPE
sdo_point_type AS OBJECT (
NUMBER,
NUMBER,
NUMBER);
sdo_elem_info_array AS VARRAY (1048576) of NUMBER;
sdo_ordinate_array AS VARRAY (1048576) of NUMBER;
Ao incluirmos as características de uma feição geográfica, definimos um campo
pertencente ao tipo definido MDSYS.SDO_GEOMETRY que armazena todas as informações
da geometria, como também, utiliza os métodos que facilitam o uso deste tipo.
De todos os operadores especiais implementados dentro do pacote Oracle Spatial, um
deles parece suprir as necessidades dos operadores de GeoVisualQL de origem topológica,
que é o operador SDO_RELATE.
A sintaxe geral do operador SDO_RELATE é a seguinte:
SDO_RELATE(geometry1, geometry2,’mask = <tipo_do_relacionamento>
querytype = <tipo_da_consulta>’) = ’TRUE’
SDO_RELATE define se duas geometrias interagem entre si de um modo específico,
ou não. Os modos de interação, entre essas geometrias, permitidos pelo operador são uma
combinação de um ou mais dos seguintes relacionamentos 9IM padrões [Ora02]: TOUCH,
OVERLAPBDYDISJOINT, OVERLAPBDYINTERSECT, EQUAL, INSIDE, COVEREDBY,
CONTAINS, COVERS, ANYINTERACT, ON.
Estes operadores foram visualmente
apresentados na Figura 6.4.
172
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Algumas dessas relações topológicas são homônimas aos operadores definidos para a
GeoVisualQL, outras, apesar de ter outros nomes, têm a mesma funcionalidade. Por exemplo,
OVERLAPBDYINTERSECT pode ser usado no lugar do operador Overlaps da GeoVisualQL.
Os operadores INSIDE e COVEREDBY podem ser usados juntos para simular a função do
operador Within da GeoVisualQL.
Também se pode usar algumas funções de geometria que estão definidas neste pacote
Oracle. Estas funções de geometria podem ser usadas para fazer a efetiva tradução dos
operadores de conjunto de GeoVisualQL, para a linguagem SQL. A sintaxe dessas funções
está mostrada a seguir, onde dim1 e dim2 são os parâmetros de dimensão das duas
geometrias, e são obtidos da tabela de metadados do Oracle [Ora02] denominada
USER_SDO_GEOM_METADATA, que armazena as informações básicas das entidades que
possuem características de geometria. Sintaxe das funções de geometria do Oracle:
SDO_GEOM.SDO_DIFFERENCE(
geom1 IN MDSYS.SDO_GEOMETRY,
dim1 IN MDSYS.SDO_DIM_ARRAY,
geom2 IN MDSYS.SDO_GEOMETRY,
dim2 IN MDSYS.SDO_DIM_ARRAY
) RETURN MDSYS.SDO_GEOMETRY;
SDO_GEOM.SDO_UNION(
geom1 IN MDSYS.SDO_GEOMETRY,
dim1 IN MDSYS.SDO_DIM_ARRAY,
geom2 IN MDSYS.SDO_GEOMETRY,
dim2 IN MDSYS.SDO_DIM_ARRAY
) RETURN MDSYS.SDO_GEOMETRY;
SDO_GEOM.SDO_INTERSECTION(
geom1 IN MDSYS.SDO_GEOMETRY,
dim1 IN MDSYS.SDO_DIM_ARRAY,
geom2 IN MDSYS.SDO_GEOMETRY,
dim2 IN MDSYS.SDO_DIM_ARRAY
) RETURN MDSYS.SDO_GEOMETRY;
6.4 Modelagem da Aplicação
A aplicação-exemplo da área de Hidrologia, consta de apenas três tipos de feições:
bacia_hidrografica, municipios e açudes . Para os dados destas feições utilizou-se dados de
173
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
latitude e longitude reais do Estado do RN, obtidos da Empresa de Pesquisa Agropecuária do
Rio Grande do Norte S/A.
De acordo com a especificação Oracle 9i, as seguintes Tabelas, 6.2, 6.3 e 6.4 foram
criadas, segundo os scripts em anexo no Apêndice D.
BACIAS_FID
VARCHAR(256)
NAME
BACIAS_NUM_PONTOS
VARCHAR(256)
INTEGER
MUNICIPIOS_FID
NAME
BACIAS_FID
VARCHAR(256)
VARCHAR(256)
INTEGER
Id. da Bacia Hidrografica
Nome da Bacia
Número de Pontos de
coordenadas
BACIAS_EXTENSAO
REAL
Extensão da Bacia em Km 2
BACIAS_PERCENTAGEM
REAL
Percentagem da Bacia em
relação ao Estado do RN
BACIAS_NUM_ACUDES
INTEGER
Número de açudes relevantes
da bacia
BACIAS_VOL_AGUA
REAL
Volume de água total da
Bacia
GM_SHAPE
MDSYS.SDO_GEOMETRY
Tipo Geometria Oracle
Tabela 6.2 Tabela de Bacias Hidrográficas
MUNICIPIOS_POPULACAO REAL
MUNICIPIOS_NUM_
REAL
PONTOS
GM_SHAPE
MDSYS.SDO_ GEOMETRY
Tabela 6.3 Tabela de Municípios
ACUDES_FID
NAME
BACIAS_FID
VARCHAR(256)
VARCHAR(256)
INTEGER
MUNICIPIOS_FID
REAL
ACUDES_RIO_BARRADO
ACUDES_CAPACIDADE
GM_SHAPE
REAL
INTEGER
MDSYS.SDO_GEOMETRY
Tabela 6.4 Tabela de Açudes
Identificador do Município
Nome da Município
Bacia onde ele se encontra
total ou parcialmente
População do Município
Número de Pontos de
coordenadas do Município
Tipo Geometria Oracle
Identificador do Açude
Nome do Açude
Bacia a que o Açude
pertence
Município ao qual o açude
pertence
Nome do Rio barrado
Capacidade do Açude
Tipo Geometria Oracle
De acordo com a especificação SQL do Oracle Spatial, e considerando as tabelas de
feições da aplicação, definem-se a seguir exemplos da geração das sentenças SQL.
174
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Considere o seguinte cenário onde a aplicação de hidrologia está em uso. Na aplicação, cada
feição geográfica possui um tipo de geometria e, possivelmente, um símbolo visual específico
para a mesma. Desta forma, na interface, para cada tipo geométrico dos símbolos visuais
básicos, encontram-se disponíveis as feições geográficas que foram definidas para o mesmo.
Estas informações são encontradas pelo sistema através dos arquivos de descrição de
metadados de cada aplicação. Os arquivos de metadados que o sistema utiliza estão no
formato do padrão FGDC, e se encontram descritos em XML (eXtensible Markup Language)
[XML02]. Para cada feição geográfica existente na aplicação são descritas informações como:
o nome da tabela, o tipo da geometria desta feição e o nome da imagem no formato GIF que
irá representar o objeto pictórico dentro da aplicação. O usuário pode então construir suas
consultas utilizando, por exemplo, os objetos pictóricos específicos da hidrologia, fazendo ou
não uma associação com alguma possível instância, ou pode utilizar os símbolos visuais
básicos da linguagem, tais como ponto, linha e polígono, juntamente com os operadores
espaciais disponíveis na interface. A descrição completa das feições geográficas utilizadas
neste protótipo, descritas em XML, são mostradas no Apêndice E.
6.4.1 Utilizando os metadados
Para cada feição geográfica, identifica-se uma seção do padrão FGDC chamada ENTITYTYPE, e uma sub-seção, ENTITY_LABEL, que em XML são identificadas respectivamente
por: enttyp e enttypl. Estas seções identificam o nome da feição, que se refere também ao
nome da tabela onde a mesma se encontra definida. Dentro de cada definição de entidade,
definem-se os atributos que a compõem, através das subseções denominadas ATTRIBUTE,
ATTRIBUTE_LABEL, ATTRIBUTE_DEFINITION, entre outras. Em XML estas subseções
estão representadas respectivamente por: attr, attrlabl, attrdef. Cada attr define um atributo.
Cada feição possui os seguintes atributos básicos: NAME, GEOMETRY-TYPE, IMAGE_GIF
e GM_SHAPE, e outros atributos que são específicos para a mesma. O atributo NAME
identifica o nome da instância, o atributo GEOMETRY_TYPE identifica o tipo da geometria
que está associada àquela feição, o atributo IMAGE_GIF indica o caminho do arquivo
contendo o símbolo visual que representa o objeto pictórico da feição, e o atributo
GM_SHAPE é o tipo geometria definido pelo Oracle. Os atributos GEOMETRY_TYPE e
IMAGE_GIF não estão efetivamente armazenados no banco de dados. São atributos que
175
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
fornecem informações para que o sistema possa compor a interface, e auxiliam à geração das
sentenças SQL.
A descrição completa das feições implementadas neste protótipo se encontra no Apêndice E.
A seguir, apresentamos um resumo da descrição da feição bacia hidrográfica, em XML:
<enttyp >
<enttypl>Bacias </enttypl>
<enttypd>Entidade Geográfica Bacias Hidrograficas do
Estado do RN e seus atributos </enttypd >
<enttypds>none </enttypds>
</enttyp>
<attr>
<attrlabl>IMAGE_GIF </attrlabl>
<attrdef >Nome do Arquivo que Representa a
Entidade </attrdef >
<attrdefs>GIF </attrdefs >
- <attrdomv >
<udom> ~GeoVisual/GIFS/Bacia.GIF </udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GM_SHAPE </attrlabl>
<attrdef >Tipo Geometria implementado no Oracle
9i</attrdef >
<attrdefs>MDSYS.SDO_GEOMETRY </attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
A identificação da imagem representativa do objeto pictórico do atributo IMAGE_GIF não é
obrigatória. Cabe ao projetista decidir se vai inserir esta imagem em sua especificação ou não.
Para as feições geográficas que não possuem objetos pictóricos previamente definidos, os
símbolos visuais básicos da linguagem podem ser usados, de acordo com o tipo de geometria
definida para esta feição, definida no atributo GEOMETRY_TYPE.
Através das informações de metadados, as informações de conteúdo do banco de dados estão
disponíveis ao usuário. Pelas representações visuais que fazem parte da interface, o usuário
obtém informações a respeito de quais tipos de feições geográficas estão implementadas para
uma determinada aplicação, inclusive com o tipo de sua geometria.
176
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
6.4.2 Exemplos das Sentenças SQL geradas
Ao usarmos os operadores de topologia da GeoVisualQL, as sentenças SQL geradas
equivalentes para a implementação do Oracle são as seguintes:
a) Equals, Touches, Disjoints e Overlaps
SELECT Feicao1.GM_SHAPE, Feicao2.GM_SHAPE
FROM Feicao1, Feicao2
WHERE SDO_RELATE(Feicao1.GM_SHAPE, Feicao2.GM_SHAPE ,
'mask=EQUAL querytype=WINDOW') = 'TRUE'
SELECT Feicao1.GM_SHAPE, Feicao2.GM_SHAPE
FROM Feicao1, Feicao2
WHERE SDO_RELATE(Feicao1.GM_SHAPE,Feicao2.GM_SHAPE,
'mask= TOUCH querytype=WINDOW') = 'TRUE'
SELECT Feicao1.GM_SHAPE, Feicao2.GM_SHAPE
FROM Feicao1, Feicao2
WHERE SDO_RELATE(Feicao1.GM_SHAPE,Feicao2.GM_SHAPE ,
'mask=DISJOINT querytype=WINDOW') = 'TRUE'
SELECT Feicao1.GM_SHAPE, Feicao2.GM_SHAPE
FROM Feicao1, Feicao2
WHERE SDO_RELATE(Feicao1.GM_SHAPE,Feicao2.GM_SHAPE ,
'mask=OVERLAPBDYINTERSECT querytype=WINDOW') = 'TRUE'
b) Within e Contains
SELECT Feicao1.GM_SHAPE, Feicao2.GM_SHAPE
FROM Feicao1, Feicao2
WHERE SDO_RELATE(Feicao1.GM_SHAPE,Feicao2.GM_SHAPE ,
'mask=INSIDE+COVEREDBY querytype=WINDOW') = 'TRUE'
SELECT Feicao1.GM_SHAPE, Feicao2.GM_SHAPE
FROM Feicao1, Feicao2
WHERE SDO_RELATE(Feicao1.GM_SHAPE,Feicao2.GM_SHAPE ,
'mask=CONTAINS+COVERS querytype=WINDOW') = 'TRUE'
Para os operadores de conjunto definidos para a GeoVisualQL a geração das sentenças SQL
são as seguintes:
177
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
a) Intersection
SELECT SDO_GEOM.SDO_INTERSECTION( A.GM_SHAPE, m.diminfo,
B.GM_SHAPE, m.diminfo)
FROM Feicao1 A, Feicao2 B, USER_SDO_GEOM_METADATA m
b) Difference
SELECT SDO_GEOM.SDO_DIFFERENCE( A.GM_SHAPE, m.diminfo,
B.GM_SHAPE, m.diminfo)
FROM Feicao1 A, Feicao2 B, USER_SDO_GEOM_METADATA m
c) Union
SELECT SDO_GEOM.SDO_UNION( A.GM_SHAPE, m.diminfo,
B.GM_SHAPE, m.diminfo)
FROM Feicao1 A, Feicao2 B, USER_SDO_GEOM_METADATA m
6.5 Considerações sobre GML
O OpenGIS define uma linguagem, a Geography Markup Language (GML), que utiliza a
codificação XML para permitir o transporte e o armazenamento de informações geográficas
incluindo tanto as propriedades espaciais como as não espaciais das feições geográficas
[GML02].
Apesar da linguagem GML ter sido definida pelo próprio OpenGIS, especificação que
foi adotada na definição do Sistema GeoVisual, foi decidido utilizar a linguagem XML da
forma como o próprio padrão FGDC definiu. Pela descrição de metadados do FGDC, o uso
do XML é auxiliado pela ferramenta TKME [Sch02]. Além disso, o protótipo do sistema
GeoVisual está baseado também neste padrão de metadados.
6.6 Exemplo de Utilização da GeoVisualQL
Considerando a aplicação de hidrologia que foi descrita na seção 6.4, seja o seguinte cenário,
onde um usuário deseja realizar uma consulta do tipo:
“Quais os Municípios que se sobrepõem à Bacia Hidrográfica de Curimataú?¨
A elaboração da consulta visual segue os seguintes passos:
178
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
1. Inicialmente, o usuário seleciona os símbolos visuais da GeoVisualQL disponíveis na
interface, que melhor possam representar as feições geográficas envolvidas na
consulta.
2. Ao selecionar o símbolo visual polígono, o usuário conta, na interface, com os objetos
pictóricos, cujas feições geográficas foram definidas para este tipo de geometria, e que
fazem parte da Interface GeoVisual. Cita-se, por exemplo, alguns anteriormente
definidos, tais como: Bacia e Município. O usuário, então, seleciona o objeto
pictórico da feição geográfica Bacia Hidrográfica identificando a instância de
‘Curimataú’. Depois disso, seleciona o objeto pictórico da feição Município e o
posiciona também na área de consulta sem necessitar identificar a instância, uma vez
que a consulta não especifica um Município individual.
3. Após serem identificados os dois operandos da consulta, o símbolo visual que
representa o operador espacial Overlaps é selecionado e agrupado junto com os
objetos pictóricos da consulta, resultando na seguinte sentença de consulta visual,
ilustrada na Figura 6.5.
Figura 6.5 – Exemplo de uma Consulta Visual válida
179
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Ao submeter esta consulta, a interface a valida e passa o processamento para o tradutor,
que gera a sentença de consulta textual, na linguagem SQL como mostrado na próxima seção.
6.6.1 Sentença SQL Equivalente
De acordo com a especificação visual da consulta, as feições e uma de suas instâncias estão
especificadas, de modo que a consulta SQL gerada tem o seguinte formato:
SELECT MUNICIPIOS1.GM_SHAPE
FROM MUNICIPIOS MUNICIPIOS1 , BACIAS BACIAS2
WHERE BACIAS2.NAME Like '%CURIMATAU%'
AND
SDO_RELATE( BACIAS2.GM_SHAPE , MUNICIPIOS1.GM_SHAPE ,
'mask=OVERLAPBDYINTERSECT querytype=WINDOW' ) = 'TRUE'
Observa-se que o resultado da sentença SQL gerada obtém as geometrias dos objetos,
representada pelo atributo GM_SHAPE. Isto se deve ao fato que não desejamos apenas um
resultado booleano (TRUE ou FALSE), desejamos que, caso o resultado seja satisfatório, ou
seja, se os municípios se sobrepõem à Bacia de Curimataú, possamos obter as geometrias dos
mesmos. Ao final, obtém-se o resultado gráfico da consulta. Caso a consulta topológica
retorne valor negativo, a consulta visual não retorna nada.
6.6.2 Resultado da Consulta
A Figura 6.3 mostra a Janela de Apresentação da Interface GeoVisual. Nela apresenta-se o
resultado da consulta de forma visual. Também se pode visualizar a consulta SQL gerada por
uma janela adicional. Para o caso da consulta mostrada na seção anterior, o resultado da
execução da mesma está ilustrado na Figura 6.6.
180
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
Figura 6.6 – Resultado da Consulta Visual
Observe que, pelo resultado da consulta obtida, toma-se conhecimento das geometrias
de dois municípios que sobrepõem a ‘Bacia de Curimataú’ que, neste caso, são os municípios
de ‘Nova Cruz’ e ‘Pedro Velho’.
6.7 Análise Crítica do Protótipo GeoVisual
Em GeoVisualQL, a apresentação do resultado da consulta é ainda bastante primitiva,
apresenta poucas informações e nenhuma contextualização. Alguns conceitos adicionais de
apresentação de resultados de consultas foram analisados ([Cam95]) e precisam ser
acrescentados à linguagem.
A linguagem GeoVisualQL ainda precisa:
•
Apresentar o resultado da consulta de forma contextualizada, ou seja, dentro de
um contexto geográfico, com a sua apropriada localização;
•
Apresentar opções ao usuário de definir tipo da cor e/ou da textura de cada*
resultado obtido de sua consulta;
181
Capítulo 6 – Implementação do Sistema GeoVisual
________________________________________________________________________________________________
•
Em caso de consultas que sejam resultados de uma junção espacial, apresentar cada
conjunto de valores em janelas diferentes ou, caso sejam apresentadas em uma
mesma janela, em cores e/ou texturas diferentes;
Um aspecto importante de pesquisa analisa a melhor maneira de se manipular com
múltiplas representações em SIG [DL99, Dav00]. Múltiplas representações em SIG é
realidade em diversos tipos de aplicações e não podem ser desprezados no projeto de novos
sistemas. Atualmente o Sistema GeoVisual não permite, da maneira como está especificado, a
manipulação de múltiplas representações de feições geográficas. Mas, existe uma maneira
viável de se trabalhar com múltiplas representações em GeoVisual através da própria
descrição de metadados. A partir da criação de atributos adicionais, ou mesmo de tags XML,
o sistema poderia identificar a existência de múltiplas representações para uma dada feição.
Para a manipulação dessas informações múltiplas na interface algumas restrições,
provavelmente, necessitariam ser definidas.
6.8 Conclusão
O Sistema GeoVisual é um ambiente de consultas visuais para bancos de dados geográficos
que foi proposto com o propósito de facilitar a interação do usuário com as linguagens de
consultas específicas para este tipo de dados, uma vez que as mesmas possuem construções
sintáticas muito complexas que muitas vezes confundem o usuário. Um outro objetivo
importante de GeoVisual é o de informar, de maneira visual, o conteúdo do banco de dados
que se encontra disponível para consultas. Desta maneira, um usuário casual, que desconhece
as informações de uma determinada aplicação, é informado dos tipos de feições geográficas
que estão disponíveis no banco, ao mesmo tempo em que pode utilizar estas informações
para formular suas consultas, utilizando os operadores disponíveis.
Foi implementado um protótipo do sistema a fim de validar as principais idéias
propostas, desde a elaboração da consulta visual pelo usuário, até a obtenção do resultado da
consulta, também de forma visual.
182
Capítulo 7 – Contribuições e Trabalhos Futuros
________________________________________________________________________________________________
CAPÍTULO 7
CONTRIBUIÇÕES E T RABALHOS FUTUROS
“Não creia no que os seus olhos lhe dizem.
Tudo que mostram é limitação. Olhe com o
entendimento, olhe além dos sentidos, do
intelecto e da mente”.
Richard Bach
7.1 I NTRODUÇÃO
As aplicações de SIG vêm demonstrando uma crescente necessidade de desenvolvimento de
novas opções de linguagens de consultas. Por serem bastante complexos e diversificados,
dados geográficos têm uma característica inerentemente visual devido a sua topologia e
referência espacial, além de suas dimensões. O uso de linguagens de consultas visuais em SIG
tem sido objeto de pesquisa nos últimos anos [BM95, BAT00, BE00] e se destaca devido a
sua maior facilidade de uso em relação às linguagens de consultas textuais tradicionais.
O Sistema GeoVisual apresenta um Ambiente de Consultas Visuais para Bancos de
Dados Geográficos, que oferece como características adicionais aos outros sistemas: (1)
Define símbolos visuais para geometrias de entidades geográficas, e para os operadores da
linguagem de consulta e os disponibiliza na interface; (2) Define formalmente uma linguagem
de consulta visual GeoVisualQL que é baseada na especificação do padrão Open GIS
[OGC99a] e possui operadores espaciais de topologia, de conjuntos e operadores lógicos; (3)
Faz a efetiva tradução para a linguagem textual baseada em SQL; (4) Define operadores de
topologia à linguagem que seguem a especificação 9IM [Ege91]; (5) Apresenta uma interface
183
Capítulo 7 – Contribuições e Trabalhos Futuros
________________________________________________________________________________________________
para a linguagem baseada em informações de metadados, e portanto, extensível a novas
aplicações.
7.2 C ONTRIBUIÇÕES DO TRABALHO
Como resultado final desse trabalho podemos citar principalmente:
1. Definição da Arquitetura do Sistema Geovisual, com a descrição funcional de
seus módulos componentes.
2. Definição gramatical de uma Linguagem de Consulta Visual para Dados
Geográficos, a GeoVisualQL.
3. Definição do Processo de Tradução da GeoVisualQL para a linguagem de
consulta baseada em SQL da especificação OGC, utilizando metadados FGDC.
4. Disponibilização, na Interface, das funcionalidades definidas para a linguagem.
5. Implementação de um protótipo para validação do sistema GeoVisual,
utilizando o Oracle Spatial 9i .
7.3 Trabalhos Futuros
Como trabalhos, a serem realizados no futuro, sugere-se:
1. Extensão do Sistema GeoVisual de modo a:
a. Permitir novos tipos de operadores, tais como operadores métricos e
direcionais.
b. Permitir que atributos não espaciais possam ser identificados pelo usuário de
modo à obtenção de resultados mais específicos.
c. Visualizar os resultados da consulta dentro de um contexto geral onde as
informações se situam.
d. Permitir que atributos de edição do resultado das consultas, tais como cor e
textura, possam ser selecionados pelo usuário de modo à obtenção de uma
melhor apresentação deste resultado.
e. Apresentar informações em forma de gráficos, de modo a complementar o
resultado visual.
184
Capítulo 7 – Contribuições e Trabalhos Futuros
________________________________________________________________________________________________
f. Implementar múltiplas representações para feições geográficas.
2. Extensão do Sistema GeoVisual de modo a que ferramentas de descrição de
metadados e de criação de símbolos visuais se incorporem ao núcleo do sistema,
facilitando o trabalho do projetista.
7.4 Conclusão
O projeto do Sistema GeoVisual - Ambiente de Consultas Visuais em Bancos de Dados
Geográficos, surgiu da percepção da necessidade de uma linguagem de consulta visual e
informativa para este tipo de dados. Visual porque utiliza símbolos visuais, ou ícones,
representativos de feições, ou entidades geográficas. Informativa porque através dessa
característica visual, informa ao usuário a respeito do conteúdo dos dados que fazem parte de
uma dada aplicação.
Através do uso de informações de metadados, a interface se torna adaptável a cada
aplicação, de modo que os objetos pictóricos disponíveis na interface, para uso na elaboração
de consultas ao sistema, sejam específicos a cada uma delas.
Apesar de existirem, na literatura, algumas propostas de Sistemas de Consultas Visuais
projetados para serem usados em SIG, como os citados no Capítulo 4, o Sistema GeoVisual se
propõe a integrar duas áreas de pesquisa – o paradigma de consultas visuais e os padrões de
metadados espaciais - que têm sido pouco utilizadas em conjunto. A especificação do padrão
Open GIS [OGC99a, OGC99b] foi utilizada na concepção da linguagem de consulta
GeoVisualQL, que foi formalmente definida utilizando-se um formalismo apropriado
[Gol91]. O Sistema GeoVisual, permite que os usuários submetam suas consultas visuais
através de uma interface apropriada, converte a sentença de consulta visual para uma
sentença de consulta textual em SQL, e realiza a busca efetiva ao banco de dados geográfico
de forma transparente ao usuário.
185
Apêndice A – Exemplo de Descrição dos Metadados de Hidrologia pelo FGDC
________________________________________________________________________________________________
APÊNDICE A
E XEMPLO DE DESCRIÇÃO DOS METADADOS DE
HIDROLOGIA PELO PADRÃO FGDC
// Descrição de Metadados dos Dados da Aplicação de Hidrologia, através da Tabela
// de Metadados GEOMETRY_COLUMNS do OpenGIS [OGC98b].
Identification_Information:
Citation:
Citation_Information:
Originator: Valéria Goncalves Soares
Publication_Date: 10012002
Title: Feicoes Geográficas de Hidrologia
Description:
Abstract: Estes dados descrevem as feicoes geograficas modeladas na aplicacao de
hidrologia, e suas tabelas OpenGIS.
Purpose: Tem como objetivo orientar a busca de informacoes nestas tabelas, atraves de
consultas visuais.
Time_Period_of_Content:
Time_Period_Information:
Single_Date/Time:
Calendar_Date: 10012002
Currentness_Reference: publication date
Status:
Progress: in work
Maintenance_and_Update_Frequency: Daily
Spatial_Domain:
Bounding_Coordinates:
West_Bounding_Coordinate: 12
East_Bounding_Coordinate: 22
North_Bounding_Coordinate: 33
South_Bounding_Coordinate: 44
Keywords:
Theme:
Theme_Keyword_Thesaurus: none
Theme_Keyword: hidrologia
Access_Constraints: none
Use_Constraints: none
Entity_and_Attribute_Information:
Detailed_Description:
186
Apêndice A – Exemplo de Descrição dos Metadados de Hidrologia pelo FGDC
________________________________________________________________________________________________
Entity_Type:
Entity_Type_Label: Bacias
Entity_Type_Definition: Entidade Geográfica Bacias Hidrograficas do Estado do RN
Entity_Type_Definition_Source: none
Attribute:
Attribute_Label: F_TABLE_CATALOG
Attribute_Definition: Catalogo da Entidade Bacias
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: UFPE
Attribute:
Attribute_Label: F_TABLE_SCHEMA
Attribute_Definition: Esquema da Entidade Bacias
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: Hidrologia
Attribute:
Attribute_Label: F_TABLE_NAME
Attribute_Definition: Nome da Tabela de Bacias no BD
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: BACIAS
Attribute:
Attribute_Label: F_GEOMETRY_COLUMN
Attribute_Definition: Nome da Coluna de Geometria dentro da Tabela de Bacias
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: BACIAS_GM_COL
Attribute:
Attribute_Label: G_TABLE_CATALOG
Attribute_Definition: Catalogo da Tabela de Geometrias de Bacias
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: UFPE
Attribute:
Attribute_Label: G_TABLE_SCHEMA
Attribute_Definition: Esquema da Tabela de Geometrias das Bacias
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: Geometrias
Attribute:
Attribute_Label: G_TABLE_NAME
Attribute_Definition: Nome da tabela de Geometrias das Bacias
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: GM_BACIAS
Attribute:
Attribute_Label: GEOMETRY_TYPE
Attribute_Definition: Tipo da Geometria Utilizada
187
Apêndice A – Exemplo de Descrição dos Metadados de Hidrologia pelo FGDC
________________________________________________________________________________________________
Attribute_Definition_Source: none
Attribute_Domain_Values:
Enumerated_Domain:
Enumerated_Domain_Value: INTEGER
Enumerated_Domain_Value_Definition: Numeros inteiros representativos das
geometrias 1=point, 3=linestring, e 5=polygon
Enumerated_Domain_Value_Definition_Source: 5
Attribute:
Attribute_Label: IMAGE_GIF
Attribute_Definition: Nome da imagem que representa a entidade
Attribute_Definition_Source: GIF
Attribute_Domain_Values:
Unrepresentable_Domain: ~/GIFS/BACIAS.GIF
Detailed_Description:
Entity_Type:
Entity_Type_Label: ACUDES
Entity_Type_Definition: Entidade Geográfica Acudes do Estado do Rio Grande do Norte
Entity_Type_Definition_Source: none
Attribute:
Attribute_Label: F_TABLE_CATALOG
Attribute_Definition: Catalogo da Entidade Acudes
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: UFPE
Attribute:
Attribute_Label: F_TABLE_SCHEMA
Attribute_Definition: Esquema da Entidade Acudes
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: Hidrologia
Attribute:
Attribute_Label: F_TABLE_NAME
Attribute_Definition: Nome da Tabela de Acudes no BD
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: ACUDES
Attribute:
Attribute_Label: F_GEOMETRY_COLUMN
Attribute_Definition: Nome da Coluna de Geometria dentro da Tabela de Acudes
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: ACUDES_GM_COL
Attribute:
Attribute_Label: G_TABLE_CATALOG
Attribute_Definition: Catalogo da Tabela de Geometrias de Acudes
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: UFPE
Attribute:
188
Apêndice A – Exemplo de Descrição dos Metadados de Hidrologia pelo FGDC
________________________________________________________________________________________________
Attribute_Label: G_TABLE_SCHEMA
Attribute_Definition: Esquema da Tabela de Geometrias dos Acudes
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: Geometrias
Attribute:
Attribute_Label: G_TABLE_NAME
Attribute_Definition: Nome da tabela de Geometrias dos Acudes
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: GM_ACUDES
Attribute:
Attribute_Label: GEOMETRY_TYPE
Attribute_Definition: Tipo da Geometria Utilizada
Attribute_Definition_Source: none
Attribute_Domain_Values:
Enumerated_Domain:
Enumerated_Domain_Value: INTEGER
Enumerated_Domain_Value_Definition: Numeros inteiros representativos das
geometrias 1=point, 3=linestring, e 5=polygon
Enumerated_Domain_Value_Definition_Source: 1
Attribute:
Attribute_Label: IMAGE_GIF
Attribute_Definition: Nome da imagem que representa a entidade
Attribute_Definition_Source: GIF
Attribute_Domain_Values:
Unrepresentable_Domain: ~/GIFS/ACUDES.GIF
Detailed_Description:
Entity_Type:
Entity_Type_Label: Municipios
Entity_Type_Definition: Entidade Geográfica Municipios do Estado do Rio Grande do
Norte
Entity_Type_Definition_Source: none
Attribute:
Attribute_Label: F_TABLE_CATALOG
Attribute_Definition: Catalogo da Entidade Municipios
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: UFPE
Attribute:
Attribute_Label: F_TABLE_SCHEMA
Attribute_Definition: Esquema da Entidade Municipios
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: Hidrologia
Attribute:
Attribute_Label: F_TABLE_NAME
Attribute_Definition: Nome da Tabela de Municipios no BD
Attribute_Definition_Source: none
189
Apêndice A – Exemplo de Descrição dos Metadados de Hidrologia pelo FGDC
________________________________________________________________________________________________
Attribute_Domain_Values:
Unrepresentable_Domain: MUNICIPIOS
Attribute:
Attribute_Label: F_GEOMETRY_COLUMN
Attribute_Definition: Nome da Coluna de Geometria dentro da Tabela de Municipios
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: MUNICIPIOS_GM_COL
Attribute:
Attribute_Label: G_TABLE_CATALOG
Attribute_Definition: Catalogo da Tabela de Geometrias de Municipios
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: UFPE
Attribute:
Attribute_Label: G_TABLE_SCHEMA
Attribute_Definition: Esquema da Tabela de Geometrias dos Municipios
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: Geometrias
Attribute:
Attribute_Label: G_TABLE_NAME
Attribute_Definition: Nome da tabela de Geometrias dos Municipios
Attribute_Definition_Source: none
Attribute_Domain_Values:
Unrepresentable_Domain: GM_MUNICIPIOS
Attribute:
Attribute_Label: GEOMETRY_TYPE
Attribute_Definition: Tipo da Geometria Utilizada
Attribute_Definition_Source: none
Attribute_Domain_Values:
Enumerated_Domain:
Enumerated_Domain_Value: INTEGER
Enumerated_Domain_Value_Definition: Numeros inteiros representativos das
geometrias 1=point, 3=linestring, e 5=polygon
Enumerated_Domain_Value_Definition_Source: 5
Attribute:
Attribute_Label: IMAGE_GIF
Attribute_Definition: Nome da imagem que representa a entidade
Attribute_Definition_Source: GIF
Attribute_Domain_Values:
Unrepresentable_Domain: ~/GIFS/MUNICIPIOS.GIF
Metadata_Reference_Information:
Metadata_Date: 10012002
Metadata_Contact:
Contact_Information:
Contact_Person_Primary:
Contact_Person: Valeria Goncalves Soares
Contact_Organization: EMPARN/UFPE
190
Apêndice A – Exemplo de Descrição dos Metadados de Hidrologia pelo FGDC
________________________________________________________________________________________________
Contact_Address:
Address_Type: Comercial
Address: Rua Prof. Luis Freire, S/N
City: Recife
State_or_Province: PE
Postal_Code: 51021-550
Country: Brazil
Contact_Voice_Telephone: (81) 3271-8430
Metadata_Standard_Name: FGDC
Metadata_Standard_Version: 2
191
Apêndice B - Definição da Gramática de GeoVisualQL
________________________________________________________________________________________________
APÊNDICE B
DEFINIÇÃO DA G RAMÁTICA DE GEOV ISUALQL
---
Este arquivo consiste da definição da gramática da linguagem de
-- consultas visuais para dados geográficos, GeoVisualQL.
---- DECLARATION SECTION
--- Primeiro, definem-se quais são os símbolos terminais e não terminais da
-- linguagem .
---
Tipos das Geometrias
%terminal ponto
%terminal linha
%terminal polígono
--- Na linguagem, além das representações geométricas das entidades
-- geográficas modeladas, também os operadores espaciais são
-- representados visualmente, e, portanto, fazem parte dos símbolos terminais da
-- linguagem, que constituem uma consulta.
---
Operadores Espaciais Topológicos
-%terminal Equals
%terminal Disjoint
%terminal Touches
%terminal Within
%terminal Overlaps
%terminal Crosses
%terminal Intersects
%terminal Contains
%terminal string
192
Apêndice B - Definição da Gramática de GeoVisualQL
________________________________________________________________________________________________
--- Operadores Espaciais
-%terminal Intersection
%terminal Difference
%terminal Union
de Conjuntos
--- Operadores Lógicos da Linguagem
-%terminal And
%terminal Or
%terminal Not
--- Os símbolos não-terminais são os formadores
--
das sentenças de consultas visuais.
%nonterminal GEOMETRY
%nonterminal LABEL
%nonterminal TOPOLOGIC_OPERATOR
%nonterminal SET_OPERATOR
%nonterminal LOGIC_OPERATOR
%nonterminal STATEMENT
%nonterminal QUERY_CLAUSE
%nonterminal SET_QUERY_CLAUSE
%nonterminal LOGIC_CLAUSE
%nonterminal AND_CLAUSE
%nonterminal AND_OPERATOR
%nonterminal OR_CLAUSE
%nonterminal OR_OPERATOR
%nonterminal NOT_CLAUSE
%nonterminal NOT_OPERATOR
%nonterminal EQUALS-CLAUSE
%nonterminal DISJOINT-CLAUSE
%nonterminal TOUCHES-CLAUSE
%nonterminal WITHIN-CLAUSE
%nonterminal OVERLAPS-CLAUSE
%nonterminal INTERSECTS-CLAUSE
%nonterminal CONTAINS-CLAUSE
%nonterminal CROSSES-CLAUSE
%nonterminal CROTHIN_CLAUSE
%nonterminal CROCHES_CLAUSE
%nonterminal CROSSOUT_CLAUSE
%nonterminal CROSSECTS_CLAUSE
%nonterminal INTERSECTION-CLAUSE
%nonterminal DIFFERENCE-CLAUSE
%nonterminal UNION-CLAUSE
193
Apêndice B - Definição da Gramática de GeoVisualQL
________________________________________________________________________________________________
--
-- Definição do símbolo inicial da linguagem
-%start STATEMENT
--- PRODUCTION SECTION
--- As geometrias a serem utilizadas nesta primeira versão da linguagem
-- GeoVisualQL serão somente as geometrias simples.
-GEOMETRY.type ⇒ ponto | linha| polígono
TOPOLOGIC_OPERATOR ⇒Equals | Disjoint | Touches| Within Overlaps | Crosses |
Intersects | Contains | Crothin | Croches | Crossout |
Crossects
SET_OPERATOR ⇒ Intersection | Difference | Union
LOGIC_OPERATOR ⇒ And | Or | Not
STATEMENT ⇒ QUERY_CLAUSE | SET_QUERY_CLAUSE
QUERY_CLAUSE ⇒EQUALS-CLAUSE| DISJOINT-CLAUSE|TOUCHESCLAUSE |
WITHIN-CLAUSE | OVERLAPS-CLAUSE |
INTERSE CTS-CLAUSE | CONTAINS-CLAUSE | CROSSES-CLAUSE |
CROTHIN_CLAUSE | CROCHES_CLAUSE | CROSSOUT_CLAUSE |
CROSSECTS_CLAUSE | LOGIC_CLAUSE
LOGIC_CLAUSE ⇒ AND_CLAUSE | OR_CLAUSE | NOT_CLAUSE
AND_CLAUSE ⇒ (QUERY_CLAUSE) And (QUERY_CLAUSE)
OR_CLAUSE ⇒ (QUERY_CLAUSE) Or (QUERY_CLAUSE)
NOT_CLAUSE ⇒ Not (QUERY_CLAUSE)
SET_QUERY_CLAUSE ⇒ INTERSECTION_CLAUSE | DIFFERENCE_CLAUSE |
UNION_CLAUSE
LABEL ⇒ string
--- As sentenças de consultas abaixo utilizando operadores topológicos, e foram
-- também descritas no Capítulo 5 dessa tese, onde pôde -se observar suas
-- representações visuais.
--
194
Apêndice B - Definição da Gramática de GeoVisualQL
________________________________________________________________________________________________
EQUALS-CLAUSE→ grouped(GEOMETRY1,Equals, GEOMETRY2)
Where
(GEOMETRY1.type = GEOMETRY2.type)
DISJOINT–CLAUSE→ grouped(GEOMETRY1,Disjoint, GEOMETRY2)
TOUCHES-CLAUSE→ grouped(GEOMETRY1,Touches, GEOMETRY2)
Where
(GEOMETRY1.type = point and GEOMETRY2.type = line) or
(GEOMETRY1.type = point and GEOMETRY2.type = polygon) or
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type = polygon) or
(GEOMETRY1.type = polygon and GEOMETRY2.type = polygon)
WITHIN-CLAUSE→ grouped(GEOMETRY1, Within, GEOMETRY2)
Where
(GEOMETRY1.type = point and GEOMETRY2.type = line) or
(GEOMETRY1.type = point and GEOMETRY2.type = polygon) or
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type = polygon) or
(GEOMETRY1.type = polygon and GEOMETRY2.type = polygon)
OVERLAPS-CLAUSE→ grouped(GEOMETRY1,Overlaps, GEOMETRY2)
Where
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = polygon and GEOMETRY2.type = polygon)
INTERSECTS-CLAUSE→ grouped (GEOMETRY1, Intersects, GEOMETRY2)
CONTAINS-CLAUSE→ grouped (GEOMETRY1, Contains, GEOMETRY2)
Where
(GEOMETRY1.type = point and GEOMETRY2.type = line) or
(GEOMETRY1.type = point and GEOMETRY2.type = polygon) or
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type = polygon) or
(GEOMETRY1.type = polygon and GEOMETRY2.type = polygon)
RELATE-CLAUSE→ grouped (GEOMETRY1, Label, Relates, GEOMETRY2)
CROSSES -CLAUSE⇒grouped(GEOMETRY1,Crosses, GEOMETRY2)
Where
(GEOMETRY1.type = line and GEOMETRY2.type = line) or
(GEOMETRY1.type = line and GEOMETRY2.type = polygon)
CROTHIN-CLAUSE⇒grouped(GEOMETRY1,Crothin,
Where
GEOMETRY2)
GEOMETRY1.type = line and GEOMETRY2.type = polygon
CROCHES-CLAUSE⇒grouped(GEOMETRY1,Croches, GEOMETRY2)
195
Apêndice B - Definição da Gramática de GeoVisualQL
________________________________________________________________________________________________
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
CROSSOUT-CLAUSE ⇒ grouped (GEOMETRY1, Crossout, GEOMETRY2)
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
CROSSECTS-CLAUSE⇒grouped(GEOMETRY1,Crossects,
GEOMETRY2)
Where
GEOMETRY1.type = line and GEOMETRY2.type = polygon
--- Consultas utilizando operadores de conjunto
--
INTERSECTION-CLAUSE ⇒ grouped(GEOMETRY1,Intersection,
GEOMETRY2)
DIFFERENCE-CLAUSE ⇒ grouped(GEOMETRY1,Difference,
GEOMETRY2)
UNION-CLAUSE ⇒ grouped(GEOMETRY1,Union,GEOMETRY2)
196
Apêndice C – Tradução da Linguagem GeoVisualQL
________________________________________________________________________________________________
APÊNDICE C
T RADUÇÃO DA LINGUAGEM GEOV ISUAL QL PARA SQL
---
Para efetivar a tradução da linguagem GeoVisualQL para o padrão SQL
-- escolhido, utilizamos definições feitas na Gramática da Linguagem.
--- Inicialmente apresentamos como modelamos os dados de Hidrologia usando o
modelo OGC
--- TABELAS BÁSICAS OPENGIS
-SPATIAL_REFS_SYS
Esta Tabela armazena os tipos de Sistema de Referência Espacial utilizados.
Nome_Atributo
SRID
AUTH_NAME
Tipo_Atributo
INTEGER NOT NULL PRIMARY
KEY
VARCHAR(256)
AUTH_SRID
INTEGER
SRTEXT
VARCHAR(2048)
Identificador único do
sistema de referencia
Nome do padrão
proprietário
Identificador dado
pelo padrão
Well_known-Text
GEOMETRY_COLUMNS
Esta Tabela armazena os dados de coordenadas da Feição
Nome_atributo
Feature_TABLE_CATALOG
Tipo_atributo
VARCHAR(256) NOT
NULL
Feature_TABLE_SCHEMA
VARCHAR(256) NOT
NULL
Feature_TABLE_NAME
VARCHAR(256) N OT
NULL
Feature_GEOMETRY_COLUMN VARCHAR(256) NOT
NULL
Geometry_TABLE_CATALOG
VARCHAR(256) NOT
NULL
Catálogo da Feição
Schema da Feição
Tabela da Feição
Coluna da Geometria
dentro da tabela
feição
Catálogo da
Geometria
197
Apêndice C – Tradução da Linguagem GeoVisualQL
________________________________________________________________________________________________
Geometry_TABLE_SCHEMA
GEOMETRY_TYPE
VARCHAR(256) NOT
NULL
VARCHAR(256) NOT
NULL
VARCHAR(256) NOT
NULL
INTEGER
COORD_DIMENSION
MAX_PPR
INTEGER NOT NULL
INTEGER
SRID
INTEGER NOT NULL
Geometry_TABLE_NAME
STORAGE_TYPE
Schema da Geometria
Tabela da Geometria
0 = normalizado
1 = binário
1 = point, 3 =
linestring, 5 =
polygon
Número de dimensões
Numero de pontos
max
ID do SR
FEATURE_TABLE
Tabela de Feições. Relacionada com as duas Tabelas anteriores.
Nome_atributo
Feature_ID
Feature_NAME
Feature_attributes …
Geometry_attributes
Tipo_atributo
INTEGER NOT NULL
VARCHAR(256) NOT NULL
Feature_attributes_types…
GID type
GEOMETRY_TABLE
Descreve uma Geometria que está sendo referenciada na Tabela de Feições
Nome_atributo
GID
ESEQ
Tipo_atributo
INTEGER NOT NULL Identificação da Geometria
INTEGER NOT NULL Identificação da Seqüência
ETYPE
INTEGER NOT NULL
SEQ
INTEGER NOT NULL
X1
Y1
…
X<MAX_PPPR>
Y<MAX_PPR>
ATTRIBUTE_NAME
ORDINATE_TYPE
ORDINATE TYPE
…
<ORDINATE_TYPE>
<ORDINATE_TYPE>
ATTRIBUTE_TYPE
de Pontos
1 = point, 2 = linestring, 3
= polygon
Identificação de (outra)
seqüência de pontos
Ponto1 x
Ponto1 y
Ultimo ponto x
Ultimo ponto y
atributo
198
Apêndice C – Tradução da Linguagem GeoVisualQL
________________________________________________________________________________________________
--- TABELAS DA APLICAÇÃO DE HIDROLOGIA DENTRO DO MODELO
OPENGIS
--
GEOMETRY_COLUMNS
F_TBL_CTGF_TBL_SCHF_TBL_NM
F_GM_COL
G_TBL_CTG G_TBL_SCHG_TBL_NM STR_TY GM_TY DIM SRID
Ufpe
Hidrologia
Bacias
Bacias_GM_COL
ufpe
Geometrias GM_Bacias
0
5
2
1
Ufpe
Hidrologia
Acudes
Acudes_GM_COL
ufpe
Geometrias GM_Acudes
0
1
2
1
Ufpe
Hidrologia Municípios Municípios_GM_COL
ufpe
Geometrias GM_Muni
0
5
2
1
BACIAS
BACIAS_FID
BACIAS_NAME
BACIAS_GM_COL
NUM_PTOS
EXTENSÃO
(KM2)
%
01
APODI_MOSSORÓ
0101
02
PIRANHAS_AÇU
0201
03
BOQUEIRÃO
0301
15
NUM_ACUDES
VOL_AGUA
(M3)
-
14276
26,8
618
469.714.600
187
17498,5
32,8
1112
3.503.853.300
250,5
0,5
0
-
GM_BACIAS
GID
ESEQ
ETYPE
SEQ
X
Y
0101
01
3
1
-35.1944
-5.7672
0101
01
3
1
-35.1943
-5.7673
0201
01
3
1
-36.2142
-5.8999
0301
01
3
1
-35.1112
-5.2000
Tabela 1 - Equivalencia de atributos entre as tabelas OpenGIS
Onde os nomes das colunas da GEOMETRY_COLUMNS são equivalentes a:
F_TBL_CTG
= FEATURE_TABLE_CATALOG
F_TBL_SCM
= FEATURE_TABLE_SCHEMA
F_TBL_NM = FEATURE_TABLE_NAME
F_GM_COL = FEATURE_GEOMETRY_COLUMN
G_TBL_CTL = GEOMETRY_TABLE_CATALOG
G_TBL_SCH = GEOMETRY_TABLE_SCHEMA
G_TBL_NM = GEOMETRY_TABLE_NAME
STR_TY
= STORAGE_TYPE
GM_TY
= GEOMETRY_TYPE
DIM
= COORDINATE_DIMENSION
SRID
= SPATIAL_REFERENCE_ID
199
Apêndice C – Tradução da Linguagem GeoVisualQL
________________________________________________________________________________________________
Acudes_FID Acudes_NAME Bacias_FID Municipios_FID Rio_Barrado Capacidade Acudes_GM_COL
001
Boqueirao
001
002
Acu
16.000
010
Tabela 2 - Tabela de Acudes com Exemplo de Instâncias
Municipios_FID Municipios_NAME Bacias_FID Populacao Num_Pontos Municipios_GM_COL
002
Acu
001
14000
134
012
Tabela 3 - Tabela de Municipios com Exemplo de Instâncias
--- Tipos de Operadores usados na Linguagem--OpTopologicoOGC = Equals | Disjoint | Touches | Within | Contains |
Overlaps | Crosses
OpConjuntoOGC = Intersection | Union | Difference
--- TRADUÇÂO DA LINGUAGEM GEOVISUALQL PARA SQL
--- Operadores Topológicos do Open GIS --Select Feicao1.GetGeometry(), Feicao2. GetGeometry()
From Feicao1, Feicao2
Where QUERY_CLAUSE
--- Operadores de Conjuntos do OpenGIS --Select SET_QUERY_CLAUSE
From Feicao1, Feicao2
--- Sentenças de Consultas Complexas com uso de Operadores Lógicos --- LOGIC_CLAUSES --
200
Apêndice C – Tradução da Linguagem GeoVisualQL
________________________________________________________________________________________________
-- Operador de Negação -- Not --Select Feicao1.GetGeometry(), Feicao2. GetGeometry(),...,
FeicaoN. GetGeometry()
From Feicao1, Feicao2,..., FeicaoN
Where NOT (QUERY_CLAUSE)
--- Operador AND --Select Feicao1.GetGeometry(), Feicao2. GetGeometry(), ..., FeicaoN.GetGeometry()
From Feicao1, Feicao2, ..., FeicaoN
Where (QUERY_CLAUSE1)
AND
(QUERY_CLAUSE2)
--- Operador OR --Select Feicao1.GetGeometry(), Feicao2. GetGeometry(), ..., FeicaoN.GetGeometry()
From Feicao1, Feicao2, ..., FeicaoN
Where (QUERY_CLAUSE1)
OR
(QUERY_CLAUSE2)
--- Traducao dos Tipos de Consultas definidos pela Gramática
--- QUERY_CLAUSES
--- Utilizando os operadores de Topologia definidos pelo OGC
-QUERY_CLAUSE = OpTopologicoOGC(Feicao1.GetGeometry(),
Feicao2.GetGeometry()) = 1
-- Utilizando os operadores de Topologia não definidos pelo OGC
---- CROTHIN -QUERY_CLAUSE = Crosses(Feicao1.GetGeometry(), Feicao2.GetGeometry())=1)
and
Within(Feicao1.GetGeometry(), Fe icao2.GetGeometry()) = 1)
201
Apêndice C – Tradução da Linguagem GeoVisualQL
________________________________________________________________________________________________
-- CROCHES -QUERY_CLAUSE = Crosses(Feicao1.GetGeometry(),Feicao2.GetGeometry())=1)
and
Touches(Feicao1.GetGeometry(),Feicao2.GetGeometry())=1)
--- SET_QUERY_CLAUSES --SET_QUERY_CLAUSE = OpConjuntoOGC(Feicao1.GetGeometry(),
Feicao2.GetGeometry())
--- FUNÇÕES AUXILIARES ---- Função Definida para selecionar as coordenadas da geometria da Feição
CREATE FUNCTION GET_GEOMETRY() ON
FEICAO
RETURN string IS gm_ordinates Geometry_Tagged_Text
BEGIN
SELECT AsText (GM_COLUMN)
INTO gm_ordinates FROM Feicao, GM_TABLE
Where Feicao.GM_COLUMN = GM_TABLE.GID;
202
Apêndice D – Descrição do Modelo de Dados no Oracle9i
________________________________________________________________________________________________
APÊNDICE D
DESCRIÇÃO DO MODELO DE DADOS NO ORACLE 9I
--- Scripts de Definições das Tabelas da Aplicação de Hidrologia no SGBD Oracle 9i
---- FEATURE
--
BACIAS
CREATE TABLE BACIAS (
BACIAS_FID
VARCHAR(256) PRIMARY KEY,
NAME
VARCHAR(256) NOT NULL,
BACIAS_NUM_PONTOS
INTEGER,
BACIAS_EXTENSAO
REAL
NOT NULL,
BACIAS_PERCENTAGEM
REAL
NOT NULL,
BACIAS_NUM_ACUDES
INTEGER,
BACIAS_VOL_AGUA
REAL,
GM_SHAPE
MDSYS.SDO_GEOMETRY
);
--- FEATURE
MUNICIPIOS
-CREATE TABLE MUNICIPIOS (
MUNICIPIOS_FID
NAME
BACIAS_FID
MUNICIPIOS_POPULACAO
MUNICIPIOS_NUM_PONTOS
GM_SHAPE
CONSTRAINT
REFERENCES BACIAS(BACIAS_FID)
);
VARCHAR(256)
PRIMARY KEY,
VARCHAR(256)
NOT NULL,
VARCHAR(256),
NUMBER,
INTEGER,
MDSYS.SDO_GEOMETRY,
BACIAS_MUNI FOREIGN KEY(BACIAS_FID)
--- FEATURE ACUDES
-CREATE TABLE ACUDES (
ACUDES_FID
NAME
BACIAS_FID
VARCHAR(256)
VARCHAR(256)
VARCHAR(256),
PRIMARY KEY,
NOT NULL,
203
Apêndice D – Descrição do Modelo de Dados no Oracle9i
________________________________________________________________________________________________
MUNICIPIOS_FID
VARCHAR(256),
ACUDES_RIO_BARRADO
VARCHAR(256),
ACUDES_CAPACIDADE
REAL,
GM_SHAPE
MDSYS.SDO_GEOMETRY,
CONSTRAINT
BACIAS_ACU FOREIGN KEY(BACIAS_FID) REFERENCES
BACIAS(BACIAS_FID),
CONSTRAINT
MUNI_ACU FOREIGN KEY(MUNICIPIOS_FID)
REFERENCES MUNICIPIOS(MUNICIPIOS_FID)
);
--
-- DEFINICOES DE METADADOS ORACLE
-INSERT INTO USER_SDO_GEOM_METADATA
VALUES(
'BACIAS',
'GM_SHAPE',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', 0, 300, 0.00000005),
MDSYS.SDO_DIM_ELEMENT('Y', 0, 300, 0.00000005)
),
NULL
);
INSERT INTO USER_SDO_GEOM_METADATA
VALUES(
'ACUDES',
'GM_SHAPE',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', 0, 1, 0.00000005),
MDSYS.SDO_DIM_ELEMENT('Y', 0, 1, 0.00000005)
),
NULL
);
INSERT INTO USER_SDO_GEOM_METADATA
VALUES(
'MUNICIPIOS',
'GM_SHAPE',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', 0, 50, 0.00000005),
MDSYS.SDO_DIM_ELEMENT('Y', 0, 50, 0.00000005)
),
NULL
);
----
DEFINIÇÕES DOS ÍNDICES ESPACIAIS
CREATE INDEX BACIAS_SPATIAL_IDX
ON BACIAS(GM_SHAPE)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
204
Apêndice D – Descrição do Modelo de Dados no Oracle9i
________________________________________________________________________________________________
CREATE INDEX MUNICIPIOS_SPATIAL_IDX
ON MUNICIPIOS(GM_SHAPE)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX ACUDES_SPATIAL_IDX
ON ACUDES(GM_SHAPE)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
205
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
APÊNDICE E
DESCRIÇÃO DAS FEIÇÕES G EOGRÁFICAS DE H IDROLOGIA EM
XML
--- Descrição da Feição Bacia Hidrográfica, utilizando o SGBD Oracle 9i
-<?xml version="1.0" encoding="ISO-8859- 1" ?>
- <metadata>
- <idinfo>
- <citation>
- <citeinfo>
<origin>Valéria Goncalves Soares </origin>
<pubdate>01012002 </pubdate>
<title >Bacias Hidrográficas do Estado do Rio Grande
do Norte</title >
</citeinfo>
</citation >
- <descript >
<abstract>Esta Tabela de Bacias contém informações
sobre as Bacias Hidrográficas do Estado do RN,
contendo informacoes sobre a sua extensao, entre
outros.</abstract>
<purpose>Estes dados de Bacias tem como objetiv o
descrever as tabelas de bacias, bem como seus
atributos.</purpose>
</descript >
- <timeperd>
- <timeinfo>
- <sngdate>
<c aldate>01152002</caldate>
</sngdate>
</timeinfo >
<current>Publication Date</current >
</timeperd>
- <status>
<progress >in work</progress>
<update>Daily </update>
</status>
- <spdom>
- <bounding>
206
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
<westbc >12</westbc >
<eastbc >13</eastbc>
<northbc >14</northbc >
<southbc >15</southbc >
</bounding>
</spdom>
- <keywords >
- <theme >
<themekt >none</themekt >
<themekey>Bacias Hidrograficas</themekey >
</theme >
</keywords>
<accconst >none</accconst >
<useconst >none </useconst >
</idinfo>
- <eainfo>
- <detailed>
- <enttyp >
<enttypl>Bacias </enttypl>
<enttypd>Entidade Geográfica Bacias Hidrograficas do
Estado do RN e seus atributos </enttypd >
<enttypds>none </enttypds>
</enttyp>
- <attr >
<attrlabl>BACIAS_FID</attrlabl>
<attrdef >Identificacao da Instancia de
Bacias</attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>PRIMARY KEY</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>NAME</attrlabl>
<attrdef >Nome da Instancia de Bacias </attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>NOT NULL</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>BACIAS_NUM_PONTOS</attrlabl>
<attrdef >Numero de pontos total que delimita a
instancia bacia </attrdef>
<attrdefs>INTEGER</attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
207
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
- <attr >
<attrlabl>BACIAS_EXTENSAO </attrlabl>
<attrdef >Extensao em Km2 da Instancia de
bacia </attrdef >
<attrdefs>REAL</attrdefs >
- <attrdomv >
<udom>NOT NULL</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>BACIAS_PERCENTAGEM</attrlabl>
<attrdef >Porcentagem de Ocupacaçao do territorio
estadual pela instancia de Bacia </attrdef >
<attrdefs>REAL</attrdefs >
- <attrdomv >
<udom>NOT NULL</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>BACIAS_NUM_ACUDES</attrlabl>
<attrdef >Numero de Acudes Cadastrados na Instancia
de Bacia</attrdef>
<attrdefs>INTEGER</attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>BACIAS_VOL_AGUA </attrlabl>
<attrdef >Volume de Agua Total da Instancia de
Bacia </attrdef >
<attrdefs>REAL</attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GEOMETRY_TYPE </attrlabl>
<attrdef >Tipo da Geometria associada as bacias.
1=ponto, 2=linha e 3=poligono. </attrdef >
<attrdefs>INTEGER</attrdefs >
- <attrdomv >
<udom>3</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>IMAGE_GIF </attrlabl>
<attrdef >Nome do Arquivo que Representa a
Entidade </attrdef >
<attrdefs>GIF </attrdefs >
208
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
- <attrdomv >
<udom>~GeoVisual/GIFS/Bacia.GIF </udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GM_SHAPE </attrlabl>
<attrdef >Tipo Geometria implementado no Oracle
9i</attrdef >
<attrdefs>MDSYS.SDO_GEOMETRY </attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
</detailed>
</eainfo>
- <metainfo >
<metd>01012002</ metd>
- <metc>
- <cntinfo >
- <cntperp >
<cntper>Valeria Goncalves Soares</cntper>
<c ntorg >EMPARN/UFPE </cntorg >
</cntperp >
- <cntaddr>
<addrtype >Comercial</addrtype >
<address>Rua Prof. Luis Freire, S/N</address>
<city>Recife</city >
<state>PE </state>
<postal>51021-550</postal>
<country>Brazil </country >
</cntaddr>
<cntvoice>(81) 3271-8430</cntvoice>
</cntinfo>
</metc>
<metstdn >FGDC</ metstdn>
<metstdv>FGDC-STD-001-1998</ metstdv>
</ metainfo>
</metadata>
--- Descrição
--
da Feição Municípios, utilizando o SGBD Oracle 9i
<?xml version="1.0" encoding="ISO-8859- 1" ?>
- <metadata>
- <idinfo>
- <citation>
- <citeinfo>
<origin>Valéria Goncalves Soares </origin>
209
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
<pubdate>01012002 </pubdate>
<title >Municipios do Estado do Rio Grande do
Norte</title >
</citeinfo>
</citation >
- <descript >
<abstract>Esta Tabela de Bacias contém informações
sobre os Municipios do Estado do Rio grande do Norte e
seus atributos. </abstract>
<purpose>Estes dados de municipios tem como objetivo
descrever as tabelas de municipios,bem como seus
atributos.</purpose>
</descript >
- <timeperd>
- <timeinfo>
- <sngdate>
<caldate>01152002</caldate>
</sngdate>
</timeinfo >
<current>Publication Date</current >
</timeperd>
- <status>
<progress >in work</progress>
<update>Daily </update>
</status>
- <spdom>
- <bounding>
<westbc >12</westbc >
<eastbc >13</eastbc>
<northbc >14</northbc >
<southbc >15</southbc >
</bounding>
</spdom>
- <keywords>
- <theme >
<themekt >none</themekt >
<themekey>Municipios</themekey >
</theme >
</keywords>
<accconst >none</accconst >
<useconst >none </useconst >
</idinfo>
- <eainfo>
- <detailed>
- <enttyp >
<enttypl>Municipios</enttypl>
<enttypd>Entidade Geográfica Municipios do Estado
do RN e seus atributos</enttypd >
<enttypds>none </enttypds>
</enttyp>
210
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
- <attr>
<attrlabl>MUNICIPIOS_FID</attrlabl>
<attrdef >Identificacao da Instancia de
Municipio </attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>PRIMARY KEY</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>NAME</attrlabl>
<attrdef >Nome da Instancia de Municipio</attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>NOT NULL</udom>
</attrdomv>
</attr>
- <attr >
<attrlabl>BACIAS_FID</attrlabl>
<attrdef >Bacia hidrografica em que
preferencialmente, se localiza. </attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>FOREIGN KEY</ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>MUNICIPIOS_POPULACAO</attrlabl>
<attrdef >Populacao Total do Municipio.</attrdef >
<attrdefs>NUMBER</attrdefs>
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>MUNICIPIOS_NUM_PONTOS </attrlabl>
<attrdef >Numero de pontos que delimitam a instancia
do municip io. </attrdef >
<attrdefs>INTEGER</attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GEOMETRY_TYPE </attrlabl>
<attrdef >Tipo da Geometria associada aos municipios.
1=ponto, 2=linha e 3=poligono. </attrdef >
<attrdefs>INTEGER</attrdefs >
- <attrdomv >
211
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
<udom>3</udom>
</attrdomv >
</attr>
- <attr>
<attrlabl>IMAGE_GIF </attrlabl>
<attrdef >Nome do Arquivo que Representa a
Entidade </attrdef >
<attrdefs>GIF </attrdefs >
- <attrdomv >
<udom>~GeoVisual/GIFS/Municipios.GIF
</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GM_SHAPE </attrlabl>
<attrdef >Tipo Geometria do Oracle 9i</attrdef >
<attrdefs>MDSYS.SDO_GEOMETRY </attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
</detailed>
</eainfo>
- <metainfo >
<metd>01012002</ metd>
- <metc>
- <cntinfo >
- <cntperp >
<cntper>Valeria Goncalves Soares</cntper>
<cntorg >EMPARN/UFPE </cntorg >
</cntperp >
- <cntaddr>
<addrtype >Comercial</addrtype >
<address>Rua Prof. Luis Freire, S/N</address>
<city>Recife</city >
<state>PE </state>
<postal>51021-550</postal>
<country>Brazil </country >
</cntaddr>
<cntvoice>(81) 3271-8430</cntvoice>
</cntinfo>
</metc>
<metstdn >FGDC</ metstdn>
<metstdv>FGDC-STD-001-1998</ metstdv>
</ metainfo>
</metadata>
-212
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
-- Descrição da Feição Açudes, utilizando o SGBD Oracle 9i
-<?xml version="1.0" encoding="ISO-8859- 1" ?>
- <metadata>
- <idinfo>
- <citation>
- <citeinfo>
<origin>Valéria Goncalves Soares </origin>
<pubdate>01012002 </pubdate>
<title >Acudes do Estado do Rio Grande do
Norte</title >
</citeinfo>
</citation >
- <descript >
<abstract>Esta Tabela de Acudes contém informações
sobre os Acudes cadastrados dentro das bacias
hidrograficas do Estado. </abstract>
<purpose>Estes dados de Acudes tem como objetivo
descrever as tabelas de acudes bem como seus
atributos.</purpose>
</descript >
- <timeperd>
- <timeinfo>
- <sngdate>
<caldate>01152002</caldate>
</sngdate>
</timeinfo >
<current>Publication Date</current >
</timeperd>
- <status>
<progress >in work</progress>
<update>Daily </update>
</status>
- <spdom>
- <bounding>
<westbc >12</westbc >
<eastbc >13</eastbc>
<northbc >14</northbc >
<southbc >15</southbc >
</bounding>
</spdom>
- <keywords>
- <theme >
<themekt >none</themekt >
<themekey>Acudes</themekey>
</theme >
</keywords>
<accconst >none</accconst >
<useconst >none </useconst >
213
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
</idinfo>
- <eainfo >
- <detailed>
- <enttyp >
<enttypl>Acudes </enttypl>
<enttypd>Entidade Geográfica Acudes do Estado do
RN e seus atributos </enttypd>
<enttypds>none </enttypds>
</enttyp>
- <attr >
<attrlabl>ACUDES_FID</attrlabl>
<attrdef >Identificacao da Instancia de
Acudes</attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>PRIMARY KEY</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>NAME</attrlabl>
<attrdef >Nome da Instancia de Acude </attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>NOT NULL</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>BACIAS_FID</attrlabl>
<attrdef >Identificacao da bacia a que o acude
pertence.</attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>FOREIGN KEY</ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>MUNICIPIOS_FID</attrlabl>
<attrdef >Identificacao do Municipio a que o acude se
localiza. </attrdef>
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
<udom>FOREIGN KEY</ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>ACUDES_RIO_BARRADO </attrlabl>
<attrdef >Nome do Rio barrado que deu origem ao
acude.</attrdef >
<attrdefs>VARCHAR(256)</attrdefs >
- <attrdomv >
214
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
<udom>none </ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>ACUDES_CAPACIDADE</attrlabl>
<attrdef >Capacidade Total de armazenamento de agua
do acude.</attrdef >
<attrdefs>REAL</attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GEOMETRY_TYPE </attrlabl>
<attrdef >Tipo da Geometria que representa um acude.
1=ponto, 2=linha e 3=poligono</attrdef >
<attrdefs>INTEGER</attrdefs >
- <attrdomv >
<udom>1</udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>IMAGE_GIF </attrlabl>
<attrdef >Nome do Arquivo que Representa a
Entidade </attrdef >
<attrdefs>GIF </attrdefs >
- <attrdomv >
<udom>~GeoVisual/GIFS/Acude.GIF </udom>
</attrdomv >
</attr>
- <attr >
<attrlabl>GM_SHAPE </attrlabl>
<attrdef >Tipo Geometria do Oracle 9i</attrdef >
<attrdefs>MDSYS.SDO_GEOMETRY </attrdefs >
- <attrdomv >
<udom>none </ udom>
</attrdomv >
</attr>
</detailed>
</eainfo>
- <metainfo >
<metd>01012002</ metd>
- <metc>
- <cntinfo >
- <cntperp >
<cntper>Valeria Goncalves Soares</cntper>
<cntorg >EMPARN/UFPE </cntorg >
</cntperp >
- <cntaddr>
215
Apêndice E – Descrição das Feições Geográficas de Hidrologia em XML
________________________________________________________________________________________________
<addrtype >Comercial</addrtype >
<address>Rua Prof. Luis Freire, S/N</address>
<city>Recife</city >
<state>PE </state>
<postal>51021-550</postal>
<country>Brazil </country >
</cntaddr>
<cntvoice>(81) 3271-8430</cntvoice>
</cntinfo>
</metc>
<metstdn >FGDC</ metstdn>
<metstdv>FGDC-STD-001-1998</ metstdv>
</ metainfo>
</metadata>
216
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
REFERÊNCIAS BIBLIOGRÁFICAS
[ACK+98] M. Ashworth, P. Cotton, H. Kucera and D. O’Brien. Comparison of Spatial Schema in
ISO/TC211, OGC, and SQL/MM. 7th ISO/TC211/WG2 Meeting – Harmonization of Spatial
Schemas and Operators, June 1998.
[AG97] N. R. Adam and A. Gangopadhyay. Database Issues in Geographic Information Systems.
Kluwer Academic Publishers. 1997.
[ATM02] ASCII Template for Metadata. Último acesso em 2002.
http://geology.usgs.gov/tools/metadata/tools/doc/template
[Aus00] Australian Spatial Data Infrastructure. Acessado em 2000.
http://www.csdc.gov.au/asdi/fmeta.htm
[BAT00] C. Bonhomme, M. A. Aufaure-Portier , C. Trepied: Metaphors for Visual Querying
Spatio-Temporal Databases. In: Advances in Visual Information Systems , edited by R.
Laurini, Proceedings of the 4th International Conference on Visual Information Systems.
Springer Verlag, Lecture Notes in Computer Science, pp. 140-153, 2000. http://wwwrocq.inria.fr/~aufaure/Visual2000.pdf
[BCC +91] C. Batini, T. Catarci, M. F. Costabile, S. Levialdi. Visual Query Systems: A taxonomy.
Proc. of the 2nd IFIP W.G. 2.6 Working Conference on Visual Databases, 1991.
ftp://ftp.dis.uniroma1.it/pub/catarci/VQSTaxonomy.ps.gz
[BCL+95] P. Bottoni, M. F. Costabile, S. Levialdi and P. Mussio. Formalising Visual Languages.
IEEE, 1995.
[BD00] K. Borges and C. Davis. Modelagem de Dados Geográficos. In Geoprocessamento: Teoria
e Aplicações. Livro on-line, acessado em 2000. http://www.dpi.inpe.br/gilberto/livro/
[BE00] A. D. Blaser and M. J. Egenhofer. A Visual Tool for Querying Geographic Databases. Proc.
of Advanced Visual Interfaces – AVI2000, Palermo, Italy, May, 2000.
[Bed99] Y. Bédard. Visual modeling of spatial databases: towards spatial PVL and UML.
Geomatica, June, 1999.
217
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[BF94] P. A. Burrough and A. U. Frank. Concepts and Paradigms in Spatial Information: Are
Current Geographic Information Systems Truly Generic? In IJGIS, pp 101–116, July 1994.
[BG99] D. Balfanz and S. Göbel. Bridging GeoSpatial Metadata Standards towards Distributed
Metadata Information Systems. The Third IEEE Meta-Data Conference, April, 1999.
http://computer.org/conferen/proceed/meta/1999/papers/40/dbalfanz.html
[Bla02] A. Blaser. General Concept. Why using a Sketch for Input Generation?. Último Acesso em
2002. http://www.spatial.maine.edu/~abl/SQBS/Concept.htm
[BM92] P. Boursier and M. Mainguenaud. Spatial Query Language: Extended SQL vs. Visual
Languages vs. Hypermaps. Proceedings of the 5th International Symposium on Spatial Data
Hanling, Charleston, USA, August 1992.
[BM95] A. Brossier-Wansek and M. Mainguenaud. Manipulations of Graphs with a Visual Query
Language: Application to a Geographical Information System. Visual Database Systems –
VDB3, Suíça, Março, 1995.
[BM98] P. Burrough and R. McDonnell. Principles of Geographical Information Systems. Oxford
University Press. 1998.
[Bog99] V. Bogorny. Um Estudo sobre o OpenGIS:A Proposta da OGC para Interoperabilidade e
Distribuição em Sistemas de Informação Geográfica. TI – 865 PPGC – UFRGS. Porto
Alegre - RS. 1999.
[Bor97] K. Borges. Modelagem de dados geográficos – uma extensão do modelo OMT para
aplicações geográficas. Dissertação de Mestrado. UFMG. Belo Horizonte. 1997.
[BRJ00] G. Booch, J. Rumbaugh and I. Jacobson. The Complete UML Training Course. Prentice
Hall. June, 2000.
[BTAL99] C. Bonhomme, C. Trépid, Marie -Aude-Aufaure and R. Laurini. A Visual Language for
Querying Spatio-Temporal Databases. In Proceedings of ACM GIS, November, Kansas
City, USA, 1999.
[Cam+00] G. Câmara et. al. Geoprocessamento: Teoria e Aplicações. Livro on-line, acessado em
2000. http://www.dpi.inpe.br/gilberto/livro/
[Cam95] G. Câmara. Modelos, Linguagens e Arquiteturas para Bancos de Dados Geográficos.
Tese de Doutorado. INPE. 1995.
218
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Cat+97] T. Catarci, et.al. Visual Query Systems for Databases: Analysis and Comparison - Journal
of Visual Languages and Computing, Vol. 8, N. 2, pp. 215-260, June 1997..
ftp://ftp.dis.uniroma1.it/pub/catarci/VQSJVLC.ps.gz
[Cat91a] T. Catarci. Visual Strategies for Querying Databases. Proc. of the IEEE Int. Workshop on
Visual Languages, Japan, October 1991. ftp://ftp.dis.uniroma1.it/pub/catarci/
VisualStrat.ps.gz
[Cat91b] T. Catarci. On The Expressive Power of Graphical Query Languages. Proc. of the W.G.
2.6 Working Conference on Visual Databases, Budapest, 1991. ftp://ftp.dis.uniroma1.it/
pub/catarci/ExPower.ps
[CCF +96] G. Câmara, M. Casanova, U. M. Freitas, J.P.C. Cordeiro, L. Hara. A Presentation
Language for GIS Cadastral Data. Proceeding of the Fourth ACM Workshop on Advances
in Geographic Information Systems, pp 139-146, November, 1996.
[CCH+96] G. Câmara, M. Casanova, A. Hemerly, G. Magalhães, e C. Medeiros. Anatomia de
Sistemas de Informação Geográfica. Décima Escola de Computação, Julh o, 1996.
[CEN99] Objectives and Principles of CEN. European Committee for Standardization.
http://www.cenorm.be/aboutcen/whatis/objectives.htm
[CF94] E. Clementini and P. Felice. Object-Oriented Modeling of Geographic Data. Journal of the
American Society for Information Science, pp. 694-704, 1994.
[Che76] P. Chen. The entity-Relationship model – toward a unified view of data. ACM Transactions
on Database Systems, v.1, p.9-36, 1976.
[CHY97] S. K. Chang, W. Hua and C. W. Yoo. Visual Abstraction in The Visual Design Process.
Department of Computer Science, University of Pittsburgh, Technical Report TR 97-02,
February 1997.
[CM91] D. Calcinelli, M. Mainguenaud. The Management of the Ambiguities in a Graphical
Query Language for Geographical Information System. 2nd Large Spatial Database
Symposium (SSD91), Zurich, Switzerland, pp. 99-118. August 1991.
[CM94] D. Calcinelli, M. Mainguenaud. Cigales: A Visual Query Language for Geographical
Information System: The User Interface. International Journal of Visual Languages and
Computing, Academic Press, 1994, Vol 5, pp 113-132.
[CM95] C. Claramunt and M. Mainguenaud. Dynamic and Flexible Vision of a Spatial Database.
DEXA 95 Workshop, London , United Kingdom, Setembro, 1995.
219
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Cor02] S. S. Cortez. Tradução de Consultas Visuais para Cláusulas SQL. Trabalho Final de
Graduação. Universidade Federal de Pernambuco. Setembro 2002.
[Cru93] I. F. Cruz. User-Defined Visual Languages for Querying Data. Department of Computer
Science. Brown University. Technical Report CS-93-58. December 1993.
[Dav00] C. Davis Jr. Múltiplas Representações em Sistemas de Informação Geográficos. Tese de
Doutorado. UFMG. 2000.
[Dav01]
C.
Davis
Jr.
Topologia .
Capítulo
de
livro
acessado
em
2001.
http://www.cdavis.hpg.ig.com.br/publicacoes.html
[DeM97] M. N. DeMers. Fundamentals of Geographic Information Systems. John Wiley & Sons,
1997.
[DL99] C. Davis Jr e A. Laender. Múltiplas Representações em Aplicações Urbanas de Sistemas de
Informação Geográficos. In Anais do I Workshop Brasileiro de GeoInformática, 35-39,
Campinas, 1999. http://www.cdavis.hpg.ig.com.br/publicacoes.html
[Dub01] Dublin Core Metadata Intiative.Acessado em 2001. http://purl.org/dc/index.html
[EF88] M. J. Egenhofer and A. Frank. Towards a Spatial Query Language: User Interface
Considerations. In Proceedings of the 14 th VLDB Conference, Los Angeles, California,
1988.
[EF90] M. J. Egenhofer and A. Frank. LOBSTER: Combinig AI and Database Techniques for GIS.
Photogrammetric Engineering and Remote Sensing, Vol. 56, No. 6, pp. 919-926, June
1990.
[Ege92] M. J. Egenhofer. Why not SQL! Int. Journal Geographical Information Systems, Vol. 6, No.
2, pp 71-85, 1992.
[Ege94] M. J. Egenhofer. Spatial SQL: A Query and Presentaion Language. IEEE Transactions on
Knowledge and Data Engineering, Vol. 6, No. 1, February, 1994.
[Ege96] M. J. Egenhofer. Spatial-Query-by-Skecth. VL96, IEEE Symposium on Visual Languages,
Boulder, CO, IEEE Press, pp. 60-67, 1996.
[Ege97] M. J. Egenhofer. Query Processing in Spatial-Query-by-Sketch. Journal of Visual
Languages and Computing, Vol. 8, No. 4, pp. 403-424, 1997.
220
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[EH91] M. J. Egenhofer and J. Herring. Categorizing Binary Topological Relations Between
Regions, Lines, and Points in Geographic Databases. Technical Report, University of
Maine, Orono, 1991.
[EM95] M. J. Egenhofer and D. Mark. Modeling Conceptual Neighborhoods of Topological LineRegion Relations. International Journal of Geographical Information Systems, pp. 555-565,
1995.
[ESM98] European Spatial Metadata Infrastructure. Acessado em 1998. http://www.esmi.org
[FA00] F. Favetta and M. A. Aufaure-Portier. About Ambiguities in Visual GIS Query Languages: a
Taxonomy and Solutions. In: Advances in Visual Information Systems, edited by R.
Laurini, Proceedings of the 4th International Conference on Visual Information Systems.
Springer Verlag, Lecture Notes in Computer Science, pp. 154-165, 2000. http://wwwrocq.inria.fr/~aufaure/Visual'2000b.pdf
[FC92] P. di Felice and E. Clementini. Towards a Standard for SQL-Based Spatial Query
Languages. In Proceedings of ACM/SGAPP Symposium on Appllied Computing pp. 184189, Kansas City, Missouri, March, 1992.
[Fer00] Fernandes, D. Y. GeoVisual Interface – Uma Interface para Consultas Visuais em Bancos
de Dados Geográficos. Dissertação de Mestrado. UFPE – Brasil. Março, 2000.
[FGD99] Federal Geographic Data Committee Standards Reference Model. Federal Geographic
Data Committee. http://www.fgdc.gov/
[Fra82] A. Frank. MAPQUERY: Data Base Query Language for Retrieval of geometric Data and
Their Graphical Representation. ACM Computer Graphics, Vol. 16, No. 3, July, 1982.
[GC96] J. M. Gooday and A. G. Cohn. Visual Language Syntax and Semantics: A Spatial Logic
Approach. Division of Artificial Language. University of Leeds, England, 1996.
[GE00] R. K. Goyal and M. J. Egenhofer. Consistent Queries over Cardinal Directions across
Different Levels of Detail. In 11th International Workshop on Database and Expert Systems
Applications (DEXA), September, 2000. London.
[GE01] R. K. Goyal and M. J. Egenhofer. Similarity of Cardinal Directions. In Seventh
International Symposium on Spatial and Temporal Databases. Lecturer Notes in Computer
Science, Vol. 2121, Springer Verlag, pp. 36-55, July 2001.
[Geo02] Intergraph Announces New GeoMedia 5.0 Procuct Suite. Acessada em Agosto 2002.
http://www.intergraph.com/gis/newsroom/press02/gm5_rlsf.asp
221
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[GIS02] What is GIS. Acessada em Setembro 2002. http://www.gis.com/whatisgis/index.html
[GM93] E. J. Golin and T. Magliery. A Compiler Generator for Visual Languages. IEEE, 1993.
[GML02] Geography Markup Language (GML) 2.0. OpenGIS Implementation Specification,
Acessado em 2002. http://opengis.net/gml/01-029/GML2.html
[Gol91] E. J. Golin. A Method for the Specification and Parsing of Visual Languages. PhD
Dissertation, Brown University, Technical Report No. CS-90-19, May, 1991.
[GR89a] E. J. Golin and S. P. Reiss. Parsing in a Visual Language Environment. Brown University,
Technical Report No. CS-89-06, February 1989.
[GR89b] E. J. Golin and S. P. Reiss. Representing Visual Programas with Object-Graphs. Brown
University, Technical Report No. CS-89-05, February, 1989.
[GR90] E.J. Golin and S. P. Reiss. The Specification of Visual Language Syntax. Journal of Visual
Languages and Computing, Vol. 1, No.2, pp. 141-157, 1990.
[Gut88] R. H. Güting. Geo-Relational Algebra: A Model and Query Language for Geometric
Database Systems. Proc. of the Intl. Conf. on Extending Database Technology, Venice,
March, 1988.
[Gut94] R. H. Güting. An Introduction to Spatial Database Systems. Special Issue on Spatial
Database Systems of the VLDB Journal ,Vol. 3, No. 4, October 1994.
[Gut99] R. H. Güting. Spatial Database Systems - Tutorial Notes. Acessado em 1999.
http://www.informatik.fernuni-hagen.de/import/pi4/gueting/home.html
[Haa95] V. Haarslev. Formal Semantics of Visual Languages Using Spatial Reasoning. IEEE,
1995.
[HE00] K. Hornsby and M. J. Egenhofer. “Identity-Based Change: A Foundation for SpatioTemporal Knowledge Representation.” International Journal of Geographical Information
Science 14(3): 207-224, 2000.
[HE99] K. Hornsby and M. J. Egenhofer. Shift in Detail Through Temporal Zoomig. Tenth
International Workshop on Database and Expert Systems Applications. Florence, Italy,
IEEE Computer Society, pp. 487-491, 1999.
[HGW99] How GIS Works. http://www.esri.com/library/gis/abtgis/gis_wrk.html
222
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[HMW00] V. Haarslev, R. Möller and M. Wessel. Visual Spatial Query Languages: A Semantics
Using Description Logic. In P. Olivier, M. Anderson and B. Meyer (editors). Diagrammatic
Representation and Reasoning. Spring-Verlag, London, 2000.
[HP98] D. Hart, H. Phillips. Metadata Primer – A “How To” Guide on Metadata Implementation.
National
States
Geographic
Information
Council.
http://www.lic.wisc.edu/metadata/metaprim.htm
[HS93] Z. Huang and P. Svensson. Neighborhood Query and Analysis with GeoSAL, a Spatial
Database Language. Advances in Spatial Databases. In Proceedings of The 3rd International
Symposium, SSD 93, Singapore, June 1993.
[HMW00] V. Haarslev, R. Möller and M. Wessel. Visual Spatial Query Languages: A Semantics
Using Description Logic. Diagrammatic Representation and Reasoning. Springer-Verlag,
London, 2000.
[HSW75] G. D. Held, M. R. Stonebraker e E. Wong. INGRES: A Relational Database Management
System. Proc. AFIPS National Comp. Conf. 1975.
[HT97] T. Hadzilacos and N. Tryfona. An Extended Entity-Relationship Model for Geographic
Applications, SIGMOD Record 26(3): 24-29(1997)
[HU79] J. E. Hopcroft and J. D. Ullman. Introduction to Automata Theory Languages and
Computation. Addison-Wesley, Reading, 1979.
[HW97] V. Haarslev and M. Wessel. Querying GIS with Animated Spatial Sketches. Proceedings
IEEE Symposium on Visual Languages, Capri, Italy, IEEE Computer Society Press, pp.
197-204, 1997.
[ISO99] ISO/TC 211 - Geographic information/Geomatics. International Organization for
Standardization Technical Committee 211. December 1999. http://www.statkart.no/
isotc211/
[ISO00] ISO/IEC JTC 1/SC 32/WG4 SQL/MM – SQL Multimedia and Application Packages
(SQL/MM) – Part 3: Spatial. International Organization for Standardization. October, 31.
2000.
[Jun96] V. Jung. Fuzzy Effectiveness Evaluation for Intelligent User Interfaces to GIS
Visualization. Proceeding of the Fourth ACM Workshop on Advances in Geographic
Information Systems, pp 155-162, November, 1996.
223
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[KPS97] G. Kösters; B. Pagel, B. U.; H. W. Six. GIS - Application development with GeoOOA.
International Journal of Geographical Information Science, v.11, n.4, 1997.
[KR98A ] S. K AUSHIK AND E. RUNDENSTEINER. D IRECT-MANIPULATION S PATIAL EXPLORATION
USING SVIQUEL. VDB4: 4TH INTERNATIONAL CONFERENCE ON VISUAL
DATABASE SYSTEMS, L'AQUILA , ITALY, MAY 27-29,1998.
[KR98b] S. Kaushik and E. Rundensteiner. SVIQUEL: A Spatial Visual Query Language and
Exploration Language. In Conference and Workshop on Database and Expert Systems
Applications (DEXA'98), Vienna, Austria, pp 290--299, August 1998.
[Kuh95] W. Kuhn. 7 ± 2 Questions and Answers About Metaphors for GIS User Interfaces. In
Cognitive Aspects of Human-Computer Interaction for Geographic Information Systems.
(Nyerges, T.L., et al., eds.), Series D: Behavioural and Social Sciences, Vol. 83, Dordrecht,
The
Netherlands,
Kluwer
Academic
Publishers,
pp:
113-122
(1995).
http://citeseer.nj.nec.com/kuhn95question.html
[Lak02] G. Lakoff. Table of Contents for: Lakoff on Conceptual Metaphor. Acessada em Setembro
2002. http://www.ac.wwu.edu/~market/semiotic/metaphor_toc.html
[LIH+02] J. Lisboa F., C. Iochpe, H. Hhasenack, E. J. Weber. Modelagem Conceitual de Bancos de
Dados Geográficos: o estudo de caso do Projeto PADCT/CIAMB. Acessado em
Setembro/2002. http://delmonio.ecologia.ufrgs.br/idrisi/artigos/jugurta.pdf
[Lim02] P. Lima. “GeoBR: Intercâmbio Sintático e Semântico de Dados Geográficos”, Dissertação
de Mestrado, INPE, 2002, disponível em. http://www.dpi.inpe.br/teses/lima
[Lis97] J. Lisboa F. Modelos Conceituais de Dados para Sistemas de Informações Geográficas.
Exame de Qualificação. UFRGS, Abril, 1997.
[Lis00] J. Lisboa F. Projeto Conceitual de Banco de Dados Geográficos através da Reutilização de
Esquemas, utilizando Padrões de Análise e um Framework Conceitual. Tese de Doutorado.
UFRGS, Janeiro, 2000.
[Mai92] M. Mainguenaud. What is Happening After the Definition of an End-User Query? 3rd
European Geographical Information System Conference, Munich, Alemanha, Março, 1992.
[Mai93a] M. Mainguenaud. The Results of Geographic Information Systems Queries. IEEE/CS
Visual Languages 93, Bergen, Norway, Agosto, 1993.
224
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Mai93b] M. Mainguenaud. From the User Interface to the Database Management System:
Application to a Geographical Information System. 5th International Conference on Human
Computer Interaction, Orlando, USA, Agosto, 1993.
[Mai94] M. Mainguenaud. Consistency of Spatial Database Query Results. Computer, Environment
and Urban Systems, Pergamon Press, Vol. 18, pp. 333-342,1994.
[Mey92a] B. Meyer. Beyond Icons. Towards New Metaphors for Visual Query Languages for
Spatial Information Systems. Interfaces to Database Systems, R. Cooper (Ed.), Springer,
1992. http://welcome.to/bernd.meyer/
[Mey92b] B. Meyer. Pictures Depicting Pictures – On the Specification of Visual Languages by
Visual Grammars. Proceedings of the International IEEE Workshop on Visual Languages,
Seattle/WA, September, 1992.
[Mey93] B. Meyer. Logic and Structure of Space – Towards a Visual Logic for Spatial Reasoning.
Proceedings of the International Symposium on Logic Programming,
D. Miller (Hrsg.), Vancouver, Canada, October 1993.
[Mey94] B. Meyer. Pictorial Deduction in Spatial Information Systems. Proceedings of the 10th
International IEEE Workshop on Visual Languages, St. Louis/MO, October 1994.
[ME94] D. Mark and M. Egenhofer. Modeling Spatial Relations Between Lines and Regions:
Combining Formal Mathematical Models and Human Subjects Testing. Cartography and
Geographical Information Systems, pp. 196-212. 1994.
[MM96a] K. Marriot and B. Meyer. Formal Classification of Visual Languages. International
Workshop on Theory of Visual Languages, Gubbio, Italy, May 1996.
[MM96b] K. Marriot and B. Meyer. Towards a Hierarchy of Visual Languages. 12th International
IEEE Workshop on Visual Languages, Boulder/CO, September 1996.
[MM98] K. Marriot and B. Meyer (Editors). Visual Language Theory. Springer Verlag, June, 1998.
[MMW98] K. Marriot, B. Meyer and K. B. Wittenburg. A Survey of Visual Language Specification
and Recognition. K. Marriot and B. Meyer (Editors). Visual Language Theory. Springer
Verlag, June, 1998.
[Mon99] Maps of Montana. Acessado em 1999. http://nris.state.mt.us/
225
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[MP90] M. Mainguenaud and M. Portier. Definition of Cigales: A Geographical Information
System Query Language. Database and Expert Systems Applications, pp. 275-280, Zürich,
July 1990.
[MPS94] A. Massari, S. Pavani and L. Saladini. QBI: An Iconic Query System for Inexpert Users.
Proceeding of Advanced Visual Interfaces, AVI, 1994, Bari, Italy.
[MSD99]
Metadata
Standards
Development.
Federal
Geographic
Data
Commitee.
http://www.fgdc.gov/metadata/metadata.html
[MSO87] K. J. McDonell, R. Sacks-Daois and B. C. Ooi. GeoQL – A Query Language for
Geographic Information Systems. Technical Report, Dept. of Computer Science, R.M.I.T.,
Melbourne, 1987.
[MV02] A. Miene and U. Visser. Interpretation of spatio-temporal relations in real-time and
dynamic environments. TZI - Center for Computing Technologies. University of Bremen.
Germany, 2002.
[Nas95] A. M. R. Nascimento. LinGeo – Uma Linguagem de Consulta Geográfica. Dissertação de
Mestrado. UFPE. Brasil. 1995.
[OGG96] The OpenGIS Guide. Part I of the Open Geodata Interoperability Specification (OGIS).
Open GIS Consortium. 1996. http://www.opengis.org/
[OGC98a] Open GIS Consortium Abstract Specification. Version 3, 1998. http://www.opengis.org/
[OGC98b] Open GIS Consortium, Conformance Test Guidelines for OpenGIS Simple Features
Specification for SQL, Revision 1.0. October, 1998. http://www.opengis.org/
[OGC99a] Open GIS Consortium Abstract Specification. Version 4, 1999. http://www.opengis.org/
[OGC99b] Open GIS Consortium, Simple Features Specification for SQL. Revision 1.1. May, 1999.
http://www.opengis.org/
[OGC990] Open GIS Consortium, Abstract Specification, Topic 0 – Abstract Specification
Overview. June – 1999. http://www.opengis.org/techno/abstract/99-100r1.pdf
[OGC01I] Open GIS Consortium, Abstract Specification, Topic 1 – Feature Geometry (ISO 19107
Spatial Schema), May, 2001. http://www.opengis.org/techno/abstract/01-101.pdf
[OGC02II] Open GIS Consortium, Abstract Specification, Topic 2 – Spatial Referencing by
Coordinates, January, 2002, http://www.opengis.org/techno/abstract/02-102.pdf
226
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[OGC99III] Open GIS Consortium, Abstract Specification, Topic 3 - Locational Geometry
Structures, March, 1999, http://www.opengis.org/techno/abstract/99-103.pdf
[OGC99V] Open GIS Consortium, Abstract Specification, Topic 5 - Features, March, 1999,
http://www.opengis.org/techno/abstract/99-105r2.pdf
[OGC99VIII] Open GIS Consortium, Abstract Specification, Topic 8 – Relationships Between
Features , March, 1999, http://www.opengis.org/techno/abstract/99-108r2.pdf
[OGC99X] Open GIS Consortium, Abstract Specification, Topic 10 – Feature Collections, April,
1999, http://www.opengis.org/techno/abstract/99-110.pdf
[OGC99XI] Ope n GIS Consortium, Abstract Specification, Topic 11 – Metadata, March, 1999,
http://www.opengis.org/techno/abstract/99-111r1.pdf
[Oli97] J. L. Oliveira. Projeto e Implementação de Interfaces para Sistemas de Informações
Geográficas. Tese de Doutorado. Unicamp, Dezembro, 1997.
[OGM97] J. L. Oliveira, M. A. Gonçalves and C. B. Medeiros. Designing and Implementing the
User Interface of Geographic Digital Libraries. Relatório Técnico, IC-97-25, Unicamp,
Dezembro, 1997.
[OM96] J. L. Oliveira, C. B. Medeiros. Tutorial: User Interface Architecture, Languages, and
Models in Geographic Databases. In Anais do Décimo Primeiro Simpósio Brasileiro de
Banco de Dados, pp 20-42, Outubro, 1996.
[OPM97] J. L. Oliveira, F. Pires and C. B. Medeiros. An Environment for Modeling and Design of
Geographic Applications. In GeoInformatica 1(1), 29-58, 1997
[Ora97] Oracle8 [tm] Spatial Cartridge. Advances in Relational Database technology for Spatial Data
Management. An Oracle Technical White Paper. June, 1997.
[Ora02] Oracle  Spatial, User Guide and Reference, Release 9.2, March 2002.
[Pas96] I. D. Passos. Validação com Proposta de Extensão do Modelo de Dados Geográficos
MGeo+. Dissertação de Mestrado. UFPB. 1996.
[PE97] D. Papadias, and M. Egenhofer. “Algorithms for Hierarchical Spatial Reasoning .”
GeoInformatica 1(3): 251-273, 1997.
[PES00] D. Papadias, M. Egenhofer and J. Sharma. "Hierarchical Reasoning about Direction
Relations". In Proceedings of ACM GIS, USA, 2000.
227
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Per00] C. R. Perez. Interoperabilidade e Integração de SIG através de Sistemas Hipermídia
Abertos. Tese de Doutorado, Centro de Informática – UFPE, Março, 2000.
[PF88] B. L. Palmer and A. U. Frank. Spatial Languages. In Proceedings of The 3rd International
Symposium on Spatial Data handling – SDH 88, Sydney, Australia, August, 1988.
[Pim95] F. L. Pimentel. Uma Proposta de Modelagem Conceitual para Dados Geográficos: O
Modelo MGeo+. Dissertação de Mestrado. Departamento de Informática – UFPE. Outubro.
1995.
[Pir97] F. Pires. Um Ambiente Computacional para Modelagem de Aplicações Ambientais. Tese de
Doutorado. Unicamp. 1997.
[Pot02] A. Pots. ArcInfo Version 8: Introducing the Next Generation. ESRI Product Mnagement
Group, Acessada em Agosto/2002. http://www.esri.com/news/arcuser/0499/ai8b.html
[PR99] E. Pourabbas and M. Rafanelli. PQL*: An Extended Pictorial Query Language for
Querying Geographical Databases using Positional and OLAP Operators. In Proceedings
of ACM GIS, November, Kansas City, USA, 1999.
[PSZ+98] C. Parent; S. Spaccapietra, S.; E. Zimanyi; P. Domini; C. Plazanet; C. Vangenot.
Modeling spatial data in the MADS conceptual model. In Proceedings of the International
Symposium on Spatial Data Handling. Vancouver, Canada, 1998.
[RFS88] N. Roussopulos, C. Faloutsos and T. Sellis. An Efficient Pictorial Database Systems for
PSQL. IEEE Transactions on Software Engineering, May, 1988.
[RS99] S. Ravada and J. Sharma. Oracle 8i Spatial: Experiences with Extensible Databases.
SSD’99, LNCS 1651, pp. 355-359, 1999.
[Rum91] J. Rumbaugh et. al. Object-Oriented Modeling and Design. New Jersey: Prentice-Hall,
1991.
[Sam88] A. Sambura. Spatial Extensions to SQL. A Search for a Universal Query Language for
LIS/GIS Applications. Proceedings of 16th Australian Conference on Urban and Regional
Planning Information Systems, Australia, Sydney, November, 1988.
[SCG+97] S. Shekhar; M. Coyle; B. Goyal; D. Liu; S. Sarkar. Data model in geographic
information systems. Communications of the ACM, v.40, n.4, p.103-111, 1997.
[Sch00]
Peter
N.
Schweitzer.
Formal
Metadata
Acessado
em
2000.
http://geology.usgs.gov/tools/metadata/
228
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Sch02] Peter N. Schweitzer. TKME - Another editor for formal metadata. Acessado em 2002.
http://geology.usgs.gov/tools/metadata/tools/doc/tkme.html
[SDT99] What is SDTS? The Spatial Data Transfer Standard Guid e for Technical Managers.
Acessado em 1999. http://mcmc.web.ec.usgs.gov/sdts.
[Sil99] S. L. F. Silva. Interação Visual com Bancos de Dados Históricos. Tese de Doutorado.
UFPB. 1999.
[Soa01] V. G. Soares. GeoVisual – Um Ambiente de Consultas Visuais para Sistemas de
Informações Geográficas. Exame de Qualificação e Proposta de Tese de Doutorado.
Centro de Informática – UFPE. Outubro - 2001.
[SPZ98] S. Spaccapietra, C. Parent & E. Zimanyi. Modeling Time from a Conceptual Perspective,
Proceedings of CIKM'98 (International Conference on Information and Knowledge
Management), Washington D.C., USA, 1998. http://lbdwww.epfl.ch/e/
publications/articles.ps/CIKM98.ps
[SS98] V. G. Soares e A. C. Salgado. Interface para Consultas Visuais em Sistemas de Informações
Geográficas utilizando Padrões de Metadados Espaciais. Relatório Técnico. Outubro.
1998.
[SS99] V. G. Soares e A. C. Salgado. Consultas Visuais em Sistemas de Informações Geográficas
baseadas em Padrões de Metadados Espaciais. I Brazilian Workshop in GeoInformatics.
Campinas. Outubro. 1999.
[SS00] V. G. Soares and A. C. Salgado. A Metadata -based Approach to Define a Standard to
Visual Queries in GIS. . In Proceedings of the International Workshop on Interactin g with
Databases in conjunction with the 11th International Conference on Database and Expert
Systems Applications - DEXA 2000. London, UK. September, 2000.
[SS02] V. G. Soares and A. C. Salgado. Visual Querying in Geographical Information Systems, pp.
251-265, In Visual and Multimedia Information Management, Edited by Xiaofang Zhou
and Pearl Pu, Kluwer Academic Publishers, 2002.
[SSC97] S.L.F.Silva, U. Schiel, T. Catarci. Integrando Aspectos Temporais no Acesso e na
Usabilidade de Interfaces Visuais Adaptativas a Banco de Dados Históricos. Proposta de
Tese de Doutorado. UFPB. 1997.
[Tho98] Rogério Thomé. “Interoperabilidade em Geoprocessamento: Conversão entre Modelos
Conceituais de Sistemas de informação geográfica e Comparação com o padrão Open
229
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
GIS”. Dissertação de Mestrado, INPE, 1998. Disponível em
http://www.dpi.inpe.br/teses/thome
[Tim94] V. C. Times. MGeo: Um Modelo Orientado a Objetos para Aplicações Geográficas.
Dissertação de Mestrado, UFPE, 1994.
[Tos98] N. Tosta. Continuing Evolution of the National Spatial Data Infrastructure. Acessado em
1998. http://www.fgdc.gov/publications/publications.html
[TPS+95] Y. Theodoridis, D. Papadias, E. Stefanakis and T. Sellis. Direction Relations and TwoDimensional Range Queries:Optimization Techniques. Technical Report 95-9. University
of Maine, Orono. July. 1995.
[TPS96] Y. Theodoridis, D. Papadias and E. Stefanakis. Supporting Direction Relations in Spatial
Database Systems. In Proceedings SDH´96, Advances in GIS Research II (Taylor &
Francis), London, 1996.
[UGIS95] Understanding GIS – The ARC/INFO Method. Self-Study Workbook. John Wiley &
Sons, 1995.
[VMR99]
The
Value
of
Metadata
(A
NSDI
Report).
Acessado
em
1999.
http://www.fgdc.gov/publications/ documents/metadata/metabroc.html
[WF02] S. Winter and A. U. Frank. Topology in Raster and Vector Representation. Acessado em
Setembro 2002. ftp://ftp.geoinfo.tuwien.ac.at/winter/winter00topology.pdf
[WH98] M. Wessel, V. Haarslev. VISCO: Bringing Visual
Spatial
Querying
to
Reality. . IEEE Symposium on Visual Languages. Nova Scotia, Canada. September, 1998.
http://kogs-www.informatik.uni-hamburg.de/~mwessel/visco-engl.html
[WZ98] D. Wang and H. Zeevat. A Syntax-Directed Approach to Picture Semantics. K. Marriot and
B. Meyer (Editors). Visual Language Theory. Springer Verlag, June, 1998.
[XML02] XML: From the Inside Out. Último acesso em 2002. http://www.xml.com/index.csp
[Zlo76] M. M. Zloof. Query-By-Example: Operations on Hierarquical Databases. In National
Comp. Conf. 1976.
230
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
BIBLIOGRAFIA
[Bow96] J. Bowen. Formal Specification and Documentation using Z: A Case Study Approach,
International Thomson Computer Press, International Thomson Publishing, 1996.
[BK00a] C. Baptista and Z. Kemp. An Integrated Metamodel for Knowledge Representation in
GeoLibraries. In Proceedings of the IEEE Advances on Digital Libraries (ADL2000).
Washington D.C., USA, May 2000.
[BK00b] C. Baptista and Z. Kemp. Interacting with Spatiotemporal Digital Libraries. In
Proceedings of the International Workshop on Interacting with Databses in conjunction
with the 11th International Conference on Database and Expert Systems Applications DEXA 2000. Londres, UK. September 2000.
[CF80] N. Chang and K. Fu. Query-By-Pictorial-Example. IEEE Transactions on Soaftware
Engineering, Vol, SE-6, NO. 6, November 1980.
[CM96] C. Claramunt and M. Mainguenaud. A Spatial Data Model for Navigation Knowledge. 7th
Spatial Data Handling, Delft, The Netherlands, Agosto, 1996.
[CSE94] E. Clementini, J. Sharma and M. Egenhofer. Modelling Topological Spatial Relations:
Strategies for Query Processing. Computer & Graphics, Vol. 18, No. 6, pp. 815-822, 1994.
[Dre99] M.Drewry. Metadata: Quality vs. Quantity.
http://www.computer.org/conferen/proceed/meta97/papers/hconover/mdrewry.html.
[EB95] M. J. Egenhofer and H. T. Bruns. Visual Map Algebra: a direct-manipulation user interface
for GIS. Proceedings of the Third Working Conference on Visual Database Systems.
Switzerland. 1995.
[Ege93] M. J. Egenhofer. What’s Special about Spatial? Database Requirements for Vehicle
Navigation in Geographic Space. SIGMOD 93, Washington, D.C., SIGMOD Record, 22
(2): 398-402, June 1993
[EGG+99] M. J. Egenhofer, J. Glasgow, O. Günther, J. Herring and D. Peuquet. Progress in
Computacional Methods for Representing Geographic Concepts. International Journal of
Geographical Information Science, pp. 775-796, 1999.
231
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Fra02] A. U. Frank. Consistency Constraints in Geographic Information Systems – An Ontological
View. Acessado em Setembro 2002. ftp://ftp.geoinfo.tuwien.ac.at/frank/3465tiers-ofontology.PDF
[Har88] D. Harel. On Visual Formalisms. Communications of the ACM. Vol. 31, Num. 5, pp. 514530, May 1988.
[HMO91] R. Helm, K. Marriot and M. Odersky. Building Visual Language Parsers. Human Factors
in Computing Systems Conference Proceedings on Reaching through Technology, pp. 105112, 1991.
[HOM93] S. Hoop, P. Oosterom and M. Molenaar. Topological Querying of Multiple Map Layers.
Spatial Information Theory – A Theoretical basis for GIS. Proceeding of European
Conference, COSIT 93, Italy, September, 1993.
[JC88] T. Joseph and A. Cardenas. PICQUERY: A High Level Query Language for Pictorial
Database Management. IEEE Transactions on Software Engineering, Vol. 14, No. 5, May,
1988.
[Jun99] V. Jung. MetaViz: Visual Interaction with Geospatial Digital Libraries. Technical Report,
International Computer Science Institute, TR-99-017, October, 1999.
[LC95] Y. C. Lee and F. L. Chin. An Iconic Query Language for Tpological Relationships in GIS.
International Journal Geographical Information Systems, Vol. 9, No. 1, pp. 25-46, 1995.
[LCN00] I. Lucena, G. Câmara and M. Nascimento. Object-Oriented User Interfaces for Map
Álgebra, Submetido ao ACMGIS 2000, http://www.dpi.inpe.br/nsf-cnpq/
[LFM+95] F. Di Loreto, F. Ferri, F. Massari and M. Rafanelli. A Visual Object-Oriented Query
Language for Geographic Information Systems. Data
base and Expert Systems
Applications. 6th Int. Conference, DEXA 95, London, UK, September, 1995.
[LG00] H. Luttermann and M. Grauer. Using Interactive, Temporal Visualizations for WWW-based
Presentation and Exploration of Spatio-Temporal Data. http://www-info.unisiegen.de/winfo/english
[Mai00a] M. Mainguenaud. A Query Resolution Engine to Handle a path Operator with Multiple
paths. Transportation Research, Part C, Vol. 8, pp 109-127. Elsevier Science. Recebido em
2000.
232
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[Mai00b] M. Mainguenaud. CIGALES: Cartographical Interface Generating an Adapted Language
for Extensible Systems. Acessado em Outubro/2000. http://www.univrouen.fr/psi/Equipe/Mainguenaud/cigales.eng.html
[Mai93] M. Mainguenaud. The Semantics of the Geographical Database Query Languages. 4th
European Geographical Information System Conference, Genes, Itália, Março, 1993.
[Mai96] M. Mainguenaud. Constraint-Based Queries in a Geographical Database for Network
Facilities. Computer, Environment and Urban Systems, Pergamon Press, Vol. 20, no. 2, pp.
139-151, 1996.
[MS99] Metadata Standards, What is Metadata and Metadata in Use.
http://alexandria.sdc.ucsb.edu/frames3.html.
[OM88] J. Orenstein and F. Manola. PROBE: Spatial Data Modelling and Query processing in na
Image Database Application. IEEE Transactions on Software Engineering, Vol. 14, No. 5,
May, 1988.
[OSAH97] C.Olston, M. Stonebraker, A. Aiken, J. Hellerstein. VIQING: Visual Interactive
QueryING. IEEE Symposium on Visual Languages. Nova Scotia, Canada. September,
1998.
[Peu88] D. J. Peuquet. Towards the Definition and Use of Complex Spatial Relationships. In
Proceedings of the 3rd International Syposium on Spatial Data handling – SDH 88, Sydney,
Australia, August, 1988.
[Pul97] D. Pullar. Query language for Spatial Relationships. Proceedings of ASPRS-ACMSM
Annual Convetions, baltimore, MD, USA, pp 180-192, 1987.
[RFS88] N. Roussopoulos, C. Faloutsos and T. Sellis. An Efficient Pictorial Database System for
PSQL. IEEE Transaction on Software Engineering, Vol. 14, No. 5, May 1988.
[Rob88] P. Robertson. Choosing Data Representations for The Effective Visualization of Spatial
Data. In Proceedings of the 3rd International Symposium on Spatial Data Handlling – SDH
88, Sydney, Australia, August, 1988.
[Set96] R. Sethi. Programming Languages. Concepts & Constructs. Addison-Wesley. Second
Edition. 1996.
[Voi95] A. Voisard. Mapgets: A Tool for Visualizing and Querying Geographic Information.
Journal of Visual Languages and Computing. 1995.
233
Referências Bibliográficas e Bibliografia
________________________________________________________________________________________________
[WLI98] E. J. Webber, J. Lisboa, C. Iochpe and H. Hasenack,. Geospatial Metadata in Brasil. An
Experience in data documentation of an environmental GIS application . In: International
Conference & Exhibition on geographic Information – GISPlanet, 1998, Lisbon, Portugal.
234