Embed Size (px)
Citation preview
MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE GRADUAÇÃO EM ENGENHARIA CARTOGRÁFICA
AL DIEGO BENINCASA FERNANDES CAVALCANTI DE ALMEIDA
AL VANDRO FERNANDES MORGADO
IMPLEMENTAÇÃO DE UM ALGORITMO COMPUTACIONAL EM CÓDIGO
ABERTO PARA MANIPULAÇÃO DA BASE CARTOGRÁFICA NACIONAL
RIO DE JANEIRO
2007
2
INSTITUTO MILITAR DE ENGENHARIA
AL DIEGO BENINCASA FERNANDES CAVALCANTI DE ALMEIDA
AL VANDRO FERNANDES MORGADO
IMPLEMENTAÇÃO DE UM ALGORITMO COMPUTACIONAL EM CÓDIGO
ABERTO PARA MANIPULAÇÃO DA BASE CARTOGRÁFICA NACIONAL
Iniciação à Pesquisa apresentada 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: Cap QEM Ermírio de Siqueira Coutinho – M.C.
Rio de Janeiro
2007
3
INSTITUTO MILITAR DE ENGENHARIA
AL DIEGO BENINCASA FERNANDES CAVALCANTI DE ALMEIDA
AL VANDRO FERNANDES MORGADO
IMPLEMENTAÇÃO DE UM ALGORITMO COMPUTACIONAL EM CÓDIGO
ABERTO PARA MANIPULAÇÃO DA BASE CARTOGRÁFICA NACIONAL
Iniciação à Pesquisa apresentada 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: Cap QEM Ermírio de Siqueira Coutinho – M.C.
Aprovada em __ de _______ de 2007 pela seguinte Banca Examinadora:
______________________________________________________________________ Cap QEM Ermírio de Siqueira Coutinho – M.C.
______________________________________________________________________ Cap QEM Vagner Braga Nunes Coelho - M.C.
______________________________________________________________________ Cap QEM Marcos de Meneses Rocha – M.C.
______________________________________________________________________ 1º Ten QEM Ivanildo Barbosa – Eng. Cart.
Rio de Janeiro
2007
4
SUMÁRIO
LISTA DE SIGLAS E ABREVIATURAS .......................................................................... 06
LISTA DE ILUSTRAÇÕES ................................................................................................. 07
RESUMO ............................................................................................................................... 08
ABSTRACT ........................................................................................................................... 09
1 INTRODUÇÃO ......................................................................................................... 10
1.1 OBJETIVO .................................................................................................................. 11
1.2 MOTIVAÇÃO ............................................................................................................. 11
1.3 ESTRUTURAÇÃO DO TRABALHO ........................................................................ 12
2 FUNDAMENTAÇÃO TEÓRICA ............................................................................ 13
2.1 SISTEMAS DE INFORMAÇÕES GEOGRÁFICAS (SIG) ....................................... 13
2.1.1 INTRODUÇÃO ........................................................................................................... 13
2.1.2 CONCEITUAÇÃO ...................................................................................................... 14
2.1.3 DADOS EM SIG ......................................................................................................... 15
2.2 OPENGIS E ISO/TC 211 ............................................................................................ 15
2.3 TIPOS DE DADOS UTILIZADOS EM CARTOGRAFIA DIGITAL ....................... 16
2.4 TERRALIB .................................................................................................................. 16
2.5 TERRAVIEW .............................................................................................................. 18
2.6 O CAD E O MICROSTATION .................................................................................. 20
2.7 SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) .............................. 21
2.8 ESTRUTURA DE ARMAZENAMENTO DOS ARQUIVOS ................................... 22
2.8.1 ESTRUTURA DO ARQUIVO DESIGN FILE ........................................................... 22
2.8.2 ESTRUTURA DO ARQUIVO SHAPEFILE .............................................................. 24
2.9 BIBLIOTECAS GDAL/OGR DE LEITURA E ESCRITA DE ARQUIVOS DESIGN
FILE E SHAPEFILE ............................................................................................................... 26
3 EQUIPAMENTOS E MÉTODOS UTILIZADOS NA PESQUISA ..................... 27
5
4 DESENVOLVIMENTO ............................................................................................ 28
4.1 REDIRECIONAMENTO DO OBJETIVO ................................................................. 28
4.2 LEITURA DOS DIVERSOS TIPOS DE ARQUIVO PELA OGR ............................ 29
4.2.1 LEITURA DO ARQUIVO DESIGN FILE ATRAVÉS DA OGR .............................. 29
4.2.2 LEITURA DO ARQUIVO SHAPEFILE POR MEIO DA OGR ................................ 30
4.3 CÓDIGO EXISTENTE DE CONVERSÃO DO DESIGN FILE PARA
SHAPEFILE ............................................................................................................................ 31
5 ANÁLISE DOS RESULTADOS .............................................................................. 35
6 CONCLUSÕES .......................................................................................................... 37
7 SUGESTÕES PARA TRABALHOS FUTUROS ................................................... 38
8 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 39
ANEXO I – CÓDIGO-FONTE DO PROGRAMA DGNTOSHP ..................................... 41
ANEXO II – CÓDIGO-FONTE DO PROGRAMA DGNTOPG ...................................... 46
6
LISTA DE SIGLAS E ABREVIATURAS
BD Banco de Dados
BDG Banco de Dados Geográficos
C2 Sistema de Comando e Controle
DCT Departamento de Ciência e Tecnologia
DGN Design File
DPI/INPE Divisão de Processamento de Imagens do Instituto Nacional de Pesquisas
Espaciais
DSG Diretoria de Serviço Geográfico
EB Exército Brasileiro
ESRI Environmental Systems Research Institute
Funcate Fundação de Ciência, Aplicações e Tecnologia Espaciais
GC2 Grupo de Comando e Controle
GDAL Geospatial Data Abstraction Library
GIS Geographic Information Systems
GRASS Geographic Resources Analysis Support System
IBGE Instituto Brasileiro de Geografia e Estatística
IME Instituto Militar de Engenharia
ISFF Intergraph’s Standard File Formats
LBS Location Based Services
OGC Open Geospatial Consortium
PBCT Plano Básico de Ciência e Tecnologia
PUC-RIO Pontifícia Universidade Católica do Rio de Janeiro
QGIS Quantum GIS
SGBD Sistema de Gerenciamento de Bancos de Dados
SIG Sistema de Informações Geográficas
SQL Structured Query Language
TBCD Tabela da Base Cartográfica Digital
Tecgraf Grupo de Tecnologia em Computação Gráfica da PUC-RIO
7
LISTA DE ILUSTRAÇÕES
Fig. 2.1 Ambiente gráfico do TerraView 3.0.3 para Linux, em execução .................... 19
Fig. 2.2 Ambiente gráfico do MicroStation SE (Windows XP) .................................... 21
Fig. 5.1 Ambiente gráfico do Quantum GIS 0.8.0 para Linux ...................................... 35
8
RESUMO
Este trabalho tem por finalidade pesquisar uma possível implementação de uma alternativa ao uso de programas licenciados para a leitura de arquivos .DGN, nativo do programa MicroStation, proprietário da Bentley, no qual encontra-se codificado quase a totalidade do mapeamento sistemático brasileiro. O objetivo é realizar a exportação dos dados vetoriais armazenados neste arquivo para um formato de arquivo aberto e livre, possível de ser lido em plataformas SIG gratuitas. Tal pesquisa está incluída num contexto de trabalhos realizados pelo Grupo de Comando e Controle (GC2) do Departamento de Ciência e Tecnologia (DCT) do Exército Brasileiro.
9
ABSTRACT
This research has the main purpose of looking forward for some possible way of estabilishing an alternative to the use of licensed softwares to read .DGN files, Bentley MicroStation’s native file format, in wich is coded almost all the systematic mapping of the Brazilian territory. The main objective is to exportate data stored in those files to some open- -source, free file format, readable in open-source GIS platforms. This research is part of a context of works realized by the Grupo de Comando e Controle (GC2) of Departamento de Ciência e Tecnologia (DCT) of Brazilian Army.
10
1 INTRODUÇÃO
O Departamento de Ciência e Tecnologia (DCT), órgão de direção setorial do Exército
Brasileiro (EB), é uma instituição que tem por objetivos principais desenvolver e apoiar
projetos de aprimoramento científico-tecnológico do EB, além de promover a formação de
recursos humanos capazes de realizar tal tarefa. Dentro deste contexto, e tendo em vista a
situação econômica do país, que não permite grandes gastos, o DCT, por meio do Plano
Básico de Ciência e Tecnologia (PBCT), deu início a onze projetos tecnológicos,
denominados grupos finalísticos, onde cada um tem uma missão bem definida, visando obter
ao seu final um produto de emprego militar considerado prioritário pelo Exército.
O Grupo de Comando e Controle (GC2) é um dos grupos finalísticos, tendo por
finalidade unir esforços empregados até então em projetos que estavam sendo desenvolvidos
de modo paralelo, adotando a filosofia de software livre para suas tarefas (o que diminui as
despesas de projeto). Tal medida trará grande economia para a Força Terrestre, pois não será
mais necessário o pagamento de licenças de uso de produtos e softwares desenvolvidos por
empresas privadas, além de passar à instituição o controle não só dos dados, como também da
manipulação dos mesmos, o que significa a independência total de outras instituições no que
diz respeito à esta manipulação.
O projeto do Sistema de Comando e Controle (C2) envolve atividades de
desenvolvimento em algumas áreas distintas do conhecimento como, por exemplo, Sistemas
de Comunicações e desenvolvimento de equipamentos, dentre outros. Dentre essas áreas, uma
das de maior importância é a de Sistemas de Informações Geográficas (SIG), que permite
visualização e análises espaciais sobre o terreno onde se desenvolvem as operações que serão
acompanhadas pelo sistema de C2. Sendo assim, foi criado um subgrupo de desenvolvimento
de SIG no âmbito do GC2. Esse grupo visa desenvolver um SIG para uso não só pelo C2,
como também por outros órgãos da Força Terrestre, empregando a filosofia de software livre.
A adoção de tal filosofia objetiva solucionar um problema atualmente enfrentado pelos órgãos
responsáveis pelo mapeamento sistemático do território brasileiro (a Diretoria de Serviço
Geográfico do Exército – DSG, e o Instituto Brasileiro de Geografia e Estatística – IBGE) que
é a dependência de aplicativos proprietários para visualização, geração e atualização de dados.
Atualmente, quase a totalidade do mapeamento digital brasileiro encontra-se feito por um
aplicativo proprietário, o Bentley® MicroStation. Desta forma, todo e qualquer tipo de uso
11
dos arquivos digitais requer uma licença do produtor do software, o que demanda um alto
custo e a dependência tecnológica. Além disso, o uso de programas de código fechado limita
o uso destas plataformas em casos muito específicos, pois os recursos disponíveis em cada
software são pré-estabelecidos pelo fabricante, e a incorporação de novas ferramentas
depende da disponibilidade técnica e financeira deste, bem como das limitações de suas
linguagens de extensão.
1.1 OBJETIVO
Como a maior parte do mapeamento sistemático do Brasil foi feito com uso de um
aplicativo comercial, os dados encontram-se codificados em arquivos de formato proprietário,
dificultando ou até mesmo impedindo seu correto uso em outras plataformas. Tendo-se isto,
uma das atividades previstas pelo subgrupo de SIG é a de utilizar um algoritmo que permita
decodificar esse arquivo proprietário, elucidando como o mesmo se encontra estruturado,
permitindo assim que os dados do mapeamento sistemático, pertencentes à Nação Brasileira e
não às empresas que desenvolveram os aplicativos nos quais eles foram produzidos, possam
ser utilizados de forma independente dessas plataformas. Um desses usos seria a sua edição
ou visualização por aplicativos de distribuição livre e código aberto (open-source), permitindo
assim a democratização do acesso a dados geográficos e a ampliação das possibilidades
relativas à sua manipulação.
No intuito de cooperar com os projetos existentes na área de Comando e Controle,
procurar-se-á, com este trabalho de pesquisa, novas formas de acesso às informações contidas
nos arquivos de formato proprietário nos quais encontram-se os dados do mapeamento
sistemático brasileiro, formas estas de livre distribuição (gratuitas) e de código aberto, o que,
por conseqüência, ainda contribui com a isenção da necessidade de uso de softwares
licenciados para manipulação destes mesmos dados, diminuindo os custos de trabalho.
1.2 MOTIVAÇÃO
O Exército Brasileiro, como já mencionado, possui diversos trabalhos na área de
Comando e Controle. Tais projetos têm, por meta principal, reduzir custos excessivos, dada a
situação econômica que o Brasil vive. Assim, visando colaborar para o desenvolvimento do
país de forma ativa, bem como permitir o total domínio sobre o uso e manipulação dos dados,
12
em meio digital, do mapeamento sistemático brasileiro, deu-se início a este trabalho de
pesquisa, que está intimamente ligado às diretrizes estabelecidas pelas pesquisas em
andamento já existentes na área de Comando e Controle.
1.3 ESTRUTURAÇÃO DO TRABALHO
O presente trabalho está estruturado em capítulos, da forma como segue detalhado.
O Capítulo 2 trata da fundamentação teórica, onde os conceitos fundamentais ao
desenvolvimento do trabalho são apresentados.
O Capítulo 3 apresenta os equipamentos e métodos necessários à execução do trabalho.
O Capítulo 4 apresenta o desenvolvimento do trabalho propriamente dito.
O Capítulo 5 trata da análise dos resultados obtidos com a conversão.
O Capítulo 6 dispõe sobre as conclusões que se pôde obter após a realização do trabalho.
O Capítulo 7 apresenta sugestões para trabalhos futuros que possam, utilizando os
resultados obtidos neste trabalho, dar continuidade ao mesmo.
O Capítulo 8 lista as referências bibliográficas que auxiliaram na realização deste
trabalho.
13
2 FUNDAMENTAÇÃO TEÓRICA
2.1 SISTEMAS DE INFORMAÇÕES GEOGRÁFICAS (SIG)
2.1.1 INTRODUÇÃO
Os primeiros estudos e conseqüentes SIG são da década de 60, e apesar de não receberem
esta denominação à época, levavam o conceito nos mais diversos campos de aplicações.
Sistemas como Computer-Aided Drafting and Design (CADD), Land Information System
(LIS), Multipurpose Cadastre e Automed Mapping (AM)/ Facilities Management (FM), entre
outros, levavam em comum a habilidade de manipular informações de caráter geográfico.
Desde as décadas de 60, estudos sobre SIG foram desenvolvidos paralelamente a Cartografia
em países como Estados Unidos, Canadá e Inglaterra. Nas décadas de 70 e 80, houve um
avanço na área computacional, o que fez com que os custos na produção de memória e
hardware diminuíssem, alavancando o crescimento dos SIG. Nesta mesma época, foram
laçados equipamentos que se somaram ao SIG (tais como “plotters” vetoriais e monitores de
vídeo coloridos), o que pôde revelar o poder desta ferramenta. Já no inicio da década de 80, o
Sistema ArcInfo da Enviroment Systems Research Institute (ESRI) foi lançado, sendo um dos
primeiros softwares de SIG a possuir um sistema de gerenciamento de banco de dados, fato
este que representou um avanço importante na área de SIG.
2.1.2 CONCEITUAÇÃO
Existem diversas definições para SIG. Algumas delas serão abordadas por serem de
autores e/ou pesquisadores renomados em estudos referentes à esta tecnologia.
Um SIG é definido como “qualquer conjunto de procedimentos manuais ou baseados em
computador usados para armazenar e manipular dados geograficamente referenciados”
(ARONOFF, 1989).
Ainda como definição de SIG, tem-se a que segue.
14
Um arranjo de equipamento computacional, software, e dados geográficos que
as pessoas interagem para integrar, analisar, e visualizar os dados; identificar
relacionamentos, padrões e tendências; e encontrar soluções para problemas. O
sistema é projetado para capturar, armazenar, atualizar, manipular, analisar, e
apresentar a informação geográfica. Um SIG é tipicamente usado para representar
mapas como camadas de dados que podem ser estudadas e usadas para fazer
análises. (ESRI-GIS Dictionary, 2006)
MAGUIRE (1991) reconhece em um SIG, a “capacidade de apresentação cartográfica de
informações complexas, uma sofisticada base integrada de objetos espaciais e de seus
atributos ou dados, e um engenho analítico formado por um conjunto de procedimentos e
ferramentas para análise espacial”.
A informação se armazena e se usa em uma base de dados geográficos, que combina
dados geométricos, posicionais e temáticos. Cada tema de informação é representado por um
nível (chamado também de camada ou, mais comumente, layer), que nada mais é do que um
conjunto de objetos elementares de mesma natureza. Um nível reúne uma representação
cartográfica de objetos espaciais que está ligada a uma tabela de informações sobre estes
objetos. Num arquivo matricial (raster), as informações armazenadas são representadas
visualmente por uma matriz de pixels, e quando em um arquivo vetorial, por objetos como
pontos, linhas ou polígonos.
O SIG permite cruzar informações de uma base de dados de diferentes formas. Seja por
características geométricas e temáticas dos objetos, que permitem seleções de subconjuntos a
partir de atributos estatísticos, ou de seleções denominados espaciais, provenientes de
ferramentas gráficas.
2.1.3 DADOS EM SIG
A tecnologia dos SIG mais modernos é relativamente recente, surgindo no princípio dos
anos 80. Em sua primeira geração, estes sistemas estavam muito ligados à geração de projetos
independentes visando o cumprimento de tarefas específicas de empresas particulares, sendo
praticamente sistemas CAD com a capacidade de representar projeções cartográficas e
associar atributos a objetos espaciais. A segunda geração, desenvolvida na década de 90, foi
concebida para o uso cliente-servidor, implantados sobre Sistemas de Gerenciamento de
15
Banco de Dados (SGBD) para armazenamento de seus dados tabulares, complementada com
pacotes adicionais para o tratamento de imagens. São os sistemas mais utilizados hoje em dia.
Os Bancos de Dados Geográficos (BDG) apareceram como a terceira geração de SIG,
caracterizadas pela gestão de grandes bases de dados geográficas, onde tantos dados tabulares
(alfanuméricos) quanto geométricos são armazenados em SGBD, com acesso por meio de
redes locais e remotas, e com interfaces por meio da internet.
2.2 OPENGIS E ISO/TC 211
O Open Geospatial Consortium (OGC™) é uma organização sem fins lucrativos, criada
em 1994 e dedicada à criação de padrões para serviços baseados em localização (LBS –
Location Based Services) e para manipulação de dados geoespaciais. Foi fundado pelas mais
importantes empresas privadas produtoras de aplicativos de geoprocessamento, órgãos
governamentais e acadêmicos. Seu objetivo é a padronização de serviços e formatos para
intercâmbio de dados entre diferentes sistemas de geoprocessamento (SIG, sensoriamento
remoto, etc.), ou seja, visa permitir a interoperabilidade entre diferentes SIG.
Na busca por esta padronização, surge a especificação OpenGIS, que define a
representação de formas geométricas básicas e os principais métodos para acessá-las, criando
uma interface padrão para manipulação e intercâmbio de dados de SIG. “A especificação do
padrão é feita em dois níveis: Abstract Specifications e Implementation Specifications. “A
finalidade do primeiro é criar e documentar um modelo conceitual suficiente o bastante para
permitir a criação do segundo” (OGC, 1999). As Abstracts Specifications definem a forma de
simbolização e representação de feições, enquanto as Implementation Specifications regem o
modo com que estas representações serão realizadas em meio digital.
Além da especificação OpenGIS, a ISO também possui um comitê permanente para
especificações nas áreas de Informações Geográficas e Geomática: o ISO/TC 211 (Technical
Committee - Geographic Information/Geomatics), sendo que “o OGC está alinhado com o
ISO/TC 211. Essas organizações têm desenvolvido um acordo de cooperação para
harmonização de seus trabalhos mútuos e desenvolvimentos futuros” (BRODEUR et al,
2000).
16
2.3 TIPOS DE DADOS UTILIZADOS EM CARTOGRAFIA DIGITAL
Basicamente, há dois tipos de fontes de informação utilizados em um SIG: as fontes
matriciais (carta digitalizada em scanner, imagens de sensores orbitais, fotografias aéreas,
imageamento radar, etc.) e as fontes vetoriais (cartas digitalizadas em mesa digitalizadora, por
exemplo).
As fontes matriciais de dados cartográficos constituem-se de dados digitalizados por
simples cópia (scanner) ou de imagens obtidas diretamente do terreno, com ou sem
processamento. Estas imagens são representadas, em ambiente computacional, por uma
matriz de pontos (pixels), onde a cada um deles é atribuído um valor numérico relativo a uma
escala de cores (RGB, CMY, YUV, etc.) ou a uma escala radiométrica (tons de cinza). Tais
dados são de uso mais trabalhoso em SIG, pois não tratam isoladamente as feições do terreno
e, por isso, não favorecem a seleção de áreas específicas para conexão a um banco de dados,
visto que imagens matriciais (mais comumente conhecidas como imagens raster) permitem
apenas a seleção pixel a pixel. A maior dificuldade na caracterização de uma feição
armazenada como raster é a definição dos seus limites, não existindo comercialmente ainda
um software que execute esta tarefa de modo preciso.
Já as fontes vetoriais de dados cartográficos são aquelas onde as feições do terreno são
representadas computacionalmente por vetores. Através da digitalização de cartas impressas,
por exemplo, pode-se armazenar pontos, linhas e polígonos representativos de feições no
terreno. Desta forma, o acesso a informações geográficas contidas em um banco de dados
torna-se facilitado, pois a seleção de linhas e de polígonos, em computador, é mais facilmente
realizada. Para efeito de comparação, pode-se dizer que a seleção de apenas um objeto (forma
geométrica definida por vetores), de certa forma, significaria a seleção de um grande número
de pixels, o que demonstra a maior facilidade de manipulação de dados vetoriais.
2.4 TERRALIB
Atualmente, as grandes aplicações SIG são desenvolvidas por empresas privadas. Desta
forma, todo tipo de dado inserido em um banco de dados geográficos está subjugado às
rotinas de armazenamento e leitura dos desenvolvedores destas aplicações, de tal forma que
não se pode ter a posse total e irrestrita dos dados efetivamente usados no SIG. Ou seja,
17
apesar de se possuir a informação, a leitura da mesma só é possível adquirindo-se uma licença
do software onde foi desenvolvido.
Para a utilização de um SIG usando plataformas proprietárias, torna-se necessário a
aquisição de licenças de uso dos aplicativos, fato que, via de regra, gera grandes custos, dado
tratarem-se de produtos de alta tecnologia e de aplicação muito específica, além da pequena
concorrência nesses nichos de mercado. O fator custo tem sido o principal motivador da nova
tendência mundial de uso do software livre, ou seja, de programas computacionais que
permitem acesso ao seu código-fonte e que podem ser usados e copiados livremente.
Seguindo a vertente de uso do software livre, foi desenvolvido pela DPI (Divisão de
Processamento de Imagens) no INPE (Instituto Nacional de Pesquisas Espaciais), pela
Tecgraf (Grupo de Tecnologia em Computação Gráfica da Pontifícia Universidade Católica
do Rio de Janeiro – PUC-RIO) e pela Funcate (Fundação de Ciência, Aplicações e Tecnologia
Espaciais), um conjunto de bibliotecas e rotinas de manipulação de Banco de Dados
Geográficos (BDG) e SIG, o TerraLib, distribuído como software livre e com código aberto,
ou seja, disponível para qualquer interessado em uma solução gratuita para SIG e com
interesse em desenvolver novas ferramentas de manipulação de dados geográficos. Tal projeto
está sendo amplamente desenvolvido, e constantes melhorias são realizadas com o objetivo de
se criar uma plataforma de SIG totalmente independente dos formatos proprietários e com os
principais métodos e funcionalidades já disponíveis em plataformas proprietárias consagradas
de SIG, como o ArcGIS e de CAD, como o MicroStation, por exemplo.
A grande motivação por trás do projeto de desenvolvimento do TerraLib é o fato de não
existir atualmente uma ferramenta versátil de SIG, ou seja, adaptável às novas tecnologias que
surgem diariamente. Com plataformas proprietárias, o usuário fica dependente da vontade do
fabricante de atualizar seus softwares, e nem sempre esta atualização vai de encontro às suas
necessidades. Com o projeto de código aberto do TerraLib, torna-se possível o
desenvolvimento de rotinas particulares, de forma a atender a um dado projeto, além de
permitir uma atualização e melhoria nos códigos-fonte de forma mais rápida, pois não há
custos adicionais de manutenção muito elevados e toda a comunidade de usuários pode
participar. Isto porque qualquer pessoa pode fazer esta melhoria a qualquer tempo, sem ficar
presa às limitações de uma empresa privada, além do fato de que estas alterações podem ser
submetidas para apreciação dos responsáveis pela distribuição do aplicativo de código aberto.
Outra idéia básica por trás do TerraLib é a atual tendência no avanço das tecnologias de
Sistemas de Gerenciamento de Bancos de Dados (SGBD) capazes de manipular dados
18
espaciais. Em outras palavras, os novos e futuros formatos de bancos de dados permitem não
apenas o armazenamento de dados tabulares, relativos às feições ou geometrias (população,
número de empresas privadas, tipo e cor de linha utilizado para uma certa representação, etc.),
como também da própria representação geométrica dos mesmos. Este novo paradigma em
SIG permite o armazenamento conjunto de todos os dados relativos a cada feição,
simplificando a modelagem do sistema e tornando-o, muitas vezes, mais eficiente.
O TerraLib é uma biblioteca de funções escrita em C++, uma conhecida e amplamente
utilizada linguagem de programação orientada a objetos. Seu projeto foi desenvolvido de
modo a permitir sua compilação multiplataforma – Windows e Linux –, e permite ainda o
desenvolvimento de diversas aplicações de SIG distintas baseadas em suas funções
Uma das características de maior destaque da TerraLib é a sua “capacidade de se conectar
à sistemas de gerenciamento de banco de dados objeto-relacionais (SGBD-OR) para
armazenar dados geográficos, tanto sua componente descritiva quanto sua componente
espacial” (CASANOVA, et al, 2005). Como a TerraLib está na camada existente entre o
banco de dados e o aplicativo final e é desenvolvido em código aberto, ele torna possível o
compartilhamento de dados existentes em diferentes bancos de dados.
2.5 TERRAVIEW
Dentre as plataformas de visualização e manipulação de dados geográficos baseados na
biblioteca TerraLib, merece destaque a TerraView. Desenvolvida pelo DPI/INPE, o
TerraView é um SIG capaz de visualizar dados geográficos e fazer consultas e análises sobre
estes dados, que estão armazenados em bancos de dados geridos por um SGBD, tais como
Oracle, MySQL, PostgreSQL e Access, servindo como prova de conceito da TerraLib e como
exemplo de aplicativo desenvolvido sobre ela.
O TerraView possui, entre outros recursos, a capacidade de importar arquivos vetoriais
de algumas outras plataformas SIG, a saber:
• MID/MIF – Formato de intercâmbio do software MAPInfo, constituído por dois
arquivos. O arquivo .mid contém os atributos, enquanto o arquivo .mif contém as
geometrias do mapa.
• Shapefile – Formato de intercâmbio de produtos da ESRI. É constituído por três
arquivos de mesmo nome, mas com extensões .shp (shapefile – armazena as
19
geometrias referentes ao terreno), .dbf (database file – contém o banco de dados, ou
seja, contém os atributos das geometrias armazenadas no .shp) e .shx (shapefile index
– contém uma lista de índices relativos ao .shp, permitindo a correta conexão entre o
banco de dados e as geometrias correspondentes).
• Tab/Geo – Formato de exportação de dados do software SPRING (Sistema de
Processamento de Informações Georeferenciadas), desenvolvido pelo INPE e
gratuito. É formado por dois arquivos de mesmo nome, porém com extensões .geo e
.tab, um contendo as geometrias e outro contendo o banco de dados acerca dos
objetos armazenados.
• BNA (Boundary File Format) – Formato de exportação de arquivo usado no software
Atlas GIS, da ESRI. Possui apenas três tipos de dados: ponto, linha e/ou área.
Uma vez importados os dados para dentro do TerraView, uma série de consultas e
análises pode ser realizada sobre o mapa, como pode ser parcialmente visto na Fig. 2.1. Na
verdade a importação consiste da conversão dos arquivos originais para seu subseqüente
armazenamento em banco de dados. Esse banco de dados segue um esquema de
armazenamento próprio conhecido como Modelo de Dados TerraLib. Tais procedimentos
estão bem detalhados no tutorial do software, disponível no site do programa em
www.dpi.inpe.br/terraview .
Fig. 2.1 – Ambiente gráfico do TerraView 3.0.3 para Linux, em execução.
20
2.6 CAD (COMPUTER-AIDED DESIGN) E O MICROSTATION
Nos diversos ramos da engenharia, é comum a necessidade de se fazer desenhos e
modelagens digitais de formas e de objetos reais. Na construção civil, por exemplo, é de
grande utilidade a criação de plantas e de maquetes digitais de edificações, pois isto permite
que se faça medições de modo mais rápido e mais preciso antes mesmo de se conceber
fisicamente a construção. Em Cartografia, usa-se, por exemplo, muito os recursos
computacionais para se criar modelos digitais de relevo para fins de estudo da superfície da
Terra, sem a necessidade da efetiva presença no local de estudo.
Para que tais concepções bidimensionais e tridimensionais pudessem ser realizadas em
ambiente computacional, foi desenvolvido o CAD – Computer Aided Design, ou Projeto
Auxiliado por Computador –, aplicativo que visa facilitar o projeto e o desenho técnicos. Uma
plataforma CAD consiste de várias ferramentas capazes de desenhar e modificar entidades
geométricas planas – ponto, linha e área – e figuras tridimensionais. Além disso, pode dispor
de ferramentas de relacionamento entre essas entidades ou essas figuras 3D, tais como:
arredondar junção de linhas, subtrair formas de figuras 3D e obter uma terceira, etc..
As plataformas CAD, apesar de serem utilizadas por um grupo muito grande de usuários,
são sistemas computacionais caros e altamente especializados, que costumam também exigir
maiores recursos computacionais. Além disso, a falta de software livre na área de CAD tem
sido um dos maiores empecilhos a uma maior popularização desta ferramenta, o que restringe
ainda mais a utilização de sistemas CAD a um grupo cada vez menor de pessoas.
Na área da Engenharia Cartográfica, para o mapeamento sistemático do território
nacional realizado pelo IBGE e pela DSG tem-se utilizado o software MicroStation, da
Intergraph®. Originalmente criado pela Bentley Systems em 1980, esse software, mostrado
na Fig. 2.2, foi o utilizado na digitalização e produção de cartas do território brasileiro. Assim,
grande parte da base vetorial cartográfica do Brasil se encontra arquivada no formato .DGN
(“DesiGN file”), que é um formato proprietário da Intergraph® e que necessita da aquisição
de uma licença para sua manipulação (edição e visualização dos dados no programa original).
O MicroStation, apesar de salvar seus arquivos no formato .DGN, permite ainda a leitura
e a importação de outros formatos de arquivos vetoriais, como o .DXF e o .DWG (do
Autodesk® AutoCAD). Permite ainda que se dê uma saída em diversos formatos de natureza
diferente, tanto em forma de imagem (arquivo matricial) como em forma de animação.
21
Fig. 2.2 – Ambiente gráfico do MicroStation SE (Windows XP).
2.7 SISTEMA DE GERENCIAMENTO DE BANCOS DE DADOS (SGBD)
Em geral, um banco de dados (BD) pode ser visto de diferentes formas. De um ponto de
vista sistemático, pode ser considerado como um conjunto de dados que possuem algum tipo
de relacionamento. Já do ponto de vista de gerenciamento de informações, pode ser
considerado como um conjunto de dados que modelam uma certa atividade empresarial, ou
que atendem a um determinado fim.
Mesmo sendo dois pontos de vista distintos, as duas interpretações possuem
características em comum, tais como:
− Funções para descrever, pesquisar e atualizar o BD.
− Interfaces que facilitam o acesso às informações do BD e que permitem a
independência do tipo de equipamento utilizado.
− Melhor entendimento das propriedades estáticas e dinâmicas dos dados armazenados.
22
Tendo isso em mente, foi criado o conceito de SGBD. Um SGBD, como o próprio nome
diz, nada mais é do que o sistema que gerencia os dados de um BD, ou seja, é o responsável
por oferecer descrição e manipulação facilitada dos dados armazenados, interfaces de acesso
aos dados totalmente independente da estrutura computacional utilizada e um conjunto de
ferramentas que provêem um bom entendimento da aplicação computacional de interesse
modelada.
Para ser considerado um SGBD, o sistema deve ser capaz de atender a alguns objetivos,
tais como: separação dos processos de descrição e de manipulação dos dados, processamento
eficiente das operações de BD, facilitação das atividades de administração e controle dos
dados, mínima redundância e mínimo espaço de armazenamento, possibilidade de
compartilhamento dos dados, garantia de segurança e integridade das informações, etc.
Atualmente, existem diversos SGBD disponíveis. Dentre os mais utilizados, pode-se citar
o MySQL, o PostgreSQL, o Oracle, o ACCESS e o dBASE.
Dentre os SGBD, destaca-se o PostgreSQL, pois este está totalmente capacitado para se
adaptar às diretrizes estabelecidas pelo OGC. Isto porque já existe uma extensão desenvolvida
para o mesmo totalmente de acordo com as especificações OpenGIS. Esta extensão,
denominada PostGIS, habilita o PostgreSQL a trabalhar com o armazenamento de geometrias,
além de possuir funções de análise e processamento dos dados armazenados, transformando o
BD em mais uma fonte de armazenamento de dados para SIG e permitindo o uso dos mesmos
em diferentes aplicativos de SIG.
2.8 ESTRUTURA DE ARMAZENAMENTO DOS ARQUIVOS
2.8.1 ESTRUTURA DO ARQUIVO DESIGN FILE (.DGN)
O formato de arquivo .DGN é um dos formatos definidos pela ISFF (Intergraph Standard
File Formats), criada nos anos 80 pela Intergraph, antiga proprietária do sistema CAD
MicroStation. A ISFF compreende os tipos de arquivos comuns ao MicroStation e à
Intergraph's Interactive Graphics Design System (IGDS). A documentação da ISFF está
disponível ao público no Guia do Usuário do MicroStation (além de disponível em diversas
fontes na internet, como em http://dgnlib.maptools.org/dl/ref18.pdf), o que possibilita o
23
desenvolvimento de aplicações que lêem e escrevem nos tipos de arquivos definidos na ISFF
sem a necessidade de se obter uma licença para isso.
Em geral, os arquivos .DGN são arquivos binários com registros de tamanho variável, o
que por conseqüência gera arquivos de tamanho também variável. Dentro deste arquivo, há
alguns tipos de registros, alguns destes de existência e tamanho obrigatórios. Tais registros
são:
− Design File Header (cabeçalho do arquivo)
− Informações de configuração do arquivo
− Elementos gráficos
− Dados não gráficos.
Arquivos .DGN permitem dois tipos básicos de elementos gráficos: os primitivos e os
complexos. Os elementos primitivos são as linhas, as polilinhas, as curvas fechadas, as
elipses, os arcos, os textos e os cones. Já os elementos complexos são aqueles construídos por
uma combinação ou união de elementos primitivos distintos, criando uma forma única com
tipo não definido. A este último grupo de elementos inclui-se as superfícies, os sólidos e as
splines.
Os registros dos elementos complexos possuem constituição diferenciada. O seu
cabeçalho possui informação sobre cada um de seus constituintes, o que inclui o número total
de elementos formadores da geometria e alguns dados acerca do tamanho dos dados destes.
Outro recurso do arquivo .DGN é a possibilidade de separação das informações em
diferentes camadas (ou layers, como são mais chamadas), o que facilita a visualização, o
estudo e a classificação de dados digitalizados. Tal recurso é amplamente utilizado nos
processos de construção da base cartográfica nacional pela DSG, que inclusive estabelece
(por meio do manual T34-700 – Manual Técnico de Convenções Cartográficas, e da TBCD –
Tabela da Base Cartográfica Digital) a regra geral de classificação dos dados em diferentes
camadas.
De uma forma geral, o formato .DGN é bastante versátil, pois permite o armazenamento
de diversos tipos de geometrias, desde as mais simples até formas bastante complexas, e sua
separação em diferentes layers. Além disso, permite a personalização de diversas
características das geometrias, como tipo, cor e peso das linhas, por exemplo. Tais
funcionalidades fizeram do MicroStation o programa mais utilizado na vetorização de cartas
pelos órgãos nacionais da Cartografia. Contudo, apesar das facilidades, seu uso gera custos,
24
pois se trata de um programa proprietário e que exige o pagamento de uma licença de uso
para edição dos dados.
Diversas outras características peculiares definem o tipo de arquivo .DGN. Todas estas
características estão mais detalhadamente descritas no Guia do Usuário do MicroStation,
disponível, como já mencionado anteriormente, na internet, em
http://dgnlib.maptools.org/dl/ref18.pdf .
2.8.2 ESTRUTURA DO ARQUIVO SHAPEFILE
O formato de arquivo shapefile foi desenvolvido pela ESRI. É reconhecido por inúmeras
plataformas de SIG e outros programas de desenho vetorial, pois a própria ESRI disponibiliza
na internet um manual com toda a estrutura do arquivo shapefile, o que permite a criação de
aplicações computacionais capazes de ler e escrever arquivos deste tipo.
O formato shapefile é consituído, na verdade, por três arquivos distintos, cada um sendo
responsável pelo armazenamento de parte da informação.
a) Arquivo principal – .shp
Este arquivo é responsável por armazenar todo o conjunto de geometrias. É um arquivo
binário e suporta três tipos básicos de formas geométricas: ponto, linha e área.
Por ser um arquivo binário, é composto por um conjunto de registros, cada um contendo
um cabeçalho, que contém o número do registro e o tamanho computacional do mesmo, e a
relação dos vértices formadores deste elemento.
O arquivo .shp possui um cabeçalho de tamanho fixo, responsável por armazenar
informações gerais a respeito de si próprio (tamanho do arquivo, bounding box, tipo de
geometria armazenada, versão e código do arquivo).
Uma restrição que ainda existe no shapefile é a de que um arquivo .shp só pode conter
geometrias do mesmo tipo. Desta forma, não é possível, por exemplo, armazenar num mesmo
.shp formas do tipo linha e polígono, sendo necessário, se for o caso, a separação destes tipos
de dados em arquivos diferentes.
Outra impossibilidade do shapefile é a de não ser possível a separação dos dados em
diferentes camadas (layers), tal qual o design file da Bentley. Contudo, se for o caso de ser
necessário classificar os dados em diferentes subgrupos, há alternativas, como a separação dos
25
mesmos em diferentes arquivos .shp e com nomes de arquivo facilmente reconhecíveis.
Assim, pode-se importar tais arquivos com facilidade para a plataforma SIG a ser utilizada.
Quanto à codificação de bytes nos cabeçalhos existentes no arquivo .shp, toda ela está
mais detalhadamente descrita no manual da ESRI, não cabendo aqui maiores detalhes por não
ser objeto direto de estudo deste trabalho de pesquisa.
b) Arquivo de banco de dados (.dbf)
Este arquivo é responsável por guardar os atributos correspondentes às geometrias
armazenadas no .shp. É um banco de dados dBASE, no qual a tabela de atributos está
estruturada de forma a conter um registro por atributo. A correta relação entre o atributo e a
geometria está garantida pelo fato de a ordem dos registros de atributos no banco de dados ser
a mesma ordem dos registros das geometrias no arquivo .shp.
Qualquer tipo de atributo desejado pode ser armazenado no arquivo .dbf, desde que seja
obedecida a ordem de armazenamento já descrita anteriormente. Para a construção e
manipulação deste arquivo, existem inúmeras aplicações disponíveis no mercado, dado que
este formato de arquivo é bem conhecido e antigo, o que facilita o seu manuseio. E
exatamente por isso, foi o tipo de banco de dados primeiramente selecionado pela ESRI para
armazenar os atributos, pois facilita a sua leitura em aplicações que irão trabalhar com o tipo
shapefile.
c) Arquivo de índices (.shx)
Este arquivo tem como finalidade principal permitir o acesso direto às informações de
uma dada geometria armazenada no .shp (e seus correspondentes atributos armazenados no
.dbf), sem a necessidade de se percorrer toda a lista de registros deste arquivo. Tal
procedimento agiliza a recuperação de informações, o que pode ser de grande utilidade, caso
a otimização do tempo gasto no processamento destas informações seja um ponto importante
no desenvolvimento de um dado projeto ou de um estudo.
Tal qual os outros dois tipos de arquivo já descritos, o arquivo .shx também é binário.
Possui um cabeçalho semelhante ao do .shp, e cada registro armazena informações
relacionadas ao tamanho dos registros guardados no .shp. São tais informações que permitem
o acesso direto ao registro desejado, quando da consulta por dados ou atributos relativos a
uma dada geometria de interesse.
26
2.9 BIBLIOTECAS GDAL/OGR DE LEITURA E ESCRITA DE ARQUIVOS DESIGN
FILE E SHAPEFILE
A GDAL (Geospatial Data Abstraction Library) é uma biblioteca computacional gratuita
e em código aberto para leitura e conversão de arquivos do tipo raster. Suporta uma vasta
gama de tipos de arquivo comuns nas áreas de geociências, e por isso é utilizada na maioria
das aplicações nesta área. Para fins de exemplificação, alguns dos aplicativos mais conhecidos
que a utilizam são: ESRI® ArcGIS 9.2+, Google® Earth, GRASS, UMN MapServer,
OpenEV e Quantus GIS (QGIS).
Paralelamente ao projeto da GDAL, vem se desenvolvendo um outro projeto que visa
criar funcionalidades semelhantes à da GDAL, porém para dados vetoriais. Este projeto foi
chamado de OGR, cuja sigla não tem significado definido (a explicação de sua origem leva
em consideração informações que exigem a aquisição de maiores conhecimentos, e por tal
fato não ser relevante para a execução deste trabalho, foi deixado em segundo plano). Tal
projeto também se constitui de um conjunto de bibliotecas capazes de interpretar diversos
tipos de arquivos vetoriais comumente empregados em SIG, além de prover ferramentas de
manipulação dos mesmos e de conversão entre formatos reconhecidos pela OGR.
Entre os formatos vetoriais de interesse deste trabalho que a OGR consegue reconhecer,
encontram-se o shapefile da ESRI, o design file V7 da Intergraph (como estabelecido na
ISFF) e o banco de dados PostgreSQL com extensão PostGIS (como estabelecido na OGC).
Contudo, apesar de ser possível ler estes arquivos e converter entre um e outro formato, a
biblioteca possui limitações, de forma que estas precisam ser avaliadas e contornadas para que
se atinja o objetivo deste trabalho de pesquisa.
O principal motivo da utilização da GDAL/OGR neste trabalho é o fato de ela conseguir
ler o arquivo .DGN, e devido à sua capacidade de conversão para outros formatos, pode-se
fazer a tradução deste formato para outro qualquer suportado pela biblioteca. Para este
trabalho, contudo, será estudado o método de conversão para shapefile e para
PostgreSQL/PostGIS, bem como suas limitações, seus sucessos e suas falhas. Mais
informações sobre o motivo do estudo de ambos os tipos de conversão serão detalhados mais
adiante.
27
3 EQUIPAMENTOS E MÉTODOS UTILIZADOS NA PESQUISA
Para a execução dos estudos acerca da implementação de um código computacional que
cumpra o objetivo estabelecido neste trabalho, alguns recursos se tornam necessários,
principalmente – mas não exclusivamente – recursos computacionais.
Sabe-se que, no intuito de diminuir gastos excessivos com licenças de programas, e
aliando-se à atual linha das pesquisas já existentes na área de SIG, o ideal, para conclusão do
trabalho, é obter bibliotecas e softwares para o sistema operacional Linux, pois todos os
recursos necessários estão disponíveis para esta plataforma. Desta forma, procurou-se utilizar
somente bibliotecas computacionais e softwares livres, atendendo aos objetivos de diminuição
de custos operacionais e acessibilidade irrestrita aos dados geográficos.
Quanto à parte computacional, os principais recursos, todos para o sistema Linux (a
menos que estejam discriminados), foram:
− Computadores com sistemas operacionais Linux (Kurumin 7.0), para execução dos
testes e elaboração de relatórios.
− Software para desenvolvimento de aplicações computacionais em linguagem C++ –
KDevelop 3.4.1.
− Software licenciado para criação/edição/visualização de arquivos .DGN – Bentley®
MicroStation 95 (Microsoft® Windows), disponível na Seção de Engenharia
Cartográfica do Instituto Militar de Engenharia.
− Plataforma SIG gratuita e em código aberto para visualização dos arquivos
convertidos – TerraView 3.1.4, Quantum GIS 0.8.0.
− Bibliotecas gratuitas e em código aberto para leitura/escrita de arquivos shapefile e
.DGN e para conversão entre estes formatos – GDAL 1.4.0, TerraLib 3.1.4.
− SGBD para Linux – PostgreSQL 8.2.4
− Cartas vetorizadas armazenadas em formato .DGN para serem utilizadas nos testes a
serem implementados.
28
4 DESENVOLVIMENTO
4.1 REDIRECIONAMENTO DO OBJETIVO
O formato shapefile foi primeiramente selecionado para a conversão por ser um tipo de
arquivo reconhecido por inúmeras plataformas SIG, dentre elas o TerraView, utilizado no
Exército Brasileiro como base para o aplicativo de SIG que está sendo desenvolvido pelo
GC2/PBCT. Isto proporcionaria uma facilidade de adaptação dos diversos órgãos do Exército
que se utilizam de SIG à uma possível nova aplicação livre para leitura de arquivos .DGN.
Entretanto, com a atual tendência de se estabelecer uma interoperabilidade entre
plataformas SIG, notadamente pelo crescimento e difusão do padrão OpenGIS, será realizado,
em contrapartida, a conversão do arquivo .DGN para um Banco de Dados Geográficos (BDG)
no formato PostgreSQL. Este tipo de banco de dados foi o selecionado por ser capaz de
atender à especificação OpenGIS e por ser reconhecido pela biblioteca OGR.
O redirecionamento do objetivo também levou em consideração a já existência de uma
rotina computacional, também baseada na OGR, para conversão entre .DGN e shapefile.
Assim, baseando-se no trabalho existente, procurou-se adaptá-lo às necessidades desta
pesquisa. Este método de trabalho também foi preferido pela exigüidade de tempo para
conclusão do mesmo, o que dificultou uma exploração mais ampla das possibilidades desta
rotina a ser desenvolvida.
Um fato que colaborou para a não utilização do TerraView foi detectado durante a fase de
análise dos resultados. Ao se abrir um banco de dados PostgreSQL/PostGIS no TerraView,
este automaticamente insere tabelas próprias dele no banco de dados, de forma que o acesso
ao mesmo fica restrito somente ao TerraView. Assim, o objetivo de se criar uma fonte de
dados multiplataforma foi perdido, pois o banco de dados PostGIS de antes passou a ser um
banco de dados TerraLib, reconhecível somente pela biblioteca TerraLib, restringindo seu
uso.
29
4.2 LEITURA DOS DIVERSOS TIPOS DE ARQUIVO PELA OGR
4.2.1 LEITURA DO ARQUIVO DESIGN FILE POR MEIO DA OGR
Sabe-se que a biblioteca OGR é capaz de ler arquivos .DGN, apesar de não conseguir
escrever neste tipo de arquivo. Contudo, como o objetivo deste trabalho é realizar a conversão
deste formato para outro de interesse, liberando o acesso às informações salvaguardadas em
arquivos proprietários, tal limitação não é empecilho ao prosseguimento da pesquisa.
A OGR, através das funções computacionais disponibilizadas na sub-rotina DGNLib,
consegue, com algumas limitações, ler os dados do arquivo .DGN, mas apenas aqueles
criados até a versão V7 do MicroStation (inclusive), utilizados até o ano 2000 na plataforma
CAD da Intergraph. Isto se deve ao fato de que a versão V7, ao contrário das posteriores a ela,
possui documentação sobre a sua estrutura interna, tornando mais fácil a sua leitura por
aplicativos livres. Os formatos mais novos são praticamente ilegíveis, visto que há a
necessidade de se descobrir como é a estrutura interna dos arquivos, o que certamente
demanda trabalhos extensos.
Apesar de não haver perda de informações, o arranjo das mesmas é modificado ao se
visualizar o arquivo pela OGR. As modificações ocorridas são:
− Todas as camadas (layers) existentes no arquivo original são reunidas em uma única
camada chamada elements;
− Não há georreferenciamento do arquivo .dgn através da OGR;
− Todo e qualquer tipo de geometria é convertido para os tipos ponto, linha ou
polígono, havendo com isso a perda do conceito de elemento complexo, a saber:
− Tipo polilinha – tratado como linha multi-segmentada;
− Tipo área – tratado como polígono;
− Tipo curva – aproximado para geometria linear;
− Tipo b-spline – aproximado, com perda de precisão, para o tipo de geometria
linear;
− Tipo arco – aproximado para geometria linear;
− Tipo elipse – aproximado para geometria linear;
− Tipo texto – aproximado para geometria pontual.
− O padrão de preenchimento de objetos não é suportado pela OGR, embora o
preenchimento com cor sólida seja.
30
Conhecidas estas limitações, pode-se realizar algumas medidas para tentar contorná-las,
visando uma futura conversão do arquivo .DGN para shapefile. Uma delas consiste em salvar
cada camada de dados em um arquivo .DGN separado, evitando assim que se perca a
classificação das informações já realizada quando da digitalização da carta.
4.2.2 LEITURA DO ARQUIVO SHAPEFILE POR MEIO DA OGR
O suporte a leitura e criação de arquivos shapefile é bastante desenvolvida na OGR. Toda
a manipulação deste tipo de arquivo é função de uma sub-rotina, a ShapeLib.
Um diretório contendo diversos arquivos .SHP é tratado como sendo um conjunto de
dados (dataset) com múltiplos layers, sendo cada layer representado por um shapefile.
Outra característica de relevância no suporte a arquivos .SHP é a possibilidade de se
anexar informações quanto à projeção cartográfica utilizada na carta. Basta que se coloque, no
diretório acima mencionado, o arquivo .PRJ (do Arc/Info ou do ESRI OGC WKT) referente
às características da projeção.
Por não ser a ferramenta padrão para leitura e escrita de arquivos .SHP, a OGR apresenta
um certo número de limitações, principalmente no que diz respeito à criação de arquivos
novos. Algumas limitações importantes de serem ressaltadas são:
− Nomes de atributos armazenados no arquivo .dbf tem um tamanho máximo de doze
caracteres, e nomes de comprimento maior do que isso são truncados, o que pode
fazer com que hajam informações repetidas no banco de dados, gerando problemas
posteriores;
− No banco de dados (.dbf), o tamanho do campo do atributo e a sua precisão são
diretamente utilizados no estabelecimento do tamanho de armazenamento do arquivo;
com isso, strings mais longas do que o tamanho máximo permitido ou números que
não caibam no espaço permitido a eles são truncados;
− Campos do tipo inteiro no arquivo .dbf sem comprimento definido são interpretados
como sendo de comprimento onze;
− Campos do tipo real (floating point) no arquivo .dbf sem comprimento definido são
interpretados como sendo de comprimento vinte e quatro, com quinze casas decimais
de precisão;
31
− Campos do tipo string no arquivo .dbf sem comprimento definido são interpretados
como sendo de comprimento oitenta.
− A OGR permite a reescrita de geometrias, bem como a remoção delas, embora o
processo de remoção dos atributos correspondentes não seja realizado no arquivo
.dbf; o atributo a ser removido no banco de dados é marcado para remoção e então
ignorado pela OGR, de forma que para concluir a remoção (se desejado) é necessário
a execução de um comando de banco de dados (dependendo da aplicação que se
utiliza da OGR, este comando pode já estar embutido no código do programa).
Como se pôde perceber, algumas das limitações existentes precisam ser contornadas para
que se possa estabelecer a OGR como biblioteca padrão a ser utilizada na conversão de dados
vetoriais da base cartográfica nacional. Estas limitações são, em sua maioria, relativas aos
atributos associados às geometrias e não às geometrias em si. Assim, pela disponibilidade de
tempo para a execução do presente trabalho, que dificulta a aquisição de maiores
conhecimentos a respeito de algumas das limitações existentes na OGR, apenas algumas delas
merecerão destaque especial e serão estudadas mais a fundo, a fim de se evitar a perda de
informações de maior relevância com a conversão.
4.3 CÓDIGO EXISTENTE DE CONVERSÃO DO DESIGN FILE PARA SHAPEFILE
No sentido de prover a comunidade cartográfica de uma base de dados livre e possível de
ser manipulada por softwares gratuitos, foi desenvolvida na 5ª Divisão de Levantamento
(5ª DL), no Rio de Janeiro-RJ, uma rotina de conversão dos dados contidos no arquivo .DGN
para o formato shapefile. Tal rotina (doravante denomidada “dgntoshp”), de autoria do 1º Ten
Maurício Carvalho Mathias de Paulo, atualmente no 5º ano de Engenharia Cartográfica do
Instituto Militar de Engenharia (IME), manipula diretamente as bibliotecas GDAL/OGR,
trabalhando com as funções nela definidas e estruturadas. Desta forma, e diferentemente do
binário “ogr2ogr” disponibilizado pela própria comunidade desenvolvedora da GDAL, o
“dgntoshp” consegue realizar toda a separação dos layers do arquivo .DGN, bem como
manter toda a informação original juntamente com seus atributos, dentro, logicamente, das
limitações impostas pela própria estrutura do arquivo shapefile (um tipo de geometria por
arquivo .SHP, apenas três possibilidades de geometria, etc.).
32
A biblioteca GDAL/OGR, como informa sua documentação, consegue converter dados
entre alguns dos formatos que é capaz de reconhecer, sendo os de interesse de momento os
seguintes:
− ESRI Shapefile
− DGN
− PostgreSQL
Para que a conversão seja realizada, é necessário passar para a função da OGR que
processa a conversão o módulo a ser utilizado. Um módulo (comumente chamado de driver),
para a OGR, nada mais é do que um conjunto de instruções específicas para a leitura/escrita
de um dado tipo de arquivo. Cada um dos drivers disponíveis na OGR recebe um nome da
forma como exemplificado acima, de acordo com o tipo de arquivo suportado por ele, e é
exatamente este nome que é utilizado para realizar a conexão entre o módulo e as funções
conversoras desejadas.
A seguir encontra-se um trecho do código do dgntoshp, mais especificamente do código
contido no arquivo cdgntoshp.cpp . Pode-se ver aqui como a referência ao driver “ESRI
Shapefile” é feita.
int cdgntoshp::createshpdir(string dir)
{
const char *pszDriverName = "ESRI Shapefile";
this->outDriver = OGRSFDriverRegistrar::GetRegistrar()-> GetDriverByName
( pszDriverName );
if( this->outDriver == NULL )
{
cout << pszDriverName << " driver not available." <<endl;
return( 0 );
}
this->dds = this->outDriver->CreateDataSource( dir.c_str(), NULL );
if( this->dds == NULL )
{
cout << "Creation of output file failed." << endl; ;
return( 0 );
}
return 1;
}
33
Como se pode perceber, o driver é informado ao programa, que o armazena na string
“pszDriverName”. Esta variável, posteriormente, é utilizada como parâmetro em outra função
da OGR, responsável por recuperar as funções a serem utilizadas na manipulação do arquivo
shapefile.
Logicamente, há mais a ser feito, mas já se pode perceber que este trecho de código
precisa ser alterado para que o “dgntoshp” passe a utilizar o driver “PostgreSQL” em vez do
“ESRI Shapefile”. Contudo, a passagem de instruções ao driver “PostgreSQL” é diferente do
driver do shapefile, visto que PostgreSQL é um banco de dados e não um arquivo. Sendo
assim, os parâmetros de conexão ao banco de dados precisam ser passados ao driver, a saber:
− Endereço do servidor;
− Nome do banco de dados a ser utilizado;
− Usuário (username);
− Senha (password).
Estudando a documentação da GDAL/OGR e analisando o código do “dgntoshp”,
chegou-se à conclusão de que a passagem destas informações se dá de um modo um pouco
diferente do modo do “dgntoshp”. O primeiro fato percebido é que, como a OGR só é capaz
de acrescentar tabelas a um banco de dados existente e não é capaz de criar um banco de
dados novo, a função CreateDataSource não poderá ser utilizada. Isto porque esta função é a
responsável por criar o arquivo de saída, e neste caso o “arquivo” seria um banco de dados.
Desta forma, a seguinte linha de código do arquivo cdgntoshp.cpp
this->dds = this->outDriver->CreateDataSource( dir.c_str(), NULL );
se transformará em
this->dds = OGRSFDriverRegistrar::Open( dir.c_str(), FALSE );
A função Open recebe como parâmetro principal (dir) os dados para conexão ao banco de
dados, sendo a responsável por abrir o mesmo para inserção das geometrias.
No arquivo dgntoshp.cpp, referente ao programa principal, alguns trechos do código
também precisam ser alterados, notadamente ao que se refere aos parâmetros passados ao
executável após compilado. Desta forma, o trecho de código
34
string entryfile=argv[1];
string outdir=argv[2];
será alterado para
string entryfile=argv[1];
string outdir="PG: host=";
outdir+=argv[2]; //host
outdir+=" dbname=";
outdir+=argv[3]; //dbname
outdir+=" user=";
outdir+=argv[4]; //user
outdir+=" password=";
outdir+=argv[5]; //password
sendo que o programa principal será executado da seguinte forma:
$ ./dgntopg origem.dgn servidor nomedobanco usuario senha
onde:
- servidor – endereço do servidor do banco de dados;
- nomedobanco – banco que receberá as geometrias;
- usuario – nome do usuário dono do banco de dados “nomedobanco”;
- senha – senha do usuário “usuario”.
Outras pequenas modificações do código do “dgntoshp” foram realizadas, modificações
estas relacionadas à particularidades dos formatos shapefile e PostgreSQL. Ambos os códigos
encontram-se em anexo ao trabalho, sendo tais modificações comentadas no formato C++ em
momento oportuno.
Após realizadas as modificações necessárias, todo o código foi recompilado, gerando-se
o arquivo binário “dgntopg”, pronto para ser executado.
35
5 ANÁLISE DOS RESULTADOS
Partindo-se de uma carta do IBGE em formato .DGN, executou-se o programa “dgntopg”
exatamente como descrito anteriormente. Logo em sua execução, pôde-se perceber que o
mesmo funcionou, gerando tabelas e inserindo-as no local correto no banco de dados.
Tendo-se os dados importados para o banco de dados, fez-se a visualização dos mesmos
através do software Quantum GIS (QGIS). Uma vez aberto o programa, selecionou-se a
ferramenta “Adicionar camada PostGIS”, e em seguida criou-se uma nova conexão com os
mesmos parâmetros utilizados na execução do “dgntopg”. Feito isto, conectou-se ao banco, de
forma que o QGIS reconheceu cada um dos diversos níveis do arquivo .DGN original como
sendo uma tabela distinta dentro do banco de dados utilizado. Adicionando-se tais tabelas ao
projeto do QGIS, pôde-se visualizar os dados, conforme pode ser visto na Fig. 5.1.
Fig. 5.1 – Ambiente gráfico do Quantum GIS 0.8.0 para Linux.
36
A principal incongruência observada entre os dados convertidos e o arquivo .DGN
original diz respeito à tabela de cores. O arquivo .DGN V7 carrega consigo um valor
numérico de cor para os objetos, de forma que quando o arquivo é aberto no MicroStation a
tabela de cores faz a tradução do valor numérico para a cor adequada. O problema reside no
fato de que o PostgreSQL não guarda tabelas de cores, sendo isto de responsabilidade da
plataforma manipuladora e visualizadora dos dados vetoriais (no caso, o QGIS). Assim,
devido ao fato de o QGIS atribuir cores aleatórias aos objetos de cada layer PostGIS (como
informa a documentação do software), as cores apresentadas na tela do programa não
correspondem àquelas apresentadas no MicroStation. Contudo, é possível de se realizar a
adaptação desta tabela, pois o QGIS oferece ferramentas de edição de tabela de cores,
cabendo ao usuário atribuir a cor que lhe convém ao valor numérico de cor do dado
armazenado no banco de dados.
Outro problema observado, este ainda na fase de conversão, foi a impossibilidade de se
converter algumas geometrias por motivo desconhecido. Durante a execução do “dgntopg”,
foram apresentadas as falhas, conforme pode ser visto na Fig. 7.1. Tais problemas
provavelmente são por falha na implementação o programa, pois os mesmos tipos de
geometria que apresentaram falha durante a conversão de um dado arquivo puderam ser
convertidos sem problemas em alguns outros arquivos.
Através do programa “dgntoshp”, “todos os dados relevantes (isto é, geometrias e seus
atributos) não são perdidos” (UCHÔA, et al, 2006), sendo os dados totalmente corretos e
válidos. Como já foi dito em outra oportunidade, o tempo disponível para execução da
pesquisa não permitiu o estudo dos demais problemas que talvez sejam gerados pelo processo
de conversão e/ou de visualização, bem como não foi possível um estudo de meios de
contorná-los. Contudo, cabem pesquisas detalhadas em cima dos dados convertidos para o
banco de dados, de forma a se poder estabelecer, com segurança nos resultados, o conjunto
OGR/PostgreSQL/PostGIS/QGIS como padrão para edição e visualização da base
cartográfica nacional.
37
6 CONCLUSÕES
O conjunto de bibliotecas GDAL/OGR é uma biblioteca completa, dispondo de inúmeras
ferramentas para reconhecimento de vários formatos de arquivos privados. Para o objetivo
deste trabalho, mostrou-se muito útil, pois foi capaz de realizar com sucesso a leitura do
arquivo .DGN e posteriormente exportar os dados para um banco de dados PostGIS.
Os dados cartográficos, antes codificados dentro da estrutura desconhecida do arquivo
.DGN, puderam ser convertidas para um formato de dados aberto e gratuito. Embora não se
tenha podido analisar profundamente as possíveis incorreções nos dados finais, em primeira
mão a rotina computacional mostrou-se de grande valia, pois certamente servirá de impulso à
execução de demais trabalhos voltados para a disponibilização das informações do
mapeamento sistemático brasileiro, cuja posse e domínio deve ser integralmente da Nação
Brasileira e não estar sujeita ao pagamento de licenças a empresas privadas para se ter acesso
às tais informações.
38
7 SUGESTÕES PARA TRABALHOS FUTUROS
Além da idéia citada nas conclusões do trabalho (pesquisar por mais falhas na conversão
do .DGN para PostgreSQL/PostGIS), uma possível proposta de trabalho futuro é a
implementação de uma padronização de uma tabela de cores a partir dos valores RGB no
banco de dados. Isto porque, como foi visto durante a análise dos resultados da conversão, a
tabela do .DGN é exclusiva do MicroStation, não sendo armazenada no banco de dados após
a conversão do arquivo, fazendo com que se perca a relação número x cor que se tinha no
MicroStation. Apesar do número relativo à cor ser armazenado, este não tem a mesma
correspondência de cores em outros softwares como o Quantum GIS. Assim, visando a
padronização do formato aberto e livre para SIG, o estudo de uma possível implementação de
uma tabela de cores no padrão da TBCD para o QGIS torna-se viável.
39
8 REFERÊNCIAS BIBLIOGRÁFICAS
ANTENUCCI, J. C., BROWN, K., CROSWELL, P. L., et al. Geografique Information
Systems: A guide to the tecnology. Van Nostrand Reinhold, 1991. ARONOFF, S. Geographic Information Systems: A Management Perspective. Canada:
WDL Publications, 1989. BRODEUR, J. et al.. Modelling Geospatial Application Databases using UML-based
Repositories Aligned with International Standards in Geomatics. In Proceedings of
Eighth ACM Symposium on Advances in Geographic Information Systems (ACMGIS).
Washington - D.C., 2000. CASANOVA, M., CÂMARA, G., DAVIS, C., VINHAS, L., QUEIROZ, G. M. Banco de
Dados Geográficos. Curitiba: MundoGEO, 2005. DE PAULO, M. C. M.. CONVERSOR DGNTOSHP. Rio de Janeiro, 2006. Conjunto de
programas. 1 CD-ROM ENVIRONMENT SYSTEMS RESEARCH INSTITUTE. Understanding GIS: The
ARC/INFO Method. Redlands, CA: Environment Systems Research Institute, 1991. ESRI SHAPEFILE TECHNICAL DESCRIPTION. Environmental Systems Research
Institute Inc., 1998 [online]. Disponível: http://shapelib.maptools.org/dl/shapefile.pdf [capturado em 09 mar. 2007].
ESRI-GIS DICTIONARY. ESRI Support Center [online]. Disponível:
http://support.esri.com/GISDictionary [capturado em 26 out. 2006]. GARDARIN, Georges, VALDURIEZ, Patrick. Relational Databases and Knowledge
Bases. Addison-Wesley Publishing Company Inc., 1989. GEOSPATIAL DATA ABSTRACTION LIBRARY. GDAL.org. Disponível:
http://www.gdal.org [capturado em 15 fev. 2007] II BRAZILIAN SYMPOSIUM ON GEOINFORMATICS, GEOINFO 2000. TerraLib:
Technology in Support of GIS Innovation [online]. São Paulo, 2000. Disponível: http://www.terralib.org/docs/papers/TerraLib_Paper_GeoInfo2000.pdf [capturado em 31 out. 2006].
ISFF. Intergraph Standard File Formats – MicroStation 95 Reference Guide, capítulo 18.
Bentley Systems Inc., 1995 [online]. Disponível: http://dgnlib.maptools.org/dl/ref18.pdf [capturado em 02 dez. 2006].
MAGUIRE, D. Geographical Information Systems: Principles and Applications. John
Wiley & Sons, 1991. MEDEIROS, Cláudia B., PIRES, Fátima. Databases for GIS. ACM SIGMOD Record, v. 23
n. 1, 1994.
40
OGC. The OpenGIS Abstract Specification – Topic 0: Overview. Open Geospatial Consortium Inc., 1999 [online]. Disponível: http://www.opengeospatial.org/standards/as [capturado em 25 ago. 2006].
OGR SIMPLE FEATURES LIBRARY. Geospatial Data Abstraction Library [online].
Disponível: http://www.gdal.org/ogr [capturado em 15 fev. 2007]. POSTGRESQL.ORG GLOBAL DEVELOPMENT GROUP. PostgreSQL 8.2.0
Documentation [online]. Disponível: http://www.postgresql.org/files/documentation/pdf/8.2/postgresql-8.2-A4.pdf [capturado em 08 mai 2007]
TOMLIN, D. Geografique Information Systems and Cartographic Modelling. New York:
Prentice-Hall, 1990. TUTORIAL DE PROGRAMAÇÃO DO TERRALIB – Disponível:
http://www.terralib.org/docs/v313/TutorialProgramacaoTerraLib313.htm [capturado em 31 out 2006].
TUTORIAL DO TERRAVIEW – Disponível: http://www.dpi.inpe.br/terraview/index.php
[capturado em 31 out. 2006]. UCHÔA, H. N. et al. Evaluation of Data Conversion of Vectorial Geographic Features in
Topographic Maps Using Free Software Tools. In: FÓRUM INTERNACIONAL DE SOFTWARE LIVRE, 2006, Porto Alegre.
WARMERDAM, Frank. DGNLib: a MicroStation DGN (ISFF) Reader [online].
Disponível: http://dgnlib.maptools.org [capturado em 02 dez. 2006] WARMERDAM, Frank. Shapefile C Library V1.2 [online]. Disponível:
http://shapelib.maptools.org [capturado em 09 mar. 2007].
41
ANEXO I – CÓDIGO-FONTE DO PROGRAMA DGNTOSHP - Arquivo cdgntoshp.cpp //////////////////////////////////////////////// // Titulo: Classe CDgnToShp // // Autor: Mauricio Carvalho Mathias de Paulo. // // (de Paulo, M. C. M.) // // Ano: 2006 // // Licença: MIT // //////////////////////////////////////////////// #include "cdgntoshp.h" int cdgntoshp::copy(string filename, string dir) { vector<string> layers; unsigned int i,j,total; int ilayer,pos; string dbname,layername,outname; stringstream ss; vector<string>::iterator v_iter; OGRLayer *layer,*poLayer; OGRFeature *feat; //OGRFeatureDefn *columns; if (!(this->readdgn(filename))) return 0; this->createshpdir( dir); layer=this->ods->GetLayer(0); layer->ResetReading(); dbname=this->ods->GetName(); feat=layer->GetNextFeature(); total=0; while (feat != NULL) { total++; //finding where to save the feature ilayer=feat->GetFieldAsInteger("level"); outname=dbname; cout << outname <<endl; pos=outname.rfind("/",outname.length()-1); outname=outname.substr(pos+1,outname.rfind(".",outname.length()-1)-
pos-1); ss<< outname << "_L"<<ilayer <<"_G" <<feat->GetGeometryRef()-
>getGeometryType(); ss>>layername; cout <<layername<<endl; v_iter=find(layers.begin(),layers.end(),layername); if (v_iter==layers.end()) { //if file does not exists, create it cout << "Creating file " << layername << ".shp" << endl; layers.push_back(layername); char **papszOptions = NULL; papszOptions = CSLSetNameValue( papszOptions, "DIM", "2" ); papszOptions = CSLSetNameValue( papszOptions, "OVERWRITE",
"YES" ); poLayer = this->dds->CreateLayer(layername.c_str(), NULL, feat-
>GetGeometryRef()->getGeometryType(), papszOptions ); CSLDestroy( papszOptions ); if( poLayer == NULL ) {
42
cout << "Layer creation failed." <<endl; return( 0 ); } //copy layer definition //columns=layer->GetLayerDefn(); i=feat->GetFieldCount(); cout <<"Columns : "; for (j=0;j<i;j++) { poLayer->CreateField(feat->GetFieldDefnRef(j)); cout << feat->GetFieldDefnRef(j)->GetNameRef() << ", "; } cout <<endl; } else { //points to the right layer poLayer=this->dds->GetLayerByName(layername.c_str()); //cout << layername; } //copy feature poLayer->CreateFeature(feat); //cout <<feat->GetFieldAsString(8)<<endl; OGRFeature::DestroyFeature(feat); //delete poLayer; //feat->DestroyFeature(feat); feat=layer->GetNextFeature(); break; } cout << "Found levels: "; for (i=0;i<layers.size();i++){ cout << layers[i] << ", "; } cout <<" containing " << total << " features" <<endl; feat->DestroyFeature(feat); //delete feat; //delete layer; //return levellist; OGRDataSource::DestroyDataSource( ods ); OGRDataSource::DestroyDataSource( dds ); //delete this->outDriver; return 1; } cdgntoshp::~cdgntoshp() { /*OGRDataSource::DestroyDataSource( ods ); OGRDataSource::DestroyDataSource( dds ); delete this->outDriver;*/ } int cdgntoshp::readdgn(string filename) { this->ods = OGRSFDriverRegistrar::Open(filename.c_str(), FALSE ); if( ods == NULL ) { printf( "Arquivo invalido.\n" ); exit( 1 ); return 0; } return 1; }
43
int cdgntoshp::createshpdir(string dir) { const char *pszDriverName = "ESRI Shapefile"; this->outDriver = OGRSFDriverRegistrar::GetRegistrar()-
>GetDriverByName( pszDriverName ); if( this->outDriver == NULL ) { cout << pszDriverName << " driver not available." <<endl; return( 0 ); } this->dds = this->outDriver->CreateDataSource( dir.c_str(), NULL ); if( this->dds == NULL ) { cout << "Creation of output file failed." << endl; ; return( 0 ); } return 1; } /*int cdgntoshp::openpgdb() { this->dds=OGRSFDriverRegistrar::Open(""); }*/ vector<int> cdgntoshp::listlayers() { unsigned int i; int ilayer; vector<int> levellist; vector<int>::iterator v_iter; OGRLayer *layer; OGRFeature *feat; layer=this->ods->GetLayer(0); layer->ResetReading(); feat=layer->GetNextFeature(); while (feat != NULL) { ilayer=feat->GetFieldAsInteger("level"); v_iter=find(levellist.begin(),levellist.end(),ilayer); if (v_iter==levellist.end()) { levellist.push_back(ilayer); } //feat->DumpReadable(NULL); feat=layer->GetNextFeature(); } cout << "Found levels: "; for (i=0;i<levellist.size();i++){ cout << levellist[i] << ", "; } cout <<endl; delete feat; delete layer; return levellist; } cdgntoshp::cdgntoshp() { OGRRegisterAll(); }
44
- Arquivo cdgntoshp.h //////////////////////////////////////////////// // Titulo: Header CDgnToShp // // Autor: Mauricio Carvalho Mathias de Paulo. // // (de Paulo, M. C. M.) // // Ano: 2006 // // Licença: MIT // //////////////////////////////////////////////// #ifndef CDGNTOSHP_H #include "ogrsf_frmts.h" #include "gdal_priv.h" #include <string> #include <iostream> #include <vector> #include <algorithm> #include <sstream> using namespace std; class cdgntoshp { public: int createshpdir(string dir); int readdgn(string filename); //int openpgdb(); vector<int> listlayers(); int copy(string filename, string dir); cdgntoshp(); ~cdgntoshp(); private: OGRDataSource* ods, *dds; OGRSFDriver *outDriver; }; #endif
45
- Arquivo dgntoshp.cpp //////////////////////////////////////////////// // Titulo: Conversor DgnToShp // // Autor: Mauricio Carvalho Mathias de Paulo. // // (de Paulo, M. C. M.) // // Ano: 2006 // // Licença: MIT // //////////////////////////////////////////////// #ifdef HAVE_CONFIG_H #include <config.h> #endif #include "cdgntoshp.h" #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { string entryfile=argv[1]; string outdir=argv[2]; cdgntoshp tool; tool.copy(entryfile,outdir); }
46
ANEXO II – CÓDIGO-FONTE DO PROGRAMA DGNTOPG - Arquivo cdgntopg.cpp ///////////////////////////////////////////////////// // Titulo: Classe CDgnToPG // // Autor: Mauricio Carvalho Mathias de Paulo. // // Colaboradores: Vandro Fernandes Morgado // // Diego Benincasa F. C. de Almeida // // Ano: 2007 // ///////////////////////////////////////////////////// #include "cdgntopg.h" int cdgntoshp::copy(string filename, string dir) { vector<string> layers; unsigned int i,j,total; int ilayer,pos; string dbname,layername,outname; stringstream ss; vector<string>::iterator v_iter; OGRLayer *layer,*poLayer; OGRFeature *feat; if (!(this->readdgn(filename))) return 0; this->createshpdir( dir); layer=this->ods->GetLayer(0); layer->ResetReading(); dbname=this->ods->GetName(); feat=layer->GetNextFeature(); total=0; while (feat != NULL) { total++; //finding where to save the feature ilayer=feat->GetFieldAsInteger("level"); outname=dbname; pos=outname.rfind("/",outname.length()-1); outname=outname.substr(pos+1,outname.rfind(".",outname.length()-1)-
pos-1); ss<< outname << "_L"<<ilayer <<"_G" <<feat->GetGeometryRef()-
>getGeometryType(); ss>>layername; v_iter=find(layers.begin(),layers.end(),layername); if (v_iter==layers.end()) { //if file does not exists, create it cout << "Criando tabela " << layername << endl; layers.push_back(layername); char **papszOptions = NULL; papszOptions = CSLSetNameValue( papszOptions, "DIM", "2" ); papszOptions = CSLSetNameValue( papszOptions, "OVERWRITE",
"YES" ); poLayer = this->dds->CreateLayer(layername.c_str(), NULL, feat-
>GetGeometryRef()->getGeometryType(), papszOptions ); CSLDestroy( papszOptions ); if( poLayer == NULL ) { cout << "Layer creation failed." <<endl;
47
return( 0 ); } i=feat->GetFieldCount(); cout <<"Colunas : "; for (j=0;j<i;j++) { poLayer->CreateField(feat->GetFieldDefnRef(j)); cout << feat->GetFieldDefnRef(j)->GetNameRef() << ", "; } cout <<endl; } else { //if creation wasn't needed, points to the right layer poLayer=this->dds->GetLayerByName(layername.c_str()); } //copy feature poLayer->CreateFeature(feat); OGRFeature::DestroyFeature(feat); feat=layer->GetNextFeature(); } cout << "Niveis encontrados: "; for (i=0;i<layers.size();i++){ cout << layers[i] << ", "; } cout <<" contendo " << total << " objetos." <<endl; feat->DestroyFeature(feat); OGRDataSource::DestroyDataSource( ods ); OGRDataSource::DestroyDataSource( dds ); return 1; } cdgntoshp::~cdgntoshp() { /*OGRDataSource::DestroyDataSource( ods ); OGRDataSource::DestroyDataSource( dds ); delete this->outDriver;*/ } int cdgntoshp::readdgn(string filename) { this->ods = OGRSFDriverRegistrar::Open(filename.c_str(), FALSE ); if( this->ods == NULL ) { printf( "Arquivo invalido.\n" ); exit( 1 ); return 0; } return 1; } int cdgntoshp::createshpdir(string dir) { OGRRegisterAll(); this->dds = OGRSFDriverRegistrar::Open( dir.c_str(), FALSE ); if( this->dds == NULL ) { cout << "Conexao ao banco falhou." << endl;
48
exit(1); } return 1; } vector<int> cdgntoshp::listlayers() { unsigned int i; int ilayer; vector<int> levellist; vector<int>::iterator v_iter; OGRLayer *layer; OGRFeature *feat; layer=this->ods->GetLayer(0); layer->ResetReading(); feat=layer->GetNextFeature(); while (feat != NULL) { ilayer=feat->GetFieldAsInteger("level"); v_iter=find(levellist.begin(),levellist.end(),ilayer); if (v_iter==levellist.end()) { levellist.push_back(ilayer); } feat=layer->GetNextFeature(); } cout << "Niveis encontrados: "; for (i=0;i<levellist.size();i++){ cout << levellist[i] << ", "; } cout <<endl; delete feat; delete layer; return levellist; } cdgntoshp::cdgntoshp() { OGRRegisterAll(); }
49
- Arquivo cdgntopg.h ///////////////////////////////////////////////////// // Titulo: Header File Conversor DgnToPG // // Autor: Mauricio Carvalho Mathias de Paulo. // // Colaboradores: Vandro Fernandes Morgado // // Diego Benincasa F. C. de Almeida // // Ano: 2007 // ///////////////////////////////////////////////////// #ifndef CDGNTOPG_H #include "ogrsf_frmts.h" #include "gdal_priv.h" #include <string> #include <iostream> #include <vector> #include <algorithm> #include <sstream> using namespace std; class cdgntoshp { public: int createshpdir(string dir); int readdgn(string filename); vector<int> listlayers(); int copy(string filename, string dir); cdgntoshp(); ~cdgntoshp(); private: OGRDataSource* ods, *dds; OGRSFDriver *outDriver; }; #endif
50
- Arquivo dgntopg.cpp ///////////////////////////////////////////////////// // Titulo: Conversor DgnToPG // // Autor: Mauricio Carvalho Mathias de Paulo. // // Colaboradores: Vandro Fernandes Morgado // // Diego Benincasa F. C. de Almeida // // Ano: 2007 // ///////////////////////////////////////////////////// #ifdef HAVE_CONFIG_H #include <config.h> #endif #include "cdgntopg.h" #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { if (argc<5) { cout << "Como usar (para leigos):\n\n dgntopg arquivo.dgn localhost
postgis postgres teste \n\n Onde 'arquivo.dgn' eh o arquivo dgn a ser convertido, 'localhost' eh o endereco da maquina, 'postgis' eh o nome do database, 'postgres' eh o nome do usuario e 'teste' eh a senha do mesmo." <<endl;
exit(1); } string entryfile=argv[1]; string outdir="PG: host="; outdir+=argv[2]; //host outdir+=" dbname="; outdir+=argv[3]; //dbname outdir+=" user="; outdir+=argv[4]; //user outdir+=" password="; outdir+=argv[5]; //password cdgntoshp tool; tool.copy(entryfile,outdir); }
