Curso de Engenharia de Computação PROTÓTIPO DE SISTEMA DE INFORMAÇÃO GEOGRÁFICA

Curso de Engenharia de Computação PROTÓTIPO DE SISTEMA DE INFORMAÇÃO GEOGRÁFICA Caio Cesar Fantini Campinas São Paulo Brasil Novembro de 2009

Curso de Engenharia de Computação PROTÓTIPO DE SISTEMA DE INFORMAÇÃO GEOGRÁFICA Caio Cesar Fantini Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Dr. Raimundo Claudio, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Mestre Raimundo Claudio da Silva Vasconcelos Campinas São Paulo Brasil Novembro de 2009

Protótipo de Sistema de Informação Geográfica Caio Cesar Fantini Monografia defendida e aprovada em 23 de Novembro de 2009 pela Banca Examinadora assim constituída: Prof. Mestre Raimundo Claudio da Silva Vasconcelos (Orientador) USF Universidade São Francisco Campinas SP. Prof. Mestre Thales de Társis Cezare USF Universidade São Francisco Campinas SP. Eng. Rubia Mara Rossi (Membro externo) Prefeitura de Hortolândia Hortolândia SP.

Dedico este trabalho a todos os professores, familiares e amigos que acreditaram em meu potencial e me deram forças em todos os momentos.

.Agradecimentos Agradeço primeiramente a Deus por ter me iluminado para poder chegar até aqui, meu orientador Prof. Mestre Raimundo Claudio pela dedicação e tempo dispostos para me ajudar durante o desenvolvimento deste projeto. Agradeço e dedico este trabalho a todos os professores que de uma forma ou de outra me deram orientações, dúvidas e imaginação para que eu pudesse desenvolver este projeto. v

Sumário Lista de Siglas... vii Lista de Figuras... viii Resumo... ix Abstract... ix 1 Introdução... 1 2 Conceitos Básicos e Teóricos... 3 2.1 Definições Básicas... 3 2.2 Cartografia... 3 2.3 Sistemas de Coordenadas... 3 2.4 GPS (Global Positioning System)... 4 2.5 Caracterização e Componentes... 4 3 Arquitetura para SIG... 5 3.1 Estrutura Geral... 5 3.2 Gerencia de Dados... 6 4 Conceitos e Desenvolvimento... 09 4.1 Conceitos e Desenvolvimento... 09 4.2 Casos de Uso... 10 4.3 Diagrama de Atividades... 11 4.4 Diagrama de Sequência... 12 4.5 Arquitetura... 13 4.6 Diagrama entidade-relacionamento... 14 4.7 Desenvolvimento... 15 4.7.1 Interface de Configuração... 15 4.7.2 Interface de Consulta... 16 4.7.3 Operações no Banco de Dados... 17 4.7.4 Dados Espaciais com KML... 17 4.7.5 Dados não-espaciais... 19 4.7.6 Cálculo de Área... 20 5 Conclusão e Trabalhos Futuros... 22 5.1 Conclusão... 22 5.2 Trabalhos Futuros... 22 Referências Bibliográficas... 23 vi

Lista de Siglas OGC KML IDE SIG GPS PDA API SGBD SQL TDE TCP UDP GPRS BLOB SGBDR SGBDOR OpenGIS RAD Open Geospatial Consortium Keyhole Markup Language Integrated Development Environment Sistema de Informação Geográfica Global Positioning System Personal Digital Assistants Application Interface Programming Sistema de Gerenciamento de Banco de Dados Structure Query Language Tipos de Dados Espaciais Transmission Control Protocol User Datagram Protocol General Packet Radio Service Large Object Sistema de Gerenciamento de Banco de Dados Relacional Sistema de Gerenciamento de Banco de Dados Objeto-Relacional Open Geographic Information System Rapid Application Development vii

Lista de Figuras Figura 1: Estrutura Geral de Sistema de Informação Geográfica...6 Figura 2: Arquitetura Dual...7 Figura 3: Arquitetura Integrada...7 Figura 4: Casos de uso geral...10 Figura 5: Diagrama de atividades...11 Figura 6: Diagrama de atividades...12 Figura 7: Arquitetura do protótipo...12 Figura 8: Diagrama entidade-relacionamento...12 Figura 9: Interface de configuração...14 Figura 10: Interface de consulta e análise espacial...15 Figura 11: Dados da tabela estrutura_kml...16 Figura 12: Função KML para desenhar ponto...17 Figura 13: Trecho de código para desenhar ponto sem substituição das tags...17 Figura 14: Trecho de código para desenhar ponto com as tags substituídas...17 Figura 15: Ponto projetado no Google Maps...17 Figura 16: Trecho de código da função MontaCabecalhoGrid...18 Figura 17: Trecho de código da função CarregaRegistroGrid que carrega os dados de endereço...18 Figura 18: Trecho de código da função CarregaRegistroGrid que carrega os dados alfanuméricos de um determinado endereço...18 Figura 19: Interface de consulta exibindo o cálculo de área...19 Figura 20: Função que calcula a área do objeto geográfico polígono...20 viii

Resumo Este projeto apresenta um protótipo de Sistema de Informação Geográfica para coletar e armazenar dados espaciais, e que pode ser configurado para funcionar em qualquer modelo de negócio. O protótipo opera em duas camadas, utiliza o MySQL como banco de dados geográfico e relacional no padrão OGC (Open Geospatial Consortium) e a linguagem KML (Keyhole Markup Language) da Google é utilizada para exibir os dados espaciais. A linguagem de programação utilizada para o desenvolvimento foi a Object-Pascal e a IDE (Integrated Development Environment) Delphi. PALAVRAS-CHAVE: Sistema de Informação Geográfica, Banco de Dados Geográfico, OGC (Open Geospatial Consortium), KML (Keyhole Markup Language). Abstract This project presents a Geographic Information System prototype to capture and store spatial data and that can be configured to work in any business model. The prototype operates in two layers, it uses the MySQL as a geographic and relational database at the standard OGC (Open Geospatial Consortium) and the Google s language KML (Keyhole Markup Language) is used to view the spatial data. The programming language used for the development was the Object-Pascal and IDE (Integrated Development Environment) Delphi. KEY WORDS: Geographic Information System, Geographic Database, OGC (Open Geospatial Consortium), KML (Keyhole Markup Language). ix

1 INTRODUÇÃO As empresas de uma forma geral estão cada vez mais se adaptando ao uso de SIG (Sistema de Informação Geográfica), pois este tipo de aplicação possibilita entre outras coisas, o controle visual em tempo real de qualquer tipo de objeto que tenha um GPS (Global Positioning System). As coordenadas geográficas (latitude e longitude) e os dados alfanuméricos relacionados em uma base de dados espacial permitem ao usuário final, gerenciar e analisar de forma eficiente, diversas informações, ou seja, o usuário pode visualizar uma informação alfanumérica qualquer e valida-la de forma visual através de imagens aéreas e formas geométricas georeferenciadas por um sistema de coordenadas. A evolução constante dos satélites e aparelhos de GPS fez com que os sistemas de informação geográfica evoluíssem para atender necessidades específicas das empresas, por exemplo, os agricultores precisam saber detalhadamente o que eles têm plantado e onde foi plantado, pois assim é possível realizar um manejo mais adequado do tipo de cultura, outro segmento que se beneficia é a logística que consegue através de informações geográficas determinar a melhor rota para entregar uma mercadoria, e assim reduz os custos e aumenta os lucros da empresa. O uso do GPS esta ficando cada vez mais comum na vida das pessoas. Atualmente os celulares e PDAs (Personal Digital Assistant) mais modernos estão recebendo um chip de GPS, e o sistema operacional do aparelho fornece uma API (Application Interface Programming) que pode ser utilizada por programadores para desenvolver programas específicos. É também muito comum o uso de GPS nos automóveis, mesmo por que o próprio aparelho informa por falas programadas e mapas digitais detalhados como chegar a um determinado local, sendo que isso só é possível por causa dos algoritmos de busca extremamente complexos e uma base de dados relacional gigantesca. Neste trabalho, foi desenvolvida em Delphi a estrutura inicial de uma aplicação SIG genérica para visualização de dados espaciais que poderá ser melhorada e adaptada a diversos ambientes de trabalho, além disso, utiliza o Google Earth como ferramenta para manipulação dos dados geográficos, pois a Google atualiza constantemente seus mapas digitais e suas imagens aéreas, e também fornece uma API para projeção de coordenadas geográficas, e muitos outros recursos interessantíssimos que permitem desenvolver uma interface dinâmica e muito eficiente para utilização do usuário final. [1] A escolha do banco de dados foi muito importante para o desenvolvimento do protótipo, mesmo por que é o responsável por armazenar todas as informações geográficas e 1

alfanuméricas. Portanto, foi utilizado o MySQL para desenvolvimento, pois é um banco de dados com extensão espacial estável e de padrão aberto baseado no padrão OGC (Open Geospatial Consortium). Uma das grandes dificuldades desse projeto foi desenvolver um esquema relacional de banco de dados que fosse capaz de se adaptar a qualquer modelo de negócio que se deseje gerenciar informações espaciais junto com informações alfanuméricas. Outro grande desafio foi elaborar uma interface que fosse amigável com o usuário e que permitisse recuperar as informações do esquema relacional de forma dinâmica sem prejudicar o desempenho da aplicação. 2

2 CONCEITOS BÁSICOS E TEÓRICOS 2.1 Definições básicas Sistema de Informação Geográfica SIG pode ser utilizado para diversas finalidades relacionadas a armazenamento, análise e manipulação de dados geográficos, os quais representam objetos e fenômenos que contém a localização geográfica como uma característica inerente à informação e fundamental para análise. Uma aplicação SIG pode trabalhar com tipos de dados e aplicações diferentes, em diversas áreas do conhecimento. Alguns exemplos reais e utilizados atualmente são otimização de tráfego, controle cadastral, identificação de culturas, controle de área, gerenciamento de serviços de utilidade pública, monitoramento costeiro, administração de recursos naturais, planejamento urbano, controle de epidemias e entre outros. [2] 2.2 Cartografia A Terra assemelha-se a uma esfera com os pólos achatados, pois o que afeta sua forma é a gravidade, força centrífuga de rotação e variações de densidades de suas rochas e componentes minerais. Portanto, estudos geodésicos apresentam valores diferentes para os elementos de um elipsóide (raio do equador, raio polar e coeficiente de achatamento). O globo terrestre apesar de apresentar distâncias, áreas, formas e direções reais, não é o mais apropriado para lidar com processamentos sistemáticos. No entanto, para permitir tais processamentos são criadas projeções num plano, isto é, cada ponto da esfera é projetado em uma superfície plana. A superfície representa o mapa e pode ser apresentado em diferentes escalas. Um SIG ideal é aquele que trabalha em qualquer escala e com qualquer tipo de dado. [2] 2.3 Sistemas de Coordenadas Os sistemas de coordenadas se dividem em sistema de coordenadas geográficas e sistema de coordenadas planas ou cartesianas. Um objeto geográfico qualquer como uma cidade, rio, estrada e entre outros é representado em um SIG por um conjunto de coordenadas sejam elas geográficas ou planas. Na superfície terrestre um ponto é representado por um valor de latitude e longitude. Longitude é a distância angular entre um ponto qualquer da superfície terrestre e o meridiano de origem. Latitude é a distância angular entre um ponto qualquer da superfície terrestre e a linha do Equador. [2] 3

O sistema de coordenadas planas, também conhecida como sistema de coordenadas cartesianas, baseia-se basicamente nos eixos, horizontal e vertical, cuja intersecção é denominada origem e determina a localização de um ponto. Neste sistema de coordenadas um ponto é constituído pelo número x (horizontal) que corresponde à longitude, e outro número y (vertical) que corresponde à latitude. As coordenadas plano retangulares estão associadas as coordenadas geográficas, com isso é possível converter uma na outra. 2.4 GPS GPS (Global Positioning System) permite localizar qualquer ponto na Terra através da coordenada geográfica (latitude e longitude) e altura. O receptor de GPS recebe e interpreta mensagens específicas que são enviadas por satélites. Os SIGs tiveram um grande crescimento graças a esta tecnologia, pois com ela é possível coletar dados de forma consistente e confiável. A precisão do GPS varia de acordo com a frequência do aparelho, pois quanto maior a freqüência, melhor será o calculo de distancia entre o receptor de GPS e o satélite oferecendo um resultado mais preciso. [2] 2.5 Caracterização e Componentes Existem inúmeros tipos de aplicações relacionadas com SIG, pois SIG é um conjunto de módulos onde cada um desses módulos possui algoritmos diferentes, porém todos relacionados com coordenada geográfica. O banco de dados define SIG como um SGBD não convencional, geográfico, que garante o gerenciamento de dados geográficos. O conceito toolbox define SIG como sendo um conjunto de ferramentas e algoritmos para manipulação de dados geográficos, por exemplo, a produção de mapas. Portanto SIG é composto por uma ampla gama de aplicações que integradas e em sincronismo podem oferecer resultados extraordinários, tais resultados podem ser gerados a partir de análise de dados geográficos, sistemas para apoio a tomada de decisão e geoestatística. Os SIGs possibilitam a integração em uma única base de dados de informações geográficas, provenientes de fonte diversas tais como dados cartográficos, dados de censo e cadastro urbano e rural, imagens de satélite e modelos numéricos de terreno. Além do armazenamento de informações geográficas relacionadas a dados alfanumericos os SIGs oferecem mecanismos para recuperar, manipular, e visualizar estes dados, através de algoritmos de manipulação e análise. [2] 4

3 ARQUITETURA PARA SIG 3.1 Estrutura Geral Um SIG é composto dos seguintes componentes: - Interface com usuário; - Entrada e integração de dados; - Funções de consulta e análise espacial; - Visualização e plotagem; - Armazenamento e recuperação de dados (organizados sob a forma de um banco de dados geográfico). O relacionamento entre estes componentes é hierárquico. O nível mais próximo ao usuário é a interface homem-máquina, a qual define como o sistema é operado e controlado. No nível intermediário o SIG trabalha com mecanismos de processamento dos dados espaciais (entrada, edição, análise, visualização e saída). Já no nível mais interno do sistema existe o sistema de gerenciamento do banco de dados geográficos que oferece armazenamento e recuperação dos dados espaciais e seus atributos, sendo que alguns mecanismos de análise e processamento dos dados podem ser implementados neste nível. [3] As funções de processamento de um SIG operam sobre dados levantados em memória principal, seja em arquivo texto comum ou uma consulta em um banco de dados. As consultas em banco de dados a partir de uma condição recuperam dados geográficos. Exemplos práticos de modos de seleção de dados: [3] - Recupere as cidades do Estado de São Paulo com população entre 100.000 e 500.000 habitantes (consulta por atributos não-espaciais); - Mostre os postos de saúde em um raio de 5 km do hospital municipal de São José dos Campos (consulta com restrições espaciais); - Calcule a área de todos os talhões que tenham cana de açúcar plantada da variedade RB72454 e esteja com idade de 12 meses. (consulta com atributos não-espaciais). [3] A Figura 1 apresenta o relacionamento entre os principais componentes ou subsistemas de um SIG. Os objetivos e necessidades de cada sistema são implementados de forma distinta dependendo das necessidades, porém todos os subsistemas devem estar presentes em um SIG.[3] 5

Figura 1: Estrutura Geral de Sistema de Informação Geográfica. 3.2 GERÊ CIA DE DADOS A principal diferença e o que define a arquitetura geral de um SIG é a forma como os dados geográficos são gerenciados. Atualmente existem três diferentes arquiteturas de SIGs que utilizam os recursos de um SGBD: dual, integrada baseada em SGBDs relacionais e integrada baseada em extensões espaciais sobre SGBDs objeto-relacionais. [3] A implementação de um SIG com estratégia dual utiliza um SGBD relacional para armazenar os atributos convencionais dos objetos geográficos (na forma de tabelas) e arquivos para armazenar as representações geométricas destes objetos. Os dados no modelo relacional são organizados na forma de uma tabela onde as linhas correspondem aos dados e as colunas correspondem aos atributos. [3] Toda entidade gráfica inserida no sistema recebe um rótulo ou identificador que é relacionado aos dados não-espaciais armazenados no SGBD relacional. A única vantagem da arquitetura dual é poder utilizar os SGBDs relacionais de mercado. No entanto, o problema está no fato de que como as representações geométricas dos objetos espaciais estão fora do controle do SGBD, pois esta estrutura dificulta a otimização de consultas, gerência de transações e controle de integridade e concorrência. As principais desvantagens da arquitetura são: - dificuldades no controle e manipulação dos dados espaciais; - dificuldades em manter a integridade entre a componente espacial e a componente alfanumérica; 6

- as consultas são mais lentas, afinal de contas são processadas separadamente. A consulta dos dados não-espaciais é feita pelo SGBD que é separado da parte espacial. A parte espacial é processada pelo aplicativo utilizando os arquivos proprietários; - a integração entre os dados é complicada, pois cada sistema produz seu próprio arquivo proprietário sem seguir um formato padrão. [3] Figura 2: Arquitetura Dual. Figura 3: Arquitetura Integrada. A arquitetura integrada consiste em armazenar todo o dado espacial no SGBD, ou seja, a entidade gráfica e os atributos são armazenados dentro do banco de dados. A principal vantagem é ter todos os recursos de um SGBD para realizar consultas otimizadas, manipulação de dados espaciais, gerência de transações, controle de integridade e concorrência. Existem duas alternativas para a arquitetura integrada: baseada em SGBDs relacionais; baseada em extensões espaciais sobre SGBDs objeto-relacionais. [3] Na arquitetura integrada baseada em um SGBD relacional os dados espaciais são armazenados em campos longos, chamados BLOBs, sendo este o ponto critico do sistema, pois as principais desvantagens são: - O dado espacial (arquivo) inserido no campo BLOB se torna uma cadeia binária, portanto não é possível conhecer a semântica do seu conteúdo; - Os métodos de acesso e consulta espacial devem ser implementados na camada superior ao SGBD, pois os dados espaciais são uma cadeia binária; - A linguagem SQL possui recursos limitados para o tratamento de campos BLOBs; 7

- Os arquivos armazenados nos campos BLOBs acabam ocupando muito espaço físico no servidor do SGBD, aumentando o custo dos equipamentos e tornando a implementação do SIG muito cara; A arquitetura ideal e que esta sendo cada vez mais implementada nos novos SIGs é a que utiliza extensões espaciais desenvolvidas sobre SGBDs obeto-relacionais (SGBDOR). O grande diferencial desta arquitetura é que ela possibilita o armazenamento dos dados espaciais no formato de objetos como pontos, linhas e polilinhas. Além do armazenamento também é possível gerenciar e analisar os dados através de funções e procedimentos espaciais disponibilizados pelo próprio SGBD. Portanto, o SGBDOR é mais adequado para tratar dados complexos, como dados geográficos, do que um SGBDR, o qual não oferece estes recursos. O SGBDOR com extensão espacial deve fornecer as seguintes características: - Fornecer tipos de dados espaciais (TDEs) como ponto, linha, polilinha e geometrias em geral e permitir a manipulação como os tipos básicos (inteiro, string, datetime, etc...); - A linguagem de consulta SQL deve ser capaz de realizar consultas, inserções, atualizações e outras operações sobre as TDEs; - Fornecer métodos de armazenamento e acesso (indexação espacial) e métodos de otimização de consultas; Portanto, os SGBDORs com extensão espacial não oferecem apenas as TDEs, mas também funções e operadores que podem ser utilizados junto com a consulta SQL. Os SGBDORs Oracle Spatial, IBM DB2 Spatial Extender, Informix Spatial Datablade, MySQL Spatial Extensions e recentemente o Microsoft SQL Server suportam extensão espacial. A OpenGIS (OGC, 1996) tem um padrão de especificações para extensão espacial que é utilizado por todos os SGBDORs, porém existe algumas variações relevantes entre os modelos de dados, semântica dos operadores espaciais e mecanismos de indexação. [3] A OpenGIS é uma associação formada por organizações públicas e privadas envolvidas com SIGs, sendo que sua função é criar e gerenciar uma arquitetura padrão para geoprocessamento. Sua função é: - Estabelecer um modelo universal de dados espaço-temporais e de processos, chamado de dados OpenGIS; - Estabelecer especificações da linguagem SQL para implementação de modelos de dados OpenGIS; - Estabelecer especificações para diversos ambientes computacionais distribuídos para implementar o modelo de processo OpenGIS. [4] 8

4 CONCEITOS E DESENVOLVIMENTO 4.1 Conceitos de Desenvolvimento O protótipo de SIG foi desenvolvido para funcionar em duas camadas, sendo que a primeira camada corresponde ao SGBD e a segunda camada a aplicação que é executada no cliente. O SGBD armazena a estrutura de endereçamento e a estrutura de dados alfanuméricos de uma determinada instituição que tem sua própria configuração. A partir do momento que as configurações de uma determinada instituição são efetuadas os dados geográficos e alfanumericos já podem ser armazenados e consequentemente visualizados pela aplicação. A interface com o usuário e as regras de negócio da aplicação foram desenvolvidas utilizando a linguagem Object-Pascal e a IDE Delphi por ser considerada uma das melhores ferramentas RAD do mercado. O SGBD com extensão espacial escolhido foi o MySQL Community por ser de código fonte aberto e fornecer suporte a extensão espacial, além disso já é um sistema estável e muito utilizado em diversos projetos complexos. O MySQL além de armazenar os dados espaciais também fornece funções específicas para análise espacial como cálculo de área, intersecção entre linhas e pontos, cálculo de distância, verificar se um polígono está fechado ou aberto e etc. Neste projeto foi implantada a função espacial para cálculo de área. [5] Para projeção dos dados geográficos e manipulação dos mapas utilizou-se a linguagem KML da Google, pois com ela é possível projetar dados geográficos sobre planos cartográficos e imagens de satélite gratuitas de excelente qualidade do Google Maps. O interessante do projeto é que a estrutura da linguagem KML fica armazenada em uma tabela especial do banco de dados, pois se a estrutura da linguagem evoluir basta alterar a estrutura no banco de dados sem ter que modificar o código fonte do cliente tornando o sistema ainda mais flexível. As funções desenvolvidas nas regras de negócio do cliente fazem acesso a esta tabela no momento de gerar o código KML, sendo que cada estrutura é composta por parâmetros como coordenada, cor, texto e entre outras de acordo com o objeto geográfico que será projetado no Google Maps. 9

4.2 Casos de uso O principal objetivo do protótipo SIG é permitir que a aplicação seja flexível ao ponto de poder gerenciar qualquer tipo de informação espacial e não-espacial. Portanto, o estudo de caso de uso foi analisado e definido no principio fundamental de configuração das variáveis que determinam a estrutura de endereçamento e a estrutura de dados que se deseja gerenciar. Portanto, para uma informação geográfica ser considerada válida é necessário que ela seja composta por coordenada, endereço e dados alfanuméricos, sendo assim foi desenvolvimento o seguinte caso de uso apresentado na figura 4 a seguir. Figura 4: Casos de uso geral. O estudo de caso de uso apresentado na figura 4 é composto pelas seguintes ações: Cadastrar cliente / instituição: Insere o cliente ou instituição entrando com seu nome e ramo de atividade. Cadastrar estrutura de endereçamento: Insere a estrutura de endereçamento de um determinado cliente. Cadastrar estrutura de dados: Insere a estrutura de dados de um determinado cliente. Cadastrar dados espaciais e não-espaciais: Insere dados espaciais e não-espaciais coletados por um PDA. 10

Consultar dados espaciais e não-espaciais: Consulta os dados espaciais e não-espaciais de um determinado cliente. 4.3 Diagrama de atividades Com base no estudo de casos de uso foi desenvolvido o diagrama de atividades apresentado na figura 5 a seguir. Após o cadastro do cliente / instituição basta o administrador do sistema estabelecer as configurações da estrutura de endereço e dados, a partir deste momento o sistema já esta pronto para ser utilizado. Figura 5: Diagrama de atividades. O administrador do sistema tem acesso total ao sistema, já o usuário comum pode apenas consultar e cadastrar dados espaciais e não-espaciais. O processo de atividades é completamente dependente, ou seja, para configurar, ou cadastrar ou consultar dados espaciais é necessário que o usuário cadastre um cliente ou instituição, pois toda a estrutura relacional é extremamente interligada. Com a apresentação do estudo de caso de uso e o diagrama de atividades já é possível entender como a aplicação funciona. É um SIG genérico que pode ser implantado em qualquer modelo de negócio. 11

4.4 Diagrama de sequência Com base no desenvolvimento do estudo de caso de uso e no diagrama de atividades foi desenvolvida toda a sequência de funcionamento do sistema. A seguir na figura 6 é apresentado o diagrama de sequência que é composto por três linhas de tempo: user, frontend, back-end e GoogleMaps. A linha de tempo user representa o usuário final que faz as solicitações através da interface do sistema que é chamado no diagrama de sequência de front-end. O front-end envia as solicitações do usuário para a linha de tempo back-end, sendo a responsável por definir as regras de negócio, ou seja, o que o sistema irá fazer com a informação enviada pelo usuário. A última linha de tempo é o GoogleMaps que é acionado apenas nas operações de consulta dos dados espaciais. Figura 6: Diagrama de sequência. 12

4.4 Arquitetura O protótipo de SIG foi desenvolvido para funcionar em duas camadas, sendo uma camada do SGBD e a outra do cliente, onde roda a aplicação. Para que o cliente possa ter total acesso ao sistema ele deve estar conectado a Internet, pois desta forma ele pode utilizar os recursos do Google Maps para projetar os dados espaciais. O projeto foi desenvolvido através do conceito da arquitetura integrada, a qual utiliza SGBDOR (Sistema de Gerenciamento de Banco de Dados Objeto-Relacional), que foi explicado no capítulo anterior. O MySQL suporta extensão espacial e trabalha neste conceito de banco de dados objeto-relacional, portanto, os dados cadastrados e consultados ficam armazenados em tipos de campos especiais do chamados ponto, linha e polilinha. A seguir há a figura 6 que dá uma visão geral do funcionamento do prototipo. Os desktops fazem acesso ao SGBD MySQL através de uma conexão TCP, mas os PDAs que fazem a coleta dos dados espaciais e não-espaciais fazem acesso UDP ao banco de dados, pois muitos locais não contém sinal GPRS, EDGE ou 3G para envio dos dados pela Internet, portanto a solução encontrada foi armazenar os dados em uma base de dados compacta e enviar os dados para a base de dados central quando tiver conexão com a Internet. Os desktops além de fazer acesso ao banco de dados centralizado também geram os arquivos KMLs a partir dos dados do banco de dados, depois de gerar os arquivos os mesmos são enviados para os servidores da Google que fazem o processamento e devolvem o resultado final que são os mapas, imagens de satélite e os dados espaciais e não-espaciais. Figura 7: Arquitetura do protótipo. 13

4.5 Diagrama entidade-relacionamento O diagrama entidade-relacionamento apresentado na figura 7 a seguir foi projetado para funcionar de maneira flexível permitindo que existam vários clientes / instituições cadastradas e que cada uma possa ter sua própria configuração de endereçamento e dados. No entanto o desenvolvimento da interface final com o usuário e das regras de negócio são bastante complexas, afinal de contas inserir dados e recuperar dados de forma intuitiva para o usuário final não é uma tarefa fácil. Figura 8: Diagrama entidade-relacionamento. 14

4.6 Desenvolvimento Com a definição do estudo de caso de uso, do diagrama de atividades e do diagrama entidade-relacionamento iniciou-se o desenvolvimento da interface do protótipo SIG. A interface ficou separada por duas abas, sendo uma aba para configuração do cliente / instituição e outra para consulta dos dados espaciais e não-espaciais. 4.6.1 Interface de Configuração A interface para configuração do sistema é apresentada na figura 8 a seguir, sendo composta por três regiões. Região 1: Permite que o administrador do sistema cadastre um novo cliente / instituição. No entanto ele deve iniciar um novo cadastro clicando no botão Novo, digitar o nome do cliente / instituição e selecionar o ramo de atividade e clicar no botão Gravar. Região 2: Nesta região o administrador do sistema deve clicar no botão Novo para iniciar o cadastro de um novo rótulo, selecionar o cliente / instituição que já foi cadastrado na região 1 e em seguida é possível digitar o rótulo, tipo de dado que será armazenado e descrição do rótulo para que o usuário saiba o que está cadastrando e finalmente clicar no botão Gravar. Região 3: O administrador do sistema deve clicar no botão Novo, selecionar o cliente / instituição que foi cadastrado na região 1, digitar o rótulo do nível de endereço e clicar no botão Gravar. Região 1 Região 2 Região 3 Figura 9: Interface de configuração. 15

4.6.2 Interface de Consulta Após o administrador do sistema cadastrar o cliente / instituição e configurar as estruturas de endereçamento e dados já é possível que o usuário utilize a ferramenta de consulta dos dados espaciais e não-espaciais. Além de consultar os dados de um determinado cliente / instituição também é possível calcular a área de um polígono de uma determinada região inserida no sistema. A interface final do usuário para consulta dos espaciais e não-espaciais é composta por três regiões conforme apresentado na figura 9 a seguir: Região 1: O usuário seleciona o cliente / instituição que deseja visualizar os dados espaciais e não-espaciais e clica botão Consultar. Região 2: Esta região carrega os dados espaciais a partir de um arquivo KML, ou seja, quando o usuário clica no botão Consultar que está na região 1 o sistema executa uma função que carrega todos os dados espaciais e não-espaciais do cliente / instituição em um arquivo KML que é carregado em um browser dentro do sistema. Região 3: Esta região o sistema simplesmente carrega os dados não-espaciais que estão atrelados aos dados espaciais apresentados na região 2, mas isto só acontece depois que o usuário selecionar o cliente / instituição e clicar no botão Consultar. Região 1 Região 2 Região 3 Figura 10: Interface de consulta e análise espacial. 16

4.6.3 Operações no Banco de Dados O sistema tem uma classe de conexão chamada de TZConnection que pertence ao componente Zeos Access. A partir desta conexão todas as operações SQL do banco de dados são executadas. As funções e procedimentos que realizam operações de I SERT, UPDATE e DELETE utilizam a classe TZQuery. Já as operações de consulta utilizam a classe TZReadOnlyQuery, sendo que ambas também pertencem ao componente Zeos Access. 4.6.4 Dados espaciais com KML Os dados espaciais apresentados na figura 10 são gerados pelos servidores da Google, pois quando o usuário clica no botão Consultar todos os espaciais do cliente / instituição são consultados e gravados em um arquivo KML que é enviado via HTTP para os servidores do Google Maps que realizam o processamento das informações e enviam a resposta no formato apresentado na figura 14. O arquivo KML é gerado da seguinte maneira: 1º O sistema consulta as estruturas do arquivo KML na tabela estrutura_kml diagrama entidade-relacionamento. A informação espacial pode ser ponto, linha ou polilinha, sendo que cada informação contém uma estrutura específica conforme a figura 11 a seguir: Figura 11: Dados da tabela estrutura_kml. A figura 10 apresenta os registros da tabela estrutura_kml, portanto, é possível ver que cada registro é uma estrutura diferente que compõe o arquivo KML. Um arquivo KML é composto basicamente da estrutura Cabeçalho e Rodapé. O sistema constrói este arquivo KML de acordo com os dados espaciais do cliente, isto é, se o cliente tiver uma informação espacial Polígono, então a função ConsultaPoligonoCliente insere a estrutura no arquivo KML. As estruturas contêm tags que são substituídas pelos dados espaciais do cliente. 17

A figura 11 apresenta a estrutura da Função Ponto e a figura 12 apresenta a estrutura do Ponto, sendo que ambas estão armazenadas na tabela estrutura_kml. Figura 12: Função KML para desenhar ponto. Função 13: Trecho de código para desenhar ponto sem substituição das tags. 2º Após a função espacial consultar a estrutura do arquivo KML ela substitui as tags pelos dados espaciais da instituição conforme apresentado na figura 13 a seguir: Figura 14: Trecho de código para desenhar ponto com as tags substituídas. O trecho de código aplicado na estrutura da Função Ponto forma a informação apresentada na figura 14 a seguir: Figura 15: Ponto projetado no Google Maps. A exibição dos dados espaciais no Google Maps dentro da aplicação foi feita utilizando um objeto TWebBrowser que funciona como um browser. Na verdade ele utiliza o Browser padrão da máquina do usuário. O arquivo KML gerado pelo sistema é gravado na 18

máquina do usuário como HTML e depois é solicitado que o browser da aplicação execute o arquivo com o método Navigate, sendo que este método recebe o caminho do arquivo. 4.6.5 Dados não-espaciais Além do sistema gerar os dados espaciais através do arquivo KML ele também exibe os dados não-espaciais na Região 3 que foi apresentado na figura 9. Para exibir os dados não-espaciais foi necessário elaborar duas funções, uma função chamada MontaCabecalhoGrid e a outra CarregaRegistroGrid, sendo que ambas recebem como parâmetro o objeto TStringGrid e o nome do cliente. Afigura 15 a seguir monta o cabeçalho do grid de acordo com as configurações de endereço e dados realizadas pelo administrador do sistema. Figura 16: Trecho de código da função MontaCabecalhoGrid. Figura 17: Trecho de código da função CarregaRegistroGrid que carrega os dados de endereço.. Figura 18: Trecho de código da função CarregaRegistroGrid que carrega os dados alfanuméricos de um determinado endereço.. 19

4.6.6 Calculo de área O MySQL Extensions Spatial oferece diversas funções para manipulação dos dados espaciais, as quais permitem realizar o cálculo de área de um polígono qualquer que esteja fechado. A terceira região do sistema conforme a figura 18 a seguir apresenta contém o botão Calcular. Depois que o usuário seleciona um registro na tabela de informações não-espaciais ele pode clicar no botão para calcular a área, porém se o local selecionado não tiver um polígono ou não tiver um polígono fechado o sistema informa que não é possível calcular. [6] Região 3 Figura 19: Interface de consulta exibindo o cálculo de área. 20

O trecho de código a seguir na figura 19 apresenta a função utilizada para calcular a área do objeto geográfico. A função recebe como parâmetro a identificação geográfica do registro que é selecionado pelo usuário na tabela de informações não-espaciais, e em seguida o é realizada uma consulta na tabela dado_geo que armazena os dados espaciais. A consulta contém a função AREA que pertence ao MySQL Spatial Extension, sendo ela a responsável por calcular a área. A consulta pode retornar mais de um polígono, portanto, após a consulta os áreas calculadas diferentes de zero são armazenadas na variável área_metros_quadrados e depois é retornada para o evento OnClick do botão calcular que exibe o resultado na tela. [6] Figura 20: Função que calcula a área do objeto geográfico polígono. 21

5 CONCLUSÃO E TRABALHOS FUTUROS 5.1 Conclusão Após um estudo aprofundado de como os SIGs funcionam, desde seus conceitos teóricos até práticos, foi possível desenvolver um protótipo em duas camadas que pode ser utilizado a partir de qualquer modelo de negócio. A análise de requisitos e os casos de uso pré-estabelecidos permitiram um desenvolvimento rápido e preciso das interfaces e regras de negócio do sistema. O MySQL funcionou perfeitamente em todo o processo, desde o desenvolvimento do diagrama entidade-relacionamento até a execução da aplicação. A linguagem KML permitiu utilizar todos os recursos oferecidos pelo Google Maps, por exemplo, projeção dos dados espaciais e ferramentas de controle para o usuário final. A estrutura flexível que foi desenvolvida fez com que o desenvolvimento das interfaces e regras de negócio fosse bastante complexa, pois todas as informações exibidas eram dinâmicas e pré-estabelecidas para cada instituição, mas mesmo assim foi possível concluir o protótipo com sucesso. 5.2 Trabalhos Futuros O sistema pode ser significativamente otimizado, mas respeitando sua idéia de ser totalmente flexível. Portanto, para trabalhos futuros do sistema é proposto: Desenvolver uma arquitetura em três camadas distribuídas; Implantar gerenciamento de transações no MySQL; Desenvolver diversas análises espaciais além do cálculo de área; Inserir novas funções KML para projeção dos dados; Desenvolver novas funções para tratamento dos dados espaciais; Melhorar a interface do sistema; Desenvolver o sistema para dispositivo móvel para coleta dos dados espaciais. 22

Referências Bibliográficas [1] Google Code KML Tutorial Disponível em: http://code.google.com/intl/pt-br/apis/kml/documentation/kml_tut.html Acessado em: 10/04/2009 [2] GILBERTO CÂMARA; MARCO A. CASANOVA; ANDREA S. HEMERLY; GEOVANE C. MAGALHÃES; CLAUDIA M. B. MEDEIROS: Anatomia de Sistemas de Informação Geográfica, Capítulo 1 Conceitos Básicos. 5 20p. Disponível em: http://www.dpi.inpe.br/geopro/livros/anatomia.pdf Acessado em: 07/03/2009 [3] GILBERTO CÂMARA; GILBERTO RIBEIRO DE QUEIROZ. Fundamentos de Geoprocessamento, Capítulo 3 - Arquitetura de Sistemas de Informação Geográfica. 2-12p. Disponível em: http://www.dpi.inpe.br/gilberto/livro/cap3-arquitetura.pdf Acessado em: 10/03/2009 [4] Open Geospatial Consortium About OGC Disponível em: http://www.opengeospatial.org/ogc Acessado em: 06/11/2009 [5] Sun Microsystems MySQL Spatial Extensions Disponível em: http://dev.mysql.com/doc/refman/6.0/en/spatial-extensions.html Acessado em: 15/08/2009 [6] Sun Microsystems MySQL Spatial Extensions Geometry Functions Disponível em: http://dev.mysql.com/doc/refman/5.1/en/geometry-propertyfunctions.html Acessado em: 03/09/2009 23

Referências Bibliográficas das Figuras Figura 1: Estrutura Geral de Sistema de Informação Geográfica. GILBERTO CÂMARA; GILBERTO RIBEIRO DE QUEIROZ. Fundamentos de Geoprocessamento, Capítulo 3 - Arquitetura de Sistemas de Informação Geográfica. 3p. Disponível em: http://www.dpi.inpe.br/gilberto/livro/cap3-arquitetura.pdf Figura 2: Arquitetura Dual. GILBERTO CÂMARA; GILBERTO RIBEIRO DE QUEIROZ. Fundamentos de Geoprocessamento, Capítulo 3 - Arquitetura de Sistemas de Informação Geográfica. 5p. Disponível em: http://www.dpi.inpe.br/gilberto/livro/cap3-arquitetura.pdf Figura 3: Arquitetura Integrada. GILBERTO CÂMARA; GILBERTO RIBEIRO DE QUEIROZ. Fundamentos de Geoprocessamento, Capítulo 3 - Arquitetura de Sistemas de Informação Geográfica. 5p. Disponível em: http://www.dpi.inpe.br/gilberto/livro/cap3-arquitetura.pdf 24