universidade do vale do itajaÍ centro de …siaibib01.univali.br/pdf/jaque bernardes.pdf ·...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE EDUCAÇÃO SÃO JOSÉ
CURSO DE CIÊNCIA DA COMPUTAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
RASTREAMENTO DE VEÍCULOS
Jaque Cúnico Bernardes
São José 2004
2
JAQUE CÚNICO BERNARDES
RASTREAMENTO DE VEÍCULOS
Monografia apresentada à Banca Examinadora do Trabalho de Conclusão de Curso de Ciência da Computação da Universidade do Vale do Itajaí - UNIVALI – São José, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação.
Orientador: Prof. Rogério Gonçalves Bittencourt, Msc.
São José 2004
3
JAQUE CÚNICO BERNARDES
RASTREAMENTO DE VEÍCULOS
Esta Monografia foi julgada adequada para a obtenção do título de Bacharel em Ciência da Computação e aprovada pelo Curso de Ciência da Computação da Universidade do Vale do Itajaí, Centro de Educação de São José.
Área de Concentração: Banco de dados
São José, 17 de dezembro de 2004.
____________________________________ Prof. Msc. Rogério Gonçalves Bittencourt
UNIVALI - CE de São José Orientador
_________________________________ Prof. Dr. Vinicius Medina Kern
UNIVALI - CE de São José Membro de banca
_________________________________ Prof. M. Eng. Henrique Simas UNIVALI - CE de São José
Membro de banca
4
SUMÁRIO
Sumário.......................................................................................................................................4 Resumo .......................................................................................................................................7 Abstract.......................................................................................................................................8 Lista de Figuras ..........................................................................................................................9 Lista de Tabelas ........................................................................................................................12 Lista de Siglas...........................................................................................................................13 1 Introdução.........................................................................................................................14
1.1 Apresentação ..................................................................................................................14 1.2 Justificativa.....................................................................................................................15 1.3 Objetivos.........................................................................................................................16
1.3.1 Objetivo geral ...................................................................................................16 1.3.2 Objetivos específicos........................................................................................16
2 Informação geográfica......................................................................................................17 2.1 Conceitos de cartografia .................................................................................................17
2.1.1 Mapas e cartas ..................................................................................................17 2.1.2 Escala................................................................................................................18
2.2 Dados Geográficos .........................................................................................................31 2.3 Estrutura de Representação ............................................................................................32
2.3.1 Estrutura Raster (Matricial) ..............................................................................34 2.3.2 Métodos de Compactação de Dados Raster .....................................................34 2.3.3 Vetorial .............................................................................................................35 2.3.4 Comparação entre Raster e Vetor.....................................................................39
3 Banco de dados Geográfico..............................................................................................41 3.1 Conceitos de Básicos de BDG........................................................................................41
3.1.1 Identidade .........................................................................................................41 3.1.2 Entidade............................................................................................................41 3.1.3 Objeto ...............................................................................................................41 3.1.4 Tipo de Entidade...............................................................................................41 3.1.5 Tipo de Objeto Espacial ...................................................................................41 3.1.6 Classe de Objeto ...............................................................................................42 3.1.7 Atributo.............................................................................................................42 3.1.8 Valor de Atributo..............................................................................................42 3.1.9 Camada (layer) .................................................................................................42
5
3.2 Arquitetura de Banco de Dados Espacial .......................................................................42 3.2.1 Arquitetura Dual ...............................................................................................44 3.2.2 Arquitetura em Camadas ..................................................................................45 3.2.3 Arquitetura Integrada........................................................................................45
4 Indexação..........................................................................................................................48 4.1.1 Quad-tree ..........................................................................................................48 4.1.2 R-tree ................................................................................................................52
5 Oracle Spatial ...................................................................................................................57 5.1 Modelo Conceitual .........................................................................................................57 5.2 Sistemas de Coordenadas ...............................................................................................58
5.2.1 Associando Geometrias com os sistemas de coordenadas ...............................60 5.2.2 Adicionando informação ..................................................................................60
5.3 Modelo de Representação...............................................................................................61 5.3.1 Representação da Geometria ............................................................................61 5.3.2 Representação da Topologia.............................................................................62
5.4 Modelo Físico .................................................................................................................62 5.4.1 Objeto Espacial.................................................................................................62 5.4.2 Conjunto de Operações Implementadas ...........................................................63 5.4.3 Semântica das operações ..................................................................................64 5.4.4 Métodos de Indexação......................................................................................65 5.4.5 Linguagens de Consulta e Ambiente de Consulta Espacial .............................66
5.5 Camadas Espaciais .........................................................................................................66 5.5.1 Objeto sdo_gtype..............................................................................................67 5.5.2 Modelo de Dados do LRS ................................................................................75 5.5.3 Definindo um segmento geométrico ................................................................77 5.5.4 Deslocando um segmento geométrico..............................................................82 5.5.5 Encontrando um ponto em um segmento geométrico ......................................82 5.5.6 Métodos em SDO_GTYPE ..............................................................................88 5.5.7 Campo de SDO_SRID......................................................................................88 5.5.8 Campo de SDO_POINT ...................................................................................89 5.5.9 Campo SDO_ELEM_INFO .............................................................................89 5.5.10 Campo de SDO_ORDINATES ........................................................................90 5.5.11 Elementos SDO_GEOMETRY ........................................................................90 5.5.12 Tipos de Elementos Sumariados ......................................................................90 5.5.13 Cadeia de linha .................................................................................................92 5.5.14 Cadeia de arco ..................................................................................................93 5.5.15 Polígono............................................................................................................93 5.5.16 Arco Polígono...................................................................................................94
6
5.5.17 Retângulo..........................................................................................................95 5.5.18 Circulo ..............................................................................................................95 5.5.19 Cadeia de linhas compostas..............................................................................96 5.5.20 Polígono composto ...........................................................................................97 5.5.21 Polígono com buraco........................................................................................98 5.5.22 Polígono composto com buraco .......................................................................99 5.5.23 Elemento desconhecido ....................................................................................99 5.5.24 Conjunto de pontos.........................................................................................100 5.5.25 Coleção de cadeias de várias linhas................................................................100 5.5.26 Coleção de Polígonos .....................................................................................101 5.5.27 Construção de geometrias...............................................................................101 5.5.28 Metadados espacial.........................................................................................103
6 Inserindo dados no formato shapefile.............................................................................106 6.1 Restrições .....................................................................................................................109 6.2 Convertendo arquivos Shapefile...................................................................................109
7 Mapserver .......................................................................................................................111 7.1 O Arquivo de Inicialização...........................................................................................112 7.2 O Mapfile......................................................................................................................113 7.3 O Arquivo Template.....................................................................................................113 7.4 A base de dados SIG.....................................................................................................113
8 Modelagem .....................................................................................................................114 8.1 Banco de dados.............................................................................................................114 8.2 Diagrama de estados.....................................................................................................115 8.3 Diagrama de classes .....................................................................................................116 8.4 Desenvolvimento..........................................................................................................117
9 Conclusão .......................................................................................................................120 10 Anexo .........................................................................................................................122
10.1 Oracle Spatial .............................................................................................................122 10.2 Mapserver ...................................................................................................................124
11 Referencia...................................................................................................................130
7
RESUMO
Com a popularização do GPS e mapas digitais, hoje é possível desenvolver sistemas
voltados para o rastreamento de veículos a baixo custo.
Nesse trabalho aborda o desenvolvimento de um sistema de rastreamento de veículos,
sem considerar o sistema embarcado para fazer a comunicação de dados entre o GPS e o
servidor de banco de dados. Contudo o sistema simula posições no espaço (no caso um mapa
de Florianópolis), demonstrando sua ultima posição e o rastro de um período.
O projeto explica como usar o oracle spatial (banco de dados espacial) como
dispositivo de armazenagem das posições geográficas (usando a projeção WGS-84),
juntamente com o Mapserver como ferramenta de visualização.
O trabalho esclarece porque esse sistema é muito mais eficiente usando a tecnologia
de banco de dados espacial e a razão pela qual esse tipo de banco é caracterizado por banco de
dados não convencional.
Palavras-chave: Banco de dados espacial, Oracle Spatial, Mapserver
8
ABSTRACT
With the popularizes of the GPS and digital maps, today the low cost is possible to
develop systems directed toward the tracking of vehicles.
In this work it approaches the development of a system of tracking of vehicles,
without considering the embarked system to make the communication of data between the
GPS and the server of data base. However the system simulates position in the space (in the
case a map of Florianópolis), demonstrating its it finishes position and the track of a period.
The project explains as to use oracle spatial (space data base) as device of storage of
the geographic positions (using the Wgs-84 projection), together with the Mapserver as
visualization tool.
The work clarifies because this system is much more efficient using the technology of
space data base and the reason for which this type of bank is characterized by not
conventional data base.
Key-Words: Space data base, Oracle Spatial, Mapserver
9
LISTA DE FIGURAS
Figura 1 – Escala gráfica ..........................................................................................................19 Figura 2 - Transformação de escala..........................................................................................20 Figura 3 - Superfícies de Desenvolvimento .............................................................................22 Figura 4 – Cilindro tangente.....................................................................................................22 Figura 5 – Cilindro secante.......................................................................................................22 Figura 6 – Cônica tangente.......................................................................................................23 Figura 7 – Cônica secante.........................................................................................................23 Figura 8 – Plano tangente .........................................................................................................24 Figura 9 – Plano secante...........................................................................................................24 Figura 10 – Sitema UTM..........................................................................................................30 Figura 11 – Estruturas básicas para representar dados espaciais..............................................32 Figura 12 - Tipos de modelos cartográficos .............................................................................33 Figura 13 - Cadeira no formato raster e vetorial ......................................................................33 Figura 14 – Modelo Spaghetti ..................................................................................................37 Figura 15 – Modelo Topológico...............................................................................................38 Figura 16 - TIN (Rede Irregular Triangularizada)....................................................................39 Figura 17 – Arquitetura Dual ...................................................................................................44 Figura 18 – Arquitetura em camadas........................................................................................45 Figura 19 – Arquitetura Integrada ............................................................................................46 Figura 20 – Decomposição do espaço em Quad-tree ...............................................................48 Figura 21 - Decomposição Sucessiva.......................................................................................49 Figura 22 – Exemplo de uma referência de objetos no índice Quad-tree ................................49 Figura 23 – Caminhamento na Quad-tree: Ordem proposta por Morton.................................50 Figura 24 - Representação geométrica do Quadtree ................................................................51 Figura 25 - Retângulo limitando a geometria...........................................................................53 Figura 26 – Decomposição R-tree (Árvore Balanceada)..........................................................53 Figura 27 - Modelo de Dados do ORACLE SPATIAL. ..........................................................58 Figura 28 – Tipos de Dados Espaciais Primitivos do Oracle Spatial .......................................62 Figura 29 - Objeto SDO_GEOMETRY ...................................................................................67 Figura 30 - Representação do tipo de dado SDO_GTYPE ......................................................67 Figura 31 - Elementos do tipo SDO_GTYPE ..........................................................................69 Figura 32 - Segmento Geométrico ...........................................................................................71 Figura 33 - Descrevendo um ponto ao longo de um segmento com uma medida e um offset .72
10
Figura 34 - Medidas, distâncias, e seu relacionamento traçando. ............................................73 Figura 35 - Povoamento da medida de um segmento geométrico............................................73 Figura 36 - Medida povoada de forma desproporcional...........................................................74 Figura 37 - Característica Linear, Segmentos Geométricos, e pontos de LRS ........................75 Figura 38 - Incluir Dimensão da medida de LRS em Metadados espacial...............................75 Figura 39 - Criando um segmento geométrico .........................................................................76 Figura 40 – Função de LRS para formatos 3D com x, y e z ....................................................77 Figura 41 - Função de LRS para formatos 3D com x e y.........................................................77 Figura 42 - Definir um segmento geométrico ..........................................................................78 Figura 43 - Redefinir um segmento geométrico.......................................................................79 Figura 44 - Anexando, dividindo, e concatenando segmentos geométricos ............................80 Figura 45 - Atribuição da medida em operações geométricas do segmento ............................80 Figura 46 - Sentido do segmento com concatenação ...............................................................81 Figura 47 - Escala de um segmento geométrico.......................................................................81 Figura 48 - Deslocando um segmento geométrico ...................................................................82 Figura 49 - Encontrando um ponto ao longo de um segmento com uma medida e um offset..83 Figura 50 - Ambigüidade na posição que referencia o offsets..................................................83 Figura 51 – Projeção de Múltiplos pontos................................................................................84 Figura 52 - Conversão do padrão para cadeia de linhas LRS...................................................85 Figura 53 - Segmento para a operação de anexo afetada por Tolerância .................................86 Figura 54 - Exemplo Simplificado de LRS: Estrada ................................................................87 Figura 55 - Tipos do elemento sumariados ..............................................................................92 Figura 56 - Exemplo de Cadeia de linha ..................................................................................93 Figura 57 - Exemplo de Cadeia de Arco ..................................................................................93 Figura 58 - Exemplo de Polígono.............................................................................................94 Figura 59 - Exemplo de Polígono.............................................................................................95 Figura 60 - Exemplo de Retângulo...........................................................................................95 Figura 61 - Exemplo de Retângulo...........................................................................................96 Figura 62 - Exemplo de Cadeia de linhas Compostas..............................................................97 Figura 63 - Exemplo de Polígono Composto ...........................................................................98 Figura 64 - Polígono com Buraco ............................................................................................98 Figura 65 - Polígono composto com Buraco............................................................................99 Figura 66 – Elemento desconhecido.......................................................................................100 Figura 67 - Coleção de pontos................................................................................................100 Figura 68 - Coleção de Multipontos.......................................................................................101 Figura 69 - Coleção de polígonos...........................................................................................101 Figura 70 - Inserindo uma cadeia de linhas............................................................................102 Figura 71 - Inserindo uma cadeia de polígonos......................................................................103
11
Figura 72 – Arquivos Shapefile..............................................................................................106 Figura 73 - Exemplo de um arquivo SQL*Loader com pontos .............................................108 Figura 74 - Exemplo de um arquivo SQL*Loader com polígonos ........................................109 Figura 75 - Sintaxe para usar o shp2sdo.................................................................................109 Figura 76 - Lógica de uma aplicação MapServer...................................................................112 Figura 77 – Banco de dados ...................................................................................................114 Figura 78 – Diagrama de Estados...........................................................................................116 Figura 79 – Diagrama de Classes ...........................................................................................117 Figura 80 – Tela inicial...........................................................................................................117 Figura 81 – Localizar um veículo...........................................................................................117 Figura 82 – Mapa da solicitação de “Localizar um veículo” .................................................118 Figura 83 – Mostrar o rastro do veículo .................................................................................118 Figura 84 – Mapa da solicitação de “Localizar rastro de um veículo”...................................119
12
LISTA DE TABELAS
Tabela 1 - Vantagens e das estruturas desvantagens de representação Raster e Vetorial. .......39 Tabela 2 - Tipo de Objetos Espacial.........................................................................................42 Tabela 3 - Vantagens e problemas das arquiteturas dual, em camadas e integrada. ................47 Tabela 4 - Sintaxe do MDSYS.SDO_GEOMETRY................................................................63 Tabela 5 – Operadores Espaciais e Funções Espaciais.............................................................64 Tabela 6 - Características da estrada e contrapartes de LRS....................................................88
13
LISTA DE SIGLAS
BD Banco de Dados
CAD Computer Aided Design
CGI Commom Gateway Interface
DBA Administrador de Banco de Dados
ESRI Environmental Systems Research Institute
GID Numeric Geometry Identifier
GPS Posicionamento Global por Satélite
HTML Hiper Text Mark-up Language
HTTP Hyper Text Transfer Protocol
LRS Sistema de Referencia Linear
MBR Minimous Bounding Rectangles
MVE Mínimo Volume Envolvente
NASA National Aeronautics and Space Administration
OGC Open GIS Consortium
SGBD Sistema Gerenciador de Bancos de Dados
SGBDOO Sistema Gerenciador de Bancos de Dados Orientado a Objeto
SGBDR Sistema Gerenciador de Bancos de Dados Relacional
SIG Sistema de Informação Geográfica
SQL Structured Query Language
UTM Projeção Universal Transversal de Mercator
14
1 INTRODUÇÃO
1.1 APRESENTAÇÃO
Com a popularização do GPS, transmissão de dados por celular e com a era dos mapas
digitais das mais diversas cidades do Brasil e do mundo, tornou-se possível monitorar
veículos em tempo real, tanto particulares (automóveis, motos etc.) ou frotas inteiras
(caminhões, carros de empresas, por exemplo).
Esse monitoramento gera dados nos quais são armazenados em um banco de dados
convencional para futuras análises (de rotas, tempo, velocidade etc.). Enquanto os dados
espaciais, onde será possível localizar um objeto no espaço geográfico, ficam armazenadas
em um banco espacial, como as ruas, lotes, municípios.
De posse desses dados, podem-se gerar informações importantes para o cliente (tanto
pessoa física quanto pessoa jurídica), tais como verificar se o veículo ultrapassou velocidade
máxima permitida, localização exata do veículo (no caso de roubo, seqüestro, ou para
previsionar tempo de chegado no de ao destino) etc..
Para podermos localizar um veículo qualquer, este veículo deve ser descrito com
relação a outros objetos geográficos (rua, BR, por exemplo) cujas posições (localizações)
sejam previamente conhecidas, com sua localização determinada em um sistema de
coordenadas fixas. Identificar a posição em que ele se encontra, temos que trabalhar com
mapas na forma digita com referencias espaciais, onde serão descritas as feições geográficas
(ruas, avenidas, BR, bairros, municípios, praças etc.), conhecidas como dados geográficos.
De acordo com Aronoff (1989), as informações para uma feição geográfica possuem
quatro componentes principais: a posição geográfica (localização); os atributos (dados
alfanuméricos); relacionamentos topológicos (caracterizam relacionamentos de vizinhança ou
de conexão entre objetos geográficos). O componente tempo (se refere ao período ou época da
ocorrência do fenômeno ou fato geográfico). Estes componentes são simplesmente as
respostas as seguintes perguntas: onde, o que, qual o relacionamento com outras feições
espaciais, e quando ocorreu o fato (ou fenômeno) geográfico.
Estes dados, do ponto de vista de banco de dados, podem ser classificados em três
categorias principais:
• Dados Convencionais - atributos alfanuméricos tradicionais, que podem ser
15
tratados por um SGBD convencional (ex.: nome e população de uma cidade);
• Dados Espaciais - atributos que descrevem a geometria e a localização do
fenômeno geográfico. Possui propriedades geométricas e topológicas (ex.: limite
geográfico de um lago);
• Dados Pictóricos - atributos que armazenam imagens (fotos) (ex.: fotografia aérea
de uma cidade).
Tais dados são armazenados em um banco de dados, ditos bancos de dados para
aplicações não-convencionais. Um banco de dados espacial é um banco de dados para esse
tipo de aplicação. Esses bancos de dados possuem a capacidade de armazenar não somente
dados textuais (convencionais), mas dados geo-referenciados (dados geográficos
referenciados espacialmente, por meio de uma coordenada geográfica). Esta disposto no
mercado de alguns bancos de dados como Oracle Spatial, IBM DB2 Spatial Extender,
Informix Spatial Datablade e o PostGIS.
Para visualizarmos o conteúdo de um banco de dados espacial, será necessária a
utilização de uma ferramenta. Esta ferramenta lê os dados geográficos do banco de dados e
desenha na tela do usuário, no caso vai permitir a visualização do mapa junto como a
localização na WEB (navegador). Tal ferramenta será o MAPSERVER, pois além de ser
gratuita (opensource), é a mais utilizada pela comunidade científica em geoprocessamento,
pois apresenta diversas vantagens, tais como: segue a licença OSS/FS, é construído com base
em outros pacotes freeware com Shapelib, GD, Freetype, OGR, Proj.4, libTiff, regex e outros
(MapServer, 2004) e permite navegar no mapa como: leste, oeste, norte, sul, mais zoom,
menos zoom, saber dados de ruas, CEP e outras informações que os dados do mapa1
permitirem extrair.
1.2 JUSTIFICATIVA
Os sistemas comerciais disponíveis no mercado são componentes de terceiros,
proprietários, complexos e muitas vezes confusos para novas implementações e manutenções.
A expectativa não é somente visualizar o veículo, mas saber onde e como está (parada,
andando, sua velocidade, sentido norte, sul, entre outras informações).
Com a junção dessas tecnologias (MapServer e banco de dados espacial) é possível
satisfazer a necessidade de todos os usurários e prestadores de serviços, pois o
desenvolvimento é todo opensource (não contando com o banco de dados), podendo ser
1 Será adquirido por terceiros, ou seja, apenas será convertido para o banco, não sofrera nenhuma auteração.
16
alterado conforme a necessidade sem precisar construir módulos alternativos, aplicativos
aparte, a alteração é na própria aplicação, reutilizando o código, aumentando a produtividade
e diminuído custos significativamente.
1.3 OBJETIVOS
1.3.1 Objetivo geral
Desenvolver uma aplicação de monitoramento de veículos na WEB.
1.3.2 Objetivos específicos
• Armazenar os mapas em uma base de dados digital (georeferenciamento de objetos
geográficos);
• Criar uma base de dados espacial para poder receber os dados geográficos dos
mapas;
• Visualizar a localização atual de um veículo, armazenando em um banco de dados
espacial;
• Visualizar o trajeto de um veicula em um determinado tempo, armazenando em
um banco de dados espacial;
17
2 INFORMAÇÃO GEOGRÁFICA
2.1 CONCEITOS DE CARTOGRAFIA
O dicionário Contemporâneo da Língua Portuguesa define, assim, o termo cartografia:
“Arte de traçar ou gravar cartas geográficas ou topográficas”. O Novo Dicionário Brasileiro
Melhoramentos é mais sintético: “Arte de compor cartas geográficas”. E o novo Dicionário da
Língua Portuguesa, de Aurélio Buarque de Holanda Ferreira, assim explica: “Arte ou ciência
de compor cartas geográficas; tratando sobre mapas”.
Foi a Associação Cartográfica Internacional (ACI), por ocasião do XX Congresso de
Geografia, reunida em Londres, em 1964, que veio, pela primeira vez, estabelecer, em síntese,
mas com precisão, o campo das atividades intimamente ligadas a cartografia: “conjunto de
estudos e operações cientificas, artísticas e técnicas, baseado nos resultados de observações
diretas ou de analise de documentação, com vistas à elaboração e preparação de cartas,
projetos e outras formas de expressão, assim como a sua utilização”.
A cartografia não é uma ciência nem uma arte, mas sem dúvida alguma um método
científico que se destina a expressar fatos e fenômenos observados na superfície da Terra,
atreves de símbolos próprios [CCM93].
Carta topográfica explica de forma gráfica, através de traços, pontos, figuras
geométricas, cores etc., a configuração duma parte da superfície terrestre, tal como ela é,
dentro duma precisão matemática, sempre compatível do à escala.
2.1.1 Mapas e cartas
Mapas são representações gráficas de uma superfície plana em uma determinada
escala, é a representação do globo terrestre, ou de trechos da sua superfície, sobre um plano,
indicando fronteiras políticas, características físicas, localização de cidades e outras
informações geográficas, sócio-políticas ou econômicas. Os mapas, normalmente, não têm
caráter técnico ou científico especializado, servindo apenas para fins ilustrativos ou culturais e
exibindo suas informações por meio de cores e símbolos. Enquanto cartas é uma
representação da superfície terrestre sobre um plano, mas foi especialmente traçada para ser
usada em navegação ou outra atividade técnica ou científica, servindo não só para ser
examinada, mas, principalmente, para que se trabalhe sobre ela na resolução de problemas
18
gráficos, onde os principais elementos serão ângulos e distâncias, ou na determinação da
posição pelas coordenadas geográficas (latitude e longitude). As cartas permitem medições
precisas de distâncias e direções (azimutes).
Embora o mapa e a carta tenham quase tudo em comum, sendo inclusive considerados
sinônimos, no Brasil costuma-se diferenciá-los. Emprega-se a expressão mapa para as
representações mais simples, generalizadas ou de escala muito pequena. Exemplos: mapa do
Brasil (escala 1:5.000.000 ou menos), mapa da América do Sul e mapa-múndi. Já a expressão
carta é utilizada para as representações mais detalhadas, mais precisas ou de grande escala.
Exemplos: cartas topográficas, cartas cadastrais ou urbanas (escalas de 1:500 a 1:10.000) e
cartas de navegação marítima e aérea (cartas náuticas e cartas aeronáuticas).
De acordo com a finalidade ou tipo de usuário a que se destinam, os mapas ou cartas
podem ser classificados em:
• Gerais: Quando se destinam ao público em geral, isto é, quando atendem aos
diversos tipos de usuários. Geralmente são mapas de pequena escala. Por exemplo:
mapas de grandes regiões, de países, de continentes e mapas-múndi.
• Especiais: Quando se destina a determinadas pessoas ou grupos (profissionais),
isto é, são mapas mais específicos ou técnicos e geralmente de grande escala. Por
exemplo: mapas políticos, econômicos, científicos, cartas náuticas, aéreas e
cadastrais.
• Temáticos: Quando se destinam ao estudo, análise e pesquisa de determinados
temas como Geologia, Pedologia, Demografia etc.
2.1.2 Escala
É a relação entre a distância de dois pontos quaisquer do mapa com a correspondente
distância na superfície da Terra. Em geral por uma fração, onde essa fração representa a
relação entre as distâncias lineares da carta e as mesmas distâncias da natureza, ou seja, é uma
fração em que o numerador (invariavelmente a unidade) representa uma distância no mapa e o
denominador a distância correspondente no terreno, tantas vezes maior, na realidade quanto
indica o valor representado no denominador.
Deve ser em função das informações que a carta contém, considerando a resolução do
dado original, o nível de detalhe desejado e o tema representado. Deve ser apresentada em
uma posição de destaque na carta em escala numérica ou gráfica.
A escala numérica vem representada pela própria fração, onde no Brasil e na maioria
dos países é representado, tomemos como exemplo, a escala 1:20.000, qualquer medida linear
19
na carta é, no terreno, 20.000 vezes maior. Se na mesma carta, tomarmos uma distância, por
exemplo, de dois centímetros, esta corresponderá, no terreno, a 40 000 centímetros, que
corresponde a 400 metros.
A escala gráfica é um segmento de reta graduado que permite medir distâncias na
carta. Como se pode observar na figura 1, de zero a quinze há uma indicação de distancias em
quilômetros, com subdivisões de cinco em cinco quilômetros, mediante uma faixa
centimétrica.
Figura 1 – Escala gráfica
Fonte: [CCM93]
Para ampliar o mapa deve-se aumentar a riqueza de detalhes. Assim, devemos
proceder da seguinte forma: Diminuir o denominador, aumentar a escala. Ex:
Num mapa de escala 1: 100.000, queremos ampliar o mapa 5 vezes. Devemos usar a escala 1:
20.000.
Para reduzir o mapa deve-se diminuir a riqueza de detalhes. Assim, devemos proceder
da forma a seguir: Aumentar o denominador, dinimuir a escala. Ex:
Num mapa de escala 1: 100.000 queremos reduzir o mapa 5 vezes. Devemos usar a escala 1:
500.000.
Transformando as escalas da figura 2 para numéricas, temos:
20
Figura 2 - Transformação de escala
Na utilização de mapas, surgem, alguns problemas; em geral eles se referem a três
elementos: a medida do terreno (D), a medida no mapa (d) e o denominador da escala (E). Eis
as relações:
a) conhecidas à distância no terreno e a escala (o denominador da fração), determinar a
distância no mapa, DEd = ;
b) conhecidas à distância no mapa e a escala, determinar a distância no terreno,
dED = .
c) conhecidas à distância no terreno e a distância no mapa, determinar a escala,
. dDE ×=
2.1.2.1 Projeções
Projeção cartográfica é a representação de uma superfície esférica (a Terra) num plano
(o mapa), ou seja, trata-se de um "sistema plano de meridianos e paralelos sobre os quais pode
ser desenhado um mapa" (Erwin Raisz. Cartografia geral. p. 58).
O grande problema da cartografia consiste em ter de representar uma superfície
esférica num plano, pois, como é sabida, a esfera é um sólido não-desenvolvível, isto é, não
planificável. Assim, sempre que achatarmos uma esfera, necessariamente ela sofrerá
alterações ou deformações.
Experimente, por exemplo, cortar uma laranja ao meio e depois pressionar (achatar)
21
uma dessas partes sobre uma superfície plana.
Isso quer dizer que todas as projeções apresentam deformações, que podem ser em
relação às distâncias, às áreas ou aos ângulos. Assim, cabe ao cartógrafo escolher o tipo de
projeção que melhor atenda aos objetivos do mapa.
O processo de produzir um mapa plano de uma superfície pode ser entendido como
uma sucessão de transformações. As irregularidades na forma da terra tornam difícil este
processo de modelagem matemática. Assim o primeiro passo no processo é modelar a Terra
como um objeto sólido mais simples que tem a mesma área de superfície.
Para mapas em grandes escalas que mostram uma porção pequena da superfície
terrestre com grande detalhe, a Terra é modelada como um elipsóide que dá uma melhor
aproximação à verdadeira forma da Terra que uma esfera perfeita.
Organismos responsáveis pela cartografia oficial nos diversos países usam elipsóides
diferentes, ajustando os raios polar e equatorial (semi-eixos) para os melhores valores da
região de interesse.
Para mapas em pequenas escalas que mostram uma área grande com pequeno detalhe,
um modelo esférico é usado por ser matematicamente mais simples e porque em escalas
pequenas, a distorção devido às irregularidades na forma da Terra pode ser considerada
desprezível.
Em termos geométricos, a Terra como um esferóide ou elipsóide (uma esfera
ligeiramente achatada nos pólos) é considerada uma superfície que não pode ser desenvolvida,
porque não importa como o esferóide ou elipsóide seja dividido, ele não pode ser planificado.
Selecionado o modelo matemático apropriado, o próximo passo é reduzir o tamanho
do modelo para a escala desejada do mapa. A escala pode ser calculada como a relação entre
o raio do modelo e o raio da Terra (aproximadamente 6.300 km). Porém, por causa da
distorção introduzida na representação de um esferóide ou elipsóide em um plano, a escala do
mapa variará de lugar para lugar.
O passo final no processo é projetar o reticulado (meridianos e paralelos) sobre a
superfície de desenvolvimento. Qualquer superfície que pode ser planificada é uma superfície
de desenvolvimento. Superfícies e métodos de projeções diferentes são usados para obter
mapas com propriedades geométricas diferentes.
A maioria das projeções é derivada de fórmulas matemáticas, mas algumas são mais
fáceis de visualizar quando projetadas em uma superfície de desenvolvimento.
Embora um número infinito de projeções seja teoricamente possível, foram descritas
aproximadamente 400 projeções na literatura cartográfica e só algumas dezenas destas são
22
extensamente usadas. Estabelecer uma classificação de projeções serve como auxílio para
entender as suas propriedades e para selecionar uma projeção apropriada para um
determinado propósito.
As projeções podem ser classificadas em termos das propriedades geométricas de
representação e pela superfície geométrica da qual elas são derivadas. Algumas das projeções
mais simples são apoiadas sobre formas geométricas que podem ser planificadas sem
deformar suas superfícies. Como exemplos de formas geométricas que refletem estas
propriedades temos cones, cilindros e planos (figura 3). Assim, temos as projeções, e
(azimutal ou zenital).
Figura 3 - Superfícies de Desenvolvimento Fonte: [EST04]
2.1.2.2 Cilindro
A esfera com alguns dos seus paralelos e meridianos, esta sendo desenvolvido de uma
envoltória cilíndrico que a tocava unicamente ao longo de uma linha – o equador, o único
círculo máximo dentre os paralelos. Esta sendo apresentado nas figuras 4 e 5.
Figura 4 – Cilindro tangente
Fonte: [EST04]
Figura 5 – Cilindro secante
Fonte: [EST04]
De acordo com Cério de Oliveiro podem-se tirar as seguintes conclusões:
1. As linhas traçadas na esfera foram transferidas para a superfície de desenvolvimento, por
meio de projeções partidas do centro da esfera.
23
2. O equador é a única linha projetada que conserva a dimensão original.
3. Os demais paralelos já não conservam as mediadas originais. Ao contrário, guardam todos
eles iguais comprimentos – um absurdo – em relação ao equador.
4. O pólo ou mesmo as áreas próximas ao pólo não tem possibilidade, aí, de ser projetada.
5. Apenas o equador é tangente à superfície cilíndrica. Os meridianos constituem linhas retas
paralelas entre si, pois seus planos na esfera contem o eixo do cilindro, e o interceptam
segundo as suas geratrizes.
2.1.2.3 Cônica
A esfera projetando-se a partir do equador, numa tangente, em um dos paralelos (o
primeiro a partir do equador). Representada nas figuras 6 e 7.
Figura 6 – Cônica tangente
Fonte: [EST04]
Figura 7 – Cônica secante
Fonte: [EST04]
Conclusão segundo Cério de Oliveiro:
1. As linhas traçadas na esfera, a partir do equador, até o pólo, foram projetadas para a
superfície de desenvolvimento, a partir de certo ponto de interior da esfera.
2. A única linha de verdadeira grandeza é o paralelo de tangência.
3. O pólo é projetado devido à forma peculiar do cone, e, em razão disso, os mediríamos
projetados se cruzam com a esfera.
4. O vértice do cone se encontra no prolongamento do eixo da esfera (projeção cônica
normal). Ao projetarmos os paralelos e meridianos sobre a superfície cônica, concluímos
que os paralelos representados por arcos de círculos concêntricos no vértice, e os
meridianos, por retas, correspondentes às geratrizes do cone, e, portanto, concorrem em
seu vértice (as projeções cônicas podem ser consideradas cilíndricas quando o ápice do
cone se achar a uma distancia infinita da esfera).
2.1.2.4 Plano
O plano é tangente à esfera no pólo. Em conseqüência, todas as linhas traçadas na
esfera são projetadas no plano, partidas de certo ponto do interior da esfera. Veja figura 8 e 9.
24
Segundo Cério de Oliveiro conclui-se:
Figura 8 – Plano tangente
Fonte: [EST04]
Figura 9 – Plano secante
Fonte: [EST04]
1. O pólo, ponto em que a esfera é tangente, é projetado no centro do plano.
2. Os paralelos, em conseqüência, são arcos de círculos concêntricos, como a esfera
terrestre.
3. Os meridianos, irradiando-se do pólo, são projetados em linhas retas.
4. À medida que se afastam da superfície de tangencia (o pólo), não conservam as linhas
e as proporções existentes na esfera. Ao contrário, tanto o espaçamento quanto as
dimensões dos paralelos e meridianos crescem infinitamente.
2.1.2.5 Condições que devem ser cumpridas pelas projeções
Pode ser observado que todas as três projeções de linhas ou de pontos da esfera em
uma superfície plana ou na superfície de desenvolvimento, nenhuma consegue obter uma
projeção sem ter um significativo grau de anormalidade, as quais dificultam a questão
essencial em cartografia, que é a precisão métrica da representação de detalhes topográficos.
Em razão desses problemas foram estudadas outras formas de projeções, visando
resolver os problemas nos quais os três métodos não conseguiam resolver, contudo ao
resolver uma anormalidade outro aparecia, dificultando a projeção absolutamente livre de
inconveniências.
Desta maneira, não existe nenhuma projeção que elimine todos os tipos de deformação
advindas da transformação da esfera em um plano. Torna-se possível que uma carta “conserve
a mesma escala em todas as direções e em todos os pontos; em outras palavras, uma carta não
pode representar com toda precisão o tamanho ou a forma dos acidentes geográficos em todos
os pontos da carta” [DEETZ]
Assim sendo devemos escolher as propriedades que possam atender melhor nossos
objetivos na construção de uma boa carta:
1. Manutenção da verdadeira forma das áreas a serem representadas (conformidade).
25
2. Inalterabilidade das dimensões relativas das mesmas (equivalência).
3. Constâncias das relações entre as distâncias dos pontos representados e as distâncias
dos seus correspondentes (eqüidistâncias).
4. Representação dos círculos máximos para o meio de linhas retas.
2.1.2.6 Projeções equivalentes
De acordo com Aurélio Buarque de Holanda Ferreira equivalente significa “de igual
valor”. Projeções equivalentes têm a propriedade de não deformar as áreas, conservando
assim, quanto à área, uma relação constante com as suas correspondentes na superfície da
Terra.
As projeções de mapas que mantêm a área constante em toda a superfície do mapa são
chamadas de igual área ou projeções equivalentes. Foram desenvolvidas várias projeções
equivalentes na tentativa de minimizar a distorção de outras propriedades geométricas
mantendo a área constante.
As Projeções equivalentes são bastante usadas para mapas temáticos que mostram
distribuição de cenários como população, distribuição de terras agricultáveis, áreas florestadas
etc.. Também são chamadas projeções de igual área, homolográfica, ou equiareal.
As quadrículas de um mapa, formadas por paralelos e meridianos, só podem guardar,
entre si, a relação de tamanho, se modificar a forma dessas quadrículas. Ora, quaisquer destas
quadrículas, na esfera terrestre, são compostas de paralelos e meridianos que se cruzam em
ângulos retos. A deformação neste caso é logo percebida pela alteração dos ângulos. Mas
como a recíproca nem sempre é verdadeiro, também aqui se pode afirmar que sempre ama
quadricula em ângulos retos deixa de ser deforme [CCM93].
2.1.2.7 Projeções conformes
A propriedade definidora das projeções conforme é que em qualquer ponto no mapa, a
escala é a mesma em todas as direções sobre o ponto. A implicação desta propriedade é que
ângulos sobre um ponto são mostrados corretamente e assim sendo, pode-se esperar a
representação de formas corretamente.
Apesar da escala do mapa variar de ponto a ponto, a propriedade de representação
correta de ângulos só se aplica aos ângulos que têm lados pequenos. As formas de áreas
pequenas são preservadas nesta projeção, mas as formas de áreas maiores são distorcidas.
Projeções conformes são aquelas que não deforma os ângulos e em decorrência dessa
propriedade, não deforma, igualmente, a forma de pequenas áreas. Outra particularidade é que
26
a escala, em qualquer ponto é a mesma, seja na direção que for, embora, por outro lado, mude
de um ponto para outro, e permaneça independente do azimute em todos os pontos do mapa.
Ela só continuará a ser a mesma, em todas as direções de um ponto, se duas direções no
terreno, em ângulos retos entre si, forem traçadas em duas direções que, também, estejam em
ângulos retos, e ao longo das quais a escala for a mesma [CCM1993].
2.1.2.8 Projeções eqüidistantes
As Projeções eqüidistantes preservam a escala em alguma parte do mapa, não sendo
possível representar todas as distâncias corretamente em escala, porém, é possível produzir
uma projeção tal que todas as distâncias a partir de um ou dois locais sejam verdadeiras em
escala ou na quais todas as distâncias medidas perpendicularmente a uma linha sejam
verdadeiras em escala.
Não apresenta deformação linear, ou seja, os comprimentos são representados em
escala uniforme. A condição de eqüidistância só é conseguida em determinada direção e se
classifica (conforme no trabalho de Almirante De Bakker) em meridiana, transversal e
azimutal ou ortodromica.
2.1.2.9 Projeções azimutais
São executadas a partir de um plano tangente sobre a esfera terrestre; o ponto de
tangência se torna o centro dessa representação cartográfica. As áreas próximas a esse ponto
de tangência apresentam pequenas deformações; entretanto, as mais distantes são muito
distorcidas, ou então desaparecem porque elas abrangem apenas um hemisfério quando
centradas num dos pólos. Abaixo, um exemplo de projeção azimutal.
Quando a projeção azimutal é centrada num dos pólos, os meridianos são
convergentes neste centro da projeção e os paralelos são concêntricos e a superfície abrangida
é apenas a de um hemisfério (N ou S).
As projeções azimutais são as mais usadas geopoliticamente, pois podem realçar o
"status" de um país em relação aos demais da Terra. Durante a Guerra Fria, por exemplo, ora
se centrava em Washington, ora em Moscou; podiam ser controlados os mísseis e ogivas
nucleares apontados para uma ou para outra superpotência, cujas rotas passavam pela Zona
Polar Ártica. A Europa Ocidental (sob influência americana) e a Oriental (sob influência
soviética) poderiam ser visualizadas através dessa projeção.
Os agentes da globalização, como os bancos internacionais e as transnacionais, dão
preferência à projeção azimutal, colocando evidentemente o ponto de tangência em suas
27
sedes, nos países centrais.
Os mapas aeronáuticos e de navegação marítima também usam a projeção azimutal,
visto que a maior parte do comércio internacional e transportes de cargas e pessoas se fazem
no hemisfério norte, onde se concentram os países desenvolvidos.
2.1.2.10 Projeções afilático
A projeção afilática, igualmente conhecida como arbitrária, nos Estados Unidos, não
possui nenhuma das propriedades dos quatro tipos, isto é, equivalência, conformidade,
eqüidistância e azimutes certos, ou seja, as projeções em que as áreas, os ângulos e os
comprimentos não são conservados.
2.1.2.11 Datum Horizontal
Concluiu-se ao longo dos anos que o modelo matemático mais adequado para a
representação da Terra é o elipsóide de revolução, porém, vários países e continentes
adotaram elipsóides de parâmetros ligeiramente diferentes, com objetivo de que se ajustassem
localmente melhor às suas regiões específicas e produzissem resultados locais mais precisos.
Portanto, o modelo da Terra usado pelos Estados Unidos é um elipsóide diferente do elipsóide
usado pelo Brasil que é por sua vez diferente do usado pela Rússia. Assim, existem vários
modelos locais e a adoção de um modelo global, que seria ideal, esbarra nas fronteiras
políticas.
Define–se Datum Horizontal como um sistema de referência padrão adotado por um
país, uma região ou por todo o planeta ao qual devem ser referenciadas as posições
geográficas (latitude e longitude ou coordenadas cartesianas). É fundamental que os dados
geográficos de um mesmo projeto de Geoprocessamento estejam referenciados ao mesmo
Datum Horizontal para evitar incompatibilidades. Um datum é constituído pela adoção de um
ELIPSÓIDE DE REFERÊNCIA que representará a figura matemática da Terra, um PONTO
GEODÉSICO ORIGEM e um AZIMUTE inicial para fixar o sistema de coordenadas na Terra
e servir como marco inicial das medições de latitudes e longitudes. O critério para escolha do
Ponto Geodésico Origem é a máxima coincidência entre a superfície do geóide e do elipsóide.
Portanto, um mesmo ponto do terreno terá valores de coordenadas diferentes quando referidas
a diferentes Datum.
No Brasil lidamos basicamente com três datum, a saber: SAD-69, que é o datum local
oficial. Córregos Alegres, que é o datum local mais antigo, referenciados ao qual existem,
ainda, vários trabalhos e WGS-84, que é o datum mundial (global) utilizado pelo Sistema
28
GPS.
O WGS-84 é dito um datum global e geocêntrico, pois o elipsoide adotado (GRS80)
ajusta-se à Terra como um todo e a origem dos seus eixos coordenados é no geocentro. No
datum global o elipsóide é fixado a Terra pelo Equador e meridiano de Greenwich (não
necessita de Ponto Geodésico Origem nem de Azimute inicial).
2.1.2.12 Datum Vertical
As altitudes são referidas ao nível médio das águas tranqüilas dos mares, ou seja, à
superfície do geóide. Porem, como ocorre com o datum horizontal, cada país mede e adota o
seu próprio nível do mar. O nível do mar sofre influência de vários fatores tais como ventos,
atração do Sol e da Lua, densidade das massas continentais e dos fundos do oceano, correntes
marítimas etc.. Para obter um valor preciso é necessário tomar medidas da variação das marés
durante um período de aproximadamente 19 anos.
Assim, DATUM VERTICAL um sistema padrão ao qual devem ser referenciadas as
altitudes de um país ou região. Geralmente é a média das observações de um marégrafo que
tem o registro das variações de marés por um período de pelo menos 19 anos. É fundamental
que os dados altimétricos de um mesmo projeto estejam referenciados ao mesmo Datum para
evitar incompatibilidades.
2.1.2.13 Sistema de Coordenadas Geodésicas
O sistema de coordenadas geodésicas constitui um sistema eficiente para localização
inequívoca da posição de objetos, fenômenos e acidentes geográficos na superfície terrestre.
Neste sistema a Terra é dividida em círculos paralelos ao Equador chamado PARALELOS e
em elipses que passam pelos pólos terrestres (perpendiculares aos paralelos) chamadas
MERIDIANOS. Cada ponto na Terra terá um único conjunto de coordenadas geodésicas
definidas por:
Latitude Geográfica ou Geodésica (ϕ): ângulo entre a normal ao elipsóide no ponto
considerado e sua projeção no plano equatorial. É medido no plano do meridiano que contém
o ponto considerado. Positiva a Norte (0 a +90°), negativo Sul (0 a –90°).
Longitude Geográfica ou Geodésica (λ): ângulo diedro entre os planos do meridiano de
Greenwich e do meridiano que passa pelo ponto considerado. Positiva a Este (0 a +180°),
negativa a Oeste (0 a 180°)
Altitude Ortométrica (H): distância vertical que se estende do nível médio do mar (Geóide =
Datum Vertical) até o ponto considerado.
29
2.1.2.14 Norte Geográfico e Norte Magnético
Em um lugar qualquer, o Norte Geográfico é definido pela direção dos meridianos
geográficos e o Norte Magnético é definido pela direção da agulha da bússola. O Pólo Norte
Magnético descreve um lento movimento, aproximadamente circular e de período secular, em
torno do Pólo Norte Geográfico considerado fixo. Existe, portanto, um ângulo entre o Norte
da bússola e o Norte Geográfico. A magnitude deste ângulo depende da localização do
observador na Terra. Todas as medidas de azimutes feitas à bússola são magnéticas, os
azimutes obtidos nas cartas, mapas ou através de cálculos geodésicos são azimutes
geográficos. Assim, quando se trabalha com os dois processos (caso da navegação) é
necessário fazer a conversão. O ângulo de conversão é chamado Declinação Magnética e pode
ser obtido através de cartas magnéticas ou de modelos digitais do campo magnético terrestre.
É importante ressaltar que o Norte magnético sofre perturbações, é impreciso e as melhores
bússolas fornecem medidas com erro de, pelo menos, meio grau, portanto as bússolas só se
prestam para orientações aproximadas.
2.1.2.15 Sistema UTM
Na realidade, a conhecida UTM não é uma projeção, mas um sistema da projeção
transversa de Mercátor (conforme de Gauss). Surgiu o sistema em 1947, para determinar as
coordenadas retangulares nas cartas militares, em escala grande, de todo o mundo.
Estabelece o sistema que a Terra seja dividida em 60 fusos de seis graus de longitude,
os quais têm início no antimeridiano de Greenwich (180º), e que seguem de oeste para leste,
até o fechamento neste mesmo ponto de origem.
Quanto à extensão em latitude, os fusos se original no paralelo de 80ºS até o paralelo
84ºN.
Se, em relação à longitude, os fusos são número 60, no que toca à latitude, a divisão
consiste em zonas de 4º, e isto está vinculado ao tamanho da carta de 1:100.000, e não à
projeção. Os fusos são decorrentes da necessidade de se reduzirem às deformações. Além dos
paralelos extremos (80ºS e 84ºN), a projeção adotada, mundialmente, é a estereográfica polar
universal.
Se fixarmos a nossa atenção em qualquer uma dessa 1.200 quadrículas, verificaremos
que os 6 graus de longitude apresentam as seguintes características: os dois meridianos
laterais são múltiplos de 6, assim como o meridiano central é de 6 mais 3. A figura 10
assinala, a propósito, duas quadrículas localizadas na região Sudeste: a primeira, com o
meridiano central de 51º e os dois meridianos laterais de, respectivamente, 54º e 48º; a
30
segunda, com o meridiano central de 45º e os dois laterais de, respectivamente, 48º e 42º.
Quanto aos limites em latitude, temos, para ambas as quadrículas, os paralelos de 28º e 20º.
Figura 10 – Sitema UTM
Fonte: [CCM93]
Para criar o sistema foram utilizados uma superfície de projeção com 60 cilindros
transversos e secantes, à superfície de referência (elipsóide), cada uma com amplitude de 6º
em longitude. Seu uso é limitado entre os paralelos 80º S e 84º N.
Os cilindros são distribuídos na superfície de referência, de modo a abranger fusos de
6º de amplitude, compreendidos entre as longitudes múltiplas de 6º + 3º (..., 57º, 51º, 45º,...).
Sobre este meridiano central (M.C.), existe uma deformação dos cilindros com a superfície de
referência - as linhas de secância - o coeficiente de deformação linear é unitário. Não existem
deformações lineares nestas regiões.
Cada um dos fusos chama fusos UTM, tem origem na interseção do seu meridiano
central com a linha do Equador. As coordenadas UTM destes pontos são x=E
(Este)=500.000,00 m e y=N (Norte)=10.000.000,00m, no Hemisfério Sul, e y=N=0,0m, no
Hemisfério Norte.
As coordenadas UTM são obtidas a partir de coordenadas geográficas, latitude e
longitude de pontos de interesse, usando-se fórmulas complexas. O coeficiente de deformação
linear (k), que varia de 0,9996 sobre o M.C. a 1,001 nos extremos do fuso, passando pelo
31
valor unitário sobre as linhas de secância, também é obtido a partir de fórmulas, sendo função
das coordenadas E e N dos pontos em questão.
O sistema UTM é conforme, as distâncias e áreas apresentam deformações. A
deformação de área é função da posição ocupada pelos pontos dentro de um fuso UTM. Esta
variável é conhecida como coeficiente de deformação linear e representada pela letra grega
kapa (k). A orientação das figuras também pode ser considerada pseudodeformação, a não ser
no meridiano central de cada fuso, onde o Norte da quadrícula UTM (NQ) coincide com o
Norte Verdadeiro (NV). Em todas as demais regiões dos fusos esses dois eixos formam entre
si, um ângulo denominado Convergências Meridianas, representadas pela letra grega gama
(y).
Porém, este tipo de projeção pode possuir uma ou outra propriedade que justifique a
sua construção. Por exemplo, a gnômica, mesmo apresentando todas as deformações, possui a
excepcional propriedade de representar as ortodromias retas.
2.2 DADOS GEOGRÁFICOS
As informações para uma feição geográfica possuem quatro características principais:
a posição geográfica (localização); os atributos (dados alfanuméricos); relacionamentos
topológicos (caracterizam relacionamentos de vizinhança ou de conexão entre objetos); e o
componente tempo (se refere ao período ou época da ocorrência do fenômeno ou fato
geográfico) caso for trabalhar com tempo/espaço. Estes componentes são simplesmente as
respostas as seguintes perguntas: onde, o que, qual o relacionamento com outras feições
espaciais, e quando ocorreu o fato (ou fenômeno) geográfico. Uma vez dentro de um SIG,
estes dados podem ser classificados em três categorias principais:
• Dados Convencionais - atributos alfanuméricos tradicionais, que podem ser tratados
por um SGBD convencional (ex.: nome e população de uma cidade);
• Dados Espaciais - atributos que descrevem a geometria e a localização do fenômeno
geográfico. Possuem propriedades geométricas e topológicas (ex.: limite geográfico de um
lago);
• Dados Pictóricos - atributos que armazenam imagens (fotos) (ex.: fotografia aérea de
uma cidade).
Em um SIG, as estruturas básicas (figura 11) para representar objetos espaciais (dados
geográficos) são:
• Pontos - adimensionais representam entes cuja propriedade espacial mais
significativa é a sua localização pontual. As coordenadas dos objetos tipo ponto podem ser
32
armazenadas como dois atributos extras na tabela de atributos da entidade;
• Linhas - unidimensionais representam entes onde a localização, a forma e
conectividade são relevantes. Aparecem normalmente em aplicações de infra-estrutura (redes
viárias), redes de utilidade pública (gás, eletricidade, água etc.), linhas de tráfego aéreo, redes
hidrográficas etc.. As redes são formadas basicamente por dois construtores que são os nós
(junções e terminadores) e as ligações (arcos entre dois nós);
• Polígonos (áreas, regiões) - bidimensionais, representam unidades com diferentes
finalidades. Por exemplo, podem ser utilizados para representar regiões homogêneas (mapas
temáticos).O relacionamento de vizinhança entre entidades bidimensionais (áreas) é
representado através de estruturas de dados que armazenam informações sobre polígonos
adjacentes. A estratégia mais utilizada é baseada no armazenamento de atributos dos arcos,
acrescidos de dois apontadores extras, referentes aos polígonos localizados à esquerda e à
direita do arco, percorrido no sentido nó-origem-nó-destino.
• Superfícies (volumes) - tridimensionais representam objetos com comprimento,
altura e largura.
Um mesmo objeto pode ter diferentes representações em função da escala ou do nível
de detalhe. Assim, um lago pode ser representado por uma região (polígono) ou por um ponto,
em função da escala.
Figura 11 – Estruturas básicas para representar dados espaciais
Fonte: [PAR 94].
2.3 ESTRUTURA DE REPRESENTAÇÃO
Tradicionalmente, os dados geográficos têm sido representados por modelos
analógicos bidimensionais, mais conhecidos por mapas. Na figura 12, podemos ver os tipos
33
de modelos cartográficos existentes [PEU 84].
Quando da atualização do mapa (modelo analógico), um novo mapa deve ser
desenhado, ou o antigo modificado. Todo este processo é manual, ou seja, custoso, demorado.
Ele requer habilidade e precisão no desenho de cada mapa.
Modelo AnalógicoMapa com curvas de nível
Modelo VetorialOrganização do vetorElemento básico = linha
Modelo Matricial (Raster)Organização da gradeElemento básico = Célula
Figura 12 - Tipos de modelos cartográficos
Fonte: [PEU 84].
Os outros dois tipos básicos de modelos de dados geográficos armazenam e
representam a informação na forma digital; vetor e raster (figura 13).
Figura 13 - Cadeira no formato raster e vetorial
Fonte: [BUR 92].
Em ambas as estruturas, a informação espacial é representada utilizando unidades
34
homogêneas. Na abordagem raster, as unidades homogêneas são as células. É usado um
número muito grande de células relativamente pequenas, todas do mesmo tamanho. Arquivos
de dados raster contêm milhões de células e a posição de cada unidade é rigidamente definida.
Na abordagem vetorial, as unidades homogêneas são pontos, linhas e polígonos. Comparado
com a estrutura raster, estas unidades homogêneas são relativamente poucas em números, e
variáveis em tamanho. Em um arquivo vetorial, o número de elementos podem ser dez ou mil,
mas não milhões como é o caso dos arquivos raster.
2.3.1 Estrutura Raster (Matricial)
A estrutura matricial possui como unidade básica lógica uma célula de uma malha (um
pixel), O espaço é regularmente subdividido dentro de uma grade regular de células (podendo
ser irregular também) e a localização de cada célula é definida por um número da linha e da
coluna. Cada célula da grade contém um valor único. A estrutura matricial (raster) define um
espaço, que quando preenchido, define a localização das entidades. De acordo com [PAR 94],
a estrutura matricial (raster) divide o espaço geográfico em elementos discretos.
Existem três tipos básicos de modelos raster, cada um possui diferenças funcionais que
são baseadas nas diferenças geométricas do polígono. Este três tipos básicos são: quadrático,
triangular e hexagonal.
O preenchimento das células se dá numa seqüência específica, linha a linha, da
esquerda para a direita. Cada conjunto de células (grade) está associado à uma camada (layer),
ou seja, cada conjunto de células armazenam valores relativos a um variável (tema) sendo que
cada célula contém somente um tipo de valor. Tipo de solo e vegetação de uma área deve ser
armazenado em arquivos diferentes. Operações sobre múltiplos arquivos raster envolvem a
recuperação e processamento dos dados de uma célula (posição de uma célula)
correspondente em diferentes arquivos.
Para encontrarmos todas as células com floresta de Pinus e solo arenoso, cada célula
no arquivo solos (arquivo que trata o tema tipos de solos) e cada célula correspondente, de
mesma localização (mesma linha - coluna), no arquivo floresta devem ser recuperados e
avaliados. Todas aquelas células que foram codificadas como floresta de Pinus, além disso,
como solo arenoso, devem ser identificadas e poderam ser colocadas em um novo arquivo.
Este procedimento é chamado de Análise de Overlays [ARO 89].
2.3.2 Métodos de Compactação de Dados Raster
Nos SIG's, em especial aqueles que utilizam à estrutura raster, tem um problema que
35
diz respeito ao volume de dados a serem armazenados. Como no modelo raster cada célula
representa uma área da superfície terrestre, e o atributo de cada célula é armazenado como um
único valor, então o número total de valores a serem armazenados é o número de linhas vezes
o número de colunas. Quanto menor a área representada por uma célula, maior é a resolução
dos dados, e maior será o arquivo que armazena estes dados. O tamanho do arquivo aumenta
de acordo com a resolução. Por exemplo, se uma célula representa 250m x 250m de área,
então à distância de 1km deverá ser representada por 4 células, e uma área de 1km x 1km
deverá ser representada por 16 células. Se a resolução for aumentada, isto é, uma célula
representar 100m x 100m, estes mesmos 1km x 1km deverá ser representado por 100 células
[ARO 89]. Por estas razões os arquivos tendem a ser grande, e necessitam de métodos de
compactação, tais como:
• Chain Codes (Códigos de Cadeia) - os limites de uma região são dados por sua
origem e uma seqüência de vetores unitários nas direções leste, norte, oeste e sul,
devendo o limite ser percorrido no sentido horário.
• Run-Length Codes (Códigos em Sequência) - o armazenamento de
cada região é feito linha a linha, da esquerda para a direita, indicando célula inicial
e final da linha.
• Block Codes (Códigos de Blocos) - a idéia do Run-length codes foi extendida para
duas dimensões. Blocos quadrados são utilizados para “ladrilhar” a área a ser
mapeada.
• Quadtrees (Árvores Quaternárias) - este método de compactação se baseia em
divisões sucessivas em matrizes de 2n x 2n quadrantes, aonde a região com
atributos vai sendo delineada pela subdivisão em quadrantes.
2.3.3 Vetorial
O modelo de representação vetorial tem como primitiva principal o Ponto, porém, são
utilizados três construtores básicos: o ponto, a linha e o polígono. As coordenadas x e y de um
ponto correspondem à localização, em um sistema de coordenadas específico, de entidades
que são representadas sem dimensões espaciais. A linha, formada por uma cadeia de
segmentos de linha reta, ou mais especificamente, por uma lista de coordenadas de pontos, é o
objeto espacial usado para representar no banco de dados, as entidades da realidade que
possuem extensão linear. O polígono é o objeto espacial que representa as entidades com
extensões bidimensionais (área), através da definição do contorno da área da entidade. O
polígono é formado por uma cadeia fechada de segmentos de linha, podendo ou não, ter
36
outros polígonos embutidos em seu interior.
Existe uma enorme variedade de técnicas de armazenamento de objetos espaciais, que
são baseadas no modelo vetorial [LAU 92]. Essas técnicas podem ser classificadas de acordo
com o tipo de objeto armazenado, ou seja, ponto, linha ou polígono. Características do tipo de
aplicações a que se destinam também são importantes. Por exemplo, em um sistema de
roteamento de veículos, uma característica fundamental é a conectividade entre as arestas da
rede viária, para possibilitar operações de análise de melhor caminho.
Outra classificação existente leva em consideração se os relacionamentos topológicos
são, ou não, armazenados. Aronoff [ARO 89], divide os diversos modelos vetoriais em dois
grupos: Modelos de Dados Spaghetti e Modelos de Dados Topológicos.
Os Modelos de Dados Spaghetti utilizam estruturas de dados que armazenam os
polígonos/linhas como seqüências de coordenadas de pontos. Nestes modelos, os limites entre
duas áreas adjacentes são registrados (digitalizados) e armazenados duas vezes, uma para cada
polígono. Estes modelos são utilizados em muitos pacotes de cartografia automatizada, onde
as informações sobre os relacionamentos entre as entidades não são importantes [NCG 90].
Neste modelo, o mapa é lido linha a linha, em coordenadas XY. Pontos são
codificados como uma coordenada XY, as linhas como uma lista de coordenadas XY e as
áreas (polígonos) como um loop fechado de coordenadas XY, que definem sua fronteira.
Quando um polígono tem seu fronteiro adjacente à fronteira de outro polígono, as
coordenadas XY desta fronteira (compartilhada pelas duas áreas adjacentes) deve ser
registrada duas vezes. Os relacionamentos espaciais não são armazenados (figura 14) [ARO
89] e [PEU 84]. Possui redundância de coordenadas.
37
Figura 14 – Modelo Spaghetti
Fonte: [PEU 84]
Este modelo é, segundo [PEU 84], ineficiente para muitos tipos de análise espacial, já
que todos os relacionamentos espaciais devem ser gerados no momento da análise (não são
armazenados). Porém, o modelo spaghetti é muito bom quando utilizado para geração de
mapas (impressão), porque ele não armazena os relacionamentos espaciais, irrelevantes para a
impressão do mapa.
As maiorias dos SIG utilizam os Modelos de Dados Topológicos, os quais usam
estruturas de dados que possibilitam o armazenamento de alguns tipos de relacionamentos,
sendo que a ênfase principal é dada nos relacionamentos de conectividade entre linhas de uma
rede (contendo arestas interligadas por nós) e nos relacionamentos de vizinhança entre áreas
(representadas por polígonos) adjacentes. Outros tipos de relacionamentos entre objetos
espaciais, como por exemplo, se uma linha "cruza" uma área ou se um ponto está "dentro" de
uma área, são calculados a partir das coordenadas desses objetos.
Na figura 15 é mostrado um exemplo de utilização do modelo topológico, onde a topologia
é registrada em três tabelas, uma para cada tipo de elemento espacial, e as coordenadas dos
dados (pontos, arcos, nós, polígonos) são armazenadas numa quarta tabela. Este exemplo
ilustra um modelo topológico denominado Modelo Arco-Nó. A entidade lógica básica é o arco,
38
que possui uma série de pontos que iniciam e terminam em nós. Um nó é uma intersecção de pontos,
onde um ou mais arcos se encontram [ARO 89].
Com este modelo, o relacionamento espacial mais elementar é armazenado e pode ser
utilizado para análises espaciais. Esta informação topológica permite que definições espaciais de
entidades tipo pontos, linhas e áreas (polígonos) sejam armazenadas de forma não redundante (ao
contrário do que acontece no modelo spaghetti). Isto é vantajoso para polígonos adjacentes [PEU
84]. Com esta estrutura, também fica mais rápido o cálculo de análises espaciais. A desvantagem é
que possui uma estrutura mais complexa que a "spaghetti", leva tempo para criar uma estrutura
topológica dos dados e atualizações de mapas levam muito tempo.
Figura 15 – Modelo Topológico Fonte: [PEU 84]
O modelo “Triangulated Irregular Network” ou TIN (Rede Irregular Triangularizada
ou Modelo de Elevação), também é um modelo topológico baseado em vetor e representa a
superfície do terreno como um conjunto de triângulos irregulares interconectados. Para cada
vértice do triângulo, existe uma coordenada XY (localização) e uma cota Z (elevação). O
maior problema esta no fato de existirem muitas triangularizações possíveis que podem ser
gerados a partir de um mesmo conjunto de pontos. Na figura 16 é ilustrada essa estrutura.
Mais detalhes sobre este modelo pode ser encontrado em [ARO 89], [PEU 84], [GOO
90] e [GOO 91].
39
Figura 16 - TIN (Rede Irregular Triangularizada)
Fonte: [PEU 84]
2.3.4 Comparação entre Raster e Vetor
Na tabela 1 estão listadas as principais vantagens e desvantagens de cada estrutura
(ARO, 1989).
RASTER VETOR
Vantagens Desvantagens Vantagens Desvantagens A estrutura raster é quase que
obrigatório para uma
manipulação eficiente de
imagens de satélite
Ineficaz para realizar análises
espaciais complexas,
condicionadas por vários
atributos descritivos dos temas
mapeados.
Estrutura compacta A representação da alta
variabilidade espacial é
ineficiente
SIG’s matriciais são de custo
baixo
Menos compacto que o
vetorial
Boa representação de
linhas e polígonos
Combinação de layers
complexa
Estrutura de dados mais simples Difícil de se representar
relacionamentos topológicos
Precisão (cálculos) Visualização e plotagem
caras
Operações de overlay são
facilmente e eficientemente
implementadas
Desempenho comprometido
em aplicações que demandam
resoluções elevadas
Melhor descrição
topológica
Manipulação de imagens
de satélite não pode ser
efetivamente feita no
domínio vetorial
Bom desempenho em operações
booleanas
Menor precisão Suporta operações que
requerem informações
topológicas
Estruturas de dados
complexas (mais que o
modelo raster)
Reduz redundâncias
devido ao uso de
coordenadas
Alta qualidade nas saídas
gráficas
Tabela 1 - Vantagens e das estruturas desvantagens de representação Raster e Vetorial.
O modelo de representação matricial é mais adequado em aplicações voltadas às
40
áreas ambientais, enquanto que o modelo vetorial é mais adequado para aplicações
relacionadas às invenções humanas, como cadastro de propriedades, redes de infra-
estruturas etc..
Normalmente, as aplicações onde às operações de análise espacial necessitam de
informações topológicas, são desenvolvidas utilizando-se o formato vetorial, enquanto que
as aplicações que necessitam realizar operações de sobreposição (overlay) a partir de dois
ou mais temas, utilizam o formato matricial. Os SIG geralmente fornecem suporte para os
dois formatos, incluindo procedimentos para conversão entre eles.
Como uma grande quantidade de dados é introduzida no sistema, a partir da
digitalização de mapas disponíveis em folhas de papel, os dados muitas vezes são
armazenados no formato vetorial e convertidos para o formato matricial para serem
utilizados em operações de overlay. Os resultados dessas operações também podem ser
reconvertidos para o formato vetorial, para serem armazenados de forma mais eficiente.
41
3 BANCO DE DADOS GEOGRÁFICO
3.1 CONCEITOS DE BÁSICOS DE BDG
O conjunto de definições a seguir, é o resultado de um trabalho de padronização de
termos, que foi proposto pelo US National Digital Cartografic Standart. Estas definições
foram extraídas de [NCG 90]. Neste trabalho, procurou-se empregar os conceitos de acordo
com estas definições.
3.1.1 Identidade
Elementos da realidade modelados em um banco de dados geográfico têm duas
identidades: o elemento na realidade, denominado entidade e o elemento representado no
banco de dados, denominado objeto. Uma terceira identidade usada em aplicações
cartográficas é o símbolo usado para representar entidades/objetos como uma feição no mapa.
3.1.2 Entidade
É um fenômeno de interesse na realidade que não pode ser subdividido em fenômenos
do mesmo tipo. Por exemplo, uma floresta pode ser dividida em florestas menores, enquanto
que uma cidade se for dividida, suas partes não serão cidades e sim bairros ou distritos.
3.1.3 Objeto
É a representação digital de uma (ou parte de uma) entidade. A representação digital
varia de acordo com a escala utilizada (ex.: um aeroporto pode ser representado por um ponto
ou uma área, dependendo da escala em uso).
3.1.4 Tipo de Entidade
É a caracterização de um agrupamento de entidades similares que podem ser
representadas por objetos armazenados de maneira uniforme (ex: o conjunto das estradas de
uma região). Fornece uma estrutura conceitual para a descrição dos fenômenos.
3.1.5 Tipo de Objeto Espacial
Cada Tipo de Entidade em um Banco de Dados Espacial é representado de acordo
42
com um tipo de objeto espacial apropriado. A Tablea 2 mostra os tipos básicos de objetos
espaciais, definidos pelo US National Digital Cartografic Standart e classificados segundo
suas dimensões espaciais:
Dimensão Tipo Descrição
0D ponto Um objeto com posição no espaço, mas sem comprimento.
1D linha Um objeto tendo comprimento. Composto de 2 ou mais objetos 0D
2D área Um objeto com comprimento e largura. Limitado por pelo menos 3
objetos 1D
3D volume Um objeto de comprimento, largura e altura. Limitado por pelo
menos 4 objetos 2D
Tabela 2 - Tipo de Objetos Espacial
3.1.6 Classe de Objeto
Descreve um conjunto de objetos que representa um conjunto de entidades (ex.: o
conjunto de pontos que representam um conjunto de nascentes, postes etc. ou o conjunto de
áreas representando lotes urbanos).
3.1.7 Atributo
Descreve características das entidades, normalmente de forma não-espacial. Exemplos
são os nomes das cidades, diâmetro de um duto etc.
3.1.8 Valor de Atributo
Valor quantitativo ou qualitativo associado ao atributo. (ex.: nome da cidade = 'Porto
Alegre', Diâmetro do duto = 1 ½").
3.1.9 Camada (layer)
Os objetos espaciais em um BD Geográfico podem ser agrupados e dispostos
(apresentados) em camadas (ou temas). Normalmente, uma camada contém um único tipo de
entidade ou um grupo de entidades conceitualmente relacionadas (ex.: uma camada pode
representar somente as rodovias de uma região, ou pode representar também as ferrovias).
3.2 ARQUITETURA DE BANCO DE DADOS ESPACIAL
A existência de diferentes arquiteturas de banco de dados geográficos se deve à
43
necessidade de integração entre dados convencionais e dados espaciais. Essa integração é
fundamental para permitir a análise conjunta de vários tipos de informações e onde elas
ocorrem no espaço.
A integração de dados espaciais com dados convencionais foi uma preocupação
posterior ao desenvolvimento das ferramentas SIG e dos dados SGBDs convencionais. As
ferramentas SIG surgiram inicialmente com a finalidade de processar mapas. Segundo Reeve
(2001), não tinham a capacidade de armazenar dados alfanuméricos, assim, foram
desenvolvidos para prover análises espaciais, visualizações cartográficas e tecnologia de
interface gráfica, não dando tanta importância em oferecer recursos de banco de dados. Por
outro lado, as aplicações envolvendo dados convencionais, se restringiam a relatórios em
forma de tabelas e gráficos. Logo, a necessidade de integração impulsionou o
desenvolvimento de novos mecanismos computacionais de conexão entre esses dois tipos de
dados.
O estudo de alternativas para integração foi necessário devido à natureza dos dados
espaciais, que, até então, eram considerados complexos para as estruturas de dados
convencionais vigentes, baseadas no Modelo Relacional. Como primeira alternativa, as
ferramentas SIG, que inicialmente só armazenavam dados espaciais, passaram a incorporar
SGBDs relacionais em suas arquiteturas, através de uma Arquitetura Dual. na qual o SGBD
relacionai é utilizado somente para armazenar atributos, enquanto que os dados geográficos
são armazenados utilizando-se as estruturas internas da ferramenta SIG. Esta abordagem
apresentou resultados satisfatórios, sobretudo com a melhora do hardware e do software, e
para aplicações stand-alone. Mas, na medida em que foram surgindo as aplicações
distribuídas e a necessidade por segurança (proteção contra falhas), integridade, consistência,
capacidade para armazenar grandes bases de dados e controle de acesso aos dados, questões
até então não atendidas pelas ferramentas SIG, mas consideradas em estado avançado em
SGBDs convencionais, mais uma vez foi necessário repensar as arquiteturas
existentes. À segunda opção foi levar os dados espaciais para os SGBDs convencionais, o que
ficou conhecido como Arquitetura Integrada, na qual ambos os tipos de dados (espacial e
alfanumérico) são armazenados no mesmo banco de dados. A seguir, essas abordagens e suas
implicações são apresentadas em mais detalhes. É importante lembrar que a evolução das
arquiteturas vai de encontro às necessidades do mercado e este exige flexibilidade de acordo
com os requisitos das aplicações.
44
3.2.1 Arquitetura Dual
A maioria das soluções disponíveis no mercado para geoprocessamento utiliza
SGBD’s relacionais, num ambiente dual. Os componentes espaciais e descritivos do objeto
geográfico são armazenados separadamente (figura 17), ligados por um identificador comum.
Para recuperar um objeto, os dois sub-sistemas devem ser pesquisados e a resposta é uma
composição de resultados.
A vantagem desta arquitetura é poder utilizar os SGBD's relacionais de mercado e
implementar métodos eficientes de acesso a dados espaciais. Como os dados espaciais estão
fora do controle do SGBD, esta estrutura não permite que propriedades do SGBD como
otimização de consultas, gerência de transações e controle de integridade e de concorrência
sejam utilizadas para os dados espaciais. As consultas devem ser divididas em duas partes: do
dado descritivo é tratado pelo SGBD e do dado espacial é tratado fora do banco [CÂM 94].
Figura 17 – Arquitetura Dual
O principal problema do "ambiente dual" é o controle de integridade. Podem ocorrer
situações como:
• O arquivo gráfico correspondente à entidade foi removido (através de algum
comando do sistema operacional), mas sua descrição ainda está presente no BD;
• Numa transação diretamente feita no SGBD, as descrições dos elementos são
alteradas, sem a mudança correspondente nos arquivos gráficos associados.
O acesso externo ao BD sempre é possível num ambiente dual [CÂM 94].
45
3.2.2 Arquitetura em Camadas
Os problemas da arquitetura dual são causados porque possui dois gerenciadores de
dados, com responsabilidades distintas. Para remediar este problema, surgiram os SGBDs
com campos longos (figura 18), que são registros binários de tamanho significativo, onde se
podem guardar informações gráficas, numéricas ou pictóricas.
Os "campos longos" possuem mecanismos de proteção de integridade física
(shadowing), mas o SGBD não possui mecanismos de acesso ao conteúdo dos campos longos,
função deixada para um subsistema de armazenamento, implementado sobre o SGBD. Não há
padronização no uso dos campos longos na tecnologia relacional. Com isto, a implementação
desta arquitetura fica dependente do SGBD escolhido [CÂM 94].
Figura 18 – Arquitetura em camadas
Fonte: [CÂM94]
O armazenamento de informações geográficas em "campos longos" pode resolver o
problema de controle de integridade física dos dados, mas continuam as questões sobre
métodos de acesso espacial, otimização de consultas e de gerência de transações.
3.2.3 Arquitetura Integrada
Quando o SGBD é aberto para extensões, pode-se adicionar novos tipos de dados e
métodos de acesso. Neste caso, o gerenciador de dados espaciais estará embutido no SGBD
(figura 19) e a arquitetura resultante é dita integrada.
46
Figura 19 – Arquitetura Integrada
Fonte [CÂM 94]
Além de possuir suporte a "campos longos", o SGBD deve possuir a possibilidade de
definir novos tipos (abstratos) de dados e métodos de acesso associados. O programador do
SIG deve implementar todas as estruturas de acesso no próprio ambiente do SGBD. O
controle de integridade física fica sobre responsabilidade do SGBD [CÂM 94].
Sistemas pós-relacionais, como POSTGRES, e orientados a objetos, como O2 e o
OBJECTSTORE, propõe-se a dar suporte a este tipo de aplicação. O SGBD deve ser
completamente extensível, para permitir que componentes como o otimizador de consultas e o
gerente de transações tenham suas funcionalidades adaptadas para lidar com dados
geográficos.
Esta nova geração de SGBD's (orientados a objetos) vem aparecendo cada vez mais
em artigos sobre SGBD's para aplicações de geoprocessamento [SOU 93].
Uma análise mais detalhada da utilização de SGBDOO para aplicações de
geoprocessamento é encontrada em [RAM 94]. Também é feita uma análise de SGBDR
Estendidos.
Comparando as vantagens e problemas das arquiteturas de SDBG para SIG têm-se a
seguinte tabela.
47
Arquitetura Vantagens Problemas
Dual - Uso de SGDB’s relacionais de
mercado
- Independência de fabricantes de
SGDB’s
- Controle de Integridade
- Otimização de Consultas
Em
camadas
- Controle de Integridade
- Uso de SGBD’s relacionais de
mercado (com campos long)
-Dependência de fabricantes de
SGDB’s
- Otimização de Consultas
Integrada - Controle de Integridade
- Otimização de Consultas e Métodos
de Acesso
- Dependências de fabricantes
- Falta de padronização de
Linguagem de Consulta
Tabela 3 - Vantagens e problemas das arquiteturas dual, em camadas e integrada.
Fonte: [CÂM94]
48
4 INDEXAÇÃO
Uma vez que os dados espaciais foram carregados em tabelas no oracle, índice espacial
pode necessitar ser criado. Os índices espaciais são construídos para a mesma razão que
outros índices são construídos em base de dados convencionais: para o acesso rápido aos
dados. No exemplo de um índice espacial, o índice é construído na coluna espacial (camada)
na tabela para fornecer o acesso rápido aos dados em uma região particular.
O oracle spatial fornece dois métodos distintos para indexação dos dados espaciais, o
Quadtree e o R-tree.
4.1.1 Quad-tree
Uma Quad-tree, segundo Oracle Spatial Training Guide [OST 04], é um mecanismo
de codificação para determinar múltiplas chaves, ou seções, para cada geometria indexada,
como mostra a Figura 20. Seções podem ser imaginadas como retângulos que definem uma
cobertura exclusiva (nenhuma seção se sobrepõe a outra) e exaustiva (as seções cobrem
completamente o objeto) de cada geometria armazenada no layer.
Figura 20 – Decomposição do espaço em Quad-tree
Fonte: Extraído de Oracle Spatial Training Guide [OST 04]
Na estrutura Quad-tree, o processo de decomposição do espaço é conhecido como
tesselação, o qual determina que seções cobrem uma dada geometria. Na tesselação, o espaço
de coordenadas é decomposto de uma maneira regular e hierárquica. No primeiro nível de
decomposição, o espaço é dividido em quatro seções. Cada seção que interage com a
geometria que está sendo decomposta, é também sub-dividida em outras quatro seções e
assim sucessivamente até que se alcance o limite estipulado de divisão representada na figura
49
21.
Figura 21 - Decomposição Sucessiva
Os resultados da tesselação são então armazenados no índice, uma árvore quaternária
cujos nodos, segundo McGill Project 32 (1999), ou são folhas (nodos sem filhos) ou têm
quatro filhos ordenados (ver Figura 22) e a cada folha pode ser associada uma página do
disco. As seções podem ser rapidamente examinadas para verificar alguma interação entre os
layers.
Figura 22 – Exemplo de uma referência de objetos no índice Quad-tree
Fonte: Adaptado [RSV 02]
As seções são linearmente ordenadas de modo a preservar a proximidade espacial.
Existem alguns algoritmos para ordenação tais como as curvas de Peano, Hilbert e Morton. A
Figura 23 mostra a curva de Morton que é utilizada na ordenação dos Quad-trees no ORACLE
SPATIAL, e que também direcionam o caminhamento na árvore.
50
Figura 23 – Caminhamento na Quad-tree: Ordem proposta por Morton
Fonte: Extraído de Oracle Spatial User's Guide and Reference [ORA 01]
4.1.1.1 Critérios de Parada para a Construção do Índice
Segundo McGill Project 32 (1999), geralmente o limite imposto de subdivisão da
Quad-tree está ligado com a capacidade de armazenamento disponível e o tempo de
processamento requerido. Segundo Rigaux, Scholl e Voisard (2002), a divisão é feita até que
o número de seções de cada quadrante seja menor que a capacidade de uma página de
memória. Segundo Oracle Spatial User's Guide and Reference (2001), o limite pode estar
relacionado com a resolução (da seção), ou seja, pode-se determinar um tamanho fixo de
resolução da seção como único fator de controle, assim, a tesselação termina quando o espaço
de coordenadas pode ser decomposto em um número específico de vezes, tendo cada seção o
mesmo tamanho. Ainda segundo Oracle Spatial User's Guide and Reference (2001), índices
espaciais utilizando seções de tamanho fixo facilitam a comparação entre duas geometrias,
que interagem quando compartilham uma ou mais seções.
4.1.1.2 Exemplo de como criar a tesselação
Os limites dados do sistema coordenado de -180 a 180 na longitude, e -90 a 90 na
latitude, o tamanho de uma telha no equador da terra no nível 32 são aproximadamente 9mm
por 4mm. É importante recordar que as telhas estão geradas somente onde há uns dados. Na
hora de criar a indexação será escolhido um nível da telha (ou o tamanho da telha) para um
índice espacial do quadtree.
No exemplo da figura 24, um DBA determinou que um nível 3 é apropriado para esta
geometria. O nível 3 é útil para finalidades ilustrativas somente. Um nível 3 é quase nunca
apropriado a um telhado de uma camada espacial.
Neste exemplo, 16 telhas do nível 3 são geradas para a geometria. As telhas que
cobrem qualquer parte da geometria que está sendo posicionada são armazenadas na coluna
de SDO_CODE da tabela espacial do índice.
Note que apesar da representação das 64 telhas apenas 16 telhas no qual estão os dados
51
são armazenadas na tabela espacial.
Figura 24 - Representação geométrica do Quadtree
Quando índice espacial do Quadtree é criado, uma tabela no oracle com três colonas
será criada:
• SDO_CODE: onde é associada a geometria à telha;
• SDO_ROWID: Este é um ponteiro para trás do ROWID (campo do status que
informa aproximadamente se cada telha cobre a parcela do limite da geometria).
Cada geometria pode ser associada com mais de uma telha, o ROWID de cada
geometria pode parecer na tabela espacial do índice mais de uma vez;
• SDO_STATUS: É um marcador para se a telha é uma telha interior ou uma telha
no limite da geometria que esta associada.
4.1.1.3 Vantagens e Desvantagens
A eficiência deste método, segundo Oracle Spatial User's Guide and Reference
(2001), depende do número de níveis determinado e da variação dos tamanhos das geometrias
dos layers. Quando os mesmos tamanhos de seções são utilizados para cobrir geometrias de
tamanhos pequeno e grande, um grande número de seções será necessário no segundo caso.
Entretanto, se o tamanho da seção for muito grande, essas seções não representarão
geometrias pequenas muito bem. A escolha do tamanho da seção traz conseqüências diretas
52
nos resultados das consultas espaciais.
Segundo Daniel Abugov em Oracle Spatial Discussion Forum [ORA 04], o uso do
índice Quad-tree é indicado para casos em que ocorrem atualizações constantes no banco de
dados, pois o índice continua utilizável por bastante tempo, sem a necessidade de
reconstrução, mesmo havendo atualizações.
Uma desvantagem desse método é que, para geometrias do tipo polígono ou linha, a
duplicação das referências dos objetos ocorre em vários níveis, uma vez que esses objetos
podem ocupar mais de uma seção no espaço.
4.1.2 R-tree
Enquanto os índices do quadtree podem somente posicionar dados bidimensionais, o
indice do R-tree pode ser feito em duas, três, ou quatro dimensões.
Os índices do R-tree são baseados em retângulos limitando do mínimo dados
bidimensionais. Isto significa que um retângulo está construído em cada geometria baseada
nos valores mínimos e máximos de cada dimensão. Ao posicionar dados tridimensionais,
cada entrada de índice é baseada em um volume mínimo ao redor de cada geometria.
Depois que todos os retângulos limitando o mínimo (ou os volumes) são
construídos, os dados estão classificados em uma estrutura de árvore. O índice é
construída e escrita em uma tabela.
Exemplificando conforme a figura 25, o índice R-tree construirá um retângulo mínimo
(o limitando) em torno da geometria. No nível mais baixo de um índice da R-tree, há um
ponteiro da geometria (ROWID) e os MBR (retângulos) associados com essa geometria.
Note que ao contrário dos índices do Quadtree, os índices da R-tree pela definição
começarão somente com uma entrada de índice para cada geometria.
53
Figura 25 - Retângulo limitando a geometria
Depois que o MBR é construído em torno de cada geometria, os dados são agrupados
de tal forma que as geometrias que estão perto das extremidades uma das outras fiquem igual
ao exemplo da figura 26.
Exemplificando observe que a geometria 1 e 2 se agrupam formando a 3 e 4 forma b,
a e b agrupados forma R. 5, 6 e 7 forma S, 8 e 9 forma d e R, S e d formam root, construindo
assim o R-tree.
Figura 26 – Decomposição R-tree (Árvore Balanceada)
Fonte: Extraído de Oracle Spatial Training Guide (OST 04)
No oracle spatial a indexação R-tree é limitada em 35 nós por folhas, assim sendo
54
caso as geometrias que estejam próximas uma das outras ultrapassem esse valor o oracle ira
criar um novo nó gerando outra folha, assim sucessivamente até que todas as geometrias
estejam na arvore.
Segundo [RSV 02], diferente dos métodos apresentados anteriormente, na estrutura do
R-tree a referência de um determinado objeto aparece em apenas um nodo folha. Entretanto,
os retângulos associados com os nodos internos, não podem ser considerados como partições
exatas do espaço, uma vez que pode haver sobreposição desses retângulos.
4.1.2.1 Critérios de Parada para a Construção do Índice
O critério de parada depende do número de geometrias no layer.
4.1.2.2 Vantagens e Desvantagens
Segundo Oracle Spatial User's Guide and Reference (2001), o índice R-tree, em
comparação com o índice Quad-tree requer menos capacidade de armazenamento, são fáceis
de serem criados, são mais rápidos em consultas que levam em consideração o vizinho mais
próximo, mas não é uma boa escolha se houver grande quantidade de atualizações nos dados
espaciais, o que não afeta a performance do Quad-tree.
Segundo Daniel Abugov em Oracle Spatial Discussion Forum [Ora 04], no ORACLE
SPATIAL, para uma utilização completa das funcionalidades do sistema, o índice R-tree é o
mais indicado se os dados envolvidos na consulta forem geodésicos, pois este índice garante
uma resposta mais exata quando se leva em consideração a curvatura da Terra.
4.1.2.3 Tipo de Geometria Associado
O índice R-tree, em adição ao Quad-tree, pode ser utilizado para indexação de pontos
3D e 4D, como nos problemas críticos de exploração de óleo, arquitetura, engenharia e
aplicações científicas. No caso de objetos 3D a aproximação é em relação ao mínimo volume
envolvente (MVE), mas serão considerados neste trabalho apenas objetos 2D.
4.1.2.4 Quadtrees ou R-trees?
Alguns pontos positivos e negativos do R-Tree:
• R-tree é mais fácil de criar, não precisa de nenhum conhecimento prévio das
geometrias para criar o índice;
• R-tree é mais rápido em localizar seu vizinho, pois ele esta no mesmo ramo da
árvore, precisando apenas ir um nível acima para localizar seu vizinho;
• Usa menos armazenamento, pois cada MBR é uma geometria;
55
• Suportam mais de duas dimensões;
• Os índices da R-tree são os únicos tipos do índice que tem a sustentação geodésica
completa;
• Caso houver necessidade de inserir ou atualizar os dados espaciais o R-tree pode
exceder o tempo de reindexação, pode ser lenta a reconstrução do novo índice.
Talvez seja melhor excluir e criar novamente o índice;
Alguns pontos positivos e negativos do Quadtree:
• Mantêm sua eficiência após manutenções como inserir/excluir/atualizar
• Requer um prévio conhecimento das geometrias para que seja escolhido o nível da
telha, a fim de criar o índice;
• É bidimensional, só suporta duas dimensões;
• Não pode ser geodésico: Os índices geodésicos incluem uma terceira dimensão no
índice;
• Não suporta a pergunta do vizinho o mais próximo incremental, essa pergunta
obrigara o banco a fazer cálculos de comparação que ira elevar muito a procura,
tornando essa consulta muito lenta;
4.1.2.5 Sintaxe para criar um índice
A sintaxe requerida para construir um novo índice é INDEXTYPE IS
MDSYS.SPATIAL_INDEX.
4.1.2.5.1 Criando um índice R-tree:
CREATE INDEX <index-name> ON <table-name> (<column-name>) INDEXTYPE IS
MDSYS.SPATIAL_INDEX;
• <index-name> : nome do índice, não pode exceder 30 caracteres e tem que
começar com um caráter alfabético;
• <table-name> : é o nome da tabela que contem a coluna espacial a ser
posicionada;
• <column-name> : é o nome da coluna do tipo MDSYS.SDO_GEOMETRY no
qual ficam os objetos espaciais.
4.1.2.5.2 Criando um índice Quadtree:
CREATE INDEX <index-name> ON <table-name> (<column-name>)INDEXTYPE IS
MDSYS.SPATIAL_INDEX [PARAMETERS ( 'SDO_LEVEL = <level>,
56
SDO_COMMIT_INTERVAL = <n>, [<storage_parameters> = <param_value> ... ')];
• <level> : Este número define a parcela fixa do nível da telha do índice espacial,
SDO_LEVEL=1 tem telhas o tamanho de 1/4 de sistema coordenado,
SDO_LEVEL=2 tem telhas o tamanho de 1/16 de sistema coordenado, e assim por
diante;
• <n>: SDO_COMMIT_INTERVAL=N onde os resultados da indexação são
gravados à tabela espacial logo depois que cada n fileiras da tabela subjacente foi
processado. O valor de default para SDO_COMMIT_INTERVAL é -1, que
significa gravar os resultados da indexação espacial depois que todos as
geometrias forem posicionadas;
• <storage_parameters> : Determina os parâmetros de armazenamento usado na
construção da tabela espacial dos dados do índice.
57
5 ORACLE SPATIAL
O ORACLE é um SGBD convencional da Oracle Corporation que, através do módulo
Spatial, suporta aplicações SIG. O ORACLE SPATIAL possui Arquitetura Integrada,
implementa o Modelo Objeto-Relacional, e atualmente se encontra na versão 10g.
5.1 MODELO CONCEITUAL
Segundo Sharma (2001), o Modelo de Dados do ORACLE SPATIAL, como mostra a
Figura 27, é uma estrutura hierárquica consisti de elementos, geometrias e camadas (layers),
que correspondem à representação dos dados espaciais. Layers são compostos de geometrias,
que por sua vez são compostas por elementos. Mostra o um exemplo do Estado do Hawaii de
geometria que consiste de um conjunto de elementos (ilhas).
Um elemento é o componente básico de construção das geometrias do ORACLE
SPATIAL, ou seja, são os tipos primitivos de dados suportados pelo ORACLE e que serão
apresentados adiante. Os elementos são construídos utilizando-se coordenadas e, dependendo
do tipo do elemento, pode ter um ou vários pares de coordenadas.
Uma geometria é uma representação de um objeto espacial, modelada como um
conjunto ordenado de elementos primitivos (homogêneos ou heterogêneos). Cada geometria
possui um identificador único, conhecido como Numeric Geometry Identifier (GID), que
associa a geometria com o correspondente conjunto de atributos.
Um layer é uma coleção heterogênea de geometrias que compartilham o mesmo
conjunto de atributos.
58
Figura 27 - Modelo de Dados do ORACLE SPATIAL.
Fonte: Adaptado de Oracle Spatial Training Guide [OST 04]
5.2 SISTEMAS DE COORDENADAS
Os sistemas de coordenadas são usados para identificar onde um objeto está no espaço.
Estas posições do objeto são consideradas absolutas em relação ao sistema de coordenadas
que esta sendo usado.
São usados também para identificar onde um objeto esta em relação a outros objetos.
Os dados espaciais podem ser associados com um sistema coordenado cartesiana,
geodésico (geográfico), projetado, ou local:
• As coordenadas cartesianas: são as coordenadas que medem a posição de um ponto
de uma origem definida ao longo da trajetória que são perpendiculares no espaço
bidimensional ou tridimensional representado.
• As coordenadas geodésicas: (chamadas às vezes coordenadas geográficas) são
coordenadas angulares (longitude que especifica posições para o leste e o oeste do
meridiano principal e latitude que especifica posições note de sul do equador),
relacionadas próximas às coordenadas polares esféricas, e são definidas relativas a
uma referência geodésica da terra particular. (A referência geodésica de A é meios de
representar a figura da terra e é a referência para o sistema de coordenadas
geodésicas.).
• As coordenadas projetadas: são as coordenadas cartesianas planas que resultam da
execução do traçado matemático de um ponto na superfície da terra a um plano. Há
muitos tipos de coordenadas, cada um usado para uma finalidade particular.
59
• As coordenadas locais: são coordenadas cartesianas em um sistema coordenado da
não georeferênciado. Os sistemas coordenados locais são usados frequentemente para
aplicações do CAD e exames do local.
O oracle spatial fornece 950 (novecentos e cinqüenta) sistemas de coordenadas
predefinidas.
Todos os sistemas de coordenadas são definidos em uma tabela do dicionário do oracle,
privilégio do usuário MDSYS. O nome da tabela é CS_SRS.
A informação sobre cada sistema de coordenada é codificada usando a notação definida
pelo Open GIS Consortium (OGC). Esta informação é armazenada na coluna de WKTEXT da
tabela de CS_SRS.
Cada sistema coordenado no oracle spatial é atribuído um número original, onde fica
armazenado na coluna de SRID.
Há seis campos na tabela de CS_SRS:
• O campo de SRID contem o número espacial original do ID da referência. O sistema
espacial da referência é o mesmo que o sistema coordenado;
• A coluna de WKTEXT apresenta o texto como descrito pelo Open GIS Consortium;
• O campo de CS_NAME apresenta uma descrição do texto de cada sistema de
coordenadas;
• O campo de AUTH_NAME apresenta o nome autor do SRID. No oracle spatial, o
AUTH_NAME será sempre oracle. Pode ser usado junto com SRID como um
identificador global para sistemas de coordenadas espaciais do oracle;
• O campo de AUTH_SRID é um número que indica como a entrada foi
derivada;
• O CS_BOUNDS é reservado para o uso do oracle e atualmente NULO.
Eventualmente conterá uma geometria especificada em Wgs-84 (longitude/latitude)
que é o limite válido do polígono para cada projeção. Remanescerá NULO para
dados geodésicos;
• Cada geometria individual em uma camada deve ter o campo de SDO_SRID dentro
do objeto de SDO_GEOMETRY ajustado. Cada geometria na camada deve ter o
mesmo valor de SRID no campo de SDO_SRID.
60
5.2.1 Associando Geometrias com os sistemas de coordenadas
Há duas entradas requeridas para associar geometrias com um sistema espacial da
referência:
• Uma definida para todas as geometrias na camada do campo de SRID na visão de
USER_SDO_GEOM_METADATA;
• Cada geometria individual em uma camada deve ter o campo de SDO_SRID dentro
do objeto de SDO_GEOMETRY. Cada geometria na camada deve ter o mesmo
SRID valor do campo de SDO_SRID;
O valor do campo de SRID na visão de USER_SDO_GEOM_METADATA deve
combinar os valores do campo SDO_SRID para cada geometria na camada. Os campos de
SRID e de SDO_SRID ambos podem ser NULOS, ou podem ser ajustados a um valor válido.
Os valores válidos podem ser encontrados na coluna de SRID da tabela de MDSYS.CS_SRS.
5.2.2 Adicionando informação
Adicionar informação do sistema de coordenadas a uma camada pode requerer diversas
etapas. Uma vista geral do processo deve fazer o seguinte:
• Se um índice espacial existir na camada, deve ser excluído (SQL> DROP INDEX
STATES_SIDX;);
• Adicionar um valor para o campo de SRID associado com a camada na
visão de USER_SDO_GEOM_METADATA
(UPDATE USER_SDO_GEOM_METADATA SET SRID=8307 WHERE
TABLE_NAME='STATES' AND COLUMN_NAME='GEOM';);
• Adicionar um valor para SDO_SRID a cada geometria na camada
(SQL> UPDATE STATES A SET A.GEOM.SDO_SRID=8307;);
• Atualizar os valores para a tolerância e/ou ajustar os limites do sistema de
coordenadas para a camada requerida
(SQL> UPDATE USER_SDO_GEOM_METADATA A SET A.DIMINFO =
MDSYS.SDO_DIM_ARRAY(MDSYS.SDO_DIM_ELEMENT('Longitude',-
180,180,0.5),MDSYS.SDO_DIM_ELEMENT('Latitude',-90,90,0.5)) WHERE
TABLE_NAME = 'STATES' and COLUMN_NAME = 'GEOM';);
• Se houver um índice espacial na camada, reconstruí-la
(SQL> CREATE INDEX STATES_SIDX ON STATES(GEOM) INDEX_TYPE IS
MDSYS.SPATIAL_INDEX;).
61
O oracle spatial requer que os limites do sistema coordenado estejam ajustados a -
180° a 180° (longitude) e -90° a 90° (latitude). Adicionalmente, o valor da tolerância deve ser
especificado nos medidores para sistemas de coordenadas geodésicos.
Depois que todas as mudanças foram feitas para adicionar os sistemas de coordenadas
apropriadas, à informação deve ser passada ao metadados da geometria em questão, podendo
em seguida reconstruir o índice espacial.
5.3 MODELO DE REPRESENTAÇÃO
5.3.1 Representação da Geometria
O ORACLE SPATIAL suporta três tipos primitivos de geometrias (ponto, linha e
polígono) e uma coleção de outras geometrias compostas desses tipos primitivos, tais como:
arcos circulares, círculos, linhas compostas e polígonos compostos, como mostram na figura
28.
Pontos são elementos compostos entre dois e quatro coordenadas. Quando o ponto é
representado apenas pelo par (X, Y), freqüentemente o X corresponde à latitude do ponto e o
Y corresponde à longitude do ponto, num determinado sistema de coordenadas.
Linhas são compostas de uma seqüência ordenada de dois ou mais pontos que definem
os segmentos de linha. Auto-cruzamento de linhas são suportados, mas o polígono formado
no cruzamento não tem um interior implícito. Arcos também não têm nenhum interior
implícito. As coordenadas podem ser armazenadas seguindo-se a ordem do sentido horário ou
anti-horário.
Polígonos são compostos de linhas conectadas que formam um anel, e cujo interior do
polígono é implícito. Polígonos podem conter “buracos” que são construídos, por definição,
internos aos polígonos. Neste caso, o anel exterior e o anel interior do polígono são
considerados como dois elementos distintos que juntos formam um polígono complexo.
Ambos os tipos, exterior e interior, devem ser armazenados seguindo a ordem do sentido
horário. Auto-cruzamento de polígonos não é permitido, embora o seja para linhas. Mas, se
uma linha cruzar ela mesma, então ela não pertence a um polígono.
Uma linha composta é uma combinação de segmentos retos e curvos. Seguem as
mesmas restrições para linhas.
Nos polígonos compostos algumas extremidades podem ser formadas por linhas retas
e outras por linhas curvas. Seguem a mesma semântica do tipo polígono.
62
Figura 28 – Tipos de Dados Espaciais Primitivos do Oracle Spatial
Fonte: Oracle Spatial Training Guide (OST 04)
5.3.2 Representação da Topologia
O oracle spatial não implementa a topologia arco-nó-polígono explicitamente, tendo
dessa forma uma estrutura mais simples. Dada uma consulta espacial envolvendo elementos
de uma mesma tabela, os relacionamentos são testados com operações de geometria
computacional.
5.4 MODELO FÍSICO
5.4.1 Objeto Espacial
No ORACLE SPATIAL, um layer corresponde à tabela espacial, cuja coluna é
declarada como sendo do tipo geometria (MDSYS.SDO_GEOMETRY). Uma geometria é
uma instância do tipo MDSYS.SDO_GEOMETRY e é armazenada em uma linha e uma
coluna espacial (ou layer) particular da tabela.
A sintaxe do MDSYS.SDO_GEOMETRY é apresentada na tabela 4:
Parâmetros de SDO_GEOMETRY Object
SDO_GEOMETRY(SDO_GTYE, SDO_SRID, SDO_POINT, SDO_ELEM_INFO,
63
SDO_ORDINATES) SDO_GTYPE
NUMBER Define o tipo de geometria
armazenada no objeto
SDO_SRID NUMBER Define o Sistema de Referência
Espacial, através de um
identificador
SDO_POINT SDO_POINT_TYPE Utilizado para otimização do
espaço quando a geometria é
Ponto
SDO_ELEM_INFO SDO_ELEM_INFO_ARRAY Elemento descritor de ordem
SDO_ORDINATES SDO_ORDINATE_ARRAY Contém as coordenadas dos
elementos geométricos
Tabela 4 - Sintaxe do MDSYS.SDO_GEOMETRY
5.4.2 Conjunto de Operações Implementadas
As operações espaciais no ORACLE são implementadas, basicamente, através dos
operadores espaciais (spatial operators) e das funções espaciais (geometry functions). A
Tabela 5 (ORA, 2001) apresenta algumas dessas operações, agrupadas por operadores e
funções, com uma descrição sucinta de suas funcionalidades. A diferença básica entre essas
duas abordagens é que, no segundo caso (funções) não há utilização dos índices das tabelas
espaciais, caso existam. Já para os operadores, é necessária a existência de índices nas tabelas
espaciais e, 82 conseqüentemente, as consultas efetuadas com operadores são mais eficientes.
Uma outra diferença é que os operadores só podem ser utilizados na cláusula WHERE de uma
consulta SQL, enquanto que as funções podem ser utilizadas tanto na cláusula WHERE como
na cláusula SELECT.
OPERADORES ESPACIAIS
SDO_NN Determina os vizinhos mais próximos a uma
geometria
SDO_NN_DISTANCE Determina quão distante estão os objetos
retornados pelo operador SDO_NN de uma
dada geometria
SDO_RELAT Determina se duas geometrias se interagem (ou
64
não) de algum modo
SDO_WITHIN_DISTANCE Determina se uma geometria está a uma dada
distância de outra
FUNÇÕES ESPACIAIS
SDO_GEOM.RELATE Determina como duas geometrias se interagem
SDO_GEOM.SDO_AREA Calcula a área de um polígono de duas
dimensões
SDO_GEOM.SDO_BUFFER Gera um buffer (em forma de polígono) ao
redor de uma geometria
SDO_GEOM.SDO_DIFFERENCE Retorna a geometria correspondente à
diferença topológica entre duas geometrias
SDO_GEOM.SDO_DISTANCE Calculam a distância entre duas geometrias
SDO_GEOM.SDO_INTERSECTION Retorna a geometria correspondente à
interseção topológica entre duas geometrias
SDO_GEOM.SDO_LENGTH Calcula o comprimento ou perímetro de uma
geometria
SDO_GEOM.SDO_UNION Retorna a geometria correspondente à
união topológica entre duas geometrias
SDO_GEOM.VALIDATE_GEOMETRY Determina se uma geometria é válida
SDO_GEOM.VALIDATE_LAYER Determina se todas as geometrias armazenadas
em uma coluna espacial são válidas
SDO_GEOM.WITHIN_DISTANCE Determina se uma geometria está a uma
distância específica (distância Euclidiana) de
outra
Tabela 5 – Operadores Espaciais e Funções Espaciais.
Além das funcionalidades apresentadas acima, o ORACLE SPATIAL ainda possui
outros recursos, como por exemplo, aqueles específicos para suportar aplicações que utilizam
redes lineares, tais como rotas de ruas (para internet), transportes, utilities e redes de
telecomunicações.
5.4.3 Semântica das operações
A seguir, são apresentados os relacionamentos topológicos utilizados no operador
SDO_RELATE e na função SDO_GEOM.RELATE, extraídos de Oracle Spatial User’s
65
Guide and Reference [ORA 01]:
• TOUCH: dois objetos se tocam quando suas fronteiras se interceptam, mas o
interior não. Em outras palavras, suas fronteiras compartilham pelo menos um
ponto comum, mas não há nenhum ponto comum a ambos os interiores.
• OVERLAPBDYDISJOINT: dois objetos têm um relacionamento do tipo
“OVERLAPBDYDISJOINT” (Overlap Boundaries Disjoint) quando o interior de
um objeto intercepta a fronteira e o interior do outro, mas as duas fronteiras não se
interceptam. É aplicável quando o teste é efetuado entre objetos do tipo linha e
polígono.
• OVERLAPBDYINTERSECT: dois objetos têm um relacionamento do tipo
“OVERLAPBDYINTERSECT” (Overlap Boundaries Intersect) quando a
fronteira e o interior de ambos se interceptam. É aplicável quando ambos os
objetos testados são do tipo polígono.
• EQUAL: dois objetos são iguais quando elas possuem a mesma fronteira e o
mesmo interior.
• INSIDE: ocorre quando o primeiro objeto está totalmente dentro do segundo e
suas fronteiras não se tocam. É o oposto de CONTAINS.
• CONTAINS: ocorre quando o segundo objeto está totalmente dentro do primeiro e
suas fronteiras não se tocam.
• COVERDBY: ocorre quando o primeiro objeto está totalmente dentro do segundo
e suas fronteiras se tocam em um ou mais pontos. É o oposto de COVERS.
• COVERS: ocorre quando o segundo objeto está totalmente dentro da primeira e
suas fronteiras se tocam em um ou mais pontos. É o oposto de CONTAINS.
• ANYINTERACT: dois objetos têm algum tipo de interação quando não são
disjuntos.
• DISJOINT: dois objetos são disjuntos quando nem o interior nem a fronteira de
ambos se interceptam, ou seja, não há relacionamento entre eles.
5.4.4 Métodos de Indexação
O ORACLE SPATIAL fornece duas opções de índice: o Quad-tree e o R-tree.
Segundo Sharma (2001), o índice R-tree pode ser utilizado em lugar do Quad-tree, ou em
conjunto com ele. Em adição, o R-tree pode ser utilizado para dados 3D e 4D.
66
5.4.5 Linguagens de Consulta e Ambiente de Consulta Espacial
A Linguagem de Consulta do ORACLE SPATIAL é a SQL. O ORACLE SPATIAL
possui um ambiente de Consulta Espacial muito restrito (Oracle Spatial Index Advisor), onde
é possível fazer consultas envolvendo apenas um layer. A interface de consulta espacial do
ORACLE SPATIAL está selecionada (na cor branca), os Distritos que têm alguma interação
com a janela definida pelo usuário. As consultas SQL mais elaboradas são formuladas
utilizando-se uma das interfaces SQL*PLUS ou SQLPLUS Worksheet.
Os comandos SQL podem ser embutidos na Linguagem de Programação do ORACLE
(PL/SQL) ou, ainda, em Linguagem C/C++.
Para visualização dos resultados das consultas, utiliza-se o Enterprise Manager
Console, ou outro visualizador externo, compatível com o ORACLE. O Enterprise Manager
Console é o ambiente de gerenciamento de tabelas (tanto espaciais quanto não espaciais) do
ORACLE.
5.5 CAMADAS ESPACIAIS
Uma camada é uma coleção de geometrias que têm a mesma característica geométrica.
Por exemplo, uma camada no sistema de informação geográfica pode incluir características
topográficas, quando outra descreve a densidade demográfica, e uma terceira descreve a rede
das estradas e das pontes em uma área. As geometrias índices espaciais associadas a cada
camada, são armazenadas na base de dados em tabelas especificas.
A criação de layers (camadas) se dá através de um tipo de dados, SDO_GEOMETRY.
O objeto SDO_GEOMETRY conterá uma geometria inteira em um registro, uma
única coluna de uma tabela do oracle.
O objeto SDO_GEOMETRY tem cinco campos. Dois dos do tipo numérico e outros
três do tipo de dados do objeto. O exemplo da figura 29 mostra como criar uma tabela
chamada STATES com uma coluna SDO_GEOMETRY.
• O objeto SDO_POINT_TYPE (x, y e z do tipo number) é um tipo de dado dentro
do objeto SDO_GEOMETRY, e não deve ser usado fora do objeto
SDO_GEOMETRY (isto é, não criar tabelas com uma coluna do tipo de
SDO_POINT_TYPE).
• SDO_ELEM_INFO_ARRAY (varray (1048576) of number) é um tipo de dado
dentro do objeto de SDO_GEOMETRY. Descreve um ou mais elemento
armazenado nesta geometria.
67
• SDO_ORDINATE_ARRAY (varray (1048576) of number) é um tipo de dado
dentro do objeto SDO_GEOMETRY. Conterá todas as ordenadas para todos os
elementos que fazem à geometria.
Figura 29 - Objeto SDO_GEOMETRY
O objeto de SDO_GEOMETRY é de propriedade do usuário MDSYS. Este é um
usuário do oracle com todos os privilégios.
A seguir serão detalhados os campos do SDO.GEOMETRY.
5.5.1 Objeto sdo_gtype
Este é o primeiro dos cinco campos no objeto de SDO_GEOMETRY.
A composição de um valor do tipo de dado SDO_GTYPE é de quatro dígitos,
representado na figura 30.
Figura 30 - Representação do tipo de dado SDO_GTYPE
O numero de dimensões da geometria são representadas também no SDO_GTYPE. É
68
determinando no primeiro dos quatro dígitos.
Antes do tipo SDO_GTYPE a única maneira de representar as dimensões de uma
geometria, era perguntando para coluna da geometria. Adicionar a dimensão ao SDO_GTYPE
tornou possível eliminar a busca espacial do dicionário para determinar a dimensão de uma
geometria.
A geometria (último algarismo do SDO_GTYPE pode assumir valores de 0 a 7, e
identifica o tipo de geometria armazenado na figura 31) pode ser composta de um ou mais
elemento. Esse tipo de dado armazenado qual é o tipo da geometria no objeto
SDO_GEOMETRY onde os elementos estão representados na figura 31.
69
Figura 31 - Elementos do tipo SDO_GTYPE
5.5.1.1 Sistemas de referencias lineares (LRS)
Referencia linear é um meio natural e conveniente de associar atributos ou eventos às
posições ou às parcelas de uma característica linear. Foi usado extensamente em aplicações do
transporte (como estradas, estradas de ferro, e rotas de trânsito) e em aplicações como os
encanamentos do gás e de óleo.
A vantagem principal de referencia linear é sua potencialidade de encontrar atributos e
70
eventos ao longo de uma característica linear com somente um parâmetro (geralmente uma
medida) em vez de dois (tais como longitude/latitude ou x/y no espaço cartesiano).
As seções de uma característica linear podem ser referenciadas e criadas dinamicamente
indicando as posições do inicio e do fim ao longo da característica sem explicitamente
armazená-las.
A relação de programação de aplicação sistema de referencia linear do (LRS) (API) no
Oracle Spatial fornece potencialidades ao usuário de nível cartográfico. A informação linear
da medida é integrada diretamente na estrutura espacial da geometria no Oracle.
5.5.1.2 Segmentos Geométricos (LRS Segmentos)
Os segmentos geométricos são baseados nos elementos LRS dentro do Oracle Spatial.
Um segmento geométrico pode ser algum dos seguintes:
• Cadeia de linha: uma geometria contínua (por exemplo, uma estrada simples);
• Cadeia de varias linhas: não conectada a cadeia de linha (por exemplo, uma estrada
com uma abertura causada por um lago ou uma estrada do desvio)
• Polígono (por exemplo, uma estrada de corrida ou uma rota de excursão que comece e
termine no mesmo ponto).
Um segmento geométrico deve conter medidas ao menos de inicio e de fim para seus
pontos. As medidas dos pontos de interesse (tais como saídas de estrada) nos segmentos
geométricos podem também ser atribuídas. Estas medidas são atribuídas por usuários ou
derivadas dos segmentos geométricos existentes. A figura 32 mostra um segmento geométrico
com quatro linhas de segmentos e um arco. Os pontos no segmento geométrico são
representados por x, y, m, onde x e y descrevem a posição e o m denota a medida (com cada
valor da medida sublinhado na figura 32).
71
Figura 32 - Segmento Geométrico
5.5.1.3 Forma de Pontos
A forma dos pontos são os pontos que são especificados quando um segmento de LRS é
construído, e que estão atribuídos à informação da medida. No oracle spatial, um segmento
de linha é representado por seus pontos de inicio e fim, e um arco é representado por três
pontos: inicio, meio, e pontos de extremidade do arco. Você deve especificar estes pontos
como forma desses pontos, mas pode também especificar outros pontos enquanto for
necessário informar a medida armazenada para estes pontos (para o exemplo, uma saída no
meio de uma reta na estrada).
Assim, as formas dos pontos podem servir a um ou mais finalidades: para indicar o
sentido do segmento (por exemplo, uma volta ou a curva), para identificar um ponto.
As formas dos pontos não puderam diretamente relacionar-se aos vários pontos ou as
referências em LRS. São usados como pontos de referência internos. A informação da
medida dos pontos da forma é povoada automaticamente quando se usa o segmento de LRS
com o procedimento SDO_ LRS.DEFINE_GEOM_SEGMENT.
5.5.1.4 Sentido de um segmento geométrico
O sentido de um segmento geométrico é indicado do ponto do começo do segmento
geométrico ao ponto da extremidade. O sentido é determinado pela ordem dos vértices (do
ponto de inicio ao ponto de fim) na definição da geometria. As medidas dos pontos em um
segmento geométrico sempre aumentam ou diminuem ao longo do sentido do segmento
geométrico.
72
5.5.1.5 Medida (Medida Linear)
A medida de um ponto ao longo de um segmento geométrico está a uma distância linear
(na dimensão da medida) ao ponto medido do ponto do começo (para valores maiores) ou do
ponto de extremidade (para valores menores) do segmento geométrico. A informação da
medida não tem que necessariamente ser da mesma escala que a distância. Entretanto, o linear
que traça o relacionamento entre a medida e a distância é sempre preservada.
5.5.1.6 Offset
O offset de um ponto ao longo de um segmento geométrico está a uma distância
perpendicular entre o ponto e o segmento geométrico. Os offsets são positivos se os pontos
estiverem no lado esquerdo ao longo do sentido do segmento e são negativos se estiverem no
lado direito.
A unidade de medida para um offset é a mesma que para o sistema coordenado
associado com o segmento geométrico. Para dados geodésicos, a unidade padrão de medida é
metros.
Na figura 33 mostra como um ponto pode ficar situado ao longo de um segmento
geométrico com informação da medida e do offset. Atribuindo um offset junto com uma
medida, é possível encontrar não somente os pontos que estão no segmento geométrico, mas
também os pontos que são perpendiculares ao segmento geométrico.
Figura 33 - Descrevendo um ponto ao longo de um segmento com uma medida e um offset
5.5.1.7 Povoando uma Medida
Todas as medidas sem valor de um segmento geométrico são povoadas
automaticamente baseadas em sua distribuição da distância. Isto é feito antes de todas as
operações de LRS para segmentos geométricos com as medidas desconhecidas (NULL no
oracle spatial). Os segmentos geométricos resultantes de todas as operações de LRS retornam
a informação da medida associada com os segmentos geométricos. A medida de um ponto no
73
segmento geométrico pode ser obtida baseada em um relacionamento traçando linearmente
entre suas medidas ou posições sabidas precedentes e seguintes. Ver a reapresentação do
algoritmo na figura 34 e no exemplo da figura 35.
Figura 34 - Medidas, distâncias, e seu relacionamento traçando.
Figura 35 - Povoamento da medida de um segmento geométrico
As medidas são espaçadas uniformente entre as medidas atribuídas. Entretanto, as
medidas atribuídas aos pontos de interesse em um segmento geométrico não necessitam ser
espaçadas uniformente.
Além disso, as medidas atribuídas não necessitam mesmo refletir distâncias reais (por
exemplo, podem refletir a evolução do tempo); podem ser todos os valores válidos dentro da
escala da medida. Figura 36 mostra a população da medida que resultam os valores atribuídos
da medida quando não forem proporcionais e não refletirem extensamente a distância.
74
Figura 36 - Medida povoada de forma desproporcional
Em todos os casos, à medida povoada é feita em uma forma incremental ao longo do
sentido do segmento. Isto melhora o desempenho de operações atuais e subseqüentes do LRS.
5.5.1.8 Escala de medida de um segmento geométrico
As medidas do inicio e do fim de um segmento geométrico definem a escala linear da
medida do segmento geométrico. Todas as medidas válidas do LRS de um segmento
geométrico devem cair dentro de sua escala da medida linear.
5.5.1.9 Projeção
A projeção de um ponto ao longo de um segmento geométrico é o ponto no segmento
geométrico com a distância mínima ao ponto especificado. A informação da medida do ponto
resultante é retornada também na geometria do ponto.
5.5.1.10 Ponto de LRS
Os pontos de LRS são pontos com informação linear da medida ao longo de um
segmento geométrico. Um ponto válido de LRS é uma geometria do ponto com informação
da medida.
Todos os dados do ponto de LRS devem ser armazenados no
SDO_ELEM_INFO_ARRAY e no SDO_ORDINATE_ARRAY, e não podem ser
armazenados no campo de SDO_POINT na definição da geometria de SDO_ do ponto.
5.5.1.11 Características Lineares
As características lineares são todos os objetos espaciais que puderem ser tratados como
um jogo lógico de segmentos lineares. Os exemplos de características lineares são estradas em
aplicações do transporte e encanamentos em aplicações de serviço público da indústria. O
relacionamento de características lineares, de segmentos geométricos, e de pontos de LRS é
mostrado em figura 37, onde uma única característica linear consiste em três segmentos
75
geométricos, e três pontos de LRS são mostrados no primeiro segmento.
Figura 37 - Característica Linear, Segmentos Geométricos, e pontos de LRS
5.5.2 Modelo de Dados do LRS
O modelo espacial dos dados do oracle LRS incorpora a informação da medida em sua
representação da geometria no nível do ponto. A informação da medida é integrada
diretamente no modelo espacial do oracle. Para realizar isto, uma dimensão adicional da
medida deve ser adicionada ao metadados espacial do oracle.
A sustentação espacial do oracle LRS afeta o metadados e os dados espaciais (as
geometrias). A figura 38 mostra como uma dimensão da medida pode ser adicionada às
geometrias bidimensionais no metadados espacial. A dimensão da medida deve ser o último
elemento do SDO_DIM_ARRAY em uma definição espacial do objeto.
Figura 38 - Incluir Dimensão da medida de LRS em Metadados espacial
Após ter adicionado a dimensão nova da medida, as geometrias com informação da
medida, tal como segmentos geométricos e pontos de LRS podem ser representados.
Um exemplo de criar um segmento geométrico com três segmentos de linha é
mostrado em figura 39.
76
Figura 39 - Criando um segmento geométrico
Sempre que um segmento geométrico é definido, suas medidas de inicio e de fim
devem ser definidas ou derivado de algum segmento geométrico existente. As medidas não
definidas o serão povoadas automaticamente.
5.5.2.1 Indexação de dados de LRS
Se os dados de LRS tiverem quatro dimensões (três mais a dimensão de M) e se você
necessitar posicionar todas as três dimensões mais a não medida, você deve usar uma
indexação espacial R-tree para os dados, e deve especificar
PARAMETERS('sdo_indx_dims=3') na indicação do CREATE INDEX para assegurar-se de
que as primeiras três dimensões estejam posicionadas. Nota-se, entretanto, que se for
especificado um valor maior ou igual 3 no sdo_indx_dims, o único operador espacial que
pode ser usado nos geometrias posicionados é SDO_FILTER (o valor padrão para a palavra
chave dos sdo_indx_dims é 2, que fariam com que somente as primeiras duas dimensões
fossem posicionadas.) Por exemplo, se as dimensões forem X, Y, Z, e M, especificar
sdo_indx_dims=3 para posicionar as dimensões de X, de Y, e de Z, mas não a dimensão da
medida (M). Não incluir a dimensão da medida em um índice espacial, pois isto causa um
processando adicional no qual não produzir nenhum benefício.
5.5.2.2 Funções de LRS para formatos 3D
A maioria das funções de LRS têm os formatos que terminam em _ 3D: por exemplo, o
DEFINE_GEOM _ SEGMENT_3D, o CLIP_GEOM_SEGMENT_3D, o
FIND_MEASURE_3D, e o LOCATE_PT_3D.
Os formatos 3D são suportados somente para a cadeia de linha e geometrias de cadeia
de varias linhas. Os formatos 3D devem ser usados somente quando o objeto da geometria
tem quatro dimensões e a quarta dimensão é a medida (o X, o Y, o Z, e o M), e somente
77
quando se deseja que a função considere as primeiras três dimensões (o X, o Y, e o Z). Se o
formato padrão de uma função (isto é, sem _ 3D) for usado em uma geometria com quatro
dimensões, a função ira considerar somente as primeiras duas dimensões (o X e o Y).
Por exemplo, na figura 40, o seguinte formato considera o X, Y, e as dimensões de Z
do GEOM.
Figura 40 – Função de LRS para formatos 3D com x, y e z
Entretanto na figura 41, o seguinte formato considera as dimensões somente de X e de
Y, e ignora a dimensão de Z, do objeto especificado de GEOM.
Figura 41 - Função de LRS para formatos 3D com x e y
Os parâmetros para o padrão e os formatos 3D de toda a função são os mesmos, e as
notas do uso aplicam-se a ambos os formatos.
Os formatos 3D não são suportados para o seguinte:
• Dados geodésicos;
• Polígonos, arcos, ou círculos.
5.5.3 Definindo um segmento geométrico
Há duas maneiras de criar um segmento geométrico com a informação da medida:
1. Construir um segmento geométrico e atribuir medidas explicitamente;
2. Definir um segmento geométrico com começo especificado e terminá-lo, e/ou todas
as outras medidas, em uma ordem ascendente ou descendente. As medidas dos
pontos da forma com medidas sem descrição, desconhecidas, valores nulos no
78
segmento geométrico serão povoadas automaticamente de acordo com suas posições
e distribuição da distância.
A figura 42 mostra maneiras diferentes de definir um segmento geométrico.
Figura 42 - Definir um segmento geométrico
Um segmento de LRS deve ser definido (ou deve já existir) antes que todas as
operações de LRS possam prosseguir. Isto é, o começo, a extremidade, e todas as outras
medidas atribuídas devem ser apresentados para derivar a posição de uma medida
especificada. A informação da medida de pontos intermediários da forma será povoada
automaticamente se os valores da medida não forem atribuídos.
5.5.3.1 Redefinindo um segmento geométrico
Você pode redefinir um segmento geométrico para substituir as medidas existentes de
todos os pontos da forma entre o começo e o ponto de final com as medidas automaticamente
calculadas. Redefinir um segmento pode ser útil se os erros estiverem feitos em um ou mais
atribuição explícita da medida, e se quiser começar com as medidas proporcionais atribuídas.
79
Na figura 43 mostra que a redefinição de um segmento onde, antes, os valores
atribuídos existentes da medida não eram proporcionais.
Figura 43 - Redefinir um segmento geométrico
5.5.3.2 Anexando, dividindo ou concatenando um segmento geométrico.
Para anexar, criar um novo segmento, fora de um segmento geométrico já existente,
como mostrado na figura 44.
No item a, um segmento criado a partir de um segmento maior. O novo segmento tem
seus próprios pontos do inicio e fim, e o sentido é o mesmo que no segmento original.
No item b, mostra a possibilidade de dividir um segmento em duas partes. O sentido
de cada segmento novo segue o do segmento original. Note que as aberturas pequenas entre
segmentos são usadas nas ilustrações de divisão e concatenação. Cada abertura reforça
simplesmente o fato que dois segmentos diferentes são envolvidos. Entretanto, os dois
segmentos (tais como o segmento 1 e o segmento 2, nos itens b e c) são conectados realmente.
A tolerância é considerada em determinar se ou não os segmentos estão conectados.
O item c demonstra que os segmentos geométricos não necessitam ser conectados
espacialmente, embora sejam conectados as medidas do segundo segmento geométrico são
deslocadas de modo que a medida do fim do primeiro segmento seja a mesma como a medida
do começo do segundo segmento. O sentido do segmento que resulta da concatenação está o
mesmo que nos dois segmentos originais.
80
Figura 44 - Anexando, dividindo, e concatenando segmentos geométricos
Medir as atribuições para anexar, dividir ou concatenar operações dentro da figura
13xx é mostrado na figura 45. Sentido da informação e do segmento da medida é preservado
em uma maneira consistente. A atribuição é feita automaticamente quando as operações
terminarem.
Figura 45 - Atribuição da medida em operações geométricas do segmento
81
O sentido do segmento geométrico que resulta da concatenação é sempre o sentido do
primeiro segmento como mostra a figura 46.
Figura 46 - Sentido do segmento com concatenação
Além de explicitamente concatenar dois conectaram segmentos usando a função
SDO_ LRS.CONCATENATE_GEOM_SEGMENTS, você pode executar o agregado
concatenação: isto é, você pode concatenar todos os segmentos geométricos conectados em
uma coluna (camada) que usa a função agregada espacial de SDO_AGGR_LRS_CONCAT.
5.5.3.3 Escala um segmento geométrico
Você pode criar um novo segmento geométrico executando uma operação linear da
escala em um segmento geométrico. Figura 47 mostra o relacionamento traçando para essa.
Figura 47 - Escala de um segmento geométrico
82
Escalar em um segmento geométrico envolve somente rearranjar medidas do segmento
geométrico recentemente criado. Entretanto, se o fator de escala for negativo, a ordem dos
pontos da forma necessita ser invertida de modo que as medidas aumentem ao longo do
sentido do segmento geométrico (que é definido pela ordem dos pontos da forma).
Uma operação da escala pode executar toda a combinação das seguintes operações:
• Traduzindo a informação da medida (deslocar). (Por exemplo, adicionar o mesmo
valor a Ms e Me para começar M’s e M’e.);
• Invertendo a informação da medida. (Deixado M’s = Me, M’e = Ms, e Mdeslocar =
0.);
• Executando a escala simples da informação da medida. (Deixado Mdeslocar = 0.).
5.5.4 Deslocando um segmento geométrico
Você pode criar um segmento geométrico novo executando uma operação de
deslocamento em um segmento geométrico. A figura 48 mostra o relacionamento traçando
para o deslocamento geométrico do segmento.
Figura 48 - Deslocando um segmento geométrico
Na operação de deslocamento mostrada na figura 48, o segmento geométrico
resultante é deslocado por 5 unidades das medidas especificadas do começo e do fim do
segmento original.
5.5.5 Encontrando um ponto em um segmento geométrico
É possível encontrar a posição de um ponto descrito por uma medida e por um offset em
um segmento geométrico (ver figura 49).
83
Figura 49 - Encontrando um ponto ao longo de um segmento com uma medida e um offset
Há sempre uma posição original com uma medida específica em um segmento
geométrico. A ambigüidade levanta-se quando os offsets são dados e os pontos descritos pelas
medidas caem em pontos da forma do segmento geométrico (ver figura 50).
Figura 50 - Ambigüidade na posição que referencia o offsets
Como mostrado na figura 50, um arco offset de da forma de um ponto em um
84
segmento geométrico é um arco em que todos os pontos têm a mesma distância mínima. Em
conseqüência, todos os pontos no arco offset são representados pelo mesmo (medida, offset)
par. Para resolver estes um-para-muitos o problema traça o ponto médio no arco offset ao
inicio.
5.5.5.1 Projetando um ponto em um segmento geométrico
O ponto a ser projetado pode estar dentro ou fora do segmento. Se o ponto estiver no
segmento, o ponto e seu ponto da projeção são o mesmo.
A projeção é uma operação reversa da operação encontrando um ponto (mostrada na
figura 49). Similar a uma operação encontrando um ponto, todos os pontos do arco offset de
um ponto da forma terão o mesmo ponto da projeção (isto é, o ponto próprio da forma),
medindo e deslocando (ver figura 50). Se houver múltiplas projeções, aponta para o primeiro
ponto do inicio (ponto 1 da projeção em ambas as ilustrações na figura 51).
Figura 51 – Projeção de Múltiplos pontos
5.5.5.2 Converter Geometria em LRS
É possível converter geometrias do formato padrão de cadeias de linha no formato de
LRS, e vice-versa. O uso principal dessa função de conversão ocorrerá provavelmente se
houver uma quantidade grande de linha, em que a conversão nesse caso é uma alternativa,
criar todos os segmentos em uma LRS manualmente. Entretanto, se você necessitar converter
um segmento de LRS a uma cadeia de linha padrão para determinadas aplicações, isso
também é possível.
As funções fornecidas para conversão são:
• Linha individual cadeias ou pontos: Para a conversão do formato padrão ao formato de
LRS, uma dimensão da medida (nomeada M por padrão) é adicionada, a informação
da medida é fornecida para cada ponto. Para a conversão do formato de LRS ao
85
formato padrão, a dimensão e a informação da medida são removidos. Em ambos os
casos, o metadados da informação dimensional (DIMINFO) na vista de
USER_SDO_GEOM_METADATA não é afetado;
• Camadas (todas as geometrias em uma coluna): Para a conversão do formato padrão
ao formato de LRS, uma dimensão da medida (nomeada M por padrão) é adicionada,
mas nenhuma informação da medida é fornecida para cada ponto. Para a conversão do
formato de LRS ao formato padrão, a dimensão e a informação da medida são
removidos. Em ambos os casos, o metadados da informação dimensional (DIMINFO)
na vista de USER_SDO_GEOM_METADATA é modificado conforme a necessidade;
• Informação dimensional (DIMINFO): O metadados da informação dimensional
(DIMINFO) na vista de USER_SDO_GEOM_METADATA é modificado conforme a
necessidade. Por exemplo, converter uma disposição dimensional padrão com
dimensões de X e de Y (SDO_DIM_ELEMENT) a uma disposição dimensional de
LRS faz com que uma dimensão de M (SDO_DIM_ELEMENT) seja adicionada.
A figura 52 mostra a adição da informação da medida quando uma cadeia de linha padrão
for convertida a uma linha corda de LRS (que usa a função de
SDO_LRS.CONVERT_TO_LRS_GEOM). Os valores da dimensão da medida são
sublinhados na figura 52.
Figura 52 - Conversão do padrão para cadeia de linhas LRS
Para conversões da geometria de ponto, o atributo SDO_POINT na geometria
retornada é afetado como segue:
• Se um ponto padrão for convertido a um ponto de LRS, informação do atributo de
SDO_POINT na geometria da entrada é usada para ajustar os atributos de
SDO_ELEM_INFO e de SDO_ORDINATES na geometria resultante, e o atributo
de SDO_POINT na geometria resultante são ajustados a null;
• Se um ponto de LRS for convertido a um ponto padrão, a informação dos atributos
SDO_ELEM_INFO e SDO_ORDINATES na entrada a geometria é usada para
86
ajustar a informação do atributo de SDO_POINT na geometria resultante, e os
atributos de SDO_ELEM_INFO e de SDO_ORDINATES na geometria resultante
são ajustados a null.
5.5.5.3 Valores da tolerância com funções de LRS
Muitas funções de LRS requerem que seja especifica um valor de tolerância ou um ou
mais disposições dimensionais. Assim, é possível todas as dimensões da não-medida ou usar a
tolerância associada a cada dimensão da não-medida na disposição dimensional ou nas
disposições. A tolerância é aplicada somente à parcela da geometria dos dados, não à
dimensão da medida. O valor da tolerância para dados geodésicos está nos medidores, e para
dados não-geodésicos está na unidade de medida associada com os dados.
Se os resultados de funções de LRS parecer impreciso ou incorreto, você pode
necessitar especificar um valor menor da tolerância.
Para operações de anexo e operações offset, se o segmento retornado tiver quaisquer
pontos da forma dentro do valor da tolerância do segmento geométrico da entrada que seria de
outra maneira o ponto de começo e/ou de extremidade do segmento retornado. Isto é feito
para assegurar-se de que a geometria resultante não contenha nenhum vértice redundante, que
faz com que a geometria fosse inválida. Por exemplo, suponha que a tolerância associada com
o segmento geométrico (dados não-geodésicos) é 0.5 (mostrado na figura 53).
Figura 53 - Segmento para a operação de anexo afetada por Tolerância
Se uma operação de anexo pedir para retornar o segmento entre a medida avaliado 0
(Inicio Ponto) e 61.5 (figura 53), e se a distância entre os pontos associar com os valores 61.5
e 61.257 da medida, for menor do que o valor da tolerância 0.5, o ponto de extremidade do
segmento retornado é (35, 10, 61.257).
5.5.5.4 Exemplo de funções de LRS
Este exemplo usa a estrada que é ilustrada na figura 54.
87
Figura 54 - Exemplo Simplificado de LRS: Estrada
A estrada (a rota 1) começa no ponto 2.2 e termina no ponto 5.14, segue o trajeto
mostrado na figura 51, e tem seis pontos de entrada a saída (saída 1 a saída 6). Cada unidade
no gráfico representa uma unidade de medida, e assim à medida do começo termina em 27 (o
segmento da saída 5 à saída 6 que é a hipotenusa de um triângulo da direita 3-4-5).
Cada fileira da tabela 6 mostra característica estrada e a característica de LRS que lhe
correspondem ou que podem ser usadas:
Característica da Estrada Característica de LRS
Rota, estrada, ou rua nomeada. Segmento de LRS, ou característica linear
(jogo lógico dos segmentos).
Marcador da milha ou do quilômetro Medida
Relatório de acidente e seguir da posição Função SDO_LRS.LOCATE_PT
Zona da construção (parcela de uma
estrada)
Função
SDO_LRS.CLIP_GEOM_SEGMENT
Extensão da estrada (que adiciona no
começo ou extremidade) ou combinação
(que designa ou que rebatiza duas estradas
Função
SDO_LRS.CONCATENATE_GEOM_
SEGMENTS
88
que se encontram com como uma estrada)
Reconstrução ou divisão da estrada (tendo
por resultado duas estradas nomeadas de
uma nomeada estrada)
Procedimento
SDO_LRS.SPLIT_GEOM_SEGMENT
Encontrando o ponto o mais próximo na
estrada a um ponto fora da estrada (tal como
um edifício)
Função SDO_LRS.PROJECT_PT
Trilho ou cerca do protetor ao lado de uma
estrada
Função
SDO_LRS.OFFSET_GEOM_SEGMENT
Tabela 6 - Características da estrada e contrapartes de LRS
5.5.6 Métodos em SDO_GTYPE
Os métodos disponíveis para analisar gramaticalmente a informação fora do
SDO_GTYPE são:
• GET_DIMS () retorna a dimensão dos retornos da geometria. Exemplo: select
a.geom.get_dims() state_dims from states s where a.state = ‘Delaware’;
• GET_GTYPE () retorna o GTYPE que descreve o tipo da geometria que está
sendo armazenado. Exemplo: select s.geom.get_gtype state_gtype from states s
where s.states = ‘Delaware’;
• GET_LRS_DIM () retorna a posição de LRS da geometria (se a consulta retorna 0,
a geometria não é conhecida para ser referenciada como linear).Exemplo: select
s.geom.get_lrs_dim() state_lrs_dim from states s where s.state = ‘Delaware’;.
Muitas vezes é melhor analisar gramaticalmente o SDO_GTYPE em sua aplicação em
vez de usar os métodos de GET_DIMS ou GET_LRS_DIM. Estes métodos retornarão o
mesmo valor para cada geometria na camada. Por exemplo, cada geometria em uma camada
deve ter a mesma dimensão, GET_DIMS retornará o mesmo valor para cada fileira em uma
camada. Para reduzir o tráfego da rede (isto é, menos colunas em sua lista selecionada),
analisar gramaticalmente o SDO_GTYPE em sua aplicação rápido do que usar GET_DIMS
ou GET_LRS_DIM na lista de seleção.
5.5.7 Campo de SDO_SRID
Este é o segundo campo no objeto de SDO_GEOMETRY. É como se associa os dados
com um sistema de coordenadas. O oracle spatial tem uma tabela do dicionário chamada
MDSYS.CS_SRS que lista todos os sistemas de coordenadas suportados. O valor que você
89
ajusta o campo de SDO_SRID deve combinar com um valor na coluna de SRID na tabela de
MDSYS.CS_SRS, ou seja não NULO. Todas as geometrias em uma coluna devem ter o
mesmo SDO_SRID.
5.5.8 Campo de SDO_POINT
Este é o terceiro campo do objeto de SDO_GEOMETRY. Esta é uma maneira otimizada de
armazenar um único ponto no objeto de SDO_GEOMETRY. O atributo de SDO_POINT é
definido usando o tipo do objeto de SDO_POINT_TYPE, onde tem os atributos X, Y, e Z,
todos do tipo NÚMERO. Se o SDO_ELEM_INFO e o SDO_ORDINATES são ambas null, e
o atributo de SDO_POINT é não nulo, então o X e o Y são as coordenadas de uma geometria
do ponto. Se não, o atributo de SDO_POINT é ignorado por Oracle Spatial. Você deve
armazenar as geometrias do ponto dentro do atributo SDO_POINT para o armazenamento
opcional; e se você tiver somente o ponto geométrico em uma camada, recomenda-se
fortemente que você armazena o ponto geométrico no atributo de SDO_POINT.
5.5.9 Campo SDO_ELEM_INFO
Este é o quarto campo no objeto de SDO_GEOMETRY. Uma geometria pode conter
um ou mais elemento. Se a geometria não for um único ponto armazenado no campo de
SDO_POINT, então uma descrição de cada elemento da geometria está armazenada no campo
de SDO_ELEM_INFO.
O campo de SDO_ELEM_INFO é um VARRAY de NUMBER. As entradas no
campo de SDO_ELEM_INFO devem ser consideradas nos grupos de três números:
1. Ordenada deslocada: Uma geometria pode ser composta de um ou mais elemento.
Este é um índice no campo de SDO_ORDINATES, descrito mais adiante. O valor
do índice corresponde à primeira ordenada de um elemento. O primeiro elemento
de uma geometria começará sempre na posição 1.
2. Tipo do elemento: Este é o tipo do elemento (ponto, linha, polígono, e outros). O
tipo do elemento é chamado também do TYPE.
3. Interpretação: A interpretação possui um significado diferente, dependendo do
valor do tipo do elemento. Podem significar que todos os pontos para este
elemento estão conectados com as linhas retas, arcos circulares, ou pôde significar
que este valor é um encabeçamento para um elemento composto.
90
5.5.10 Campo de SDO_ORDINATES
Este é o quinto campo no objeto de SDO_GEOMETRY. Este campo é um VARRAY
de NUMBER. Contém todas as ordenadas dos elementos descritos pelo campo de
SDO_ELEM_INFO.
5.5.11 Elementos SDO_GEOMETRY
Um exemplo para armazenar um único ponto no campo de SDO_POINT (Se você
estiver armazenando um ponto 2D no campo de SDO_POINT, ajustar o valor de z para null): INSERT INTO TELEPHONE_POLES VALUES (attribute_1, attribute_n,
MDSYS.SDO_GEOMETRY (2001, null, MDSYS.SDO_POINT_TYPE(-
75.2,43.7,NULL), null, null)); Se você usar uma indexação espacial quadtree, o índice spatial será 2D (isto é,
somente x e y são posicionados). Os filtros preliminares de Quadtree são 2D. Se for usado
índices espaciais do R-tree, pode posicionar até 4 dimensões. Não obstante do tipo do índice
escolhido, o oracle spatial tem como filtros secundários sempre 2D (isto é, as comparações
volumétricas não são suportadas). Se você tiver um algoritmo volumétrico para comparar
geometrias, você pode executar este como um PL/SQL ou um procedimento armazenado em
Java, e chama-o nos resultados de um filtro preliminar da R-tree (na mesma indicação do
SQL).
Para gerar índices espaciais no campo de SDO_POINT, os campos de
SDO_ELEM_INFO e de SDO_ORDINATES devem ser nulos. O campo de SDO_POINT
será ignorado pelo Oracle Spatial se os campos de SDO_ELEM_INFO e de
SDO_ORDINATES não forem nulos.
5.5.12 Tipos de Elementos Sumariados
Representa um elemento no campo de SDO_ELEM_INFO do objeto de
SDO_GEOMETRY.
Uma geometria pode ser composta de um ou mais elementos. Se a geometria não for um
único ponto armazenado no campo de SDO_POINT, cada elemento terá uma entrada no
terceiro campo da disposição de SDO_ELEM_INFO (ordenada deslocada, tipo do elemento,
interpretação).
O offset da ordenada é um número que representa onde o elemento começa na
disposição de SDO_ORDINATES. A figura 55 descreve somente outras duas partes do
terceiro campo (tipo, interpretação do elemento).
91
Não confundir com o tipo SDO_GTYPEs, pois o tipo de elemento descreve o elemento
enquanto o SDO_GTYPEs representa que tipo de geometria é armazenado, onde uma
geometria é composta de um ou mais elemento.
O tipo 3 do elemento é substituído com o 1003 (anel exterior) ou o 2003 (buraco), e o
tipo 5 do elemento é substituído com o 1005 (anel exterior) ou o 2005 (buraco). O tipo do
elemento de quatro dígitos para polígonos esteve introduzido para fazê-lo mais fácil de
determinar se um elemento do polígono fosse um anel exterior ou um buraco.
Os tipos de elementos ficam da seguinte forma:
1. Para armazenar pontos ou vários pontos. O campo da interpretação descreve como
muitos pontos são armazenados.
2. Para armazenar as cadeias de linhas. A interpretação 1 representa uma linha
convencional cadeia conectada com as linhas retas. A interpretação 2 representa
uma linha circular cadeia do arco composta de um ou mais arco da circular.
3. 1003 representa um polígono exterior do anel, 2003 representam um anel interno (ou
o buraco).
• Interpretação 1: Polígono convencional conectado com as linhas retas;
• Interpretação 2: Polígono do arco, conectado com os arcos circulares;
• Interpretação 3: O retângulo simples requer somente uns pontos direitos esquerdos,
superiores e inferior para representar o retângulo;
• Interpretação 4: Círculo simples (não verdadeiramente um polígono, mas
categorizado com polígono porque tem a área).
4. Cadeia de linha composta, elemento contíguo que contem linhas retas e arcos
circulares. O campo da interpretação determina quantos subelementos (isto é,
terceiro valor no campo de SDO_ELEM_INFO);
5. 1005 representa um polígono exterior do composto de anel (um elemento contíguo
que contenha linhas retas e arcos circulares). 2005 representam um polígono
composto que seja um anel interno (ou buraco). O campo da interpretação determina
quantos subelementos (isto é, terceiro valor no campo de SDO_ELEM_INFO).
92
Figura 55 - Tipos do elemento sumariados
5.5.13 Cadeia de linha
Na tabela desenhada na figura 56 está o terceiro valor (offset da ordenada, tipo do
elemento, interpretação) você armazena o campo de SDO_ELEM_INFO. A maioria dos
ordenada do offsets esta no começo da tabela (ordinate offset), no exemplo o valor esta em 1
porque descreve geometria com um único elemento.
O elemento tipo 2 do elemento corresponde a uma linha elemento da cadeia, onde é
feita de um ou mais segmentos contíguos.
O campo da interpretação para um elemento tipo 2 definirá como conectar os segmentos
que fazem a cadeia de linha. Neste exemplo, a interpretação é 1, e corresponde a uma cadeia
de linha cujos segmentos sejam conectados com as linhas retas (uma linha convencional).
A cadeia de linha pode até apresentar uma forma, pode até se cruzarem umas com as
outras, mas não tem nenhuma área.
O SDO_GTYPE para representar essa geometria é 2002 (única linha do elemento da
cadeia).
93
Figura 56 - Exemplo de Cadeia de linha
5.5.14 Cadeia de arco
O campo da interpretação para o elemento tipo 2 (figura 57) definirá como conectar os
segmentos da linha. Neste exemplo, a interpretação é 2, e corresponde a uma linha cujos
segmentos estão conectados com os arcos circulares. Um arco circular é definido por três
pontos distintos na circunferência de um círculo, o primeiro ponto, o último ponto e o ponto
distinto dentro o meio, o raio. O último ponto de um arco circular é o primeiro ponto do arco
circular seguinte.
A cadeia de linha pode até apresentar uma forma, um arco pode se cruzar umas com as
outras, mas não tem nenhuma área.
O SDO_GTYPE para representar essa geometria é 2002 (única linha do elemento da
cadeia).
Figura 57 - Exemplo de Cadeia de Arco
5.5.15 Polígono
O elemento tipo 3 corresponde um polígono, representado na figura 58. Um polígono
implica em área. Os polígonos exteriores do anel são representados como o elemento tipo
1003, e os polígonos (buracos) internos do anel são representados como elemento do tipo
2003.
94
Os polígonos exteriores do anel devem ser armazenados com uma rotação anti-horária.
Os polígonos (buracos) internos do anel devem ser armazenados com uma rotação sentida
horário.
Reforçar que rotação permite uns cálculos mais rápidos da área. Ao determinar a
rotação, o lado esquerdo recebe os valores do sistema de coordenadas.
O último ponto de um polígono deve ser igual ao primeiro ponto. Mesmo que este ponto
poderia ser derivado, deve-se repetir conforme a Open GIS Consortium (OGC) Standard.
O campo da interpretação definirá como conectar os segmentos que fazem parte do
polígono.
Neste exemplo, a interpretação é 1, e corresponde a um polígono cujos segmentos sejam
conectados com as linhas retas (um polígono convencional).
Os segmentos das linhas dos polígonos não podem cruzar-se.
O SDO_GTYPE para esta geometria é 2003 (único elemento do polígono).
Figura 58 - Exemplo de Polígono
5.5.16 Arco Polígono
No exemplo da figura 59, a interpretação é 2, e corresponde a um polígono cujos
segmentos sejam conectados com os arcos circulares. Um arco circular é definido por três
pontos na circunferência de um círculo.
95
Figura 59 - Exemplo de Polígono
5.5.17 Retângulo
O elemento tipo 3 corresponde a um polígono. Polígonos exteriores do anel são
representados como o elemento tipo 1003, e os polígonos internos (buracos) do anel são
representados como elemento do tipo 2003.
No exemplo da figura 60, a interpretação é 3, e corresponde a um retângulo simples
para o armazenamento.
Somente o ponto direito superior e esquerdo inferior do retângulo é armazenado.
O SDO_GTYPE para esta geometria é 2003 (único elemento do polígono).
Figura 60 - Exemplo de Retângulo
5.5.18 Circulo
O elemento tipo 3 do elemento corresponde a um polígono. Polígonos exteriores do anel
96
são representados como o elemento tipo 1003, e os polígonos internos (buracos) do anel são
representados como elemento do tipo 2003. Os polígonos exteriores do anel devem ser
armazenados com uma rotação sentido anti-horário. Os polígonos internos (buracos) do anel
devem ser armazenados com uma rotação sentida horário. Reforçar a rotação permite uns
cálculos mais rápidos da área.
No exemplo da figura 61, a interpretação é 4, e corresponde a um círculo. O círculo é
representado por todos os três pontos distintos na circunferência.
Figura 61 - Exemplo de Retângulo
5.5.19 Cadeia de linhas compostas
O elemento do tipo 4 corresponde a uma cadeia de linha composta. Linhas compostas (
tipo do elemento 2) foram conectadas todas com as linhas retas ou todas conectadas com os
arcos circulares.
Com uma cadeia de linha composta, você pode definir uma única linha contígua, cadeia
que seja composta de linhas retas e de arcos circulares.
A cadeia de linha composta tem as mesmas propriedades que uma cadeia de linha. As
linhas podem se cruzar, mas não suportam nenhuma área, mesmo se pelo cruzamento a reta
ou arco se fecharem, dando forma a um anel.
Uma cadeia linha composta é definida por uma série de subelementos contíguos. Cada
subelemento será uma linha reta, ou um arco circular.
Todos os subelementos devem ser do tipo 2 (a interpretação 1 ou 2), e deve ser
contíguo (isto é, o último ponto de um subelemento é o primeiro ponto do subelemento
seguinte). A observação no exemplo da figura 62, as ordenadas do offsets de cada
subelemento são diferente, e corresponde a onde o subelemento começa na disposição da
97
ordenada.
O SDO_GTYPE para esta geometria é 2002 (elemento de cadeia de linha).
`
Figura 62 - Exemplo de Cadeia de linhas Compostas
5.5.20 Polígono composto
O elemento do tipo 5 corresponde a um polígono composto. O polígono (elemento do
tipo 3) foi conectado por linhas retas ou conectado com os arcos circulares.
Com um polígono composto, pode se definir um único polígono com linhas retas
contíguas e arcos circulares.
Os polígonos compostos têm as mesmas propriedades que polígonos (isto é, não pode se
cruzarem). Polígonos exteriores do composto de anel são representados como o tipo 1005 do
elemento, e polígonos compostos internos do anel (buraco) são representados como o tipo
2005 do elemento.
Os polígonos exteriores do composto de anel devem ser armazenados com uma rotação
sentida anti-horário. Os polígonos compostos internos do anel (buraco) devem ser
armazenados com uma rotação sentido horário.
Todos os subelementos devem ser do elemento tipo 2 (a interpretação 1 ou 2), e deve
ser contíguo (isto é, o último ponto de um subelemento é o primeiro ponto do subelemento
seguinte). A observação no exemplo da figura 63, as ordenadas do offsets de cada
subelemento é diferente, e corresponde a onde o subelemento começa na disposição da
ordenada.
O SDO_GTYPE para esta geometria é 2003 (único elemento do polígono).
98
Figura 63 - Exemplo de Polígono Composto
5.5.21 Polígono com buraco
Na figura 64 esta representada um polígono com um buraco. O anel exterior tem um
tipo do elemento de 1003, e o anel interno tem um tipo do elemento de 2003.
Os buracos podem conter áreas, e as áreas podem conter buracos. A área é computada
como a diferença entre polígonos exteriores e interiores.
A rotação de elementos exteriores dos anéis deve ser sentido anti-horário, e os
elementos internos do anel devem ser no sentido horário.
Um elemento exterior do anel deve ser seguido por todos seus elementos internos do
anel antes que um outro elemento exterior do anel possa ser especificado como a parte da
geometria.
O SDO_GTYPE desta geometria é 2003 (polígono 2D). Um polígono com um ou o
mais buracos pode ainda ser considerado um único polígono (isto é, não categorizado como
vários polígono).
Figura 64 - Polígono com Buraco
99
5.5.22 Polígono composto com buraco
No exemplo da figura 65 temos um anel exterior do tipo de elemento 1005 (polígono
composto), e o anel interno do tipo de elemento de 2003 (retângulo simples).
O polígono composto tem 3 entradas no terceiro campo de SDO_ELEM_INFO. O
primeiro dos três é um encabeçamento (1.1005.2). A interpretação de 2 definiu os
subelementos compostos do polígono (1.2.1) e (7.2.2).
Observe que o terceiro valor desta geometria (17.2003.3) não é parte do polígono
composto. Define um buraco, nesse caso é um retângulo.
O SDO_GTYPE desta geometria é 2003 (polígono 2D).
Figura 65 - Polígono composto com Buraco
5.5.23 Elemento desconhecido
Se for necessário modelar algo que o oracle spatial não suporta (por exemplo, uma
curva ou uma ranhura, ver figura 66), você pode usar um tipo 0 do elemento (elemento
desconhecido).
A geometria com um tipo 0 do elemento deve conter ao menos um elemento do tipo 1,
2, 1003, 2003, 4, 1005, ou 2005. O elemento do tipo 0 é uma aproximação do elemento não
suportado. A aproximação é posicionada e perguntada para o Oracle Spatial.
O SDO_GTYPE desta geometria é 2003 (polígono 2D).
100
Figura 66 – Elemento desconhecido
5.5.24 Conjunto de pontos
Uma coleção é uma geometria que contem mais de um elemento. Na figura 67, a
coleção são vários pontos. Elemento é do tipo 1, e a interpretação corresponde ao número dos
pontos na coleção.
O SDO_GTYPE para esta geometria é 2005 (vários pontos 2D).
Figura 67 - Coleção de pontos
5.5.25 Coleção de cadeias de várias linhas
Para uma cadeia de várias linhas, cada elemento na coleção contém um valor no terceiro
campo de SDO_ELEM_INFO. No exemplo da figura 68, a linha reta da cadeia é (1.2.1) e o
circular da cadeia do arco é (7.2.2).
O SDO_GTYPE para esta geometria é 2006 (cadeia de várias linhas 2D).
101
Figura 68 - Coleção de Multipontos
5.5.26 Coleção de Polígonos
Na figura 69, a coleção são vários polígono, onde cada elemento da coleção contém um
valor no campo de SDO_ELEM_INFO. No terceiro campo do elemento do polígono
pentágono é (1.1003.1) e o círculo é (13.1003.4).
O SDO_GTYPE para esta geometria é 2007 (vários polígonos 2D).
Figura 69 - Coleção de polígonos
5.5.27 Construção de geometrias
A indicação da inserção usa um construtor de SDO_GEOMETRY, ajusta o SRID, e
campos de SDO_POINT null, e usos SDO_ELEM_INFO_ARRAY e
construtores de SDO_ORDINATE_ARRAY para povoar os campos da disposição.
. O exemplo da figura 70 esta inserindo uma cadeia de linhas, onde attibute_1, ..., .
attribute_n, representam as colonas convencionais de um banco de dados relacional. O
MDSYS.SDO_GEOMETRY (objeto sdo_gtype representa o tipo e a dimensão da geometria,
objeto sdo_srid tipo da coordenada, objeto sdo_point se for ponto usar esse objeto,
102
sdo_elem_info_array mostra quais serão o tipo da geometria um a um, no caso temos inicio 1
uma linha (representado por 2) conectado por uma linha reta (representada por 1 conforme
figura 55). Como não é mencionado outra geometria todos o pares de pontos são considerado
uma linha reta conectada ponto a ponto. O mdsys.sdo_ordinate_array caracteriza os pontos da
geometria.
Figura 70 - Inserindo uma cadeia de linhas
Um outro exemplo representado na figura 71 armazena a informação nos campos da
disposição (SDO_ELEM_INFO e SDO_ORDINATES) do objeto de SDO_GEOMETRY.
Este exemplo está introduzindo os polígonos compostos com um exemplo de buraco.
A indicação da inserção usa um construtor de SDO_GEOMETRY, ajusta o SRID, e
campos de SDO_POINT null, e usos SDO_ELEM_INFO_ARRAY e
construtores de SDO_ORDINATE_ARRAY para povoar os campos da disposição.
O SDO_GTYPE desta geometria (figura 71) é 2003 (polígono 2D). Um polígono com
um ou mais elementos (com buraco) pode ainda ser considerado um único polígono (isto é,
não categorizado como vários polígonos).
103
Figura 71 - Inserindo uma cadeia de polígonos
5.5.28 Metadados espacial
Para cada coluna de SDO_GEOMETRY, deve-se povoar o metadados em uma visão do
dicionário chamada USER_SDO_GEOM_METADATA. Esta visão já é criada quando é
instala do oracle spatial.
O metadados da geometria que descreve as dimensões, limites inferiores, superiores, e
tolerância em cada dimensão são armazenados em uma tabela global possuída por MDSYS
(onde os usuários nunca devem diretamente fazer atualização). Cada usuário do banco tem as
seguintes visões disponíveis no schema (usuário SYS) associado com esse usuário:
• USER_SDO_GEOM_METADATA contem a informação do metadados para
todas as tabelas espaciais com usuário (schema). Esta é a única visão que você
pode atualizar, e é esse em que os usuários espaciais devem introduzir o
metadados relacionado às tabelas espaciais.
• ALL_SDO_GEOM_METADATA contem a informação do metadados para todas
as tabelas espaciais em que o usuário tem a permissão SELECT.
Os usuários espaciais são responsáveis por povoar estas visões. Para cada coluna
espacial, você deve introduzir uma fileira apropriada na visão de
USER_SDO_GEOM_METADATA. O oracle spatial assegura-se de que a visão de
ALL_SDO_GEOM_METADATA esteja atualizada também para refletir as fileiras que você
104
introduzir em USER_SDO_GEOM_METADATA.
Cada visão do metadados tem a seguinte definição:
(
TABLE_NAME VARCHAR2(32),
COLUMN_NAME VARCHAR2(32),
DIMINFO SDO_DIM_ARRAY,
SRID NUMBER
);
5.5.28.1 TABLE_NAME
A coluna de TABLE_NAME contem o nome de uma tabela característica, tal como
COLA_MARKETS, que tem uma coluna do tipo SDO_GEOMETRY.
O nome da tabela é armazenado na visão espacial do metadados com todos os
caracteres em caixa alta.
COLUMN_NAME
A coluna de COLUMN_NAME contem o nome da coluna do tipo
SDO_GEOMETRY.
O nome da coluna é armazenado na visão espacial do metadados em todos os
caracteres em caixas alta.
5.5.28.2 DIMINFO
A coluna de DIMINFO é uma disposição variando do comprimento de um tipo do
objeto, requisitada pela dimensão, e tem uma entrada para cada dimensão. O tipo de
SDO_DIM_ARRAY é definido como segue:
Criar o tipo SDO_DIM_ARRAY como VARRAY(4) de SDO_DIM_ELEMENT;
O tipo de SDO_DIM_ELEMENT é definido como:
Create Type SDO_DIM_ELEMENT as OBJECT (
SDO_DIMNAME VARCHAR2(64),
105
SDO_LB NUMBER,
SDO_UB NUMBER,
SDO_TOLERANCE NUMBER);
O exemplo de SDO_DIM_ARRAY é do tamanho n se houver umas dimensões de n.
Isto é, DIMINFO contem 2 exemplos de SDO_DIM_ELEMENT para geometrias
bidimensionais, 3 exemplos para geometrias tridimensionais, e 4 exemplos para geometrias
com quatro dimensões. Cada exemplo de SDO_DIM_ELEMENT na disposição deve ter
valores (not null) válidos para os atributos de SDO_LB, de SDO_UB, e de
SDO_TOLERANCE.
A disposição variando do comprimento de DIMINFO deve ser requisitada pela
dimensão na mesma maneira que as ordenadas para os pontos na disposição variando do
comprimento de SDO_ORDINATES são requisitadas. Por exemplo, se a disposição variando
do comprimento de SDO_ORDINATES contiver {X1, Y1…, X n, Y n}, então a primeira
entrada de DIMINFO devem definir a dimensão de X e a segunda entrada de DIMINFO deve
definir a dimensão de Y.
5.5.28.3 SRID
A coluna de SRID deve conter qualquer um do seguinte: o valor de SRID para o
sistema coordenado para todas as geometrias da coluna, ou NULL se nenhum sistema
coordenado específico for associado com a geometria.
5.5.28.4 Exemplo
INSERT INTO USER_SDO_GEOM_METADATA
(TABLE_NAME,COLUMN_NAME,DIMINFO,SRID)
VALUES
('posicao','GEOM',MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X',-180.000000000,180.000000000,0.500000000),
MDSYS.SDO_DIM_ELEMENT('Y',-90.000000000,90.000000000,0.500000000)),8307);
106
6 INSERINDO DADOS NO FORMATO SHAPEFILE
Um shapefile é um formato de arquivo de dados introduzido pela ESRI para armazenar
características geográficas no formato vetorial. Isso significa que as características de um
mapa são representadas como conjuntos de coordenadas X e Y. As coordenadas em shapefiles
usam o sistema de coordenadas cartesianas.
A geometria de cada característica é armazenada como uma figura (shape) que inclui
um conjunto de coordenadas vetoriais. Os atributos de cada característica são armazenados
como um registro em uma tabela dBASE associada com o shapefile. Há um registro na tabela
dBASE para cada característica no arquivo principal.
Um shapefile é armazenado na forma de três arquivos no sistema de arquivos do
computador, como mostra a figura 72. O arquivo principal contém a geometria para as
figuras. O arquivo de índices contém um índice seqüencial de offsets das figuras. A tabela
dBASE contém os atributos para cada figura. Pode-se modificar as definições dos campos
(adicionando, retirando ou alterando campos) numa tabela dBASE.
Figura 72 – Arquivos Shapefile
Cada shapefile contém um tipo de figura. Usa-se múltiplos shapefiles para representar
múltiplos tipos de figuras. Essas figuras podem ser qualquer uma descrita no tópico de
Elementos SDO_GEOMETRY.
Nesse capitulo será descrito como carregar os dados usando comandos padrão do
oracle (SQL*Loader, importação, inserção), como usar uma ferramenta (shp2sdo) no qual
converte um arquivo ESRI shapefiles para comandos SQL do oracle spatial para ser inserido
em uma tabela. conceito
107
Duas etapas2 são envolvidas para mover todos os dados, de modo que possa ser feita
consulta de forma eficientemente:
1. Converter os arquivos ESRI shapefiles usando o programa shp2sdo;
2. Usar o arquivo .sql para criar a tabela no banco e posterior mente usar o
SQL*Loader (sqlldr login/senha .ctl) para importar o mapa propriamente dito que
esta com a extensão .crt.
O SQL*Loader tem a seguinte funcionalidade:
• Adicionar dados à tabela existente, ou substituir dados na tabela existente;
• Manipular campos de dados com funções do SQL antes de introduzir os dados em
colunas da base de dados;
• Gerar chaves primarias, chaves seqüenciais, valores em colunas especificas;
• Importar os dados convertidos para o banco de dados;
• Relatar todos os erros de modo que seja possível facilmente ajustar e carregar
todos os registros.
SQL*Loader não reconhece formatos de dados espaciais proprietários de outros
vendedores. Ou usa o arquivo ESRI shapefiles para que o programa desenvolvido pela própria
oracle (shp2sdo) faça as converções ou usa o programa FME da Safe Software
(www.safe.com.br) ou o GIS/Spatial.
2 Esse processo será descrito com detalhes
108
Figura 73 - Exemplo de um arquivo SQL*Loader com pontos
Na figura 73 está um exemplo de um arquivo de controle do SQL*Loader. Observar o
seguinte:
• INFILE * significa que os dados a serem inseridos estão logo após o comando
BEGINDATA;
• INTO TABLE cities significa que a tabela cities é quem estará sendo carregada;
• FIELDS TERMINATED BY ‘|’ significa que cada campo estará terminado com
uma barra vertical (os campos não são de comprimento fixo);
• TRAILING NULLCOLS ajustar-se a NULL caso o campo preenchido conter
apenas um ou mais espaço branco. Representado por NULLIF coluna=BLANKS;
• Vem em seguida à coluna da posição do tipo SDO_GEOMETRY. A sintaxe
mostrada (isto é, COLUMN OBJECT) é específica para objetos; a sintaxe não é
específica ao oracle spatial;
• É obrigatório o comando EXTERNAL depois de cada tipo de dados.
Logo após o BEGINDATA observe que CITY é o primeiro dado a ser inserido e caso
conter somente espaços ele será preenchido com NULL, depois vem STATE_ABRV que
também não aceita espaço em branco, me seguida vem POP90, RANK90 e finalmente os
tipos de objetos, SDO_GYTPE e SDO_POINT.
Todas as partes dos SDO_GEOMETRY que não forem especificados ira receber
NULL, por exemplo, SDO_SRID, SDO_ELEM_INFO e SDO_ORDINATES.
109
Figura 74 - Exemplo de um arquivo SQL*Loader com polígonos
O exemplo da figura 74 é muito similar ao exemplo da figura 73. Há algumas
diferenças. A primeira diferença é:
• CONTINUEIF NEXT(1:1) = ‘#’ Esta sintaxe faz com que o SQL*Loader olhe o
primeiro caráter de cada registro de entrada. Se for # continuará lendo como se
fosse uma única linha. Uma das exigências quando usar esta sintaxe é que nunca se
deve usá-lo na primeira posição de um registro. O SQL*Loader olhará sempre a
primeira posição de caráter e se for a # tratará o registro como uma continuação do
registro precedente, causando um erro, pois o programa ira pensar que é
continuação do BEGINDATA;
• Nesse exemplo o registro, que é um polígono, é terminado por barra vertical (|);
• A maneira que o SQL*Loader tem de representar o final dos tipos de dado
SDO_ELEM_INFO e SDO_ORDINATES varray é colocando ‘|/’.
6.1 RESTRIÇÕES
O SQL*Loader não suporta arquivos com mais de 64k, caso isso ocorra será necessário
quebrar o arquivo em dois ou mais arquivos com menos de 64k.
Quando houver importação de vários dados é aconselhável criar o índice somente
depois que todos os dados forem importados, dessa forma os índices serão construídos com
mais facilidade e integridade.
6.2 CONVERTENDO ARQUIVOS SHAPEFILE
O conversor de arquivos Shapefile é uma ferramenta externa ao Oracle e pode ser
encontrada no site www.oracle.com/technology/software/products/spatial/index.html.
No exemplo da figura 75 mostra como invocar o shapefile ao conversor espacial do oracle.
Figura 75 - Sintaxe para usar o shp2sdo
110
O primeiro parâmetro <shapefile> é o nome do shapefile. O conversor usará a entrada
do .shp, .dbf e do .shx.
O segundo parâmetro <table-name> é o nome da tabela espacial a ser criada. Seguindo
o mesmo padrão que o oracle suporta.
O terceiro parâmetro –g seguido do <geometry-col> especificam o nome da coluna da
geometria a ser criado na tabela. É do tipo MDSYS.SDO_GEOMETRY.
O quinto parâmetro –i seguido do <id-col> é um parâmetro opcional, onde cria uma
coluna numérica que possa ser usada para armazenar um campo de identificador. O oracle
espacial não tem nenhuma exigência que este campo existe, mas muitas ferramentas requerem
um campo com uma chave numérica.
O sétimo parâmetro –n é um parâmetro usado para povoar o campo chaves numéricas,
criadas pelo parâmetro -i. Se um <id-col> for fornecido os números vão começar a ser gerada
a partir desse valor. Se não, os números começam em 0.
O oitavo parâmetro -d é usado para especificar que os dados devem ser incluídos
diretamente no arquivo de controle. Se não, um arquivo de dados separado é usado.
O nono parâmetro – x seguido do décimo (Xmin, Xmax) é usado para dizer ao oracle
os limites (ou a extensão) da primeira dimensão de o sistema coordenado que vai ser usado.
Se não especificado, os limites são extraídos do arquivo shapefile. A oracle recomenda usar
este parâmetro os maiores do sistema coordenado. Como por exemplo, para os dados
armazenados como Longitude/Latitude, os valores de Xmin e Xmax devem ser ajustados aos
valores menores e maiores da longitude, isto é, -180, 180.
O décimo primeiro parâmetro - y décimo segundo (Ymin, Ymax) é usado para dizer ao
oracle os limites (ou a extensão) da segunda dimensão de o sistema coordenado que vai ser
usado. Se não especificado, os limites são extraídos do arquivo shapefile. A oracle recomenda
usar este parâmetro os maiores do sistema coordenado. Como por exemplo, para os dados
armazenados como Longitude/Latitude, os valores de Ymin e Ymax devem ser ajustados aos
valores menores e maiores da latitude, isto é, -90, 90.
O décimo quarto parâmetro -s seguido do décimo quinto <srid> é usado especificar o
sistema coordenado (sistema espacial de referência) associado com os dados. Por default,
nenhuma informação do sistema de coordenada é carregada (NULL para SDO_SRID na
coluna de SDO_GEOMETRY e NULL para SRID dentro
USER_SDO_GEOM_METADATA)
O décimo sexto -t <tolerance> deve ser especificado se o valor da tolerância a ser
carregado na disposição de DIMINFO é um valor de 0.00000005.
111
7 MAPSERVER
O MapServer foi originalmente desenvolvido pela University of Minnesota
(UMN) ForNet, projeto em cooperação com a NASA e com o Minnesota Department of
Natural Resources (MNDNR). Alguns aprimoramentos foram feitos pelo MNDNR e pelo
Minnesota Land Management Information Center (LMIC). O atual desenvolvimento é
financiado pelo projeto TerraSIP, um projeto patrocinado pela NASA entre o UMN e o
Consortium of Land Management Interests.
O MapServer não é um sistema GIS completo, nem pretende ser. Porém, ele fornece
funcionalidades suficientes para sustentar uma ampla variedade de aplicações web. Além da
leitura de dados GIS, o MapServer permite a você criar "imagens de mapas geográficos", isto
é, mapas que conseguem mostrar o conteúdo claramente para os usuários. Por exemplo, a
Minnesota DNR "Recreation Compass“ fornece mais de 10,000 páginas web, notícias e
mapas através de um simples aplicativo. O mesmo aplicativo serve como um "map engine"
para outras partes do site, fornecendo o contexto espacial necessário.
O MapServer normalmente é executado como uma aplicação CGI a partir de um
servidor HTTP. Essa forma de implementação resolve na maioria dos casos, a menos que
você queira desenvolver uma aplicação mais avançada usando o MapScript, que acessa a API
do MapServer diretamente.
As aplicações CGI MapServer usam os seguintes recursos:
1. Um servidor HTTP como Apache, IIS;
2. O software MapServer;
3. Um arquivo de inicialização, que define a primeira visão da aplicação MapServer
(opcional);
4. Um Mapfile, que define como o MapServer manipulará os dados;
5. Um arquivo template, que define a interface de usuário da aplicação MapServer na
janela do browser;
6. A base de dados SIG.
O MapServer é normalmente instalado no diretório "cgi-bin" de um servidor HTTP, e
os arquivos gerados pelo MapServer e a base de dados SIG são armazenados em diretórios do
servidor HTTP.
112
A lógica de uma aplicação típica MapServer é descrita no diagrama da figura 76.
Figura 76 - Lógica de uma aplicação MapServer
Fonte: http://mapserver.gis.umn.edu
7.1 O ARQUIVO DE INICIALIZAÇÃO
Este arquivo pode fazer parte de outro arquivo HTML, porém, para simplificar é
interessante que seja um arquivo separado.
O Arquivo de Inicialização utiliza um formulário para enviar uma consulta inicial ao
servidor HTTP, que retornará um resultado do MapServer. O MapServer não conserva
estados entre solicitações e respostas (sessões).
O MapServer é iniciado e executado cada vez que uma solicitação de consulta é
recebida, portanto o arquivo de inicialização é apenas uma forma de passar parâmetros ao
MapServer, sem que os mesmos fiquem expostos em código HTML.
O arquivo de inicialização é um arquivo HTML comum, com extensão .htm ou .html.
113
Também é possível iniciar a aplicação através de um link (sem usar um formulário), porém
este link deve conter os parâmetros básicos requeridos pela aplicação CGI MapServer.
7.2 O MAPFILE
O Mapfile define a origem dos dados que são usados na aplicação, bem como as
formas de apresentação destes dados ou parâmetros de consulta. Em outras palavras, é o
arquivo de configuração da aplicação. O Mapfile também contém informações sobre como
desenhar o mapa, a legenda, barra de escala e os mapas resultantes de uma consulta. Mapfiles
normalmente possuem a extensão .map.
7.3 O ARQUIVO TEMPLATE
O Arquivo Template define como mapas, legendas etc.. gerados pelo MapServer serão
apresentados em uma página HTML; funciona como qualquer arquivo HTML normal, exceto
pelo fato de que tags especiais são manipuladas/geradas pelo MapServer. O arquivo template
permite posicionar o mapa e/ou seus componentes na página e determinar como o usuário
poderá interagir com a aplicação (ex.: browse, query, zoom etc....). O Mapserver processa o
arquivo template e substitui palavras reservadas neste arquivo com informações relativas ao
seu estado corrente ou à base de dados SIG para produzir o resultado em HTML que será
enviado ao browser do usuário. Normalmente, utiliza-se arquivos templates terminados com a
extensão .html. Veja o Guia de Referência do Arquivo Template para uma documentação
mais detalhada.
7.4 A BASE DE DADOS SIG
O Mapserver utiliza shapefiles ESRI como formato padrão para dados vetoriais. Dados
matriciais podem ser lidos de diversos formatos, isto apenas depende de como o MapServer
foi compilado. Por padrão, o MapServer suporta arquivos geoTiff e arquivo Tiff com world
file. Outros formatos podem ser usados, mas isto é um pouco mais complicado. Os arquivos
da base de dados SIG devem estar localizados no diretório referenciado pelo Mapfile.
114
8 MODELAGEM
8.1 BANCO DE DADOS
Figura 77 – Banco de dados
Na tabela Fpolis_Logradouro não tem chave primária por não precisar identificar
(exclusivamente) um registro, nessa aplicação a tabela funciona como um repositório,
contudo o índice (fpolis_logradouro_ipx) esta no atributo GEON, onde é o objeto espacial.
Essa tabela contém os dados espaciais do mapa de Florianópolis, somente os dados físico
representando as ruas, não foi obtido o nome das mesmas.
Na tabela Fpolis_Logradouro não foi construída chave primária para mostrar como o
sistema gera a tabela, os campos foram criados a partir do arquivo shapefile, claro que nada
impede de ser manipulada, criar novos campos (os dados espaciais estão no atributo GEON só
isso não pode ser mudado de forma alguma), contudo nessa aplicação o objetivo não exige
nenhuma alteração.
As demais tabelas já estão normalizadas e respeitando as regras de relacionamento.
A tabela posicao também foi indexada (posicao_idx) pelo GEON e como pode ser
115
observado tem chave primária, esses pontos são individuais e cada registro é único e precisa
ser identificado exclusivamente.
8.2 DIAGRAMA DE ESTADOS
No diagrama da figura 78 demonstra dois sistemas. Um onde o cliente logo no sistema
com um login e senha. Esses dados são recuperados no banco e verificado se estão corretos e
se esta ativo. Caso afirmativo o sistema libera a próxima tela.
Confirmado os dados a próxima tela apresenta um menu no qual o cliente vai poder
escolher qual ou quais veículos ele pretende localizar.
Através de um radio button o cliente vai definir como o mapa ira aprensetar a
localização, ou seja, caso seja selecionado um veículo o sistema ira habilitar a possibilidade
de criar seu rastro ou localizar a ultima posição. Caso selecionado vários veículos somente
será apresentado a ultima posição de cada veículo selecionado.
A apresentação do mapa será possível fazer uma navegação, aproximando, afastando,
indo para direita, esquerda, para cima ou para baixo. Assim é possível ver mais detalhes do
mapa caso seja necessário.
O modulo é um programa residente no linux que fica de tempo em tempo verificando
novas posições. Como o objetivo não é criar esse comunicador o programa residente já pega
os dados processados e coloca no banco de dados espacial de forma que o sistema consiga
fazer as devidas projeções solicitadas. Não será detalhado esse sistema pelo fato dos dados
serem sigilosos e essa apresentação é uma simulação para tornar mais real o projeto.
116
Figura 78 – Diagrama de Estados
8.3 DIAGRAMA DE CLASSES
Na figura 79 esta modelado o diagrama de classes, onde a classe modulo pega dos
dados da posição do veículo e coloca no banco de dados na tabela posicao. Não será detalhado
por esses dados serem sigilosos.
A classe cliente verifica os dados, confirmando ele pergunta para classe veliculo quais
são os veículos pertencentes ao cliente confirmado.
Retornando a lista de veículos o cliente escolhe se deseja localizar um ou vários
veículos, caso deseja um ele pode localizar por período, gerando com isso um rastro.
As camadas do mapa serão criadas pelo Oracle e o Mapserver, ou seja,
dinamicamente o sistema constroe a consulta e em conjunto as ferramentas criam o mapa e
apresentam na tela.
117
Figura 79 – Diagrama de Classes
8.4 DESENVOLVIMENTO
O sistema de rastreamento tem como objetivo mostrar a ultima posição veículo, ou em
um período mostrar seu rastro, ou seja, as posições do período solicitado.
Devido à ausência da camada de logradouro, o sistema se limita em mostrar a posição no
mapa, não disponibilizando o nome da rua.
A primeira tela (figura 80) pede o login e senha do usuário. Esses dados alem de autorizar
o uso do sistema, será feita uma pesquisa no banco mostrando todos os veículos cadastrados
para esse usuário.
Figura 80 – Tela inicial
Confirmado a login e a senha o sistema permite o usuário escolher o veiculo a ser
rastreado ou localizado (figura 81).
Figura 81 – Localizar um veículo
118
Uma vez escolhido o veiculo e que tipo de informação deseja (no caso figura 81), é só
apertar o botão enviar para que o servidor possa montar o mapa e mostrar a ultima3 posição
do veiculo, mostrado na figura 82.
Figura 82 – Mapa da solicitação de “Localizar um veículo”
Para mostrar o rastro do veículo é necessário colocar uma data de inicio e de fim para
limitar as posições e apresentar o rastro pertinente ao período desejado (figura 83).
Figura 83 – Mostrar o rastro do veículo
O rastro é representado por vários pontos por onde o veiculo passou durante o tempo
escolhido (data inicial e final). Esse mapa é demonstrado na figura 84.
3 Essa posição vem de equipamentos embarcado, onde não foi descrito nesse projeto, leva-se em conta que esses dados estão no banco de dados.
119
Figura 84 – Mapa da solicitação de “Localizar rastro de um veículo”
120
9 CONCLUSÃO
O banco de dados espacial é uma ferramenta para armazenar objetos no espaço,
facilitando a manipulação (inserir novos objetos, excluir ou alterar), bem como possibilitando
dar características a esses objetos, como por exemplo, definir sentido de ruas, mapearem áreas
de risco, entre outras informações respeitando as características de um banco relacional.
Esses objetos espaciais agrupados entre si, permitem a criação de mapas ou cartas,
contudo o banco de dados não foi projetado para fazer essa visualização, para essa tarefa foi
usada outra ferramenta que é o Mapserver.
O oracle contém inúmeras funções para manipular os dados, nos quais não foram
descritos nem a metade neste trabalho, como o objetivo era mostrar como usar o oracle e o
Mapserver para rastreamento de veículos, o trabalho se limitou em integrar as duas
ferramentas e montar algumas camadas para possibilitar a visualização do objeto veículo.
Como a Mapserver não tem o oracle como um banco nativo, foi criado um drive
especifico para possibilitar o desenvolvimento de um trabalho de rastreamento de navios pelo
CTTMAR (www.cttmar.univali.br), onde houve problemas com a integração, pois a
interpretação de múltiplos polígonos não é possível até o presente momento. Assim sendo o
mapa precisou ser montado usando apenas linhas.
Como a elaboração do mapa necessita de várias técnicas de geoprocessamento, esses
dados foram adquiridos por terceiros e posteriormente inseridos no banco (os procedimentos
foram descrito no capitulo 8).
Para simular os dados chegando por um sistema embarcado contendo gps e um
comunicador de dados qualquer foi usado um agente que capturada dados reais e joga no
banco de dados espacial como pontos espaciais propriamente dito. Poderiam ser gerados esses
pontos a partir dos dados de longitude e latitude em uma tabela relacional convencional e
convertido a dados espaciais posteriormente, contudo o objetivo era mostrar como trabalhar
com o banco de uma forma já conhecida, ou seja, são apenas novos comandos, com novas
funções.
Com o banco de dados espacial (no caso o oracle) que tem uma arquitetura dual, os
profissionais de banco de dados não precisam ter um grande conhecimento cartográfico para
conseguir modelar o banco, necessita apenas de conceitos para saber o que seria um dado
121
espacial, podendo facilmente integrar o modelo relacional ao atributo objeto espacial.
Existem vários formatos de mapas digitais, dfx, dgn, mid, mif, info, entre outras, contudo
em banco de dados geográfico observou-se uma tendência a padronização, onde só existem
ferramentas para inserir no banco se o formato do mapa estiver no padrão shipefile. Isso foi
claramente observado no Oracle Spacial, todavia o PostoGis a acontece a mesma coisa.
A espacialização dos dados facilita a extração de informações e o processo de tomada de
decisão.
Um exemplo disso seria encontrar a melhor rota. Se tivéssemos somente a camada de
ruas teríamos uma falsa rota, agora se tivermos as camadas de ruas pavimentadas, ruas sem
pavimento e o sentido de cada uma poderíamos traçar uma rota real, levando em conta o
sentido de cada uma. Ainda seria possível colocar mais uma camada de parada para
descarregar ou carregar (clientes no caso), obrigando o sistema fazer uma outra rota.
Com isso fica claro que a espacialização ajuda a visualização do problema, pois na
medida em que os dados vão sendo inseridos a visualização fica mais clara. Um caso seria
assalto a caminhões em um trecho. Poderia marcar esse trecho como evitar a passar e caso
seja obrigatório o usuário pode tomar algumas providências a título de prevenção.
Outro bom exemplo seria estatísticas de violência, índice de saúde, loteamento e
urbanização, entre outras.
Para continuação do projeto poderia ser implementado com o banco de dados PosGis,
tornando totalmente opensorce.
O rastro poderia ser usado com Sistema de Referencias Lineares, onde no lugar de fazer o
rastro com o posicionamento de pontos, usaria o LRS para criar segmentos de retas
melhorando o visual e corrigindo possíveis erros do GPS. Dessa forma impossibilita a má
impressão de falhas na rota, como o ponto esta longe da rua.
122
10 ANEXO
A instalação foi feita na distribuição Fedora Core 1 do Linux. Será descrito todos os
passos da instalação do banco de dados e da ferramenta de visualização.
10.1 ORACLE SPATIAL
A versão do oracle foi o 10g (10.1.0.2) encontrado no endereço
http://otn.oracle.com/software/products/database/oracle10g/index.html.
Ao baixar o arquivo ship.db.cpio.gz, descompacte (gunzip ship.db.cpio.gz) e em
seguida desagrupe (cpio -idmv < ship.db.cpio).
No arquivo /etc/hosts deve conter um nome identificando o servidor.
No arquivo /etc/sysctl acrescente os seguintes comandos:
• kernel.shmall = 2097152
• kernel.shmmax = 2147483648
• kernel.shmmni = 4096
• # semaphores: semmsl, semmns, semopm, semmni
• kernel.sem = 250 32000 100 128
• fs.file-max = 65536
• net.ipv4.ip_local_port_range = 1024 65000
Execute /sbin/sysctl –p
No arquivo /etc/security/limits.conf acrescete:
• * soft nproc 2047
• * hard nproc 16384
• * soft nofile 1024
• * hard nofile 65536
No arquivo /etc/pam.d/login acrescente:
• session required /lib/security/pam_limits.so
Depois de completo os passos descrito acima instalar os seguintes pacotes:
# From Fedora Core 1 Disk 1
cd /mnt/cdrom/Fedora/RPMS
setarch-1.0-1.i386.rpm
123
# From Fedora Core 1 Disk 2
cd /mnt/cdrom/Fedora/RPMS
openmotif-2.2.2-16.1.i386.rpm
# From Fedora Core 1 Disk 3
cd /mnt/cdrom/Fedora/RPMS
compat-libstdc++-7.3-2.96.118.i386.rpm
compat-libstdc++-devel-7.3-2.96.118.i386.rpm
compat-db-4.0.14-2.i386.rpm
compat-gcc-7.3-2.96.118.i386.rpm
compat-gcc-c++-7.3-2.96.118.i386.rpm
Criar grupo e usuário:
groupadd oinstall
groupadd dba
groupadd oper
useradd -g oinstall -G dba oracle
passwd oracle
Crie o diretório:
mkdir -p /u01/app/oracle/product/10.1.0/db_1
chown -R oracle.oinstall /u01
No arquivo .bash_profile acrescente as seguintes linhas de comandos:
# Oracle Settings
TMP=/tmp; export TMP
TMPDIR=$TMP; export TMPDIR
ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1; export
ORACLE_HOME
ORACLE_SID=TSH1; export ORACLE_SID
ORACLE_TERM=xterm; export ORACLE_TERM
PATH=/usr/sbin:$PATH; export PATH
124
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export
LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_
HOME/rdbms/jlib; export CLASSPATH
#LD_ASSUME_KERNEL=2.4.1; export LD_ASSUME_KERNEL
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Edite o arquivo /etc/redhat-release para redhat-3.
Depois desses passos completos entrar no diretório Disk1 e digitar ./runInstaller. Siga
as instruções da caixa de diálogo. Após a instalação executar as seguintes tarefas:
• Editar /etc/redhat-release e voltar para Fedora Core release 1 (Yarrow)
• Editar /etc/oratab e colocar TSH1:/u01/app/oracle/product/10.1.0:Y
10.2 MAPSERVER
• Apache - 2.0.48
Devem estar instalado --> glibc-devel glibc-devel-static
Editar o arquivo config.layout acrescentar o texto abaixo:
<Layout optweb>
prefix: /opt/apache
exec_prefix: ${prefix}
bindir: ${exec_prefix}/bin
sbindir: ${exec_prefix}/sbin
125
libdir: ${exec_prefix}/lib
libexecdir: ${exec_prefix}/libexec
mandir: ${prefix}/man
sysconfdir: /etc${prefix}
datadir: /home/apache
installbuilddir: ${datadir}/build
errordir: ${datadir}/error
iconsdir: ${datadir}/icons
htdocsdir: ${datadir}/htdocs
manualdir: ${datadir}/manual
cgidir: ${datadir}/cgi-bin
includedir: ${prefix}/include
localstatedir: /var/apache
runtimedir: ${localstatedir}/run
logfiledir: ${localstatedir}/logs
proxycachedir: ${localstatedir}/proxy
</Layout>
• Configurar com freetds
./configure --enable-module=so --enable-layout=optweb --with-mpm=worker --enable-mods-
shared="access actions alias asis auth auth_anon auth_dbm auth_digest autoindex cern_meta
cgi deflate dir env expires ext_filter headers imap include info log_config mime mime_magic
negotiation proxy proxy_connect proxy_ftp proxy_http rewrite setenvif speling ssl status
suexec unique_id userdir usertrack vhost_alias"
• Configurar sem o freetds
./configure --enable-layout=optweb --with-mpm=worker --enable-mods-shared="access
actions alias asis auth auth_anon auth_dbm auth_digest autoindex cern_meta cgi deflate dir
env expires ext_filter headers imap include info log_config mime mime_magic negotiation
proxy proxy_connect proxy_ftp proxy_http rewrite setenvif speling ssl status suexec
unique_id userdir usertrack vhost_alias"
• Freetds - 0.62
126
tar -xzvf freetds-0.62.tgz
cd freetds-0.62/
./configure --prefix=/usr/local/freetds --with-tdsver=7.0
make && make install
• Bison - 1.875
./configure --prefix=/usr
make
make install
• Geos - 1.0
./configure --prefix=/usr
make
make install
• GD - 2.0.22
Instalar os pacotes "-devel" das biblitecas gráficas, freetype2, libjpeg, libpng e xpm ( presente
no XFree86-devel )
Apage libgd.so.1 de /usr/lib/libgd.so.1
./configure --prefix=/usr
make
make install
faça um link de nome libgd.so.1 para a libgd.so.2
ln -s /usr/lib/libgd.so.2 /usr/lib/libgd.so.1
• Tiff - 3.6.1
Apage libtiff* de /usr/lib
./configure --prefix=/usr
make
127
make install
• PROJ - 4.4.7
./configure --prefix=/usr
make
make install
• LIB geotiff - 1.2.1
Tome o devido cuidado de ter instalado proj antes se quiser esse suporte, de pref, soga a
ordem colocada aqui
./configure --prefix=/usr
make
make install
• LIB Grass - 1.0.0
./configure --prefix=/usr
make
make install
• GDAL - 1.1.9
./configure --prefix=/usr --with-grass=/usr/include
make
make install
• CURL - 7.11.0
Apagar libcurl.so.2* de /usr/lib
./configure --prefix=/usr
make
128
make install
• PDF LITE - 5.0.3
./configure --prefix=/usr
make
make install
• PHP 4.3.9 CGI para Mapserver
• Com oracle
./configure --enable-shared --with-regex=system --with-jpeg-dir=/usr/lib --with-png-
dir=/usr/lib --with-zlib --with-gd --with-freetype-dir=/usr/lib --enable-force-cgi-redirect --
enable-dbase --with-pdflib --with-mysql --with-config-file-path=/etc/mphp/ --
prefix=/home/mphp --with-readline --with-openssl-dir=/usr/lib --exec-prefix=/opt/mphp --
with-oci8--enable-sigchild --with-xpm-dir=/usr/lib/X11/ --with-tiff-dir=/usr/lib --with-curl --
with-thread-safety
• com oracle e mssql
./configure --enable-shared --with-regex=system --with-jpeg-dir=/usr/lib --with-png-
dir=/usr/lib --with-zlib --with-gd --with-freetype-dir=/usr/lib --enable-force-cgi-redirect --
enable-dbase --with-pdflib --with-mysql --with-config-file-path=/etc/mphp/ --
prefix=/home/mphp --with-readline --with-openssl-dir=/usr/lib --exec-prefix=/opt/mphp --
with-oci8--enable-sigchild --with-xpm-dir=/usr/lib/X11/ --with-tiff-dir=/usr/lib --with-curl --
with-thread-safety --with-sybase=/usr/local/freetds --enable-track-vars
• MapServer 4.0.1
./configure --exec-prefix=/opt/mapserver --prefix=/home/mapserver --with-jpeg --with-zlib --
with-freetype --with-png --with-xpm --with-libiconv --with-gd --with-pdf --with-tiff --with-
eppl --with-proj --with-threads --with-ogr --with-gdal --with-postgis --with-wfs --with-
wmsclient --with-wfsclient --with-curl-config=/usr/bin/curl-config --with-
php=/home/oracle/Intalacao/tar-gz/php-4.3.9/ --with-httpd=/opt/apache/sbin/httpd --with-
oraclespatial
make
129
Copiar php_mapscript.so da pasta mapscript/php3 do mapserver para a pasta de extensões do
php
cp mapscript/php3/php_mapscript.so /opt/mphp/lib/php/extensions/
Copiar o executável mapserv que está na raiz da pasta de compilação do mapserver, para o
diretório cgi-bin do php.
130
11 REFERENCIA
[ARO 89] ARONOF, S. Geographic Information Systems: a management
perspective. Canada: WDL Publications, 1989.
[CCM 93] OLIVEIRA, Cêurio de. Curso de cartografia modena /Cêurio de Oliveira. – 2.
ed. –Rio de Janeiro: IBGE, 1993.
[CÂM 94] CÂMARA, Gilberto. Análise de Arquiteturas para Bancos de Dados
Geográficos Orientados-a-Objetos. São Jóse dos Campos, SP : Instituto
Nacional de Pesquisas Espaciais, abr. 1994. Tese de Doutorado.
[DEETZ] DEETZ, Charles H., ADAMS, Oscar S. Elements of map projection.
[EST 04] ESTEIO ENGENHARIA E AEROLEVANTAMENTOS S.A.. Disponível
em:<http://www.esteio.com.br/newsletters/paginas/006/orientacao.htm>
Acesso em: Setembro. 2004.
[GOO 91] GOODCHILD, Michael F. Integrating GIS and Environmental Modeling at
Global Scales. In GIS/LIS, 1991, Atlanta. Proceedings... Atlanta, Georgia :
[s.n.], 1991. v.1.
[GOO 90] GOODCHILD, Michael F. ; KEMP, Karen K. (Eds.) NCGIA Core
Curriculum : Issues in GIS. Santa Barbara, CA : National Center for
Geographic Information and Analysis (NCGIA), University of Califórnia, July
1990.
[LAU 92] LAURINI, Robert; THOMPSON, Derek. Fundamentais of Spatial
Information Systems. San Diego: Academic Press, 1992.
[NCG 90] NATIONAL CENTER FOR GEOGRAPHIC INFORMATION AND
ANALYSIS, NCGIA Core Curriculum. Edited by Michael F. Goodchild and
Karen K Kemp (Eds.), Santa Barbara: University of California, 1990.
[ORA 01] ORACLE COORPORATION. Oracle spatial user’s guide and reference:
release 9.2, June 2001. Part. No. A88805-01. Disponível em:
<http://www.oracle.com>. Acesso em: Abril. 2004.
[ORA 04] ORACLE COORPORATION. Oracle spatial discussion forum. Disponível
em: <http://otn.oracle.com/forums/database.html (Spatial)> Acesso em: Jun.
2004.
131
[ODL 04] Oracle DataBse Document Library. Disponível em
<http://www.oracle.com/pls/db10g/portal.portal_demo3?selected=3> Acessado
em: Nov 2004
[IOF 04] Oracle Database 10g (10.1.0.2) Installation On Fedora Core 1. Disponivel em <
www.oracle-base.com/articles/10g/OracleDB10gInstallationOnFedora1.php>
Acessado em: Nov 2004
[OST 04] ORACLE COORPORATION. Oracle spatial training guide: release 9.2, Jan.
2004. Disponível em <http://www.oracle.com>. Acesso em: Nov. 2004.
[PAR 94] PAREDES, E. A. Sistema de Informação Geográfica - Princípios e
Aplicações: Geoprocessamento, São Paulo: Ed. Érica, 1994.
[PEU 84] PEUQUET, Donna J. A conceptual framework and comparison of spatial data
models. Cartographica, [S.I.], v.21, n.4, p. 66-113, 1984.
[RAM 94] RAMIREZ, Milton Ramos. Sistemas Gerenciadores de Banco de Dados para
Geoprocessamento. Rio de Janeiro, RJ : COPPE/UFRJ, abr. 1994. Dissertação
de Mestrado.
[SOU 93] SOUZA, Jano Moreira de ; RAMIREZ, Milton ; FERRARI, Roberto et ai.
Uma Arquitetura Organizacional para Sistemas de Informação Geográfica
Orientados a Objetos. In: SIMPÓSIO BRASILEIRO DE
GEOPROCESSAMENTO, 2., [S.l.]. Anais... [S.I.], 1993.
[SHAR 01] SHARMA, J. Oracle Spatial: an Oracle technical white paper. May 2001.
Disponível em: <http://www.oracle.com>. Acesso em Jun. 2004.