RONALDO APARECIDO DE OLIVEIRA CONCEPÇÃO, DESENVOLVIMENTO E APLICAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS NO CONTEXTO DO MAPEAMENTO TERRESTRE MÓVEL Dissertação apresentada à Faculdade de Ciências e Tecnologia da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Campus de Presidente Prudente, para a obtenção do título de Mestre em Ciências Cartográficas (Área de Concentração: Aquisição, Análise e Representação de Informações Espaciais). Orientador: Prof. Adj. João Fernando Custódio da Silva Presidente Prudente 2001 unesp UNIVERSIDADE ESTADUAL PAULISTA FACULDADE DE CIÊNCIAS E TECNOLOGIA – PRESIDENTE PRUDENTE Curso de Pós-Graduação em Ciências Cartográficas u n e s pu n e s p Ronaldo Aparecido de Oliveira RONALDO APARECIDO DE OLIVEIRA CONCEPÇÃO, DESENVOLVIMENTO E APLICAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS NO CONTEXTO DO MAPEAMENTO TERRESTRE MÓVEL Dissertação apresentada à Faculdade de Ciências e Tecnologia da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Campus de Presidente Prudente, para a obtenção do título de Mestre em Ciências Cartográficas (Área de Concentração: Aquisição, Análise e Representação de Informações Espaciais). Orientador: Prof. Adj. João Fernando Custódio da Silva Presidente Prudente 2001 unesp UNIVERSIDADE ESTADUAL PAULISTA FACULDADE DE CIÊNCIAS E TECNOLOGIA – PRESIDENTE PRUDENTE Curso de Pós-Graduação em Ciências Cartográficas u n e s pu n e s p Ronaldo Aparecido de Oliveira RONALDO APARECIDO DE OLIVEIRA CONCEPÇÃO, DESENVOLVIMENTO E APLICAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS NO CONTEXTO DO MAPEAMENTO TERRESTRE MÓVEL Dissertação apresentada à Faculdade de Ciências e Tecnologia da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Campus de Presidente Prudente, para a obtenção do título de Mestre em Ciências Cartográficas (Área de Concentração: Aquisição, Análise e Representação de Informações Espaciais). Orientador: Prof. Adj. João Fernando Custódio da Silva Presidente Prudente 2001 u n e s pu n e s p Ronaldo Aparecido de Oliveira iii RONALDO APARECIDO DE OLIVEIRA CONCEPÇÃO, DESENVOLVIMENTO E APLICAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS NO CONTEXTO DO MAPEAMENTO TERRESTRE MÓVEL BANCA EXAMINADORA Prof. Adj. João Fernando Custódio da Silva (Orientador) Prof. Dr. Klaus Schlünzen Junior Prof. Dr. Luiz Felipe Coutinho Ferreira da Silva Presidente Prudente 2001 i RONALDO APARECIDO DE OLIVEIRA CONCEPÇÃO, DESENVOLVIMENTO E APLICAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS NO CONTEXTO DO MAPEAMENTO TERRESTRE MÓVEL Orientador: Prof. Adj. João Fernando Custódio da Silva Presidente Prudente 2001 ii Oliveira, Ronaldo Aparecido de O51c Concepção, desenvolvimento e aplicação do Banco de Imagens Georreferenciadas no contexto do Mapeamento Terrestre Móvel. / Ronaldo Aparecido de Oliveira. - Presidente Prudente: [s.n], 2001. 74p.: il.; 29cm. Dissertação (mestrado) - UNESP, Faculdade de Ciências e Tecnologia, Presidente Prudente, 2001. Orientador: Prof. Dr. João Fernando Custódio da Silva 1. Sistema de Mapeamento Móvel. 2. Banco de Imagens. I. Título. CDD (18.ed.)623.72 v DADOS CURRICULARES RONALDO APARECIDO DE OLIVEIRA NASCIMENTO 29.4.1976 – JALES/SP FILIAÇÃO Arcidio Pereira de Oliveira Iraides Diamantino de Oliveira 1994/1998 Curso de Graduação em Engenharia Cartográfica Faculdade de Ciências e Tecnologia de Presidente Prudente 1999/2001 Curso de Pós-graduação em Ciências Cartográficas Faculdade de Ciências e Tecnologia de Presidente Prudente vi Aos meus pais (minha origem) e à Raquel (meu destino) vii AGRADECIMENTOS À Deus, pela vida. Aos meus pais, Arcidio e Iraides, pela educação e pelo amor. Ao meu orientador, João Fernando Custódio da Silva, que foi mais que um orientador, me auxiliando nos diversos problemas enfrentados, paciente com minha falta de paciência e experiência e, acima de tudo, um grande amigo. À minha noiva (esposa), Raquel, que mesmo sem poder ajudar na parte relacionada à pesquisa, teve muita paciência para me auxiliar psicológica e emocionalmente, nunca deixando de acreditar em mim. Aos meus amigos, Leonardo Ercolin Filho (meu “irmão”), Rodrigo Bezerra de Araújo Gallis (“Danone”), Ricardo Barbosa (“Ricardinho”), Almir Artero e Milton Shimabukuro, pela força nos momentos difíceis e pela companhia nos momentos agradáveis (principalmente quando pagavam a cerveja). Aos professores Luiz Felipe da Silva e Leonardo Oliveira, ambos do IME, pela amizade, confiança e por tudo que ajudaram-me no tempo que estive no Rio de Janeiro desenvolvendo o estágio. Às secretárias do departamento, Graça e Cidinha, pela paciência, atenção e carinho prestado para comigo. Não poderia de deixar de agradecer também à FAPESP (Fundação de Amparo à Pesquisa do Estado de São Paulo) pela concessão da bolsa de mestrado e também pelo auxílio financeiro ao projeto da Unidade Móvel de Mapeamento Digital. E à todos que, direta ou indiretamente, contribuíram para a realização deste projeto e, principalmente, pela minha formação acadêmica. viii “Mestre não é quem ensina, mas quem de repente aprende” João Guimarães Rosa (1908-1967) ix SUMÁRIO LISTA DE FIGURAS _____________________________________________ ix LISTA DE TABELAS ______________________________________________x LISTA DE ABREVIATURAS _______________________________________ xi RESUMO ______________________________________________________ xii 1 INTRODUÇÃO _________________________________________________1 1.1 Sistemas Móveis de Mapeamento Digital __________________________1 1.2 Banco de Dados e Banco de Imagens _____________________________4 1.3 Proposição _________________________________________________7 1.4 Objetivos __________________________________________________8 1.4.1 Geral ________________________________________________________ 8 1.4.2 Específico_____________________________________________________ 9 1.5 Estrutura do Trabalho ________________________________________9 2 CONCEITOS BÁSICOS_________________________________________11 2.1 Modelagem de um Banco de Dados _____________________________11 2.1.1 Modelo Conceitual ______________________________________________11 2.1.2 Modelo de Representação_________________________________________13 2.1.3 Modelo de Implementação ________________________________________14 2.2 Ambiente de Programação e o Banco de Dados Paradox _____________14 3 MODELAGEM E ESTRUTURAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS _________________________________________16 3.1 Modelo Conceitual __________________________________________17 3.2 Modelo de Representação_____________________________________18 4 IMPLEMENTAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS _________________________________________24 4.1 Módulo de Cadastramento ____________________________________25 4.2 Módulo de Gerenciamento ____________________________________27 4.3 Módulo de Consulta _________________________________________30 4.4 Módulo de Emissão de Relatórios_______________________________32 5 ANÁLISE DO BANCO DE IMAGENS GEORREFERENCIADAS ______35 6 CONCLUSÕES E RECOMENDAÇÕES ___________________________39 x REFERÊNCIAS__________________________________________________43 ANEXO A – OPERAÇÃO DO MÓDULO DE CADASTRAMENTO ________46 A.1 Cadastrando o Projeto_______________________________________46 A.2 Cadastrando o Cliente _______________________________________47 A.3 Cadastrando o Endereço _____________________________________48 A.4 Cadastrando a Cidade_______________________________________49 A.5 Cadastrando a Câmara ______________________________________50 ANEXO B – OPERAÇÃO DO MÓDULO DE GERENCIAMENTO ________53 B.1 Inserindo um Registro _______________________________________53 B.2 Alterando um Registro_______________________________________55 B.3 Excluindo um Registro_______________________________________57 ANEXO C – OPERAÇÃO DO MÓDULO DE CONSULTA _______________59 C.1 Consulta por Nome da Imagem ________________________________59 C.2 Consulta por Nome do Projeto_________________________________60 C.3 Consulta por Nome do Cliente_________________________________62 C.4 Consulta por Nome da Rua ___________________________________63 C.5 Consulta por Data do Levantamento____________________________65 ANEXO D – OPERAÇÃO DO MÓDULO DE EMISSÃO DE RELATÓRIOS 67 D.1 Relatório por Nome da Imagem________________________________67 D.2 Relatório por Nome do Projeto ________________________________68 D.3 Relatório por Nome da Rua___________________________________69 ABSTRACT _____________________________________________________71 AUTORIZAÇÃO PARA REPRODUÇÃO _____________________________72 xi LISTA DE FIGURAS Figura 1 Unidade Móvel de Mapeamento Digital _______________________3 Figura 2 Laboratório de Mapeamento Móvel___________________________3 Figura 3 Par de vídeo câmaras e antena GPS instalados na UMMD ________3 Figura 4 Objetos básicos do modelo E-R utilizados no BIG, baseado nos conceitos de Chen(1976) __________________________________12 Figura 5 Tipos de relacionamento por conectividade ___________________13 Figura 6 Compilador C++ Builder v3.0 ______________________________15 Figura 7 Modelo Conceitual do BIG ________________________________17 Figura 8 Tela principal do BIG ____________________________________25 Figura 9 Formulário para Cadastrar Projeto__________________________26 Figura 10 Formulário para Cadastrar Câmara ________________________26 Figura 11 Formulário para Inserir Registro - parte 1 ___________________28 Figura 12 Formulário para Inserir Registro - parte 2 ___________________28 Figura 13 Formulário para Alterar Registro - parte 1___________________28 Figura 14 Formulário para Alterar Registro - parte 2___________________29 Figura 15 Formulário para Alterar Registro - parte 3___________________29 Figura 16 Formulário para Excluir Registro__________________________30 Figura 17 Formulário para Consulta por Projeto ______________________31 Figura 18 Formulário para Consulta por Imagem _____________________31 Figura 19 Formulário para Consulta por Rua_________________________31 Figura 20 Formulário para Consulta por Data de Levantamento _________32 Figura 21 Formulário para Emissão de Relatórios _____________________33 Figura 22 Exemplo da emissão de um relatório simples por consulta de Endereço (Rua) _________________________________________33 Figura 23 Exemplo da emissão de um relatório completo por consulta de Endereço (Rua) _________________________________________34 xii LISTA DE TABELAS TABELA 1 Síntese dos protótipos existentes de STMM___________________2 TABELA 2 Tabela ENDEREÇO do banco de imagens __________________19 TABELA 3 Tabela CLIENTE do banco de imagens ____________________19 TABELA 4 Tabela IMAGEM/PROJETO do banco de imagens ___________19 TABELA 5 Tabela CIDADE do banco de imagens _____________________19 TABELA 6 Tabela IMAGEM do banco de imagens_____________________20 TABELA 7 Tabela PROJETO do banco de imagens ____________________21 TABELA 8 Tabela CÂMARA do banco de imagens ____________________21 TABELA 9 Relacionamentos na base de dados do BIG__________________22 TABELA 10 Ficha técnica do programa______________________________37 xiii LISTA DE ABREVIATURAS BIG Banco de Imagens Georreferenciadas DBMS Database Management System – Sistema de Gerenciamento de Banco de Dados E-R Entidade-Relacionamento FCT Faculdade de Ciências e Tecnologia GPS Global Positioning System – Sistema de Posicionamento Global INS Inercial Navigation System – Sistema de Navegação Inercial LaMMov Laboratório de Mapeamento Móvel Mb Megabyte SIG Sistema de Informação Geográfica SMMD Sistema Móvel de Mapeamento Digital STMM Sistema Terrestre Móvel de Mapeamento SQL Structure Query Language – Linguagem de Consulta Estruturada UMMD Unidade Móvel de Mapeamento Digital Unesp Universidade Estadual Paulista xiv RESUMO Apresentam-se as bases de um sistema móvel de mapeamento digital, cuja característica principal é a de integrar diferentes sensores e obter dados e imagens de rodovias e arruamentos urbanos. A constituição básica de um sistema móvel de mapeamento é dada por um segmento móvel e um fixo. O segmento móvel é caracterizado por um veículo, no teto do qual são colocados um par de câmaras digitais de vídeo e uma antena de receptor GPS; no interior do veículo são embarcados um microcomputador portátil e diversos equipamentos e dispositivos de apoio e controle. O segmento fixo é caracterizado por um laboratório, particularmente, o Laboratório de Mapeamento Móvel, equipado com capacidade de armazenamento, processamento e análise de imagens e dados espaciais. Em operação, este sistema produz rapidamente uma grande quantidade de dados e informações, que precisam ser armazenadas e acessadas quando necessário. Concebe-se então um banco de imagens georreferenciadas, como um ambiente de armazenamento, controle de acesso e gerenciamento da informação. Este trabalho apresenta o conceito, a justificativa, o objetivo, a metodologia, o desenvolvimento e aplicações do Banco de Imagens Georreferenciadas (BIG). 1 1 INTRODUÇÃO O rápido desenvolvimento da tecnologia computacional trouxe consigo um maior conhecimento da Cartografia (devido a novos produtos e novas formas de apresentação) e isto fez surgir a necessidade de se obter informações espaciais com rapidez. A integração da Cartografia com esta tecnologia emergente, aliada a um sistema de armazenamento e gerenciamento de informações, propiciou a idealização de um novo sistema, chamado Sistema de Informação Geográfica (SIG). Com a contínua necessidade de atualização da base de dados, houve um grande esforço para desenvolver técnicas confiáveis para tal tarefa. Uma das técnicas de obtenção de informações espaciais que vem se destacando, principalmente devido à rapidez, eficiência e economia de recursos, é o Sistema Móvel de Mapeamento Digital (SMMD). 1.1 Sistemas Móveis de Mapeamento Digital No mundo, existem vários centros de pesquisas e empresas trabalhando com esta técnica e, basicamente, todos os sistemas possuem as mesmas configurações: uma integração de métodos de posicionamento (como por exemplo GPS ou sistema inercial de navegação – INS, utilizado quando há perda do sinal GPS) , câmaras de vídeo (analógicas e/ou digitais) e um sistema de armazenamento para as imagens (El-Sheimy, 1996; Ellum & El-Sheimy, 2000; Habib, 1994; He, 1996; He & Orvets, 2000; Li et al., 1994, 1996, 1998; Maresch & Duracher, 1996; Novak & Bossler, 1995; Toth, 1995; Visintini, 1999; Wang et al., 2000; Zhao & Shibaski, 1998). A tabela 1 2 mostra alguns dos principais protótipos de SMMD bem como o país e aplicação de cada sistema. TABELA 1 – Síntese dos protótipos existentes de STMM Nome do sistema País Aplicações GPSVan EUA Mapeamento rodoviário, ferroviário e hidroviário GPSVision EUA Mapeamento rodoviário VISAT Canadá Mapeamento rodoviário FRANK Holanda Mapeamento urbano para fins cadastrais MANDLI EUA Mapeamento de Rodovias e Estradas WELENCO EUA Geofísica DCSS Alemanha Mapeamento rodoviário e urbanístico KiSS Alemanha Mapeamento rodoviário GEOVan EUA Mapeamento rodoviário e ferroviário TruckMAP EUA Mapeamento rodoviário e urbano ARAN Canadá Mapeamento rodoviário e urbano DAVIDE Itália Mapeamento rodoviário ROMDAS Nova Zelândia Mapeamento rodoviário e urbano Na Faculdade de Ciências e Tecnologia (FCT/Unesp) está-se em fase de estruturação de um protótipo similar (Oliveira & Silva, 1998a, 1998b, 1999; Oliveira et al., 2000; Silva et al., 1999, 2000, 2001; Silva & Oliveira, 1998). Tal sistema é composto por um segmento móvel e por um fixo. A Unidade Móvel de Mapeamento Digital (UMMD) representa o segmento móvel, enquanto que o Laboratório de Mapeamento Móvel (LaMMov) representa o segmento fixo (figuras 1 e 2, respectivamente). A UMMD é formada por três módulos: o de posicionamento GPS e sincronismo dos quadros, o de aquisição de imagens digitais e o de alimentação de energia. Os principais equipamentos que a compõem são: um automóvel Kombi, um par 3 de vídeo câmaras digitais (Sony DSR 200A), um par de receptores GPS, um microcomputador notebook e um dispositivo de sincronismo dos quadros. A figura 3 mostra o par de câmaras e a antena GPS instados sobre o teto da UMMD. Figura 1 - Unidade Móvel de Mapeamento Digital Figura 2 - Laboratório de Mapeamento Móvel O LaMMov é o local onde se realiza todo o processamento das imagens e dados GPS obtidos em campo, visando a construção de um produto final, como por exemplo um mapa. As câmaras de vídeo coletam uma grande quantidade de imagens 4 (30 quadros por segundo) e mesmo depois da seleção e separação das imagens necessárias para um projeto, o volume ainda é muito grande. Figura 3 - Par de vídeo câmaras e antena GPS instalados na UMMD Por exemplo, um arquivo com 1 minuto de filmagem, sem corte, ocupa cerca de 230 Mb no disco rígido. Cortando este arquivo de modo a utilizar uma imagem a cada um segundo, o espaço necessário se reduz a 15 Mb. Deste modo, ao final da edição e transformação de cada quadro editado em imagem bitmap, tem-se um total de 60 imagens. Como cada imagem ocupa cerca de 1 Mb, necessitar-se-á de, no mínimo, 60 Mb para armazenar as imagens resultantes de um levantamento de 1 minuto. A uma velocidade de 60 Km/h, a extensão coberta seria de aproximadamente 1 Km (uma imagem a cada 17 metros). Considerando-se o par de câmaras, o espaço em disco necessário para armazenar as imagens de um levantamento será o dobro do valor necessário para armazenar os dados de uma única câmara. Se fosse utilizado o formato JPEG, cada imagem ocuparia cerca de 100 Kb (≈ 10 vezes menor). Partindo desta análise, verifica-se a necessidade de um gerenciador de dados que tenha a capacidade e/ou funcionalidade para armazenar, atualizar, excluir e agilizar consultas sobre as informações contidas no(s) levantamento(s). Antes de montar 5 um sistema para gerenciar estas informações é necessário criar uma estrutura capaz de armazená-las com segurança e, para isto, utiliza-se o conceito de banco de dados. 1.2 Banco de Dados e Banco de Imagens A tecnologia de banco de dados é uma das áreas mais recentes da ciência da computação, pois teve início apenas no final da década de 60. No entanto, devido à sua grande importância, tornou-se rapidamente foco de vários estudos, tanto práticos como teóricos. De um modo simplificado, pode-se dizer que um Banco de Dados é um conjunto de informações ou dados armazenados de forma organizada e inter- relacionadas, para a utilização por um ou vários usuários. Sistemas de banco de dados são concebidos para gerenciar grandes quantidades de informação. O gerenciamento dos dados envolve tanto a definição de estruturas para armazenamento da informação como a provisão de mecanismos para manipulá-la. Em adição, o sistema de banco de dados deve proporcionar a segurança das informações armazenadas no banco de dados, mesmo em casos de queda do sistema operacional, ausência de energia elétrica ou de tentativas de acessos não autorizados (Korth & Silberschatz,1989). Um sistema de banco de dados envolve quatro componentes maiores: dados, hardware, software e usuários (Date,1986). A definição das informações necessárias no banco de dados, bem como o hardware e o software utilizados, são estritamente dependentes do usuário, ou seja, da finalidade das informações armazenadas. Dentre os modos de banco de dados, o mais utilizado é o integrado. Mas, por que usar um Banco de Dados Integrado1? A resposta a esta pergunta pode ser 1 Banco de dados integrado pode ser imaginado como sendo a unificação de diversos arquivos que, de outra forma, seriam distintos, eliminando parcial ou totalmente qualquer redundância entre aqueles arquivos. 6 resumida nas seguintes vantagens: diminui ou elimina a redundância de informação, evita parcialmente a inconsistência dos dados, propicia um compartilhamento dos dados, controla os padrões definidos, melhora a segurança com estas restrições, mantém a integridade da informação e permite balancear necessidades conflitantes. Segundo Teorey (1990), o ciclo de vida de um banco de dados depende das seguintes etapas: análise das necessidades, projeto lógico, refinamento, distribuição dos dados, esquema local e projeto físico e implementação do banco de dados, monitoramento e modificação. Esta última fase compreende a fase de checagem e validação do sistema implementado. Para garantir que todas estas etapas sejam realizadas com êxito surge a idéia de um dispositivo chamado Sistema Gerenciador de Banco de Dados (DataBase Management System - DBMS). Este gerenciador de banco de dados consiste numa coleção de dados inter- relacionados e numa coleção de programas que acessam esses dados. O objetivo central de um banco de dados é proporcionar ao usuário uma visão abstrata dos dados, isto é, o sistema esconde certos detalhes de como os dados são armazenados ou mantidos. O gerenciador de banco de dados é um módulo de programa que provê a interface entre os dados de baixo nível armazenados no banco de dados e os programas de aplicação e consultas submetidas ao sistema. Tal gerenciador de banco de dados é responsável pela interação com o gerenciador de arquivos do sistema operacional, pela garantia de integridade e segurança, pelo salvamento e recuperação e pelo controle de concorrência (Korth,1989). A utilização de banco de dados na Cartografia vem sendo pesquisada, principalmente com o surgimento dos Sistemas de Informações Geográficas. Até 1994 a utilização de banco de dados ocorria em trabalhos pequenos, locais ou regionais; hoje, a grande fatia das aplicações está direcionada para a Internet, como por exemplo, sistemas 7 para visualização de imagens de satélite (Osaki,1996), interação visual (catálogo) com dados espaciais de grandes áreas (Walcher,1996) e sistema de informação ambiental através da visualização de mapas e imagens (Wiesel et al.,1996). Com a evolução tecnológica que ocorreu e que continuamente vem acontecendo, novos tipos de SIGs estão sendo implementados, onde se destacam os SIGs 3D (Kofler et al.,1996), Orientados a Objetos (Govorov & Khorev,1996; Gong & Li,1996) e os SIGs Universais (Derényi & Fraser,1996). Neste último, os dados cartográficos vetoriais e raster podem ser processados e gerenciados, abrindo novas possibilidades para a análise espacial. Outra aplicação do banco de dados está no auxílio ou contribuição de dados externos para outras aplicações, dentre elas, a análise de imagens aéreas (Bordes et al.,1996), na automação da orientação exterior através de modelos de arame (3D-Wireframe) para a determinação de pontos de controle no terreno (Läbe & Ellenbeck,1996) e arquivos de grandes imagens de diferentes escalas para uma representação detalhada da superfície do planeta e suporte para a busca de dados (com alta resolução) em áreas de interesse (Rehatschek,1996). Com todas estas classificações, verifica-se que não há um critério bem definido. Isto porque uma única aplicação é classificada de diversos modos e isto dificulta a análise do sistema em si, pois cada idealizador, classifica conforme a sua vontade. Diante deste quadro pode-se concluir que a importância de um meio que gerencie todas essas informações coletadas pela UMMD, será cada vez mais solicitado. Considerando ainda que os SMMD coletam uma grande quantidade de imagens, há a necessidade de armazenar não somente os dados alfanuméricos, mas também as imagens e todos os seus atributos. Daí vem a noção de banco de imagens, ou seja, um banco de dados com imagens armazenadas. 8 No caso destes sistemas, onde a imagem é o elemento principal, é fundamental a modelagem e desenvolvimento de um banco de imagens. Considerando que as imagens são tomadas em posições conhecidas (coordenadas GPS) e é possível determinar sua atitude através de fototriangulação ou obter diretamente através de um sistema inerceial (INS), pode-se conceber então um banco de imagens com imagens orientadas ou georreferenciadas. 1.3 Proposição Buscando a melhor utilização das imagens e das informações relacionadas a cada uma delas, foi proposta a elaboração de um banco de imagens, chamado de Banco de Imagens Georreferenciadas (BIG). Além da melhor utilização das imagens, deve-se pensar também que a quantidade de informações (imagens e dados alfanuméricos) que a UMMD coleta é muito grande. Deste modo, a construção de um dispositivo que gerencie estas informações é de vital importância. Ou seja, deve existir um gerenciador para inserir novas informações ou ainda alterar e excluir informações que estejam desatualizadas ou que não sejam mais necessárias. Analisando a aplicabilidade de um sistema como o BIG, pode-se destacar: ü utilização em administrações municipais para a localização, visualização e gerenciamento das informações referentes a um arruamento, a um lote ou a uma construção; ü interesse de empresas e órgãos públicos relacionados ao planejamento, construção, conservação e utilização de rodovias e ferrovias; 9 ü organizações responsáveis pelos serviços de utilidade pública, tais como: água e esgoto, energia elétrica, telecomunicações, coleta de lixo, engenharia de transporte, tráfego e trânsito, segurança e saúde pública, etc; ü mapeamento topográfico de detalhes urbanos por meio do caminhamento fotogramétrico (como exemplo, cita-se a localização de postes da rede de distribuição elétrica e telecomunicações, de boca de lobos, etc). 1.4 Objetivos 1.4.1 Geral Desenvolver um Banco de Imagens Georreferenciadas para facilitar experimentalmente a compreensão de uma aplicação do Mapeamento Móvel. Ou seja, com o desenvolvimento do BIG estar-se-á executando mais uma etapa do desenvolvimento do SMMD, além de verificar, na prática, o funcionamento completo do próprio BIG. 1.4.2 Específico O objetivo específico do presente trabalho é a criação de um Banco de Imagens Georreferenciadas (BIG) com informações referentes aos parâmetros de orientação interior e exterior (relativa), informações relacionadas ao local, dia e hora da tomada, condições da pista e dos arredores e condições climáticas, de modo que a partir delas, seja possível realizar consultas para tomadas de decisões. 10 1.5 Estrutura do Trabalho Visando mostrar o desenvolvimento desta pesquisa, organizou-se este trabalho em 6 capítulos cujos temas estão a seguir descritos: No capítulo 2 são apresentados alguns conceitos básicos sobre a modelagem de dados e sobre o ambiente de programação C++ Builder. O capítulo 3 trata da modelagem e estruturação do BIG. Este é o primeiro passo na construção de um banco de dados, conforme será visto. Já o capítulo 4, corresponde à implementação propriamente dita do programa. Neste tem-se como o programa foi desenvolvido e seus diversos módulos apresentados em detalhe. O capítulo 5 aborda a análise e aplicações do BIG, apresentando alguns benefícios e restrições do uso. Neste encontra-se uma discussão sobre a situação da primeira versão concluída. Finalmente, o capítulo 6 destaca as conclusões e recomendações referentes ao projeto e ao programa, procurando discutir e ajudar nas próximas versões que este terá. Para facilitar a leitura e a compreensão, os procedimentos para a utilização do software e o detalhamento das funções são apresentados nos anexos ao final do trabalho. Estes anexos servem para mostrar como é o uso do programa. 11 2 CONCEITOS BÁSICOS Neste capítulo serão mostrados alguns conceitos básicos sobre banco de dados e modelagem de dados. A criação de um banco de dados necessita de um grande planejamento anterior. Isto se deve ao fato que toda a estruturação indicará o desenvolvimento do sistema. Deve-se projetar todos os objetivos almejados e acima de tudo descrevê-los detalhadamente. No caso deste trabalho, o planejamento se resume à experiência adquirida pelos pesquisadores no decorrer do desenvolvimento de projeto anteriores relacionados ao tema geral, já que não há literatura específica sobre o assunto. A existência de um banco de dados por si só, não é muito lógica, pois este, só existe quando surge uma necessidade. Neste projeto, as necessidades a serem solucionadas pelo BIG foram definidas pelo LaMMov, chamado de cliente. O LaMMov é o laboratório onde é feito todo o processamento das informações coletadas pela UMMD. Trabalham 6 pessoas, todas no desenvolvimento do Sistema Terrestre de Mapeamento Digital da Unesp/FCT. A principal necessidade do cliente é de armazenar, de forma estrutura, todas as informações obtidas pela UMMD, e além disso, possibilitar consultas sobre estas informações. Neste projeto, as consultas que deveriam ser solucionadas foram: quando, onde e quem tomou a imagem; quais eram as condições ambientais no momento da tomada de uma determinada imagem; quais as imagens referentes a um determinado cliente, projeto, data ou rua. Com base nestas necessidades que foram desenvolvidas todas as etapas seguintes do projeto. 12 2.1 Modelagem de um Banco de Dados A modelagem de um banco de dados compreende três fases: o modelo conceitual, o modelo de representação e o modelo de implementação. Estas modelagens são realizadas nesta seqüência e, em sendo desenvolvidas corretamente, proporcionam um produto final, se não exato, muito próximo do desejado. 2.1.1 Modelo Conceitual O esquema global, no qual são mostrados todos os dados e seus relacionamentos, é desenvolvido usando técnicas de modelagem de dados como por exemplo, entidade-relacionamento (E-R). A base do modelo E-R consiste de três classes de objetos: entidade, relacionamento e atributo (figura 4). As entidades são os objetos de dados principais sobre o qual a informação deve ser coletada; elas, usualmente, denotam uma pessoa, um lugar, uma coisa ou qualquer informação de interesse. Sua representação é feita através de um retângulo com o nome da entidade dentro. O relacionamento representa uma associação do mundo real entre uma ou mais entidades. Os relacionamentos, por cardinalidade, mais comuns que ocorrem na prática são: um para um, um para muitos e muitos para muitos. Um losango que conecta as entidades é a representação de um relacionamento no diagrama, sendo que o nome do relacionamento é escrito dentro do losango. Os atributos são características das entidades de modo a descrevê-las com maiores detalhes. Uma ocorrência particular de um atributo dentro da entidade ou relacionamento é chamado atributo valor (domínio). A representação de um atributo é uma elipse com o nome do atributo dentro (Teorey, 1990). 13 Figura 4 - Objetos básicos do modelo E-R utilizados no BIG, baseado nos conceitos de Chen(1976) A figura 5 mostra os três tipos de relacionamentos por conectividade. Os números ao lado da entidade representam o grau de relacionamento. Figura 5 - Tipos de relacionamento por conectividade O modelo conceitual de um projeto só pode ser dito finalizado quando o cliente, com o analista, verificar, testar e aprovar a modelagem. Feito isso, o próximo passo é a transformação deste modelo para o modelo de representação. 14 2.1.2 Modelo de Representação O modelo de representação compreende como as informações (tabelas, relacionamentos, campos chaves, etc) estão armazenadas e estruturadas no banco de dados. Nesta fase, são escolhidas as tabelas que comporão a base de dados. Esta escolha é feita com base no modelo conceitual concluído anteriormente. Basicamente, cada entidade gera uma tabela, sendo que, nos casos onde há um relacionamento “muitos para muitos”, entre duas entidades, deve ser criada uma nova tabela para receber o relacionamento. A passagem do modelo conceitual para o modelo de representação nada mais é do que transformar o diagrama gráfico do papel em comandos para o computador (definição da implementação). Esta transformação já dá a definição das tabelas, quais os relacionamentos que devem ter entre elas e, principalmente, quais as informações que devem ser armazenadas em cada tabela. 2.1.3 Modelo de Implementação O modelo de implementação é a última fase da modelagem do banco de dados. Esta fase é responsável pela criação do banco de dados propriamente dito. Depois desta fase é possível a inserção, alteração e exclusão de registros, além de consultas sobre as informações armazenadas. 15 2.2 Ambiente de Programação e o Banco de Dados Paradox A linguagem de programação do ambiente C++ Builder é a linguagem C orientada a objetos (C++). Por este motivo, todos os conceitos existentes na estrutura orientada a objetos é válida para a linguagem, tais como os conceitos de classe, objeto, componente, propriedade, evento, etc. Mesmo sendo orientada a objetos, um modelo E-R pode ser implementado sem problemas dentro deste ambiente, já que o acesso às tabelas de dados pelos componentes do C++ Builder, não depende de como eles foram modelados. O C++ Builder é um ambiente completo, pois abrange desde a estrutura da linguagem e ambiente de programação até a parte de compilação e “linkagem” dos dados. A figura 6 apresenta uma visão do compilador com suas barras de ferramentas no topo, o gerenciador de propriedades e eventos à esquerda e o formulário e a unidade de código ao centro. Dentre as ferramentas destacam-se as responsáveis pela criação da parte visual (a que fará a interação com o usuário), pela emissão dos relatórios, pela ligação programa/banco de dados e as ferramentas próprias para a manipulação do banco de dados. Devido à versão do compilador ser acadêmica e standard, ele não permite a utilização de um banco de dados de grande porte, como por exemplo o Oracle. Então optou-se em utilizar o banco de dados padrão do C++ Builder, o Paradox. 16 Figura 6 - Compilador C++ Builder v3.0 Dentro do Paradox são criadas as tabelas, definidos todos os nomes dos campos e seus formatos, as chaves primárias e secundárias das tabelas, os controles dos dados e, principalmente, o relacionamento entre as tabelas. Todas estas etapas podem ser realizadas dentro do compilador utilizando a linguagem SQL, mas neste projeto escolheu-se em utilizar a primeira opção. O C++ Builder funciona como um gerenciador quando está-se trabalhando com tabelas externas. Isto se deve ao fato de que ele próprio realiza as verificações de caminho das tabelas, de configuração, de análise de entrada, de salvamento e de recuperação dos dados. Não se trabalha diretamente com a tabela dentro do compilador e sim com componentes ou objetos que são associados às tabelas. Estes componentes possuem propriedades, eventos e métodos para manipular as informações das tabelas e associá-las, alterá-las e excluí-las quando necessário. Isto apresentado, pode-se passar para as fases de desenvolvimento propriamente dito do projeto. 17 3 MODELAGEM E ESTRUTURAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS A modelagem e a estruturação de um banco de dados dependem de vários fatores e de várias etapas. Dentre os fatores destacam-se a necessidade e a aplicação a que se destina. Quanto às etapas, tem-se desde o primeiro contato com o usuário para saber o que se pretende solucionar até a fase de implementação. Da primeira parte, ou seja, a necessidade do usuário e sua realidade, é construído o modelo lógico ou conceitual do projeto. Já as fases seguintes dependem do analista ou do programador, pois são as fases de definição da estrutura física dos dados (montagem de tabelas, códigos, relacionamentos, etc) e da criação do programa propriamente dito (implementação do modelo). Antes da criação da estrutura física dos dados e depois do modelo lógico, há uma fase intermediária na qual são definidos como os dados deverão estar após sua criação física, ou seja, como deverá ser seu modelo de representação. A última fase do processo de criação de um banco de dados é a implementação em computador do modelo de representação. Esta etapa é feita exclusivamente pelo programador. A ausência de um cliente específico fez com que se considerasse neste projeto o cliente como o próprio LaMMov. Isto foi motivado pela necessidade de organizar a quantidade crescente de imagens georreferenciadas. O BIG foi desenvolvido para permitir uma visão de como se comportam os dados e quais os rumos que as pesquisas seguintes deveriam tomar a fim de permitir uma maior integração com possíveis clientes reais. 18 3.1 Modelo Conceitual Utilizando o diagrama E-R, a representação do modelo conceitual do BIG (figura 7) tem a entidade IMAGEM como uma entidade forte, enquanto as outras entidades são ditas normais. As letras e números próximos às entidades dizem respeito ao tipo de relacionamento (grau de cardinalidade). Por exemplo, no caso da entidade câmara com a entidade imagem, temos um relacionamento um (1) para muitos (N) porque uma única câmara pode capturar muitas imagens. A modelagem foi definida como está porque se desejava que a imagem fosse o foco principal, já que ela é o elemento mais importante. Deste modo, todas as outras informações deveriam ser ou estar correlacionadas com a imagem. Figura 7 - Modelo Conceitual do BIG 19 Após a finalização do modelo conceitual, deve-se realizar a passagem do modelo acima para a enumeração das possíveis tabelas que irão compor o banco de dados. Este processo é chamado de criação do modelo de representação. 3.2 Modelo de Representação Com base no modelo conceitual são definidos os níveis ou planos de informações a serem criados, bem como suas características. Nesta fase são definidas as tabelas, os campos que comporão as tabelas, seus relacionamentos para tornar verdadeiro o modelo conceitual e também como estes dados deverão ser armazenados. Cada entidade da figura 7 deu origem a uma tabela de dados. Como o relacionamento entre projeto e imagem é de muitos para muitos, foi criada uma outra tabela para armazenar este relacionamento. Nos outros relacionamentos, foram criados campos nas tabelas para receberem o relacionamento. A partir da definição das tabelas, passou-se à definição dos nomes dos campos das tabelas, ou seja, criação dos campos referentes a cada atributo das entidades. Nas tabelas seguintes são apresentados os nomes das tabelas que compõem a base de dados do BIG, bem como o nome dos campos, o tipo de dado e o tamanho dos campos. Nestas tabelas que seguem, a seguinte legenda é válida para a coluna TIPO. + : dado do tipo auto-incremento (próprio do banco de dados) A: dado do tipo alfanumérico D: dado do tipo data I : dado do tipo inteiro L: campo Lookup N: dado do tipo numérico 20 T: dado do tipo hora * : índice primário ou chave primária TABELA 2 – Tabela ENDEREÇO do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_endereco + * Índice primário Nome_rua A 70 2 Índice secundário Nome_bairro A 40 2 Índice secundário Codigo_cidade N Nome_cidade L Nome_estado L Na tabela 2, os campos referentes ao nome da cidade e do estado (Nome_cidade e Nome_estado) estão relacionados ao local onde a imagem foi tomada. TABELA 3 – Tabela CLIENTE do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_cliente + * Índice primário Nome_cliente A 40 2 Índice secundário / Campo Obrigatório Responsavel A 40 Telefone A 20 Cidade A 40 Estado A 2 TABELA 4 – Tabela IMAGEM/PROJETO do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_imagem I * Índice primário Codigo_projeto I * Índice primário Nome_projeto L Nome_Imagem L Caminho_Imagem L 21 TABELA 5 – Tabela CIDADE do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_cidade I * Índice primário Nome_cidade A 40 2 Índice secundário Estado A 2 Na tabela 5, os campos Nome_cidade e Estado são referentes ao local de onde pertence o cliente do projeto. Deste modo, os campos Nome_cidade e Nome_estado da tabela 2 não estão relacionados com os campos Nome_cidade e Estado da tabela 5. TABELA 6 – Tabela CÂMARA do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_camara + * Índice primário Nome_camara A 30 2 Índice secundário / Campo Obrigatório Tipo_camara A 25 Campo obrigatório Tamanho_imagem A 10 Valor default (0x0) Tamanho_pixel N Valor default (0) Distancia_focal N Valor default (0) Param_x0 N Valor default (0) Param_y0 N Valor default (0) Param_k1 N Valor default (0) Param_k2 N Valor default (0) Param_k3 N Valor default (0) Param_p1 N Valor default (0) Param_p2 N Valor default (0) Desvio_distancia_focal N Valor default (0) Desvio_param_x0 N Valor default (0) Desvio_param_y0 N Valor default (0) Desvio_param_k1 N Valor default (0) Desvio_param_k2 N Valor default (0) Desvio_param_k3 N Valor default (0) Desvio_param_p1 N Valor default (0) Desvio_param_p2 N Valor default (0) 22 TABELA 7 – Tabela IMAGEM do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_imagem + * Codigo_endereco I Codigo_camara I Condicao/_pavimento A 20 Posicao_sol A 20 Posicao_sensor A 15 Posicao_imagem A 10 Natureza_pista A 20 Tipo_pista A 25 Nome_imagem A 20 2 Índice secundário / Campo obrigatório Caminho_imagem A 100 Campo obrigatório Condicao_iluminacao A 25 Data_levantamento D 2 Índice secundário / Campo obrigatório Hora_levantamento T 2 Índice secundário / Campo obrigatório Coord_cpxe N 2 Índice secundário / Campo obrigatório Coord_cpyn N 2 Índice secundário / Campo obrigatório Coord_cpzh N 2 Índice secundário / Campo obrigatório Ang_omega N Valor default (0) Ang_fi N Valor default (0) Ang_kapa N Valor default (0) Desvio_coord_cpxe N Valor default (0) Desvio_coord_cpyn N Valor default (0) Desvio_coord_cpzh N Valor default (0) Desvio_ang_omega N Valor default (0) Desvio_ang_fi N Valor default (0) Desvio_ang_kapa N Valor default (0) Fuso A 4 23 A idéia de dar nome à imagem, vem de como será a busca desta imagem, pois, suponha que necessite de uma determinada imagem. Deverá ser conhecido à priori, o projeto, ou o cliente, ou a data do levantamento, ou a rua onde foi tomada ou ainda o nome dela. Se a nome for dado arbitrário, seqüencialmente por exemplo, este último modo de consulta seria impossibilitado. TABELA 8 – Tabela PROJETO do banco de imagens Nome do Campo Tipo Tamanho Chave Observação Codigo_projeto + * Índice primário Nome_projeto A 30 2 Índice secundário / Campo Obrigatório Finalidade_projeto A 100 Codigo_cliente I Campo obrigatório Data_levantamento D Campo obrigatório Hora_levantamento T Campo obrigatório Nome_cliente L Com a definição de todos os campos que formam as sete tabelas, deve-se agora definir como serão os relacionamentos entre elas de modo que o modelo conceitual seja praticado. Antes, vale ressaltar que a maioria dos campos Lookup constantes nas tabelas acima não foram definidos nesta fase e sim foram acrescentados na fase de implementação, de modo a dinamizar o código, sem fugir à metodologia. A criação do relacionamento foi a última etapa desta fase, já que este só pôde ser definido após a criação de todas as tabelas que compõem a base de dados do sistema (Tabela 9). TABELA 9 – Relacionamentos na base de dados do BIG Tabela Filha Campo da Integridade Relacional Tabela Pai IMAGEM Codigo_camara CÂMARA IMAGEM Codigo_endereco ENDEREÇO ENDEREÇO Codigo_cidade CIDADE PROJETO Codigo_cliente CLIENTE IMAGEM/PROJETO Codigo_projeto PROJETO IMAGEM/PROJETO Codigo_imagem IMAGEM 24 Com todas estas informações definidas, conferidas e aprovadas, deve- se converter o modelo de representação para o modelo de implementação. Utilizando as definições das tabelas acima pôde-se montar o modelo de representação final para o projeto. A última etapa de modelagem (modelo de implementação) será visto em detalhes no próximo capítulo. 25 4 IMPLEMENTAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS Com base no que foi discutido até agora, a estruturação e implementação do BIG foi feita levando-se em consideração grandes grupos ou módulos de rotinas, onde rotinas semelhantes fossem agrupadas. Assim sendo, criaram-se os seguintes módulos: cadastramento, gerenciamento, consultas e relatórios, cada módulo portanto, designado por sua finalidade. As informações referentes à cada imagem devem seguir uma certa regra para serem inseridas no BIG. Primeiramente, deve-se cadastrar todas as informações referentes ao projeto, ao cliente, ao local e à câmara. Apenas após estas informações estarem inseridas é que se pode inserir um registro com uma imagem. As informações referentes à imagem são: projeto, cliente, local, data de tomada, local do levantamento, orientação exterior da imagem, condições do pavimento e condições metereológicas. A tela principal de entrada do programa é muito simples (figura 8). Possui o menu com os quatro módulos como título, além de ícones de atalhos para a maioria das funções. Na parte inferior são mostrados o dia da semana, a data e a hora local. Nos itens seqüentes são descritos os módulos citados acima de modo geral, já que o detalhamento operacional do software é apresentado nos anexos A, B, C e D. São apresentados também os formulários que pertencem a cada módulo (a noção de formulário vem do C++ Builder que os caracterizam como form). 26 Figura 8 - Tela principal do BIG 4.1 Módulo de Cadastramento Este é responsável pela inserção das informações referentes ao projeto, ao cliente, à câmara e à localização (rua, bairro, cidade). Foram desenvolvidos cinco formulários, cujos nomes são: Cadastrar Projeto, Cadastrar Cliente, Cadastrar Cidade, Cadastrar Endereço e Cadastrar Câmara. As figuras 9 e 10 mostram dois formulários, o Cadastrar Projeto e o Cadastrar Câmara. A finalidade dos formulários são conforme os nomes de cada. Quanto às informações necessárias para o preenchimento dos formulários, temos: nome do projeto, cliente, data do levantamento, hora do levantamento, finalidade, endereço do cliente, cidades do cliente e do levantamento, endereço do levantamento, nome da câmara, tipo da câmara, tamanho da imagem e do pixel, além dos parâmetros de orientação interior. 27 Assim como os outros formulários que serão vistos, estes dois mostrados possuem rotinas de verificação de valores, testes de validação, controles de valores nulos e um controlador para garantir um perfeito controle no armazenamento dos dados nas tabelas. Figura 9 - Formulário para Cadastrar Projeto Figura 10 - Formulário para Cadastrar Câmara 28 4.2 Módulo de Gerenciamento Este é o módulo mais complexo em termos de programação do banco de dados, pois é o responsável pela inserção, alteração ou exclusão de dados relacionados à imagem. Preferiu-se fazer esta distinção entre cadastramento de informações gerais e inserção de dados referentes à imagem, pois como este é um banco de imagens, parte-se do princípio que não se pode inserir uma informação completa sem a imagem. Pode-se cadastrar um projeto ou um cliente, mas não se pode dizer que num lugar qualquer, de uma cidade tal, foi tomada uma imagem com os parâmetros de orientação interior e exterior conhecidos, sem possuir a imagem. Desse modo, quando se falar de inserção de dados, está-se referindo ao cadastramento de um conjunto de informações que dizem respeito ao local onde a imagem foi tomada, suas características, o projeto, o cliente e o tipo de câmara. As figuras 11 e 12 referem-se ao item de inserção de um registro. São dois formulários porque o primeiro é responsável pela inserção de dados referentes ao projeto em geral enquanto o outro é para as informações referentes à imagem. O item alteração é composto por três formulários (figuras 13, 14 e 15). O primeiro é responsável pela consulta do registro que se deseja alterar. Esta busca pode ser feita pelo nome da imagem, pelo nome do projeto ou pelo nome da rua. Uma vez escolhido o item para alterar, são chamados dois formulários similares às figuras 11 e 12, com as informações do registro e a partir destes dois formulários pode-se realizar as alterações desejadas no registro. Após a realização das alterações, salva-se as informações novas substituindo as antigas. 29 Figura 11 - Formulário para Inserir Registro – parte 1 Figura 12 - Formulário para Inserir Registro – parte 2 Figura 13 - Formulário para Alterar Registro – parte 1 30 Figura 14 - Formulário para Alterar Registro – parte 2 Figura 15 - Formulário para Alterar Registro – parte 3 Finalmente, a figura 16 mostra o formulário de exclusão de dados. Para a exclusão, basta localizar o item que se queira apagar do banco de dados, selecioná- lo e excluí-lo. Esta busca pode ser feita através das mesmas opções do item alteração. Uma vez excluído o registro, não há possibilidade de recuperá-lo, nem mesmo a imagem. 31 Figura 16 - Formulário para Excluir Registro 4.3 Módulo de Consulta Este módulo é para fins de procura ou pesquisa sobre um determinado registro já cadastrado. Foram desenvolvidos cinco formulários, sendo quatro deles mostrados nas figuras 17, 18, 19 e 20. Os cinco formulários são: Consulta por Projeto, Consulta por Cliente, Consulta por Imagem, Consulta por Rua e Consulta por Data do Levantamento. As figuras referem-se ao formulário de Consulta por Projeto, Consulta por Imagem, Consulta por Rua e Consulta por Data do Levantamento, respectivamente. Em todos os formulários deve ser inserido um valor de entrada e depois deve ser pedida a pesquisa (área superior do formulário). Se houver registros com o valor desejado, a seção “Resultado da Consulta” apresenta todos os registros (área central do formulário). A Consulta por Rua tem caráter de localização ou posicionamento, enquanto que a por Data do Levantamento tem caráter temporal. 32 Figura 17 - Formulário para Consulta por Projeto Figura 18 - Formulário para Consulta por Imagem Figura 19 - Formulário para Consulta por Rua 33 Figura 20 - Formulário para Consulta por Data de Levantamento Basicamente todos possuem a mesma estrutura; é entrado um valor e pedida a busca. Se houver registro cadastrado no banco com o valor pedido, este ou estes serão mostrados na tela. São mostradas as informações principais do registro, além da imagem no esquema thumbnail. Esta consulta é apenas visual, não sendo permitido qualquer tipo de impressão em papel. A impressão foi projetada no módulo de emissão de relatórios. 4.4 Módulo de Emissão de Relatórios A última parte implementada do programa foi o módulo de geração de relatórios. Como os demais itens, foi projetado um único módulo para esta finalidade. Neste, uma consulta é realizada e mostrada no vídeo na forma de relatório (report). Este relatório pode ser impresso ou simplesmente consultado visualmente. A diferença deste módulo em relação ao anterior, além da possibilidade de impressão, é a não visualização da imagem (neste módulo são impresso apenas dados alfanuméricos). 34 Este módulo tem apenas um formulário (figura 21) e nele pode-se optar pela emissão do relatório por consulta por nome de imagem, por nome de projeto ou por nome de rua. Para cada opção de tema de relatório, há ainda a opção de um relatório simples, com informações básicas referentes aos registros, ou um relatório completo, com todas as informações relacionadas aos registros encontrados na consulta (figuras 22 e 23, respectivamente). Figura 21 - Formulário para Emissão de Relatórios Figura 22 - Exemplo da emissão de um relatório simples por consulta de Endereço (Rua) 35 Figura 23 - Exemplo da emissão de um relatório completo por consulta de Endereço (Rua) Com a finalização deste módulo, deu-se por completada a primeira versão do banco de imagens georreferenciadas para um sistema de mapeamento móvel. Infelizmente, o compilador C++ Builder apresentou alguns problemas, sendo a maioria insignificante dentro do contexto do sistema. Mas um, em especial, dificultou muito a execução do módulo de emissão de relatórios. O componente responsável pela montagem do relatório (DataSet) acusou erro cíclico nos dados, mesmo este estando desativado. Com isto, houve a necessidade de se buscar uma outra forma para implementar o módulo. A saída encontrada foi criar um outro programa, realizando uma cópia dos dados e criando uma tabela temporária para o armazenamento dos dados selecionados pela consulta. Deste modo, o módulo de emissão de relatórios deixou de fazer parte integrante do BIG, mas ficou sendo um aplicativo dependente dele. Por este motivo, sacrificou-se, algumas vezes, a melhor solução devido aos problemas ocorridos, mas deixando de respeitar a modelagem dos dados. 36 5 ANÁLISE DO BANCO DE IMAGENS GEORREFERENCIADAS Este capítulo apresenta uma análise visual e técnica do programa desenvolvido. Como não há possibilidade de fazer uma comparação ou análise numérica do mesmo, será mostrada uma análise com base em observações práticas (rendimento, aplicabilidade, facilidade, velocidade e segurança). O primeiro ponto a ser tratado está no gerenciamento das imagens dentro do banco. Como o Paradox não suportaria a grande quantidade de imagens que seria inserida (média de 1200 imagens para cada 10 minutos de levantamento), foi desenvolvido um gerenciador de modo que no banco de dados fossem salvos apenas os caminhos (path) da imagens. Ou seja, quando uma consulta é realizada, o programa busca o caminho da imagem no registro e a partir deste caminho, vai no disco rígido e abre a imagem. Quando se deseja apagar ou alterar um registro, o gerenciador se encarrega de apagar a imagem no disco ou alterar o nome da imagem, caso seja necessário. O local onde a imagem é salva depende do projeto a que ela pertence. Quando se instala o programa, são criadas duas pastas na pasta Arquivos de Programas do Windows. Uma pasta serve para armazenar as tabelas e a outra para armazenar as imagens. Nesta última, cada projeto criado no BIG pelo usuário, gera uma pasta de dados, na qual as imagens são salvas. Mesmo com as imagens armazenadas fora do BIG (numa pasta externa), o acesso às imagens e informações é rápido. Foram realizados diversos testes no módulo de gerenciamento (inserção, alteração e exclusão), consulta e relatório. Os testes foram de acesso à imagem, alteração de valores no banco de dados, exclusão de dados, gerenciamento das imagens nas pastas dos projetos, velocidade do acesso às informações 37 e facilidade de uso do programa. Os critérios para a análise da qualidade foram: retorno da informação com segurança, a espera pelo operador para obter a informação desejada, a análise da interface, integridade do banco de dados e a utilização para o armazém das informações. Não foi constatado nenhum erro de acesso ou violação do sistema e a resposta do sistema ficou entre 1 e 4 segundos. Este está muito estável, para uma quantidade pequena de imagens armazenadas (menos que 100 imagens). Um outro ponto que deve ser analisado é com relação à segurança dos dados. Por não ser um banco de dados de grande porte, as ferramentas de proteção são muito frágeis. Além do mais, as imagens sendo salvas numa pasta externa permitem ao usuário acesso direto a elas sem a necessidade do banco. Com isso tudo, caso alguém apague ou renomeie alguma imagem, a integridade dos dados é rompida. Desde modo, há a necessidade de melhorar esta proteção. Uma questão que se mostrou importante no desenvolvimento foi a interação com o usuário. Foram discutidos alguns esquemas e lay-out com o cliente (membros do laboratório) para a implementação final do BIG. Mesmo sendo a primeira versão, o programa está muito amigável, segundo avaliação do cliente. Foram criados vários ícones de modo a proporcionar um aumento da produtividade do trabalho, evitando grande número de acessos ao menu. Outro ponto importante desta interatividade são as mensagens de erro. Existem diversas mensagens que o sistema pode emitir e a grande maioria diz qual o problema que ocorreu, onde ocorreu e como pode ser solucionado (o próprio programa sugere uma solução). Uma limitação desta versão é que ela permite apenas o cadastramento individual das imagens, ou seja, mesmo possuindo o par estereoscópico, as imagens têm que ser cadastradas uma a uma. Isto implica num maior tempo de cadastramento. O mesmo ocorre no caso da alteração, exclusão ou consulta. Na consulta é ainda mais 38 complicado. Por exemplo: suponha que um cliente queira as imagens pertencentes a uma certa rua; ele terá que localizar todas as imagens daquela rua do lado direito e depois realizar uma outra consulta para localizar as imagens daquela mesma rua, mas do lado esquerdo. Se desejar realizar uma medição fotogramétrica, terá que pegar as duas imagens individuais e só depois poderá fazer medidas. Quando se planejou o BIG, não havia nenhum parâmetro para guiá-lo na modelagem, sendo assim, esta limitação só se tornou clara após a finalização do programa. Para solucionar estas limitações, deve-se realizar uma modelagem mais complexa dos dados. Ou seja, necessita-se voltar ao início do processo e definir os novos objetivos do programa, já que agora há vários parâmetros que podem direcionar a nova versão. O programa foi desenvolvido em aproximadamente 7 meses, considerando desde sua modelagem conceitual até a apresentação do programa. Neste período diversas alterações foram feitas. Uma das maiores alterações ocorreu no terceiro mês de desenvolvimento, onde, fazendo um estudo mais profundo da estruturação dos dados, concluiu-se que com a modelagem até então definida, não possibilitaria atingir todos os objetivos propostos. Assim sendo, modelou-se novamente o sistema (tabelas e relacionamentos) e recomeçou-se a implementação do programa. Como algumas funções já estavam implementadas, não foi preciso começar o programa desde o início. O resultado técnico final da implementação do BIG pode ser resumido conforme a tabela 10. Como o programa possui várias tabelas, além dos arquivos biblioteca e executáveis, foi desenvolvido um outro programa de modo a instalá-lo corretamente no computador. Para instalá-lo é necessário que o sistema operacional seja Windows (versão em português), possua no mínimo 32 Mb de memória RAM e 2 Mb de espaço em disco, além de um monitor de vídeo com resolução mínima de 1024 x 768 pixels. 39 TABELA 10 – Ficha técnica do programa Nome do Programa Banco de Imagens Georreferenciadas - BIG Linguagem de Programação C++ Builder Compilador C++ Builder 3 Standard Academic Sistema Operacional Windows 98 Banco de Dados Paradox Número de Tabelas de Dados* 8 Número de Formulários 30 Linhas de código ≈ 10.300 Tempo de compilação** 102,13 seg. Linhas compiladas ≈ 723.000 Versão 1.0 (Dezembro/2000) * no modelo de representação foram apresentadas 7 tabelas; a outra é uma tabela temporária utilizada no módulo de emissão de relatórios. ** computador K6 II, 400 MHz, 64 Mb RAM, 10 Gb HD. 40 6 CONCLUSÕES E RECOMENDAÇÕES Pelo presente trabalho, procurou-se mostrar a configuração final do desenvolvimento da primeira versão de um Banco de Imagens Georreferenciadas para um Sistema Móvel de Mapeamento. Diversas dificuldades foram enfrentadas no desenvolvimento do programa. A maior delas foi, sem sombra de dúvida, a de desenvolver um programa que cumprisse integralmente com os objetivos pré-determinados, ou seja, servisse como um protótipo para uma análise criteriosa da situação atual e que permitisse, para a próxima versão, correções e alterações de modo a aperfeiçoá-lo. Isto foi alcançado e hoje pode-se definir várias alterações de modo a permitir que se adapte a um cliente com necessidades mais específicas, visto que toda a modelagem e definição das informações foram escolhidas e definidas pelos pesquisadores, imaginando uma possível aplicação fotogramétrica na construção ou atualização de um mapa de ruas e rodovias. Outros problemas que merecem ser citados são: ü algumas raras vezes, as ferramentas do compilador não funcionaram como se esperava (como por exemplo o componente DataSet), talvez devido à versão do compilador (acadêmica), obrigando a buscar outros recursos ou soluções (criando uma tabela temporária para as consultas). A desvantagem do uso de uma versão acadêmica do software é justamente esta, pois o software vêm sem algumas opções ou ferramentas que a versão profissional possui; ü falta de bibliografia específica a respeito do assunto. O que se encontra muito na literatura é um sistema que gerencia imagens para uma consulta visual seja esta 41 consulta em terminal ou via Internet. A estruturação e modelagem dos dados para esta finalidade não são apresentados nos poucos trabalhos relacionados a este tema, talvez pela dificuldade e complexidade da modelagem ou mesmo pelo não interesse em divulgar a estrutura; ü a falta de parâmetros externos para direcionar o desenvolvimento do programa. Como não se conhece um programa similar na literatura ou mesmo no mercado, o desenvolvimento foi direcionado conforme a necessidade do laboratório. Este último item, deve-se ao fato que o LaMMov (neste caso, o cliente do projeto) está em fase de desenvolvimento e muitas de suas tarefas e necessidades ainda não estão consolidadas (estão em processo de consolidação). Diversas questões podem ser levantadas com relação ao futuro do banco de imagens. Basicamente, estas questões estão relacionadas com o próximo passo do desenvolvimento. Considerando este contexto, pode-se sugerir algumas recomendações para tal decisão: ü integrá-lo a mapas digitais, procurando ligar as informações alfanuméricas com as informações gráficas, permitindo uma visualização mais apropriada dos dados no contexto cartográfico; ü alterar a modelagem atual dos dados para permitir a utilização do par de imagens, tanto nas operações de gerenciamento, como nas consultas. Nesta modelagem, devem ser previstos mecanismos para permitir a integração com dados vetoriais e raster, possibilitar o armazenamento de informações referentes às feições nas imagens (estas podendo ser detectadas automaticamente) e ainda trabalhar com arquivos multimídia (imagens + som); 42 ü utilizar uma versão do compilador mais completa. Algumas restrições desta versão não existiriam numa versão mais atualizada ou numa versão profissional; ü possibilitar a montagem do par estereoscópico e proporcionar medidas precisas nas imagens de modo a poder realizar um interseção direta, determinando as coordenadas de pontos no terreno. O principal objetivo deste processo é poder restituir qualquer feição ou objeto do terreno à partir da leitura de coordenadas lidas nas imagens e da orientação exterior pré-determinada e inserida no banco. Utilizando um programa que consiga ler as imagens e orientações, que possua ferramentas para medidas precisas (leituras subpixel) e que tenha um módulo para a realização de um ajustamento destas informações, é possível determinar as coordenadas no terreno e estimar a precisão final do resultado; ü melhorar as ferramentas de consulta e de emissão de relatório, ampliando os itens de busca. Atualmente, só podem ser realizadas consultas simples. A idéia é que para a próxima versão possa-se realizar consultas combinadas, como por projeto e nome de imagem, ou por cliente e rua, etc. A emissão do relatório também pode ser incrementada de modo a permitir a escolha dos itens que se deseja constar no relatório. Estas consultas têm que ser definidas na modelagem inicial dos dados; ü trocar o gerenciador de banco de dados para um de grande porte, como por exemplo, o Oracle onde as imagens poderiam ser salvas dentro do BIG evitando a necessidade de desenvolvimento de um gerenciador. Esta é uma das alterações que deve ser implementada, pois o banco de dados Paradox não comporta uma quantidade muito grande de dados; por outro lado, o Oracle é um banco de dados mais complexo e necessita de uma maior análise na implantação; ü implementar módulos de extração de feições, de modo a auxiliar no processo de orientação das imagens e também na determinação das coordenadas no terreno destas 43 feições. A escolha de pontos no terreno para a realização da orientação das imagens é muito dispendiosa em termos de tempo e de trabalho. Com isso, este módulo eliminaria dois problemas que limitam muito a produtividade do SMMD. Analisando este panorama geral, conclui-se que as perspectivas para o desenvolvimento são as melhores. Automatizando as etapas de coleta de pontos, construindo um banco de imagens com funcionamento amplo, pode-se criar um sistema que disponibilize todas estas informações para consulta e coleta de dados via Internet. Isso possibilitaria uma consulta (ou até “viajar” pela área mapeada através da visualização do arquivo multimídia), uma busca ou mesmo uma análise à longa distância, independente de se conhecer ou não o sistema, ou ainda, o mais importante, não necessitando armazenar a grande quantidade de imagens em cada computador que necessitar do sistema. 44 REFERÊNCIAS BORDES, G., GUÉRIN, P., GIRAUDON, G. & MAÎTRE, H. Contribution of external data to aerial image analysis. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, 1996, v. 31, t. B4, p. 134-8, 1996. CHEN, P.P. The entity-relationship model – forward a unified view of data. ACM Trans. Database System, 1, 1. p. 9-36, 1976. DATE, C. J. Introdução a sistemas de banco de dados. Tradução de Hélio Auro Gouveia, Editora Campus, 4ª edição, Rio de Janeiro, 513p., 1986. DERÉNYI, E. & FRASER, D. Using images within a GIS for spatial analysis. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, 1996, v. 31, t. B4, p. 216-18, 1996. ELLUM, C. & EL-SHEIMY, N. The development of a backpack mobile mapping system. In: INTERNATIONAL CONGRESS OF ISPRS, 19., Amsterdam. International Archives..., ISPRS, CD-ROM. 8p, 2000. EL-SHEIMY, N. A mobile multi-sensor system for GIS applications in urban centers. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives..., ISPRS, v. 31, t. B2, p. 95-100, 1996. GONG, J. & LI, D. Design and implementation of an object-oriented GIS Software. In: INTERNATIONAL CONGRESS OF ISPRS, 18. Viena, International Archives... ISPRS, 1996, v. 31, t. B4, p. 299-304, 1996. GOVOROV, M.O. & KHOREV, A.G. Object-oriented GIS and representation of multi- detailed data. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, 1996, v. 31, t. B4, p. 445-50, 1996. HABIB, A. F. Estimation of motion parameters for stereo-image sequences using data association of linear features. The Ohio State University, Dissertation, Ph. D. Department of Geodetic Science and Surveying, , 129 p., 1994. HE, G. Design of a mobile mapping system for GIS data collection. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, v. 31, t. B2, p. 154- 9, 1996. HE, G. & ORVETS, G. Capturing road network data using mobile mapping technology. In: INTERNATIONAL CONGRESS OF ISPRS, 19., Amsterdam. International Archives..., 45 ISPRS, CD-ROM. 6p, 2000. KOFLER, M., REHATSCHEK, H. & GRUBER,M. A database for a 3D GIS for urban environmets supporting Photo-Realistic Visualization. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, v. 31, t. B2, p. 198-202, 1996. KORTH, H. F. & SILBERSCHATZ, A. Sistemas de banco de dados. Editora McGraw- Hill, São Paulo, 582p., 1989. LÄBE, T. & ELLENBECK, K.H. 3D-wireframe models as ground control points for the automatic exterior orientation. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, 1996, v. 31, t. B2, p. 218-23, 1996. LI, R., CHAPMAN, A., QIAN, L., XIN, Y. & TAO, C. VISAT: a real time system for highway spatial information acquisition. In: ASPRS-ACSM ANNUAL CONVENTION AND EXPOSITION, Reno, Proceedings... Bethesda: ASPRS & ACSM, v.1, p.344-9, 1994. ___. Mobile mapping for 3D GIS data acquisition. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, v. 31, t. B2, p. 232-7, 1996. ___. Object recognition and measurement from mobile mapping image sequences using Hopfield neural networks: part II. In: INTERNATIONAL SYMPOSIUM OF ISPRS, Cambridge, International Archives... ISPRS, v. 32, t. B2, p. 192-7, 1998. MARESCH, M. & DURACHER, P. The geometric design of a vehicle based 3 line CCD camera system for data acquisition of 3D city models. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives..., ISPRS, v. 31, t. B1, p. 121-7, 1996. NOVAK, K. & BOSSLER, J. D. Development and application of the highway mapping system of Ohio State University. Photogrammetric Record, 15(85):123-34, 1995. OLIVEIRA, R.A. & SILVA, J.F.C. Caminhamento Fotogramétrico Aplicados aos Sistemas Móveis de Mapeamento Digital Terrestre. X Congresso de Iniciação Científica, Livro de Resumos, Rio Claro. p83, 1998a. ____. Triangulação de uma seqüência de imagens digitais terrestres. In: CONGRESSO BRASILEIRO DE CADASTRO TÉCNICO MULTIFINALITÁRIO, 3., Florianópolis, Anais..., CD-ROM. 8p, 1998b. ____. Calibração de um par de vídeo câmaras digitais. XIX Congresso Brasileiro de Cartografia, CD-ROM, Recife, 4 p., 1999. OLIVEIRA, R.A., SILVA, J.F.C. & GALLIS, R.B. Banco de imagens georreferenciadas obtidas por um sistema móvel de mapeamento digital. CONGRESSO BRAS. DE CADASTRO TÉCNICO MULTIFINALITÁRIO, 4., Florianópolis, Anais..., CD-ROM, 10 p., 2000. OSAKI, K. Preliminary new satellite data retrieval system on world wide web. In: 46 INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, v. 31, t. B1, p. 150-3, 1996. REHATSCHEK, H. A Concept for a network-based distributed image data archive. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, v. 31, t. B2, p. 327-32, 1996. SILVA, A.R., BATISTA, J.C., OLIVEIRA, R.A., CAMARGO, P.O., SILVA, J.F.C. Surveying and mapping of urban streets by photogrammetric traverse. Mobile Mapping Technology Workshop, Anais..., Bangkok, 4 p., 1999. SILVA, J.F.C., CAMARGO, P.O., OLIVEIRA, R.A., GALLIS, R.B.A., GUARDIA, M.C., REISS, M.L.L., SILVA, R.A.C. A street ,map built by a mobile mapping system. In: INTERNATIONAL CONGRESS OF ISPRS, 19., Amsterdam, International Archives... ISPRS, v. 32, t. B2, p. 510-7, 2000. SILVA, J.F.C. & OLIVEIRA, R.A. Triangulation of a sequence of terrestrial digital images. In: ISPRS Commission II International Symposium on Data Integration – Systems and Techniques, Anais..., Cambridge, 5 p., 1998. SILVA, J.F.C., OLIVEIRA, R.A. & GALLIS, R.B. Georeferenced road image database. In: INTERNATIONAL SYMPOSIUM ON MOBILE MAPPING TECHNOLOGY, 3., Cairo, International Archives..., ISPRS, CD-ROM. 8 p., 2001. TEOREY, T.J. Database modeling & design: the fundamental principles. Morgan Kaufmann Publishers, São Francisco, 2nd edition. 277 p., 1990. TOTH, C. Mapping with a mobile image acquisition system. GeoInfo System, p. 35-37, 1995. VISINTINI, D. Direct together with indirect methods of sensor orientation. In: WORKSHOP OF ISPRS, Barcelona. International Archives... ISPRS, Anais..., p. 144-160, 1999. WALCHER, W. Visual interaction with very large spatial data sets. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... ISPRS, v. 31, t. B1, p. 197- 202, 1996. WANG, M., GUO, B. LI, D. & GONG, J. Research on match of GPS sinal and road information for mobile navigation system. In: INTERNATIONAL CONGRESS OF ISPRS, 19., Amsterdam, International Archives..., ISPRS, CD-ROM. 5 p., 2000. WIESEL, J., HAGG, W., KOSCHEL, A., KRAMER, R. & NICOLAI, R. A client/server map visualization component for an environmental information system based on www. In: INTERNATIONAL CONGRESS OF ISPRS, 18., Viena, International Archives... 47 ISPRS, 1996, v. 31, t. B2, p. 402-7, 1996. ZHAO, H & SHIBASKI, R. Reconstructing textured urban 3D model by fusing ground- based laser range image and video image. In: INTERNATIONAL SYMPOSIUM OF ISPRS, Cambridge, International Archives... ISPRS, v. 32, t. B2, p. 357-62, 1998. 48 ANEXO A – OPERAÇÃO DO MÓDULO DE CADASTRAMENTO A.1 Cadastrando o Projeto No menu Cadastrar e escolha a opção Projeto. A seguinte caixa de diálogo se abre para as informações serem inseridas. Após a inserção das informações, basta pressionar o botão cadastrar e as informações serão inseridas no banco de dados. Se o cliente, necessário para o cadastramento do projeto, não tiver sido cadastrado, pode-se cadastrá-lo deste mesmo formulário, sem precisar fechá-lo: clique no botão Cliente e um formulário se abrirá para o cadastramento do Cliente. Feche a caixa e automaticamente o cliente cadastrado será inserido no campo correspondente. 49 Para cancelar o cadastramento do projeto, clique em Fechar que as informações serão desconsideradas. Atenção: se as informações não estiverem corretas, não clique em cadastrar, pois o comando Fechar não cancelará a inserção. A.2 Cadastrando o Cliente Clique no menu Cadastrar e escolha a opção Cliente. A seguinte caixa de diálogo se abre para as informações serem inseridas. 50 Após a inserção das informações clique em cadastrar, que as informações serão inseridas no banco de dados. Para cancelar o cadastramento do cliente, clique em Fechar que as informações serão desconsideradas. Atenção: se as informações não estiverem corretas não clique em cadastrar, pois o comando Fechar não cancelará a inserção. A.3 Cadastrando o Endereço Clique no menu Cadastrar e escolha a opção Endereço. A seguinte caixa de diálogo se abre para as informações serem inseridas. 51 Após a inserção das informações basta clicar em cadastrar e as informações serão inseridas no banco de dados. Se a cidade necessária para o cadastramento do projeto não tiver sido cadastrada, pode-se cadastrá-la deste mesmo formulário, sem precisar fechá-lo: clique no botão Cidade e um formulário se abrirá para a inserção da informação. Feche a caixa e automaticamente a cidade cadastrada será inserida no campo correspondente. Para cancelar o cadastramento do endereço, clique em Fechar que as informações serão desconsideradas. Atenção: se as informações não estiverem corretas não clique em cadastrar, pois o comando Fechar não cancelará a inserção. A.4 Cadastrando a Cidade Clique no menu Cadastrar e escolha a opção Cidade. 52 A seguinte caixa de diálogo se abre para as informações serem inseridas. Após a inserção das informações, clique em cadastrar, que as informações serão inseridas no banco de dados. A escolha do Estado é feita selecinando a sigla do estado a que pertence a cidade. Para cancelar o cadastramento da cidade, clique em Fechar que as informações serão desconsideradas. Atenção: se as informações não estiverem corretas não clique em cadastrar, pois o comando Fechar não cancelará a inserção. A.5 Cadastrando a Câmara Clique no menu Cadastrar e escolha a opção Câmara. 53 A seguinte caixa de diálogo se abre para as informações serem inseridas. Nesta caixa, os valores iniciais referentes aos parâmetros de orientação interior da câmara são todos nulos. Os valores destes campos são, normalmente, decimais. Então para a inserção destes valores utiliza-se vírgulas e não pontos (correto: 6,023 mm; errado: 6.023 mm). O tipo da câmara é escolhido dentre as opções do ComboBox. Após a inserção das informações, clique em cadastrar, que as informações serão inseridas no banco de dados. 54 Para cancelar o cadastramento da câmara, clique em Fechar que as informações serão desconsideradas. Atenção: se as informações não estiverem corretas, não clique em cadastrar, pois o comando Fechar não cancelará a inserção. 55 ANEXO B – OPERAÇÃO DO MÓDULO DE GERENCIAMENTO B.1 Inserindo um Registro A inserção de um registro só é possível depois que as informações do projeto, cliente, endereço, cidade e câmara tiverem sido cadastradas. Para inserir um registro clique em Gerenciamento no menu principal e escolha Inserir Registro. A caixa abaixo se abre. Neste formulário, deve-se entrar com o código do projeto e da câmara, pois o restante das informações são inseridas automaticamente no formulário. Caso não sejam conhecidos os códigos do projeto e da câmara, basta procurá-los nos respectivos botões. 56 Quando se pressiona no botão imagem, abre-se uma caixa de diálogo para que seja escolhida a imagem. Escolhendo-a, um outro formulário é aberto para que sejam inseridas todas as informações referentes à imagem aberta. Neste formulário, têm-se que inserir o novo nome da imagem, o local onde foi tomada a imagem (cadastrado no item Endereço), as informações referentes ao ambiente e à posição da imagem e, finalmente, a orientação exterior da imagem (posição, atitude e as precisões). Após a inserção destes dados, o formulário terá o seguinte aspecto: Para aceitar as informações clique em OK. Caso queira rejeitar basta clicar no botão Cancelar. Clicando em OK, volta-se ao formulário principal de inserção de registros, mas agora com a imagem selecinada, seu nome antigo e seu nome novo que será cadastrado no banco. As informações referentes ao projeto e à câmara são preservados. 57 Finalmente, para inserir o registro dentro do banco, clique em Cadastrar. Se clicar em Fechar, antes de cadastrar, as informações inseridas serão perdidas. B.2 Alterando um Registro A alteração de um registro consiste em duas fases. A primeira é localizar o registro que se quer alterar e depois realizar a alteração propriamente dita. O caminho para acessar este item é: no menu principal escolha Gerenciamento e depois desça até o item Alterar Registro. A seguinte caixa se abre e pede a entrada de um dado para a pesquisa. Esta pesquisa pode ser feita por nome da imagem, nome do projeto ou nome da rua (Endereço). 58 O resultado da busca é mostrado na parte central do formulário (Resultado da Busca). Clicando num item, a imagem correspondente é mostrada no lado direito do formulário. Encontrando o registro que se deseja alterar, clique em Alterar. As informações correspondentes ao registro serão recuperadas e mostradas em dois formulários (ambos similares aos formulários de inserção de registro). O primeiro, referente às informações gerais do contexto da imagem, ou seja, o projeto, o cliente e a câmara. O segundo, mostrará as informações relacionadas à imagem propriamente dita. 59 O procedimento para a alteração dos dados é semelhante ao procedimento de inserção de registros. B.3 Excluindo um Registro A exclusão de um registro ou de um conjunto de registros é feita pelo módulo de Exclusão de Registro. Para acessá-lo, selecione Gerenciamento no menu principal e depois em Excluir Registro. O seguinte formulário se abre e pede que entre com um item de busca. Este item pode ser o nome de uma imagem, o nome de um projeto ou o nome de uma rua. Se for selecionado o nome de uma imagem, serão encontradas todas com o nome solicitado, independente do projeto a que pertença. Se a busca for por projeto, todas as imagens daquele projeto serão mostradas. O mesmo se aplica para a busca por nome de rua. 60 Após a busca, o resultado é mostrado na área Resultado da Busca. Para apagar um registro, é necessário passar o(s) item(s) para a área Itens a Excluir. Uma vez selecionados, basta clicar no botão Excluir. Uma mensagem de alerta será mostrada avisando que todos os dados dentro da área Itens a Excluir serão apagados e não poderão ser recuperados. Se for escolhida a opção Sim, todos os registros serão excluídos do banco de dados. Caso contrário, os registros serão conservados dentro do banco. 61 ANEXO C – OPERAÇÃO DO MÓDULO DE CONSULTA C.1 Consulta por Nome da Imagem Para chamar o módulo de consulta por nome da imagem, clique em Pesquisar no menu principal e em seguida Imagem. Uma caixa de diálogo se abre e pede a entrada do nome da imagem. Como nesta versão apenas o formato bitmap é aceito, não é necessário entrar com a extensão do nome da imagem. 62 Com a inserção do nome da imagem, clique no botão Pesquisar e o resultado da pesquisa será mostrado na parte inferior do formulário. C.2 Consulta por Nome do Projeto Para chamar o módulo de consulta por nome do projeto, clique em Pesquisar no menu principal e em seguida Projeto. 63 Uma caixa de diálogo abre e pede a entrada do código do projeto. Caso o usuário não saiba o código, basta clicar no botão Projeto (“dedinho”) e selecionar o desejado. Após a inserção do código, o nome do respectivo projeto aparece na caixa ao lado. Com isso o botão Pesquisar é habilitado. Não é permitida a entrada direta do nome do projeto na caixa de texto (a caixa não é habilitada). Com a inserção do código do projeto, clique no botão Pesquisar e o resultado da pesquisa será mostrado na parte inferior do formulário. 64 C.3 Consulta por Nome do Cliente Para chamar o módulo de consulta por nome do cliente, clique em Pesquisar no menu principal e em seguida Cliente. Uma caixa de diálogo abre e pede a entrada do código do cliente. Caso o usuário não saiba o código, basta clicar no botão Cliente (“dedinho”) e selecionar o desejado. 65 Após a inserção do código, o nome do respectivo cliente aparece na caixa ao lado. Com isso o botão Pesquisar é habilitado. Não é permitida a entrada direta do nome do cliente na caixa de texto (a caixa não é habilitada). Com a inserção do código do projeto, clique no botão Pesquisar e o resultado da pesquisa será mostrado na parte inferior do formulário. C.4 Consulta por Nome da Rua Para chamar o módulo de consulta por nome da rua, clique em Pesquisar no menu principal e em seguida Rua. 66 Uma caixa de diálogo abre e pede a entrada do código da rua. Caso o usuário não saiba o código, basta clicar no botão Rua (“dedinho”) e selecionar a desejada. Após a inserção do código, o nome da respectiva rua aparece na caixa ao lado. Com isso o botão Pesquisar é habilitado. Não é permitida a entrada direta do nome da rua na caixa de texto (a caixa não é habilitada). Com a inserção do código da rua, clique no botão Pesquisar e o resultado da pesquisa será mostrado na parte inferior do formulário. 67 C.5 Consulta por Data do Levantamento Para chamar o módulo de consulta por data do levantamento, clique em Pesquisar no menu principal e em seguida Data do Levantamento. Uma caixa de diálogo abre e pede a entrada da data do levantamento. Esta pesquisa não necessita de nenhum código, mas exige que o usuário saiba quando foi a data do levantamento. 68 À medida que é feita a inserção da data nas caixas de texo, um label vai sendo criado para a confirmação da data. Após a data ter sido inserida completamente, o botão Pesquisar será habilitado. Clicando no botão Pesquisar, o resultado da pesquisa será mostrado na parte inferior do formulário. 69 ANEXO D – OPERAÇÃO DO MÓDULO DE EMISSÃO DE RELATÓRIOS Este módulo é acessado no menu principal, na opção Relatórios. Nesta opção, o usuário pode imprimir, em papel, os valores encontrados numa determinada consulta. A caixa de diálogo abre com três opções de consulta e para cada tipo de consulta, duas possibilidades de relatórios (simples e completo). D.1 Relatório por Nome da Imagem Para a criação de um relatório sobre o nome da imagem é necessária a realização de uma consulta para verificar se a imagem existe e, se existe, localizar os dados referentes à imagem. Caso haja mais de uma imagem com o mesmo nome (em 70 projetos diferentes), todas serão selecionadas e recuperadas para serem mostradas no relatório. Digitando o nome da imagem (não é necessário entrar com a extensão do arquivo), deve-se escolher o tipo de relatório, que pode ser simples ou completo. Por default, o tipo de relatório é o completo. No relatório simples são mostradas apenas as informações básicas da imagem, enquanto o completo mostra todas as informações referentes a cada imagem. Digitado o nome da imagem e escolhido o tipo de relatório, deve-se clicar no botão Criar Relatório. Será apresentado uma janela onde pode-se dar zoom, visualizar as páginas com os registros e imprimir. 71 D.2 Relatório por Nome do Projeto Para a criação de um relatório sobre o nome do projeto é necessário a realização de uma consulta para verificar se o projeto existe e, se existe, localizar todas as imagens pertencentes ao projeto. Digitando o nome do projeto, escolhe-se o tipo de relatório, que pode ser simples ou completo. Por default, o tipo de relatório é o completo. No relatório simples são mostradas apenas as informações básicas das imagens pertencentes ao projeto, enquanto o completo mostra todas as informações referentes a cada imagem. Digitado o nome do projeto e escolhido o tipo de relatório, deve-se clicar no botão Criar Relatório. Será apresentado uma janela onde pode-se dar zoom, visualizar as páginas com os registros e imprimir. 72 D.3 Relatório por Nome da Rua Para a criação de um relatório sobre o nome da rua é necessário a realização de uma consulta para verificar se a rua existe e, se existe, localizar todas as imagens pertencentes à ela. Digitando o nome da rua, escolhe-se o tipo de relatório, que pode ser simples ou completo. Por default, o tipo de relatório é o completo. No relatório simples são mostradas apenas as informações básicas das imagens pertencentes à rua, enquanto o completo mostra todas as informações referentes a cada imagem. Digitado o nome da rua e escolhido o tipo de relatório, deve-se clicar no botão Criar Relatório. Será apresentado uma janela onde pode-se dar zoom, visualizar as páginas com os registros e imprimir. 73 ABSTRACT The foundations of a mobile mapping system are introduced. This system's main features are the integration of different sensors and fast and reliable data and image acquisition of streets and roads. There are two basic units: the mobile and the fixed segments. The mobile segment is characterized by a vehicle on whose roof are mounted a pair of digital video cameras and the GPS antenna; in its interior a notebook and a sort of control devices and support equipment are on board. The fixed segment is characterized by a laboratory, namely the Laboratório de Mapeamento Móvel, equipped with storage, processing and analysis capabilities of spatial data and image. When operating, these systems deliver a large amount of data and information that need to be stored and accessed when necessary. Therefore it is conceived a georeferenced image database as an environment of information storage, access and management. The dissertation introduces the concept, the reasons, the objective, the methodology, the development and aplications of the “Banco de Imagens Georreferenciadas”. 74 Autorizo a reprodução parcial ou completa deste trabalho. Presidente Prudente, 6 de abril de 2001. RONALDO APARECIDO DE OLIVEIRA Capa Folha de rosto Folha de aprovação Ficha catalográfica DADOS CURRICULARES Dedicatória AGRADECIMENTOS Epígrafe SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE ABREVIATURAS RESUMO 1 INTRODUÇÃO 1.1 Sistemas Móveis de Mapeamento Digital 1.2 Banco de Dados e Banco de Imagens 1.3 Proposição 1.4 Objetivos 1.5 Estrutura do Trabalho 2 CONCEITOS BÁSICOS 2.1 Modelagem de um Banco de Dados 2.2 Ambiente de Programação e o Banco de Dados Paradox 3 MODELAGEM E ESTRUTURAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS 3.1 Modelo Conceitual 3.2 Modelo de Representação 4 IMPLEMENTAÇÃO DO BANCO DE IMAGENS GEORREFERENCIADAS 4.1 Módulo de Cadastramento 4.2 Módulo de Gerenciamento 4.3 Módulo de Consulta 4.4 Módulo de Emissão de Relatórios 5 ANÁLISE DO BANCO DE IMAGENS GEORREFERENCIADAS 6 CONCLUSÕES E RECOMENDAÇÕES REFERÊNCIAS ANEXO A – OPERAÇÃO DO MÓDULO DE CADASTRAMENTO ANEXO B – OPERAÇÃO DO MÓDULO DE GERENCIAMENTO ANEXO C – OPERAÇÃO DO MÓDULO DE CONSULTA ANEXO D – OPERAÇÃO DO MÓDULO DE EMISSÃO DE RELATÓRIOS ABSTRACT