INSTITUTO MILITAR DE ENGENHARIA - cartografia.ime.eb.br · Geração de um Modelo Altimétrico...
50
1
Transcript of INSTITUTO MILITAR DE ENGENHARIA - cartografia.ime.eb.br · Geração de um Modelo Altimétrico...
1
INSTITUTO MILITAR DE ENGENHARIA
Asp Of R2 LUIGI CASTRO CARDELES
Al MAURÍCIO CARVALHO MATHIAS DE PAULO
Geração de um Modelo Altimétrico Global
Projeto de fim de curso apresentado ao Curso de Graduação em Engenharia Cartográfica
no Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de
Graduado em Engenharia Cartográfica.
Orientador: Prof. Luiz Felipe Coutinho Ferreira da Silva - D.E.
Orientador: Prof. Flávio Luís de Mello - D. Sc.
Aprovada em __ de _______ de 2007 pela seguinte Banca Examinadora:
___________________________________________________________________________
Prof. Luiz Felipe Coutinho Ferreira da Silva - D.E.
___________________________________________________________________________
Cap Marcos de Meneses Rocha - M.C.
___________________________________________________________________________
1º Ten Ivanildo Barbosa – M.C.
___________________________________________________________________________
Prof. Walter da Silva Prado – M.C.
Rio de Janeiro
2007
2
SUMÁRIO
RESUMO...................................................................................................................................7
ABSTRACT...............................................................................................................................8
1 INTRODUÇÃO.....................................................................................................................9
1.1 Motivação.............................................................................................................................9
1.2 Objetivo................................................................................................................................9
2 INTRODUÇÃO TEÓRICA...............................................................................................10
2.1 Representações da Superfície da Terra..............................................................................10
2.2 Modelo Digital de Terreno.................................................................................................10
2.3 Reamostragem....................................................................................................................12
2.4 SRTM.................................................................................................................................15
2.5 GEBCO .............................................................................................................................17
2.6 Visualização de MDT.........................................................................................................18
3 METODOLOGIA...............................................................................................................20
3.1 Material utilizado...............................................................................................................20
3.2 Origem dos dados...............................................................................................................23
3.2.1 Arquivos da SRTM .........................................................................................................23
3.2.2 Arquivo do GEBCO........................................................................................................24
3.3 Preparação do Sistema.......................................................................................................25
3.3.1 Abordagem Escolhida.....................................................................................................25
3.3.2 Preparação dos arquivos SRTM para geração de MDT..................................................26
3.3.3 Preparação do arquivo GEBCO para geração de MDT..................................................28
3.3.4 Dependências..................................................................................................................28
3.4 Implementação...................................................................................................................29
3.4.1 Estratégia.........................................................................................................................29
3.4.2 Classe “cbn3”..................................................................................................................31
3.4.3 Classe “cgeodb”..............................................................................................................32
3.4.4 Classe “czip”...................................................................................................................33
3.4.5 Classes “ewsm_call”, “ewsm_gui” e “pvtgl”.................................................................33
3.4.6 Classe “cterrainsample”..................................................................................................35
3.4.6.1 O método “getRegionTiles()”......................................................................................36
3.4.6.2 O método “ressampleTile”..........................................................................................37
3
3.4.6.3 O método “createhdrfile()”..........................................................................................37
3.4.6.4 O método “ressampleSea()”.........................................................................................37
3.4.6.5 O método “ressampleArea()”.......................................................................................37
4 RESULTADOS....................................................................................................................40
4.1 Desenvolvendo um MDT em escalas de cinza com EWSM e OpenJump Pirol...............40
4.2 Desenvolvendo um modelo 3D em escalas de cinza com EWSM e OpenJump Pirol.......42
4.3 Análise dos resultados........................................................................................................44
5 CONCLUSÃO.....................................................................................................................46
BIBLIOGRAFIA.....................................................................................................................48
REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................48
ANEXO I – EXTENSÕES DOS ARQUIVOS UTILIZADOS............................................50
ANEXO II – CONTEÚDO DO CD-ROM EM ANEXO......................................................51
4
LISTA DE ILUSTRAÇÕESFIG. 2.1 Grade inicial com alguns valores ..............................................................................13
FIG. 2.2 Máscara 2x2...............................................................................................................14
FIG. 2.3 Interferometria por Radar (Adaptado de NASA's JET PROPULSION LAB, 2006). 15
FIG. 2.4 Cobertura da SRTM (quantidade de passagens nas regiões) (NASA's JET
PROPULSION LAB, 2006)......................................................................................................16
FIG. 2.5 Visualização por projeção perspectiva (CÂMARA, 2006)........................................18
FIG. 2.6 Imagem SRTM visualizada do QGIS.........................................................................19
FIG. 3.1 Atividades executadas pelo aplicativo........................................................................25
FIG. 3.2 Corte do índice da cobertura das imagens SRTM......................................................27
FIG. 3.3 Visualização do GEBCO no QGIS ............................................................................29
FIG. 3.4 Modelo de Classes simplificado do aplicativo EWSM..............................................30
FIG. 3.5 Arquivo “.bn3” aberto no editor de textos Kate ........................................................32
FIG. 3.6 Interface gráfica do programa EWSM........................................................................34
FIG. 3.7 Interface gráfica gerada pela classe "pvtgl"...............................................................35
FIG. 3.8 Funcionamento da classe "cterrainsample"................................................................36
FIG. 3.9 Diferenças entre a tabela “coastline” a “worldpolitical”............................................39
FIG. 4.1 Visualização do Rio de Janeiro no OpenJump...........................................................40
FIG. 4.2 Conectando ao banco de dados no OpenJump...........................................................41
FIG. 4.3 Escolha da escala de cinza..........................................................................................41
FIG. 4.4 Visualização 3D do Rio de Janeiro no OpenJump......................................................42
FIG. 4.5 Camadas geradas........................................................................................................43
FIG. 4.6 Gerando o modelo 3D no OpenJump Pirol.................................................................44
FIG. 4.7 América do Sul no QGis.............................................................................................45
5
LISTA DE TABELASTAB. 3.1 Gdal (Geospatial Data Abstraction Library) 1.3.1 ..................................................20
TAB. 3.2 OpenJump 1.2.0 Pirol................................................................................................20
TAB. 3.3 KDevelop 3.3.............................................................................................................21
TAB. 3.4 PostgreSQL 8.1..........................................................................................................21
TAB. 3.5 PostGIS 1.1................................................................................................................21
TAB. 3.6 Qgis (Quantum GIS) 0.8...........................................................................................21
TAB. 3.7 libzipios++ ................................................................................................................22
TAB. 3.8 Python 2.5..................................................................................................................22
TAB. 3.9 Umbrello 3.5..............................................................................................................22
TAB. 3.10 OpenOffice.org 2.2..................................................................................................22
TAB. 3.11 Kubuntu 7.05...........................................................................................................22
TAB. 3.12 Boost C++ Library..................................................................................................23
TAB. 3.13 Qt 3..........................................................................................................................23
TAB. 3.14 Teste de porcentagem de compactação....................................................................27
TAB. 3.15 Objetos do arquivo “bn3”........................................................................................31
6
RESUMO
Durante o início deste milênio a NASA (National Aeronautics and Space
Administration - EUA) trabalhou numa missão para mapear a superfície física da Terra. Esta
missão foi chamada de SRTM (Shuttle Radar Topography Mission) e alguns de seus
resultados ainda estão em processamento. Durante várias décadas, a IHO (International
Hidrographic Organization) juntou esforços dos órgãos de cartografia náutica dos países de
todo o mundo definindo padrões para cartas náuticas. Como resultado do processamento
destas informações foi criado o GEBCO (General Bathymetric Chart of the Oceans) que
engloba informações de batimetria do mundo todo. Apesar de possuírem objetivos diferentes,
estas duas iniciativas geraram modelos digitais de terrenos em grades regulares da altimetria
do planeta e ambas estão disponíveis para o público gratuitamente. Desta forma, este projeto
visa unir estas duas fontes de dados num único sistema que possa visualizá-las em um modelo
tridimensional. Para atingir esta meta primeiramente foram definidas técnicas de obtenção e
armazenamento dos dados. Depois foi desenvolvido um aplicativo para efetuar o processo de
escolha da região geográfica selecionada pelo usuário e retornar os pontos que a representam.
Este aplicativo começa identificando quais modelos (do GEBCO para a parte submersa e
SRTM para a parte terrestre) deverão ser utilizados para representar aquela região. Em seguida
define uma grade regular para cada corte da SRTM e recupera as alturas desses pontos. Da
mesma forma, uma grade regular é definida para a região de estudo e são extraídos os pontos
do GEBCO. Todos os pontos da SRTM com altura zero ou menor são removidos. Todos os
pontos do GEBCO com altura maior que zero são removidos. Foram testadas outras
abordagens para definir como mesclar os dados dos dois modelos e esta solução foi a que
apresentou menor tempo de processamento (até 5 segundos para uma região de 5x5 graus). Os
pontos são armazenados no formato “.bn3” e em duas tabelas no banco de dados geográfico
com PostgreSQl/Postgis. Dessa forma possibilita-se a visualização da região por diversos
aplicativos no mercado (por exemplo, OpenJump Pirol e Quantum GIS) assim como na
Plataforma de Visualização de Teatros de Guerra, desenvolvida pela parceria CTEx (Centro
Tecnológico do Exército) e IME (Instituto Militar de Engenharia).
7
ABSTRACT
By the beginning of this millennium the NASA (National Aeronautics and Space
Administration - EUA) worked on a mission to map the physical surface of the Earth. This
mission was called SRTM (Shuttle Radar Topography Mission) and some of its results are
still being processed.Along many decades the IHO (International Hydrographic Organization)
organized efforts of many nautical cartography organizations of the whole world defining
patterns for nautical charts. As a result of the processing of these informations the GEBCO
(General Bathymetric Chart of the Oceans) was born, containing information of the whole
world. Despite of having different purposes, these two efforts created digital terrain models
stored in regular grids of the earth surface of the planet and both are freely available to the
public. This project aims to bring together these two sources of information in a single system
that is able to visualize them in a tridimensional model. To reach this goal first techniques of
obtaining and storing the data were defined. Then a program was developed to do the process
of choosing the geographical region defined by the user and returning the points that represent
it. This program starts finding out what models (from GEBCO for the underwater and SRTM
for the land) should be used to represent the region. Then it defines a regular grid for each
SRTM tile and gets the height of each vertex. Again, a regular grid is defined for the region of
interest and those vertexes are extracted from the GEBCO. Every point from the SRTM with
height zero or less are removed. Every point from the GEBCO with height higher than zero is
removed. Other approaches were tested to solve the problem of joining the data in the two
models and this solution was the one with least time spent (up to 5 seconds for a region of 5x5
degrees). The points are stored in the “.bn3” file format and also in two tables in a geographic
database with PostgreSQL/Postgis. This way it is possible to visualize the region on many
programs available (for example, OpenJump Pirol and Quantum GIS) and also in the
Plataforma de Visualização de Teatros de Guerra, developed by the partnership CTEx
(Centro Tecnológico do Exército) and IME (Instituto Militar de Engenharia)
8
1 INTRODUÇÃO
1.1 Motivação
Um problema muito comum no mapeamento é o acesso à algumas regiões. Território
inimigo, regiões não habitadas e regiões que passam parte do ano alagadas são exemplos de
regiões difíceis de mapear. Utilizando os dados de um modelo que possua a porção terrestre e
a marítima pode-se produzir a altimetria para documentos cartográficos que supram
necessidades críticas nestas regiões, ressalvados os níveis de qualidade dos dois modelos.
A integração desses dados permite análises integradas facilitando o planejamento de
serviços de transporte (marítimo, terrestre e aéreo), logística, geomarketing, exploração off-
shore de recursos naturais etc.
A Plataforma de Visualização de Teatros de Guerra (no escopo deste trabalho também
será referida como “Plataforma de visualização”) é um projeto desenvolvido em uma parceria
entre CTEx e IME. Seu princípio básico é trabalhar utilizando um modelo digital de terreno
triangulado de uma determinada região. A entrada dos dados é feita em “.bn3”, que é um
formato baseado em texto raramente utilizado no mercado atual. É desejável que uma
quantidade maior de modelos de terreno esteja adaptada ao formato para auxiliar em testes e
dar mais potência ao projeto.
1.2 Objetivo
Desenvolver um procedimento para integração de dados oriundos da missão SRTM
(Shuttle Radar Topography Mission) e do projeto GEBCO (General Bathymetric Chart of the
Oceans) visando a integração em um único Modelo Digital de Terreno e a integração dos
dados oriundos da SRTM (radar) e da GEBCO (batimetria).
9
2 INTRODUÇÃO TEÓRICA
2.1 Representações da Superfície da Terra
Modos de se representar o terreno são utilizados desde a antiguidade: homens da
caverna riscavam as primeiras representações do mundo à sua volta em pedra lascada na
parede de suas cavernas-moradias. Na tentativa de representar a realidade, evoluções
ocorreram ao longo dos séculos até os dias atuais: informações geográficas disponibilizadas
livremente pela Internet ou em meio eletrônico, uso intensivo do computador na obtenção,
preparação, exibição desses dados de modo a atender aos mais variados gostos e utilidades (
Google Earth®, Google Maps®, NASA World Wind etc.) além de bases de dados geográficos
como as disponibilizadas livremente pelo IBGE, INPE (imagens CBERS), imagens SRTM
(imagens com informação altimétrica com cobertura quase global) e GEBCO (batimetria dos
oceanos do mundo todo). Cada um dos serviços busca atender uma demanda específica e para
isso são projetados com detalhes específicos tais como precisão, visualização e demais
características desses produtos.
Foi a partir da necessidade de representar a realidade (principalmente a superfície da
Terra) que surgiu um método de modelagem cujo principal objetivo era auxiliar no
planejamento e na construção de auto-estradas utilizando técnicas de fotogrametria e com
intensivo uso de computadores onde foram armazenados e criados perfis digitais.(LI,2005) A
denominação dada a esse método foi: Modelagem Digital de Terreno (MDT).
2.2 Modelo Digital de Terreno
"Um modelo é um objeto ou um conceito por meio do qual representa-se algo. Ele
representa a realidade em alguma escala e é concebido de um modo que possamos entender"
(MEYER, 1985 apud LI,2005).
No caso de um MDT, o objeto que ser quer modelar é a superfície ou em alguns casos o
subsolo de um trecho ou de toda a Terra. Pode-se interpretar o "modo que possamos entender"
como sendo uma série de abstrações que são utilizadas de modo a facilitar a modelagem e
conseqüentemente a compreensão da realidade. Por exemplo, uma estrada em determinada
aplicação pode ser somente uma linha, coincidente com seu eixo, enquanto que em outras a
mesma estrada podem ser duas linhas paralelas que demarcam os meios-fios.
10
Um modelo matemático é uma representação abstrata de algum fenômeno através de
parâmetros e equações matemáticas com o objetivo de descrever o seu funcionamento ou as
suas características. No caso do MDT, a equação matemática que o representa, geralmente, é:
Z= f X ,Y (EQ.2.1)
Geralmente essa é uma função bijetora, ou seja, para cada par de valores X, Y existe um e
somente um valor de Z. Os parâmetros dessa equação são:
● X,Y: coordenadas de um ponto;
● Z: valor do fenômeno espacial desejado na modelagem, geralmente, é a altura ou a
altitude de um ponto.
Essa modelagem foi utilizada pela primeira vez por Charles Miller em um projeto de
auto-estradas nos EUA, em 1957. Essa metodologia surgiu da necessidade de se automatizar o
projeto, tendo sido realizado através da medição das coordenadas dos pontos em pares
estereoscópicos ao longo da futura rodovia. Foi desse trabalho que surgiu a denominação
dessa técnica: Modelagem Digital de Terreno, que é assim definida:
O modelo Digital de Terreno (MDT) é simplesmente uma representação estatística
de uma superfície contínua do solo construída com uma grande quantidade de
pontos selecionados com coordenadas X, Y e Z conhecidas em um sistema de
coordenadas arbitrário. (MILLER apud LI,2005,p.7)
A partir dessa primeira definição surgiram várias outras dependendo do que representa a
coordenada Z:
● somente a superfície do solo, desconsiderando benfeitorias;
● superfície do solo considerando as benfeitorias;
● tendo a copa das árvores como referência;
● entre outros.
Outras classificações diferenciam a modelagem matemática da visualização,
chamando de MNT - Modelagem Numérica do Terreno quando trata-se somente da
modelagem. Existem definições para todos os gostos mas no presente trabalho foi utilizada a
definição de Charles Miller (MILLER apud LI,2005,p.7) e observando que ela engloba todo o
produto: modelagem matemática e visualização.
11
Para a geração de um MDT algumas etapas devem ser seguidas tais como:
● amostragem de pontos do terreno;
● pontos amostrados de modo a serem representativos da geometria do local;
● criação da malha (regular ou irregular, triangular ou não);
● precisão do modelo gerado;
● representatividade do modelo gerado;
● visualização do modelo (essa etapa é opcional).
Aspectos das etapas acima são:
● na grande maioria dos casos, uma rede triangular possui todos os seus vértices sendo
pontos amostrados diretamente no terreno, ou seja, os vértices só possuem o erro
devido ao processo de obtenção das coordenadas em campo, não há erro adicional;
● as grades regulares costumam possuir os seus nós como pontos interpolados a partir de
uma amostragem de pontos medidos no terreno, ou seja, os nós da grade possuem,
além do erro inerente à medição no campo, os erros decorrentes da interpolação, erro
esse que varia em função do método de interpolação utilizado.
Um MDT possui uma série de vantagens sobre modos analógicos de armazenagem dos
dados:
● precisão garantida pelo modelo matemático;
● diferentes modos de visualização: como carta topográfica, modelo tridimensional,
seções verticais e transversais, etc.;
● a qualidade do dado não se deteriora com o passar do tempo como acontece, por
exemplo, com as cartas em papel que sofrem efeitos de fungos e bactérias. (apesar de
que possa ocorrer uma eventual desatualização);
● possibilidade de atualização dos dados de modo mais simples (basta adicionar a nova
coordenada medida em campo);
● escalas de representação variadas (sendo a única limitação a precisão dos dados
coletados em campo).
2.3 Reamostragem
Os dados são coletados em campo através de equipamentos e técnicas específicas
12
dependendo da escala em que se deseja trabalhar com o MDT. Quando se quer passar para
uma escala muito menor do que a originalmente planejada é interessante realizar uma
reamostragem dos dados de modo a reduzir o custo computacional. Especialmente no caso
das imagens SRTM é necessária uma técnica de reamostragem para não sobrecarregar o
equipamento com uma massa de dados muito maior do que a capacidade do computador
utilizado (descrito no item 3.1). Para o presente trabalho foram vistos os métodos de
reamostragem do ponto mais alto, da média e da segunda derivada.
O método do ponto mais alto consiste em, determinada uma máscara (uma quantidade
de referência) de polígonos da grade, eles são transformados em um único polígono da grade
cujo valor de Z será o maior dos polígonos pertencentes à máscara. O procedimento pode ser
visto na seqüência de figuras abaixo:
FIG. 2.1 Grade inicial com alguns valores
13
FIG. 2.2 Máscara 2x2
.
Em relação ao método da segunda derivada, ele é mencionado somente como um
parâmetro para a escolha de pontos com certa relevância na geometria do terreno. Não foi
encontrada nenhuma utilização dele, aparecendo neste trabalho mais como opção e inspiração
para futuras implementações. Ele é utilizado junto com os outros métodos e serve para
graduar as quadrículas e escolher a que mais peso possui na representação do terreno.
Considera-se f X i=H é utilizada a seguinte equação:
f ' ' X i=2∗[ f X i−1−f X i−1 f X i1
2] (LI,2005)(EQ.2.2)
, onde f ' ' X i é a segunda derivada, X i é o ponto que se deseja calcular e
X i−1 e X i1 são os pontos adjacentes. Essa distância pode ser qualquer, no exemplo ela
será de uma quadrícula, ou seja, cada duas quadrículas serão unidas em uma única. Para a
primeira linha horizontal do exemplo será:
f ' ' X i=2∗[10−
10202
]=−10
Para a segunda linha horizontal será:
14
f ' ' X i=2∗[30−3040
2]=−10
Vemos assim que ambos possuem mesmo grau de significância e são pontos
igualmente importantes para caracterizar o terreno pois f ' ' X i da primeira linha é igual a
f ' 'X i da segunda linha.
2.4 SRTM
“O objetivo da Shutte Radar Topography Mission é obter por radar dados de elevação em
uma escala quase global e gerar o mais completo banco de dados topográficos de alta
resolução da Terra. Os dados de radar da SRTM tem várias aplicações.” (Traduzido de
NASA's JET PROPULSION LAB, 2006)
Conforme anunciado pelo Laboratório de Propulsão de Jatos da NASA, o objetivo da
SRTM é produzir um banco de dados da topografia da Terra buscando as melhores cobertura e
resolução. Para obter esses dados foi utilizada uma nave espacial equipada com um sistema de
radar. Em fevereiro de 2000 o equipamento ficou em órbita por 11 dias obtendo informações
através da técnica de interferometria por radar. Essa técnica consiste em obter duas imagens
da mesma região utilizando dois sensores em posições diferentes. A variação nessas imagens
permite calcular a elevação da superfície. Para obter as duas imagens a SRTM carregou um
sensor no compartimento de carga e o outro em um mastro de 60 metros de comprimento ao
lado da nave. (NASA's JET PROPULSION LAB, 2006) A FIG. 2.3 exibe o esquema de
funcionamento da interferometria por radar.
FIG. 2.3 Interferometria por Radar (Adaptado de
NASA's JET PROPULSION LAB, 2006)
15
A SRTM foi lançada em órbita com uma inclinação de 57 graus. Isso permitiu que os
radares cobrissem grande parte da superfície da Terra entre os paralelos 60 graus Norte e 56
graus Sul. Isso equivale a, aproximadamente, 80% da massa do planeta. (NASA's JET
PROPULSION LAB, 2006) A FIG. 2.4 exibe a quantidade de vezes que cada região foi
imageada durante a missão.
FIG. 2.4 Cobertura da SRTM (quantidade de passagens nas regiões) (NASA's JET
PROPULSION LAB, 2006)
As imagens geradas pela SRTM possuem dois níveis de resolução geométrica. Cada
grupo de imagens foi gerada utilizando técnicas diferentes. A missão carregou sensores de
radar das bandas X e C. Os sensores da banda C possuíam objetivo de imagear rapidamente
grandes áreas (255km de largura), enquanto os da banda X tinham foco em obter a melhor
resolução geométrica possível na época (imageando 50 km de largura). Foram utilizados dois
feixes em cada antena responsável por imagear a banda C. Utilizando duas antenas
conectadas ao GPS (Global Positioning System) o sistema se posicionava em relação à Terra.
(NASA's JET PROPULSION LAB, 2006) Utilizando as informações das imagens da banda
C, da banda X e do posicionamento de bordo o Laboratório de Propulsão de Jatos da NASA
gerou as imagens chamadas de “unfinished” (inacabadas). Posteriormente a National
Geospatial-Intelligence Agency (NGA, antiga National Imagery and Mapping Agency)
16
processou os dados e gerou a chamada “finished” SRTM data. (USGS, EROS, Data Services
Branch, 2004)
O erro desse mapeamento está documentado no sítio da NASA e cabe ressaltar que o erro
máximo absoluto é de 15 m. O tamanho de cada recorte dos arquivos é de 1x1 grau e cada
pixel representa uma região de 3x3 segundos. Os dados estão armazenados em coordenadas
geodésicas utilizando WGS 84.
Existem várias versões dos dados oriundos da SRTM. Cada um se diferencia pelo pós-
processamento feito. Neste trabalho foi utilizada a versão obtida em
“ftp://e0srp01u.ecs.nasa.gov”. Essa versão disponível no sítio da NASA possuiu alguns erros
decorrentes do não mapeamento de trechos da superfície terrestre, trechos onde não se tem
nenhuma informação disponível. Essas regiões são conhecidas como NODATA.
Além das versões do mapeamento disponíveis para download, existem outras duas:
● uma versão que preencheu o NODATA com métodos originários do Arcview® (versão
chamada de CGIAR-CSI-SRTM);
● uma versão “hidrologicamente” correta (na palavra dos autores), trabalhada pela
WWF (World Wide Fund For Nature).
Assim como estas existem outras iniciativas que tentaram suprir as deficiências do
imageamento. Algumas estão bem documentadas enquanto outras possuem pouco ou
nenhuma documentação. A opção pelo uso da versão disponibilizada pela NASA garante que
a qualidade dos dados estão certificados pela instituição que realizou o imageamento.
Parte dos dados oriundos da SRTM, possui informação de parte da hidrografia, próximas
das regiões costeiras (alguns valores negativos dispersos). Para o presente trabalho, os dados
oriundos da missão SRTM foram fontes de subsídios somente para a região terrestre.
2.5 GEBCO
GEBCO ou General Bathymetric Chart of the Oceans é um mapa de batimetria dos
oceanos. Esse mapa começou a ser construído ainda no século 19 e ao longo do tempo o
projeto foi capitaneado pela The International Hydrographic Organization (IHO) e pela
Intergovernmental Oceanographic Commission (IOC) sendo esta última uma organização de
âmbito mundial filiada à UNESCO. O propósito dessa organização é padronizar a coleta de
dados, a nomenclatura utilizada e seus métodos de mapeamento.
Os dados GEBCO são compatíveis com a escala de 1:10.000.000 e além deste está
17
disponível no mesmo endereço uma série de produtos que vão desde mapas de batimetria
digital, até um CD-ROM contendo toda a informação adquirida com a batimetria em meio
digital (BODC, 2007).
De acordo com os responsáveis pelo levantamento dos dados GEBCO, a acurácia dos
dados é da ordem de + 5% da profundidade da região. O arquivo contém 180 graus de latitude
e 360 de longitude. Cada píxel representa uma região de 1x1 minuto. Os dados estão
armazenados em coordenadas geodésicas utilizando o sistema WGS 84. Este dados
representam tanto a região marinha quanto a região terrestre sendo:
● dos oceanos, a informação é oriunda de batimetria;
● da terra a informação é da missão GLOBE. (NGDC, 2007)
No presente trabalho foi utilizado somente a informação da região oceânica do
GEBCO, excluindo a região terrestre.
2.6 Visualização de MDT
Cada MDT possui uma finalidade específica. Os principais fatores que norteiam a
implementação das representações visuais são a capacidade de armazenamento, o tempo de
extração e a qualidade geométrica da representação. Diversas formas de visualização são
conhecidas e cada uma possui vantagens e desvantagens para cada finalidade.
FIG. 2.5 Visualização por projeção perspectiva (CÂMARA, 2006)
Uma forma de visualizar e armazenar os dados de um MDT é a projeção planar. Este
18
método consiste em tomar um plano na posição onde será gerada a imagem e uma projeção do
espaço 3D no plano. As visualizações que mais se aproximam à visão humana utilizam um
ponto de perspectiva a partir do qual são feitas as projeções sobre o plano da imagem. A FIG.
2.5 ilustra a abordagem utilizada na projeção perspectiva.
Outra forma de visualização é utilizar uma imagem para representar em seus níveis de
cinza a altimetria de uma determinada região. (CÂMARA, 2006) Esse método armazena
grades regulares onde cada pixel representa um ponto da grade. Para transformar de um
sistema para o outro utiliza-se a fórmula:
NCi = {[(Zi – Zmin)*254] / (Zmax – Zmin)} + 1 (CÂMARA, 2006)
Onde o nível de cinza (Nci) é relacionado com a altura do ponto (Zi) e com os valores
máximo (Zmax) e mínimo (Zmin) de altimetria da grade. Esta técnica economiza memória
mas dificulta a generalização dos dados. A maioria dos arquivos contendo MDTs disponíveis
são armazenados utilizando esta idéia. A FIG. 2.6 exibe uma imagem gerada na SRTM como
exemplo de grade regular armazenada em uma imagem Geotiff.
FIG. 2.6 Imagem SRTM visualizada do QGIS
19
3 METODOLOGIA
3.1 Material utilizado
Diversos programas foram utilizados durante o desenvolvimento do projeto. Foi feita a
opção por trabalhar com ferramentas de código aberto ou grátis. As tabelas desta parte exibem
as ferramentas utilizadas e os locais onde estão disponíveis para acesso público.
O computador utilizado durante os testes foi um HP Pavillion dv6120BR
NOTEBOOK PC. Processador Mobile AMD SempronTM, Disco rígido de 60GB Enhanced
IDE 5400 RPM SATA e memória de 512MB 667MHz DDR2 utilizando Kubuntu Linux.
As ferramentas aqui listadas como “código aberto” podem ser utilizadas sem
restrições, tanto o programa como seu código-fonte. As ferramentas listadas como “livres”
podem ser utilizadas com a restrição de que todo programa gerado utilizando o código-fonte
das mesmas deve ser GPL e, portanto, livre também.
TAB. 3.1 Gdal (Geospatial Data Abstraction Library) 1.3.1
Disponível em: www.gdal.org - MIT (código aberto)
Finalidade: Ferramentas em C++ para manipular os diferentes tipos de dados.
Descrição Bibilioteca C++ para tratamento de dados geográficos matriciais (GDAL) e
vetoriais (OGR) em C++.
TAB. 3.2 OpenJump 1.2.0 Pirol
Disponível em: http://www.al.fh-osnabrueck.de/jump-download.html - LGPL (código
aberto)
Finalidade: Ferramenta para acompanhar resultados e visualização tridimensional.
Descrição Ferramenta de SIG com capacidade de edição, conexão a bancos de dados
geográficos e análise de MDT vetorial.
20
TAB. 3.3 KDevelop 3.3
Disponível em: http://www.kdevelop.org/ - GPL (Livre)
Finalidade: Interface de desenvolvimento para C++.
Descrição Interface de desenvolvimento multilinguagem que auxilia na organização
dos arquivos para compilação utilizando g++ (para Linux) e mingw32 (para
Windows®).
TAB. 3.4 PostgreSQL 8.1
Disponível em: http://www.postgresql.org/ - BSD (código aberto)
Finalidade: Gerenciamento da tabela de índices e recorte da região de interesse
utilizando análises espaciais.
Descrição Sistema gerenciador de banco de dados objeto-relacional.
TAB. 3.5 PostGIS 1.1
Disponível em: http://www.postgis.org/ - GPL (livre)
Finalidade: Definição e extração dos arquivos necessários para a geração do MDT em
uma determinada região de interesse.
Descrição Extensão do PostgreSQL para manipulação de dados espaciais com suporte
a análises geográficas e otimização de consultas.
TAB. 3.6 Qgis (Quantum GIS) 0.8
Disponível em: http://www.qgis.org/ - GPL (livre)
Finalidade: Teste da sintaxe de análise geográfica utilizada para a definição da região
de interesse.
Descrição Aplicativo base para sistemas de informação geográfica que possui
conexão com PostgreSQL/PostGIS e que repassa comandos SQL para as
tabelas do SGBD.
21
TAB. 3.7 libzipios++
Disponível em: http://zipios.sourceforge.net/ - LGPL (código aberto)
Finalidade: Extração dos arquivos SRTM compactados.
Descrição Programa para extração de arquivos compactados no formato ZIP.
TAB. 3.8 Python 2.5
Disponível em: http://www.python.org – Específica (Código aberto)
Finalidade: Execução de arquivos na linguagem interpretada Python.
Descrição Programa que interpreta códigos em Python e os executa independente de
arquitetura e sistema operacional.
TAB. 3.9 Umbrello 3.5
Disponível em: http://uml.sourceforge.net/ - GPL (livre)
Finalidade: Importação de diagramas de classes à partir do código-fonte em C++.
Descrição Programa CASE para definição de diagramas UML com importação e
exportação de código para várias linguagens.
TAB. 3.10 OpenOffice.org 2.2
Disponível em: http://www.openoffice.org - LGPL (código aberto)
Finalidade: Documentação do projeto.
Descrição Ferramenta de escritório para geração de documentos digitais.
TAB. 3.11 Kubuntu 7.05
Disponível em: http://www.kubuntu.com - GPL (livre)
Finalidade: Sistema operacional Linux para testes.
Descrição Sistema operacional Linux que possui manutenção estável dos pacotes
disponíveis no repositório.
22
TAB. 3.12 Boost C++ Library
Disponível em: http://www.boost.org - GPL (livre)
Finalidade: Interação com sistema de arquivos (cópias, remoções, diretórios, etc).
Descrição Biblioteca multi-plataforma com diversas funcionalidades gerais para C++.
TAB. 3.13 Qt 3
Disponível em: http://trolltech.com/products/qt/qt3 - QPL (específica)
Finalidade: Desenvolvimento da interface gráfica.
Descrição Framework utilizado para interface gráfica.
3.2 Origem dos dados
No ANEXO I estão inseridas informações sobre os diferentes formatos de arquivos
utilizados durante o projeto. A relevância destas informações se dá pois a integração dos
dados das duas fontes (SRTM e GEBCO) não é possível sem a análise de formas de leituras
para seus formatos de arquivos.
3.2.1 Arquivos da SRTM
Foi desenvolvido o código “srtm_dl_fin.py”. Este código é um programa na
linguagem interpretada Python. O objetivo do mesmo é organizar as descargas dos arquivos
que compõem o mosaico de cobertura da SRTM “finished”. Os dados foram disponibilizados
no servidor FTP (File Transfer Protocol) da NASA (“ftp://e0srp01u.ecs.nasa.gov”). Após a
descarga verificou-se que a soma dos tamanhos dos arquivos SRTM compactados chegava a
valores acima de 16 gigabytes.
O formato original dos dados é o “.hgt”. Este arquivo, quando anexado a um
cabeçalho, pode ser lido utilizando a biblioteca GDAL como se fosse um arquivo “.bil”. A
primeira implementação do arquivo “srtm_dl_fin.py” utiliza o código gerado por (NETELER,
2006) para executar a conversão dos dados obtidos para uma imagem em fromato GeoTiff,
possibilitando a visualização. Foi criado o método “createhdr()” (explicado no ítem 3.4.6) no
aplicativo que se encarregou de gerar os cabeçalhos que contém informações de
georeferenciamento das imagens. Com os cabeçalhos criados a biblioteca GDAL consegue ler
naturalmente os arquivos “.bil”.
23
A escala altimétrica das imagens da SRTM é de 1 metro para 1 valor de nível de cinza.
Isso possibilita a leitura do valor de cinza como altura do ponto sem a necessidade de outros
cálculos para conversão.
3.2.2 Arquivo do GEBCO
Para obter os dados do GEBCO foi feito o acesso através da Internet: (BODC, 2007).
Dentro deste endereço é necessário o registro no sítio da BODC (British Oceanographic Data
Center) para obter a permissão para acessar os arquivos. Este registro é feito sem pagamento
de nenhuma quantia. O formulário exige informações simples sobre a identidade do usuário.
Assim que o endereço eletrônico do usuário e a senha registrados na BODC são informados
ao sistema este permite o acesso a arquivos pequenos regionais (20x20 minutos em
coordenadas geodésicas), arquivos de imagens de mapas gerados com estes dados ou um
único arquivo com 275,1MB no formato “.zip” que contém um único arquivo “.grd” com
todos os dados do modelo digital do GEBCO.
A BODC aconselha utilizar o programa GMT (aplicativo livre, multi-plataforma,
usado para produção de mapas) ou o GEBCO Grid Display (aplicativo desenvolvido pela
BODC para trabalhar com os dados do GEBCO em ambiente Microsoft Windows)
disponibilizado na Internet.(BODC, 2007)
O arquivo “grd” é do formato NetCDF (BODC, 2007). Este formato é definido pela
Unidata (Unidata, 2007), que também disponibiliza bibliotecas para trabalhar com este
formato. A biblioteca para C++ é a libnetcdf++. Porém esta biblioteca permite o acesso ao
GEBCO sem informações geográficas (cabendo ao programa que a utiliza acessar as
informações dentro do arquivo e processá-las de forma a obter o georeferenciamento do
mesmo). Por outro lado a biblioteca GDAL acessa também o arquivo NetCDF já como
imagem georeferenciada.
Foi encontrada uma falha na compilação da biblioteca GDAL no pacote disponível nos
repositórios do Kubuntu Linux. Ao abrir um arquivo NetCDF a biblioteca gerava um estouro
de memória. Em uma lista de discussão foi mencionado que a solução era recompilar a
biblioteca sem o suporte a arquivos “.hdf” (Gdal wiki, 2007). Ao recompilar, a biblioteca
GDAL passou a trabalhar com os arquivos NetCDF sem a necessidade de nenhum trabalho
adicional.
Assim como na SRTM, no GEBCO a escala altimétrica das imagens é de 1 metro para
24
1 valor de nível de cinza.
3.3 Preparação do Sistema
3.3.1 Abordagem Escolhida
Para atingir o objetivo de gerar um modelo digital global foi definida uma estratégia
que consiste em armazenar os arquivos matriciais oriundos da SRTM e do GEBCO em um
sistema de arquivos. Desenvolveu-se um programa que se encarrega de receber as
coordenadas da região de interesse, descobrir quais são os arquivos que contém os dados
necessários para gerar um modelo digital daquela região, abrir cada arquivo, fazer a
reamostragem escolhendo uma quantidade fixa de pontos para aquela região e gerar um
arquivo no formato “bn3” que pode ser exibido utilizando a Plataforma de Visualização. A
FIG. 3.1 exibe as atividades que o aplicativo desenvolvido deve fazer.
FIG. 3.1 Atividades executadas pelo aplicativo
O padrão “bn3” foi definido durante o desenvolvimento da Plataforma de
25
Visualização. O objetivo foi definir um padrão simples baseado em tabelas ASCII, que
armazenasse dados vetoriais em três dimensões. Atualmente estão definidos pontos, linhas e
polígonos para este tipo de arquivo. Mais informações sobre este formato são discutidas no
item 3.4.2.
3.3.2 Preparação dos arquivos SRTM para geração de MDT
Depois de obter os primeiros arquivos começou-se o desenvolvimento do código que
trataria da geração do produto final. Durante esta etapa foram gerados 5 arquivos “.sql” que
foram carregados em um banco de dados geográfico utilizando PostgreSQL/PostGIS. Esses
arquivos foram gerados utilizando o arquivo de lote para BASH “createindex.sh” que utiliza
ferramentas da GDAL e o arquivo de lote gerado por Markus Neteler para extração e
georreferenciamento dos arquivos, geração de um polígono no arquivo “.shp” para cada
arquivo e remoção dos arquivos extraídos. O polígono gerado é um quadrilátero que
representa a região que a imagem contida naquele arquivo cobre. Esse procedimento foi feito
desta forma pois os arquivos estão compactados utilizando o formato “.zip”. Estes arquivos
“.bil” não possuem informação geográfica definida em seu formato. Para o
georreferenciamento é necessária a geração dos cabeçalhos a partir do nome do arquivo.
Nesta etapa o código de Markus Neteles foi necessário.
Alguns testes de tamanhos de arquivos foram feitos para decidir se o esforço
computacional necessário para extrair o arquivo durante a geração do MDT final valia quando
comparado com o armazenamento dos arquivos. Quando descompactados, todos arquivos
“.bil” são matrizes de 1201x1201 píxels. Isso, junto com os arquivos de georeferenciamento
somam 2,8 megabytes para cada arquivo. Foram escolhidos alguns arquivos para notar a
porcentagem de compactação. Utilizando os arquivos da primeira descarga (incompleta) da
América do Sul, haviam 1805 arquivos. A TAB. 3.14 exibe os dados do teste. Conforme
observado, 77% dos arquivos possuíram mais de 50% de compactação (pois os tamanhos são
menores que o original (2,8 megabytes no formato “.hgt”) e a quase totalidade teve pelo
menos 75%. Armazenar como arquivo GeoTiff significaria aumentar em pelo menos 33% o
tamanho dos nossos arquivos.
26
Observando a TAB. 3.14 a idéia de converter diretamente os arquivos compactados
para GeoTiff e disponibilizá-los desta forma foi descartada. Desta forma os dados estão
armazenados da mesma forma como extraídos do servidor. Isso faz com que o sistema torne-
se menos vulnerável às alterações nos dados do servidor pois só seria necessário gerar a
tabela de índices novamente.
Como os arquivos permanecem armazenados compactados, é custoso saber qual
região cada um deles cobre. Para solucionar esse problema foi gerado um arquivo “.sql” que
carrega uma tabela para PostgreSQL/Postgis chamada “índice”. Essa tabela contém as
coordenadas de contorno de cada imagem da SRTM. A FIG. 3.2 ilustra as tabelas “indice” e
“worldpolitical”. A tabela “worldpolitical” foi obtida através da conversão do arquivo “.shp”
para “.sql” utilizando o comando do Postgis “shp2pgsql”. O arquivo original foi obtido em
“http://aprsworld.net/gisdata/world/”. Na tabela, além dos contornos, estão armazenados na
coluna “location” os nomes dos arquivos que geraram esses contornos.
FIG. 3.2 Corte do índice da cobertura das imagens SRTM
27
TAB. 3.14 Teste de porcentagem de compactação
Compactação Quantidade % Arquivosaté 10% 143 0.08até 50% 1388 0.77até 75% 1801 1TOTAL: 1805
3.3.3 Preparação do arquivo GEBCO para geração de MDT
O GEBCO é disponibilizado de várias formas. Uma delas fornece um único arquivo
compactado utilizando o formato “zip” que pode ser extraído utilizando o aplicativo unzip.
Após a descompactação o arquivo está pronto para a utilização no aplicativo desenvolvido.
Esta decisão de não guardá-lo compactado foi tomada observando que mesmo para pequenas
regiões geográficas o sistema teria que descompactar as informações referentes do mundo
todo.
3.3.4 Dependências
A biblioteca para executar a extração dos arquivos compactados escolhida foi a
biblioteca multi-plataforma libzipios++ (TAB. 3.8). Essa escolha foi feita pelo fato de ser
uma interface para a linguagem C++, disponível no repositório do Kubuntu Linux.
Para conseguir acesso aos arquivos no formato NetCDF foi necessário recompilar a
biblioteca multi-plataforma GDAL. Para isso foi obtido o código fonte da biblioteca e
compilada conforme as instruções que vieram junto do código. Por recompilar a GDAL foi
necessário recompilar também o QGIS, que a utiliza. O QGIS foi parte crucial pois serviu
como programa de referência para visualizar os dados da mesma forma que o programa
desenvolvido os acessaria dado que ambos programas utilizam a biblioteca. A biblioteca
GDAL também possibilitou acesso ao PostgreSQL com Postgis e aos arquivos “.bil” da
SRTM. A FIG. 3.3 ilustra a visualização do arquivo do GEBCO no QGIS. Isso só é possível
quando a biblioteca GDAL está com o acesso ao formato NetCDF funcionando corretamente.
28
FIG. 3.3 Visualização do GEBCO no QGIS
Para executar operações básicas nos arquivos dentro da arquitetura de sistema foi
utilizada a biblioteca multi-plataforma Boost C++. Essa foi uma tentativa de manter o caráter
multi-plataforma do EWSM.
Para executar todas as operações de análises geográficas e armazenamento de dados
vetoriais foi utilizado o conjunto PostgreSQL/Postgis. Esse sistema gerenciador de banco de
dados, com a extensão espacial, permite análises otimizadas utilizando índices GIST. Tanto o
QGIS (através da GDAL) quanto OpenJump conseguem se conectar ao Postgis e trabalhar os
dados armazenados nele.
3.4 Implementação
3.4.1 Estratégia
Para executar as atividades definidas na FIG. 3.1 , iniciou-se o desenvolvimento de um
programa que pudesse ser compilado em várias plataformas. Foi escolhida a linguagem C++
29
(TAB. 3.4) e o nome do programa é EWSM (Earth and Water Surface Model). Sua primeira
implementação completa foi feita em Kubuntu Linux (TAB. ). O modelo da FIG.3.4 exibe o
modelo de classes do código desenvolvido.
FIG. 3.4 Modelo de Classes simplificado do aplicativo EWSM
A classe “cterrainsample” se encarrega de executar os passos 2 a 8 da FIG. 3.1. Nela
estão implementadas as reamostragens. Para efetuar a conexão ao banco de dados
PostgreSQL/Postgis é utilizada a classe “cgeodb”. As análises geográficas complexas são
30
feitas através desta classe. Como os arquivos da SRTM estão compactados para economizar
memória, a classe “czip” é essencial para a “cterrainsample” pois permite a extração de
arquivos compactados. O programa tem duas saídas de dados. Uma compatível com os
padrões internacionais que armazena os pontos da malha no banco PostgreSQL/Postgis e
simultaneamente é gerado um arquivo “bn3”, utilizando a classe “cbn3”, que contém as
mesmas informações da malha. As classes “pvtgl”, “ewsm_call” e “ewsm_gui” são as classes
responsáveis pela interface gráfica que permite ao usuário escolher parâmetros para trabalhar
com a classe “cterrainsample”. A classe “ccron” se encarrega de cronometrar as atividades
executadas pelo programa (em segundos) pois a maior dificuldade ao trabalhar com o SRTM
na máquina na qual foi feito o projeto era o tempo de processamento ao acessar os arquivos.
3.4.2 Classe “cbn3”
Esta classe é a responsável pela criação do arquivo “bn3”. Sua implementação visou
definir métodos simples que pudessem gerar os três tipos de geometrias do arquivo “bn3”:
linha 3D, ponto 3D e polígono 3D. Cada objeto é descrito por um cabeçalho onde a classe
escreve o tipo de objeto (apenas para facilitar a leitura pelos usuários curiosos) e um número.
Este número é a quantidade de pontos definidos pelo objeto multiplicado por um valor. Este
valor pode ser 1 ou -1. No caso do polígono 3D o primeiro ponto deve ser repetido no fim do
arquivo de forma a coincidir o início com o final da linha do polígono. Dessa forma, as
geometrias são armazenadas com valores conforme a tabela .
TAB. 3.15 Objetos do arquivo “bn3”
Número de descrição Tipo de geometria
npontos * 1 Linha 3D
n = 1 Ponto 3D
npontos * -1 Polígono 3D
Na FIG. 3.5 está representado um exemplo de arquivo “bn3” gerado pela classe cbn3
onde pode-se observar o cabeçalho e a quantidade de pontos positiva para definir uma linha
de três dimensões.
31
FIG. 3.5 Arquivo “.bn3” aberto no editor de textos Kate
Como não são definidas malhas no arquivo “bn3”, a saída do aplicativo EWSM são
duas linhas sendo uma delas gerada utilizando os dados da SRTM (parte terrestre) e a outra
utilizando os dados do GEBCO (parte sob as águas). Cada uma destas linhas liga todos
3.4.3 Classe “cgeodb”
A biblioteca GDAL contém outra de nome OGR. Da mesma forma que a GDAL é
voltada para o acesso e manipulação de dados geográficos matriciais, a OGR é responsável
pelos dados de natureza vetorial. Diversos formatos de dados vetoriais são mapeados para
objetos no modelo lógico da OGR. Entre eles se encontram Shapefiles, DGN, GML e
PostgreSQL/Postgis.
A classe “cgeodb” utiliza a capacidade de conexão ao PostgreSQL/Postgis para
disponibilizar-se como ferramenta de armazenamento e análise de dados geográficos. As
análises são passadas para o Postgis utilizando comandos SQL (Structured Query Language)
através do método “runsql()”. Este método retorna um ponteiro para uma tabela geográfica
(OGRLayer). Os métodos “getlayer()” e “createlayer()” são utilizados para acessar e criar
tabelas geográficas respectivamente.
Os parâmetros para conexão ao PostgreSQL estão definidos no objeto privado
“std::string connstring”. Esta implementação restringe o modelo do banco de dados de forma
que o nome do banco de trabalho (que deve estar previamente criado) é “profic”, a senha do
32
usuário “postgres” é “teste”, a porta de conexão é “5432” e o banco é local. Para definir um
acesso diferente o objeto deveria ser gerado definindo parâmetros de conexão no método de
criação (“new cgeodb()”).
3.4.4 Classe “czip”
Para escrever esta classe foi usada como referência o arquivo “test_zip.cpp”
disponível junto do código fonte da biblioteca “libzipios++” (TAB. 3.8). O método “extract()”
é o responsável pelo processamento de um arquivo cuja localização é passada utilizando uma
“std::string” na chamada do método.
3.4.5 Classes “ewsm_call”, “ewsm_gui” e “pvtgl”
Este conjunto de classes foi desenvolvido utilizando a integração KDevelop 3 e Qt-
Designer 3. Esta funcionalidade do KDevelop permite gerar a geometria da interface gráfica
utilizando o Qt-Designer e depois especializar a classe gerada (no caso, classe “ewsm_call”).
Esta nova classe (no caso, classe “ewsm_gui”) herda todos os métodos e propriedades que
geram o desenho das janelas e permite a implementação dos métodos que controlam as
interações entre a interface gráfica e as demais classes (no caso, classe “cterrainsample”). A
FIG. 3.6 ilustra a interface gráfica gerada pela classe “ewsm_gui”. Nota-se uma caixa de texto
no topo da janela. Esta caixa de texto armazena instruções sobre como utilizar corretamente o
aplicativo. Por exemplo, explica que a entrada da região de interesse deve ser em graus
decimais, utilizando ponto como separador.
33
FIG. 3.6 Interface gráfica do programa EWSM.
A classe “pvtgl” (Plaforma de Visualização de Teatros de Guerra Lite) representa um
“QmainWindow” (Trolltech, 2007). Esta classe define quem é a classe principal. O objetivo
dessa classe é servir como plataforma para chamar a classe “ewsm_gui” assim como faria a
Plaforma de Visualização de Teatros de Guerra.
34
FIG. 3.7 Interface gráfica gerada pela classe "pvtgl".
3.4.6 Classe “cterrainsample”
Esta classe é a encarregada de receber os parâmetros da região de interesse,
reamostrar, fundir os dois modelos em um único e guardar este novo modelo tanto no banco
de dados geográfico quanto em um arquivo “bn3”. O método que faz este controle de entrada
e saída e que é acessado pelas classes de interface com usuário é o “ressampleArea()”. Ele
recebe como parâmetros os locais onde os arquivos estão, as quantidades de pontos por linha
para a reamostragem e as coordenadas de X e Y do contorno da região (em coordenadas
geodésicas, ou seja, longitude e latitude).
Os métodos mais relevantes implementados na “cterrainsample” são:
1. “getRegionTiles()”
2. “ressampleTile()”
3. “createhdrfile()”
4. “ressampleSea()”
5. “ressampleArea()”
Seu processo começa com o método “getRegionTiles()” para descobrir quais são as
imagens da SRTM que ela deverá reamostrar. Este retorna uma uma lista de nomes de
arquivos SRTM que cobrem a região. Em seqüência, cada arquivo é extraído usando o método
“czip::extractFile()” e cada arquivo é reamostrado utilizando o método “ressampleTile()”. Ao
juntar todos os pontos está pronta a porção terrestre. A porção marítima é feita através de uma
única reamostragem no arquivo “GridOne.grd” do GEBCO. O método chamado é o
“ressampleSea()”. Por fim, todos os resultados das reamostragens são guardados em um único
arquivo “bn3” (classe cbn3) e grava as porções marítima e terrestre separadas no banco de
dados (classe cgeodb). A FIG. 3.8 ilustra o funcionamento da classe “cterrainsample”.
35
FIG. 3.8 Funcionamento da classe "cterrainsample"
3.4.6.1 O método “getRegionTiles()”
O método “getRegionTiles()” utiliza um comando SQL para executar uma análise
geográfica dentro do banco de dados com Postgis. O objetivo desse comando é identificar
quais são as imagens SRTM que representam a região de estudo. A região de estudo é definida
por um retângulo (em coordenadas geodésicas). Este comando acessa a tabela “indice” que
contém os nomes e os contornos de cada imagem da SRTM. Utilizando os contornos e o
retângulo da região de estudo, uma interseção espacial retorna todos os contornos que
intersectam ou estão contidos na região de estudo. O comando utilizado para obter as
interseções no exemplo da FIG 3.6 foi:
SELECT * FROM indice WHERE Intersects(indice.the_geom,
PolyFromText('POLYGON((-40 -20, -45 -20, -45 -25, -40 -25, -40 -20))'));
36
3.4.6.2 O método “ressampleTile”
O método “ressampleTile()” faz a reamostragem nos arquivos da SRTM. A
reamostragem utilizada consiste em tomar uma grade regular definida pela quantidade de
linhas e colunas da grade. A altura de cada ponto é o valor de cinza representado no píxel da
região onde o ponto se encontra. Cada arquivo gera uma grade contendo uma quantidade
fixada de linhas e colunas.
3.4.6.3 O método “createhdrfile()”
Com o objetivo de tentar manter o programa em C++, o script de Markus Neteler foi
traduzido para o método “createhdr()”. O método cria dois arquivos a partir do nome de um
arquivo “.hgt”: um “.prj” e um “.hdr”. O arquivo “.prj” guarda o sistema de referência (no
caso, coordenadas geodésicas em WGS 84), enquanto o arquivo “.hdr” guarda a posição do
arquivo neste sistema. Diferente do script, este método não transforma o arquivo “.hgt” em
GeoTiff pois a biblioteca GDAL consegue acessar os arquivos “.hgt” quando acompanhados
dos arquivos “.prj” e “.hdr”.
3.4.6.4 O método “ressampleSea()”
A reamostragem do GEBCO é feita pelo método “ressampleSea()”. O processo é o
mesmo das imagens SRTM, mas a forma de definir a região de estudo é diferente. Como o
GEBCO é um único arquivo que cobre o mundo, a região de estudo deve ser recortada de um
único arquivo. Por isso não são geradas várias grades como acontece com os dados da SRTM.
Uma única grade é gerada e espaçada na região de estudo. Por isso os valores aconselháveis
de pontos por linha na porção marítima a utilizar no programa EWSM normalmente são
maiores que os utilizados na porção terrestre.
3.4.6.5 O método “ressampleArea()”
O método “ressampleArea()” é que gerencia o processamento. Primeiramente,
identifica as imagens SRTM que cobrem a região de estudo e obtém os dados reamostrados
37
das mesmas. Estes dados são armazenados no banco de dados geográfico
PostgreSQL/Postgis na tabela “bn3”. Enquanto os pontos são inseridos no banco é feito um
teste. Todos os pontos com altura exatamente igual a zero são ignorados. Isso é feito desta
forma para não haver sobreposição entre os zeros da SRTM e os dados oceânicos do GEBCO.
Esta abordagem foi a que apresentou melhor tempo de processamento. Anteriormente
foram testadas duas outras abordagens. A primeira era definir uma linha de costa utilizando a
curva de nível de 2 metros de todo o modelo da SRTM. Como a precisão altimétrica está
acima desse valor, pode-se considerar isso como linha de costa. Não foi utilizada a curva de 0
metros pois os oceanos todos estão mapeados com 0 metros nas imagens. Esta abordagem tem
qualidade dos dados compatível com a melhor qualidade disponível dentro do modelo da
SRTM. Sua desvantagem foi gerar arquivos com centenas de MB. A linha de costa gerada em
arquivo “.sql” da América do Norte possui 755 MB. Carregá-los no banco levou mais de 15
minutos.
Um segundo teste foi feito utilizando a camada “worldpolitical”. Esta camada não
passa de 5MB quando em formato “.sql” e cobre o mundo todo. Obviamente, a qualidade dos
dados é muito pior. Foi então preparado um comando SQL que copiasse todos os pontos
gerados pelo programa que estivessem na região de terra para uma outra tabela. Dessa forma,
quando o banco encontrasse um ponto contido em algum país ele adicionaria à tabela. Para a
parte marítima foi feito o oposto. Cada ponto encontrado dentro de algum país seria removido
da tabela. O comando utilizado na porção marítima foi:
delete from sea where ogc_fid IN (select sea.ogc_fid from sea, worldpolitical
where sea.wkb_geometry && worldpolitical.the_geom AND
within(sea.wkb_geometry,worldpolitical.the_geom)='t')
Os testes de processamento com o comando demoravam entre 1 e 5 minutos para
regiões de 5x5 graus. Como a qualidade dos dados da tabela “worldpolitical” já apresentava
erros que removeriam pontos considerados terra na SRTM, foi feita a opção de simplesmente
não gerar os pontos com altura zero ou nula. Essa solução apresentou resultados em 5
segundos para a mesma região geográfica.
A FIG. 3.9, ilustra as três abordagens. A linha mais grossa pertence à tabela
“worldpolitical” (segunda abordagem), a mais fina à tabela “coastline” (gerada utilizando a
curva de nível de 2 metros nas imagens da SRTM – primeira abordagem), e os pontos mais
38
espaçados são oriundos da SRTM e os menos espaçados oriundos do GEBCO. Os pontos
foram escolhidos removendo das imagens da SRTM os valores menores ou iguais a zero e
removendo do GEBCO os valores maiores que zero (terceira abordagem).
A terceira abordagem foi escolhida como definitiva. Os resultados deste
processamento são armazenados nas tabelas “sea” (parte marítima) e “bn3” (parte terrestre).
Ao fim da execução o arquivo “.bn3” é preenchido com duas linhas, uma ligando todos os
pontos da tabela “sea” e outra ligando os pontos da tabela “bn3”.
FIG. 3.9 Diferenças entre a tabela “coastline” a “worldpolitical”
Todas as imagens utilizadas neste documento, assim como os arquivos utilizados para
produzi-las estão no CD-ROM em anexo. O ANEXO II contém a listagem dos diretórios e a
explicação como estão armazenados os arquivos.
39
4 RESULTADOS
Para exibir um exemplo dos resultados obtidos com o aplicativo EWSM é necessário
que algum outro aplicativo faça a visualização dos dados gerados. Foram definidas duas
metodologias para exibir os resultados: Uma utilizando visualização bidimensional (FIG. 4.1)
e outra utilizando visualização tridimensional (FIG. 4.4).
4.1 Desenvolvendo um MDT em escalas de cinza com EWSM e OpenJump Pirol
FIG. 4.1 Visualização do Rio de Janeiro no OpenJump
Para gerar a FIG. 4.1, foi utilizado o aplicativo OpenJump com as extensões PIROL.
Esta ferramenta é voltada para sistemas de informações geográficas. Entre suas funções,
permite produzir mapas temáticos à partir de dados armazenados em um banco de dados
geográficos PostgreSQL/Postgis.
Para exibir os dados dessa forma primeiro foi feita a conexão ao banco utilizando o
menu “Layer” e o sub-menu “Add a Datastore Layer”. A janela ilustrada na FIG. 4.2 exibe os
parâmetros de conexão ao banco ao adicionar a tabela “bn3” (que contém os pontos oriundos
da SRTM).
40
FIG. 4.2 Conectando ao banco de dados no OpenJump
O segundo passo é adicionar as tabelas “sea” e “worldpolitical” utilizando a mesma
janela. O terceiro passo é alterar o estilo de cada camada. Com o botão direito sobre o nome
da camada na barra lateral esquerda, abre-se um menu e escolhe-se “Change Styles”. A FIG.
4.3 exibe a janela e as escolhas de escala de cinza utilizando o atributo “height” contido na
tabela “sea”. O mesmo procedimento é executado para a tabela “bn3”. Na aba “Rendering”
dos estilos da camada “worldpolitical” desabilita-se a opção “fill”. Dessa forma o contorno
político dos países será mostrado sem sobrepor os pontos. O resultado deste processo está
exibido na FIG. 4.1.
FIG. 4.3 Escolha da escala de cinza
41
4.2 Desenvolvendo um modelo 3D em escalas de cinza com EWSM e OpenJump Pirol
FIG. 4.4 Visualização 3D do Rio de Janeiro no OpenJump
Iniciando a produção da visualização tridimensional é necessário ter cumprido todas
as etapas da visualização bidimensional. Com o mapa pronto, escolhe-se a camada “bn3” na
barra da esquerda. A seguir o menu “Tools”, submenu “Edit”, submenu “new Affine
Transformation” faz surgir uma janela onde deve-se colocar “10000.0” nos valores de escala
para os eixos X e Y. Isso irá criar uma camada nova “Affine-bn3”. O mesmo procedimento é
feito para a camada “sea” gerando a camada “Affine-sea”. Com o botão direito na camada
“Affine-sea” na barra da esquerda escolhe-se o menu “Zoom to Layer”. Isso deve mostrar
uma nova região onde as coordenadas estão em grau vezes 104. Esse processo é feito pois as
coordenadas de altura estão entre 0 e 105 metros. Para visualizar é bom que os eixos estejam
em escalas próximas. A FIG. 4.5 ilustra as camadas geradas neste processo. No caso a camada
selecionada é a “bn3”.
42
FIG. 4.5 Camadas geradas
Em seguida, novamente com o botão direito sobre o nome da camada “Affine-sea”,
seleciona-se o menu “Select Current Layer Items”. Com o botão direito sobre algum dos
pontos selecionados no mapa, escolhe-se o menu “Copy”. Com o botão direito sobre o nome
da camada “Affine-bn3” escolhe-se o menu “Paste Items”. Dessa forma todos os pontos da
camada “Affine-sea” deverão estar na camada “Affine-bn3”, gerando um único modelo.
Acessando o menu do OpenJump, enquanto a camada ativa (marcada por uma
caixinha azul na barra da esquerda) é a “Affine-bn3”, escolhe-se a opção “Pirol Tools”,
submenu “Visual Tools”, submenu “Terrain Model 3D”. Escolhe-se a coluna “height” como
fonte da altimetria e aceita-se a opção de gerar textura. O resultado do processamento está na
FIG. 4.4. A FIG. 4.6 ilustra a seleção da camada “Affine-bn3” e o pedido de modelagem da
mesma.
43
FIG. 4.6 Gerando o modelo 3D no OpenJump Pirol
4.3 Análise dos resultados
Foram apresentadas duas metodologias sobre como visualizar os dados gerados pelo
aplicativo EWSM. A metodologia que define a utilização na Plataforma de Visualização está
documentada no próprio programa que trabalha com o arquivo “.bn3” nativo. É claro que
outras formas de acesso a estes dados são possíveis pois os dados estão armazenados em um
padrão aberto no banco de dados. Foram feitos testes com o Quantum GIS (FIG.4.7) , gvSIG e
OpenEV. Estes outros testes de visualização bidimensional não foram documentados pois
seriam redundância de informação já que os processos são extremamente similares. O único
teste de visualização tridimensional feito foi no OpenJump Pirol. Foram feitos testes com
outras regiões. Um teste na Escócia e outro da América do Sul completa. Este último demorou
cerca de 5 minutos para exibir um resultado. À princípio este número pareceu alto. Depois
verificou-se que existem 2.5GB de dados que cobrem a região, que deveriam ser
descompactados durante a extração das coordenadas. Este, sem sombra de dúvida, é o gargalo
44
do processo pois é comparável ao tempo de descompactação utilizando o unzip.
FIG. 4.7 América do Sul no QGis
45
5 CONCLUSÃO
O Earth and Water Surface Model não é uma idéia nova. O próprio modelo do
GEBCO já possui dados de porção terrestre e submersa. Porém, a qualidade dos dados
levantados na SRTM é superior e a mistura destes modelos traz resultados com qualidade
melhor na porção terrestre.
O parâmetro escolhido (quantidade de pontos) é muito pouco natural para o usuário.
Este deve ter em mente que cada corte SRTM possui 1x1 grau e que os pontos do GEBCO
serão espaçados regularmente na região que ele definir.
Utilizando todos os dados disponibilizados na SRTM pode-se gerar um modelo
altimétrico de toda a superfície de terra do planeta. O processo só exigiria possuir espaço em
disco para armazenar em único diretório todos os arquivos da SRTM e armazenar o GEBCO
em algum lugar acessível.
No disco em anexo existem diversos arquivos. Entre eles há a documentação gerada
pelo Doxygen através do KDevelop. Esta documentação exibe modelos de dependência entre
os métodos, dá marcações de onde cada método foi implementado no código, explica o que
cada método faz e quais são as idéias utilizadas em cada um. Para futuros desenvolvedores
que utilizem algum pedaço do EWSM, este documento é uma ferramenta crucial.
O código fonte do desenvolvimento, assim como arquivos utilizados (principalmente
capturas de tela e projetos do OpenJump e QGIS) durante a execução deste trabalho estão
também no disco em anexo.
Uma sugestão para trabalhos futuros é implementar novos métodos de reamostragem.
A reamostragem utilizada é a mais imediata possível. Outros tipos de projetos podem sentir a
necessidade de uma reamostragem mais rebuscada conforme as documentadas no item 2.3.
Essas reamostragens exigiriam um pouco de esforço no código para definir uma forma de
implementá-las tanto no “ressampleTile()” quanto no “ressampleSea()”.
Não foram feitos testes utilizando a Plataforma de Visualização de Teatros de Guerra.
Estes testes são interessantes mas não houve a disponibilidade do código compilado para
Linux onde pudessem ser feitos os testes.
Durante os testes foi levantada a possibilidade de integrar o EWSM ao MapServer
(http://www.mapserver.org) e, possivelmente, ao Open3DGIS (http://www.open3dgis.org).
Estes aplicativos permitiriam uma interface em páginas da rede global (Internet) para o
46
EWSM.
BIBLIOGRAFIA
NOÇÕES BÁSICAS DE CARTOGRAFIA. Coordenação Isabel de Fátima Teixeira Silva.
Desenvolvido pelo Instituto Brasileiro de Geografia e Estatística. Disponível em:
<http://www.ibge.gov.br/home/geociencias/cartografia/manual_nocoes/indice.htm>. Acessado
em 03/08/2006.
CGIAR – CONSORTIUM FOR SPATIAL INFORMATION. Correção SRTM. Disponível
em: <http://srtm.csi.cgiar.org/>. Acessado em :03/08/2007.
WORLD WIDELIFE FUND FOR NATURE– FRESHWATER – HYDROSHEDS. Correção
SRTM. Disponível em: <http://www.worldwildlife.org/freshwater/hydrosheds.cfm> .
Acessado em: 3/8/2007.
REFERÊNCIAS BIBLIOGRÁFICAS
LI, Zhilin; ZHU, Qing; GOLD, Chris. Digital Terrain Modeling: Principles and Methodology.
Boca Raton, Flórida, EUA, CRC Press, 2005. ISBN 0-415-32462-9.
MEYER, W.. Concepts of Mathematical Modeling. New York, McGraw-Hill Book Company,
1985. ISBN .
NASA'S JET PROPULSION LAB. Shuttle Radar Topography Mission, Disponível em:
<http://www2.jpl.nasa.gov/srtm/>. Acesso em 31/10/2006.
USGS, EROS, DATA SERVICES BRANCH. Shuttle Radar Topography Mission
(SRTM)"Finished" 1 Arc Second (30m):, Disponível em:
<http://seamless.usgs.gov/website/seamless/products>. Acesso em 31/10/2006.
NGDC (NATIONAL GEOPHYSICAL DATA CENTER). NOAA/NGDC/MGG-GLOBE
Project (Global Land One-km Base Elevation) Home page, Disponível em:
<http://www.ngdc.noaa.gov/mgg/topo/globe.shtml>. Acesso em 16/08/2007.
47
CÂMARA, G. DAVIS, C.. Introdução à Ciência da Geoinformação .INPE, 2006.
NETELER, MARKUS. SRTM remote sensing at MPBA group/IRST, Disponível em:
<http://mpa.itc.it/rs/srtm/>. Acesso em 08/16/2006.
BRITISH OCEANOGRAPHIC DATA CENTRE. Gridded Bathymetry Data, Disponível em:
<http://www.bodc.ac.uk/data/online_delivery/gebco/>. Acesso em 2007.
UNIDATA. NetCDF (Network Common Data Format), Disponível em:
<http://www.unidata.ucar.edu/software/netcdf/>. Acesso em 02/08/2007.
OSGEO - GDAL WIKI. HDF - GDAL - Trac, Disponível em:
<http://trac.osgeo.org/gdal/wiki/HDF>. Acesso em 02/08/2007.
TROLLTECH. Qt - Trolltech, Disponível em: <http://trolltech.com/products/qt>. Acesso em
16/08/2007.
48
ANEXO I – EXTENSÕES DOS ARQUIVOS UTILIZADOS
Extensão: Descrição: Compatível com programa:
“.htg” Imagem matricial binária. Não contém
informações geográficas dentro da codificação.
No caso da SRTM o enquadramento é dado pelo
nome do arquivo.
QGIS (quando os arquivos de
georeferenciamento foram
criados)
“.bn3” Imagem vetorial baseada em texto. Plataforma de Visualização de
Teatros de Guerra
“.zip” Pacote compactado unzip
“.bil” Imagem matricial binária. Semelhante ao “.htg”. QGIS (quando os arquivos de
georeferenciamento foram
criados)
“.shp” Imagem vetorial binária. QGIS, OpenJump Pirol
“.sql” Arquivo de lote SQL. Contém comandos SQL
que são executados seqüencialmente.
PostgreSQL
“.grd” Imagem matricial binária (no formato NetCDF)
utilizado pelo GEBCO.
QGIS
“.tif” Imagem matricial binária. Pode conter
informação de georeferenciamento, passando a
ser chamada de GeoTiff.
QGIS, OpenJump Pirol
“.hdf” Imagem matricial binária. A implementação atual
(versão 1.3.1) da biblioteca GDAL possui
conflitos entre este formato e o formato NetCDF.
QGIS
49
ANEXO II – CONTEÚDO DO CD-ROM EM ANEXO
Arquivos geográficos Pasta que contém os arquivos “.shp” utilizados
Indice Arquivo “.shp” que gerou a tabela “indice”
world Arquivo “.shp” que gerou a tabela “worldpolitical”
Bibliotecas Pasta que contém os pacotes das bibliotecas utilizadas no programa.
documentação Pasta que contém todos os arquivos utilizados para a produção deste
documento
apresentacao Pasta que contém as diversas versões da apresentação feita durante a
defesa do projeto.
imagens Pasta que contém as imagens geradas.
openjump Pasta que contém os projetos do OpenJump Pirol que geraram
algumas das imagens da pasta “imagens”.
qgis Pasta que contém os projetos do QGIS que geraram algumas das
imagens da pasta “imagens”.
uml Pasta que contém o projeto do Umbrello que gerou o modelo de
classes.
ewsm_gui_cvs Pasta que contém o programa desenvolvido no projeto.
bin Pasta que contém os arquivos necessários para a execução.
html Pasta que contém a documentação gerada pelo DOXYGEN.
src Pasta que contém o código-fonte do programa EWSM.
GEBCO Pasta que contém o arquivo do GEBCO e seus documentos.
scripts Pasta que contém os scripts utilizados durante o projeto.
profic-corpo-0.16-
fim.pdf
Este relatório de desenvolvimento do projeto. Documento no formato
PDF.
As demais pastas e diretórios não são relevantes pois foram geradas somente para
utilização de alguns arquivos.
50
